Reglamento de IA + RGPD artículo 32: checklist de cumplimiento en 12 puntos

Las políticas no son pruebas

El marco de cooperación del EDPB publicado en 2025 dejó claro a cualquier DPO europeo: las autoridades no le piden demostrar que tiene políticas de IA. Le piden demostrar que esas políticas se aplican. La distinción es decisiva. Un PDF de 40 páginas titulado «Uso aceptable de la IA generativa» almacenado en SharePoint no es una prueba. Un registro con marca de tiempo que muestra que el 14 de marzo a las 11:42 un empleado intentó pegar un contrato de cliente en ChatGPT y que su capa DLP redactó tres nombres y un IBAN antes de la transmisión — eso sí lo es.

Esta checklist conecta las obligaciones del Reglamento de IA (artículo 4 sobre alfabetización en IA, artículo 26 sobre deberes de los responsables del despliegue de alto riesgo, artículo 50 sobre transparencia) con el RGPD artículo 32 (seguridad del tratamiento) y artículo 35 (EIPD). Para cada punto: la obligación en una frase, la prueba que la AEPD pedirá, el artefacto concreto que debe producir ya. Cuando el registro de auditoría de Zeuslock interviene, lo decimos — no porque toda casilla deba marcarse con un proveedor, sino porque la mayoría de los CISO con los que trabajamos descubren, en la inspección, que la pieza ausente es siempre la misma: un registro continuo de quién envió qué a qué herramienta de IA.

La checklist de 12 puntos

1. Artículo 4 — Alfabetización en IA. Los responsables del despliegue deben garantizar un nivel suficiente de alfabetización en IA entre el personal usuario, proporcional al riesgo. Prueba esperada: un inventario actualizado de cada herramienta de IA usada por empleados (sancionadas y shadow), revisado al menos trimestralmente, junto con registros de finalización de formación asociados a los puestos que tratan datos personales. Producir ya: un CSV de inventario con nombre de herramienta, proveedor, región de alojamiento, categorías de datos permitidas, responsable y fecha de última revisión. La parte de shadow IA es la que falta con más frecuencia — una capa de descubrimiento pasiva (la extensión de Zeuslock señala DeepSeek, Perplexity, Poe y cualquier destino no sancionado por defecto) cubre ese hueco.

2. Artículo 50 — Transparencia frente al personal y los interesados. Cuando una IA interactúa con personas o trata sus datos, ese hecho debe revelarse de forma clara y accesible. Prueba esperada: un aviso de transparencia por herramienta, más registros que muestren que el destino (modelo, proveedor, región) de cada interacción se registró y se presentó al usuario. Producir ya: una pantalla de onboarding o banner que enumere las herramientas de IA permitidas y sus características de tratamiento, y una política de retención que capture URL de destino, modelo y marca de tiempo de cada prompt.

3. Artículo 26 — Supervisión de los responsables del despliegue de alto riesgo. Los responsables del despliegue de sistemas de IA de alto riesgo deben supervisar el funcionamiento y conservar los registros generados automáticamente durante al menos seis meses. Prueba esperada: registro continuo de entradas y salidas de los sistemas de IA usados en RR. HH., crédito, empleo o seguridad — recomendamos un suelo de retención de 13 meses para cubrir un ciclo de auditoría completo (revisión anual + 1 mes). Producir ya: envíe los registros de interacción IA a su SIEM con huellas hash de las entradas (no texto en claro, para respetar la minimización del artículo 32) y la decisión de política aplicada.

4. RGPD artículo 32 — Medidas técnicas del estado del arte. Confidencialidad, integridad, disponibilidad y resiliencia del tratamiento, con medidas proporcionales al riesgo. Prueba esperada: controles documentados que muestren que los datos personales se anonimizan antes de enviarse a un LLM de terceros, más pruebas que demuestren que los controles funcionan. Producir ya: una matriz de redacción que liste qué categorías de datos (api_key, IBAN, tarjeta, DNI, email, teléfono, código fuente) se bloquean, anonimizan o monitorizan por destino IA, con una prueba de regresión automatizada semanal.

5. RGPD artículo 35 — Evaluación de impacto (EIPD). Una EIPD es obligatoria para todo tratamiento que pueda entrañar alto riesgo — el uso de IA generativa sobre datos personales casi siempre lo es. Prueba esperada: una EIPD que cubra el flujo de prompts en sí, no solo el proceso de negocio subyacente, validada por el DPO. Producir ya: una plantilla de EIPD que aborde explícitamente el contenido del prompt, el proveedor del modelo, la región de alojamiento, la retención por parte del proveedor y el riesgo de reidentificación. La lista de tratamientos sujetos a EIPD de la AEPD y su guía sobre IA generativa son un punto de partida útil.

6. RGPD artículo 5(2) — Responsabilidad proactiva. El responsable debe poder demostrar el cumplimiento. Prueba esperada: un único cuadro de mando donde una autoridad pueda ver, para cualquier intervalo de fechas, el volumen de interacciones IA, el número de intervenciones de política, las categorías de datos interceptadas y la resolución de cada incidente. Producir ya: una exportación mensual desde su capa DLP a un dossier para el consejo — la Operator Console de Zeuslock lo exporta como CSV en un clic.

