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

Un lanzamiento de IA es la configuración completa que determina el comportamiento servido, no sólo el nombre del modelo ni el texto del prompt. Si el equipo revierte el modelo pero deja activos un permiso, un esquema de herramienta, una regla de recuperación o una ruta de reintento recién modificados, no restauró lo que había probado. La operación necesita una identidad única para saber qué candidato se evaluó, qué atendió cada solicitud y qué conjunto compatible debe recuperar el tráfico.

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

Debe contar como un lanzamiento el conjunto de dependencias que puede modificar la respuesta, la autoridad del sistema, el riesgo, el costo, la latencia o la observabilidad. El modelo es una pieza de esa unidad. Las guías de NIST tratan el ciclo de vida y sus actores como interdependientes, mientras Google Cloud describe sistemas de producción que incluyen configuración, verificación, metadatos, infraestructura y monitoreo además del código del modelo.

• Prompt y variables resueltas; modelo fijado y parámetros efectivos de inferencia.
• Esquemas de herramientas, permisos, políticas, barreras y reglas de aprobación.
• Recuperación, fuentes de contexto, lógica del flujo, esquemas de entrada y salida y dependencias de ejecución.
• Enlaces de entorno que alteran el enrutamiento, las conexiones autorizadas o el contexto disponible.

Los conjuntos de evaluación, evaluadores, rúbricas y umbrales también necesitan versión, aunque normalmente no participen en la ruta que atiende solicitudes. Son activos de aseguramiento: cambian la evidencia con la que se autoriza el candidato. Conviene incluir una dependencia propia o de terceros sólo cuando pueda afectar materialmente el servicio o la decisión de lanzamiento. Esa frontera se documenta por sistema; ampliar el inventario sin criterio sólo vuelve opaco el control.

Cada modificación material del prompt, la instantánea del proveedor, un parámetro efectivo, una herramienta, un permiso, una política, el contexto recuperado, el flujo, un esquema, una dependencia o un enlace de entorno genera otro candidato. Los historiales individuales siguen siendo útiles para desarrollar y diagnosticar, pero la identidad integral evita reconstruir a contrarreloj una combinación dispersa cuando aparece una falla.

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

Se une congelando un manifiesto inmutable con una identidad del lanzamiento y referencias estables para cada componente. Debe registrar fecha de creación, responsable, servicio objetivo, estado, condiciones de paro, responsable de reversión y versión anterior conocida como buena. Para cada pieza se guarda la versión, confirmación, digest, huella de contenido o referencia equivalente, además de los parámetros efectivos. Un alias como “producción” o “más reciente” sólo es un apuntador mutable.

El manifiesto también identifica conexiones aprobadas, referencia de datos o recuperación, bandera de función y restricciones de enrutamiento, sin almacenar secretos. La asignación de tráfico y las horas de despliegue pertenecen a eventos de promoción vinculados, porque cambian conforme avanza la exposición. Aumentar una asignación ya autorizada puede conservar el candidato; modificar una ruta o enlace que cambie el comportamiento, la autoridad o el contexto por solicitud exige una identidad nueva.

• Candidato support-assistant-r18: prompt p-42 e instantánea m-2026-07 con temperatura 0.2 y límite de salida resuelto.
• Contrato t-9 para crear tareas en CRM, política policy-12 con aprobación humana, flujo wf-a71 y esquema reply-6.
• Bloqueo de dependencias de ejecución, servicio objetivo, bandera, conexiones aprobadas y reglas de enrutamiento.
• Paquete de evidencia separado: conjunto eval-23, versiones de evaluadores, resultados, aprobación y observaciones del despliegue.

En este ejemplo, la intención es mejorar la escalación de tickets sin contexto de cuenta y conservar la aprobación antes de crear una tarea. support-assistant-r17 sólo puede nombrarse como objetivo de reversión después de comprobar que tolera los campos opcionales de fecha límite y motivo de escalación. La identidad fija no promete resultados idénticos: conserva la configuración efectiva y hace rastreable la decisión, incluso cuando el servicio hospedado o el muestreo introducen variación.

Si algo cambia el comportamiento servido o la evidencia que lo autoriza, necesita una identidad resuelta en el registro.

¿Qué evidencia decide si el candidato puede avanzar?

El candidato avanza sólo cuando la evidencia del paquete exacto satisface las compuertas aplicables y una persona responsable registra promover, pausar o rechazar. Las notas deben explicar la intención de comportamiento, cada dependencia modificada, escenarios e interfaces afectados, cambios de permisos u observabilidad, limitaciones conocidas, riesgo residual, plan de promoción y objetivo compatible de reversión. Así, la aprobación responde a una decisión operativa y no a una lista de archivos cambiados.

Las pruebas deben comparar el candidato completo con la versión vigente. Incluyen contratos, tarea específica, escalaciones esperadas, autoridad de herramientas, confiabilidad, latencia y costo cuando sean relevantes. También revisan segmentos importantes y casos poco frecuentes pero costosos. Una media favorable no compensa una ruptura material de contrato, un permiso indebido o una regresión concentrada. Los evaluadores automáticos ayudan, pero requieren auditoría y participación de especialistas del flujo.

