La mayoría de los equipos de ingeniería tienen un checklist de despliegue. Cubre variables de entorno, migraciones de base de datos, procedimientos de rollback y smoke tests contra la API. Ese checklist es correcto para software. Es incompleto para pipelines de IA.
Los seis elementos a continuación no aparecen en los checklists estándar. Cada uno corresponde a un modo de falla específico. Cada modo de falla ha causado un incidente real en producción en algún equipo que asumió que su proceso existente era suficiente.
Los Seis Elementos del Checklist Específicos de IA
1. Bloqueo de Versión de Prompt
Qué previene: Deriva de prompts entre entornos.
Los prompts son código. Si no están fijados a un hash de versión o a una release etiquetada, un cambio en staging puede propagarse silenciosamente a producción durante un despliegue de rutina. El modo de falla: el formato de salida cambia sin una actualización de esquema correspondiente, los parsers downstream se rompen y el error aparece tres pasos alejado de la causa real.
Elemento del checklist: Confirmar que el hash de versión del prompt en producción coincide con la versión probada en staging. Detener el despliegue si divergen.
2. Smoke Test de Recuperación
Qué previene: Falla silenciosa de recuperación a nivel de índice.
Un sistema de recuperación puede devolver resultados sin devolver resultados correctos. Si el índice vectorial fue reconstruido con un cambio de esquema, una discrepancia en la dimensión de embeddings o un conjunto de documentos desactualizado, las consultas se resolverán pero las respuestas serán incorrectas. El modo de falla: el sistema parece saludable, pero los usuarios reciben respuestas incorrectas con total confianza durante 48 horas antes de que alguien lo note.
Elemento del checklist: Ejecutar tres consultas de respuesta conocida contra el índice de producción antes de que el tráfico esté activo. Requerir coincidencia exacta o coincidencia por umbral en los IDs de documentos esperados. Esto es distinto del probe de regresión de recuperación cubierto en un post anterior — este es un gate previo al tráfico, no una suite de regresión.
3. Verificación del Camino de Fallback
Qué previene: Falla silenciosa cuando el modelo primario o la capa de recuperación no está disponible.
Todo pipeline de IA debería tener un fallback: un modelo más simple, una respuesta en caché o un mensaje de degradación controlada. El modo de falla cuando esto se omite: el camino primario cae, el fallback nunca fue ejercitado en producción y resulta que la ruta de fallback tiene una API key mal configurada o un timeout de 2 segundos en lugar de 20.
Elemento del checklist: Activar el camino de fallback manualmente en producción antes de habilitar el tráfico primario. Confirmar que devuelve una respuesta válida dentro de la latencia aceptable.
4. Validación del Esquema de Salida
Qué previene: Salida malformada del modelo que rompe los consumidores downstream.
Los modelos no siempre devuelven lo que se espera. Un campo JSON desaparece. Un campo de tipo string devuelve un entero. El modo de falla: el servicio downstream que consume la salida del modelo lanza una excepción no manejada, y el error se registra como un 500 genérico en lugar de un error de salida de IA, lo que dificulta el rastreo.
Elemento del checklist: Ejecutar el modelo contra cinco entradas canónicas en producción y validar la salida contra el esquema declarado antes de enrutar tráfico en vivo. Usar un validador estricto, no uno permisivo.
5. Confirmación del Umbral de Confianza
Qué previene: Salidas de baja confianza que llegan a los usuarios sin un guard.
La mayoría de los pipelines establecen un umbral de confianza durante el desarrollo y nunca verifican que haya sobrevivido el despliegue. Las diferencias de entorno, los cambios de versión del modelo o las actualizaciones del índice pueden desplazar las distribuciones de puntajes. El modo de falla: el umbral que filtraba el 15% de las salidas en staging ahora filtra el 2% en producción, y las respuestas de baja calidad llegan a los usuarios a una tasa mayor que la prevista.
Elemento del checklist: Muestrear 20 requests de producción inmediatamente después del despliegue. Confirmar que la distribución de puntajes de confianza coincide con el rango esperado de staging dentro de una tolerancia aceptable.
6. Verificación del Enrutamiento de Alertas
Qué previene: Errores específicos de IA que pasan desapercibidos porque se enrutan al equipo equivocado o a ninguno.
Los pipelines de IA producen señales de falla que el monitoreo estándar de aplicaciones no clasifica correctamente. Los fallos de recuperación, las violaciones del límite de tokens y los errores de timeout del modelo frecuentemente caen en un bucket de errores genérico. El modo de falla: una degradación específica de IA se ejecuta durante horas porque ninguna alerta se disparó, o una alerta se disparó a una cola que nadie monitorea.
Elemento del checklist: Confirmar que las clases de error específicas de IA — falla de recuperación, falla de validación de esquema, violación del umbral de confianza, timeout del modelo — tienen cada una un responsable nombrado y un camino de alerta probado. Enviar una alerta de prueba antes del go-live.
Integración en un Pipeline CI/CD Existente
Ninguno de estos elementos requiere una herramienta nueva. Requieren un paso nuevo.
Agregar una etapa de verificación post-despliegue al pipeline existente. Esta etapa se ejecuta después de que la infraestructura está activa pero antes de que el tráfico esté habilitado. Ejecuta las seis verificaciones anteriores como scripts o casos de prueba. Si alguna verificación falla, el pipeline se detiene y hace rollback.
El patrón de implementación:
- Bloqueo de versión de prompt: Una comparación de hash de una línea en un shell script.
- Smoke test de recuperación: Un script de Python que consulta el índice en vivo y verifica los IDs de documentos.
- Verificación del camino de fallback: Una llamada HTTP al endpoint de fallback con una aserción de timeout.
- Validación del esquema de salida: Un validador de JSON schema ejecutado contra la salida del modelo en vivo.
- Confirmación del umbral de confianza: Un script de muestreo que registra la distribución de puntajes y falla fuera de la tolerancia.
- Verificación del enrutamiento de alertas: Un evento de prueba enviado al sistema de alertas con un paso de confirmación manual.
Tiempo total agregado al pipeline: 3 a 8 minutos dependiendo de la latencia del modelo. Es un intercambio razonable para detectar los modos de falla que causan el primer incidente en producción.
Los equipos que omiten este paso no lo hacen porque estén en desacuerdo con la lógica. Lo omiten porque nadie escribió el checklist antes del primer despliegue. Escríbelo antes del primer despliegue.