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 puede cambiar lo que el servicio hace, no solamente un prompt o un endpoint de modelo. Si un equipo revierte el modelo, pero deja activos el prompt nuevo, un permiso distinto o la lógica de reintentos modificada, no ha restaurado la versión que evaluó. Sin una identidad común tampoco puede demostrar qué combinación atendió una solicitud problemática, qué evidencia autorizó su despliegue ni cuál es el conjunto compatible al que debe devolver el tráfico.

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

Debe contar como un lanzamiento el conjunto de dependencias capaces de modificar las respuestas, las acciones permitidas o las condiciones operacionales del servicio. NIST trata las actividades y componentes del ciclo de vida como elementos interdependientes, mientras Google Cloud describe la producción de ML como algo más amplio que el modelo: también incluye configuración, pruebas, metadatos, infraestructura y monitoreo. El límite exacto depende del sistema, pero no puede definirse por comodidad administrativa.

El inventario mínimo reúne el prompt; el identificador resuelto del modelo y sus parámetros de inferencia; los contratos y permisos de 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 los enlaces de ambiente que alteran el tratamiento de una solicitud. Un cambio material en cualquiera de esos elementos crea un candidato nuevo, aunque el endpoint del modelo conserve su nombre.

Los datos de evaluación, evaluadores automáticos, rúbricas y umbrales ocupan una categoría distinta: normalmente no corren en la ruta que atiende al usuario, pero sí cambian la decisión de autorizarla. Por eso deben tener versiones vinculadas al registro del lanzamiento. La misma regla se aplica a componentes propios o de terceros solo cuando pueden influir de manera material en el servicio o en su aprobación; inventariar cada biblioteca irrelevante genera ruido sin mejorar el control.

¿Cómo se reúne la configuración en un manifiesto de lanzamiento?

La configuración se reúne congelando un manifiesto inmutable con un identificador de lanzamiento y referencias estables para cada componente. Debe registrar fecha de creación, responsable, servicio objetivo, estado, condiciones de detención, encargado del rollback y versión conocida anterior. Para cada pieza guarda la versión resuelta, commit, digest, huella de contenido u otra referencia estable, además de los ajustes efectivos. Un alias como “producción” o “último” es apenas un puntero y no reemplaza al destino que resolvía al crear el candidato.

• Componentes: prompt, instantánea del modelo, temperatura y demás parámetros, herramientas, permisos, políticas, recuperación, flujo, esquemas y bloqueo de dependencias.
• Ambiente: servicio de destino, identidad del feature flag, reglas de enrutamiento, conexiones aprobadas y referencia de datos o recuperación, sin copiar secretos al manifiesto.
• Compatibilidad: migraciones, contratos de herramientas, disponibilidad de proveedores y campos que deben seguir siendo legibles por la versión anterior.
• Evidencia vinculada: compilación, pruebas de contrato, suite de evaluación, versiones de graders, aprobación, observaciones del despliegue y limitaciones conocidas.

Por ejemplo, support-assistant-r18 puede fijar el prompt p-42, el modelo m-2026-07 y sus parámetros, el contrato CRM t-9, la política policy-12, el commit wf-a71, el esquema reply-6 y el bloqueo del runtime. Su paquete enlaza eval-23 y las versiones de los evaluadores, pero no muta el manifiesto cuando aumenta la exposición. El objetivo support-assistant-r17 solo es válido después de comprobar que tolera los nuevos campos opcionales de fecha y escalamiento.

Si algo puede cambiar la conducta atendida —o la evidencia que la autoriza— necesita una identidad resuelta en el registro del lanzamiento.

¿Qué evidencia decide si el candidato puede avanzar?

El candidato avanza solo cuando la evidencia del mismo conjunto completo satisface puertas acordadas y termina en una decisión registrada de promover, mantener en espera o rechazar. Las notas deben explicar la intención conductual, cada dependencia modificada, escenarios e interfaces afectados, cambios de permisos u observabilidad, evidencia disponible, limitaciones, riesgo residual, responsables del despliegue y objetivo compatible de rollback. Así, la aprobación responde a una diferencia operacional concreta y no a una lista genérica de commits.

Las evaluaciones generales del proveedor no reemplazan ejemplos del flujo real. Conviene comparar el candidato con la versión vigente, incorporar casos poco frecuentes pero costosos, revisar segmentos importantes y auditar los graders automáticos con especialistas del dominio. Una media favorable no compensa una falla material de contrato, una acción sin autorización, una infracción de seguridad o una regresión concentrada en un segmento crítico. Las suites, rúbricas y límites también se versionan, porque cambiar la puerta altera la interpretación del resultado.

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

