Versione 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 solamente el endpoint del modelo ni el texto del prompt. Revertir un modelo mientras permanecen activos un prompt nuevo, otro contrato de herramienta o una regla de permisos modificada no restaura el sistema anterior. Para saber qué se evaluó, qué atendió una solicitud problemática y qué debe recibir tráfico de nuevo, el equipo necesita una identidad única que vincule cada dependencia relevante, la evidencia de aprobación y el objetivo compatible de reversión.

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

Debe contar como un lanzamiento todo conjunto de dependencias capaz de cambiar la respuesta, la autoridad, el riesgo, el costo, la latencia o la observabilidad del servicio. NIST trata las actividades del ciclo de vida como interdependientes y pide inventarios y pruebas documentadas; Google Cloud también describe la producción de ML como un sistema que incluye configuración, pruebas, metadatos, infraestructura y monitoreo. El límite preciso es propio de cada servicio, pero el modelo aislado rara vez representa todo su comportamiento.

Conviene separar dos grupos vinculados. El primero es la configuración que se ejecuta al atender solicitudes. El segundo contiene los recursos de aseguramiento —datos de evaluación, evaluadores, rúbricas y criterios— que no suelen estar en la ruta de servicio, pero sí pueden cambiar la decisión de promover. Ambos necesitan versiones y linaje, aunque solo el primer grupo forme el candidato ejecutable que avanzará por los entornos.

• Prompt y formato efectivo de mensajes.
• Snapshot resuelto del modelo y parámetros de inferencia.
• Esquemas de herramientas, permisos, políticas y guardrails.
• Recuperación, contexto, rutas y enlaces del entorno que alteren la solicitud.
• Código del flujo, esquemas de entrada y salida y dependencias de ejecución.
• Versiones de datasets, evaluadores, rúbricas y criterios de aprobación.

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

Se vincula congelando un manifiesto inmutable con una identidad de lanzamiento y referencias estables para cada componente. Debe incluir hora de creación, propietario, servicio objetivo, estado, condiciones de detención, responsable de reversión y versión anterior conocida como buena. Para cada dependencia, guarde la versión resuelta, commit, digest, huella de contenido u otra referencia estable junto con los ajustes efectivos. Un alias como “producción” o “más reciente” es un puntero, no una identidad inmutable.

Considere support-assistant-r18, un asistente interno que resume tickets, propone respuestas y crea tareas en el CRM solo después de la aprobación de un agente. El manifiesto vincula el prompt p-42, el snapshot m-2026-07 con temperatura 0.2 y su límite efectivo de salida, la herramienta t-9, la política policy-12, el commit wf-a71, el esquema reply-6 y el bloqueo de dependencias. El paquete enlazado incorpora por separado eval-23, las versiones de evaluadores y sus resultados.

También deben registrarse las conexiones aprobadas, la referencia de datos o recuperación, la identidad de la feature flag y las restricciones de ruta, sin guardar secretos en el manifiesto. Los cambios planificados de asignación y las horas de despliegue pertenecen a eventos de promoción enlazados. Si cambia una ruta o un enlace que modifica el contexto, la autoridad o el comportamiento por solicitud, nace otro candidato. Antes de designar r17 como objetivo de reversión, compruebe su compatibilidad con los nuevos campos opcionales.

• Identidad, propietario, estado y servicio objetivo.
• Versiones resueltas, parámetros efectivos y huellas de artefactos.
• Enlaces del entorno, restricciones de ruta y compatibilidad conocida.
• Evidencia, aprobación, plan de promoción y condiciones de detención.
• Objetivo conocido como bueno, responsable de reversión y runbook para efectos externos.

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

¿Qué evidencia debe decidir si avanza el candidato?

Debe decidirlo evidencia obtenida del candidato completo, comparada con la versión vigente y evaluada contra contratos y riesgos materiales. Las notas de lanzamiento deben explicar la intención de comportamiento, dependencias modificadas, escenarios e interfaces afectados, cambios de permisos u observabilidad, limitaciones conocidas, riesgo residual, responsables y objetivo compatible de reversión. La suite debe identificar datasets, evaluadores, rúbricas y criterios exactos, porque modificar una compuerta cambia la interpretación del resultado aun cuando el candidato ejecutable sea idéntico.

No apruebe por un promedio único si existe una falla de contrato, autoridad, seguridad, herramienta, caso costoso o segmento importante. Las evaluaciones generales del proveedor tampoco sustituyen ejemplos del trabajo real ni la auditoría de evaluadores automáticos. Cada compuerta debe terminar en promover, pausar o rechazar, con propietario y evidencia registrados. En lanzamientos de mayor riesgo, la persona que autoriza la promoción puede ser distinta de quien preparó el cambio; plataformas de despliegue permiten aplicar esa separación.

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

