La regla que cambia cada semana no debería estar en el código

Por qué la regla que cambia cada semana no pertenece al código#

Una regla de negocio es un dato, no código. Cualquier pedido de cambio que exija un despliegue para cambiar un número, un plazo, un límite o un criterio de aprobación es el síntoma de una decisión de arquitectura que se tomó mal antes, cuando alguien escribió como constante lo que el negocio trata como registro.

La pregunta aparece en toda reunión de descubrimiento, y siempre con las mismas palabras: "¿y cuando cambie la regla, voy a depender de ustedes?". La respuesta honesta no es sí ni no. Es: depende de dónde se puso la regla, y eso se decide antes de la primera línea.

La genómica lo deja más nítido. Cuando construimos SheepGen para DNA Genética do Brasil, la plataforma de evaluación genómica de ovinos, el cliente describió su propio trabajo así: sale una investigación nueva, él crea un campo nuevo, recalcula y entrega otra vez. No era un pedido de función futura. Era la premisa de su negocio. Con cada publicación científica, un marcador genético gana dirección y empieza a puntuar. Cualquier sistema con esa regla escrita en el código nacería desactualizado, y envejecería más rápido de lo que el equipo logra desplegar.

Qué se convierte en parámetro y qué sigue siendo código#

El criterio no es gusto de ingeniero ni preferencia del cliente. Son tres preguntas sobre la regla, y las respuestas empujan hacia lados opuestos.

Tres sí y la regla pertenece al registro. Tres no y pertenece al código, e insistir en parametrizar solo traslada la complejidad a un lugar donde no existen pruebas.

La línea suele pasar dentro de la misma fórmula, y ahí la decisión se vuelve concreta:

Mira la última fila. En una plataforma multiinquilino que definimos, la zona horaria quedó fija y la personalización visual quedó en unos doce temas cerrados, en lugar de un campo de color libre. Fue una decisión consciente: cada opción abierta es un estado más para probar, y un estado más para que alguien configure mal.

Cómo la regla se volvió dato en un dominio que cambia cada mes#

En SheepGen, la decisión estructural fue tratar la interpretación genética como catálogo, no como algoritmo. El equipo de DNA Genética registra el marcador y, para cada combinación de genotipo y raza, define el compuesto, la puntuación y la clasificación. Quien mantiene el cerebro del sistema es el genetista, no el programador.

Lo que sorprende es el tamaño: ningún marcador vale solo, porque es la relación entre ellos, dentro del compuesto y de la raza, la que produce la nota. Por eso el catálogo tiene 76 marcadores y 1.103 reglas, y no 76 respuestas. El mismo SNP puntúa distinto en razas distintas, y un marcador tiene su propio ciclo de vida (activo, esperando dirección, bloqueado), porque así funciona la ciencia.

La segunda decisión fue separar el dato bruto del cálculo. El archivo del laboratorio, 4,3 GB y 59 millones de líneas, sube directo al almacenamiento y se lee en streaming; cada lectura útil se guarda como dato del animal, independiente de cualquier puntuación. La consecuencia es lo que el cliente pidió sin usar el nombre técnico: el recálculo se volvió un botón. Y cuando un marcador se registra después de la importación, el sistema relee el archivo que ya está guardado y graba solo lo que faltaba, sin pedirle nada nuevo al laboratorio.

Eso se probó en vivo, en el ambiente real: registramos un marcador nuevo, el sistema releyó los 4,3 GB, grabó las 734 lecturas que faltaban y recalculó los 735 informes en 4 minutos. Después de la prueba, el marcador de test salió y el recálculo devolvió el número validado. La cuenta cierra en los dos sentidos.

El mismo patrón sostiene el sistema de genética bovina que construimos para DNA Genética, la plataforma DGA Intelligence: cada campo declara su propia naturaleza (genotípico, fenotípico o morfométrico), y de ahí se deduce si puntúa y si convierte hacia otro campo. En la migración del sistema heredado al nuevo fueron 32 campos con regla de normalización y factorización por raza y sexo, más 12 modelos genéticos, todos cargados como dato. La granularidad en sí es decisión de código: la conversión es por raza, la normalización es por raza y sexo. Los valores dentro de ella son registro.

