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

Un release de IA es la configuración completa que puede cambiar lo que el servicio hace, no la etiqueta del modelo ni el texto del prompt por separado. Si producción conserva una política nueva, un esquema de herramienta distinto o una ruta de reintento modificada, volver solamente al modelo anterior no restaura el comportamiento probado. El equipo necesita una identidad única para saber qué evaluó, qué atendió cada solicitud y qué conjunto compatible puede recuperar.

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

El release debe abarcar toda dependencia capaz de alterar comportamiento, autoridad, riesgo, costo, latencia u observabilidad. NIST trata las actividades del ciclo de vida como interdependientes y contempla inventarios que incluyen componentes de terceros. Google Cloud también describe producción como un sistema de configuración, automatización, pruebas, metadatos, infraestructura y monitoreo, además del modelo. El límite concreto varía según el servicio, pero tiene que poder explicarse sin reconstruir historiales dispersos.

• Prompt y sus recursos de contexto; snapshot resuelto del modelo y parámetros efectivos.
• Esquemas de herramientas, permisos, políticas, guardrails y reglas de aprobación.
• Configuración de recuperación, datos o contexto; código del flujo, rutas de error y reintentos.
• Esquemas de entrada y salida, dependencias de ejecución y bindings del entorno que afecten solicitudes.
• Activos de evaluación versionados: conjunto de casos, evaluadores, rúbricas y umbrales.

Los activos de evaluación merecen una distinción útil: normalmente no corren en la ruta que responde al usuario, pero sí cambian la evidencia con la que se autoriza el release. Por eso se vinculan al expediente y se versionan. Si cambia un evaluador o un umbral, puede cambiar la interpretación del mismo candidato. En cambio, cualquier cambio material en la configuración operativa crea un candidato nuevo que debe identificarse y volver a evaluarse.

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

La configuración se vincula congelando un manifiesto con una identidad de release y referencias estables para cada componente. Debe incluir fecha de creación, responsable, servicio objetivo, estado, condiciones de detención, dueño del rollback y versión conocida anterior. Un alias como «producción» o «último» sirve para apuntar, no para probar qué se ejecutó. Hay que guardar el destino resuelto, sus parámetros efectivos y, cuando corresponda, un hash o digest.

• Identidad: release, propietario, servicio, entorno objetivo y estado.
• Componentes: versión, commit, digest o hash de contenido, más los ajustes efectivos.
• Bindings: conexión aprobada, referencia de datos, feature flag y restricciones de enrutamiento, sin copiar secretos.
• Compatibilidad: esquemas, contratos, migraciones, disponibilidad y versión conocida a restaurar.
• Evidencia: resultados, aprobación, plan de promoción, condiciones de detención y runbook para efectos externos.

En un asistente interno de soporte, support-assistant-r18 podría reunir el prompt p-42, el snapshot m-2026-07 y sus parámetros, el esquema CRM t-9, la política policy-12, el commit wf-a71, el esquema reply-6 y el lock de ejecución. El expediente enlazaría eval-23 y las versiones de sus evaluadores. support-assistant-r17 solo sería un objetivo válido después de comprobar compatibilidad con los nuevos campos opcionales de vencimiento y escalamiento.

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

¿Qué evidencia decide si el candidato puede avanzar?

El candidato avanza solamente cuando la evidencia del paquete completo satisface gates previamente acordados y termina en una decisión con responsable. Las notas deben decir qué comportamiento se busca, qué dependencias cambiaron, qué escenarios e interfaces quedan afectados, qué permisos u observabilidad se modifican, qué limitaciones persisten y qué versión compatible recibiría el tráfico. NIST recomienda métodos documentados y una determinación explícita sobre la continuidad del despliegue.

Las pruebas tienen que comparar el candidato con la versión vigente en tareas propias del flujo, segmentos importantes y casos infrecuentes pero costosos. Un promedio favorable no compensa una ruptura de contrato, una acción sin autoridad, una falla de seguridad o una regresión material concentrada en un segmento. Los evaluadores automáticos también necesitan auditoría y versiones identificables. Cuando el riesgo lo amerita, quien promueve puede ser distinto de quien preparó el cambio.

La salida de cada gate debe ser promover, mantener o rechazar, con evidencia, fecha y responsable registrados. Los límites de calidad, latencia y costo pertenecen al servicio: no hay un porcentaje universal que convierta un candidato en seguro. Si un cambio afecta datos sensibles, permisos consecuenciales o un flujo regulado, el paquete debe incorporar la revisión de los especialistas internos competentes sin presentar este método operativo como una determinación legal o de cumplimiento.

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

