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

Un lanzamiento de IA no es solo un modelo nuevo ni una cadena de instrucciones revisada: es toda la configuración capaz de cambiar lo que el servicio hace. Si se revierte únicamente el modelo y siguen activos el prompt, el contrato de una herramienta, los permisos o la lógica de reintentos modificados, producción permanece en un estado que quizá nunca se evaluó. La respuesta operativa consiste en asignar una identidad única al conjunto, congelar sus referencias efectivas, probar exactamente ese candidato y conservar un paquete compatible al que devolver el tráfico.

¿Qué debe considerarse un único lanzamiento de IA?

Debe considerarse un único lanzamiento el conjunto de dependencias que puede alterar el comportamiento servido, la autoridad disponible, el riesgo, el coste, la latencia o la capacidad de observar el sistema. Esa frontera suele incluir el prompt, el identificador resuelto del modelo y sus parámetros, las herramientas, sus esquemas y permisos, las políticas o barreras, la recuperación de contexto, el código del flujo, los esquemas de entrada y salida, las dependencias de ejecución y las vinculaciones relevantes del entorno.

El criterio no es si un elemento lleva la etiqueta «IA», sino si puede cambiar el tratamiento de una solicitud. Una regla de encaminamiento, una conexión aprobada o una versión de biblioteca puede ser tan decisiva como el modelo. El inventario debe abarcar dependencias propias y de terceros cuando sean materiales, sin convertir el manifiesto en un catálogo indiscriminado. El NIST trata las actividades del ciclo de vida como interdependientes, y Google Cloud describe los sistemas de producción como conjuntos mucho más amplios que el código del modelo.

• Componentes de ejecución: prompt, modelo fijado, parámetros, herramientas, permisos, políticas, contexto, flujo, esquemas y dependencias.
• Vinculaciones del entorno: servicio de destino, reglas de encaminamiento, conexiones autorizadas, banderas y referencias de datos.
• Activos de garantía enlazados: conjunto de evaluación, evaluadores, rúbricas y umbrales que influyen en la decisión, aunque no atiendan solicitudes.

Cada cambio material en esa configuración inicia un candidato nuevo. Los historiales individuales siguen siendo valiosos, pero no deben ser la única forma de averiguar qué combinación estuvo activa. Una identidad común permite responder qué se probó, qué atendió una solicitud problemática y qué conjunto debe restaurarse. Los activos de evaluación se versionan por separado y se enlazan al expediente porque un cambio de rúbrica o umbral puede modificar la lectura de unos resultados sin alterar la ruta de ejecución.

¿Cómo se reúne la pila de comportamiento en un manifiesto?

La pila se reúne congelando un manifiesto inmutable con un identificador de lanzamiento y una referencia estable para cada componente. El encabezado debe indicar fecha de creación, responsable, servicio de destino, estado, condiciones de parada, responsable de reversión y versión anterior conocida como válida. Para cada pieza se conserva la versión resuelta, el commit, el resumen criptográfico, el identificador de artefacto o una referencia estable equivalente, además de los ajustes efectivos que modifican su funcionamiento.

Un alias como «producción» o «último» es un puntero, no una identidad inmutable. MLflow, por ejemplo, combina versiones de plantillas con alias mutables y permite configuraciones de modelo que pueden cambiar; también puede asociar modelos con versiones concretas de prompts. Por eso el expediente debe guardar el destino resuelto y, cuando sea necesario, una instantánea o resumen de la configuración efectiva. Si el proveedor ofrece instantáneas de modelo, se registra la probada, sin afirmar que ello vuelva deterministas las respuestas.

• Identidad y propiedad: lanzamiento, fecha, responsable, servicio, estado y versión conocida como válida.
• Configuración resuelta: versiones o resúmenes de todos los componentes y sus parámetros efectivos.
• Entorno: conexiones autorizadas, referencia de recuperación o datos, bandera, encaminamiento y restricciones de despliegue, nunca los secretos.
• Garantía y recuperación: evidencia, aprobación, compatibilidad, condiciones de parada, responsable y procedimiento para acciones externas.

En un asistente interno de soporte, support-assistant-r18 podría reunir el prompt p-42, la instantánea m-2026-07 y sus parámetros, el esquema de herramienta t-9, la política policy-12, el commit wf-a71, el esquema reply-6 y el bloqueo de dependencias. Su expediente enlazaría eval-23 y las versiones de los evaluadores. support-assistant-r17 solo sería un destino de reversión válido tras comprobar que tolera los nuevos campos opcionales de fecha límite y motivo de escalado.

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

¿Qué evidencia debe decidir si el candidato avanza?

Debe decidirlo evidencia vinculada al candidato exacto, comparada con la versión vigente y cerrada con una resolución de promover, mantener en espera o rechazar. Las notas explican la intención conductual, todas las dependencias cambiadas, los escenarios e interfaces afectados, las modificaciones de permisos u observabilidad, las limitaciones conocidas, el riesgo residual, el plan de promoción y el destino compatible de reversión. Así, quien aprueba entiende la decisión, no solo una colección de métricas.

Las pruebas deben cubrir los contratos aplicables, la calidad de las tareas reales, la seguridad y la autoridad, el uso de herramientas, la fiabilidad, la latencia y el coste. Las evaluaciones generales del proveedor no capturan todos los matices del flujo: conviene incluir ejemplos reales, segmentos importantes y casos poco frecuentes pero costosos, con revisión especializada cuando corresponda. Un promedio favorable no compensa un incumplimiento material de contrato, un permiso indebido o una regresión grave en un segmento.