Cuando la regla vive en la cabeza de las personas#

El caso más didáctico de parametrización no viene de un dominio científico. Viene del crédito.

En Ideal Veículos, una red de 11 tiendas, el trabajo de financiación en el punto de venta consiste en encontrar, entre decenas de financieras, quién aprueba a ese cliente para ese vehículo y en qué condiciones. Sostiene una parte relevante de la facturación de la concesionaria, y su regla no estaba en ningún lado: vivía en la cabeza de quien tenía experiencia. Conocimiento tácito, mal documentado, que se perdía con la rotación natural de un equipo comercial.

El giro fue registrar esa regla. Cada una de las 19 financieras pasó a tener sus propios criterios en la plataforma (qué vehículo financia, año mínimo, si acepta subasta, si exige licencia de conducir), y el sistema empezó a recomendar las financieras correctas para cada cliente y vehículo, con ranking por financiera. Lo que era memoria de un profesional veterano se volvió sugerencia del sistema.

El efecto de volumen llega después, y es lo que prueba que aguantó operación real: en 13 meses en el aire, 11.364 financiaciones y 51.595 propuestas registradas, con 10.494 clientes en el historial. Antes, solo la propuesta final entraba en la hoja de cálculo; ahora cada intento queda registrado. Eso es lo que compra una pantalla de configuración y no compra un algoritmo escondido: la regla sobrevive a la salida de la persona que la conocía.

Dónde la IA no entra#

Parametrizar reglas y generar texto con IA parecen vecinos, y son cosas opuestas. La frontera se ve en Sistema Cuidar, la plataforma de diagnóstico de riesgo psicosocial que construimos para la norma brasileña NR-1.

El informe tiene 15 secciones. Las institucionales (portada, presentación, introducción, objetivo, metodología, caracterización de la muestra, dimensiones evaluadas) vienen de una plantilla versionada. La matriz de riesgo de 13 factores se renderiza directo del dato extraído, sin IA alguna: es aritmética y regla, auditable línea por línea. Solo entonces entra la IA, para escribir 5 secciones que exigen interpretación técnica, en cinco llamadas independientes y paralelas, cada una regenerable por separado. El texto cae en un editor donde la responsable técnica revisa antes de exportar.

La regla que define el producto es esta: la IA escribe y no calcula. Es lo que hace el documento firmable, porque ningún número del informe salió de un modelo de lenguaje. El mismo principio vale cuando la IA entra como interfaz: en la capa de IA que modelamos para DGA Intelligence, un servidor MCP que expone el sistema como herramientas conversables, el alcance dice que la IA no calcula genética, sino que acciona el motor determinista que ya existe por la misma API de las pantallas, heredando límites, permisos y auditoría. Vale registrar que esa capa está modelada y presupuestada, no entregada.

El precio de parametrizar de más#

Esta es la parte que casi nadie escribe, y es la que separa la parametrización de una trampa carísima.

Un sistema que parametriza todo se convierte en un lenguaje de programación malo dentro de un formulario de administración. Tiene condicionales, tiene precedencia entre reglas, tiene efecto combinado, y no tiene nada de lo que tiene un lenguaje de verdad: sintaxis verificable, pruebas automatizadas, revisión de código, historial legible de cambios. Escribiendo sobre motores de reglas en 2009, Martin Fowler ya señalaba que el problema no es la regla aislada, que siempre parece sensata: es que un cambio pequeño en un lugar produce consecuencias no intencionadas en muchos otros, porque el flujo del programa queda implícito.

El síntoma práctico es siempre el mismo. Un error de configuración no produce un error visible. Produce un número plausible.

