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

Una versión de IA debe representar toda la configuración capaz de cambiar lo que el servicio hace, no solamente el prompt o el nombre del modelo. Si un equipo revierte el modelo, pero deja activo un nuevo permiso, esquema de herramienta, parámetro, flujo de reintentos o ajuste de recuperación, no ha restaurado el comportamiento probado. La unidad operativa correcta es un paquete identificable que conecte cada dependencia resuelta con su evidencia, aprobación, despliegue y destino de reversión. Esa identidad permite responder qué se evaluó, qué atendió una solicitud problemática y qué configuración completa 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 alterar el comportamiento servido, la autoridad concedida, el riesgo, el costo, la latencia o la observabilidad. El límite exacto varía por sistema, pero la pregunta práctica es estable: si modificar este elemento podría cambiar cómo se procesa una solicitud o cómo se controla el resultado, ese elemento pertenece al candidato. NIST trata las actividades y componentes del ciclo de vida como interdependientes, mientras Google Cloud describe la producción de aprendizaje automático como algo mucho más amplio que el código del modelo.

• Prompt y sus plantillas o mensajes de sistema resueltos.
• Modelo fijado, parámetros efectivos y formato de respuesta.
• Esquemas de herramientas, permisos, aprobaciones y conexiones autorizadas.
• Políticas, barreras, recuperación de contexto y configuración de búsqueda.
• Código del flujo, reglas de enrutamiento, reintentos y transferencias.
• Esquemas de entrada y salida, dependencias de ejecución y enlaces del entorno.
• Conjuntos de evaluación, evaluadores, rúbricas y umbrales que autorizan la promoción.

Los activos de evaluación merecen una distinción. Normalmente no intervienen en la ruta que atiende al usuario, pero sí cambian la interpretación de la evidencia y, por tanto, la decisión de liberar. Deben versionarse y enlazarse al registro, aunque no formen parte del paquete ejecutable. También conviene incluir dependencias de terceros solo cuando puedan afectar materialmente el servicio o su autorización. Toda modificación relevante de prompt, instantánea, parámetro, permiso, política, contrato, flujo, esquema, recuperación, dependencia o enlace de entorno crea un candidato nuevo.

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

La pila se une congelando un manifiesto inmutable con una identidad propia y referencias estables para cada componente. Un alias como «producción» o «más reciente» sirve para ubicar un destino, pero no demuestra cuál fue el objeto evaluado. El registro debe guardar la versión resuelta, el commit, el digest del artefacto, la huella del contenido u otra referencia estable, junto con los ajustes efectivos. Esto importa porque algunos registros mantienen inmutable la plantilla del prompt, pero permiten cambiar configuraciones del modelo asociadas con ella.

• Identificador del lanzamiento, fecha de creación, responsable, servicio objetivo y estado.
• Componentes resueltos y parámetros efectivos, sin guardar secretos dentro del manifiesto.
• Enlaces de entorno: conexión aprobada, referencia de datos, bandera, enrutamiento y restricciones.
• Condiciones de compatibilidad, destino conocido anterior, responsable de reversión y criterios de parada.
• Vínculos a compilación, pruebas, evaluaciones, aprobaciones y plan de promoción.

En un asistente interno de soporte, el candidato support-assistant-r18 podría unir el prompt p-42, la instantánea m-2026-07, temperatura 0,2 y límite efectivo de salida, el esquema de CRM t-9, la política policy-12, el flujo wf-a71, el esquema reply-6 y el bloqueo de dependencias. Su expediente enlazaría eval-23 y las versiones de sus evaluadores. support-assistant-r17 solo sería un destino válido después de comprobar que admite los campos opcionales de fecha de vencimiento y motivo de escalamiento.

La asignación de tráfico y las horas de despliegue cambian durante la promoción; por eso pertenecen a eventos vinculados y no deben reescribir el manifiesto. Una ampliación previamente autorizada puede promover al mismo candidato. En cambio, cambiar una regla de enrutamiento o un enlace de entorno que modifique el contexto, la autoridad o el tratamiento de cada solicitud produce otra configuración y exige una identidad nueva. Así se conserva la diferencia entre el objeto evaluado y la historia de su exposición.

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 el candidato avanza?

Debe decidir una combinación de evidencia del candidato exacto, comparación con la versión vigente y una disposición explícita: promover, mantener en espera o rechazar. Las notas de lanzamiento deben explicar la intención conductual, cada dependencia modificada, los escenarios e interfaces afectados, los cambios de permisos u observabilidad, las limitaciones conocidas, el riesgo residual, la persona responsable del despliegue y el destino compatible de reversión. No basta con afirmar que mejoró la calidad; la nota debe conectar el cambio con decisiones comprobables.

Las evaluaciones generales del proveedor no capturan todos los matices de un flujo empresarial. La suite debe incluir ejemplos representativos, casos poco frecuentes pero costosos, segmentos importantes, contratos, comportamiento de herramientas, autoridad, seguridad, confiabilidad, latencia y costo cuando sean pertinentes. Los datos, evaluadores, rúbricas y umbrales también reciben versión: si cambia la puerta, cambia la lectura del resultado. Un promedio favorable nunca debe ocultar una falla material de contrato, permiso, seguridad o segmento.

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

