Gobernanza de datos para agentes de IA en empresas

Gobernar los datos de un agente de IA significa poder responder, en cualquier momento, a tres preguntas: qué datos puede tocar ese agente, qué hace con ellos de verdad y quién puede quitarle ese acceso ya mismo. Según el informe 2026 Data Security and Compliance Risk Forecast de Kiteworks (225 responsables de seguridad, TI y riesgo, 10 sectores, marzo de 2026), el 63% de las empresas no puede limitar el propósito para el que actúa un agente de IA, y el 60% no tiene forma de apagarlo si empieza a comportarse mal. La mayoría de las empresas ya tiene agentes en producción. Muy pocas pueden gobernar lo que esos agentes tocan.

El despliegue de agentes de IA ha ido mucho más rápido que la capacidad de controlarlos. Eso no es una opinión: es lo que dicen, con cifras, los dos estudios más recientes sobre el tema.

Qué es la gobernanza de datos de un agente de IA

Un agente de IA no solo responde preguntas: lee, escribe y modifica datos dentro de los sistemas de la empresa, a menudo sin que una persona revise cada acción. La gobernanza de datos para agentes de IA es el conjunto de controles que define, antes de que eso pase, qué datos puede ver cada agente, para qué finalidad concreta, durante cuánto tiempo, y cómo queda constancia de cada acción que ejecuta.

No es lo mismo que la gobernanza de datos «clásica» (la que ya existe para empleados y aplicaciones). Un agente de IA puede operar a cualquier hora, encadenar decisiones sin supervisión humana en el momento, y acceder a sistemas distintos en una sola tarea. Un marco pensado para personas con horario y memoria no cubre eso.

Las cifras que no salen en la demo

En la demo de un proveedor de agentes de IA se ve lo que el agente hace bien. Lo que no se ve es si tu empresa puede controlarlo cuando algo sale mal. El informe de Kiteworks, con el 51% de las empresas encuestadas ya operando agentes en producción, encontró que:

• El 63% no puede imponer un límite de propósito a sus agentes de IA: una vez autorizados, actúan sin que el sistema compruebe si siguen dentro del uso para el que se les dio acceso.
• El 60% no dispone de un interruptor de apagado (kill switch) para detener a un agente que se comporta de forma anómala; solo el 40% puede hacerlo.
• El 45% tiene capacidad de aislar a un agente de la red si hace falta — por debajo de la mitad.
• El 33% no tiene ningún registro de auditoría con calidad suficiente para reconstruir qué hizo un agente y por qué. Las empresas sin ese registro quedan, de media, entre 20 y 32 puntos por detrás en madurez de IA frente al resto.
• En el sector público, el 90% carece de límite de propósito y el 76% no tiene interruptor de apagado.

El informe 2026 State of AI Agent Identity Security de Akeyless (400 responsables de TI y seguridad en EE. UU. y Reino Unido, mayo de 2026) llega a la misma conclusión desde el lado de las credenciales: el 67% de las empresas sospecha que sus agentes de IA ya han accedido a datos fuera del alcance que tenían asignado, y el 61% ha tenido que revocar o rotar credenciales de agentes por una exposición sospechada. Detectar un agente comprometido tarda, de media, 14 horas; contenerlo y remediarlo, cerca de 7 días. Solo el 7% de las empresas confía en que sus controles actuales impedirían que un agente comprometido siguiera operando.

El permiso que nadie revoca

Lo que nadie cuenta al vender un agente de IA es esto: casi ninguna empresa tiene manera de quitarle el acceso una vez que termina la tarea para la que se le dio. El acceso se concede al desplegar el agente y se queda ahí, abierto, hasta que alguien se acuerda de revisarlo — y según los datos de Kiteworks y Akeyless, esa revisión casi nunca llega. La gobernanza de datos para agentes no es un documento de políticas: es la capacidad técnica real de limitar, vigilar y cortar ese acceso en el momento en que haga falta, no después.

Esto conecta directamente con lo que ya vimos al hablar de permisos de agentes de IA: dar acceso de más es el síntoma; no poder revocarlo ni auditarlo es la causa de fondo. Y sin observabilidad real sobre lo que el agente hace con ese acceso, el problema es invisible hasta que ya ha pasado algo.

Qué exige de verdad gobernar los datos de un agente

De los dos informes se pueden extraer cinco controles concretos que separan a la minoría que gobierna de verdad sus agentes del resto:

