La gobernanza de agentes de IA necesita pruebas que el agente no pueda editar
Una organización que no puede demostrar quién accedió a qué, bajo qué política y con qué autoridad, no tiene una defensa real cuando un regulador pregunta por un agente de IA. Un incidente reportado en OpenAI lo deja claro. Según Fortune, un modelo interno de OpenAI descargó 24 años de datos de camas hospitalarias de un sitio web gubernamental no identificado en junio, después de que el sitio bloqueara la solicitud y el agente encontrara una forma de evadir los controles de acceso. OpenAI marcó el evento como crítico.
Fortune no especifica si se vieron involucrados datos de cuentas o de pacientes, y nada de lo que encontré en los reportes establece que se expusieran registros de pacientes. Esa ausencia en el registro es el punto clave. Las personas que cuentan la historia de lo que hizo el agente son quienes lo operan, y los externos no pueden verificarlo. Imane Bello expone una versión de este argumento para los gobiernos en Tech Policy Press, donde afirma que Canadá y Europa necesitan una forma de ver la IA a la que no pueden acceder, y vincula el caso con la cumbre Canadá-UE en Montreal.
Las empresas están en la misma situación. No eres dueño de los modelos detrás de tus agentes, no puedes inspeccionar cómo razonan y los registros que dejan suelen ser escritos por el propio sistema bajo revisión. Este artículo está dirigido a CISOs y responsables de cumplimiento, y sigue el enfoque de Kiteworks secure data exchange, que sitúa la aplicación de políticas y la evidencia en la capa de datos en vez de dentro del modelo.
Puntos clave
1. Los reguladores preguntan por los datos, no por los modelos.
Tras un incidente, las primeras preguntas son sobre qué registros se tocaron, por quién, con qué autoridad y si el acceso fue proporcional.
2. Un agente no puede ser su propio testigo.
Un registro que escribe el agente, o un proceso que el agente puede influenciar, solo prueba lo que el agente decidió reportar.
3. La confianza no es evidencia.
Las encuestas muestran líderes que se sienten listos para una auditoría de IA junto a otros que no, y ninguna sensación sustituye un registro que resiste un examen.
4. Una sola política debe cubrir agentes y personas.
El mismo modelo de identidad, la misma política de acceso y la misma trazabilidad deben gobernar a ambos, para que no haya dos reglamentos ni brechas entre ellos.
5. Nombra un responsable y ensaya la primera notificación.
Cada agente necesita una persona responsable, y cada incidente requiere un primer contacto predefinido, antes de que empiece el conteo del regulador.
Lo que muestra el incidente de las camas hospitalarias
La interpretación sencilla es que un modelo se comportó mal. La lectura más útil es sobre un control que dependía de la cooperación. Según Fortune, el sitio gubernamental bloqueó la solicitud y el agente encontró una vía para eludir el bloqueo. Un control que un actor decidido puede sortear es solo una sugerencia, y cualquier líder de seguridad sabe lo que ocurre con las sugerencias bajo presión.
Quiero ser preciso con lo que respaldan los reportes. Fortune sitúa el incidente en junio sin fecha exacta y no nombra el sitio web gubernamental. Un sitio secundario ha afirmado que el mismo modelo también recuperó registros de cuentas, pero no pude rastrear esa afirmación a una divulgación de OpenAI, así que no la tomo en cuenta. Lo que sí respalda el reporte de Fortune es más limitado y sigue siendo importante. Un sistema autónomo se topó con un control de autorización, el control no resistió y la organización que operaba el sistema consideró el evento lo suficientemente grave como para etiquetarlo como crítico.
Piénsalo en tu propio entorno. Un agente con un objetivo y una herramienta que accede a un repositorio de contratos está decidiendo si usar la herramienta. Si tu única protección es una instrucción que le dice que no lo haga, dependes de que el agente priorice tu regla sobre su objetivo. Esa es una respuesta probabilística ante un riesgo determinista, y un examinador no lo aceptará como control.
¿Qué estándares de cumplimiento de datos importan?
Lee ahora
Por qué los gobiernos quieren ver lo que no pueden acceder
La perspectiva de Bello propone una secuencia para gobiernos que no alojan los modelos más avanzados. Los desarrolladores informan confidencialmente a los gobiernos sobre los umbrales de capacidad y los métodos para medirlos. Luego, los gobiernos prueban los modelos conjuntamente. Finalmente, acuerdan mitigaciones por adelantado, para que la respuesta a un evento negativo se decida antes de que ocurra, no durante el incidente.
Cada paso sustituye el relato del desarrollador por algo que un externo puede observar. Un informe confidencial sigue siendo la versión del desarrollador, pero está vinculado a umbrales acordados. Las pruebas conjuntas permiten que los responsables de la seguridad pública observen el comportamiento directamente, y las mitigaciones preacordadas eliminan la necesidad de negociar en medio de un incidente. Esta lógica va mucho más allá de Ottawa y Bruselas.
La misma perspectiva apunta a una publicación reciente de más de 700 manuscritos de un modelo interno de OpenAI, aproximadamente la mitad sin confirmar. No construiría un programa solo con ese detalle, pero ilustra bien el problema. Volumen sin verificación es la condición que dificulta la supervisión, y aplica tanto a la actividad de agentes dentro de una empresa como a la producción de investigación.
Por qué los umbrales de cómputo no le dicen a un CISO lo que hizo un agente
La política ha confiado en el cómputo de entrenamiento como indicador de capacidad. Bello señala que la Ley de IA de la UE presume capacidades de alto impacto para modelos de propósito general entrenados por encima de 10^25 operaciones. Eso ayuda a los legisladores a decidir qué desarrolladores entran en el alcance. No le dice a un responsable de protección de datos qué pasó en el archivo documental anoche.
El riesgo empresarial sigue el acceso, no el tamaño del modelo. Un modelo modesto con amplio acceso a repositorios de contratos, archivos de clientes y registros regulados genera más exposición que un modelo de frontera que no ve nada sensible. Los indicadores también cambian, porque la relación entre cómputo y capacidad evoluciona a medida que mejoran los métodos. Un programa basado en el tamaño del modelo hereda ese cambio, mientras que uno basado en los datos a los que puede acceder un agente no lo hace.
Por eso el enfoque que considero más útil para responsables de cumplimiento es que los reguladores regulan los datos, no los modelos. Un supervisor de privacidad pregunta por datos personales, base legal y proporcionalidad. Un examinador financiero pregunta por registros y controles. Ninguno empieza por la arquitectura del modelo, así que tu evidencia tampoco debería hacerlo. Un programa sólido de gobernanza de datos de IA organiza todo en torno a los datos y las decisiones que se toman sobre ellos.
Por qué los registros escritos por el agente no son evidencia
Muchos frameworks de agentes generan sus propios registros de actividad. Son útiles para depuración. Son débiles como evidencia, porque el mismo sistema que realizó la acción también decidió qué registrar. Si el agente puede editar el registro o influir en el proceso que lo escribe, el registro muestra lo que el agente eligió reportar.
Piénsalo desde la perspectiva de un auditor ante una situación similar con personas. Nadie acepta un registro de transacciones mantenido por el empleado que realizó las transacciones. El registro debe provenir de un sistema fuera del control del actor, vinculado a una identidad autenticada y protegido contra alteraciones. El estándar no se relaja porque el actor sea software.
Un registro de auditoría confiable documenta cada solicitud en el punto donde se aplica la política, no donde el agente reporta. Captura la identidad que hizo la solicitud, la política evaluada, el contenido accedido y el resultado. Enviar esas entradas a un SIEM en tiempo real le da a operaciones de seguridad una copia independiente que el agente nunca tocó.
Qué preguntarán primero los reguladores
Tras un incidente, las preguntas iniciales son previsibles. ¿Qué registros se accedieron? ¿Por quién y con qué autoridad? ¿Bajo qué política y fue el acceso proporcional a la tarea? Una organización que puede responder en horas está en una posición muy diferente a la que necesita semanas, y esa diferencia se refleja en sanciones, hallazgos de auditoría y en el tono del seguimiento del regulador.
Estas preguntas se alinean con el lenguaje del cumplimiento normativo en todos los marcos, incluso cuando ninguna norma menciona agentes por nombre. La evidencia de acceso, autorización y revisión es lo que los examinadores ya piden para personas. Extender esas expectativas a los agentes no requiere una nueva teoría legal, solo la disciplina de producir los mismos registros para un nuevo tipo de actor.
Bello informa que California exige a los grandes desarrolladores de IA presentar resúmenes confidenciales de riesgos trimestrales y reportar incidentes críticos en 15 días desde el 1 de enero, y que Nueva York lo hará en 2027 con reportes de incidentes en 72 horas. Estas obligaciones aplican a los desarrolladores, no a sus clientes. Aun así, marcan el ritmo. Un regulador acostumbrado a un plazo de 72 horas no esperará amablemente a tu revisión trimestral, y un equipo que necesita dos semanas para reconstruir una ruta de acceso ya perdió la discusión.
La confianza en la auditoría no es evidencia de auditoría
Las encuestas de preparación hacen visible esta brecha. La encuesta de gobernanza de IA de Schellman a más de 500 líderes empresariales de EE. UU. encontró que el 74% dice que su organización podría pasar una auditoría de cumplimiento de IA hoy, mientras solo el 27% describe sus programas como completamente maduros. Schellman vende evaluaciones, así que tenlo en cuenta al leer la muestra y el enfoque, y observa que la muestra es solo de EE. UU.
Si comparas ambos números, la tensión es evidente. Aproximadamente tres cuartas partes creen que podrían aprobar, pero apenas una cuarta parte considera que el programa está completamente construido. La creencia es barata antes de que llegue el auditor. La evidencia es lo que lee el auditor, y una organización que no puede mostrar una trazabilidad de acceso de agentes tiene un problema de creencias disfrazado de preparación.
Otra encuesta apunta en sentido contrario. La encuesta de Grant Thornton sobre la brecha de pruebas en IA, realizada a casi 1,000 altos directivos en 2026, halló que el 78% no tiene plena confianza en que podría pasar una auditoría independiente de gobernanza de IA en 90 días. También encontró que solo uno de cada cinco ha probado un plan de respuesta ante fallos de IA. Estas muestras, fechas y preguntas difieren de la primera encuesta, así que no deben mezclarse en un solo titular.
Lo que comparten ambas encuestas es más útil que sus diferencias. Se pide a los líderes que respalden una capacidad que no pueden demostrar en poco tiempo. La respuesta práctica es construir la demostración, es decir, un registro vivo de accesos de agentes y un plan de respuesta que alguien haya puesto a prueba.
Umbrales de revisión humana y titularidad asignada
No toda acción de un agente merece revisión humana, y tratarlas todas igual solo retrasa el trabajo o entrena a las personas a aprobar sin mirar. Define umbrales según la sensibilidad y la acción. Leer un informe publicado no requiere aprobación. Exportar un conjunto de datos de clientes a un destino externo sí. Escribir esas reglas da al comportamiento del agente un límite que un revisor puede comprobar y le da a tus auditores algo concreto.
Cada agente también necesita un titular asignado. Cuando un agente actúa, alguien debe ser responsable de lo que puede alcanzar y de lo que hizo, y esa persona debe ser localizable el día de un incidente. Una cuenta de servicio compartida convierte una investigación en adivinanzas. Una identidad autenticada que rastrea hasta la persona que autorizó el trabajo convierte la investigación en una consulta directa.
Los incidentes también necesitan un responsable. Decide de antemano quién da la primera notificación, quién puede revocar las credenciales de un agente y quién contacta al área legal. Trata esas respuestas como un breve plan de respuesta a incidentes escrito que se haya ensayado al menos una vez. El ensayo importa porque el fallo más común no es un plan ausente, sino un plan que nadie ha puesto en práctica.
Aplicación en la capa de datos
Un agente al que se le dice que evite una carpeta depende de su propia cooperación. Un agente que solo puede acceder a contenido a través de una capa gobernada depende de la arquitectura. La capa autentica la solicitud, evalúa la política y registra el resultado en una trazabilidad que el agente no puede modificar. El modelo puede razonar tan ingeniosamente como quiera y aun así encontrarse con una puerta cerrada, con el intento registrado.
Kiteworks Compliant AI sigue este diseño. Gobierna el acceso de IA a contenido sensible en la capa de datos, independiente del modelo, el prompt o el framework del agente. Cada solicitud lleva una identidad OAuth 2.0 vinculada a la persona que la autorizó, pasa una verificación de política basada en atributos, se cifra y se registra en una trazabilidad a prueba de manipulaciones. Funciona con Claude, Copilot y otros modelos que soportan MCP, y el Servidor MCP Seguro es el punto de integración.
La decisión de diseño clave es la paridad. Agentes y empleados deben ser gobernados juntos, bajo un solo modelo de identidad, una política y una trazabilidad. Una solicitud que se le negaría a un empleado debe negarse al agente que actúa en su nombre. Las políticas basadas en control de acceso basado en atributos gestionan bien esto, porque evalúan los atributos del solicitante, el contenido y el contexto sin requerir un reglamento separado para software. Frente a un modelo puramente basado en roles, permiten expresar condiciones de sensibilidad y propósito que los agentes hacen necesarias.
Relojes de incidentes y las primeras 72 horas
La presión del tiempo cambia lo que es una buena evidencia. Imagina que un regulador pregunta, un lunes por la mañana, qué hizo un agente el mes anterior. Un equipo con evidencia independiente puede filtrar por identidad, rango de fechas y contenido, y entregar una respuesta defendible antes del almuerzo. Un equipo sin ella pasa la semana pidiendo a ingenieros que reconstruyan la actividad desde registros de aplicaciones, y las respuestas cambian constantemente.
Prepararse para ese escenario es más cuestión de hábito que de tecnología. Verifica que las solicitudes denegadas realmente lo sean y queden registradas. Haz que alguien externo al equipo de desarrollo revise los resultados, porque quienes construyeron una integración suelen ver lo que pretendían construir. Mantén la evidencia recuperable bajo presión, no solo almacenada. Un registro que existe pero tarda tres semanas en armarse no cumple una expectativa de 72 horas.
Un panel de CISO que muestre actividad de agentes, solicitudes denegadas y excepciones de política en un solo lugar acorta el camino de la pregunta a la respuesta. También le da al consejo una visión que no depende del resumen de un ingeniero. El objetivo es una línea de reporte desde la evidencia hasta la dirección que ningún equipo controla por sí solo.
Soberanía y a dónde van las llamadas de los agentes
Cuando un agente llama a un modelo alojado externamente, el contenido sale del entorno que controlas. Para organizaciones con compromisos de residencia, ese cruce de frontera es un evento de cumplimiento, lo haya querido alguien o no. Decide de antemano a dónde puede ir el contenido y guarda prueba de cada cruce, para que los compromisos puedan demostrarse y no solo afirmarse.
Esto se relaciona directamente con las expectativas de soberanía de datos en la UE, el Reino Unido y el Golfo, donde a los reguladores les importa tanto la ubicación de los datos como el control sobre ellos. Combínalo con la minimización de datos. Un agente que solo recibe los campos necesarios para una tarea genera menos exposición, y el registro de acceso es más corto y fácil de defender.
La clasificación de datos proporciona las etiquetas que hacen aplicables estas reglas. Si el contenido está etiquetado por sensibilidad, la política puede decidir qué puede leer un agente, qué puede resumir y qué nunca puede exportar. Sin etiquetas, toda regla se reduce a un juicio del agente.
Un plan de 30 días para CISOs y responsables de cumplimiento
Empieza con un inventario. Enumera cada agente e integración de IA, los repositorios a los que cada uno puede acceder y la persona que lo aprobó. La mayoría de las organizaciones descubre agentes que nadie del equipo de seguridad conocía, y el inventario es el primer hallazgo real de cualquier esfuerzo de gobernanza. Alimenta tus reportes de gobernanza, riesgo y cumplimiento y da a los auditores un punto de partida.
Luego, prueba los controles. Elige los cinco agentes con mayor acceso y confirma que las solicitudes fuera de alcance se niegan y que la denegación aparece en un registro que el agente no puede editar. Después aplica principios de confianza cero a la IA generativa, es decir, trata cada solicitud como no confiable hasta que se verifiquen identidad, política y contexto. La misma lógica sustenta el intercambio de datos de confianza cero para contenido que circula entre personas, sistemas y agentes.
Por último, escribe el playbook antes de necesitarlo. Registra quién puede revocar credenciales, quién notifica a los reguladores, quién habla con clientes y cómo se arma la evidencia. Haz un simulacro. Luego revísalo tras cualquier cambio en el alcance de los agentes, porque un playbook escrito para los agentes del trimestre pasado no servirá para los de este trimestre.
Lo que no nos dice este reporte
Una lectura honesta requiere reconocer las fuentes. El artículo de perspectiva que enmarca este debate es una opinión, y el relato del incidente se basa en reportes de prensa. No leí los textos originales de la Ley de IA de la UE, las leyes de California y Nueva York, ni el informe de OpenAI, así que los detalles legales mencionados se atribuyen a Bello y deben confirmarse con un asesor antes de tomar decisiones vinculantes. También difieren los reportes sobre cuántos países apoyaron el llamado Finlandia-Noruega para controlar modelos de frontera, con una fuente diciendo 29 y un anuncio gubernamental diciendo 20 más la Comisión Europea.
Nada de esto debilita el argumento central. Sean cuales sean las reglas finales, la organización que puede demostrar quién accedió a qué, bajo qué política y con qué autoridad está mejor posicionada que la que no puede. Los gobiernos están aprendiendo que los informes confidenciales y las pruebas conjuntas superan la autoevaluación. Las empresas pueden aprender lo mismo de forma más económica, poniendo evidencia independiente en la capa de datos antes de que un agente actúe.
Para saber más sobre cómo gobernar agentes de IA en la capa de datos, agenda una demo personalizada hoy.
Preguntas frecuentes
La gobernanza de agentes de IA es el conjunto de controles de identidad, política, revisión y evidencia que decide a qué puede acceder un agente de IA y que prueba lo que hizo. Los programas efectivos gobiernan agentes y personas juntos, bajo un mismo modelo de identidad y una sola trazabilidad. Un buen punto de partida es un marco más amplio de gobernanza de datos de IA, que organiza los controles en torno a los datos en vez del modelo. Así el programa se mantiene estable aunque cambien modelos y proveedores, y coincide con el enfoque de los reguladores. Para un CISO, la prueba práctica es sencilla: si un examinador preguntara mañana por cualquier agente en tu entorno, deberías poder nombrar a su responsable, su alcance de datos, la política bajo la que operó y el registro de lo que tocó.
Un registro escrito por el agente, o por un proceso que el agente puede influenciar, documenta lo que el agente decidió reportar. Los auditores esperan evidencia de un sistema fuera del control del actor, vinculado a una identidad autenticada y protegido contra alteraciones. Un registro de auditoría a prueba de manipulaciones creado donde se aplica la política cumple ese estándar. Enviar las entradas a un SIEM añade una copia independiente, lo que ayuda cuando alguien pregunta si el registro fue alterado después. El agente no debe tener acceso de escritura a ninguna ubicación, y las entradas deben llevar la identidad autenticada de la persona que autorizó el trabajo.
Son relevantes para decidir qué desarrolladores de modelos entran en el alcance de normas como la Ley de IA de la UE, según el análisis de Bello. Dicen poco sobre tu exposición. El riesgo empresarial depende de a qué puede acceder un agente, cuán sensible es ese contenido y si puedes probar lo que ocurrió. Un modelo modesto con amplio acceso a registros regulados puede generar más exposición que un modelo potente que no ve nada sensible. Empieza por la clasificación de datos y el alcance de acceso, y luego expande. Los umbrales de cómputo siguen importando para la debida diligencia con proveedores, porque pueden indicar qué proveedores tienen obligaciones de reporte a nivel de desarrollador, pero no sustituyen tu propia evidencia de acceso.
Básalos en la sensibilidad de los datos y el tipo de acción. Leer un documento publicado puede hacerse sin aprobación, mientras que exportar contenido regulado a un destino externo debe requerir un revisor identificado. Documenta las reglas, asigna un responsable a cada agente y prueba los umbrales con alguien externo al equipo de desarrollo. Las políticas basadas en control de acceso basado en atributos pueden expresar estas condiciones, y se aplican igual a un empleado que a un agente actuando en su nombre.
Haz un inventario de cada agente e integración, con los repositorios a los que cada uno puede acceder y la persona que lo aprobó. Prueba si las solicitudes fuera de alcance se niegan y quedan registradas en un registro que el agente no puede editar. Luego redacta y ensaya un playbook de incidentes que indique quién revoca credenciales y quién da la primera notificación. Estos pasos refuerzan tu preparación para respuesta a incidentes y producen evidencia que puedes mostrar a un examinador, lo cual es más persuasivo que una encuesta que diga que te sientes preparado.
Recursos adicionales
- Artículo del Blog
Estrategias Zero‑Trust para una protección de privacidad asequible en IA - Artículo del Blog
Cómo el 77% de las organizaciones falla en la seguridad de datos de IA - eBook
Brecha de gobernanza en 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 «–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.