Cómo versionar prompts, modelos y lógica de flujo como un único release de IA

El release de una aplicación de IA es la configuración completa que determina su comportamiento, no solamente el prompt ni el endpoint del modelo. Si un equipo revierte el modelo pero deja activo un prompt nuevo, un permiso ampliado o una ruta de reintento distinta, no volvió realmente a la versión anterior. Sin una identidad común resulta difícil demostrar qué se evaluó, qué configuración atendió una solicitud problemática y qué conjunto compatible debe recuperar el tráfico.

¿Qué debe contar como un único release de IA?

Debe contar como un único release el conjunto de dependencias que puede modificar lo que el servicio hace, qué autoridad ejerce o cómo se lo observa. La frontera exacta depende del sistema, pero normalmente incluye el prompt, el identificador resuelto del modelo, los parámetros de inferencia, los contratos de herramientas, sus permisos, las políticas, la recuperación de contexto, el código del flujo, los esquemas y las dependencias de ejecución. Google Cloud remarca que un sistema de ML productivo comprende mucho más que el código del modelo, y NIST propone inventariar componentes interdependientes, incluidos los relevantes de terceros.

También conviene distinguir entre la configuración que atiende solicitudes y los activos que autorizan su promoción. Los conjuntos de evaluación, evaluadores, rúbricas y umbrales no suelen ejecutarse en el camino productivo, pero una modificación en ellos puede cambiar la interpretación del mismo resultado. Por eso necesitan versiones vinculadas al release. La regla práctica es incluir una dependencia cuando pueda afectar materialmente el servicio o la decisión de desplegarlo, sin convertir el manifiesto en un inventario indiscriminado de toda la plataforma.

• Runtime: prompt, snapshot del modelo, parámetros, herramientas, permisos, políticas, contexto, lógica, esquemas y dependencias.
• Bindings: conexiones aprobadas, reglas de enrutamiento, identidad de flags y referencias de datos, sin guardar secretos.
• Evidencia: datasets, evaluadores, rúbricas, umbrales, resultados, revisiones y limitaciones conocidas.
• Identidad: cualquier cambio que altere comportamiento, autoridad o contexto origina un candidato nuevo.

¿Cómo se une toda la configuración en un manifiesto de release?

La configuración se une congelando un manifiesto inmutable con un identificador de release y referencias estables para cada componente. Debe registrar fecha de creación, responsable, servicio objetivo, estado, condiciones de detención, responsable del rollback y versión conocida anterior. Para cada pieza se guarda la versión resuelta, el commit, el digest del artefacto, el hash del contenido u otra referencia estable, junto con los ajustes efectivos. Un alias como production o latest es apenas un puntero mutable y no identifica por sí solo aquello que se probó.

El criterio se vuelve concreto con un asistente interno que resume tickets, propone respuestas y crea tareas en el CRM únicamente después de la aprobación de un agente. El candidato support-assistant-r18 vincula el prompt p-42, el snapshot m-2026-07, temperatura 0,2 y límite de salida, el esquema de herramienta t-9, la política policy-12, el commit wf-a71, el esquema reply-6 y el lock de dependencias. Su paquete enlaza por separado eval-23 y las versiones de sus evaluadores, además de la comparación con support-assistant-r17.

• Guardar las conexiones, restricciones de enrutamiento, referencias de datos y flags capaces de cambiar el tratamiento de una solicitud.
• Mantener secretos fuera del manifiesto; registrar solamente la identidad de la conexión o referencia aprobada.
• Anotar compatibilidad, migraciones y campos opcionales antes de designar a support-assistant-r17 como objetivo de rollback.
• Registrar asignaciones de tráfico y horarios en eventos de promoción vinculados, sin mutar el candidato congelado.

Una ampliación preaprobada de exposición puede seguir siendo un evento del mismo candidato. En cambio, modificar durante el despliegue un prompt, parámetro, permiso, contrato, política, contexto, dependencia o binding que cambie el tratamiento por solicitud crea otro candidato. Esta separación permite conservar un historial claro: el manifiesto dice qué era r18; los eventos posteriores dicen dónde estuvo activo, durante cuánto tiempo, bajo qué cohorte y con qué decisión.

Si algo puede cambiar el comportamiento servido o la evidencia que lo autoriza, necesita una identidad resuelta en el registro del release.

¿Qué evidencia debe decidir si el candidato avanza?

Debe decidirlo evidencia vinculada al candidato exacto y a los riesgos concretos del flujo, seguida por una disposición explícita: promover, mantener en espera o rechazar. Las notas de release explican la intención conductual, cada dependencia modificada, los escenarios e interfaces afectados, los cambios de permisos u observabilidad, los resultados, las limitaciones, el riesgo residual, la persona responsable del despliegue y el objetivo compatible de rollback. Así, la aprobación responde a una modificación entendible y no a un puntaje aislado.

La suite debe comparar r18 con r17 sobre contratos, calidad de la tarea, escalamiento, segmentos importantes, casos infrecuentes pero costosos, uso de herramientas, autoridad, confiabilidad, latencia y costo. No corresponde compensar una regresión material de seguridad, permisos, contratos o un segmento crítico con una mejora del promedio. Los datasets, evaluadores, rúbricas y umbrales también se versionan, porque cambiar la puerta puede alterar el significado de los resultados aunque el candidato permanezca igual.

Las puertas pueden automatizar verificaciones, pero siempre deben conservar la evidencia, la decisión y el responsable. En releases de mayor riesgo, separar a quien preparó el cambio de quien autoriza la promoción reduce conflictos y deja una excepción auditable. En un equipo chico los roles pueden coincidir, aunque no debería desaparecer el registro de quién aceptó el riesgo residual y por qué.