El conjunto de casos, las rúbricas, los evaluadores y los umbrales se conservan con versión propia. Cambiar una compuerta puede cambiar la interpretación del mismo resultado, aun si el candidato no se tocó. Para lanzamientos de mayor riesgo, la persona que preparó el cambio puede ser distinta de quien autoriza la promoción. En equipos pequeños los roles pueden coincidir, pero la evidencia, la decisión, la excepción y su responsable deben quedar explícitos.

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

El mismo candidato resuelto debe avanzar por etapas medidas: repetición en sombra o sin acciones, grupo interno, cohorte canario estable, exposición ampliada y tráfico completo. En una repetición de solicitudes reales se deshabilitan o aíslan las herramientas de escritura y otros efectos importantes; reproducir ciegamente una acción de producción puede duplicarla. La evidencia fuera de línea y la sombra revelan fallas útiles, pero no representan todas las condiciones ni todos los casos raros del servicio activo.

1. Ejecutar tickets representativos contra r18 con escrituras bloqueadas y comparar sus trazas con r17.
2. Habilitar el candidato para operaciones internas, manteniendo la aprobación en cada acción externa.
3. Asignar una cohorte de producción estable y comparar señales de tarea, seguridad, herramientas, confiabilidad, latencia y costo.
4. Ampliar la exposición sólo después de cumplir la observación y la muestra definidas por el servicio.
5. Pasar a tráfico completo, conservar r17 durante la ventana aprobada y mantener monitoreo etiquetado por versión.

Las reglas de cohorte, asignación de tráfico, inicio y fin de observación y disposición se registran como eventos vinculados al manifiesto; no se reescribe el candidato. Los porcentajes, tamaños de muestra y periodos dependen del riesgo, volumen, demora para detectar fallas y capacidad operativa. Si durante la promoción cambia el prompt, un parámetro, herramienta, permiso, política, recuperación, flujo, esquema, dependencia o enlace de entorno, el equipo detiene la escalera y evalúa una identidad nueva.

¿Cuándo debe detenerse el lanzamiento y qué restaura la reversión?

El lanzamiento debe detenerse ante una violación material de seguridad o política, una acción sin autoridad, una ruptura de contrato o una falla grave de confiabilidad; las demás regresiones usan límites definidos para el servicio. Las condiciones, la severidad y quien decide se acuerdan antes de exponer tráfico. Un indicio ambiguo puede justificar una pausa para investigar en vez de una reversión automática, pero no debe quedar sin disposición, responsable ni plazo operativo.

La reversión restaura el tráfico hacia el conjunto completo conocido como bueno y compatible, no hacia una sola pieza anterior. Antes del lanzamiento se ensaya esa restauración y se comprueban esquemas, cambios de estado, migraciones, contratos de herramientas, rutas y disponibilidad del proveedor. En el asistente, volver de r18 a r17 requiere confirmar que los campos opcionales nuevos no rompan consumidores ni dejen solicitudes en un estado que la lógica anterior no pueda procesar.

• Registrar el disparador, la primera observación, versión, cohorte, rutas afectadas y solicitudes relacionadas.
• Validar la compatibilidad del objetivo conocido y restaurar el tráfico con verificaciones posteriores.
• Aislar la ruta de acciones externas si existe riesgo de nuevas escrituras o aprobaciones incorrectas.
• Usar identificadores de trazas y acciones para reconciliar, corregir, notificar o compensar mediante un procedimiento autorizado.

Cambiar la configuración controla solicitudes futuras; no borra mensajes, revierte escrituras, cancela aprobaciones ni elimina tareas ya creadas en sistemas externos. Por eso el registro de reversión separa el restablecimiento del tráfico de la remediación. En el caso del CRM, operaciones puede deshabilitar la ruta, localizar identificadores de tareas mediante trazas y aplicar el procedimiento de corrección autorizado. La acción apropiada depende del sistema y de las facultades de la organización.

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

El registro debe permitir reconstruir la configuración efectiva, la evidencia observada y la razón de la decisión. Incluye manifiesto inmutable, identificadores y parámetros resueltos, enlaces de entorno, hallazgos de compatibilidad, versiones y resultados de evaluaciones, aprobaciones, eventos de despliegue, reglas de cohorte, asignaciones, trazas, hallazgos, reversiones y disposición final. Google Cloud recomienda conservar versiones, ejecutores, parámetros, artefactos, resultados y un apuntador al objetivo anterior como parte del linaje operativo.

El identificador del lanzamiento debe acompañar cada traza para atribuir generaciones, llamadas a herramientas, transferencias, barreras, tiempos y resultados a la configuración que atendió la solicitud. Cuando existan, también conviene registrar el identificador de solicitud del proveedor y el de la aplicación para investigar entre fronteras técnicas. La captura no necesita incluir cada prompt, entrada de herramienta, salida del modelo o dato de cliente: los datos sensibles siguen las políticas internas de acceso y retención.

Este resultado ofrece reproducibilidad de configuración y de decisión, no repetición exacta de la salida. Las instantáneas fijadas, parámetros archivados y trazas reducen ambigüedad, pero un modelo estocástico o un proveedor hospedado puede producir otra respuesta. El paquete mínimo es el que todavía identifica al candidato, su evidencia versionada, las decisiones de promoción y el objetivo compatible. Cambios en datos sensibles, permisos relevantes o flujos regulados requieren la revisión de las áreas profesionales correspondientes.