1. Límite de propósito aplicado por el sistema, no solo escrito en una política. El 99,7% de las empresas de otro estudio reciente (Delinea, 2026) dice tener una política sobre qué puede tocar un agente — pero solo el 51% la comprueba en tiempo real. Una política que no se aplica automáticamente no protege nada. 2. Interruptor de apagado operativo, probado, no solo documentado: poder cortar a un agente concreto sin tener que apagar el sistema entero. 3. Registro de auditoría con calidad de evidencia: que permita reconstruir, acción por acción, qué datos tocó un agente y con qué autorización, no un log genérico de aplicación. 4. Revocación y rotación de credenciales como proceso, no como reacción a un incidente ya ocurrido. 5. Visibilidad de dónde viven las credenciales de cada agente — menos de la mitad de las empresas, según Akeyless, tiene esa visibilidad completa hoy.

Un ejemplo de cómo falla esto en el día a día

Un ejemplo ilustrativo, no un caso real, ayuda a ver dónde aparece el problema: una empresa despliega un agente de IA para clasificar y archivar documentos de clientes (facturas, contratos, correos) en su gestor documental. Durante el proyecto piloto, se le da acceso de lectura y escritura a toda la carpeta compartida del departamento, no solo a la bandeja de entrada que procesa. El piloto termina, el agente pasa a producción, y ese acceso amplio nunca se reduce porque nadie lo tiene asignado como tarea de nadie. Meses después, una instrucción ambigua —o un documento manipulado que el agente procesa sin que una persona lo revise— hace que mueva o sobrescriba archivos que nunca debería haber podido tocar. No hay interruptor de apagado inmediato, y el registro disponible no basta para reconstruir con exactitud qué tocó y cuándo. El fallo no está en el modelo: está en la gobernanza que nunca se construyó.

En Optima Quantum no desplegamos un agente de IA sin definir antes su gobierno de datos: qué puede tocar, con qué límite de propósito, con qué registro y con qué forma de cortarlo si hace falta. Si ya tienes agentes de IA en producción y no puedes responder hoy mismo a «qué datos puede tocar este agente y quién puede quitarle ese acceso», es exactamente lo que revisamos en una auditoría de ciberseguridad. Contáctanos y lo repasamos juntos antes de que lo descubras por un incidente.

Si entre esos datos están las ventas y el stock que alimentan tus pedidos, el gobierno de ese acceso tiene su propio ángulo en previsión de demanda con IA.

Preguntas frecuentes

¿Qué diferencia hay entre gobernar los datos de un agente de IA y gobernar los de una aplicación normal? Una aplicación ejecuta lo que está programada para hacer, dentro de un alcance fijo. Un agente de IA decide, en cada caso, qué acción tomar dentro del acceso que tiene — por eso el límite de propósito y el registro de auditoría importan más: sin ellos, no hay forma de saber qué decidió hacer y por qué.

¿Tener una política de acceso para agentes de IA ya es suficiente? No. Según Delinea (2026), el 99,7% de las empresas tiene una política escrita, pero solo el 51% la comprueba en tiempo real contra lo que el agente hace de verdad. Sin aplicación automática, la política es un documento, no un control.

¿Cuánto tarda una empresa en detectar un agente de IA comprometido? Según Akeyless (2026), 14 horas de media para detectarlo y cerca de 7 días para contenerlo y remediarlo del todo — tiempo suficiente para que un acceso indebido se traduzca en un daño real.

¿Esto solo afecta a empresas grandes con muchos agentes desplegados? No. El riesgo no depende del número de agentes, sino de si existe o no un límite de propósito y un interruptor de apagado para cada uno. Una pyme con un solo agente de IA conectado a su gestor documental o a su CRM necesita exactamente los mismos controles.

¿Por dónde se empieza a gobernar los datos de un agente que ya está en producción? Por lo más simple y lo que más empresas ignoran: mapear qué datos toca de verdad ese agente hoy (no lo que se le concedió «por si acaso»), comprobar si ese acceso se puede revocar sin apagar el sistema entero, y verificar si existe un registro capaz de responder, con evidencia, qué hizo el agente la última semana.

Relacionado: ese mapeo de accesos es más fiable cuando antes se ha hecho inventario de todas las credenciales de máquina que la empresa tiene activas, no solo las del agente que se está revisando — lo tratamos en identidades no humanas.