Cómo versionar prompts, modelos y lógica de flujo como un solo lanzamiento de IA

Un lanzamiento de IA no es únicamente el modelo ni el texto del prompt: es toda la configuración que puede cambiar la respuesta servida, las acciones permitidas, el costo, la latencia o la capacidad de observar lo ocurrido. Revertir solo el modelo puede dejar activos un prompt nuevo, otro contrato de herramientas, permisos distintos o una ruta de reintento defectuosa. Sin una identidad para el conjunto, resulta difícil demostrar qué se evaluó, qué configuración atendió una solicitud problemática y cuál versión compatible debería recuperar el tráfico.

¿Qué debe contar como un solo lanzamiento de IA?

Debe contar como un solo lanzamiento el conjunto de dependencias capaces de cambiar materialmente el servicio o la decisión de autorizarlo. El inventario normalmente abarca el prompt; el identificador resuelto del modelo y sus parámetros; los esquemas, permisos y conexiones de las herramientas; las políticas o barreras; la recuperación de información y el contexto; el código del flujo; los esquemas de entrada y salida; las dependencias de ejecución; y las vinculaciones del entorno que modifican la atención de cada solicitud.

• Configuración ejecutable: prompt, modelo fijado, parámetros efectivos, herramientas, permisos, políticas, contexto, flujo, esquemas y dependencias.
• Vinculaciones operativas: servicio de destino, reglas de enrutamiento, identidad de banderas, conexiones aprobadas y referencias de datos, sin guardar secretos en el manifiesto.
• Activos de aseguramiento: conjuntos de evaluación, evaluadores, rúbricas y criterios que no suelen atender solicitudes, pero sí cambian la decisión de promover.
• Dependencias externas: componentes de terceros únicamente cuando puedan alterar de forma material el comportamiento, la autoridad, el riesgo, el costo, la latencia o la observabilidad.

Los historiales de cada componente siguen siendo útiles, pero no deberían reconstruirse a contrarreloj durante una falla. Una modificación del prompt, la instantánea del proveedor, un parámetro efectivo, una política, un contrato de herramienta, el flujo, un esquema, la recuperación, una dependencia o una vinculación conductual crea otro candidato. El límite exacto depende del sistema: ampliar el inventario sin criterio produce ruido, mientras dejar por fuera una dependencia relevante rompe la trazabilidad.

¿Cómo se une la pila de comportamiento en un manifiesto?

La pila se une congelando un manifiesto inmutable con una identidad de lanzamiento y referencias resueltas para cada componente. Como mínimo, el documento registra fecha de creación, responsable, servicio objetivo, estado, condiciones de detención, dueño de la reversión y lanzamiento conocido anterior. Para cada pieza guarda una versión, commit, resumen de artefacto, huella de contenido u otra referencia estable, además de los ajustes efectivos. Un alias como “producción” o “más reciente” es apenas un puntero, no la identidad probada.

• Identidad y gobierno: ID del lanzamiento, responsable, estado, entorno, aprobación y propietario de la reversión.
• Componentes resueltos: versiones o huellas del prompt, modelo, parámetros, herramientas, permisos, políticas, contexto, flujo, esquemas y dependencias.
• Compatibilidad: migraciones, campos opcionales, contratos externos, rutas, banderas y disponibilidad requerida del proveedor.
• Evidencia enlazada: compilación, contratos, comparación con la versión vigente, limitaciones conocidas, decisiones y observaciones del despliegue.
• Recuperación: lanzamiento conocido anterior, resultado de la verificación de compatibilidad y procedimiento autorizado para efectos externos.

Considere un asistente interno que resume casos, propone respuestas y crea una tarea en el CRM solo después de la aprobación de un agente. El candidato support-assistant-r18 vincula el prompt p-42, la instantánea m-2026-07, temperatura 0,2 y el límite efectivo de salida; también el esquema t-9, la política policy-12, el commit wf-a71, el esquema reply-6 y el bloqueo de dependencias. Su paquete enlaza eval-23 y las versiones de evaluadores. support-assistant-r17 solo sirve como objetivo de reversión después de comprobar los nuevos campos opcionales de vencimiento y escalamiento.

La asignación de tráfico y las fechas de cada etapa pertenecen a registros de promoción enlazados; no se debe mutar el manifiesto para reflejarlas. Un aumento de exposición previamente aprobado puede conservar la identidad del candidato. En cambio, una modificación de enrutamiento, permisos, contexto o cualquier otra vinculación que cambie lo que ocurre por solicitud exige una identidad nueva y evidencia propia.

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

¿Qué evidencia decide si el candidato avanza?

El candidato avanza únicamente cuando la evidencia aplicable respalda una decisión explícita de promover, mantener en espera o rechazar. Las notas deben explicar 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, los responsables y el objetivo compatible de reversión. Así, quien aprueba revisa una decisión operativa y no una lista de commits sin contexto.

Las pruebas se ejecutan sobre la configuración completa que podría recibir tráfico. Incluyen, según el servicio, compilación e interfaces; calidad en tareas reales; casos poco frecuentes pero costosos; seguridad y autoridad; comportamiento de herramientas; confiabilidad, latencia y costo; y comparación con la versión vigente en segmentos importantes. Un promedio favorable no compensa una ruptura material de contrato, una acción no autorizada o una regresión grave en un segmento crítico.

También se versionan el conjunto de evaluación, los evaluadores, las rúbricas y los criterios: cambiar la compuerta puede alterar la interpretación aunque el candidato permanezca igual. Los evaluadores automáticos requieren auditoría y no eliminan el juicio de quienes conocen el proceso. En lanzamientos de mayor exposición, separar a quien prepara el cambio de quien autoriza su promoción añade una barrera útil; equipos pequeños pueden combinar roles, pero deben conservar evidencia, decisión, responsable y excepciones.

