Postmortems de incidentes con IA: lo que nos han enseñado

Actualizado: 2026-05-15

Durante el último año, cada vez más equipos que operan sistemas con IA en producción han empezado a publicar postmortems detallados de sus incidentes. La práctica, heredada de la cultura SRE clásica, se está consolidando en el nuevo terreno de los LLMs y sistemas agénticos, y la cosecha de 2025 más los primeros meses de 2026 ya permite hacer una lectura ordenada de los patrones que se repiten. Vale la pena destilarlos porque muchos equipos están a punto de cometer los mismos errores que otros han documentado con detalle.

Puntos clave

• Los guardrails necesitan sus propias pruebas sintéticas periódicas, no solo la activación del componente.
• La deriva silenciosa del modelo solo se detecta con un banco de evaluaciones propias ejecutado con regularidad.
• La dependencia de proveedor no es solo de disponibilidad; es de comportamiento exacto del modelo.
• Los incidentes clásicos de operación (timeouts, memory leaks, certificados) se manifiestan de forma novedosa en sistemas con IA.
• Los agentes con uso de herramientas necesitan límites de tasa propios por herramienta, no solo globales.

Patrón uno: guardrails que fallan sin ruido

El patrón más repetido en los postmortems recientes es el fallo silencioso de guardrails. Equipos que construyeron sistemas con validación de entradas, filtrado de salidas, detección de prompt injection y contención de llamadas a herramientas descubrieron, a veces tras meses, que alguno de esos mecanismos había dejado de funcionar sin generar alerta. El patrón típico es una actualización del modelo base por parte del proveedor que cambia ligeramente el comportamiento, rompe la heurística del guardrail, y nadie se entera porque la métrica observable no cambia visiblemente.

Un caso documentado involucró un sistema de atención al cliente donde el filtro de datos personales en las salidas dependía de una detección regex que asumía ciertos formatos en la respuesta del modelo. Cuando el proveedor actualizó a una versión que reformateó ligeramente algunas salidas, el regex empezó a dejar pasar información sensible durante semanas. La detección final llegó por una auditoría externa, no por el sistema de monitorización.

La lección: los guardrails necesitan sus propias pruebas sintéticas periódicas que verifiquen su funcionamiento extremo a extremo, no solo la activación del componente. Los equipos maduros han introducido tests de guardrail que inyectan entradas adversarias conocidas en intervalos regulares y verifican que el filtro sigue bloqueándolas.

Patrón dos: deriva silenciosa del modelo

Otro patrón recurrente es lo que varios postmortems llaman deriva silenciosa. El modelo base, operado por un proveedor externo, cambia de comportamiento de forma sutil sin que el equipo lo detecte hasta que algún usuario avispado lo reporta. Los cambios pueden ser de estilo, de longitud de respuesta, de tolerancia a ciertos tipos de entradas, o de capacidad real en tareas complejas. Rara vez son catastróficos, pero degradan la calidad del sistema durante el tiempo que pasan desapercibidos.

Un postmortem publicado por una empresa de asistentes para médicos describe exactamente este fenómeno. Durante aproximadamente seis semanas, la precisión de las respuestas en un subconjunto de preguntas clínicas degradó gradualmente tras una actualización menor del modelo. El sistema seguía funcionando, los usuarios no habían cambiado sus patrones de uso, y las métricas básicas de disponibilidad no mostraban nada. Solo al introducir un banco de preguntas de evaluación automatizada con respuestas esperadas, el equipo detectó la regresión.

La lección: cualquier sistema en producción con un modelo externo necesita su propio banco de evaluaciones ejecutado regularmente. Sin este mecanismo, el equipo depende de la buena voluntad del proveedor para ser notificado de cambios relevantes. Para profundizar en cómo construir ese banco, ver evaluaciones de agentes en producción.

Patrón tres: dependencia oculta del proveedor

Varios postmortems han destacado cómo equipos que creían tener una dependencia manejable del proveedor de modelos descubrieron, durante un incidente, que la dependencia era mucho más profunda de lo que asumían. Un caso particularmente instructivo ocurrió cuando un proveedor tuvo una caída prolongada y un equipo que había diseñado failover hacia un proveedor alternativo descubrió que su sistema de prompts estaba tan afinado al comportamiento específico del modelo caído que el modelo alternativo producía resultados significativamente peores.