Lo vivimos en la conversión del catálogo genético. Un marcador tenía la nomenclatura de alelo decidida línea por línea, y en esa forma un genotipo coincidía por una convención y el otro por otra distinta: medio marcador correcto, sin ningún mensaje de error. El sistema habría emitido un informe con una nota equivocada y con cara de correcta. La corrección fue sacar la decisión del dato y pasarla a una regla por marcador, y el marcador problemático entró bloqueado hasta que alguien decidiera su convención. Dos lecciones: parte de la configuración pertenece al código, y la configuración que no se puede verificar no debería existir.

Y hay el costo silencioso del volumen. Las 1.103 reglas del catálogo existen en una hoja verificable línea por línea, cada línea con su procedencia. Aun así, durante semanas, la revisión humana completa de esas 1.103 líneas fue un pendiente abierto, no una tarea hecha. Un registro grande traslada trabajo; no elimina trabajo. Quien promete "es solo configurar" está describiendo la parte fácil.

Entonces la regla para abrir un campo de configuración es económica: cada campo tiene que pagarse en cambios reales que el equipo del cliente hizo solo. Un campo que nadie tocó en un año costó pantalla, pruebas, documentación y riesgo, y no devolvió nada.

Cómo se verifica que la regla parametrizada está correcta#

Parametrizar sin forma de verificar es peor que dejar la regla en el código, porque la regla equivocada no avisa. En un documento que orienta una decisión de reproducción, de crédito o de salud ocupacional, un número errado con cara de correcto es el peor defecto posible.

La técnica que resiste es comparar el sistema con un camino de cálculo independiente, sobre los mismos datos. En SheepGen el motor de puntuación no solo se probó: se verificó contra un verificador escrito aparte a propósito, corriendo fuera del sistema. Los dos tenían que llegar al mismo informe, animal por animal, compuesto por compuesto. Resultado en la primera carga real: cero divergencias en 55.050 lecturas de 735 animales. Y esa igualdad quedó protegida por una prueba automatizada, así que cualquier cambio en el motor que se separe del verificador rompe la suite antes de llegar a producción.

Verificar contra el origen también atrapa lo que vino mal de fuera: cuando 71 animales salieron con un compuesto en cero, la revalidación contra los archivos originales encontró una clasificación cambiada en la hoja de origen, marcadores registrados en el compuesto equivocado. Corregida con el cliente, la suma de cada animal no se movió un punto, porque era reclasificación, y el compuesto en cero bajó de 71 animales a 2, los 2 correctos.

El mismo método vale cuando existe un sistema viejo para comparar. En la sustitución del sistema heredado de DNA Genética, armamos un paquete de homologación con dato real convertido (54 toros, 200 hembras, 32 campos y 12 modelos genéticos) para correr los dos motores sobre los mismos insumos. El sistema que se va a apagar es el mejor oráculo disponible, es gratis, y existe una sola vez.

Tres formas de verificación, en orden de costo:

Quién toca el parámetro después, y qué queda registrado#

Una regla que se volvió dato ahora es editable por alguien que no es programador. Eso es el objetivo, y también un vector de incidente nuevo: quién puede cambiarla, qué afecta el cambio y cómo se descubre después qué se cambió.

El mínimo que un sistema parametrizado tiene que cargar:

• La versión del conjunto de reglas en cada resultado. En SheepGen, cada análisis guarda la revisión del catálogo y la fecha del cálculo, y el informe en PDF imprime las dos: un contador sube con cada escritura en un marcador o una regla. Dos informes del mismo animal, de épocas distintas, nunca se confunden, y la pregunta "¿bajo qué regla salió este número?" tiene respuesta.
• Permiso por rol en el parámetro, no solo en la pantalla. Quien opera consulta; quien responde por la regla edita.
• Confirmación explícita para toda acción que graba. En el alcance de la capa de IA de DGA Intelligence, cada herramienta que graba o dispara un lote exige confirmación del usuario.
• Recálculo explícito, nunca silencioso. Cambiar la regla y recalcular son dos actos. El recálculo automático sobre un documento ya emitido es como se pierde la trazabilidad.

