Air Canada perdió en los tribunales por su chatbot. El modelo estaba bien. La gobernanza no.

Imagina una aerolínea que despliega un chatbot para atender consultas de clientes, lo observa inventar con total confianza una política de descuentos que no existe, y luego argumenta ante un tribunal que el chatbot era básicamente su propia entidad y, por lo tanto, no era realmente su problema. Ese argumento no funcionó. Air Canada fue declarada responsable de un reembolso que su chatbot había prometido bajo una política de tarifas por duelo que el chatbot simplemente se había inventado. El término técnico para esto es alucinación. El término legal y operativo para lo que vino después es: completamente evitable. Y la lección más profunda, la que aplica a cada equipo que despliega IA en un rol de atención al cliente, es que el chatbot hizo exactamente lo que hacen los modelos de lenguaje. El fallo ocurrió un nivel más arriba, en la ausencia de cualquier estructura de gobernanza para detectarlo.

Cuando el modelo funciona bien y todo sigue saliendo mal

El caso de Air Canada es una ilustración clara de un patrón que el análisis de NineTwoThree sobre los grandes fallos de IA documenta directamente: la brecha entre el entusiasmo por la IA y su implementación es precisamente donde vive el daño real. Según ese análisis, la gran mayoría de las iniciativas corporativas de IA en 2025 no llegaron a producción ni generaron flujo de caja positivo. El chatbot de Air Canada, siendo justos, sí llegó a producción. Solo que generó flujo de caja negativo al perder un fallo judicial, lo que lo coloca en la categoría más instructiva de fracasos: los que te enseñan algo específico.

El informe "Five AI Fails" de MITRE Corporation ofrece un enfoque que los profesionales deberían guardar en algún lugar donde realmente lo vayan a leer. Los sistemas de IA no son módulos independientes, argumenta MITRE, sino partes de un ecosistema complejo que interactúa con el comportamiento humano y la toma de decisiones, e influye en ellos. Medir el sistema solo a nivel del modelo pasa por alto el impacto más amplio que tiene sobre las personas e instituciones que lo rodean. Un chatbot que produce respuestas erróneas con total seguridad es una observación a nivel de modelo. Una empresa que comparece ante un tribunal porque nadie revisó qué tenía permitido prometer el chatbot es un fallo a nivel de gobernanza. Son problemas categóricamente distintos, y confundirlos es la razón por la que los equipos terminan sorprendidos.

La taxonomía de lo que realmente falla

Investigadores de la Universidad Ss. Cirilo y Metodio y del Metropolitan College de la Universidad de Boston publicaron recientemente una taxonomía basada en datos de fallos reales de IA, a partir de un corpus de 9.705 artículos periodísticos sobre incidentes de IA, extrayendo acciones de mitigación explícitas de 6.893 de esos textos. Su artículo en arXiv concluye que los fallos de los LLM en flujos de trabajo de alto riesgo se propagan más allá de los errores aislados del modelo hacia fallos sistémicos que generan exposición legal, daño reputacional y pérdidas económicas materiales.

La palabra clave aquí es sistémico. El modelo cometió un error; el sistema no tenía ningún interruptor de seguridad.

Un estudio separado en arXiv sobre desarrolladores que usan estos modelos como base, realizado mediante entrevistas y encuestas con métodos mixtos, encontró que los profesionales que construyen sobre modelos preentrenados frecuentemente subestiman modos de fallo como la filtración de datos y los resultados sesgados, y que estos riesgos a veces se pasan por alto inadvertidamente en los despliegues reales en lugar de mitigarse activamente.

Ese "inadvertidamente" hace un trabajo significativo. No es malicia. Es el resultado natural de equipos que optimizan para velocidad de lanzamiento y tratan la gobernanza como una preocupación posterior al despliegue.

La brecha de investigación que empeora todo

Aquí hay un hecho estructural incómodo. Un artículo de arXiv que analiza 9.439 artículos de investigación sobre IA generativa publicados entre enero de 2020 y marzo de 2025, comparando resultados de las principales empresas de IA (Anthropic, Google DeepMind, Meta, Microsoft y OpenAI) y universidades líderes (CMU, MIT, NYU, Stanford, UC Berkeley y la Universidad de Washington), encontró que la investigación corporativa en IA está cada vez más concentrada en el trabajo previo al despliegue, específicamente en la alineación de modelos y en pruebas y evaluación. La atención a los problemas en la fase de despliegue, como el sesgo del modelo, ha disminuido de hecho.

El artículo identifica brechas significativas de investigación en dominios de despliegue de alto riesgo, incluyendo salud, finanzas, alucinaciones y derechos de autor, y recomienda ampliar el acceso de investigadores externos a los datos de despliegue y la observabilidad sistemática de los comportamientos de la IA en el mercado.

Así que las personas que construyen los modelos más capaces están, según sus propios resultados de investigación, prestando menos atención a lo que ocurre después de que esos modelos se lanzan.

El Centro Safra de Ética de Harvard enmarca esto como un patrón más amplio: los fallos de la IA son recordatorios cautelares de los peligros prácticos del desarrollo y despliegue de la IA, y examinarlos sirve como punto de referencia crucial para responsables de políticas, tecnólogos y partes interesadas para identificar riesgos que deberían influir en otras iniciativas de IA.

Puedes leer esto como una observación académica o como una instrucción directa para tu próxima reunión de planificación de sprint. Ambas lecturas son válidas.

Lo que los profesionales pueden hacer en la práctica

El marco de lecciones aprendidas de MITRE propone cuatro respuestas concretas que funcionan bien como lista de verificación para profesionales: ampliar las consideraciones iniciales del proyecto para incluir modos de fallo antes de la primera línea de código de producción; incorporar resiliencia tanto en la IA como en la organización que la rodea; calibrar la confianza en la IA y en los datos de los que depende; y ampliar las formas en que se evalúa el impacto del sistema más allá de las métricas de precisión.

Ninguna de estas requiere un nuevo modelo. Requieren tratar el despliegue como una disciplina de ingeniería con sus propios requisitos, no como una vuelta de victoria tras el entrenamiento.

El análisis de AIMutiple sobre las causas raíz de los fallos de IA añade una perspectiva complementaria: muchos fallos se remontan a objetivos mal alineados, mala calidad de los datos e insuficiente supervisión humana en el proceso, no a la arquitectura del modelo en sí.

Si tu chatbot puede hacer promesas vinculantes a los clientes sin ningún paso de revisión humana, no has desplegado un sistema de IA. Has desplegado una responsabilidad legal.

Para quienes aprenden y se encaminan hacia roles en producción, el caso de Air Canada vale la pena marcarlo como favorito no porque sea escandaloso, sino porque es clarificador. Todo despliegue de IA orientado al cliente necesita una respuesta explícita a tres preguntas antes de lanzarse: qué puede comprometer este sistema en nombre de la organización, quién revisa los resultados de alto riesgo antes de que lleguen a los usuarios, y cuál es la ruta de escalada cuando el modelo se equivoca. Los equipos que respondan esas preguntas en el diseño no tendrán que responderlas ante un tribunal.

Estate atento a los marcos de gobernanza emergentes del calendario de implementación de la Ley de IA de la UE y de los compromisos voluntarios de los principales desarrolladores de IA: la próxima oleada de fallos en producción probablemente involucrará sistemas agénticos con una toma de decisiones aún más autónoma, lo que convierte la capa de gobernanza no en algo deseable sino en el desafío central de ingeniería.

El chatbot de Air Canada solo daba malos consejos. La próxima generación de sistemas actuará en consecuencia.