7. RGPD artículo 28 — Encargados del tratamiento. Cada proveedor de IA que utilice es un encargado (a veces corresponsable). Necesita un contrato de encargo, CCT cuando proceda y una posición clara sobre el entrenamiento con datos del cliente. Prueba esperada: contratos firmados con OpenAI, Anthropic, Google, Microsoft, más la confirmación de opt-out de entrenamiento para cada uno. Producir ya: una fila por proveedor de IA en el registro de encargados, con referencia contractual, región de alojamiento, lista de subencargados y estado de entrenamiento.

8. RGPD artículo 25 — Protección de datos desde el diseño. Las medidas técnicas y organizativas deben integrarse en el propio tratamiento, no añadirse después. Prueba esperada: evidencia de que la detección se ejecuta antes de que el prompt salga del endpoint, no a posteriori en el análisis de logs. Producir ya: un diagrama de arquitectura que muestre la interceptación en cliente (extensión de navegador o agente de escritorio) con la ruta de red que hace imposible el escenario «el dato ya salió».

9. RGPD artículos 33-34 — Notificación de brechas. Un prompt que contenga datos personales sin redactar enviado a un LLM de terceros constituye una brecha notificable a la AEPD en la práctica totalidad de casos. Prueba esperada: un runbook de incidentes que trate la exfiltración vía IA como un incidente de datos personales, con el reloj de 72 horas arrancando en la detección. Producir ya: un webhook Slack/Splunk que avise al DPO en cualquier decisión Block que implique más de un número configurable de identificadores personales por prompt.

10. Reglamento de IA artículo 15 — Robustez y ciberseguridad. Los sistemas de IA deben ser resilientes frente a intentos de alterar su comportamiento — jailbreaks, inyección de prompts, evasión del modelo. Prueba esperada: pruebas documentadas de inyección de prompts y jailbreak contra cualquier agente IA o chatbot interno, con resultados y remediaciones. Producir ya: un ejercicio de red team trimestral; si opera agentes basados en MCP, una capa DLP que inspeccione ambos sentidos del intercambio agente ↔ herramienta (ahí se sitúa la integración MCP de Zeuslock).

11. RGPD artículo 22 — Decisiones automatizadas. Una decisión exclusivamente automatizada con efectos jurídicos o significativamente similares requiere consentimiento explícito o necesidad contractual, más derecho a revisión humana. Prueba esperada: registros por decisión con la salida IA, el revisor humano y la tasa de override. Producir ya: un esquema de registro de decisión con campos {decision_id, modelo, hash_entrada, salida, revisor, override, marca_tiempo}.

12. RGPD artículo 30 — Registro de actividades de tratamiento. Su RAT debe listar explícitamente los tratamientos mediados por IA — muchos aún no lo hacen. Prueba esperada: una entrada por caso de uso IA con finalidad, base jurídica, categorías de datos, destinatarios, retención y mecanismo de transferencia internacional. Producir ya: una fila por herramienta de IA que cruce la frontera de la UE, con la versión de CCT y la referencia a la evaluación de impacto de transferencias. La AEPD ofrece una plantilla de RAT actualizada; añádale un anexo IA.

13. NIS2 — Riesgo de cadena de suministro. Si está sujeto a NIS2 (entidad esencial o importante), sus proveedores de IA forman parte de su evaluación de riesgo de terceros. Prueba esperada: un cuestionario de proveedor que cubra región de alojamiento, subencargados, procedencia del modelo y capacidad de desactivar el entrenamiento. Producir ya: una «ficha de evaluación de proveedor IA» de una página anexada a su revisión de seguridad de terceros estándar.

Por qué el registro continuo es el artefacto que soporta todo

Once de los doce puntos anteriores se reducen, en la práctica, a un requisito técnico único: un registro a prueba de manipulación de cada interacción IA, con la decisión que aplicó la capa DLP. La posición del EDPB en su dictamen de 2025 sobre IA generativa converge con la de las autoridades nacionales — AEPD, CNIL, ICO — en el mismo estándar probatorio: continuo, consultable, conservado al menos tanto como el ciclo de auditoría.

Es el hueco que ningún documento de política puede cerrar. Una política dice «los empleados no deben pegar datos de clientes en ChatGPT»; un registro de auditoría prueba que un día determinado se enviaron 1 847 prompts, 23 contenían datos personales, 21 se anonimizaron al vuelo, 2 se bloquearon, y al usuario se le mostró la política cada vez. Es exactamente lo que el artículo 5(2) RGPD llama responsabilidad proactiva.

Qué hacer este trimestre

1. Inventariar y clasificar. Antes de fin de trimestre, produzca un inventario completo de las herramientas de IA en uso — incluidas las shadow detectadas en una pasada de descubrimiento — clasificadas por sensibilidad del dato y por nivel de riesgo del Reglamento de IA.
2. Activar el registro continuo. Elija una capa DLP que registre cada prompt IA con destino, modelo, decisión de política y resultado. Fije la retención en 13 meses como mínimo. Envíe una copia a su SIEM.
3. Ejecute una EIPD de principio a fin. Elija su caso de uso IA de mayor volumen y complete una EIPD según el artículo 35, con el flujo de prompts dentro del alcance. Hágala firmar por su DPO. Ese único artefacto le dirá cuál de los otros 11 puntos es el más débil.

El registro de auditoría es la columna vertebral de toda conversación sobre el artículo 32 en 2026. Constrúyalo primero y el trabajo de gobernanza tendrá dónde aterrizar.