Preparado para Producción: El Checklist Completo para Funcionalidades de IA

La Pregunta

Siete artículos. Resiliencia, observabilidad, costes, governance, integración, testing. Muchos patrones y mucho código.

Ahora alguien pregunta: ¿la funcionalidad de IA está lista para salir?

La mayoría de equipos responden esa pregunta por sensación. Parece que funciona. La demo fue bien. El happy path va fino. A producción.

Así es como acabas con los problemas del artículo 1 — la brecha entre demo y producción. La demo siempre va bien. Producción es donde descubres lo que te dejaste.

Un checklist pre-vuelo elimina el problema de “parece que está listo”. Los pilotos no se saltan el checklist porque el avión parece estar bien. Lo ejecutan cada vez, porque el coste de dejarte algo es demasiado alto.

Este es ese checklist. No un resumen de los artículos — una revisión estructurada que ejecutas antes de que cualquier funcionalidad de IA salga a producción. Organizado por dominio, con una respuesta sí/no para cada punto. Si no puedes responder a alguno de estos, ese es el primero que hay que arreglar.

El Checklist

Resiliencia (Artículo 2)

El proveedor de IA tendrá incidencias. Tu funcionalidad tiene que sobrevivir a ellas sin llevarse por delante el resto de la aplicación.

• Timeout configurado — cada llamada a la IA tiene un timeout fijo. No solo el default del HttpClient — un timeout de Polly que salta antes del timeout de red.
• Reintentos en errores transitorios — reintentas en 429 y 503 con exponential backoff. No reintentas en respuestas malas o resultados vacíos.
• Circuit breaker configurado — después de un umbral de fallos, el circuito se abre. Conoces los umbrales (ratio de fallos, ventana de muestreo, duración del corte).
• El fallback devuelve null, no una excepción — cuando el circuito está abierto o los reintentos se agotan, el servicio devuelve null. No lanza excepción. Los consumidores manejan null correctamente.
• La caída de la IA solo afecta a la funcionalidad de IA — si el proveedor de IA se cae completamente, los usuarios pueden seguir leyendo, escribiendo y usando el resto de la aplicación. La funcionalidad de IA muestra un mensaje de “temporalmente no disponible”. Nada más se rompe.
• Ruta de fallback testeada — hay un test de integración usando un fake HTTP handler (503) que confirma que se devuelve null, no una excepción.

Observabilidad (Artículo 3)

Si algo va mal en producción, necesitas saberlo antes de que te lo digan los usuarios.

• Latencia p95 monitorizada — monitorizas latencia p50, p95 y p99 para las llamadas a la IA. No te fías de promedios. Hay una alerta si el p95 supera tu umbral.
• Uso de tokens registrado — los tokens de prompt y de completion se registran por petición. Tienes una línea base. Una desviación del 20% dispara una revisión.
• Tasa de fallback monitorizada — monitorizas con qué frecuencia se activa el fallback. Por encima del 2% dispara una alerta.
• Desglose de resultados visible — puedes ver la distribución entre success, empty_response, circuit_open y error en cualquier momento.
• Respuestas sospechosas registradas — respuestas demasiado cortas, o que empiezan con patrones de rechazo, se registran para revisión.
• Versión del modelo registrada — registras qué modelo respondió a cada petición. Cuando el proveedor actualiza silenciosamente, puedes correlacionar la marca temporal con un cambio de comportamiento.

Costes (Artículo 4)

Los costes de tokens escalan con la complejidad del input, no solo con el volumen de peticiones. Una carga de trabajo inesperada puede duplicar tu factura.

• Límite de tamaño de input aplicado — cada endpoint de IA rechaza inputs que superan un límite de tokens. El límite está documentado. El rechazo se registra.
• Respuestas cacheadas — peticiones repetidas o similares van al caché, no a la IA. Conoces tu tasa de cache hit. Está por encima del 20% para cargas estables.
• Routing de modelos implementado — las peticiones simples van a un modelo más barato. Las complejas van al más capaz. La lógica de routing es explícita, no accidental.
• Rate limit por usuario configurado — un usuario intensivo no puede consumir todo el presupuesto. Hay un límite por usuario o por tenant. Los usuarios reciben aviso cuando se acercan al límite.
• Métrica de coste diario existente — calculas el coste a partir del conteo de tokens y precios del modelo. Tienes un total diario. Hay un umbral de alerta de presupuesto.
• Finanzas puede entender la factura — puedes explicar qué hace que el coste de IA suba o baje. Si no puedes explicarlo, no puedes controlarlo.

Governance y Compliance (Artículo 5)

Si procesas datos de usuarios en la UE, esto no es opcional. Son requisitos legales.

• Datos personales mapeados — sabes exactamente qué campos se envían a la IA. “Nada sensible” no es una respuesta a menos que lo hayas verificado campo por campo.
• DPA firmado — tienes un Data Processing Agreement firmado con el proveedor de IA.
• Residencia de datos confirmada — los datos se quedan en la UE, o has documentado las salvaguardas adecuadas para transferencias fuera de ella.
• Opt-out de entrenamiento activo — tus datos no se usan para entrenar los modelos del proveedor. Confirmado por escrito.
• Usuarios informados — tu política de privacidad menciona el procesamiento con IA. Si los usuarios interactúan directamente con la funcionalidad de IA, hay una divulgación visible (obligación de transparencia del EU AI Act).
• Log de auditoría existente — para cada llamada a la IA: ID de usuario, funcionalidad, hash del input (no el input en sí), modelo, base legal, marca temporal. Duradero, no logs de aplicación.
• Consentimiento verificado antes de llamadas a la IA — si el consentimiento es tu base legal, se verifica antes de cada llamada. La retirada del consentimiento se respeta inmediatamente.
• Clasificación EU AI Act documentada — has evaluado tu sistema como riesgo limitado (o superior) y has escrito por qué. Un auditor necesita ver el razonamiento, no solo la conclusión.