El mismo candidato resuelto debe avanzar por etapas medibles, sin que el equipo le cambie componentes a mitad del recorrido. Cuando sea viable, comienza con sombra o repetición no actuante: las herramientas que escriben, aprueban o producen otros efectos relevantes quedan deshabilitadas o aisladas. Después pasa a un grupo interno, una cohorte estable de producción, una exposición ampliada y finalmente el tráfico completo. En cada etapa se comparan señales de tarea, seguridad, herramientas, confiabilidad, latencia y costo con la versión vigente.

1. Reproducir casos representativos sin ejecutar acciones externas y comparar las trazas completas.
2. Habilitar al equipo interno manteniendo las aprobaciones humanas de acciones relevantes.
3. Asignar una cohorte de producción estable para que una misma entidad no salte entre versiones.
4. Ampliar solo después de cumplir la ventana de observación y la evidencia acordadas.
5. Llegar al tráfico completo, conservar temporalmente el objetivo anterior y continuar el monitoreo etiquetado por lanzamiento.

La asignación de tráfico, la regla de cohorte, los tiempos de observación y la decisión de cada etapa pertenecen a eventos de despliegue vinculados al manifiesto. Un aumento preaprobado de exposición no crea por sí solo otro candidato. Sí lo crea cualquier cambio de prompt, parámetro, herramienta, permiso, política, recuperación, flujo, esquema, dependencia o enlace de ambiente que modifique el tratamiento de una solicitud. Los porcentajes y plazos se definen según riesgo, volumen, demora de detección y capacidad operacional; un canario no representa todas las condiciones ni revela necesariamente fallas raras.

¿Cuándo se detiene el lanzamiento y qué debe restaurar el rollback?

El lanzamiento debe detenerse ante una infracción de seguridad o política, una acción de herramienta sin autorización, una ruptura contractual o una falla grave de confiabilidad; las demás regresiones se juzgan con límites propios del servicio acordados antes de exponer tráfico. Un resultado ambiguo puede justificar una pausa para investigar en vez de un rollback automático, pero siempre necesita una disposición y un responsable explícitos. La decisión no debe improvisarse cuando la presión operacional ya está instalada.

El rollback debe devolver el tráfico al último lanzamiento completo, conocido y compatible, no revertir una pieza aislada. Antes de depender de ese objetivo hay que ensayar la restauración y verificar esquemas, estado persistente, migraciones, disponibilidad del proveedor, contratos de herramientas y reglas de enrutamiento. El conjunto anterior puede haber sido seguro cuando se publicó y aun así dejar de ser restaurable después de un cambio de datos o interfaz; por eso la compatibilidad es una comprobación vigente, no una propiedad histórica.

La reversión controla solicitudes futuras: no borra mensajes, no revierte escrituras, no cancela aprobaciones ni deshace acciones completadas en sistemas externos. Las trazas etiquetadas con el lanzamiento deben ayudar a ubicar solicitudes y sus identificadores de acción. Luego corresponde ejecutar un procedimiento separado y autorizado para contener, conciliar, corregir, notificar, restaurar o aplicar una acción compensatoria. En el ejemplo del asistente, volver a r17 no elimina una tarea CRM defectuosa; el equipo debe aislar la ruta de creación y corregir los registros afectados mediante su runbook.

¿Qué registro permite reconstruir un lanzamiento de IA?

Un registro permite reconstruir el lanzamiento cuando conecta el manifiesto inmutable con la evidencia que sustentó la decisión y con lo observado durante el despliegue. Debe conservar identificadores y parámetros resueltos, enlaces de ambiente, resultados de compatibilidad, versiones de las evaluaciones, aprobaciones, eventos de promoción, asignaciones de tráfico, hallazgos, trazas, rollback y disposición final. Google Cloud recomienda registrar versiones, tiempos, ejecutores, parámetros, artefactos, evaluaciones y la referencia anterior; esa disciplina evita depender de la memoria del equipo.

La identidad del lanzamiento debe viajar en los metadatos de la traza para atribuir generaciones, llamadas a herramientas, traspasos, barreras, tiempos y resultados a la configuración que los atendió. También conviene guardar los identificadores de solicitud del proveedor y de la aplicación cuando existan, porque facilitan el diagnóstico entre plataformas. Esto no obliga a retener cada prompt, entrada de herramienta, salida o dato de cliente: las cargas sensibles, las muestras y los plazos de conservación deben seguir la política de información de la organización.

El resultado es reproducibilidad de configuración y de decisión, no la promesa de repetir exactamente cada salida. Las instantáneas fijadas, huellas y parámetros archivados reducen ambigüedad, pero los servicios alojados y los modelos estocásticos pueden producir diferencias. El paquete más pequeño que sigue siendo útil identifica el candidato, su evidencia versionada, las decisiones de promoción y el objetivo compatible de reversión. Si cambia el tratamiento de datos sensibles, permisos relevantes, flujos regulados, retención o remediación externa, deben participar los especialistas internos que correspondan.