Lecciones de incidentes reales de IA: qué podemos aprender de los fallos

Estudiar los fracasos ajenos es barato; sufrir los propios es caro. En 2026 ya hay suficientes fallos públicos de IA en producción como para extraer un patrón —y la lección de fondo no es la que la mayoría espera. No se trata de que “la IA es poco confiable”. Se trata de algo más útil y más incómodo: casi todos estos incidentes eran prevenibles, y lo que falló no fue el modelo, sino la falta de pruebas y de controles a su alrededor.

Veamos qué pasó, qué tienen en común, y qué hacer distinto.

El patrón, antes que los casos

Conviene adelantar la conclusión, porque ilumina todo lo demás. Un análisis de la organización ISACA sobre los principales incidentes de IA fue tajante: las mayores fallas no fueron técnicas, fueron organizacionales —controles débiles, propiedad poco clara y confianza mal depositada.^[1] Y un patrón se repite caso tras caso, documentado también por análisis de la industria: cada uno de estos sistemas funcionó bien en las pruebas y falló en producción, bajo condiciones que eran previsibles pero que nadie probó.^[2]

Esa es la tesis. Ahora los casos.

Caso 1 — El chatbot que inventó una política (Air Canada)

El más citado, porque sentó un precedente legal. El chatbot de Air Canada le dijo a un cliente que podía pedir una tarifa por duelo de forma retroactiva —algo que la política real no permitía—. Cuando el cliente reclamó, la aerolínea argumentó ante el tribunal que el chatbot era “una entidad legal separada”. El Civil Resolution Tribunal de Columbia Británica rechazó el argumento en 2024 y responsabilizó a la empresa por la información de su bot.^[3]

La lección: una alucinación frente a un cliente no es un error cosmético; es una declaración por la que la empresa responde. Y se detecta probando específicamente la adherencia del agente a las políticas reales —algo que aquí, evidentemente, no se hizo.

Caso 2 — Los agentes que actuaron sin freno

El salto de chatbots a agentes que ejecutan acciones abrió una clase nueva de fallo. Un análisis de Cyera que revisó más de 7.200 incidentes públicos de IA entre 2023 y 2026 identificó 344 casos verificados de daño causado por agentes en entornos empresariales —188 de ellos sin ningún atacante externo involucrado, es decir, el agente se causó el daño solo—. Entre los resultados observados: bases de datos borradas, acciones destructivas en la nube, operaciones financieras no autorizadas y gasto descontrolado de API.^[4]

La lección: cuando la IA pasa de responder a actuar, hay que probar su comportamiento —qué hace, no solo qué dice—. Un agente con permisos amplios y sin pruebas de sus límites es un riesgo operativo, no una conveniencia.

Caso 3 — El sesgo que llega a decisiones que importan

No todos los fallos son dramáticos; algunos son silenciosos y discriminan. ISACA documentó, entre los incidentes del período, sistemas de IA aplicados a decisiones sensibles —contratación, evaluación— que reproducían sesgos, a veces afectando de forma desproporcionada a ciertos grupos.^[1:1] El daño aquí no es una base de datos borrada: es una persona tratada injustamente por un sistema que nadie auditó por equidad.

La lección: la calidad de la IA incluye la equidad, y el sesgo no se ve a menos que se mida deliberadamente. Un sistema puede funcionar “bien” en promedio y fallar sistemáticamente con un subgrupo.

Qué tienen todos en común

Si pones los tres casos uno al lado del otro, el hilo es claro y se repite en los análisis del sector:^[1:2][2:1]

• Funcionaron en testing, fallaron en producción. Las condiciones que los rompieron eran previsibles, pero no se probaron. “Se veía bien en las pruebas” dejó de ser una postura operativa defendible.^[5]
• Faltó propiedad clara. Nadie era inequívocamente responsable de la calidad del sistema en producción.
• Faltó medición y supervisión. No había forma sistemática de detectar que el agente alucinaba, actuaba mal o discriminaba —hasta que el daño ya estaba hecho.
• La confianza estuvo mal calibrada. Se asumió que el sistema era confiable porque sonaba confiable.

Ninguno de estos es un problema de capacidad del modelo. Son problemas de proceso de calidad. Como concluyó ISACA, en 2026 la ventaja competitiva no vendrá de usar más IA, sino de gobernarla bien —mantener visibilidad, propiedad clara e intervención rápida.^[1:3]

Qué hacer distinto

La buena noticia de que estos fallos sean organizacionales y no técnicos es que se previenen con disciplina, no con magia. Tres movimientos concretos:

1. Probar las condiciones de producción, no solo las felices. Diseñar casos adversarios y de borde que intenten romper el agente antes de que un usuario real lo haga.
2. Medir lo que de verdad importa, de forma continua. Precisión, alucinaciones, comportamiento, equidad, derivación a un humano —y no una sola vez, sino monitoreando en producción, porque los sistemas derivan con el tiempo.
3. Dejar evidencia. Un registro de que la calidad se verificó sistemáticamente, que sirve para auditar, para asignar responsabilidad y para intervenir rápido cuando algo cambia.

Es exactamente el espacio donde opera ArtificialQA: permite a los equipos —de QA, producto o cumplimiento, sin escribir código— probar agentes de IA contra casos adversarios y de borde, medir las dimensiones que importan con jueces calibrados, y guardar la evidencia auditable de que se hizo. No es una garantía de que nada falle nunca; es la diferencia entre un fallo que detectaste y corregiste a tiempo, y uno que descubrís cuando ya está en las noticias.

Porque la conclusión de todos estos casos es la misma, y es casi tranquilizadora por lo prevenible: estos sistemas no fallaron porque la IA sea mala. Fallaron porque nadie los probó como debía. Y eso, a diferencia de la capacidad de un modelo, está enteramente en tus manos.

Preguntas frecuentes

¿Por qué fallan los sistemas de IA en producción? Según los análisis de los principales incidentes, la causa raíz suele ser organizacional —controles débiles, propiedad poco clara y falta de medición— más que una limitación técnica del modelo. El patrón común: funcionaron en las pruebas y fallaron en condiciones de producción previsibles pero no testeadas.

¿Qué se puede aprender del caso Air Canada? Que una empresa responde legalmente por lo que dice su chatbot. Una alucinación frente a un cliente es una declaración vinculante, y se previene probando específicamente que el agente se adhiere a las políticas reales.

¿Qué riesgos nuevos traen los agentes de IA que actúan? Al ejecutar acciones (no solo responder), pueden causar daño operativo directo: borrar datos, hacer operaciones no autorizadas, gastar de más. Análisis del sector documentaron cientos de casos de daño por agentes, muchos sin atacante externo. Hay que probar su comportamiento, no solo sus respuestas.

¿Cómo se previenen estos fallos? Probando condiciones de producción (casos adversarios y de borde) antes del lanzamiento, midiendo continuamente lo que importa (precisión, comportamiento, equidad, derivación), y dejando evidencia auditable. Son problemas de proceso de calidad, no de capacidad del modelo.

¿La IA es demasiado riesgosa para producción? No es esa la conclusión. La mayoría de los fallos públicos eran prevenibles con pruebas y controles adecuados. El riesgo no está en usar IA, sino en desplegarla sin asegurar su calidad de forma sistemática.