Integración (Artículo 6)

Las funcionalidades de IA añadidas a sistemas existentes deben ser enriquecimientos opcionales, no dependencias duras.

• La IA se ejecuta de forma asíncrona — la petición principal devuelve inmediatamente. El enriquecimiento con IA ocurre en segundo plano. Los usuarios no se quedan bloqueados esperando al modelo.
• Feature flag controla el despliegue — hay un interruptor para activar o desactivar la funcionalidad de IA sin desplegar. Soporta despliegue por porcentaje.
• Las columnas generadas por IA son nullable — no existe ningún campo requerido de IA en una tabla que tenía datos antes de construir la funcionalidad. Las filas existentes sin datos de IA se manejan correctamente.
• La respuesta de la API comunica disponibilidad — las respuestas incluyen un campo como AiAvailable o AiSummaryAvailable. Los clientes usan esto para decidir qué mostrar — no un null check en el campo de contenido.
• Estrategia de backfill existente — tienes un plan (y código) para enriquecer datos existentes. Se ejecuta en lotes con delays. No bloquea tablas ni machaca la API de IA.

Testing (Artículo 7)

Tres capas. Cada una responde a una pregunta diferente. Las tres deben existir.

• Tests unitarios hacen mock de la IA — tu lógica de aplicación se testea sin llamar al modelo real. El controlador, el enricher, el middleware y otros componentes tienen tests que inyectan un IAiSummaryService falso.
• Tests de integración cubren caminos de fallo — hay tests usando un fake HTTP handler (503, timeout) que confirman que el circuit breaker se abre, los reintentos paran, y se devuelve null.
• Tests de eval existen y se ejecutan en un horario — tienes un conjunto de inputs de referencia con criterios de calidad (no output exacto). Se ejecutan semanalmente o antes de cada release. Detectan regresiones del modelo.
• Criterios de eval explícitos — cada caso de eval define longitud mínima, longitud máxima, frases prohibidas y keywords esperadas. El listón está documentado, no implícito.
• Tests de eval separados del CI — no se ejecutan en cada push. Tienen su propio paso de pipeline, con credenciales reales, en un horario.

Las Dos Preguntas Que Más Importan

Puedes leer cada punto de arriba y aún así no pillar lo importante. Así que después del checklist, hazte estas dos preguntas:

Si el proveedor de IA se cae ahora mismo, ¿qué ven los usuarios?

La respuesta debería ser: un mensaje diciendo que la funcionalidad de IA está temporalmente no disponible. Todo lo demás funciona normal. Si la respuesta es “un error 500” o “la página entera se rompe”, tienes trabajo de resiliencia pendiente.

Si un usuario en la UE te pregunta qué datos enviaste a la IA sobre él, ¿qué le dices?

La respuesta debería ser: miras el log de auditoría, consultas por ID de usuario, y le das una lista de marcas temporales, funcionalidades y hashes de input. Si la respuesta es “no estoy seguro” o “no registramos eso”, tienes trabajo de compliance pendiente.

Todo lo demás en el checklist apoya estas dos respuestas. Construye para ellas y el resto viene solo.

Lanzar No Es el Final

Una cosa más antes de lanzar.

Las funcionalidades de IA no son de configurar y olvidar. El modelo se actualiza silenciosamente. Los patrones de uso cambian. Los costes se desvían. Los requisitos de compliance evolucionan. El circuit breaker que configuraste en enero puede estar mal para tu tráfico en junio.

Los patrones de esta serie — métricas, evals, logs de auditoría, feature flags — no son solo para el lanzamiento. Son la capa de mantenimiento continuo que te mantiene en control después del lanzamiento. Revisa los resultados de eval semanalmente. Revisa el gráfico de costes mensualmente. Revisa la documentación de compliance cuando añadas una nueva fuente de datos.

La brecha del artículo 1 — entre lo que funciona en la demo y lo que funciona en producción — no se cierra permanentemente. Hay que mantenerla. El checklist te lleva al lanzamiento. La monitorización te mantiene ahí.

Lo Que Viene Después

Has lanzado la funcionalidad de IA. Es resiliente, observable, con costes controlados, cumple con compliance, está integrada y testeada.

Ahora surge una pregunta diferente e interesante: ¿cómo construyes mejor con IA? No solo cómo ejecutas IA en producción — sino cómo usas la IA como herramienta en tu propio proceso de desarrollo. Prompting estructurado, diseño asistido por IA, mantener la salida de la IA consistente y verificable.

De eso va una nueva serie que estoy escribiendo — ATLAS + GOTCHA. Donde esta serie se centra en el sistema alrededor de la IA, ATLAS + GOTCHA se centra en la metodología de desarrollo — cómo arquitectos e ingenieros pueden trabajar con herramientas de IA de forma estructurada y repetible.

Si esta serie te ha resultado útil, esa continúa donde esta termina. (Actualización: la serie ATLAS + GOTCHA ya está publicada.)

---

Si esta serie te ayuda, considera invitarme a un café.

Este es el artículo 8 de la serie AI in Production — el checklist completo de preparación para producción de funcionalidades de IA en sistemas enterprise.