Nadie asume las consecuencias cuando falla un agente de IA
Ocho de cada diez ejecutivos en Europa y Oriente Medio afirman que un incidente de IA llegó a su junta directiva o equipo C-suite en el último año. Si les preguntas a esos mismos ejecutivos quién responde cuando un agente de IA causa el próximo incidente, ningún cargo recoge más del 17 por ciento de los votos.
Esa división proviene de un estudio de IBM publicado el 14 de octubre de 2026, que encuestó a 3,221 ejecutivos a través de Censuswide en organizaciones con 1,000 o más empleados en Reino Unido, Francia, Alemania, Italia, España, Países Bajos, Arabia Saudita y los Emiratos Árabes Unidos. El trabajo de campo se realizó del 14 al 24 de septiembre de 2026. El dato del 80 por ciento de incidentes fue el titular. El hallazgo más útil para un CISO o Chief Compliance Officer está más profundo en el informe, en las respuestas sobre quién es responsable cuando los agentes fallan.
Llámenlo el incidente sin dueño. La junta ha asignado formalmente el riesgo de IA a alguien, los agentes siguen accediendo a datos sensibles y, cuando algo se rompe, la cadena de responsabilidad se dispersa en ocho respuestas diferentes. Eso es un problema de gobernanza y también de evidencia, porque un regulador que pregunta quién autorizó a un agente a leer un registro quiere un nombre y un registro auditable, no un comité. El intercambio seguro de datos de Kiteworks existe para esa segunda parte de la pregunta, y este artículo explica cómo se conectan ambas mitades.
Puntos Clave
1. El número de incidentes ya no es la noticia.
El ochenta por ciento de los ejecutivos encuestados afirma que un incidente de IA llegó a su junta o C-suite en el último año, así que la pregunta abierta es qué puede demostrar el liderazgo sobre su respuesta.
2. La responsabilidad está fragmentada donde más importa.
La responsabilidad de IA a nivel de junta es casi universal, pero ningún cargo es nombrado por más del 17 por ciento cuando un agente de IA genera un resultado adverso.
3. La escalada informal es una exposición en auditoría.
Más de un tercio de los incidentes que llegaron a los líderes lo hicieron de manera informal, lo que deja a un Chief Compliance Officer sin un registro de lo que se decidió y cuándo.
4. Los contratos no son controles.
La mayoría de las organizaciones gestionan la IA de proveedores con cláusulas y derechos de auditoría, mientras que solo una pequeña minoría monitorea la IA de terceros de forma continua o exige garantías independientes.
5. Las obligaciones sobre los datos no se han movido.
El calendario de la Ley de IA de la UE cambió, pero los deberes de seguridad y notificación de brechas del GDPR y los deberes de reporte de NIS 2 siguen aplicando al acceso de agentes hoy.
Ocho de Cada Diez Juntas Ya Han Visto un Incidente de IA
Empecemos por el dato que nadie puede ignorar. Según el informe de IBM, The New Realities of AI Governance, el 80 por ciento de los ejecutivos encuestados afirma que un incidente relacionado con IA llegó a su junta o C-suite en el último año. Ya no es un riesgo hipotético en un mapa de calor. Es un tema recurrente en la agenda.
Lo que ocurrió después revela más que el número de incidentes. De las organizaciones donde un incidente llegó a los líderes, el 43 por ciento afirma que fue revisado formalmente a ese nivel, mientras que el 37 por ciento dice que se comunicó informalmente. Léelo de nuevo. Más de un tercio de las veces, un incidente de IA llegó a la cima de la organización por una conversación de pasillo en vez de un proceso de gobernanza.
Una escalada informal no deja registro que resista un escrutinio. Cuando una autoridad supervisora pregunta cómo se enteró el liderazgo del incidente, qué decidió y cuándo, «lo hablamos» no es una respuesta que un Chief Compliance Officer pueda presentar ante un regulador. La revisión formal es el control. La mención informal es la exposición.
Las consecuencias que enumera el informe son igual de concretas. Entre las organizaciones donde un incidente llegó a los líderes, el 40 por ciento cita un cambio en la política de gobernanza de IA como resultado principal, el 38 por ciento un cambio en los planes de inversión o implementación, el 37 por ciento la contratación de asesores externos y el 35 por ciento que se notificó a los reguladores. Tómalos como orientativos. Provienen de una encuesta encargada por un proveedor a ejecutivos que se auto-reportan, y cubren ocho mercados, no el mundo entero.
Aun así, el dato sobre reguladores merece una segunda mirada, porque es el único número de esta lista que una autoridad supervisora podría verificar en sus propios archivos. Más de un tercio de las organizaciones que escalaron un incidente también terminaron hablando con un regulador. Para quienes se ocupan de la preparación para auditorías, eso mueve la pregunta de la evidencia de «algún día» a «este trimestre».
Confías en que tu organización es segura. Pero ¿puedes demostrarlo?
Lee ahora
La Junta Tiene la Responsabilidad, pero Falta la Rendición de Cuentas de los Agentes
Sobre el papel, la imagen parece ordenada. La encuesta de IBM halló que el 98 por ciento de los encuestados ha asignado formalmente la responsabilidad de IA a nivel de junta, y el 26 por ciento cuenta con un comité de IA específico en la junta. Las estructuras de gobernanza están presentes casi en todas partes.
Ahora viene la pregunta difícil. Cuando un agente de IA produce un resultado adverso, ¿quién responde? El CIO o CTO fue la respuesta más común con un 17 por ciento, y ningún cargo fue nombrado por más del 17 por ciento. La responsabilidad compartida en el C-suite obtuvo un 14.5 por ciento, el chief risk o chief compliance officer un 14 por ciento, un chief AI officer un 13 por ciento, el equipo implementador un 11 por ciento, el proveedor de IA un 10 por ciento, un líder de línea de negocio un 10 por ciento y el CEO un 9 por ciento.
No es un desacuerdo sobre organigramas. Es la ausencia de uno. Un comité de la junta puede ser dueño de una categoría de riesgo, pero un incidente necesita una persona que pueda explicar qué tocó el agente, bajo la autoridad de quién y bajo qué política. Ocho respuestas distintas, ninguna mayoritaria, indican que la mayoría de las organizaciones aún no ha hecho esa asignación.
Esta división merece la cautela que merece cualquier encuesta. Una sola encuesta encargada por IBM en 2026 a ejecutivos de ocho mercados no es un hecho consolidado sobre quién es responsable de la seguridad de IA. Encuestas a diferentes perfiles en distintas regiones han puesto al CIO, al CTO y al CISO en el primer puesto. Lo que permanece es la fragmentación.
Aquí está la clave. La rendición de cuentas que solo existe a nivel de comité no genera evidencia. La evidencia viene de la capa de datos, donde se encuentran un autorizador humano identificado, la identidad del agente, una decisión de política y un registro auditable. Si esa cadena existe, la pregunta de quién responde tiene una base factual. Si no, la organización discute culpables mientras el reloj del regulador sigue corriendo.
El CISO suele heredar este vacío, aparezca o no su cargo en las respuestas. El líder de seguridad es a quien la junta recurre cuando el incidente es real, lo que convierte la cadena ausente en un problema personal además de institucional.
La Gobernanza Diseñada para Personas Ahora Escala a Agentes
Los agentes ya están en producción en una proporción significativa de estas organizaciones. IBM informa que el 35 por ciento ejecuta IA agente en producción y el 75 por ciento espera que los agentes actúen sin aprobación humana para cada acción en 2027. Al mismo tiempo, solo el 37 por ciento dice que su gobernanza está diseñada para escalar con la implementación de agentes, mientras que otro 45 por ciento considera que podría adaptarse pero necesita fortalecerse.
Si comparas esas cifras, el problema se hace evidente. La implementación tiene calendario. La gobernanza tiene intención. El informe añade que el 56 por ciento sigue implementando dentro de los límites de riesgo acordados mientras su gobernanza se adapta, y un tercio retrasa la implementación hasta que la gobernanza esté lista. La mayoría está construyendo el avión en pleno vuelo.
Retraso en la gobernanza es el nombre adecuado. Es el intervalo entre el día en que un agente empieza a tocar datos regulados y el día en que los controles que lo rigen alcanzan calidad de evidencia. Cada día dentro de ese intervalo produce eventos de acceso que no pueden reconstruirse después.
Una aclaración es importante para cómo se documenta esto internamente. «Sin aprobación humana para cada acción» describe delegación, no independencia. Una persona autoriza el flujo de trabajo, una política delimita qué puede tocar el agente y el registro auditable documenta ambos. Los agentes se suman a las personas como una segunda clase de identidad bajo un mismo modelo de gobernanza. No reemplazan la cadena de responsabilidad humana, y un programa que los trate como actores autónomos ya ha interpretado mal la tarea.
Aquí también aparece el costo de esperar. Adaptar identidad, políticas y registros auditables a agentes ya en producción implica reconstruir una historia que nunca se capturó. Construir los controles en la capa de datos desde el inicio significa que cada interacción del agente está gobernada desde su primera solicitud. La gobernanza de datos de IA implementada temprano es más barata que la reconstrucción forense tardía.
La Responsabilidad Fragmentada Necesita una Sola Cadena de Evidencia
Si la responsabilidad está fragmentada, la cadena de evidencia debe ser única. Ese es el principio de diseño que resuelve el vacío sin esperar a que se defina el organigrama.
Empieza por el autorizador. Cada flujo de trabajo de agente debe rastrearse hasta una persona identificada que lo delegó, igual que el acceso de un usuario humano se rastrea hasta su cuenta. Cuando la identidad del agente está vinculada a la identidad del humano que delega, la pregunta de quién responde tiene una respuesta factual, sin importar qué cargo termine siendo responsable del riesgo de IA.
Luego viene la política. Las reglas basadas en roles deciden qué puede ver una persona en un puesto, pero un agente actúa en varias tareas y un modelo solo basado en roles concede demasiado o demasiado poco. El control de acceso basado en atributos evalúa el perfil del agente, la sensibilidad de los datos, el contexto de la solicitud y la operación solicitada. Un agente autorizado para leer una carpeta no tiene permiso automático para descargarla.
Después viene el registro. Un registro de auditoría a prueba de manipulaciones que capture quién autorizó al agente, qué datos tocó, bajo qué política y cuándo, convierte un incidente en un informe, no en una investigación. La diferencia importa en la práctica. Los reguladores trabajan con plazos de días y un paquete de evidencia que tarda semanas en armarse es un hallazgo en espera de ocurrir.
Kiteworks Compliant AI gobierna el acceso de agentes en la capa de datos exactamente bajo esos principios. Verifica la identidad del agente y la vincula al autorizador humano, evalúa cada solicitud según políticas basadas en atributos, aplica cifrado validado FIPS 140-3 y escribe registros de auditoría a prueba de manipulaciones. El Kiteworks Secure MCP Server lleva el mismo modelo a clientes de IA como Claude y Copilot, donde cada solicitud hereda los permisos existentes del usuario mediante OAuth 2.0 y se registra en el mismo registro de auditoría que cubre correo electrónico, uso compartido de archivos y transferencia de archivos gestionada. Un solo registro de auditoría para todos los canales es la clave. Cinco herramientas generan cinco brechas de auditoría.
El Punto Ciego del Proveedor Es el Punto Ciego de la Auditoría
El problema de la responsabilidad no termina en el límite corporativo. La encuesta de IBM halló que el 54 por ciento de los ejecutivos reconoce brechas en la cobertura de gobernanza para la IA utilizada por proveedores clave y socios de la cadena de suministro.
Los controles que las organizaciones eligen lo dicen todo. Las disposiciones contractuales lideran con un 43 por ciento y los derechos de auditoría siguen con un 39 por ciento, mientras que el monitoreo continuo del riesgo de IA de terceros se sitúa en el 21 por ciento y la garantía o certificación independiente en el 13 por ciento. Los controles en papel dominan y los controles observados quedan muy atrás.
Una cláusula es una promesa. Un registro es un hecho. Cuando el agente de un socio accede a tus datos regulados, el contrato dice lo que debió pasar y solo tus propios registros dicen lo que realmente ocurrió. Esa asimetría es el punto ciego del proveedor, y se convierte en un punto ciego de auditoría la primera vez que un examinador pide el historial de acceso de datos que salieron de tu entorno.
Para las organizaciones europeas, la exposición está codificada. La Directiva NIS 2 exige a las entidades cubiertas gestionar la seguridad de la cadena de suministro como parte de sus medidas de administración de riesgos de ciberseguridad, y sus disposiciones sobre el órgano de administración ponen la responsabilidad de aprobar y supervisar esas medidas en el liderazgo. La interpretación práctica es que la administración de riesgos de terceros debe generar evidencia de lo que los socios y sus agentes hicieron con tus datos, no solo un cuestionario firmado. Un programa maduro de administración de riesgos de proveedores solicita registros de acceso y decisiones de política, y luego verifica que existan antes de que lo haga un regulador.
La brecha también tiene un costo que rara vez aparece en un registro de riesgos. Cuando el agente de un proveedor accede a tus datos y el registro solo existe en el sistema del proveedor, tu capacidad de responder ante un regulador depende de la rapidez con la que responde el proveedor y de si su periodo de retención coincide con el tuyo. Ninguna de esas cosas puede garantizarse con una cláusula a la velocidad que exige un plazo de 72 horas.
La Ley de IA Cambió, pero las Obligaciones sobre los Datos No
Algunos ejecutivos leerán la noticia sobre el calendario de la Ley de IA de la UE como un alivio. El AI Omnibus, según el resumen del Future of Privacy Forum, movió la fecha de aplicación de los requisitos de alto riesgo del Anexo III del 2 de agosto de 2026 al 2 de diciembre de 2027, y para los sistemas del Anexo I del 2 de agosto de 2027 al 2 de agosto de 2028. El Parlamento adoptó el texto el 16 de junio de 2026, el Consejo el 29 de junio de 2026 y se publicó en el Diario Oficial el 24 de julio de 2026.
Tómalo como un cambio de calendario para una regulación, no como una pausa en la gobernanza. IBM halló que el 41 por ciento de los ejecutivos de la UE en su muestra está acelerando la inversión en gobernanza antes de las obligaciones de alto riesgo, lo que sugiere que muchos han interpretado correctamente el retraso. Están usando el tiempo extra para construir, no para esperar.
La razón es sencilla. Los reguladores regulan datos, no modelos. El GDPR aplica a los datos personales tanto si los procesa una persona como un agente de software, y su deber de seguridad del procesamiento bajo el Artículo 32 y su obligación de notificación de brechas en 72 horas bajo el Artículo 33 no dependen del calendario de la Ley de IA. NIS 2 añade su propio reloj de reporte, con una advertencia temprana en 24 horas y una notificación más completa en 72 horas tras un incidente significativo. Ninguna de esas obligaciones contiene una exención para agentes.
Así que la pregunta práctica para un Chief Compliance Officer o un Responsable de Privacidad de Datos es la misma. Si un agente accede a datos personales a las dos de la mañana y algo sale mal, ¿puede la organización demostrar quién autorizó el acceso, qué vio el agente y qué política lo permitió, dentro del plazo del regulador? Un DPO que no pueda responder a esa pregunta está expuesto en el GDPR hoy, sin importar lo que diga la Ley de IA sobre 2027.
Qué Puede Hacer un CISO y un CCO Antes de la Próxima Junta
Deja de preguntar qué ejecutivo debe ser dueño de la IA. Empieza a preguntar si cada flujo de trabajo de agente tiene un responsable, una política y un registro auditable. Son tres cosas que puedes verificar este mes y que sirven sin importar cómo se resuelva la cuestión ejecutiva.
Primero, asigna un autorizador humano identificado a cada flujo de trabajo de agente que acceda a datos regulados y registra esa asignación donde tanto el sistema de identidad como el registro de auditoría puedan verla. Un comité de la junta que sea dueño del «riesgo de IA» no sustituye a una persona que sea responsable del «acceso de este agente». Cuando los encuestados de IBM se dividieron en ocho opciones sobre la responsabilidad, casi siempre faltaba este punto.
Segundo, haz un ejercicio de evidencia. Elige un flujo de trabajo de agente y pide al equipo que produzca, en cuestión de horas, el registro completo de acceso para una muestra de sus acciones, incluyendo quién autorizó al agente, qué datos tocó y qué política lo permitió. Si la respuesta tarda semanas, has medido tu brecha de evidencia y tienes un dato que la junta entenderá.
Tercero, formaliza la escalada de incidentes. El 37 por ciento de los incidentes que llegaron a los líderes de forma informal deberían llegar mediante una revisión documentada que registre qué se decidió y cuándo. Un registro escrito de la respuesta del liderazgo es evidencia, y es barato.
Cuarto, lleva la IA de proveedores del lenguaje contractual a controles observados. Pide a los socios registros y decisiones de política para cualquier agente que acceda a tus datos, y escribe el derecho a recibirlos en el acuerdo. El monitoreo continuo en el 21 por ciento es el número a superar.
Quinto, aplica la minimización de datos a nivel de operación. Un agente que solo recibe los datos que requiere su tarea genera un incidente menor si algo falla y una historia más sencilla cuando pregunta una autoridad supervisora.
La propia perspectiva de IBM merece estar en la pared. En el comunicado, Ana Paula Assis, presidenta de IBM para EMEA y APAC, dijo que la gobernanza «ya no puede tratarse como un ejercicio de cumplimiento». La consecuencia para quienes firman la respuesta de auditoría es clara. La gobernanza que no puede producir evidencia bajo demanda sigue siendo solo un ejercicio de cumplimiento, sin importar cómo se le llame.
Para saber más sobre cómo generar registros de calidad de evidencia del acceso de agentes de IA a datos regulados, solicita una demo personalizada hoy.
Preguntas Frecuentes
La encuesta de IBM muestra que no hay consenso, ya que ningún cargo es nombrado por más del 17 por ciento de los encuestados, así que la respuesta debe venir del diseño y no del organigrama. Haz que la responsabilidad siga el flujo de trabajo asignando un autorizador humano identificado a cada agente y registrando la delegación. Eso da al regulador una respuesta factual incluso mientras los ejecutivos debaten cargos. Combina la asignación con un registro de auditoría que vincule las acciones del agente con esa persona y con una gobernanza de datos clara sobre los datos que toca.
Cambia el calendario de una regulación, no de las obligaciones sobre los datos que ya aplican. El Omnibus movió la fecha de alto riesgo del Anexo III al 2 de diciembre de 2027, pero los deberes de seguridad y notificación de brechas del GDPR y los deberes de reporte de NIS 2 no dependen de esa fecha. La mayoría de los equipos de cumplimiento debería tratar el tiempo extra como una ventana para construir, no para pausar. Un punto de partida práctico es una revisión de distancia frente a los requisitos de cumplimiento GDPR y cumplimiento NIS 2 para el acceso de agentes a datos regulados.
Espera preguntas sobre quién autorizó el acceso, qué datos tocó el agente, qué política lo permitió y cuándo ocurrió, respondidas con registros y no con recuerdos. Las mismas preguntas aplican a un usuario humano, por lo que un regulador no aceptará el prompt del sistema de un modelo como control de acceso. Los registros deben ser a prueba de manipulaciones y exportables en un formato que un examinador pueda leer. Una cadena de custodia que cubra acciones de agentes y humanas cierra la brecha, y el motor de políticas de datos es donde se registran esas decisiones de política.
Empieza reconociendo que las cláusulas contractuales y los derechos de auditoría, los controles más comunes en la muestra de IBM, describen intención y no comportamiento. Exige a los socios que proporcionen registros de acceso y decisiones de política para los agentes que accedan a tus datos y verifica que existan antes de necesitarlos. Lleva la pregunta a tu proceso existente de administración de riesgos de terceros para que el uso de IA sea un tema permanente de diligencia y no una revisión puntual. La garantía independiente, usada solo por el 13 por ciento en la encuesta, es el control más fuerte y el menos adoptado.
La gobernanza integrada en la capa de datos normalmente elimina un cuello de botella en vez de añadir uno, porque los proyectos ya no esperan una revisión manual de cumplimiento para cada resultado. El retraso ocurre cuando los controles se adaptan después de que los agentes ya están en producción y los equipos deben reconstruir qué se accedió. El hallazgo de IBM de que el 56 por ciento sigue implementando mientras la gobernanza se adapta muestra lo común que es la adaptación posterior. Construir sobre Kiteworks Compliant AI significa que cada solicitud de agente se evalúa, cifra y registra desde la primera llamada, en línea con los principios de generative AI de confianza cero.
Recursos Adicionales
- Artículo del Blog
Estrategias Zero‑Trust para una Protección de Privacidad de IA Accesible - Artículo del Blog
Cómo el 77% de las organizaciones falla en la seguridad de datos de IA - eBook
Brecha en la Gobernanza de IA: Por qué el 91% de las pequeñas empresas juega a la ruleta rusa con la seguridad de datos en 2025 - Artículo del Blog
No existe un «–dangerously-skip-permissions» para tus datos - Artículo del Blog
Los reguladores ya no preguntan si tienes una política de IA. Quieren pruebas de que funciona.