El mismo candidato resuelto debe avanzar por una escalera de exposición medida, desde una repetición sin efectos hasta el tráfico completo. Cuando sea viable, comience con solicitudes representativas en modo sombra, desactivando o aislando las herramientas de escritura y cualquier otro efecto consecuente. Continúe con usuarios internos, una cohorte persistente de producción, una expansión controlada y, por último, todo el tráfico. Compare en cada etapa las señales acordadas de tarea, seguridad, herramientas, confiabilidad, latencia y costo con la versión vigente.

Registre las reglas de cohorte, la asignación de tráfico, el periodo observado y la disposición como eventos enlazados al lanzamiento. Un aumento de exposición previamente aprobado puede mantener la misma identidad; cambiar prompt, parámetros, herramientas, permisos, políticas, recuperación, flujo, esquema, dependencias o enlaces que afectan el comportamiento exige otro candidato. Los porcentajes, muestras y ventanas deben responder al riesgo, volumen, demora de detección y capacidad operativa. Ni el modo sombra ni un canario representan todos los casos o fallas raras.

1. Repita casos representativos sin ejecutar acciones externas.
2. Exponga el candidato al equipo interno y conserve todas las aprobaciones requeridas.
3. Asigne una cohorte persistente y compare señales con la versión vigente.
4. Amplíe solo después de cumplir la evidencia y observación preacordadas.
5. Pase a tráfico completo sin modificar el candidato durante la promoción.

¿Cuándo debe detenerse y qué tiene que restaurar la reversión?

El lanzamiento debe detenerse ante una infracción de seguridad o política, comportamiento no autorizado de una herramienta, una falla material de contrato o una falla grave de confiabilidad; otros retrocesos se rigen por límites específicos del servicio acordados antes de la exposición. Un hallazgo ambiguo puede justificar una pausa e investigación, en vez de una reversión automática, pero siempre necesita una disposición y un propietario explícitos. Esta regla evita improvisar cuando la presión operativa es mayor.

La reversión debe restaurar el paquete completo compatible conocido como bueno, no una pieza aislada. Ensaye esa restauración con anticipación y verifique esquemas, estado, migraciones, contratos de herramientas, rutas y disponibilidad del proveedor. En el ejemplo, r17 solo es un objetivo válido si acepta o ignora correctamente los campos opcionales añadidos por r18. Después de restaurar el tráfico, confirme que la versión esperada sirve solicitudes, que las verificaciones esenciales pasan y que las señales operativas se estabilizan.

Restaurar la configuración controla el enrutamiento futuro, pero no borra mensajes, revierte escrituras, cancela aprobaciones ni deshace tareas ya creadas en sistemas externos. Use trazas etiquetadas con el lanzamiento para identificar solicitudes, caminos y acciones afectadas. Después, aplique un runbook separado y autorizado para contención, conciliación, corrección, notificación, restauración o compensación, según corresponda. En decisiones sobre datos sensibles, permisos consecuentes o acciones reguladas, intervienen los profesionales calificados de seguridad, privacidad, asuntos legales, registros, riesgo o dominio.

• Registre el disparador, la primera observación y la cohorte afectada.
• Identifique solicitudes, rutas del flujo y acciones externas relacionadas.
• Documente el objetivo conocido como bueno y el resultado de compatibilidad.
• Separe la hora de restauración del tráfico de cualquier corrección externa.
• Asigne la disposición final y las mejoras de evaluación o monitoreo.

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

Un registro reconstructable conserva el manifiesto inmutable, identificadores y parámetros resueltos, enlaces del entorno, resultados de compatibilidad, versiones y resultados de evaluación, aprobaciones, eventos de despliegue, asignaciones de tráfico, trazas, hallazgos, reversiones y disposición final. Adjunte el ID del lanzamiento a cada traza para atribuir generaciones, herramientas, transferencias, guardrails, tiempos y resultados a la configuración que atendió la solicitud. Cuando estén disponibles, registre también el identificador de solicitud del proveedor y el de la traza de la aplicación.

La meta es reproducibilidad de configuración y de decisión, no una promesa de repetir el mismo texto byte por byte. Los modelos estocásticos y los servicios alojados pueden impedir una reproducción idéntica aunque se conserven snapshots y parámetros. Tampoco hace falta guardar cada prompt, entrada de herramienta, salida o payload del cliente: preserve identificadores y evidencia gobernada, y aplique la política organizacional a los datos sensibles. Empiece con el paquete más pequeño que todavía identifique candidato, evidencia, promociones y objetivo de reversión sin perder la historia decisoria.

• Qué configuración efectiva estaba activa.
• Qué evidencia y criterios se aplicaron.
• Quién aprobó, pausó, rechazó o revirtió.
• Qué cohortes y solicitudes recibieron el candidato.
• Qué limitaciones, efectos y acciones posteriores quedaron abiertos.