La IA distribuye las decisiones. La responsabilidad todavía se gestiona como si las tomara una sola persona. En las empresas tecnológicas españolas, los fallos con inteligencia artificial se siguen tratando igual que los fallos técnicos de siempre. Eso ya no funciona: buscar un culpable único es la respuesta más rápida y la menos útil.
📌 Que la responsabilidad sea compartida no quiere decir que sea de nadie. Quiere decir que hay que gestionarla de otra manera.
📌 El aprendizaje real después de un incidente con IA exige construir una narrativa colectiva, no señalar a alguien y seguir adelante.
📌 Las organizaciones que van a sobrevivir a esta transición son las que convierten cada fallo en una conversación, no en un expediente.
Lo que aprendí cuando el sistema hizo exactamente lo que se suponía que debía hacer
He trabajado con equipos que usaban herramientas de monitorización automatizada en parques eólicos. Sistemas que recogían datos, interpretaban señales y generaban alertas. Cuando el sistema avisaba y el técnico no actuaba, la pregunta era inevitable: ¿quién había fallado?
¿El técnico que ignoró la alerta? ¿El responsable de operaciones que no había definido el protocolo de respuesta? Ahí solía quedarse el análisis. En la práctica, encontrábamos al eslabón más visible y ahí cerrábamos el asunto.
François-Xavier de Vaujany y Aurélie Leclercq-Vandelannoitte han estudiado este problema y lo han publicado en MIT Sloan Management Review. Lo llaman responsabilidad narrativa. Y proponen tres movimientos para hacerlo real en organizaciones donde la IA ya toma decisiones.
Boeing: cuando destituir al CEO no cambia nada
En 2018 y 2019, dos accidentes del Boeing 737 MAX mataron a 346 personas. La respuesta fue rápida: el CEO Dennis Muilenburg fue destituido. Pero los problemas de fondo —los de calidad, los de cultura, los de presión comercial sobre los procesos de seguridad— siguieron ahí. En 2024, una puerta de emergencia salió volando en pleno vuelo de otro 737 MAX. Y se fue otro CEO.
Despedir a una persona raramente resuelve las causas reales de un fallo organizativo.
Con la IA, la cadena de decisiones es más larga, más opaca y más distribuida. El culpable único es una ficción útil para cerrar el caso.
Los tres movimientos para gestionar la responsabilidad con IA en empresas tecnológicas e industriales
El estudio de Vaujany y Leclercq-Vandelannoitte propone tres palancas concretas. A continuación, cómo funciona cada una en el contexto de las empresas tecnológicas e industriales españolas.
1. Reconstruir la historia real: el postmórtem técnico solo cuenta la mitad
Cuando algo sale mal con un sistema de IA, el análisis suele ser técnico. Se mira el log, se identifica el error, se actualiza el modelo. Se cierra el ticket.
Lo que ese análisis casi nunca recoge es otra cosa: por qué no se cuestionó el modelo antes de lanzarlo, o quién sabía que había un problema y prefirió no decirlo.
Cuando Google lanzó Gemini en 2024 y produjo imágenes históricamente inexactas, publicó una explicación técnica detallada y el CEO se comprometió a cambios estructurales. Algo se hizo bien ahí. Pero lo que no apareció en ningún informe fue la presión para lanzar antes que los rivales, las pruebas que se acortaron, los riesgos que había encima de la mesa y se ignoraron. Si eso no entra en el análisis, el patrón se repite con el siguiente producto.
En las empresas de ingeniería española que ya usan IA, no se suele preguntar por qué la organización permitió el fallo. Solo por qué falló el sistema.
💡 Un postmórtem que solo analiza el sistema no cambia nada. El aprendizaje real aparece cuando se pregunta qué decisiones humanas y organizativas hicieron posible el fallo.
2. Distribuir la propiedad sin diluirla: que todos respondan no significa que nadie responda
Cuando se dice que la responsabilidad es colectiva, muchas organizaciones lo interpretan como que nadie tiene que asumir nada en particular. Es exactamente lo contrario de lo que el concepto propone.
En la aviación lleva décadas funcionando de otra manera. Air France y KLM convocan paneles con personas de distintas áreas después de cada incidente con automatización. El objetivo es entender qué pasó de verdad, no encontrar a quién echarle la culpa. Y ha tenido un impacto demostrable en la seguridad del sector.
En las empresas tecnológicas españolas el patrón es diferente:
- Ingeniería señala la configuración defectuosa.
- Producto dice que los requisitos estaban bien definidos.
- Operaciones alega que ejecutó lo que le pedían.
- Dirección encuentra al eslabón más visible y cierra el asunto.
Cada área aprende lo mínimo para cubrirse. Nadie aprende lo que necesita para no repetirlo.
💡 La responsabilidad distribuida solo funciona si señalar problemas no tiene coste personal. Sin ese entorno, la distribución se convierte en dilución.
3. Incorporar la reflexión como rutina: que el aprendizaje no dependa de los incidentes
Hay equipos técnicos que llevan meses trabajando con un sistema de IA sin que nadie haya revisado si lo que se decidió al principio sigue teniendo sentido. El sistema funciona, genera decisiones, y la única señal de que algo va mal es cuando el problema ya está encima de la mesa.
En muchas organizaciones tecnológicas, la prioridad es resolver lo que falla. Pensar en lo que podría fallar antes de que ocurra casi nunca es prioritario.
ING Bank ha integrado sesiones de revisión en sus rutinas de trabajo. Después de cada ciclo, los equipos discuten qué fue bien, qué mejorar y qué aprendieron de los últimos incidentes. No esperan a que algo falle para tener esa conversación.
En las empresas tecnológicas españolas que trabajan con IA, esto prácticamente no existe. Cuando llega el problema, la reflexión se hace deprisa y con el foco puesto en apagar el fuego. Y lo que se aprende así tiene una vida muy corta.
💡 El aprendizaje que solo aparece después de los fallos llega tarde y dura poco. La reflexión sobre cómo funciona la IA en la organización tiene que ser parte de la operación normal.
¿Tu organización tiene estos patrones?
☐ Cuando un sistema de IA falla, ¿el análisis incluye los factores humanos y organizativos que lo hicieron posible, o se queda en el diagnóstico técnico?
☐ Cuando alguien señala un problema con un sistema de IA, ¿eso tiene coste personal para quien lo señala?
☐ ¿Los equipos que trabajan con IA revisan de forma habitual si lo que se decidió al principio sigue siendo válido, o esa revisión solo ocurre cuando ya hay un problema?
☐ ¿Existe en tu organización un proceso de postmórtem que vaya más allá del análisis técnico?
☐ ¿Saben tus equipos qué parte de la decisión asumieron ellos y qué parte tomó el sistema?
☐ ¿Se habla abiertamente de los fallos con IA, o los incidentes se cierran sin que el aprendizaje se comparta?
☐ ¿Hay algún espacio recurrente —no puntual— para revisar cómo está funcionando la IA en la operación?
¿Quieres saberlo con certeza?
En HR4TechTeam trabajo con empresas tecnológicas e industriales españolas para entender qué pasa realmente cuando un sistema de IA falla y quién acaba cargando con ello. Si te has reconocido en alguno de estos patrones, tiene sentido hablarlo.
🔍 Tengo un diagnóstico inicial. Si quieres ver un ejemplo de lo que recibirías, mándame un mensaje privado.
💙 Si quieres explorar cómo abordarlo, puedes encontrarme en hr4techteam.com/coaching-ejecutivo
💬 Recursos y herramientas para equipos técnicos en payhip.com/SkillCraftTeam
🔁 ¿Reconoces alguno de estos patrones en tu organización? Cuéntalo en los comentarios.
Referencia académica Vaujany, F.-X. de & Leclercq-Vandelannoitte, A. (2026). Rethink Responsibility in the Age of AI. MIT Sloan Management Review, abril de 2026.
Nota: si lo que buscas es ayuda concreta para implantar IA en tu empresa, en KasandrIA tienes diagnóstico, formación e implantación adaptados a pymes.
0 comentarios