Software empresarial: acuerda las reglas de negocio antes de programar con IA

Volver

Kevin Riedl

15 min de lectura · 12 oct 2026
Última revisión 12 de octubre de 2026

Siguiente

La función de reembolsos parece lista para un agente de programación: las compras de hace menos de 30 días cumplen las condiciones. Entonces ventas reenvía una promesa de 60 días. Finanzas pregunta si el importe supera los 5.000 €. Soporte explica que los gestores de Customer Success siempre han hecho excepciones.

El desarrollador puede escribir la condición. La empresa todavía tiene que acordar qué significa.

Veamos este proceso empresarial ficticio. Una persona de cumplimiento normativo acepta la práctica actual; otra cree que infringe una política que nadie encuentra. La promesa de ventas procede de una página de Confluence cuyo autor dejó la empresa. Cada departamento espera que el nuevo software conserve su interpretación.

Las reglas de negocio contradictorias son instrucciones incompatibles sobre una misma decisión empresarial. Para resolverlas hacen falta evidencias, una persona con autoridad y un resultado explícito para los casos en disputa. Generar más código no otorga esa autoridad.

Los sistemas empresariales también plantean retos técnicos difíciles, sobre todo en seguridad y estado distribuido. Este artículo trata un obstáculo previo: decidir qué comportamiento respaldará la empresa. Los plazos de reembolso y el umbral de aprobación del ejemplo son reglas empresariales ilustrativas, no derechos de reembolso establecidos por ley.

Empieza con un registro de reglas contradictorias

Registra cada afirmación por separado antes de incorporarla a una especificación. Un párrafo bien redactado puede ocultar un desacuerdo que una tabla pequeña deja a la vista. Conserva el texto original, la versión de la fuente y las operaciones afectadas junto a la pregunta que necesita una decisión.

Comprueba primero el ámbito de aplicación. Un plazo habitual de 30 días y un compromiso confirmado de 60 días pueden ser válidos para compras distintas. La aprobación de finanzas responde a otra pregunta. Antes de tratar dos instrucciones como contradictorias, confirma que se refieren a la misma operación y a la misma decisión.

Un documento antiguo es una evidencia que hay que investigar. Su antigüedad por sí sola no invalida un compromiso con el cliente. Del mismo modo, repetir excepciones no demuestra que el personal tuviera autoridad para concederlas. Una búsqueda documental sin resultados deja una pregunta abierta.

El manual de ingeniería de sistemas de la NASA vincula expresamente la resolución de conflictos entre las partes con saber quién tiene autoridad para decidir. Esa misma disciplina resulta útil aquí: identificar la decisión que sigue pendiente.

Asigna a cada conflicto un responsable, una fecha límite para decidir y una instrucción temporal de tramitación. Si una promesa de ventas sin resolver afecta a una solicitud en curso, envíala al circuito de revisión acordado. Ese circuito necesita una persona responsable y un plazo de escalado que respete la fecha límite aplicable al cliente.

Define quién tiene autoridad para cada decisión

Elige un responsable para la decisión concreta y registra los límites de su mandato. «Ya decidirá el negocio» deja la tarea sin asignar.

El marco DACI de Atlassian distingue a quien impulsa la decisión de quien la aprueba, quienes aportan información y quienes necesitan conocer el resultado. Esa separación permite coordinar la recogida de evidencias sin asumir de forma implícita la autoridad sobre la política.

En el ejemplo, el responsable de finanzas decide la regla de aprobación. Las personas autorizadas de las áreas comercial y jurídica determinan qué compromisos con clientes son aplicables. El responsable de la política define las circunstancias excepcionales y delega, cuando corresponda, la facultad de conceder excepciones. La dirección de producto coordina el proceso dentro de ese mandato.

Un CPO a tiempo parcial puede hacer visibles las decisiones pendientes y coordinar el trabajo. El cargo no concede automáticamente permiso para omitir requisitos de finanzas o cumplimiento normativo. Si una decisión necesita varias aprobaciones, identifica cada una y su secuencia.

