Versionar prompts, modelos y lógica de flujo como un solo lanzamiento de IA

Un lanzamiento de IA es la configuración completa que atiende una solicitud, no solo el nombre del modelo ni el texto del prompt. Si el equipo revierte el modelo, pero deja activos un esquema de herramienta, una política de permisos o una ruta de reintento modificados, no ha restaurado lo que realmente probó. La unidad operativa debe tener una sola identidad que permita saber qué combinación se evaluó, cuál recibió tráfico, qué sirvió una solicitud problemática y qué conjunto compatible puede recuperarse.

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

Debe contar como un solo lanzamiento todo elemento capaz de modificar el comportamiento servido, la autoridad, el riesgo, el costo, la latencia o la observabilidad. NIST trata las actividades del ciclo de vida de la IA como interdependientes y recomienda inventariar componentes, documentar evaluaciones y monitorear la operación. Google Cloud también describe un sistema en producción como algo más amplio que el modelo: incluye configuración, automatización, pruebas, metadatos, infraestructura de servicio y monitoreo.

En la práctica, el inventario reúne el prompt; el identificador resuelto del modelo y sus parámetros; los esquemas y permisos de herramientas; políticas o guardrails; recuperación y contexto; código del flujo; esquemas de entrada y salida; dependencias de ejecución; y bindings de entorno que cambien el manejo de una solicitud. Las dependencias propias o de terceros entran solo cuando pueden afectar materialmente el servicio. La frontera exacta depende del sistema.

Los conjuntos de evaluación, evaluadores automáticos, rúbricas y umbrales ocupan otra categoría: normalmente no se ejecutan en la ruta que atiende al usuario, pero sí pueden cambiar la decisión de autorizar el lanzamiento. Por eso deben tener versiones y quedar vinculados al expediente. Si cambia el prompt, una instantánea del proveedor, un parámetro efectivo, una política, una herramienta, un esquema, una dependencia o un binding conductual, nace un candidato distinto.

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

La configuración se une congelando un manifiesto con una identidad única y referencias estables para cada componente. Como mínimo, debe registrar el ID del lanzamiento, fecha de creación, propietario, servicio objetivo, estado, condiciones de parada, responsable de reversión y versión conocida anterior. Para cada pieza se guarda la versión resuelta, commit, digest del artefacto, hash de contenido u otra referencia estable, junto con sus ajustes efectivos.

Un alias como production o latest es apenas un puntero: el manifiesto debe conservar el destino que resolvía al crear el candidato. MLflow, por ejemplo, documenta versiones inmutables de plantillas, pero también alias mutables y configuraciones asociadas que pueden cambiar; además permite registrar vínculos entre modelos y versiones específicas de prompts. Cuando un proveedor ofrece instantáneas, conviene fijar la probada, sin asumir por ello que las respuestas serán deterministas.

• Identidad y control: lanzamiento, propietario, servicio, estado, parada, aprobación y objetivo anterior.
• Componentes resueltos: prompt, modelo y parámetros, herramientas, permisos, políticas, contexto, flujo, esquemas y runtime.
• Entorno: conexión aprobada, referencia de datos, feature flag, restricciones de enrutamiento y compatibilidad, sin guardar secretos.
• Evidencia vinculada: build, pruebas de contrato, suite y evaluadores versionados, resultados, limitaciones y decisiones.

Pensemos en support-assistant-r18, un asistente interno que resume tickets, propone respuestas y solo crea una tarea en el CRM después de la aprobación de un agente. El candidato enlaza el prompt p-42, el modelo m-2026-07 y sus parámetros, la herramienta t-9, la política policy-12, el commit wf-a71, el esquema reply-6 y el lock de dependencias. Su expediente vincula por separado eval-23 y las versiones de los evaluadores.

Las asignaciones de tráfico y las horas de despliegue pertenecen a eventos de promoción enlazados, no a mutaciones del manifiesto. Aumentar una exposición ya aprobada puede avanzar el mismo candidato. Cambiar una conexión, regla de enrutamiento o binding que altere el comportamiento, la autoridad o el contexto por solicitud exige otra identidad. Antes de señalar support-assistant-r17 como retorno, hay que comprobar su compatibilidad con los campos opcionales de fecha y escalamiento.

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 solo cuando la evidencia del paquete exacto satisface las puertas aplicables y un responsable registra una decisión de promover, mantener en espera o rechazar. Las notas deben explicar la intención conductual, las dependencias cambiadas, escenarios e interfaces afectados, permisos, observabilidad, resultados, limitaciones, riesgo residual, responsables del despliegue y el objetivo compatible de reversión. Así, la decisión puede revisarse sin reconstruir conversaciones dispersas.

Las evaluaciones generales del modelo no capturan todos los matices de un flujo empresarial. La comparación debe enfrentar el candidato con la versión vigente mediante ejemplos representativos, casos infrecuentes pero costosos, segmentos importantes e interfaces reales. También debe auditar la calidad de los evaluadores automáticos. Un promedio favorable no compensa una falla material de contrato, seguridad, autoridad o segmento; cada dimensión conserva su propia respuesta de bloqueo.

