Las orientaciones de la AEPD sobre IA agéntica: 76 páginas que se leen como una especificación para gobernar automatizaciones
En febrero de 2026 la Agencia publicó el primer tratamiento con rango de regulador de los agentes de IA desde la protección de datos. Lo hemos leído de principio a fin. Esto es lo que pide, por qué importa más allá de la IA, y dónde Kimetai responde — y dónde no.
Siete insights, y dónde encaja Kimetai
Si solo lees una sección, que sea esta. Cada tarjeta enuncia lo que piden las orientaciones, en sus propios términos, y después qué significa para una empresa que opera agentes y automatizaciones — con la aportación de Kimetai y su límite dichos con claridad. El resto del artículo es la versión larga.
01 · Gobernanza primero
La Agencia identifica cuál es la amenaza raíz: desplegar agentes sin que la empresa los gestione como un sistema más de su gobernanza. Cuando eso ocurre — dice el texto — «no hay control de quién, cuándo, dónde, con qué propósito y qué datos personales se están tratando».
Kimetai — esa frase es el inventario: descubrimiento de cada agente y workflow, un responsable por automatización y registro de qué toca cada una. Límite: el descubrimiento cubre las plataformas conectadas, no cada secreto local de un portátil.
02 · La Regla de 2
Un agente tiene tres propiedades de riesgo — recibir entradas no confiables, acceder a datos sensibles y actuar de forma automática — y nunca debe reunir las tres a la vez. Como máximo dos, y cada pareja posible lleva asociado un control compensatorio obligatorio.
Kimetai — esto es una política: clasificar cada automatización en los tres ejes y enviar a REVIEW o BLOCK, antes de ejecutar, todo lo que toque los tres. Límite: la política decide; el bloqueo solo ocurre donde la integración la aplica en el punto de ejecución.
03 · Identidad y mínimo privilegio
Verificación criptográfica de identidad para los agentes, RBAC/ABAC granular, credenciales de vida corta, sin delegación de privilegios entre agentes fuera de flujos predefinidos, autenticación mutua en interacciones agente-a-agente.
Kimetai — un DID W3C y una Credencial Verificable firmada por automatización, acotada a acciones, con humano responsable, revocable globalmente. Límite: revocar la identidad en Kimetai no revoca el token del SaaS salvo que el conector lo haga.
04 · Puntos de control antes de acciones sensibles
Definir criterios y puntos de control «especialmente antes de que se ejecuten acciones sensibles»: las operaciones de alto impacto, irreversibles o con consecuencias legales requieren aprobación humana. Principio de los cuatro ojos para las más graves.
Kimetai — es el propósito entero del gateway de Kimetai: un veredicto ALLOW / REVIEW / BLOCK firmado antes de la acción, con un paso de aprobación humana ligado a la operación exacta. Límite: la aprobación debe vincularse a los parámetros; si cambia el destino, hay que reevaluar.
05 · Catálogo y listas blancas de servicios
Mantener un catálogo de todos los servicios que un agente puede invocar — modelos, herramientas, repositorios internos, APIs externas — y limitar cada tratamiento al conjunto máximo de herramientas que necesita.
Kimetai — el perfil de orquestación de cada automatización lista qué la dispara y sobre qué aplicaciones actúa; las políticas expresan el conjunto permitido por automatización. Límite: hacer cumplir la lista blanca exige que el runtime la respete.
06 · Trazabilidad con integridad
Linaje del dato a lo largo de todo el ciclo de vida, y un registro con control de integridad de responsabilidades, decisiones y acciones — con retención estricta, políticas no-log selectivas y usuarios seudonimizados.
Kimetai — una traza encadenada por hash y sellada eIDAS que guarda identidad, versión de política, parámetros, aprobador y resultado — y se trata a sí misma como tratamiento: payloads minimizados, retención que configuras. Límite: la integridad prueba que el registro no se alteró, no que fuera completo.
07 · No esconderse detrás del supervisor
La supervisión humana no puede usarse para desplazar a la persona que vigila la responsabilidad por fallos sistémicos de diseño. Los supervisores tienen un rol «dentro de unos límites» — la diligencia del responsable en el diseño no es delegable.
Kimetai — REVIEW existe para las pocas acciones que merecen un humano, no para cada cambio a velocidad de máquina; las rutinarias las decide la política, para que la persona en el bucle pueda mirar de verdad. Límite: qué acciones van a REVIEW es una decisión de diseño que pertenece al responsable.
Qué es el documento, y qué no
«Inteligencia artificial agéntica desde la perspectiva de protección de datos» (v1.2, febrero de 2026) tiene 76 páginas, y su resumen ejecutivo marca el tono: un agente de IA es un sistema que usa modelos de lenguaje para cumplir un objetivo, y el objeto del documento no es analizar el cumplimiento de un tratamiento concreto, sino explicar las peculiaridades que se incorporan a un tratamiento cuando se implementa, total o parcialmente, con agentes. Va dirigido expresamente a responsables y encargados que deciden si usarlos y cómo.
Llegó tres meses antes que la Memoria 2025 de la Agencia, que mostró cómo los procedimientos por brechas pasaban de 30 a 77. Esa Memoria la analizamos aparte: La AEPD multiplica los procedimientos por brechas de datos. Leídos juntos, un documento dice qué encontró la supervisión; este dice qué espera la Agencia que construyas.
Dos decisiones de encuadre importan. Primera, la Agencia rechaza ambos reflejos: tanto el «rechazo irracional» como la «aceptación acrítica» de los agentes se califican de perjudiciales, e insiste en que los agentes pueden ser en sí mismos una tecnología de mejora de la privacidad si se diseñan bien. Segunda, no es una lista de comprobación de cumplimiento ni una certificación — es una orientación. Las medidas del capítulo VII son cosas que un responsable «podría adoptar», seleccionadas según el riesgo de cada tratamiento. Nada en el documento hace obligatoria una herramienta concreta. Lo que hace es nombrar, con una precisión poco habitual, las propiedades que debe tener un agente gobernado.
La estructura sigue el arco de la gestión de riesgos: qué son los agentes (capítulo II), cómo entran en los tratamientos (III), las vulnerabilidades que añaden (IV), las obligaciones RGPD que tocan (V), las amenazas que explotan esas vulnerabilidades (VI) y las medidas que las abordan (VII). Seguimos el mismo arco.
Cuatro vulnerabilidades propias de los agentes
El capítulo IV es donde el documento justifica su extensión. En lugar de repetir lo que ya se sabe de la IA generativa, aísla qué cambia cuando a un modelo se le da capacidad de actuar. Cuatro familias:
A · Interacción con el entorno
El agente lee datos de la organización y del usuario, y percibe y actúa fuera de la organización. Cada conexión es a la vez una ruta de datos y un actor con alcance.
B · Integración de servicios
Los agentes son fáciles de desplegar y encadenar a servicios externos. La Agencia señala la propia facilidad como vulnerabilidad: los servicios se multiplican más rápido de lo que se gestionan.
C · Memoria
La memoria de trabajo y la de largo plazo acumulan datos personales entre tareas y usuarios. Una memoria sin compartimentar hace que un tratamiento se filtre en otro — y los derechos de los interesados se vuelven difíciles de atender.
D · Autonomía
Planificación de tareas, interacción entre agentes, comportamiento no repetible y capacidad de actuar en nombre del usuario o de la organización. La salida no puede revisarse como un informe — ya ha ocurrido.
Fíjate en lo que tienen en común las cuatro. Ninguna trata de la calidad del modelo. Las cuatro tratan de la autoridad del agente en el entorno: qué puede leer, qué puede invocar, qué recuerda y qué puede hacer sin preguntar. Ese es el eje sobre el que se construyó Kimetai — y también la razón por la que, como argumentamos al final, tres de las cuatro aplican igual a un workflow determinista sin modelo dentro.
La Regla de 2
La idea más operativa del documento es prestada — la Agencia atribuye a la «rule of 2» de Chromium de 2021 para seguridad de navegadores y a su reformulación posterior para agentes — y se presenta como un «umbral mínimo de garantías que jamás hay que traspasar». Un agente tiene tres propiedades peligrosas. Puede tener como máximo dos.
- 1
- Trata información no controlada — correo, web, documentos, otro agente.
- 2
- Accede a información sensible o datos personales.
- 3
- Realiza acciones automáticas con efecto dentro o fuera de la organización.
- 1+2
- Ninguna acción automática sin supervisión humana.
- 2+3
- Solo con garantías de integridad y seguridad de la información interna y externa.
- 1+3
- Hay que impedir al agente el acceso a información sensible o datos personales.
- 1+2+3
- Una configuración que «no se debería permitir».
El propio ejemplo de la Agencia es un agente que responde correos automáticamente: recibe mensajes no confiables (1), puede alcanzar datos sensibles en los sistemas del usuario (2) y puede enviar respuestas o reescribir registros (3). Ese es el triángulo prohibido. La automatización de triaje de soporte de nuestra Home tiene la misma forma — por eso su superficie de riesgo cae donde cae.
El documento se cuida de añadir que esto es un mínimo de seguridad, no un techo de protección de datos: incluso una pareja conforme sigue necesitando minimización, exactitud de las entradas y los límites adicionales que aplican a categorías especiales y a menores. Pero como primera criba de un inventario es notablemente útil — y es una clasificación que una plataforma de gobernanza puede calcular para cada automatización que descubre.
Cumplimiento: roles, el registro, el artículo 22
El capítulo V recorre el RGPD. Tres puntos merecen destacarse.
Los roles se multiplican. Un stack agéntico implica al desarrollador del modelo, al proveedor de la plataforma agéntica, a los proveedores de herramientas externas y a la organización que lo despliega. Las orientaciones piden al responsable determinar quién es responsable, encargado o corresponsable de cada uno — y, en las medidas de gobernanza, «formalizar las relaciones con los terceros que permiten desplegar agentes», aclarando obligaciones, niveles de servicio y las «funcionalidades para mantener el control». Un encargado que no ves en tu inventario es un encargado que no has formalizado.
El registro de actividades de tratamiento tiene que seguir al agente. El artículo 30 no tiene excepción para software que se reconfigura solo. Si un agente empieza a leer un repositorio nuevo o a escribir en un destino nuevo, el RAT queda desactualizado en ese mismo instante. Las orientaciones tratan mantener el registro al día como una obligación viva, lo que en la práctica significa que el inventario que lo alimenta también tiene que estarlo.
Automatización no siempre es decisión automatizada — pero tienes que saber cuál es cuál. Aquí las orientaciones son precisas: un agente que resume noticias del sector para empleados según sus intereses declarados no es una decisión del artículo 22. Uno que afecta a las circunstancias de una persona, tiene un impacto prolongado o puede excluir o discriminar, sí lo es — y entonces aplican las condiciones del 22.2–22.4, los deberes de transparencia de los artículos 13 y 14 y los límites adicionales sobre categorías especiales y menores. No puedes tomar esa decisión sobre una automatización que no has clasificado.
Las amenazas que nombra la Agencia
El capítulo VI separa las amenazas procedentes del propio tratamiento autorizado de las procedentes de tratamientos no autorizados (inyección de prompts, fallo de servicios externos, acceso ilícito a la memoria del agente). El primer grupo es el más interesante, porque va enteramente de decisiones propias de la organización. En el orden de la Agencia:
- Falta de gobernanza y políticas — la amenaza de base, citada en el insight 01.
- Falta de madurez en el desarrollo — flujos complejos construidos con personal no cualificado o métodos inmaduros incumplen la protección de datos desde el diseño.
- Falta de política de acceso a datos de la organización y del usuario, especialmente repositorios no estructurados.
- Falta de control del proceso de razonamiento y del acceso a información externa; exfiltración shadow-leak.
- Desplazar toda la responsabilidad al usuario o al supervisor humano — insight 07.
- Memoria sin compartimentar, información no estructurada y metadatos sin filtrar, retención excesiva.
- Sesgo de automatización, perfilado de los propios usuarios del agente, disponibilidad y resiliencia, acceso por usuarios no cualificados, compromisos en la cadena de suministro.
Lee esa lista contra lo que una empresa mediana europea tiene realmente funcionando y deja de ser abstracta. El agente programado de marketing contra el CRM no tiene política de acceso a datos porque nadie la escribió. El workflow de finanzas que replica facturas lo construyó alguien que ya no está — desarrollo inmaduro, sin supervisión, sin dueño. La memoria del bot de soporte guarda todas las conversaciones de clientes desde el lanzamiento — retención excesiva, sin compartimentar. Cada elemento de la lista de la Agencia tiene su correlato en un inventario real.
Las medidas, leídas como especificación
El capítulo VII va de la página 54 a la 73 y se organiza en nueve bloques: gobernanza y procesos de gestión; evaluación continua basada en evidencias; minimización de datos; control de la memoria; automatización; control del agente desde el diseño; consentimiento; transparencia; alfabetización. Tres de ellos se leen casi como requisitos de producto.
Gobernanza (VII.A) abre con una línea digna de enmarcar — «aceptar la posibilidad de fallo» — y después enumera lo que la gobernanza de la organización tiene que absorber: asignar roles para los agentes; anticipar efectos colaterales; determinar casos de uso y perfiles de usuario por tratamiento; fijar criterios de selección de agentes, componentes y conexiones externas; controlar el rediseño de los tratamientos cuando entran agentes; formalizar terceros; controlar despliegue, monitorización, mantenimiento y retirada; integrar con la gestión de incidentes y las obligaciones de brechas; y mantener «monitorización, supervisión y auditoría continua» con procedimientos de respuesta claros.
Automatización (VII.E) es el bloque que un CTO debería leer dos veces: decidir el grado de autonomía por tratamiento; diseñar cadenas de razonamiento seguras; mantener catálogo y lista blanca de servicios; limitar los servicios accesibles por tratamiento; controlar la ejecución de herramientas — parámetros de entrada, respuestas de salida, acción humana para herramientas de alto impacto; definir puntos de control antes de acciones sensibles; garantizar reversibilidad; prever rutas de escalamiento; aplicar el principio de los cuatro ojos en los casos más graves.
Control desde el diseño (VII.F) es el bloque que un CISO debería leer dos veces: documentación con control de integridad de responsabilidades, decisiones y acciones; profesionales cualificados; trazabilidad como linaje completo del dato; tests de verificación y validación; procedimientos operativos estándar para los prompts; mecanismos de repetibilidad; gestión de identidad, autenticación y privilegios bajo mínimo privilegio; control estricto de actualizaciones; sandboxing; protocolos de detección de errores y planes de contingencia; control del flujo de extracción de datos; cortacircuitos y límites duros de pasos; controles de calibrado y alineación entre pasos del razonamiento.
Medida a medida frente a Kimetai
Preferimos ser específicos a ser tranquilizadores. La tabla proyecta las medidas que caen en el ámbito de una plataforma de gobernanza sobre lo que hace Kimetai, y enuncia la condición bajo la que cada una es realmente eficaz. Las medidas que pertenecen a otro sitio — higiene de la memoria dentro del runtime del modelo, procedimientos para prompts, sandboxing del desarrollo, gestión del consentimiento, alfabetización — quedan fuera de nuestro alcance y no se listan.
| Medida AEPD | Kimetai | Eficaz cuando |
|---|---|---|
| Asignar roles; controlar despliegue, monitorización y retirada (VII.A) | Discovery inventaría cada agente y workflow de las plataformas conectadas; la promoción asigna un responsable con nombre y un identificador único. | Las plataformas donde viven las automatizaciones están conectadas. Discovery no ve scripts locales ni API keys personales fuera de ellas. |
| Identidad, autenticación y privilegios bajo mínimo privilegio (VII.F) | DID W3C + Credencial Verificable firmada por automatización, acotada a acciones, con humano responsable; revocación global en segundos. | El sistema destino valida la credencial, o el conector traduce la revocación al token del SaaS. Una identidad de Kimetai no desactiva por sí sola una clave externa. |
| Catálogo y listas blancas; limitar servicios accesibles (VII.E) | El perfil de orquestación registra activadores y aplicaciones sobre las que actúa; las políticas definen el conjunto permitido por automatización y departamento. | El runtime consulta la política antes de invocar una herramienta. Una lista blanca que el agente puede saltarse es documentación, no control. |
| Puntos de control antes de acciones sensibles; cuatro ojos (VII.E) | El gateway devuelve un ALLOW / REVIEW / BLOCK firmado antes de ejecutar; REVIEW enruta a una aprobación humana ligada a la operación y parámetros exactos. | La integración aplica el veredicto en el punto de ejecución — gateway en línea o ejecutor controlado — y las rutas directas están cerradas. Un PDP solo decide; no bloquea. |
| Cortacircuitos y límites duros de pasos (VII.F) | Políticas sobre volumen acumulado, frecuencia y duplicados: la tercera orden de compra duplicada incumple la política y se avisa a un humano. | Cada acción pasa por el punto de decisión. Las acciones por una ruta no cubierta no se cuentan. |
| Trazabilidad como linaje del dato; documentación con control de integridad (VII.F) | Traza encadenada por hash y sellada eIDAS por evento: identidad, versión de política, parámetros, aprobador, resultado — exportable por normativa. | La captura cubre las fuentes instrumentadas. La integridad prueba no alteración, no exhaustividad; el resultado debe corroborarlo el destino, no declararlo el agente. |
| Retención estricta; no-log selectivo; usuarios seudonimizados (VII.C, VII.D) | Payloads de evento minimizados — decisión y metadatos, no contenido — y ventanas de retención que el cliente configura por plan. | El cliente define una matriz de conservación con su fundamento. No hay una regla RGPD universal de retención de logs, y un hash no es automáticamente anónimo. |
| Integrar con gestión de incidentes y obligaciones de brechas (VII.A) | Reconstrucción de una ejecución de principio a fin; exportación a SIEM e ITSM para que el reloj de 72 horas arranque con hechos, no con una búsqueda. | La valoración del riesgo y la decisión de notificar siguen siendo del responsable. Una alerta entregada no es una contención ejecutada. |
La columna de la derecha es la parte honesta. Las propias orientaciones hacen la misma distinción cuando dicen que un PDP «decide» y un PEP «aplica»: una plataforma de gobernanza aporta control exactamente donde su decisión se aplica en el punto de ejecución, y aporta visibilidad en todo lo demás. Ambas cosas valen. No son lo mismo, y no vamos a describirlas como si lo fueran.
Por qué esto aplica también a tus workflows
El documento va de agentes. Pero vuelve a sus cuatro vulnerabilidades y pregúntate cuáles requieren un modelo de lenguaje. La interacción con el entorno, no: un webhook lee y escribe entre sistemas. La integración de servicios, no: un escenario de n8n encadena cinco APIs SaaS. La autonomía — actuar en nombre de la organización sin que nadie haga clic — tampoco. Solo la memoria es específica de los modelos, y hasta eso tiene un primo determinista en las tablas de staging que nadie purga.
Lo mismo vale para las medidas. Identidad y mínimo privilegio, listas blancas de servicios, puntos de control antes de acciones sensibles, cortacircuitos, trazabilidad, integración con la respuesta a incidentes — a ninguna le importa si lo que se gobierna decide con un modelo o con un if. Lo que añade el agente es variabilidad en cómo alcanza su objetivo, lo que sube el listón. No cambia de tema.
La Agencia escribió una especificación para gobernar agentes. Leída quitando el modelo, es una especificación para gobernar la automatización — y la mayoría de las tuyas no tienen modelo dentro.
Por eso construimos Kimetai para las dos especies desde la primera conexión, y por eso el inventario — no el motor de políticas, no la traza de auditoría — es donde empieza cada conversación con un cliente. La propia amenaza de base de las orientaciones lo dice en una línea: sin gobernanza, no hay control de quién, cuándo, dónde, con qué propósito y qué datos personales se están tratando. No puedes gobernar lo que no has descubierto.
Fuentes citadas
- [1]AEPD, «Inteligencia artificial agéntica desde la perspectiva de protección de datos», v1.2, febrero de 2026, 76 pp. — capítulos IV (vulnerabilidades), V.G (Regla de 2, pp. 41–43), VI (amenazas, pp. 45–54) y VII (medidas, pp. 54–73). Enlace aquí.
- [2]AEPD, nota de prensa de publicación de las orientaciones, 18 de febrero de 2026. Enlace aquí.
- [3]Chromium, «The Rule of 2» (seguridad de navegadores), citada por la AEPD como origen de la formulación para agentes. Enlace aquí.
- [4]Reglamento (UE) 2016/679 (RGPD) — arts. 5, 13, 14, 22, 24, 25, 28, 30, 32–35. Enlace aquí.
- [5]Documentación de Open Policy Agent — separación entre decisión y aplicación de políticas. Enlace aquí.
Informativo. No constituye asesoramiento jurídico. Las orientaciones son una orientación, no una certificación: no hacen obligatorio ningún producto ni certifican a Kimetai. Lo que se afirma sobre Kimetai describe su diseño y las condiciones bajo las que cada control es eficaz.