Registra la regla acordada, su justificación, las aprobaciones necesarias, el grupo de clientes afectado y la fecha de entrada en vigor. Añade los enlaces a las fuentes y la persona que mantendrá el registro. Quien dirija el producto debe poder explicar por qué existe la regla cuando ya no quede nadie de la reunión original.

Si el acuerdo se bloquea, plantea una opción concreta a la persona con autoridad. Por ejemplo: «Estas compras tienen compromisos de 60 días en disputa. ¿Deben pasar a revisión mientras el responsable contractual determina cuáles están cubiertas?». Es más fácil decidir eso que responder a una petición abierta de ponerse de acuerdo sobre los reembolsos.

Separa las condiciones del reembolso de la aprobación del pago

Un reembolso que cumple las condiciones puede seguir necesitando la aprobación de finanzas antes de ejecutar el pago. Combinar ambas preguntas en un único booleano facilita que se pierda ese requisito.

Supongamos que los responsables ficticios aprueban este alcance limitado: un reembolso íntegro para una compra con el pago liquidado y un importe positivo en EUR, sin reembolsos previos ni disputas activas. Los demás casos pasan a un circuito de revisión con su propio responsable. Las tablas proponen ejemplos; no son una política de producción ni un sistema de reembolsos ejecutado.

En este ejemplo, el registro de la compra identifica la versión de la política aprobada y un plazo de 30 o 60 días. El plazo de 60 días solo se aplica cuando la revisión autorizada confirma ese compromiso para la compra. Una promesa sin resolver permanece en revisión.

El plazo se mide desde que se completa la compra hasta que se recibe la solicitud de reembolso, con marcas de tiempo UTC y periodos transcurridos de 24 horas. «Menos de 30 días» excluye, por tanto, el instante en que se cumplen exactamente 30 días. Son decisiones explícitas para este ejemplo; tu empresa debe definir su propio evento, zona horaria y límite.

Un tiempo transcurrido negativo, una marca temporal ausente o una autoridad para conceder excepciones sin verificar son datos sin resolver. La excepción aprobada debe identificar la compra y seguir siendo válida para la solicitud. Las aprobaciones de excepción caducadas, revocadas, contradictorias o que no correspondan a la solicitud pasan a REVIEW. NOT_ELIGIBLE describe el resultado de esta política; un derecho contractual o de obligado cumplimiento que esté en disputa requiere la revisión correspondiente.

Evalúa ahora la aprobación del pago por separado. Dentro del alcance de este ejemplo, el umbral utiliza el importe bruto liquidado de la compra en EUR. Exactamente 5.000 € no supera los 5.000 €. Los responsables deben definir otra base de cálculo antes de incorporar reembolsos parciales u otras monedas.

En este ejemplo, la excepción que un CSM aprueba para un reembolso fuera de plazo nunca sustituye la aprobación de finanzas. «Listo para los controles de pago» tampoco significa que el dinero ya se haya enviado. La autorización, las solicitudes duplicadas y los fallos de pago siguen necesitando ingeniería y verificación.

Decision Model and Notation, de OMG, ofrece un estándar para expresar decisiones. Una hoja de cálculo también puede mostrar estas condiciones antes de que el equipo elija un motor de ejecución.

El orden de las reglas merece una comprobación aparte. En las políticas de coincidencia documentadas por Camunda, Unique permite como máximo una regla coincidente; First devuelve la primera coincidencia. Ninguna determina qué política empresarial debe tener prioridad.

Nuestras tablas son explicativas, no DMN ejecutable. Antes de implementar, verifica todas las combinaciones de entradas que quieras admitir. La ausencia de coincidencias necesita un resultado definido, y una fila genérica no debe solaparse con las filas habituales bajo Unique. Reordenar filas para eliminar un conflicto visible puede imponer una decisión empresarial sin que nadie la haya aprobado.

Convierte los límites en disputa en ejemplos de aceptación

Pide a los responsables que aprueben pares concretos de entradas y resultados antes de empezar a implementar. Los siguientes ejemplos comprueban las decisiones anteriores. Son casos de aceptación propuestos, no resultados de pruebas realizadas.