Vale la honestidad sobre el escalón que falta: registrar la revisión del conjunto de reglas responde "qué regla produjo este número", que es la pregunta que importa para verificar la cuenta. Registrar quién cambió la regla y qué cambió exactamente es una capa más, un rastro por usuario, y no es automática. Un sistema que abre la configuración al cliente y no construye ese rastro está cambiando dependencia de despliegue por ausencia de rastro.

Preguntas frecuentes#

¿Cuando cambie la regla de mi negocio, voy a depender de ustedes?#

Depende de dónde se puso la regla, y eso se decide en el proyecto, no después. Una regla que cambia por una publicación científica, una norma nueva o una negociación comercial tiene que nacer como un registro que mantiene tu propio equipo. En SheepGen, el catálogo de interpretación genética tiene 1.103 reglas registradas por el equipo del cliente, y un marcador nuevo recalcula los 735 informes del rebaño en 4 minutos. La regla que cambia una vez al año, o que nadie fuera del equipo técnico sabe responder, se queda en el código a propósito: convertirla en pantalla de configuración costaría más de lo que ahorra.

¿Cuál es el criterio para decidir si algo se vuelve parámetro o sigue en el código?#

Tres preguntas resuelven casi todos los casos. Quién sabe la respuesta correcta: si es quien opera y no quien programa, la regla tiende a la base de datos. Con qué frecuencia cambia sin avisar: si cambia por un evento externo, gana la base. Y si la regla cabe en un formulario cerrado: si la forma es estable y solo varían los valores, es parámetro; si cada caso tiene una forma distinta, es código. Cuando las tres respuestas son sí, parametrizar ahorra despliegues; cuando son no, parametrizar solo traslada la complejidad a un lugar sin pruebas.

¿Parametrizar de más es un problema real?#

Es el error más caro de esta familia, y casi nadie escribe sobre él. Un sistema con todo configurable se convierte en un lenguaje de programación malo dentro de un formulario de administración: nadie entiende el efecto combinado de las opciones, nada de eso está cubierto por pruebas, y un error de configuración produce un número plausible en lugar de un error visible. Martin Fowler ya advertía en 2009 que la facilidad de cambiar una regla aislada es justamente lo que hace impredecibles las consecuencias. En la práctica, cada campo configurable tiene que pagarse en cambios reales que el equipo del cliente hizo solo.

¿Cómo sé que la regla que registré está correcta?#

Solo hay una forma que resiste: comparar el resultado del sistema con un camino de cálculo independiente, sobre los mismos datos. En SheepGen escribimos el motor de producción y un verificador aparte, fuera del sistema, y los dos tenían que llegar al mismo informe animal por animal. En la primera carga real dieron cero divergencias en 55.050 lecturas, y esa igualdad quedó protegida por una prueba automatizada: cualquier cambio en el motor que se separe del verificador rompe la suite. Parametrizar sin esa verificación es peor que dejar la regla en el código, porque la regla equivocada no avisa.

¿La IA puede encargarse de la regla de negocio en lugar del parámetro?#

No para calcular. En Sistema Cuidar la IA escribe 5 de las 15 secciones del informe, y la matriz de riesgo de 13 factores se calcula del dato, sin IA alguna: es aritmética y regla, auditable línea por línea. Esa separación es lo que hace el documento firmable por una responsable técnica, porque ningún número del informe salió de un modelo de lenguaje. La IA es una buena capa de conversación encima de un motor determinista, y una pésima sustituta de él.

Fuentes#

• Martin Fowler, Rules Engine (2009): https://martinfowler.com/bliki/RulesEngine.html

Próximo paso#

Si tu operación tiene una regla que cambia más rápido de lo que cualquier proveedor logra desplegar, el lugar para decidir eso es el proyecto, no el contrato de mantenimiento. Mira cómo quedó en el caso SheepGen, donde el equipo del cliente mantiene 1.103 reglas de interpretación genética sin programador en el camino, y en el caso Ideal Veículos, donde la regla de crédito salió de la cabeza de las personas y se volvió registro. Es el tipo de decisión que tratamos en software a medida, y la frontera con la IA está en el caso Sistema Cuidar y en automatización con IA.