Fuga de datos en IA: riesgo, regulación y qué exige la Ley de IA de la UE
Seis vectores de fuga de datos en IA, las obligaciones del Artículo 15 y del RGPD que activan, y los controles que cierran la brecha. Actualizado para el Ómnibus Digital.
La fuga de datos sensibles de un sistema de IA no es una amenaza teórica. Ocurre a través de vías fáciles de pasar por alto — un modelo que ha memorizado fragmentos de su conjunto de entrenamiento, un empleado que pega un contrato de un cliente en una herramienta de chat pública, una incrustación (embedding) almacenada en una base de datos vectorial sin controles de acceso. Con arreglo al Derecho de la UE, cada una de esas vías genera exposición: el Artículo 15 de la Ley de IA de la UE (Reglamento (UE) 2024/1689) exige que los sistemas de IA de alto riesgo sean resilientes frente a los ataques contra la confidencialidad, y los artículos 5 y 32 del RGPD exigen, de forma independiente, que los datos personales se mantengan seguros.
Este artículo cartografía los principales vectores de fuga, los anclajes regulatorios que activan y los controles prácticos que cierran la brecha.
Qué significa realmente la fuga de datos en IA
La «fuga de datos» en IA se refiere a la salida de datos sensibles, personales o propios del sistema de maneras no previstas ni autorizadas. Existen seis vectores distintos:
Memorización de los datos de entrenamiento. Los modelos grandes pueden codificar fragmentos de los datos de entrenamiento textualmente y reproducirlos cuando se les solicita. Si su conjunto de entrenamiento contenía historias clínicas, datos salariales o documentos internos, una consulta bien elaborada puede extraer esos fragmentos. El riesgo es asimétrico: puede que no sepa qué ha memorizado el modelo hasta que alguien lo extraiga.
Fuga de la instrucción y del contexto. En los sistemas de generación aumentada por recuperación o que utilizan herramientas, el contexto de la instrucción suele contener material sensible — datos de clientes extraídos de un CRM, turnos de conversación anteriores, un contrato recuperado. Sin un filtrado estricto de la salida, esos fragmentos pueden filtrarse a otros usuarios o a los registros.
Exposición de incrustaciones y de almacenes vectoriales. Los sistemas de recuperación almacenan documentos como incrustaciones numéricas. El texto original puede aproximarse a partir de esas incrustaciones en determinadas condiciones, y si el almacén vectorial es accesible más allá de los usuarios previstos, los datos subyacentes quedan expuestos de hecho.
Ataques de inversión del modelo y de inferencia de pertenencia. Un ataque de inversión del modelo utiliza los resultados del modelo para reconstruir ejemplos que se asemejan a los datos de entrenamiento. Un ataque de inferencia de pertenencia determina si el registro de una persona concreta estaba en el conjunto de entrenamiento. Ambos son técnicas reales y documentadas, con herramientas disponibles públicamente. El Artículo 15 aborda exactamente esta clase de amenaza bajo la rúbrica de «ataques contra la confidencialidad».
IA en la sombra: el personal que usa herramientas públicas. La vía de fuga más común es la más simple. Un empleado pega un borrador de contrato, una hoja de cálculo con nombres de clientes o un plan de negocio en un asistente de IA de cara al público que utiliza las entradas para el entrenamiento. No hay ninguna explotación técnica; los datos abandonan la organización por una acción deliberada (aunque bienintencionada). La obligación de alfabetización en materia de IA del Artículo 4 — en vigor desde el 2 de febrero de 2025 — exige que las organizaciones doten a su personal de la competencia para usar las herramientas de IA de forma segura. La IA en la sombra entra de lleno en el ámbito de aplicación.
Permisos de herramientas e integraciones demasiado amplios. Cuando se concede a un asistente de IA acceso de lectura al correo electrónico, al calendario y a los almacenes de documentos para responder a preguntas amplias, puede mostrar de forma inadvertida datos del contexto de un usuario en el de otro, o escribir datos recuperados en una ubicación con controles de acceso más laxos. La delimitación del privilegio mínimo es a la vez un control de seguridad y de cumplimiento.
Anclajes en la Ley de IA de la UE: qué artículos se aplican
Artículo 15 — Exactitud, robustez, ciberseguridad
El Artículo 15 es el principal anclaje de la Ley de IA de la UE para la fuga de datos en los sistemas de alto riesgo. Exige a los proveedores que diseñen los sistemas de IA de alto riesgo para resistir los intentos de terceros de alterar su comportamiento o sus resultados (robustez adversaria) y, de forma crítica, los intentos de explotar las vulnerabilidades del sistema para acceder a los datos u obtener un acceso no autorizado (ciberseguridad, incluidos los ataques contra la confidencialidad). Los ataques de inversión del modelo y de inferencia de pertenencia entran directamente en los «ataques contra la confidencialidad» del requisito de ciberseguridad del Artículo 15.
El Artículo 15 también remite a los requisitos de notificación y divulgación coordinadas de vulnerabilidades de la Ley de Ciberseguridad (Reglamento (UE) 2019/881), por lo que las orientaciones pertinentes de ENISA se aplican junto con la Ley de IA.
Artículo 10 — Datos y gobernanza de datos
El Artículo 10 regula cómo se manejan los datos de entrenamiento, validación y prueba para los sistemas de IA de alto riesgo. Los proveedores deben contar con prácticas de gobernanza de datos que abarquen: las finalidades previstas de los datos; los posibles sesgos; las limitaciones pertinentes de los datos; los métodos de recopilación de datos apropiados; y si los datos son adecuados para la finalidad del sistema. Esto no es formación del personal — eso es el Artículo 4 — sino la gobernanza de las propias canalizaciones de datos.
Para la fuga de datos, el Artículo 10 importa de dos maneras. Primero, exige la minimización en la canalización de datos: si el conjunto de entrenamiento se despoja de datos personales innecesarios antes del entrenamiento, se reduce la superficie de exposición a la memorización de los datos de entrenamiento. Segundo, una canalización de datos bien gobernada con una trazabilidad documentada permite auditar qué había en el conjunto de entrenamiento si se produce un incidente de fuga.
Artículo 53 — Proveedores de GPAI: resumen de los datos de entrenamiento
Si usted es un proveedor de un modelo de IA de uso general (GPAI) y no de una aplicación posterior, se aplica el Artículo 53. Entre otras obligaciones de referencia, el Artículo 53, apartado 1, letra d), exige a los proveedores de GPAI publicar un resumen suficientemente detallado de los datos de entrenamiento utilizados — lo que permite a los responsables del despliegue posteriores comprender qué categorías de datos se utilizaron para entrenar el modelo y evaluar el riesgo de fuga en consecuencia. Las obligaciones relativas a los modelos GPAI del Capítulo V se aplican desde el 2 de agosto de 2025.
RGPD: artículos 5, 9, 32, 33 y 34
El RGPD se aplica en paralelo y debe aplicarse junto con la Ley de IA, no en su lugar.
El artículo 5, apartado 1, letra f), del RGPD (integridad y confidencialidad) exige que los datos personales se traten de manera que se garantice una seguridad adecuada, incluida la protección contra el tratamiento no autorizado o ilícito y contra su pérdida, destrucción o daño accidentales.
El artículo 9 del RGPD establece requisitos reforzados para las categorías especiales de datos — salud, biométricos, origen racial o étnico, afiliación sindical y más. Muchos conjuntos de datos de entrenamiento de IA tocan categorías especiales de datos. La fuga de datos de categorías especiales activa un mayor nivel de escrutinio tanto en virtud del RGPD como de las categorías de alto riesgo del Anexo III de la Ley de IA (biometría en el punto 1; sanidad en el punto 5 para las evaluaciones de riesgos de seguros).
El artículo 32 del RGPD exige a los responsables y encargados del tratamiento aplicar medidas técnicas y organizativas apropiadas para garantizar un nivel de seguridad adecuado al riesgo — cifrado, seudonimización, confidencialidad, integridad, disponibilidad y resiliencia continuas de los sistemas.
Los artículos 33 y 34 del RGPD exigen la notificación a las autoridades de control en un plazo de 72 horas desde que se tenga conocimiento de una violación de la seguridad de los datos personales (artículo 33) y, cuando la violación entrañe probablemente un alto riesgo para las personas, la notificación directa a dichas personas (artículo 34). Si un incidente de fuga de datos de un sistema de IA afecta a datos personales, se activan ambas obligaciones de notificación junto con cualquier notificación de incidentes de la Ley de IA en virtud del Artículo 73.
Dónde se enfrentan los sistemas de alto riesgo a la mayor exposición
Si su sistema de IA se sitúa en una categoría del Anexo III — contratación o evaluación del rendimiento (punto 4), evaluación de la solvencia (punto 5, letra b)), evaluación de riesgos en seguros de salud o de vida (punto 5, letra c)) o identificación biométrica (punto 1) —, los datos que trata son por definición sensibles, y la fuga es un riesgo de primer orden, no secundario.
Un sistema de contratación entrenado con datos históricos de currículos puede codificar nombres, direcciones e historiales laborales de candidatos en sus pesos. Un modelo de calificación crediticia con acceso por API a los datos de transacciones de los solicitantes crea un vector de fuga en los registros de inferencia si dichos registros no están cifrados ni sometidos a control de acceso. La herramienta de evaluación de riesgos de una aseguradora de salud que trata historiales médicos en virtud del Anexo III, punto 5, letra c), maneja datos de categorías especiales del RGPD, por lo que la fuga activa simultáneamente el artículo 9 del RGPD y el Artículo 15 de la Ley de IA.
El plazo para estos sistemas autónomos del Anexo III es el 2 de diciembre de 2027, en virtud del Ómnibus Digital acordado en mayo de 2026 (la fecha original del 2 de agosto de 2026 se aplazó). Es más margen del que había hace seis meses — pero el trabajo de gobernanza de datos para satisfacer el Artículo 10, y los controles de ciberseguridad para satisfacer el Artículo 15, no son proyectos rápidos.
Mitigaciones que satisfacen ambos marcos
Clasificación y minimización de datos
Antes que cualquier otro control, clasifique sus datos: qué es personal, qué es de categoría especial, qué es comercialmente confidencial, qué es genuinamente público. Después aplique la minimización en cada etapa — recopilación, preprocesamiento, entrenamiento, registro. Los datos que no están en el sistema no pueden filtrarse de él.
Con arreglo al Artículo 10, los proveedores deben documentar que los datos de entrenamiento son apropiados para la finalidad prevista; la minimización es el resultado natural de esa disciplina.
Controles de prevención de pérdida de datos (DLP) y política sobre IA en la sombra
Despliegue herramientas de prevención de pérdida de datos (DLP) que detecten y bloqueen la transmisión de contenido sensible a servicios de IA externos. Combínelas con una política escrita que cubra qué herramientas puede usar el personal para qué categorías de datos, y asegúrese de que se respalde con la formación de alfabetización en materia de IA del Artículo 4. Una política sin controles técnicos no es suficiente, y los controles técnicos sin la comprensión del personal generan soluciones alternativas.
Salvaguardias contractuales: cláusulas de no entrenamiento y APD
Si utiliza un servicio de IA de un tercero, revise sus condiciones antes de enviarle cualquier dato personal o confidencial. Necesita: una declaración clara de que el proveedor no utilizará sus entradas para el entrenamiento de modelos; un acuerdo de tratamiento de datos (APD) en virtud del artículo 28 del RGPD si hay datos personales implicados; e idealmente la residencia de datos en la UE o, al menos, un mecanismo de transferencia con adecuación a la UE si el servicio está fuera de la UE/EEE.
Estas no son mejoras opcionales. Enviar datos personales de categorías especiales a un servicio sin un APD es una infracción del artículo 28 del RGPD en sí misma, con independencia de que se produzca o no un incidente de fuga.
Redacción, anonimización y seudonimización
No todos los casos de uso requieren datos identificables. Cuando la finalidad de su sistema de IA pueda satisfacerse con datos anonimizados o seudonimizados, aplíquelos antes del entrenamiento y antes del registro de inferencias. Los datos verdaderamente anonimizados quedan totalmente fuera del ámbito de aplicación del RGPD; los datos seudonimizados siguen activando el RGPD, pero reducen materialmente la gravedad de una violación.
Controles de acceso y delimitación del privilegio mínimo
Aplique el control de acceso basado en roles a los conjuntos de datos de entrenamiento, los pesos del modelo, las API de inferencia y los registros. Audite los accesos trimestralmente. Cuando las integraciones de IA tengan permisos de herramientas (correo electrónico, almacenes de documentos, CRM), delimítelos al mínimo necesario para la tarea. Cada permiso concedido a un asistente de IA más allá de su necesidad inmediata es un vector de fuga adicional.
Diligencia debida sobre los proveedores
Antes de desplegar un sistema de IA de un tercero en un contexto del Anexo III, pida al proveedor su documentación técnica del Artículo 11 (o equivalente) y su resumen de la arquitectura de ciberseguridad del Artículo 15. Un proveedor que no pueda facilitarlos ante un próximo contexto de alto riesgo le está dando una señal sobre su postura de cumplimiento. En virtud del Artículo 25, si modifica sustancialmente un sistema de IA o lo despliega para una finalidad distinta del uso previsto original, puede asumir usted mismo las obligaciones del proveedor — incluida la responsabilidad de los controles de fuga de datos.
Cómo ayuda Confir
Cuando completa una evaluación en Confir para un sistema de alto riesgo, el área de Datos y Robustez Técnica (AITR) registra sus controles de manejo de datos — incluida la gobernanza de los datos de entrenamiento del Artículo 10 y las medidas de ciberseguridad del Artículo 15. La evaluación formula preguntas en lenguaje sencillo sobre la minimización de datos, los controles de acceso, los compromisos de no entrenamiento de los proveedores y las prácticas de registro; el motor basado en reglas asigna sus respuestas a los requisitos del Reglamento y marca las brechas. El resultado alimenta directamente su paquete de documentación técnica del Artículo 11 / Anexo IV.
Preguntas frecuentes
¿Qué es la fuga de datos en IA con arreglo a la Ley de IA de la UE?
La fuga de datos en IA se refiere a la salida de datos sensibles, personales o propios de un sistema de maneras no previstas — mediante la memorización de los datos de entrenamiento, la exposición de la instrucción o del contexto, la fuga de incrustaciones, los ataques de inversión del modelo o de inferencia de pertenencia, el personal que pega datos en herramientas públicas (IA en la sombra) o permisos de integración demasiado amplios. Con arreglo a la Ley de IA de la UE, los sistemas de IA de alto riesgo deben ser resilientes frente a los ataques contra la confidencialidad (Artículo 15); con arreglo al RGPD, los responsables del tratamiento deben aplicar medidas de seguridad apropiadas (artículo 32) y notificar a las autoridades de control en un plazo de 72 horas desde una violación de la seguridad de los datos personales (artículo 33).
¿Qué artículo de la Ley de IA de la UE cubre la fuga de datos de forma más directa?
El Artículo 15 es el principal anclaje: exige que los sistemas de IA de alto riesgo sean resilientes frente a la manipulación adversaria y los ataques contra la confidencialidad, lo que incluye expresamente las técnicas de inversión del modelo y de inferencia de pertenencia. El Artículo 10 regula la gobernanza de datos previa que impide que los datos sensibles entren innecesariamente en la canalización de entrenamiento. Para los proveedores de modelos GPAI, el Artículo 53, apartado 1, letra d), exige un resumen de los datos de entrenamiento. Los artículos 5, apartado 1, letra f), y 32 del RGPD se aplican en paralelo para cualquier sistema que trate datos personales.
¿Se aplica el RGPD o la Ley de IA de la UE cuando se filtran datos de un sistema de IA?
Ambos pueden aplicarse simultáneamente. El artículo 32 del RGPD exige una seguridad apropiada; los artículos 33 y 34 exigen la notificación de la violación si la fuga afecta a datos personales. El Artículo 15 de la Ley de IA de la UE exige que los proveedores de sistemas de alto riesgo dispongan de controles de ciberseguridad frente a los ataques contra la confidencialidad. Un incidente de fuga de un sistema de IA de alto riesgo — por ejemplo, un modelo de calificación crediticia que expone los datos de transacciones de los solicitantes — activaría las obligaciones de notificación de violaciones del RGPD y podría constituir un incumplimiento de los requisitos de ciberseguridad del Artículo 15 de la Ley de IA. No son alternativas; se acumulan.
¿Qué es la IA en la sombra y por qué importa para la fuga de datos?
La IA en la sombra es el personal que usa herramientas de IA públicas — asistentes de chat, herramientas de resumen, generadores de imágenes — sin supervisión organizativa ni cobertura de políticas. El riesgo de fuga inmediato es que los datos confidenciales o personales tecleados en una herramienta pública puedan utilizarse para el entrenamiento de modelos o registrarse de maneras que escapan a su control. La obligación de alfabetización en materia de IA del Artículo 4 de la Ley de IA de la UE (en vigor desde el 2 de febrero de 2025) exige que las organizaciones garanticen que el personal tenga la competencia suficiente para usar las herramientas de IA de forma segura. Una política sobre IA en la sombra respaldada por controles técnicos de DLP y por la formación del Artículo 4 es la respuesta mínima.
¿Qué salvaguardias contractuales reducen el riesgo de fuga de datos en IA?
Tres son esenciales al usar cualquier servicio de IA de un tercero para datos personales o confidenciales: una cláusula de no entrenamiento con las entradas (el proveedor se compromete a no usar sus datos para reentrenar su modelo); un acuerdo de tratamiento de datos conforme con el RGPD en virtud de su artículo 28; y, para los datos de categorías especiales, una base jurídica clara y un mecanismo de transferencia apropiado si el servicio está fuera del EEE. A falta de un APD, está tratando datos personales sin salvaguardias adecuadas — una infracción autónoma del RGPD con independencia de cualquier incidente de fuga.
¿Cuándo deben cumplir los sistemas de IA de alto riesgo del Anexo III los controles de fuga de datos?
En virtud del Ómnibus Digital acordado en mayo de 2026, la fecha de cumplimiento para los sistemas autónomos de alto riesgo del Anexo III es el 2 de diciembre de 2027 (aplazada respecto de la fecha original del 2 de agosto de 2026). La IA de alto riesgo integrada en productos regulados del Anexo I (productos sanitarios, máquinas) debe cumplir a partir del 2 de agosto de 2028. Las obligaciones de alfabetización en materia de IA del Artículo 4 — directamente pertinentes para la IA en la sombra — están en vigor desde el 2 de febrero de 2025. Las obligaciones de referencia de los GPAI del Artículo 53 se aplican desde el 2 de agosto de 2025.
¿Qué multas se aplican a los fallos de fuga de datos en IA con arreglo a la Ley de IA de la UE?
Los incumplimientos de las obligaciones de alto riesgo — incluida la gobernanza de datos del Artículo 10 y la ciberseguridad del Artículo 15 — están sujetos al nivel de 15 000 000 € o el 3 % del volumen de negocios anual mundial total en virtud del Artículo 99, apartado 4, si esta última cifra es mayor. Para las empresas con menores volúmenes de negocios, en virtud del Artículo 99, apartado 6, la multa se limita al menor del porcentaje y el techo fijo — una protección de proporcionalidad para las empresas más pequeñas. Las multas del RGPD (hasta 20 M€ o el 4 % en virtud del artículo 83, apartado 5, del RGPD por infracciones del artículo 9 relativas a categorías especiales) se aplican por separado.
Guías relacionadas
- sistema de gestión de riesgos del Artículo 9
- requisitos de transparencia de la IA de riesgo limitado
- marco de cumplimiento de la Ley de IA de la UE
- clasificación de riesgos con arreglo a los Artículos 6 a 11
- lista de comprobación de cumplimiento de la Ley de IA de la UE
- criterios de clasificación de alto riesgo del Artículo 6
- estrategias de mitigación de riesgos del Artículo 9
- hoja de ruta de implementación para 2026
- marco de gobernanza de la IA responsable
Gestiona el cumplimiento de la Ley de IA de la UE en un solo lugar
Confir automatiza la clasificación de riesgo, la documentación técnica y los registros de auditoría para cualquier empresa. Sin consultores. Sin proyectos de seis meses. Prueba gratuita de 7 días.
Empieza la prueba gratuita →