También se versionan el conjunto de evaluación, los evaluadores, las rúbricas y los umbrales. De lo contrario, dos ejecuciones aparentemente comparables podrían haberse juzgado con reglas distintas. Cada puerta conserva métodos, resultados, excepciones, responsable y disposición final. En lanzamientos de mayor riesgo puede separarse a quien prepara el cambio de quien autoriza la promoción; en equipos pequeños pueden coincidir los roles, pero no debe desaparecer el rastro de la decisión.

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

El mismo candidato resuelto debe avanzar por una escalera de exposición medida, sin cambiar sus componentes entre etapas. Cuando resulte viable, se empieza con sombra o repetición sin actuación: las herramientas de escritura y cualquier efecto relevante se desactivan o se aíslan, porque reproducir acciones reales a ciegas no es una prueba segura. Después se pasa a usuarios internos, una cohorte estable de producción, exposición ampliada y, finalmente, todo el tráfico.

1. Reproducir casos representativos sin ejecutar efectos externos y comparar las trazas completas.
2. Exponer al grupo interno manteniendo las aprobaciones de cualquier acción relevante.
3. Asignar una cohorte estable al candidato y compararla con la versión vigente.
4. Ampliar solo cuando se cumplan la observación y las evidencias acordadas.
5. Pasar a tráfico completo y continuar el seguimiento identificado por lanzamiento.

Las asignaciones de cohorte, el volumen expuesto, el momento de observación y la decisión de cada etapa pertenecen a registros de despliegue enlazados; no se reescribe el manifiesto. Un aumento preaprobado de exposición puede promover el mismo candidato. En cambio, modificar el prompt, un parámetro, una herramienta, un permiso, la recuperación, el flujo, un esquema, una dependencia o una vinculación que cambie la solicitud atendida exige otra identidad y evidencia propia.

No existen porcentajes, tamaños de muestra ni ventanas universales. Se eligen según el riesgo del servicio, su tráfico, la rapidez con la que puede detectarse un problema y la capacidad del equipo para responder. Las cohortes estables y la telemetría etiquetada facilitan la comparación, pero una prueba en sombra puede diferir del uso activo y un canario puede no contener condiciones raras. Superar una etapa reduce incertidumbre; no demuestra una seguridad completa.

¿Cuándo debe detenerse 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 no autorizada, un contrato incumplido o un fallo grave de fiabilidad; las demás regresiones se valoran con límites definidos para el servicio. Las condiciones se acuerdan antes de exponer tráfico, junto con el responsable y la respuesta esperada. Un hallazgo ambiguo puede justificar una pausa e investigación en vez de una reversión automática, pero también necesita una resolución explícita.

La reversión debe devolver el tráfico al último paquete completo, conocido como válido y todavía compatible, no deshacer una sola pieza. Antes del lanzamiento se ensaya la restauración y se comprueban esquemas, estado persistente, migraciones, contratos de herramientas, rutas y disponibilidad del proveedor. Una versión anterior puede conservar una buena evaluación histórica y, aun así, haber dejado de encajar con el entorno actual. La compatibilidad es una conclusión verificada, no una propiedad permanente de la etiqueta.

Restaurar la configuración solo controla las solicitudes futuras. No borra mensajes, revierte escrituras, cancela aprobaciones ni deshace tareas creadas en sistemas externos. En el ejemplo de soporte, si r18 generase una tarea de CRM no autorizada o mal formada, el equipo deshabilitaría esa ruta, localizaría los identificadores afectados mediante las trazas y aplicaría el procedimiento autorizado de corrección. Volver a r17 impediría nueva exposición, pero no eliminaría las tareas existentes.

• Registrar el disparador, el momento observado, el lanzamiento y la cohorte afectados.
• Validar el paquete conocido como válido antes de restaurar el tráfico.
• Separar la restauración técnica de la contención, conciliación, corrección, notificación o compensación.
• Conservar la disposición final, el responsable de seguimiento y las mejoras necesarias en pruebas o vigilancia.

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

Un expediente enlazado permite reconstruir el lanzamiento cuando conserva el manifiesto inmutable, las referencias y parámetros resueltos, las vinculaciones del entorno, las comprobaciones de compatibilidad, las versiones y resultados de evaluación, las aprobaciones, los despliegues, la exposición, las trazas, los hallazgos, las reversiones y la disposición final. El objetivo es demostrar qué configuración estuvo disponible, qué evidencia se revisó y quién decidió, sin depender de recuerdos o historiales inconexos.

El identificador del lanzamiento debe viajar con las trazas para atribuir generaciones, llamadas a herramientas, transferencias, barreras, tiempos y resultados. Cuando existan, también se registran el identificador de petición del proveedor y el de la traza de la aplicación, lo que ayuda a investigar a través de los límites del sistema. Esta observabilidad no obliga a conservar cada prompt, entrada de herramienta, respuesta o carga del cliente: los datos sensibles siguen la política de tratamiento y retención de la organización.

Ese expediente ofrece reproducibilidad de configuración y de decisión, no reproducción idéntica de salidas. Una instantánea fijada, un resumen de contenido o unos parámetros archivados reducen ambigüedad, pero el muestreo, la infraestructura y los servicios alojados pueden impedir repetir exactamente una respuesta. Conviene adoptar el paquete más pequeño que aún identifique candidato, evidencia, promoción y reversión. Los cambios sobre datos sensibles, permisos relevantes, flujos regulados, conservación o remediación requieren la intervención de los especialistas cualificados de la organización.