Si cambió el comportamiento, ¿qué cambió? Versionar prompts, políticas y evaluaciones

Un equipo despliega un agente que clasifica solicitudes entrantes. Durante seis semanas funciona bien. En la séptima, la calidad se degrada de forma perceptible: casos que antes se clasificaban correctamente ahora terminan en la categoría equivocada.

Empieza la investigación. ¿Cambió el modelo? Puede ser, el proveedor actualizó la versión. ¿Cambió el prompt? Alguien lo ajustó hace un par de semanas para mejorar otro caso. ¿Cambiaron los datos de entrada? Se agregó un canal nuevo. ¿Cambió la política de negocio? Se creó una categoría más.

Cuatro sospechosos, ninguna evidencia. La investigación termina en una reconstrucción por memoria de tres personas que recuerdan cosas distintas.

Este escenario es evitable con una práctica que la industria del software resolvió hace veinte años y que la adopción de IA está reintroduciendo desde cero: control de versiones.

Qué hay que versionar

La respuesta corta es: todo lo que determina el comportamiento del sistema. En un sistema con agentes eso es bastante más que el código.

Instrucciones y prompts. Son el equivalente funcional del código: determinan qué hace el sistema. Deberían vivir en el repositorio, con historial, revisión por pares y despliegue controlado. Un prompt editado directamente en una consola de administración es un cambio de producción sin traza.

Políticas. Los umbrales de escalamiento, las listas de herramientas permitidas, los límites de consumo, las reglas de aprobación. Si están en la cabeza de alguien o en la configuración de una interfaz, no se pueden auditar ni revertir.

Evaluaciones. El conjunto de casos con los que se mide si el sistema funciona. Este es el que más se descuida y el que más valor tiene: sin una versión de las evaluaciones, no puedes comparar el rendimiento de hoy con el de hace dos meses, porque no sabes si cambió el sistema o cambió la vara.

Versión de modelo y configuración. Qué modelo, qué parámetros, qué proveedor. Los proveedores actualizan modelos, a veces sin cambiar el identificador. Registrar qué versión se usó en cada ejecución es la diferencia entre poder explicar un cambio de comportamiento y no poder.

Contexto y fuentes. Qué documentos, qué base de conocimiento, con qué fecha de corte. Un agente que responde distinto porque alguien actualizó un documento interno no está fallando: está funcionando exactamente como se diseñó. Pero si eso no queda registrado, parece una falla.

El repositorio como fuente de verdad

La forma más simple de resolver esto no requiere herramientas nuevas: es tratar el repositorio de código como el sistema de registro de todo lo anterior.

Prompts en archivos versionados. Políticas en archivos de configuración versionados. Casos de evaluación en un directorio versionado. Cambios que pasan por el mismo flujo de revisión que el código. Despliegue que toma la versión del repositorio, no de una edición manual.

Esto tiene una consecuencia práctica inmediata: cualquier cambio de comportamiento se puede rastrear a un cambio registrado, con autor, fecha y motivo. La investigación del ejemplo inicial pasa de cuatro sospechosos sin evidencia a un historial que se lee en cinco minutos.

Tiene además una consecuencia menos evidente pero más profunda. Cuando el conocimiento sobre cómo opera el sistema vive en el repositorio, ese conocimiento es accesible para los propios agentes. Un agente que puede consultar el historial de cambios, las decisiones registradas y los casos de evaluación opera con contexto real. Un agente que no puede, opera con lo que le quepa en la conversación.

Evaluaciones: la pieza que convierte la opinión en dato

De los cinco elementos, el que más cambia la conversación organizacional es el conjunto de evaluaciones.

Un conjunto de evaluación es simplemente una colección de casos con resultado esperado. Entradas reales o representativas, y el criterio de qué constituye una respuesta correcta. Puede empezar con veinte casos escritos a mano en una tarde.

Lo que ese conjunto habilita es enorme:

Comparar dos versiones de un prompt con un número en vez de una impresión.
Detectar una regresión antes de que la detecte un cliente.
Decidir si vale la pena cambiar de modelo con evidencia sobre tu caso, no sobre un benchmark genérico.
Justificar ante un comité que un agente está listo para subir de nivel de autonomía.
Reconstruir, meses después, con qué criterio se aprobó algo.

Sin evaluaciones versionadas, cada una de esas cinco decisiones se toma por intuición. Con ellas, se toma con datos. El costo de construir el primer conjunto es de horas. El costo de no tenerlo se paga en cada discusión sobre si el sistema está funcionando bien.

Los tres errores frecuentes

Versionar el prompt pero no la evaluación. Se registra qué cambió pero no se puede medir si mejoró. Es media práctica y produce falsa confianza.

Casos de evaluación que solo cubren el camino feliz. Veinte casos que el sistema resuelve bien no miden nada. Los casos valiosos son los ambiguos, los del borde, los que históricamente causaron problemas. Un conjunto de evaluación útil debe fallar a veces.

Evaluar solo el resultado final. En un sistema con agentes, la traza importa tanto como la salida. Un agente que llega a la respuesta correcta invocando tres herramientas innecesarias y consultando datos que no debería tocar está fallando aunque el resultado sea bueno.

El registro mínimo por ejecución

Versionar los artefactos resuelve la mitad del problema: saber qué versiones existen. La otra mitad es saber cuál se usó en cada caso concreto.

Un registro por ejecución que permite investigar de verdad tiene siete campos, y ninguno es costoso de capturar si se decide desde el principio:

Identificador de ejecución. Para poder referirse a un caso específico sin ambigüedad.
Versión de instrucciones. Qué prompt exacto se usó, referenciado a su versión en el repositorio.
Modelo y configuración. Identificador del modelo, versión reportada por el proveedor y parámetros aplicados.
Fuentes de contexto. Qué documentos o consultas alimentaron la ejecución, con su fecha de última modificación.
Herramientas invocadas. Cuáles, con qué parámetros y con qué resultado.
Resultado y decisión humana. Qué produjo el sistema y qué hizo la persona con eso: aceptar, corregir, rechazar.
Costo y latencia. Para poder relacionar calidad con consumo.

El campo que más se omite y más valor tiene es el penúltimo. Registrar si la persona aceptó, corrigió o rechazó el resultado convierte cada uso en un dato de evaluación gratuito. Después de unos meses, esa serie permite responder preguntas que ningún conjunto de evaluación construido a mano responde igual de bien: en qué tipos de caso el sistema se equivoca más, si mejoró tras un cambio, qué proporción de sus salidas se usa sin modificar.

Hay una precaución necesaria. Este registro contiene, casi por definición, información de la organización y a veces datos personales. La decisión sobre cuánto tiempo se conserva, quién puede consultarlo y cómo se protege hay que tomarla antes de empezar a acumularlo, no cuando ya hay ocho meses de historial bajo condiciones que nadie definió.

Y una consecuencia práctica que conviene anticipar: la primera vez que una organización mira estos registros agregados, el hallazgo habitual es que una proporción considerable de las ejecuciones se corrige o se descarta. Ese número suele ser bastante peor que la percepción general sobre el sistema. No es una mala noticia: es la primera medición honesta, y es el punto de partida contra el que se van a comparar todas las mejoras posteriores.

Qué se puede hacer esta semana

Si tu organización tiene al menos un agente en operación, hay una secuencia corta y de bajo costo.

Primero, mueve los prompts que hoy viven en interfaces de administración a archivos en el repositorio. Segundo, escribe veinte casos de evaluación para el uso más importante, con el resultado esperado. Tercero, registra en cada ejecución qué versión de prompt, qué modelo y qué fuentes de contexto se usaron.

Con esos tres pasos, la próxima vez que alguien pregunte por qué el sistema se comporta distinto, la respuesta va a ser una fecha, un autor y un cambio concreto. No una conversación sobre lo que cada quien recuerda.