Adjunta estos ejemplos al registro de la decisión. Los desarrolladores pueden convertir los pares aprobados en pruebas. Quienes revisen el trabajo podrán vincular una prueba fallida con la decisión empresarial que protege.

Prueba también las combinaciones sin cubrir, incluidos los datos inválidos y las aprobaciones contradictorias. Cuando la ejecución de pagos entre en el alcance, añade sus propios casos de fallo y repetición. Mantén esos controles separados de los ejemplos de elegibilidad para que una prueba de política superada no se confunda con una integración de pagos segura.

Encarga a la IA el análisis de evidencias y la implementación aprobada

Usa la IA para detectar contradicciones, preparar alternativas y traducir decisiones aprobadas en código y pruebas. Un agente de programación puede asumir partes sustanciales del trabajo. La organización sigue aportando la autoridad que permite poner la regla en vigor.

Antes de decidir, pide al asistente que compare las fuentes autorizadas, conserve fechas y citas, y señale las definiciones ausentes. Puede detectar que un documento dice «importe de la compra» y otro «importe del reembolso». También puede proponer el caso de 5.000,01 € que nadie había discutido.

Una petición de análisis útil sería:

Compara estas fuentes sobre reembolsos. Enumera las afirmaciones contradictorias con su fuente, versión, fecha de entrada en vigor y grupo de clientes afectado. Separa las decisiones registradas de los supuestos y la práctica histórica. Identifica quién debe resolver cada pregunta. Propón ejemplos de casos límite, pero deja abierto el resultado esperado cuando falte la decisión autorizada.

Después de que los responsables aprueben la regla, entrega al agente la versión de la decisión y los ejemplos aceptados. Exige que señale cualquier ambigüedad nueva en vez de elegir una política por la fecha o la frecuencia con que aparece. Las pruebas derivadas únicamente de la misma instrucción sin resolver pueden repetir el mismo supuesto.

Nuestra guía de GitHub Spec Kit para producción explica el proceso posterior de especificación, planificación e implementación. Una especificación resulta más útil cuando las decisiones empresariales en disputa que la sustentan tienen un responsable y un resultado.

Mantén la decisión vigente después del lanzamiento

Publica la regla aprobada donde ventas, soporte e ingeniería vayan a utilizarla. Actualiza las instrucciones comerciales y de soporte junto con la implementación. Marca claramente el material sustituido y conserva el historial necesario para explicar las compras anteriores.

La guía de gestión de requisitos de la NASA relaciona los cambios aprobados con el análisis de impacto y los registros trazables. En este proceso, significa identificar a qué clientes, instrucciones y pruebas afecta cada cambio de regla.

El registro debe conservar el identificador de la regla, su versión, responsable, evidencia de aprobación y ámbito de aplicación. Enlázalo con los ejemplos de aceptación y el cambio en la implementación. Una nueva política de 30 días puede aplicarse a compras futuras mientras un grupo de clientes anterior conserva un plazo confirmado de 60 días.

Asigna a las excepciones temporales una fecha de caducidad o una condición que obligue a revisarlas. Vigila cuánto tiempo llevan abiertos los casos sin resolver y por qué el personal utiliza el circuito de revisión. Las excepciones repetidas pueden indicar que una regla necesita reconsiderarse. Deben llegar a su responsable mediante una solicitud de cambio visible.

Nuestra guía de una wiki empresarial preparada para IA explica cómo mantener el conocimiento aprobado. La guía de la fase de discovery aborda el trabajo más amplio de convertir un problema de producto en un alcance acordado.

Para evaluar si la programación con IA ayuda en este proceso, mide el tiempo a la espera de decisiones y el trabajo que hay que rehacer al aclarar reglas, además del tiempo de implementación. Si el código avanza más deprisa pero las aprobaciones siguen pendientes, el cuello de botella de la entrega seguirá a la vista.

Empieza con una decisión sobre la que haya desacuerdo. Reúne las evidencias contradictorias, elige al responsable autorizado y revisad juntos los casos límite. Así el equipo tendrá algo preciso que implementar y motivos para confiar en ello.

Preguntas frecuentes sobre reglas de negocio contradictorias