Cómo versionar reglas de negocio para saber qué lógica tomó cada decisión automática

Una decisión automática pierde explicabilidad cuando la regla que la produjo cambia sin dejar rastro. Hoy un lead puede considerarse prioritario por una combinación de presupuesto, país y fecha; la próxima semana el equipo modifica un umbral y el mismo caso recibiría otro resultado. Si solo se conserva la decisión final, después será imposible saber si hubo un error o si simplemente se aplicó una política distinta. Versionar reglas de negocio significa identificar la lógica que estaba vigente cuando se tomó cada decisión y conservar suficiente contexto para reproducirla sin congelar para siempre el proceso.

La unidad que se versiona es la decisión, no necesariamente todo el sistema. Una regla puede ser “v3 de elegibilidad”, “v5 de descuento” o “v2 de prioridad comercial”. Cada versión necesita un identificador estable, fecha de entrada en vigor y una descripción breve del cambio. Separar reglas permite modificar una política sin declarar que toda la automatización cambió de versión. También evita mezclar conceptos: el formato de un payload puede seguir igual mientras la lógica que interpreta sus valores cambia. El registro debe señalar qué versión de regla consumió los datos y produjo el resultado.

Toda ejecución relevante debería guardar la versión aplicada junto con el resultado. Si un agente clasifica una solicitud, conviene registrar classification=alta y ruleVersion=priorityv4; si calcula una tarifa, priceRule=v7. Esto transforma una auditoría posterior. En lugar de preguntar “¿por qué el sistema hizo esto?”, el equipo puede localizar la regla exacta, los datos disponibles y la salida. No hace falta conservar una copia completa de código en cada registro; basta con una referencia estable a una definición que pueda recuperarse. La trazabilidad une decisión, versión y evidencia de entrada.

Los cambios necesitan una política de vigencia para evitar que dos versiones compitan sin intención. Una regla nueva puede entrar a partir de una fecha, aplicarse solo a nuevos casos o ejecutarse en paralelo durante una prueba. Es importante decidir qué ocurre con los casos ya abiertos. Algunos deben conservar la lógica con la que comenzaron; otros necesitan recalcularse. Esa decisión no debe quedar implícita. Una migración puede marcar qué registros fueron reevaluados, con qué versión anterior y nueva, y si el resultado cambió. Así se evita que una actualización silenciosa reescriba compromisos pasados.

Antes de activar una versión nueva conviene ejecutarla sobre ejemplos históricos sin modificar resultados reales. Ese modo de comparación permite observar qué decisiones cambiarían y revisar si las diferencias son deseadas. Se seleccionan casos representativos, se corre la regla vigente y la candidata, y se agrupan divergencias. El objetivo no es que ambas coincidan; precisamente se cambia una regla para producir resultados distintos. Lo importante es que el equipo pueda explicar esas diferencias antes de ponerlas en producción. Una regla nueva debería llegar con ejemplos que demuestren el comportamiento que se quiere introducir.

Retirar una regla antigua requiere saber quién todavía depende de ella. Si varios flujos llaman a la misma decisión, una versión puede permanecer activa porque un proceso legado aún la usa. Mantener un inventario de consumidores evita borrar lógica necesaria o sostener versiones indefinidamente por miedo. Se puede establecer una fecha de deprecación, medir llamadas restantes y migrar cada consumidor. Cuando el uso llega a cero, se archiva la versión pero se conserva su definición para auditoría histórica. El objetivo es reducir complejidad operativa sin perder la capacidad de explicar decisiones antiguas.

Versionar reglas convierte los cambios de criterio en eventos gobernables en lugar de ediciones invisibles. Una organización madura puede responder qué política está vigente, desde cuándo, qué cambió, qué decisiones se tomaron bajo versiones anteriores y qué pasaría si recalculara un caso. Esa capacidad resulta especialmente valiosa cuando agentes ejecutan políticas comerciales, financieras u operativas a gran escala. La lógica de negocio siempre evoluciona; el problema no es cambiarla, sino hacerlo sin poder distinguir después entre un error y una política nueva. La versión vuelve visible esa diferencia.