El ICO acaba de convertir la seguridad de la IA en una obligación bajo el artículo 32 del RGPD del Reino Unido
5 conclusiones clave
1. La seguridad de la IA ahora es un deber de protección de datos.
La nueva guía de la ICO presenta las amenazas impulsadas por IA como una obligación actual bajo el Artículo 32 del RGPD del Reino Unido, no como un riesgo futuro. Se espera que las organizaciones que gestionan datos personales actúen ya.
2. Siete tipos de ataques están en el radar del regulador.
Phishing potenciado por IA, ingeniería social con deepfakes, escaneo automatizado de vulnerabilidades, malware impulsado por IA, credential stuffing, envenenamiento de datos e inyección indirecta de prompts aparecen todos en la guía.
3. Cinco pasos forman la nueva base de cumplimiento.
Análisis de amenazas emergentes, fundamentos de seguridad, protección de datos personales, gobernanza de IA en capas y monitoreo con respuesta a incidentes. Ninguno es nuevo. La urgencia combinada sí lo es.
4. Ahora se requieren EIPD para procesamiento de IA de alto riesgo.
Las organizaciones que usan herramientas de IA que procesan datos personales de alto riesgo deben realizar una evaluación de impacto de protección de datos y establecer protecciones contra ataques dirigidos a la IA.
5. Capita es el precedente que todos deberían leer.
La multa de 14 millones de GBP impuesta por la ICO a Capita en octubre de 2025 se basó en «medidas técnicas y organizativas apropiadas» bajo el Artículo 32. El mismo estándar ahora aplica a la infraestructura de IA.
Lo que realmente dijo la ICO el 13 de mayo de 2026
El 13 de mayo de 2026, Ian Hulme, Director Ejecutivo Interino de Supervisión Regulatoria de la ICO,
publicó
un artículo del blog titulado «Five steps to protect your organisation from AI-powered cyber threats»
(nota: se mantiene la ortografía británica del título). Es breve. Es directo.
Y para cualquier organización que procese datos personales en el Reino Unido, es la señal más clara hasta ahora
de que la seguridad de la IA ya no es una cuestión de cumplimiento a futuro.
La guía comienza con una lista de amenazas que el regulador está siguiendo: phishing potenciado por IA que genera
mensajes personalizados altamente convincentes, audio y video deepfake usados para suplantar colegas,
herramientas automatizadas que escanean sistemas rápidamente y explotan debilidades, malware impulsado por IA que adapta su
comportamiento para evadir la detección, credential stuffing acelerado por IA, envenenamiento de datos contra modelos en
producción e inyección indirecta de prompts donde instrucciones maliciosas se incrustan en contenido externo que un sistema de IA procesa como comandos legítimos.
Luego viene la parte que debería cambiar la postura en cada oficina de CISO y DPO: «Tus obligaciones bajo
el RGPD del Reino Unido requieren que implementes medidas técnicas y organizativas apropiadas para proteger los datos personales». El regulador no está introduciendo un nuevo marco. Está mapeando las amenazas de IA sobre el
marco vigente desde 2018 y diciendo, en efecto, que el estándar aplica ya, a velocidad de IA, sin periodo de gracia.
Por qué esto redefine el Artículo 32 en la práctica
El Artículo 32 del RGPD del Reino Unido exige «medidas técnicas y organizativas apropiadas» calibradas al
riesgo del procesamiento. La ICO ha pasado los últimos 18 meses demostrando, a través de acciones, cómo
luce ese estándar cuando los controles fallan. El precedente más claro es
la
multa de 14 millones de GBP a Capita impuesta en octubre de 2025, tras un ciberataque en 2023 que expuso los
datos personales de 6,6 millones de personas. El regulador concluyó que Capita no implementó medidas técnicas y organizativas apropiadas, incluyendo protecciones insuficientes para datos de categoría especial, controles deficientes para evitar el movimiento lateral de atacantes en la red y una respuesta inadecuada a alertas tempranas.
Capita no es un caso de IA. Pero el marco aplicado por el regulador es idéntico al que Hulme
ahora extiende a las amenazas de IA. El mismo razonamiento del Artículo 32 que produjo una multa de 14 millones de GBP por respuesta lenta a incidentes y controles de acceso débiles generará futuras sanciones por no gobernar sistemas de IA que gestionan datos personales. La prueba legal no cambia porque el vector de amenaza sea IA. El listón técnico simplemente sube.
La implicación para los consejos directivos es directa. Cuando ocurra la próxima gran filtración de datos personales relacionada con IA en el Reino Unido, el regulador no preguntará si la organización implementó defensas contra inyección de prompts. Preguntará si la organización puede demostrar autenticación, control de acceso, cifrado, monitoreo, respuesta a incidentes y evaluación de riesgos documentada para el sistema de IA que accedió a datos personales. La lista resulta familiar porque es la misma que Capita no cumplió.
Cómo leer los cinco pasos desde la perspectiva de los datos personales
El primer paso es el análisis de amenazas emergentes: entender cómo lucen realmente las amenazas impulsadas por IA en tu
entorno. La ICO nombra siete categorías. La mayoría de los equipos de seguridad pueden describir tres o cuatro. La distancia
entre la expectativa del regulador y la conciencia operativa es el primer riesgo.
El segundo paso son los fundamentos de seguridad: los cinco controles técnicos del esquema Cyber Essentials, el
Código de Buenas Prácticas de Gobernanza de Ciberseguridad, autenticación multifactor en todo acceso remoto, cuentas de administrador y
correo electrónico, políticas de contraseñas robustas y un proceso sólido de aplicación de parches. No son nuevos. El punto de la ICO es
que son el mínimo. La IA no cambia el requisito. Cambia la velocidad con la que una falla
se convierte en una filtración.
El tercer paso es la protección de datos personales: minimización de datos, auditorías regulares de qué datos personales se
tienen y dónde, y capacitación del personal sobre ingeniería social potenciada por IA. Los problemas de higiene de datos que han
impulsado la mitad de las acciones recientes de cumplimiento se concentran en este paso.
El Informe de Pronóstico de Seguridad y Cumplimiento de Datos de Kiteworks: 2026 encontró que solo el 36% de las organizaciones tiene
visibilidad sobre cómo los socios gestionan datos en sistemas de IA, y el 35% cita los datos personales en prompts como una de las principales exposiciones de privacidad, confiando la mayoría en políticas y capacitación en lugar de controles técnicos. La política no evita que alguien pegue una lista de clientes en un asistente público de IA a las 11 p.m.
El cuarto paso son las defensas en capas y la gobernanza de IA. La ICO destaca, específicamente: EIPD para
procesamiento de IA de alto riesgo, protecciones contra ataques dirigidos a IA, cumplimiento del Código de Buenas Prácticas de Ciberseguridad de IA del gobierno del Reino Unido y consideración de cifrado y seudonimización para reducir el impacto de una filtración. «En capas» es la palabra clave. La defensa de un solo control lleva una década fallando en ciberseguridad.
La IA reduce la ventana de fallo.
El quinto paso es monitoreo, gobernanza de la cadena de suministro y respuesta a incidentes. La guía exige
monitoreo integral de seguridad para actividades sospechosas como patrones inusuales de inicio de sesión, transferencias inesperadas de datos y uso anormal de API. Pide mapear qué pueden acceder terceros, exigirles estándares de seguridad adecuados e incluir requisitos de seguridad en los contratos. Exige un plan de respuesta a incidentes mantenido y probado regularmente.
Cuando la brecha de contención se convierte en responsabilidad de cumplimiento
El énfasis de la ICO en defensas en capas y gobernanza de IA apunta directamente a una brecha documentada en el
mercado. El Informe de Pronóstico 2026 halló que el 63% de las organizaciones no puede imponer limitaciones de propósito a
agentes de IA, el 60% no puede terminar rápidamente uno que se comporte mal y el 55% no puede aislar sistemas de IA del
acceso a la red general. Estos son los controles de contención —la capacidad de detener la IA cuando algo
sale mal— y son las mayores brechas en toda la
investigación propietaria de Kiteworks.
Lee esa brecha frente a la expectativa de la ICO. El regulador quiere ver supervisión humana, respuesta a incidentes
y la capacidad de contener daños cuando un control falla. Una organización cuyos agentes de IA
no pueden ser terminados rápidamente o aislados de sistemas sensibles es, según el marco del regulador, una
organización sin medidas técnicas y organizativas apropiadas. El cálculo de la multa de Capita —
punto de partida de 58 millones de GBP, reducido a 14 millones tras acuerdo— es una ventana a cómo
luce «apropiado» en la práctica cuando los controles no alcanzan.
La exposición a IA de terceros agrava el problema. El Informe de Pronóstico 2026 halló que el 30% de las organizaciones cita
la gestión de datos por parte de proveedores de IA de terceros como una de las principales preocupaciones de seguridad, pero solo el 36% tiene alguna visibilidad sobre cómo
los socios gestionan datos en sistemas de IA. El 64% restante depende de contratos y cuestionarios para
protegerse de riesgos que no pueden ver. La guía de la ICO es explícita en este punto: las organizaciones deben
mapear qué pueden acceder terceros, exigirles estándares de seguridad adecuados e incluir requisitos de seguridad
en los contratos. El
Informe de Amenazas de Datos Thales 2026 corrobora
la crisis de visibilidad: solo un tercio de las organizaciones sabe completamente dónde se almacenan sus datos y solo el 39% puede clasificarlos todos. La IA se apoya sobre esa base ya frágil.
Cómo las EIPD y las defensas contra ataques dirigidos a IA pasan de opcionales a obligatorias
La ICO es clara respecto a las EIPD para procesamiento de IA de alto riesgo. Si tu organización utiliza herramientas de IA que
procesan datos personales de alto riesgo, necesitas una evaluación de impacto de protección de datos documentada y protecciones
adecuadas contra ataques dirigidos a IA. «Mejor práctica opcional» ya no es el enfoque. «Expectativa documentada bajo los Artículos 35 y 32» sí lo es.
Los datos del Informe de Pronóstico 2026 sobre esta brecha son contundentes. El 74% de las organizaciones no afectadas por la Ley de IA de la UE carecen de evaluaciones de impacto de IA. El 84% no ha realizado red-teaming de IA. El 72% carece de vinculación de propósito. Incluso entre las organizaciones dentro del alcance de la Ley de IA de la UE, los porcentajes comparables son 41%, 61% y 46%. La Ley y la ICO convergen en la misma expectativa. La mayoría de las organizaciones no está lista.
Los hallazgos del Informe de Amenazas Internas DTEX 2026 refuerzan la
brecha desde otra perspectiva: el 92% de las organizaciones dice que la IA generativa ha cambiado fundamentalmente cómo
los empleados acceden y comparten información, pero solo el 13% ha integrado formalmente la IA en sus estrategias de negocio. La brecha estratégica es la brecha de gobernanza.
Los ataques dirigidos a IA tienen un significado específico que la ICO ahora incorpora al Artículo 32. Inyección indirecta de prompts, donde los adversarios incrustan instrucciones maliciosas en los datos que el sistema de IA recupera en tiempo de inferencia. Envenenamiento de datos, donde los atacantes corrompen datos de entrenamiento o manipulan salidas. Envenenamiento de herramientas, donde instrucciones se esconden en los metadatos de herramientas con las que interactúa un agente de IA. No son amenazas cibernéticas genéricas. Son clases de explotación específicas de IA que las reglas tradicionales de DLP, EDR y SIEM no fueron diseñadas para detectar. La defensa debe estar donde ocurre el acceso a los datos por parte de la IA.
Cómo Kiteworks operacionaliza los cinco pasos de la ICO para quienes gestionan datos personales
La guía de la ICO no menciona a ningún proveedor. No es necesario. La arquitectura que describe está
bien definida: acceso autenticado, defensas en capas, cifrado y seudonimización, monitoreo en
la capa de datos, preparación para respuesta a incidentes y gobernanza documentada. Kiteworks Compliant AI se
construyó exactamente sobre este conjunto de controles.
Kiteworks Compliant AI
gobierna el acceso de agentes de IA en la capa de datos en lugar de la capa de modelo o aplicación. Cada solicitud de IA
se autentica vía OAuth 2.0 con tokens almacenados en el llavero del sistema operativo y nunca
expuestos al modelo. Cada operación se evalúa en tiempo real contra políticas de control de acceso basado en atributos y control de acceso basado en roles. Cada interacción genera una entrada de registro de auditoría a prueba de manipulación,
transmitida a SIEM sin limitaciones. El cifrado validado FIPS 140-3 protege los datos en tránsito y en
reposo. El agente hereda los permisos del usuario autorizante y no puede excederlos, sin importar
si los valores predeterminados del framework de IA son correctos, si una inyección de prompt tiene éxito o si el
modelo en sí está comprometido.
Así es como se ve el paso cuatro de la ICO en producción. La defensa en capas se mantiene cuando cualquier
control falla. La trazabilidad de auditoría produce la evidencia requerida bajo la responsabilidad del Artículo 5(2) y
las «medidas apropiadas» del Artículo 32. La EIPD se vuelve realmente satisfactoria porque las protecciones técnicas están documentadas, son exigibles y auditables. La gobernanza de la cadena de suministro del paso cinco
se vuelve posible porque la capa de datos aplica la política en cada interacción, incluidas las iniciadas
por herramientas de IA de terceros.
Lo más importante es que la arquitectura responde a la pregunta implícita del regulador: cuando un agente de IA accede
a datos personales, ¿qué lo detiene de exceder su autorización? Los controles en la capa de modelo pueden
ser eludidos. El registro en la capa de aplicación puede ser evitado si la aplicación está diseñada para fallar abierta.
La gobernanza en la capa de datos no puede serlo, porque la capa de datos no confía en que el agente se comporte correctamente. Verifica cada solicitud contra la política, siempre.
Qué deben hacer CISOs, DPOs y consejos directivos este trimestre
Primero, trata la guía de la ICO como base de cumplimiento, no como comentario.
Los cinco pasos se alinean directamente con las expectativas del Artículo 32 y aparecerán en futuras sanciones de la ICO como
evidencia de cómo lucen las «medidas apropiadas» en 2026. Documenta la postura de tu organización frente
a cada paso.
Segundo, completa una EIPD para cada sistema de IA que procese datos personales de alto riesgo.
El Informe de Pronóstico 2026 de Kiteworks halló que el 74% de las organizaciones fuera del alcance de la Ley de IA de la UE no tiene
evaluación de impacto de IA. La ICO acaba de convertir esa brecha en una exposición bajo el RGPD del Reino Unido. La solución es una EIPD documentada
por sistema, no una política genérica de IA.
Tercero, audita tu cadena de suministro en busca de exposición a IA.
Los hallazgos del Informe de Pronóstico 2026 de Kiteworks muestran que solo el 36% de las organizaciones tiene alguna visibilidad sobre cómo
los socios gestionan datos en sistemas de IA. La ICO espera que mapees qué pueden acceder terceros e
incluyas requisitos de seguridad en los contratos. Los cuestionarios anuales a proveedores no serán suficientes.
Cuarto, cierra la brecha de contención.
Los datos del Informe de Pronóstico 2026 de Kiteworks muestran que el 63% de las organizaciones no puede imponer limitaciones de propósito a agentes de IA y el 60% no puede terminar rápidamente uno. El énfasis de la ICO en supervisión humana, defensas en capas y respuesta a incidentes significa que estas brechas ahora son de cumplimiento, no solo de seguridad. La vinculación de propósito, los kill switches y el aislamiento de red pasan de la hoja de ruta a la producción.
Quinto, lleva la detección a la capa de datos.
Los ataques dirigidos a IA —inyección de prompts, envenenamiento de datos, envenenamiento de herramientas— evaden el monitoreo en la capa de aplicación por diseño. La expectativa de monitoreo de la ICO solo es realista cuando la telemetría se ejecuta en la capa donde realmente ocurre el acceso a los datos por parte de la IA.
Sexto, informa a tu consejo directivo este trimestre.
El precedente de Capita es una multa de 14 millones de GBP que comenzó en 58 millones. La próxima gran
filtración de datos personales relacionada con IA en el Reino Unido se evaluará bajo el marco que Ian Hulme acaba de
publicar. La conciencia del consejo es un control. Documenta que se informó.
El enfoque de la ICO es sobrio, no alarmista. «Nada de esto es nuevo», escribe Hulme en el párrafo final,
«pero la IA trae una urgencia renovada y mayor velocidad». Ese es el enfoque correcto. El estándar
no ha cambiado. El reloj sí.
Preguntas frecuentes
Sí. Cualquier organización del Reino Unido que procese datos personales mediante sistemas de IA está bajo el alcance del Artículo 32 del RGPD del Reino Unido, y la guía de la ICO del 13 de mayo de 2026 es explícita en que esto incluye amenazas cibernéticas potenciadas por IA. El Informe de Pronóstico de Seguridad y Cumplimiento de Datos de Kiteworks: 2026 encontró que el 35% de las organizaciones cita los datos personales en prompts como una de las principales exposiciones de privacidad, confiando la mayoría en políticas y capacitación en lugar de controles técnicos. Las firmas de servicios financieros deben documentar una EIPD para el procesamiento de alto riesgo y demostrar protecciones en capas.
La ICO exige «medidas técnicas y organizativas apropiadas» calibradas al riesgo, el mismo estándar que generó la multa de 14 millones de GBP a Capita en octubre de 2025. Para IA en salud que procese datos de pacientes, esto significa acceso autenticado, aplicación de políticas ABAC o RBAC, cifrado en tránsito y en reposo, registro de auditoría a prueba de manipulación y una EIPD documentada. El Informe de Pronóstico de Seguridad y Cumplimiento de Datos de Kiteworks: 2026 halló que el 60% de las organizaciones no puede terminar rápidamente un agente de IA que se comporte mal, lo que se convierte en una brecha directa del Artículo 32 en una implementación de salud.
El quinto paso de la ICO exige que las organizaciones mapeen qué pueden acceder terceros, les exijan estándares de seguridad adecuados e incluyan requisitos de seguridad en los contratos. El Informe de Pronóstico de Seguridad y Cumplimiento de Datos de Kiteworks: 2026 halló que solo el 36% de las organizaciones tiene alguna visibilidad sobre cómo los socios gestionan datos en sistemas de IA y el 30% cita la gestión de proveedores de IA de terceros como una de las principales preocupaciones de seguridad. La interpretación razonable es que los cuestionarios anuales no cumplirán con el Artículo 32; se requerirá monitoreo continuo y requisitos técnicos contractuales.
Están convergiendo. El Artículo 9 de la Ley de IA de la UE exige gestión de riesgos, el Artículo 14 exige supervisión humana y el Artículo 17 exige un sistema de gestión de calidad para IA de alto riesgo. La guía de la ICO aplica los mismos controles al Artículo 32 del RGPD del Reino Unido. El Informe de Pronóstico de Seguridad y Cumplimiento de Datos de Kiteworks: 2026 halló una brecha de 22 a 33 puntos entre las organizaciones bajo presión de la Ley de IA de la UE y las que están fuera de ella en evaluaciones de impacto de IA, vinculación de propósito y red-teaming de IA. Los organismos del sector público son responsables bajo ambos regímenes simultáneamente.
La inyección indirecta de prompts incrusta instrucciones maliciosas en los datos que la IA recupera en tiempo de inferencia. El DLP tradicional opera sobre movimientos de archivos y salida de red. El EDR opera sobre el comportamiento del endpoint. Ninguno está posicionado para evaluar qué está siendo instruido a hacer un sistema de IA por el contenido que acaba de leer. El Informe de Pronóstico de Seguridad y Cumplimiento de Datos de Kiteworks: 2026 halló que el 60% de las organizaciones carece de detección de anomalías específica de IA. La expectativa de monitoreo de la ICO —patrones inusuales de inicio de sesión, transferencias inesperadas de datos, uso anormal de API— debe implementarse en la capa de datos, donde los agentes de IA realmente solicitan acceso.