El mismo candidato resuelto debe avanzar por una escalera de exposición medida, sin modificar sus componentes entre etapas. Cuando sea viable, el recorrido empieza con repetición en sombra o no actuante: las escrituras y otros efectos consecuenciales quedan deshabilitados o aislados. Luego sigue una audiencia interna, una cohorte estable de producción, una expansión controlada y finalmente todo el tráfico. Cada paso compara señales acordadas con la versión vigente.

1. Reproducir casos representativos con herramientas de escritura desactivadas y comparar trazas completas.
2. Habilitar el candidato para un grupo interno manteniendo las aprobaciones sobre acciones externas.
3. Asignar una cohorte estable para que cada participante conserve la misma versión durante la observación.
4. Ampliar solo cuando se cumplan las condiciones de muestra, tiempo y operación definidas para el servicio.
5. Pasar a tráfico completo, conservar el objetivo de rollback y continuar el monitoreo etiquetado por release.

La asignación de tráfico, el tamaño de muestra y la ventana de observación dependen del riesgo, el volumen, la demora con que aparecen los problemas y la capacidad de respuesta. Aumentar una exposición preaprobada puede registrarse como evento del mismo release. Cambiar el prompt, el modelo, una herramienta, un permiso, el contexto o un binding crea otro candidato. Ni la sombra ni el canario demuestran cobertura completa: pueden omitir condiciones reales o fallas poco frecuentes.

¿Cuándo hay que detener el release y qué restaura el rollback?

Hay que detener el release ante una infracción de seguridad o política, una acción de herramienta sin autoridad, una ruptura de contrato o una falla grave de confiabilidad previamente definida. Para otras regresiones se aplican límites propios del servicio. Un hallazgo ambiguo puede justificar una pausa e investigación en vez de un rollback automático, pero la decisión y su responsable deben quedar explícitos. El criterio se acuerda antes de exponer tráfico, no durante la emergencia.

• Restaurar tráfico hacia la versión conocida completa, no revertir solamente el modelo.
• Verificar compatibilidad de esquemas, estado, migraciones, herramientas, rutas y proveedor.
• Ensayar la restauración y sus controles de validación antes de necesitarlos.
• Etiquetar solicitudes y acciones externas afectadas mediante la identidad del release.
• Aplicar un runbook autorizado para contener, conciliar, corregir, notificar o compensar.

El rollback de configuración gobierna solicitudes futuras; no borra mensajes, revierte escrituras, cancela aprobaciones ni deshace tareas ya creadas en otro sistema. En el ejemplo, volver de r18 a r17 impediría nuevas ejecuciones de r18, pero una tarea CRM defectuosa seguiría existiendo. Las trazas permiten ubicar el release, la llamada y el identificador de la acción. La corrección posterior necesita autoridad y un procedimiento separado, adecuado al sistema afectado.

¿Qué registro permite reconstruir un release más adelante?

El registro debe permitir reconstruir la configuración efectiva, la evidencia observada y la decisión tomada, aunque no reproduzca una salida idéntica. Como mínimo conserva el manifiesto inmutable, identificadores y parámetros resueltos, bindings, compatibilidad, versiones y resultados de evaluación, aprobaciones, eventos de despliegue, asignaciones de tráfico, hallazgos, rollback y disposición final. Google Cloud recomienda registrar versiones, ejecuciones, parámetros, artefactos, resultados y una referencia a la versión anterior.

• Adjuntar el release ID a cada traza y registrar generaciones, herramientas, handoffs, guardrails, tiempos y resultados relevantes.
• Conservar identificadores de la aplicación y del proveedor cuando estén disponibles para cruzar investigaciones.
• Relacionar cada promoción, pausa y restauración con su evidencia, persona responsable y momento.
• Guardar identificadores y muestras gobernadas sin exigir la retención indiscriminada de prompts, payloads o datos de clientes.
• Documentar qué material sensible se excluyó y qué política controla su acceso y conservación.

Este resultado es reproducibilidad de configuración y de decisión, no reproducción byte a byte. Un snapshot fijado, un hash, una temperatura baja o una solicitud archivada no eliminan el muestreo, las variaciones de infraestructura ni los cambios posibles de un servicio alojado. El expediente permite responder qué estaba configurado, qué se probó, quién autorizó y qué ocurrió; no debe prometer que una nueva ejecución devolverá exactamente el mismo texto.

Conviene adoptar el paquete más chico que todavía identifique al candidato, su evidencia versionada, sus decisiones de promoción y un objetivo de rollback compatible. Cuando el cambio modifica el tratamiento de información sensible, permisos con consecuencias, retención o remediación externa, deben participar los responsables calificados de seguridad, privacidad, riesgo, registros o dominio. El manifiesto ordena la operación y hace auditables las decisiones, pero no reemplaza esas determinaciones especializadas.