¿Quién responde cuando la IA toma decisiones?

Imagine que un sistema de IA recomienda rechazar a un proveedor. La persona responsable acepta la recomendación y, semanas después, la organización descubre que se basó en información incompleta. Tecnología señala al proveedor del modelo; el proveedor dice que el cliente definió la configuración; el negocio recuerda que una persona aprobó el resultado; y esa persona explica que siguió al sistema.

El problema no es solo el error de la IA. Es que nadie puede explicar con claridad quién tenía autoridad para decidir, quién debía cuestionar el resultado y quién debía responder por las consecuencias.

La gobernanza de IA empieza ahí. Un sistema puede generar una predicción, clasificación o recomendación e incluso automatizar parte de una decisión. Pero no sustituye la responsabilidad de las personas y funciones que autorizan, utilizan, supervisan y modifican ese sistema. La responsabilidad jurídica dependerá de la jurisdicción y del caso de uso; la responsabilidad organizativa debe definirse antes de que ocurra un incidente.

La automatización puede mover una decisión. No puede mover la obligación de responder por ella.

La IA no ocupa un puesto en el organigrama

Decir que “la IA tomó la decisión” puede describir lo ocurrido técnicamente, pero es una explicación pobre de gobierno. El auditor debería separar tres elementos: la salida del sistema —una puntuación, recomendación o clasificación—; la decisión empresarial —aprobar, rechazar, bloquear o escalar—; y la responsabilidad por esa decisión, incluida la autoridad para aceptarla, cambiarla, detenerla y explicar sus efectos.

El Modelo de las Tres Líneas actualizado por el IIA ayuda a mantener esa separación. La dirección conserva la responsabilidad de gestionar riesgos y operar procesos y controles; las funciones de segunda línea aportan especialización, monitoreo y desafío; y Auditoría Interna proporciona aseguramiento y asesoramiento independientes sin asumir responsabilidad de gestión ni autoridad de decisión.

Por eso, evaluar la gobernanza de IA no significa convertirse en propietario de ella. Auditoría Interna puede cuestionar responsabilidades y controles, pero debería evitar aprobar modelos, aceptar riesgos residuales o decidir si un sistema puede operar cuando después tendrá que proporcionar aseguramiento sobre esas decisiones.

Empiece por la decisión, no por el modelo

Una matriz de responsabilidades puede ayudar, pero la primera pregunta no debería ser “¿quién es el dueño del modelo?”. Una mejor pregunta es: ¿qué decisión empresarial puede influir este sistema y quién tiene autoridad sobre ella?

Rol	Pregunta de responsabilidad	Evidencia útil
Consejo y alta dirección	¿Quién fija límites, apetito de riesgo y escalaciones?	Política, mandatos, actas, criterios de aceptación de riesgo
Propietario del proceso o sistema	¿Quién responde por el uso previsto y el desempeño?	Inventario, aprobación del caso de uso, controles, monitoreo
Supervisor o decisor humano	¿Quién puede cuestionar, anular, detener o escalar?	Instrucciones, formación, revisiones y excepciones
Proveedor y responsable de terceros	¿Qué obligaciones corresponden a cada parte?	Contratos, SLA, documentación, cambios e incidentes

El riesgo aparece cuando una actividad crítica no tiene propietario, varias partes son “responsables” pero nadie posee autoridad final, o el responsable nominal carece de capacidad para actuar.

Una matriz RACI puede ser una buena práctica, aunque no es un requisito universal. Lo importante es que la organización pueda demostrar quién aprobó el uso, quién aceptó el riesgo y quién puede ordenar una corrección o suspensión.

ISO/IEC 42001 convierte los roles en algo auditable

ISO/IEC 42001:2023 trata la responsabilidad como parte del sistema de gestión de la IA. La cláusula 5.3 exige que la alta dirección asegure que las responsabilidades y autoridades de los roles pertinentes estén asignadas y comunicadas. También exige asignar responsabilidad y autoridad para asegurar la conformidad del sistema de gestión y reportar su desempeño a la alta dirección.

El Anexo A refuerza esa lógica con el control de referencia A.3.2 sobre roles y responsabilidades de IA. No es una lista automática que todas las organizaciones deban implantar de forma idéntica: ISO/IEC 42001 utiliza un enfoque basado en riesgos y la organización determina los controles necesarios mediante su tratamiento del riesgo y la declaración de aplicabilidad.

La guía de implementación del Anexo B señala áreas donde suelen requerirse responsabilidades explícitas, como gestión de riesgos, evaluaciones de impacto, seguridad, privacidad, desarrollo, desempeño, calidad de datos, supervisión humana y proveedores. Para Auditoría Interna, una frase genérica como “el equipo de IA es responsable” rara vez demuestra que esas funciones estén realmente cubiertas.