Los datos de evaluación, evaluadores, rúbricas y umbrales deben versionarse porque modificar una puerta cambia la interpretación del resultado aunque el runtime permanezca intacto. Los límites concretos se fijan según el objetivo y el riesgo del servicio, no mediante porcentajes universales. En cambios de mayor exposición, quien preparó el candidato puede ser distinto de quien autoriza su promoción; incluso en equipos pequeños deben quedar registrados el responsable, la evidencia y cualquier excepción.

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

El mismo candidato resuelto debe avanzar por etapas medidas, desde una prueba sin efectos hasta el tráfico completo. Cuando sea viable, se empieza con replay o sombra sobre casos representativos, pero con escrituras y otras acciones consecuentes deshabilitadas o aisladas. Después puede atender a un grupo interno, pasar a una cohorte estable de producción, ampliar su exposición y finalmente recibir todo el tráfico, siempre sin modificar su configuración.

1. Ejecutar sombra o replay no actuante y comparar trazas completas con la versión vigente.
2. Habilitar el candidato para un grupo interno manteniendo las aprobaciones de acciones externas.
3. Asignar una cohorte estable y comparar calidad, seguridad, herramientas, confiabilidad, latencia y costo.
4. Ampliar solo cuando se cumplan la observación y la evidencia acordadas.
5. Mover a tráfico completo y continuar el monitoreo identificado por lanzamiento.

Cada evento registra la regla de cohorte, asignación de tráfico, periodo observado, señales y disposición. Los porcentajes, muestras y ventanas deben responder al riesgo, volumen, latencia de detección y capacidad operativa del servicio; copiar cifras universales crea una falsa precisión. La sombra puede omitir efectos propios de la interacción real y una cohorte canaria puede no contener condiciones raras. Aprobar pruebas fuera de línea o etapas limitadas reduce incertidumbre, pero no demuestra seguridad completa.

Aumentar una asignación preaprobada no crea por sí solo otro lanzamiento. En cambio, tocar el prompt, modelo, parámetros, herramientas, permisos, política, recuperación, flujo, esquema, dependencia o binding conductual durante la promoción produce un candidato distinto que necesita evidencia propia. Esta disciplina evita atribuir a r18 resultados obtenidos por una variante improvisada y permite comparar las señales de producción con el paquete exacto que pasó las puertas.

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

El lanzamiento se detiene cuando alcanza una condición acordada antes de la exposición, y la reversión restaura el paquete completo conocido y compatible. Las infracciones de seguridad o política, el uso no autorizado de herramientas, las fallas de contrato y los errores graves de confiabilidad deben ser paradas duras. Para degradaciones de calidad, latencia o costo se usan límites propios del servicio. Un hallazgo ambiguo puede justificar una pausa e investigación, pero siempre necesita disposición y responsable.

Restaurar únicamente el modelo puede dejar activos el prompt, los permisos, la lógica o los esquemas responsables del problema. El objetivo debe ser una configuración anterior ensayada, como support-assistant-r17, tras comprobar esquemas, estado persistido, migraciones, disponibilidad del proveedor, contratos de herramientas y enrutamiento. Google Cloud recomienda probar con anticipación que la versión previa pueda recuperarse rápida y seguramente y conservar su referencia junto con los metadatos del despliegue.

La reversión controla solicitudes futuras; no elimina mensajes ni deshace escrituras, aprobaciones u otras acciones ya completadas en sistemas externos. Si r18 creó una tarea de CRM no autorizada o malformada, el equipo debe deshabilitar esa ruta, localizar los identificadores afectados mediante trazas y aplicar un runbook autorizado de contención, conciliación, corrección, notificación o compensación. Esa remediación es un trabajo separado de devolver el tráfico a r17.

• Registrar el disparador, la primera observación, el lanzamiento y las cohortes afectadas.
• Confirmar el objetivo conocido, su compatibilidad y las validaciones posteriores a restaurar el tráfico.
• Separar las acciones de contención o compensación de la reversión de configuración.
• Cerrar con disposición final, responsable de seguimiento y mejoras a pruebas o monitoreo.

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

Un lanzamiento puede reconstruirse cuando el registro enlaza la configuración efectiva, la evidencia observada y la decisión tomada. Debe conservar el manifiesto inmutable, identificadores y parámetros resueltos, bindings de entorno, hallazgos de compatibilidad, versiones y resultados de evaluación, aprobaciones, eventos de despliegue, asignaciones de tráfico, trazas, hallazgos, reversiones y disposición final. También conviene guardar tiempos, responsables, artefactos y la referencia al paquete anterior.

El ID del lanzamiento debe viajar en las trazas para atribuir generaciones, llamadas a herramientas, transferencias, guardrails, tiempos y resultados a la configuración que atendió cada solicitud. Cuando existan, los identificadores de la aplicación y del proveedor ayudan a investigar fallas que atraviesan límites técnicos. No hace falta retener cada prompt, entrada de herramienta, respuesta o payload de cliente: los datos sensibles y sus plazos siguen la política de información de la organización.

Este expediente ofrece reproducibilidad de configuración y de decisión, no una promesa de salida idéntica. Aun con instantáneas, parámetros y artefactos fijados, el muestreo, la infraestructura y un servicio alojado pueden impedir una repetición byte por byte. El paquete mínimo debe identificar el candidato, la evidencia que autorizó su avance, las decisiones de promoción y el objetivo de retorno. Cambios sensibles requieren además la intervención de los especialistas de seguridad, privacidad, riesgo, registros o dominio correspondientes.