¿Cómo debe entrar a producción el mismo candidato?

El mismo candidato resuelto debe avanzar por una escalera de exposición medible, sin recibir cambios silenciosos entre etapas. Cuando sea viable, el recorrido comienza con sombra o repetición sin capacidad de actuar: las herramientas de escritura y otros efectos consecuentes se deshabilitan o se llevan a un entorno aislado. Reproducir ciegamente acciones de producción puede duplicar tareas, mensajes o cambios de estado, por lo que una sombra útil compara decisiones y trazas, no ejecuta nuevamente sus consecuencias.

1. Ejecutar casos representativos en sombra o repetición sin efectos y comparar recorridos con el lanzamiento vigente.
2. Habilitar el candidato para un grupo interno que pueda observar problemas y mantener las aprobaciones requeridas.
3. Asignar una cohorte de producción persistente y comparar señales de tarea, autoridad, herramientas, confiabilidad, latencia y costo.
4. Ampliar la exposición solo después de cumplir la evidencia y el periodo de observación definidos para el servicio.
5. Pasar a tráfico completo, conservar temporalmente el objetivo de reversión y continuar el seguimiento identificado por lanzamiento.

Cada evento de despliegue registra reglas de cohorte, asignación de tráfico, momento de inicio, observación y disposición. La persistencia de la cohorte evita que una misma persona salte entre configuraciones durante la comparación. Los porcentajes, muestras y ventanas no tienen valores universales: dependen del riesgo, el volumen, la velocidad con que aparece una señal y la capacidad de responder. Ni las pruebas fuera de línea, ni la sombra, ni un canario demuestran cobertura completa; una falla rara puede no aparecer en la muestra.

¿Cuándo se detiene el lanzamiento y qué debe restaurar la reversión?

El lanzamiento debe detenerse ante las condiciones duras acordadas antes de la exposición: incumplimientos de seguridad o política, comportamiento no autorizado de herramientas, ruptura de contratos o fallas graves de confiabilidad. Para calidad, latencia, costo y otras regresiones se usan límites propios del servicio, no cifras copiadas. Un hallazgo ambiguo puede justificar una pausa y una investigación en vez de reversión automática, pero la decisión, la evidencia y quien asume la siguiente acción deben quedar registrados.

La reversión restaura el tráfico hacia el paquete completo conocido y compatible, no hacia un modelo aislado. Antes de declarar válido el objetivo anterior hay que revisar esquemas, estados, migraciones, disponibilidad del proveedor, contratos de herramientas, recuperación y enrutamiento. El equipo debe ensayar esa restauración antes de necesitarla y validar después que el servicio volvió a la configuración esperada. Una etiqueta de “versión anterior” no basta si el entorno evolucionó y ya no acepta sus contratos.

Restaurar la configuración controla solicitudes futuras; no elimina mensajes enviados, no revierte escrituras, no cancela aprobaciones ni borra tareas creadas en sistemas externos. Para esos efectos se necesita un procedimiento autorizado separado. Las trazas identificadas por lanzamiento permiten ubicar solicitudes y acciones afectadas, deshabilitar la ruta correspondiente y entregar identificadores verificables al equipo responsable de contener, conciliar, corregir, notificar, restaurar o ejecutar una acción compensatoria.

• Registrar el disparador, la primera observación, el candidato, la cohorte y las rutas afectadas.
• Confirmar el paquete conocido, el resultado de compatibilidad y la hora de restauración del tráfico.
• Separar las acciones de contención o compensación de la reversión de configuración.
• Cerrar con validaciones, disposición final, responsable de seguimiento y ajustes a evaluación o monitoreo.

¿Qué registro permite reconstruir después un lanzamiento de IA?

Un registro reconstruible conserva el manifiesto inmutable, las referencias y parámetros resueltos, las vinculaciones del entorno, los hallazgos de compatibilidad, las versiones y resultados de evaluación, las aprobaciones, los eventos de despliegue, la exposición, las trazas, las observaciones, las reversiones y la disposición final. El identificador del lanzamiento debe viajar con cada traza para atribuir generaciones, llamadas a herramientas, transferencias, barreras, tiempos y resultados a la configuración que atendió la solicitud.

• Identidad del candidato, componentes efectivos, parámetros, entorno y objetivo anterior compatible.
• Versiones de datos de evaluación, evaluadores, rúbricas, criterios, resultados y responsables de decisión.
• Eventos de promoción con cohorte, exposición, tiempos, observaciones y decisión de cada etapa.
• Trazas e identificadores de solicitudes del proveedor y de la aplicación cuando estén disponibles.
• Hallazgos, reversiones, acciones externas afectadas y cierre operativo.

La trazabilidad no obliga a guardar cada prompt, entrada de herramienta, respuesta o carga de clientes. Es posible conservar identificadores, resultados y muestras gobernadas mientras el manejo de información sensible sigue las políticas de la organización. Los identificadores de solicitudes del proveedor y de la aplicación ayudan a investigar entre fronteras técnicas, pero deben quedar vinculados con el lanzamiento; aislados, muestran una transacción sin explicar qué configuración la produjo.

El resultado es reproducibilidad de configuración y de decisión, no la promesa de repetir byte por byte una salida. Una instantánea fijada, una huella y parámetros archivados reducen ambigüedad, pero los servicios alojados y los modelos estocásticos todavía pueden variar. El paquete mínimo debe identificar el candidato, su evidencia versionada, las decisiones de promoción y el objetivo de reversión. Si cambia el manejo de datos sensibles, permisos consecuentes, flujos regulados, retención o remediación externa, deben participar los profesionales calificados de seguridad, privacidad, asuntos legales, registros, riesgo o dominio que correspondan.