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.
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, lo que ilustra un problema más profundo: el equipo nunca había validado que el guardrail seguía funcionando tras cambios del modelo.
La lección que se extrae con claridad es que los guardrails necesitan sus propias pruebas sintéticas periódicas que verifiquen su funcionamiento extremo a extremo, no solo la activación del componente. Un guardrail que no recibe tráfico que debería rechazar no está demostrando que funciona; solo que nadie lo está probando. 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 y tuvo evidencia para exigir al proveedor mayor transparencia sobre los cambios.
La lección es que cualquier sistema en producción con un modelo externo necesita su propio banco de evaluaciones ejecutado regularmente, con respuestas esperadas validadas por humanos expertos, y alertas cuando la tasa de coincidencia cae por debajo de un umbral. Sin este mecanismo, el equipo depende de la buena voluntad del proveedor para ser notificado de cambios relevantes, y la experiencia demuestra que esa notificación es tardía e incompleta.
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, y cambiar de proveedor requería rediseño no trivial de buena parte del sistema. El failover técnicamente existía pero era casi inútil.
La lección aquí es doble. Primera, probar regularmente el failover con tráfico real, no solo verificar que las tuberías están conectadas. Segunda, 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. Es trabajo extra durante el desarrollo pero evita la trampa de descubrir la dependencia oculta en el peor momento posible.
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 o tardía 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. Son problemas conocidos desde hace décadas, pero el equipo no los anticipó bien en el contexto de sistemas con componentes de IA porque el monitoring estándar no cubría los patrones específicos de estos sistemas.
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 que se presentaba a los usuarios como lentitud general del sistema. Nadie había revisado los timeouts específicos de IA durante los ejercicios habituales de capacity planning, porque no encajaban en la mentalidad de sistema tradicional.
La lección es que los sistemas con componentes de IA no son una categoría separada de la ingeniería de fiabilidad; son sistemas que requieren aplicar prácticas conocidas a componentes nuevos. Circuit breakers, retries con backoff exponencial, monitoring específico de llamadas a APIs externas, dashboards que combinen métricas de IA con métricas de sistema tradicionales. Nada de esto es nuevo conceptualmente, pero muchos equipos están reaprendiendo estas lecciones en el contexto de la IA, y el aprendizaje sale caro cuando se hace en producción.
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, porque los límites externos protegen al proveedor pero no necesariamente a los usuarios del sistema.
Otra lección más general es que 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. Este ejercicio, realizado antes de poner el sistema en producción, evita muchas sorpresas que los postmortems documentan una y otra vez.
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 entre los equipos con experiencia operativa. 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. Estos procedimientos ya no se improvisan en el momento; las empresas maduras los han escrito y los ejercitan con game days periódicos.
Contratos con proveedores que incluyen cláusulas sobre comunicación de cambios relevantes, sobre SLAs diferenciados según criticidad del uso y sobre acceso a métricas de comportamiento del modelo. Los contratos genéricos de 2023 no tenían estos términos; los de 2026 los incluyen cada vez con más frecuencia porque los equipos han aprendido qué preguntar tras los postmortems ajenos.
Cuándo compensa escribir postmortems públicos
No todas las empresas pueden o quieren publicar postmortems, pero las que lo hacen ganan reputación técnica y reciben retroalimentación valiosa de otros equipos. Compensa cuando el incidente tiene lecciones generalizables que ayuden al ecosistema, cuando la empresa puede describir el problema sin comprometer seguridad o información confidencial, y cuando hay voluntad interna de aprender en público, que no todas las culturas toleran.
Para quienes no publican, al menos escribir postmortems internos rigurosos es una disciplina que separa a los equipos que aprenden de los que repiten. El formato clásico de incidente, impacto, causa raíz, cronología, lecciones y acciones sigue siendo útil en el contexto de IA, con la adición de secciones específicas sobre versión del modelo, prompts afectados, herramientas involucradas y datos de evaluación relevantes.
Mi lectura
La cultura de postmortems en sistemas con IA ha madurado notablemente entre 2025 y 2026. Todavía es desigual según el equipo, y sigue habiendo empresas que publican descripciones vagas que evitan entrar en detalles técnicos útiles, pero el nivel general ha subido. 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 que los que solo tropiezan con sus propios incidentes.
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 principios de observabilidad, contención de fallos, defensa en profundidad y aprendizaje sistemático siguen siendo válidos, y los equipos que los aplican con rigor tienen menos incidentes y mejores postmortems que los que todavía tratan la IA como terreno especial donde las reglas de siempre no se aplican. 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.