Además, el estándar exige aprobación de la dirección designada para el plan de tratamiento y la aceptación del riesgo residual. La gobernanza, por tanto, no solo distribuye tareas: también define derechos de decisión sobre el riesgo.

La Ley de IA de la UE da contenido a la supervisión humana

La Ley de IA de la Unión Europea distribuye obligaciones entre roles como proveedor y responsable del despliegue. Para determinados sistemas de alto riesgo, el artículo 14 convierte la “supervisión humana” en algo más concreto que colocar a una persona al final del proceso.

La supervisión debe permitir que las personas asignadas comprendan capacidades y limitaciones relevantes, vigilen anomalías, reconozcan el riesgo de confiar automáticamente en la salida, interpreten el resultado y puedan ignorarlo, anularlo, revertirlo, intervenir o detener el sistema cuando corresponda. El artículo 26 exige que el responsable del despliegue asigne esa función a personas con la competencia, formación, autoridad y apoyo necesarios.

Esto ofrece una regla práctica: una persona no constituye un control solo por aparecer en el flujo. Si no dispone de información, tiempo, competencia o autoridad real para cuestionar el sistema, la supervisión puede ser meramente ceremonial.

El artículo 25 también aborda responsabilidades a lo largo de la cadena de valor y contempla circunstancias en las que un distribuidor, importador, responsable del despliegue u otro tercero puede pasar a ser considerado proveedor de un sistema de alto riesgo. Además, prevé acuerdos escritos en determinados escenarios para facilitar información y asistencia entre proveedor y terceros.

A septiembre de 2026, la Ley de IA es aplicable con excepciones, pero las reglas para sistemas de alto riesgo tienen períodos transitorios ampliados. Según la cronología oficial de la Comisión Europea, los casos de uso del Anexo III se aplicarán desde el 2 de diciembre de 2027 y los sistemas integrados en productos del Anexo I desde el 2 de agosto de 2028. Estas disposiciones pueden orientar el diseño de gobierno hoy, pero un auditor no debería concluir incumplimiento legal antes de la fecha aplicable al sistema concreto.

Contratar a un proveedor divide tareas, no borra la responsabilidad

Una brecha habitual surge cuando la organización supone que un servicio de IA “pertenece” al proveedor. El proveedor puede controlar el modelo base, la infraestructura o ciertas actualizaciones. La organización usuaria todavía decide sobre propósito, datos introducidos, usuarios autorizados, integración en procesos, umbrales, excepciones y acciones tomadas a partir de los resultados.

ISO/IEC 42001 aborda estas relaciones en su guía de controles: la organización debería documentar las partes que intervienen en el ciclo de vida y determinar sus responsabilidades, además de considerar riesgo del proveedor, documentación, monitoreo y acciones correctivas cuando un componente no funciona como se esperaba.

Para Auditoría Interna, no basta comprobar que existe un contrato. Según el riesgo, debe ser posible responder: ¿quién notifica cambios del modelo?, ¿quién investiga incidentes?, ¿qué evidencia puede obtener el cliente?, ¿cómo se documentan limitaciones?, ¿qué ocurre ante un cambio crítico?, ¿cómo se suspende o termina el servicio?

Tercerizar tecnología no equivale a tercerizar la rendición de cuentas por su uso.

Cómo puede Auditoría Interna probar la cadena de responsabilidad

La prueba más útil consiste en seguir decisiones reales de extremo a extremo y comprobar si la autoridad definida también existió en la práctica. Un programa de trabajo fundamental puede incluir cinco pruebas:

Reconstruir una decisión relevante. Identificar la salida de IA, quién o qué la convirtió en una acción, la evidencia considerada y el resultado final.
Rastrear derechos de decisión. Verificar quién podía autorizar el uso, aceptar riesgo residual, aprobar cambios y detener el sistema.
Probar la supervisión humana. Muestrear revisiones, anulaciones y escalaciones para comprobar que existían información, competencia y autoridad reales.
Seguir un cambio. Seleccionar una actualización de modelo, configuración o proveedor y comprobar si activó evaluación, pruebas y reautorización cuando correspondía.
Contrastar contrato y operación. Verificar que las obligaciones sobre documentación, cambios, incidentes y soporte funcionan realmente.

Las señales de alerta son claras: todos son “responsables” pero nadie decide; el negocio cree que Tecnología posee el riesgo; el revisor humano no puede anular la salida; un cambio del proveedor no gatilla reevaluación; o Auditoría Interna participa en aprobaciones que después deberá auditar.

La pregunta final no es “¿quién construyó el algoritmo?”. Es: ¿quién puede explicar qué decisión puede influir la IA, quién aprobó ese uso, quién puede desafiarlo o detenerlo, quién monitorea sus efectos, quién acepta el riesgo residual y cómo cambian esas responsabilidades cuando interviene un tercero?

Si la organización no puede responder con evidencia, todavía no tiene una cadena de responsabilidad. Tiene una cadena de suposiciones.