¿Cómo debe avanzar el mismo candidato hasta producción?

El mismo candidato resuelto debe avanzar por etapas medidas, desde una prueba sin efectos hasta el tráfico completo. Cuando sea viable, el primer paso es ejecutar en sombra o reproducir entradas sin actuar: las herramientas de escritura y cualquier efecto relevante se deshabilitan o se aíslan. Reproducir ciegamente acciones productivas podría duplicar tareas o modificar sistemas externos. Después se habilita el candidato para un grupo interno, una cohorte productiva estable, una exposición ampliada y, finalmente, todo el tráfico.

1. Ejecutar tickets representativos en sombra con las herramientas de escritura desactivadas y comparar las trazas completas con r17.
2. Habilitar r18 para operaciones internas, manteniendo la aprobación humana de cada acción externa.
3. Asignar una cohorte productiva estable y comparar señales de tarea, seguridad, herramientas, confiabilidad, latencia y costo.
4. Ampliar solamente cuando se cumplan la observación y la muestra definidas para ese servicio.
5. Pasar al tráfico completo, conservar r17 como objetivo disponible y continuar el monitoreo etiquetado por release.

Cada evento debe registrar la regla de cohorte, la asignación de tráfico, el período observado y la decisión, siempre vinculados a r18. Los porcentajes, tamaños de muestra y ventanas se eligen según riesgo, volumen, demora de detección y capacidad de respuesta; no existen valores universales. Una cohorte estable mejora la comparación, pero ni el tráfico en sombra ni un canario representan todas las condiciones productivas o garantizan descubrir fallas raras. Si cambia la configuración durante la escalada, la evidencia anterior ya no corresponde al mismo candidato.

¿Cuándo debe detenerse el release y qué tiene que restaurar el rollback?

El release debe detenerse ante una infracción de seguridad o política, una acción de herramienta no autorizada, la ruptura de un contrato o una falla grave de confiabilidad; las demás regresiones requieren límites definidos para el servicio antes de exponer tráfico. Un hallazgo ambiguo puede justificar una pausa y una investigación en lugar de un rollback automático, pero la disposición y su responsable tienen que quedar registrados. Preacordar estos caminos evita negociar criterios bajo presión mientras el candidato sigue atendiendo solicitudes.

El rollback debe restaurar el conjunto completo conocido y compatible, no un componente aislado. Antes del despliegue hay que ensayar la restauración y verificar esquemas, estado, migraciones, disponibilidad del proveedor, contratos de herramientas, rutas y bindings. En el ejemplo, r17 solo sirve como objetivo si tolera los nuevos campos opcionales de fecha de vencimiento y motivo de escalamiento. La etiqueta «versión anterior» no alcanza cuando esa configuración ya no puede operar sobre el estado actual.

• Restaurar el tráfico futuro al manifiesto compatible y validar sus contratos y señales básicas.
• Aislar el camino de acción si hubo una llamada no autorizada o una escritura malformada.
• Usar trazas etiquetadas para identificar solicitudes, rutas e identificadores de acciones afectadas.
• Aplicar un runbook autorizado para contener, reconciliar, corregir, notificar, restaurar o compensar según corresponda.
• Registrar el disparador, los tiempos, la cohorte, la validación y la disposición final.

Revertir r18 no elimina tareas ya creadas, no retira mensajes enviados ni deshace aprobaciones o escrituras realizadas en otros sistemas. El rollback controla el enrutamiento siguiente; la remediación de efectos completados es otro procedimiento, con autoridad y evidencia propias. Cuando cambien el tratamiento de datos sensibles, permisos relevantes, flujos regulados o obligaciones de conservación, la organización debe involucrar a sus responsables calificados de seguridad, privacidad, asuntos legales, registros, riesgo o dominio.

¿Qué registro permite reconstruir un release de IA más adelante?

Un registro reconstruible debe unir el manifiesto inmutable, las versiones resueltas, los parámetros efectivos, los bindings del entorno, las conclusiones de compatibilidad, las evaluaciones, las aprobaciones y cada evento de promoción o rollback. También conserva asignaciones de tráfico, hallazgos, tiempos, responsables y disposición final. La identidad del release debe viajar en las trazas para atribuir generaciones, llamadas a herramientas, handoffs, guardrails, latencia y resultados a la configuración que realmente atendió cada solicitud.

Cuando estén disponibles, conviene guardar tanto el identificador de solicitud del proveedor como el identificador de traza de la aplicación. Esa conexión ayuda a investigar un síntoma a través de fronteras operativas. Sin embargo, trazabilidad no significa retener por defecto cada prompt, entrada de herramienta, salida del modelo o payload del cliente. Los identificadores, resultados y muestras gobernadas pueden conservar evidencia útil mientras el contenido sensible sigue las políticas internas de acceso y retención.

• Identidad y configuración: release, componentes, parámetros, bindings, restricciones y objetivo anterior.
• Evidencia y decisión: suites, evaluadores, rúbricas, resultados, aprobaciones, excepciones y riesgo residual.
• Despliegue: cohortes, tráfico, tiempos, observaciones, pausas, promociones y restauraciones.
• Operación: trazas, solicitudes, herramientas, hallazgos, acciones externas identificadas y disposición final.

El resultado es reproducibilidad de configuración y de decisión, no la promesa de repetir una salida idéntica. Un modelo estocástico o un servicio alojado puede variar aun con identificadores fijados y ajustes archivados. El paquete más chico que sigue siendo útil es aquel que identifica sin ambigüedad el candidato, la evidencia versionada que lo autorizó, las decisiones de exposición y el objetivo compatible de rollback. Si falta alguno de esos vínculos, la reconstrucción vuelve a depender de conjeturas.