El mismo candidato resuelto debe avanzar por una escalera de exposición medida, sin ajustes silenciosos entre etapas. Las pruebas fuera de línea reducen incertidumbre, pero no reproducen toda la diversidad, carga ni interacción de producción. Cuando sea viable, el primer paso es una repetición en sombra o sin capacidad de actuar. Las herramientas que escriben, envían, aprueban o modifican sistemas externos deben deshabilitarse o aislarse; repetir ciegamente acciones reales convertiría una prueba en una segunda ejecución.

1. Reproducir casos representativos sin efectos externos y comparar el rastro completo con la versión vigente.
2. Habilitar el candidato para un grupo interno con aprobaciones humanas aún activas.
3. Asignar una cohorte estable de producción para evitar que una misma persona cambie de versión entre solicitudes relacionadas.
4. Ampliar la exposición únicamente cuando se cumplan la observación y la muestra definidas para el servicio.
5. Pasar a tráfico completo y mantener monitoreo identificado por versión, con el destino anterior disponible durante el periodo acordado.

Cada evento debe registrar reglas de cohorte, asignación, momento de observación, señales comparadas y decisión. Los porcentajes, tamaños de muestra y ventanas no se copian de una receta universal: dependen del riesgo, volumen, demora de detección y capacidad de respuesta. Una ampliación prevista no crea otra versión, pero cualquier cambio de prompt, parámetro, herramienta, permiso, política, recuperación, flujo, esquema, dependencia o enlace conductual sí lo hace. La sombra y el canario aportan evidencia; ninguno prueba cobertura completa ni descarta fallas raras.

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

El lanzamiento debe detenerse ante una infracción de seguridad o política, una acción de herramienta sin autorización, una ruptura de contrato o una falla grave de confiabilidad; las demás regresiones usan límites propios del servicio definidos antes de exponer tráfico. Un resultado ambiguo puede justificar una pausa y una investigación, en vez de una reversión automática, pero siempre requiere una disposición y un responsable. La regla evita negociar el riesgo bajo presión y separa los hallazgos críticos de variaciones que necesitan más evidencia.

La reversión debe restaurar el paquete completo conocido y compatible, no únicamente el modelo. Antes del lanzamiento hay que ensayar esa restauración y comprobar esquemas, estados, migraciones, contratos de herramientas, enrutamiento y disponibilidad del proveedor. Una versión anterior puede seguir identificada y aun así haber dejado de ser utilizable. Después de recuperar el tráfico, deben validarse las rutas principales y dejarse registrados el disparador, la hora observada, el candidato afectado, el destino restaurado y el resultado.

• La reversión cambia qué configuración atiende solicitudes futuras.
• No borra mensajes, escrituras de datos, aprobaciones ni tareas ya creadas.
• Los rastros identificados por versión ayudan a localizar solicitudes y acciones afectadas.
• La contención, conciliación, corrección, notificación o compensación sigue un procedimiento autorizado aparte.

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

El registro mínimo debe permitir reconstruir la configuración efectiva, la evidencia observada y la decisión, sin prometer una repetición idéntica de la salida. Para ello conserva el manifiesto inmutable, los identificadores y parámetros resueltos, los enlaces del entorno, las comprobaciones de compatibilidad, las versiones y resultados de evaluación, las aprobaciones, los eventos de despliegue, la exposición, los hallazgos, las reversiones y la disposición final. La identidad del lanzamiento debe viajar en los rastros que atienden cada solicitud.

• Versiones, digests, parámetros y referencias efectivas de los componentes.
• Evidencia, responsables, aprobaciones, excepciones y decisiones de cada puerta.
• Cohorte, asignación de tráfico, tiempos y resultado de cada promoción.
• Rastros de generaciones, herramientas, transferencias, barreras y resultados pertinentes.
• Identificadores de solicitud del proveedor y de la aplicación cuando estén disponibles.

No hace falta retener cada prompt, entrada de herramienta, salida del modelo o carga de un cliente para mantener trazabilidad. Los identificadores, resultados gobernados y muestras autorizadas pueden conservarse conforme a la política de la organización, mientras los datos sensibles reciben el tratamiento correspondiente. El resultado es reproducibilidad de configuración y reproducibilidad de decisión: se puede establecer qué se intentó servir y por qué se aprobó. Una instantánea fijada, un digest o una solicitud archivada no garantizan una salida idéntica de un servicio alojado o estocástico.

Conviene adoptar el expediente más pequeño que todavía identifique al candidato, su evidencia versionada, las decisiones de promoción y un destino de reversión compatible. Si el cambio modifica el tratamiento de datos sensibles, permisos consecuenciales, actividades reguladas, obligaciones de retención o la remediación de acciones externas, deben intervenir los responsables calificados de seguridad, privacidad, asuntos legales, registros, riesgo o del dominio. Este patrón organiza el lanzamiento y su evidencia; no determina por sí mismo los requisitos profesionales o normativos aplicables.