La dependencia no era solo de disponibilidad; era de comportamiento exacto. Los prompts, los patrones de interacción, las expectativas de formato y los criterios de evaluación habían evolucionado durante meses para encajar con las peculiaridades de un modelo concreto.

La lección aquí es doble:

1. Probar regularmente el failover con tráfico real, no solo verificar que las tuberías están conectadas.
2. Diseñar el sistema para que funcione razonablemente bien con al menos dos modelos diferentes desde el inicio, lo que impone disciplina de prompts menos dependientes de peculiaridades específicas.

Patrón cuatro: operación clásica agravada por novedad

Una parte considerable de los postmortems recientes no son en realidad incidentes de IA, sino incidentes de operación clásica que se manifestaron de forma novedosa porque la capa de IA enmascaraba las señales:

• Fugas de memoria en workers que procesaban entradas grandes.
• Problemas de conexión con bases de datos.
• Certificados expirados.
• Despliegues mal coordinados.
• Secretos rotados sin actualizar.

Un caso concreto involucró un timeout configurado de forma muy corta en el cliente de un modelo externo. Durante condiciones normales funcionaba, pero en momentos de carga alta del proveedor, los timeouts disparaban reintentos que saturaban recursos internos y generaban cascada de errores.

La lección: los sistemas con componentes de IA no son una categoría separada de la ingeniería de fiabilidad. Los principios de observabilidad, contención de fallos, defensa en profundidad y aprendizaje sistemático siguen siendo válidos. Circuit breakers, retries con backoff exponencial, monitoring específico de llamadas a APIs externas, nada de esto es conceptualmente nuevo, pero muchos equipos están reaprendiendo estas lecciones en el contexto de la IA.

Patrón cinco: uso de herramientas con efectos inesperados

Los sistemas agénticos con uso de herramientas han producido una categoría propia de postmortems particularmente interesante. El patrón típico es un agente que, en condiciones normales, invoca herramientas externas de forma razonable, pero bajo ciertas entradas adversas o inesperadas entra en bucles, invoca herramientas con parámetros dañinos, o combina varias herramientas en secuencias que producen efectos secundarios no previstos.

Un caso documentado en un postmortem involucró un agente con acceso a una API de envío de correos que, tras una entrada específica, invocó la herramienta repetidamente enviando cientos de correos a usuarios antes de que el límite de tasa del sistema externo cortara la cadena. La lección inmediata fue que los agentes necesitan límites de tasa propios en cada herramienta, no solo en el sistema global.

Otra lección más general: cada herramienta accesible al agente tiene que tener su propio modelo de amenazas explícito. No basta con pensar el sistema como un todo; hay que enumerar qué puede hacer cada herramienta, qué efectos secundarios tiene, qué reversibilidad ofrece y qué controles aplican. Esta lección es central también en la gobernanza de agentes en empresa.

Qué prácticas están adoptando los equipos maduros

A partir de la acumulación de postmortems, varias prácticas concretas se están consolidando:

• Evaluaciones sintéticas continuas contra bancos de referencia, tanto para verificar comportamiento del modelo base como para probar guardrails y herramientas.
• Separación clara entre métricas de infraestructura, métricas de modelo y métricas de producto, con dashboards que permiten correlacionar incidentes a través de las tres capas.
• Procedimientos de respuesta a incidentes específicos para IA, con runbooks que cubren escenarios como deriva del modelo detectada por evaluación, saturación del proveedor externo, fallo de guardrail, comportamiento anómalo del agente.
• Contratos con proveedores que incluyen cláusulas sobre comunicación de cambios relevantes, SLAs diferenciados según criticidad y acceso a métricas de comportamiento del modelo.

Mi lectura

La cultura de postmortems en sistemas con IA ha madurado notablemente. La comunidad de ingeniería tiene ya un corpus de casos documentados suficiente para aprender sin necesidad de cometer cada error por primera vez, y los equipos que leen sistemáticamente estos postmortems están claramente mejor preparados.

La lección transversal más importante es que la IA en producción es ingeniería de fiabilidad aplicada a componentes nuevos, no una disciplina completamente distinta. Los equipos que aplican con rigor los principios clásicos, observabilidad, contención de fallos, defensa en profundidad, aprendizaje sistemático, tienen menos incidentes y mejores postmortems. No hay atajos: lo que funcionó durante décadas para sistemas críticos sigue funcionando, solo que ahora hay más componentes que requieren atención específica.