La IA no blanquea el RGPD: licitud, transparencia y minimización cuando el modelo quiere comérselo todo

La fantasía más cara del mercado de IA es esta: si el modelo promete productividad, el RGPD ya se adaptará. No funciona así. Un sistema de IA puede ser técnicamente brillante y jurídicamente defectuoso desde el minuto uno. Y cuando eso ocurre, el problema no es abstracto: se traduce en tratamientos sin base del art. 6, información insuficiente bajo los arts. 13 y 14, recogidas desproporcionadas que chocan con el art. 5.1.c y decisiones que rozan o cruzan el art. 22 sin que nadie quiera pronunciar su nombre en la reunión.

El Comité Europeo de Protección de Datos lleva tiempo diciendo, con más paciencia que entusiasmo, que la IA no crea una zona franca. La novedad no está en que exista una guía moral sobre “usar la IA de forma responsable”. La novedad jurídica es más sobria y más incómoda: si hay datos personales en entrenamiento, ajuste, despliegue, monitorización o uso, el RGPD entra entero. No por partes. Entero.

Para CISOs y responsables de cumplimiento, aquí está el quid: el debate no va solo de “puedo usar IA o no”. Va de identificar en qué fase del ciclo de vida del sistema se produce cada tratamiento, con qué finalidad concreta, sobre qué categoría de datos, con qué rol jurídico y bajo qué base legal. Si no haces ese trabajo de bisturí, acabarás gobernando el asunto con frases grandilocuentes y controles vagos. Mala idea. Los reguladores suelen preferir matrices, registros, evaluaciones y pruebas. Menos épica, más evidencia.

El error de origen: tratar la IA como una finalidad, cuando no lo es

“Usar IA” no es una base jurídica ni una finalidad del tratamiento. Es una tecnología o, si se quiere, una familia de técnicas. El art. 5.1.b del RGPD exige finalidades determinadas, explícitas y legítimas. Eso obliga a bajar al barro operativo. No es lo mismo entrenar un modelo generalista con grandes volúmenes de texto que ajustar un modelo interno para clasificar tickets, usar un LLM para redactar respuestas a clientes o desplegar un sistema de scoring antifraude con efectos significativos.

Esa distinción parece obvia, pero muchas organizaciones la esquivan porque complica la gobernanza. Y complica, sí. También evita decisiones absurdas. La base jurídica que puede sostener un sistema de detección de fraude en pagos no es necesariamente la misma que la de un asistente interno para recursos humanos o la de un copiloto comercial conectado al CRM. El art. 6.1 del RGPD no se concede en bloque a toda la estrategia de IA de la empresa.

En la práctica conviene separar al menos cinco capas de tratamiento:

Primero, la recogida u obtención inicial de datos. Segundo, la preparación, limpieza, etiquetado y enriquecimiento. Tercero, el entrenamiento o fine-tuning. Cuarto, la inferencia o uso en producción. Quinto, la observabilidad posterior: logging, monitorización, control de calidad, depuración y reentrenamiento.

Cada capa puede implicar bases de licitud distintas, plazos de conservación distintos, riesgos diferentes y hasta responsables distintos si intervienen proveedores, filiales o plataformas cloud. Si tu registro de actividades del art. 30 describe un único tratamiento llamado “IA corporativa”, ya tienes una señal de alerta. No por sofisticado, sino por vago.

La licitud no se resuelve con un consentimiento metido con calzador

Cuando una organización se pone nerviosa con IA, suele aparecer la solución perezosa: “pidamos consentimiento y listo”. El problema es que el consentimiento del art. 6.1.a debe ser libre, específico, informado e inequívoco. En entornos laborales, esa libertad suele ser frágil. En relaciones con clientes, su especificidad se desmorona si se formula de manera amplia para cubrir usos futuros imprecisos. Y en datos inicialmente recogidos para otra finalidad, pretender reciclar todo con una cláusula generosa es una invitación a que el regulador haga preguntas incómodas.

No significa que el consentimiento sea inútil. Significa que no es un comodín universal. Para muchas implementaciones empresariales de IA, la base relevante será la ejecución de un contrato del art. 6.1.b, el cumplimiento de una obligación legal del art. 6.1.c o el interés legítimo del art. 6.1.f. Cada una tiene costes jurídicos propios.

La ejecución de contrato sirve cuando el tratamiento es objetivamente necesario para prestar el servicio contratado. “Necesario” no es “útil”, ni “moderno”, ni “mejora la eficiencia interna”. Si una aseguradora usa un modelo para acelerar la tramitación de siniestros, tendrá que demostrar por qué ese tratamiento forma parte de la prestación contractual y no es solo una mejora interna opcional.

La obligación legal puede cubrir tratamientos en materia de prevención del blanqueo, fraude o gestión de reclamaciones reguladas, pero solo hasta donde la norma lo permita. Y el interés legítimo, el favorito de medio mercado, exige una prueba de tres pasos que demasiadas empresas convierten en un trámite de dos párrafos: identificar el interés perseguido, demostrar la necesidad del tratamiento y realizar la ponderación frente a los derechos y libertades del interesado. Si el sistema usa datos a gran escala, combina fuentes, infiere atributos o se despliega en contextos de asimetría fuerte, esa ponderación se endurece bastante.

Aquí conviene ser incómodamente concreto. Un LLM interno entrenado con correos de empleados para “mejorar la productividad” tiene mala cara jurídica si no hay una finalidad delimitada, controles de acceso estrictos, exclusión de categorías especiales y una ponderación robusta. Un sistema de detección de fraude en banca, en cambio, parte de un terreno más defendible si está vinculado a seguridad, prevención de pérdidas y obligaciones sectoriales. Incluso ahí, la proporcionalidad sigue siendo el filtro.

Y luego está el pequeño detalle que algunos descubren demasiado tarde: si el modelo trata categorías especiales del art. 9, el art. 6 no basta. Hace falta además una excepción del art. 9.2. Salud, biometría, origen racial o étnico, afiliación sindical, vida sexual, orientación sexual, creencias religiosas. No desaparecen porque estén embebidos en un corpus de entrenamiento.

El interés legítimo en IA: posible, sí; automático, ni de lejos

El interés legítimo no está prohibido para IA. Tampoco está predestinado a funcionar. El problema real no es doctrinal, sino probatorio. ¿Puedes demostrar que el tratamiento es necesario para una finalidad concreta y que no existe un medio menos intrusivo razonablemente eficaz? ¿Puedes explicar por qué el interesado podía esperar ese uso de sus datos? ¿Puedes acreditar salvaguardas técnicas y organizativas que reduzcan el impacto?

El Tribunal de Justicia de la UE y las autoridades de protección de datos llevan años recordando que la ponderación no es un formulario ceremonial. En IA, la situación empeora por cuatro factores recurrentes: reutilización de datos originalmente recogidos para otra cosa, opacidad de la lógica estadística, escala elevada y capacidad de inferencia.

La inferencia merece un subrayado. Un sistema puede generar datos personales nuevos sobre una persona a partir de datos aparentemente neutros. Perfil de riesgo, propensión a impago, afinidad política, rasgos de personalidad, probabilidad de abandono, sospecha de fraude. Aunque el modelo “solo” prediga, sigue tratando datos personales si la salida se refiere a una persona identificada o identificable. El RGPD no distingue entre dato observado y dato inferido a efectos de protección básica. Y el impacto puede ser mayor en el inferido, porque tiene un halo de objetividad matemática que seduce a los equipos de negocio.

Si una entidad quiere apoyar un caso de interés legítimo para un sistema de IA, su test debe incluir al menos estos elementos en sustancia, aunque no los llame así: finalidad concreta; relación con el interesado; naturaleza y sensibilidad de los datos; escala y combinatoria de fuentes; razonables expectativas; posibilidad de exclusión u oposición; medidas de minimización; límites de retención; y controles para evitar reutilizaciones derivadas. Sin eso, la base jurídica se parece más a una esperanza que a una defensa.

Transparencia: el art. 5 no pide poesía, pide que el interesado entienda qué pasa

La transparencia en IA se destruye de dos formas. La primera, con avisos de privacidad tan abstractos que no permiten comprender nada material. La segunda, con textos tan largos y técnicos que nadie sensato puede procesarlos. El RGPD exige información transparente, inteligible y de fácil acceso en los arts. 12, 13 y 14. No exige un tratado filosófico sobre redes neuronales. Exige que el interesado entienda qué datos se usan, para qué, con qué base, de dónde proceden, durante cuánto tiempo, con quién se comparten y qué consecuencias puede tener el tratamiento.

Eso es perfectamente compatible con IA, pero obliga a abandonar dos vicios corporativos. Uno: describir la finalidad como “mejorar la experiencia”. Dos: esconder la lógica relevante detrás de fórmulas como “utilizamos herramientas avanzadas de análisis”. A estas alturas, esa redacción ya no protege a nadie. Ni al interesado ni al departamento legal.

En sistemas complejos, la transparencia útil funciona por capas. Una primera capa breve explica la finalidad, los datos principales, si existe perfilado, si hay intervención humana y qué derechos se activan. Una segunda capa desarrolla fuentes, criterios de funcionamiento, categorías de destinatarios, transferencias internacionales y plazos. Y una tercera capa interna, no necesariamente pública, documenta diseño, variables de entrada, exclusiones, tasas de error conocidas, métricas de validación y límites del sistema. Esa última capa no es un gesto de buena voluntad: es lo que te salvará cuando el DPO, auditor interno o regulador pregunte por qué el sistema decidió lo que decidió.

El punto delicado aparece cuando la organización alega secreto comercial o complejidad técnica para limitar explicaciones. Hay margen para proteger propiedad intelectual, sí. Lo que no hay es un derecho a ser opaco en lo esencial. Si el sistema perfila o contribuye de forma significativa a decisiones que afectan a personas, la organización debe poder explicar los factores relevantes y las consecuencias previstas del tratamiento. No hace falta publicar pesos de modelo. Hace falta decir algo inteligible y útil.

Una paradoja bastante común: cuanto más se presume de “IA explicable” en presentaciones comerciales, menos documentación sólida existe sobre variables, datasets y rutas de decisión cuando llega la revisión de cumplimiento. La explicabilidad de marketing y la explicabilidad para cumplir no son la misma especie.

Minimización: la obligación que más choca con la cultura del dato total

El art. 5.1.c del RGPD exige que los datos sean adecuados, pertinentes y limitados a lo necesario en relación con los fines. La IA generativa y el aprendizaje automático de gran escala nacieron con un reflejo opuesto: cuanto más dato, mejor. O al menos eso asume medio sector. Aquí está uno de los choques más serios entre práctica tecnológica y disciplina jurídica.

Minimizar no significa inutilizar el modelo. Significa justificar por qué cada categoría de dato aporta valor real al fin perseguido y por qué no existen alternativas menos invasivas. Un caso sencillo lo ilustra. Si quieres automatizar la clasificación de tickets de soporte interno, ¿necesitas conservar identificadores personales completos en el corpus de entrenamiento? Muchas veces no. ¿Necesitas incluir historiales libres sin depurar, donde aparecen datos de salud, incidencias disciplinarias o comentarios personales? Tampoco. ¿Necesitas retener prompts y respuestas indefinidamente “por si sirven para mejorar”? Esa coletilla es el himno no oficial de la mala gobernanza.

Para CISOs y equipos de cumplimiento, la minimización en IA se traduce en decisiones de diseño muy concretas:

Selección de atributos antes del entrenamiento; exclusión de categorías especiales salvo cobertura jurídica clara; seudonimización real y no solo cosmética; truncado o hashing de identificadores cuando el caso de uso lo permita; límites estrictos de logging; segregación de entornos; y políticas de retención diferentes para datos de entrada, salidas, prompts, feedback humano y artefactos de entrenamiento.

La seudonimización del art. 4.5 ayuda, pero no convierte mágicamente el dato en no personal. Reduce riesgo. No evapora obligaciones. Y la anonimización auténtica, cuando se invoca, debe resistir una pregunta básica: ¿puede reidentificarse razonablemente con medios disponibles, especialmente al combinar datos o salidas? En IA, ese riesgo no es teórico. Los modelos pueden memorizar patrones raros o reproducir fragmentos sensibles bajo determinadas condiciones.

Quien quiera hacer minimización en serio necesita gobernar el dataset como un activo regulado. Inventario de fuentes. Base jurídica por fuente. Exclusiones. Regla de elegibilidad. Criterios de calidad. Caducidad. Registro de transformaciones. Si esto suena más a ingeniería y compliance que a magia algorítmica, es porque lo es.

Cuando el modelo aprende demasiado: memorizar, inferir y filtrar

Hay un malentendido persistente: que el riesgo de privacidad en IA termina cuando un dato se “mezcla” en un modelo. No termina. Cambia de forma. Un modelo puede retener o reproducir información personal en sus parámetros o en sus salidas, especialmente si el entrenamiento incluyó datos sensibles, raros o mal depurados. Puede también permitir extracción indirecta mediante prompting diseñado para ello. No hace falta entrar en pánico para admitir un hecho básico: el entrenamiento no es una trituradora jurídica.

El EDPB y otras autoridades han insistido en que el principio de protección de datos desde el diseño y por defecto del art. 25 debe aterrizarse en el diseño técnico. En IA eso implica, como mínimo, filtrar datasets, reducir identificadores directos, limitar campos libres, evaluar memorization risk, controlar el acceso a corpus y artefactos, y revisar si las salidas pueden revelar información sobre individuos concretos.

Para un CISO, esta parte conecta de forma natural con seguridad del tratamiento del art. 32. No basta con hablar de cifrado en reposo y en tránsito. Hace falta pensar en amenazas específicas del ciclo de vida de IA: envenenamiento de datos, extracción de prompts, fuga de embeddings, acceso lateral a repositorios de entrenamiento, recuperación de secretos en contexto, reconstrucción de datos desde logs o abuso de interfaces por insiders. El RGPD no te va a nombrar el prompt injection en latín jurídico, pero sí te exige un nivel de seguridad adecuado al riesgo. Y el riesgo en IA tiene acento propio.

Además, si se produce una violación de seguridad que afecte a datos personales, vuelven a entrar los plazos clásicos: notificación a la autoridad competente sin dilación indebida y, de ser posible, en 72 horas conforme al art. 33; comunicación al interesado si hay alto riesgo, según el art. 34. Tener un sistema de IA en medio no te regala tiempo extra. Bastante generoso es ya el calendario europeo con todo lo demás que pide.

Art. 22 RGPD: la norma que todos citan poco y temen mucho

El art. 22 del RGPD sigue siendo el gran punto de fricción cuando la IA se usa para decidir sobre personas. La disposición reconoce el derecho a no ser objeto de una decisión basada únicamente en el tratamiento automatizado, incluida la elaboración de perfiles, que produzca efectos jurídicos en él o le afecte significativamente de modo similar, salvo en las excepciones tasadas del art. 22.2.

La discusión práctica casi siempre gira en torno a tres preguntas.

La primera: ¿hay una decisión? Si el sistema solo recomienda y un humano revisa de verdad, puede que no estemos ante el supuesto más duro del art. 22. Si el humano firma en automático lo que el modelo dice, la “intervención humana” es decorativa. Los reguladores no se impresionan con un clic final sin capacidad real de revisión.

La segunda: ¿está basada únicamente en tratamiento automatizado? Si existe participación humana sustantiva, formada y con autoridad para apartarse del resultado, la respuesta puede ser no. Pero esa sustantividad debe probarse. Manuales, flujos de escalado, métricas de override, formación y registros de revisión importan mucho más que una frase en la política interna.

La tercera: ¿produce efectos jurídicos o afecta significativamente de modo similar? Denegar crédito, modificar condiciones de seguro, rechazar una candidatura, suspender pagos, bloquear una cuenta o asignar una prima con impacto económico claro parecen candidatos obvios. Un priorizador interno de incidencias, probablemente no. Pero hay una amplia zona gris donde el “solo es una recomendación” acaba moldeando resultados materiales. Ahí es donde empiezan las peleas serias.

Si el tratamiento entra en art. 22, las excepciones son limitadas: necesidad para un contrato entre interesado y responsable, autorización por Derecho de la Unión o de los Estados miembros con medidas adecuadas, o consentimiento explícito. Y cuando se aplican las letras a o c, el art. 22.3 exige medidas adecuadas para salvaguardar los derechos y libertades e intereses legítimos del interesado, al menos el derecho a obtener intervención humana, expresar su punto de vista y impugnar la decisión.

La palabra “al menos” merece atención. No es un techo. Es el mínimo. En sistemas de alto impacto, una organización prudente añadirá controles de calidad de datos, validaciones periódicas de sesgo, umbrales de confianza, revisión reforzada en casos límite y documentación de errores conocidos. Si no, el derecho de impugnación se convierte en un buzón de reclamaciones que nadie puede resolver de forma informada.

El AI Act no sustituye al RGPD. Lo complica, porque añade otra capa

Una de las lecturas más peligrosas del AI Act es pensar que, como trae obligaciones específicas sobre IA, desplazará al RGPD en lo relativo a datos personales. No. Son capas normativas distintas y complementarias. El AI Act regula sistemas de IA con un enfoque de riesgos, imponiendo obligaciones a proveedores y desplegadores según la categoría del sistema. El RGPD sigue gobernando el tratamiento de datos personales. Si un sistema entra en ambos mundos, hay que cumplir ambos. Doble disciplina. Doble documentación. Doble oportunidad de hacerlo mal.

La conexión práctica es inmediata. El AI Act exige para sistemas de alto riesgo requisitos sobre gobernanza de datos, documentación técnica, registro de eventos, transparencia, supervisión humana, precisión, robustez y ciberseguridad. Nada de eso exime de tener base jurídica, transparencia bajo arts. 13 y 14 o evaluación de impacto si procede bajo el art. 35 del RGPD. Más bien refuerza la expectativa de que la organización pueda demostrar control real del sistema.

Desde el 1 de agosto de 2024, el AI Act está formalmente en vigor, aunque sus obligaciones se aplican de forma escalonada. La prohibición de ciertas prácticas y la alfabetización en IA llegarán antes que la parte más pesada del régimen de alto riesgo; otras obligaciones se activarán en fases posteriores de 2025, 2026 y más allá. El calendario da algo de margen. No da derecho a improvisar. Quien espere a que todo sea exigible para ordenar datos, roles y trazabilidad llegará tarde y mal.

Lo interesante para equipos de cumplimiento es que el AI Act empuja a una disciplina de producto que puede ayudar mucho con RGPD si se hace bien. Inventario de sistemas, clasificación por riesgo, documentación de dataset, validación, controles de supervisión, logging y gestión de incidencias. Todo eso dialoga muy bien con arts. 5, 25, 30, 32 y 35 del RGPD. El problema aparece cuando las organizaciones montan dos burocracias paralelas que no se hablan: la de privacidad por un lado y la de IA por otro. Duplican papeles y dejan huecos justo donde importan los hechos.

La evaluación de impacto no es opcional cuando el riesgo se dispara

El art. 35 del RGPD obliga a realizar una evaluación de impacto relativa a la protección de datos cuando un tipo de tratamiento, en particular si utiliza nuevas tecnologías, entrañe un alto riesgo para los derechos y libertades de las personas físicas. Si querías una frase escrita pensando en IA antes de que la fiebre actual existiera, aquí la tienes.

La necesidad de una EIPD o DPIA suele activarse cuando coinciden elementos como evaluación sistemática y exhaustiva de aspectos personales, decisiones automatizadas con efectos significativos, observación sistemática, tratamiento a gran escala, combinación de conjuntos de datos o uso de categorías especiales. Muchos sistemas de IA empresariales marcarán varias casillas a la vez.

Lo que separa una DPIA útil de una pieza decorativa es el detalle operativo. Debe describir el tratamiento y sus fines; evaluar necesidad y proporcionalidad; identificar riesgos específicos para derechos y libertades; y definir medidas para afrontarlos. En IA, eso implica además documentar origen de datos, variables, procesos de limpieza, sesgos conocidos, controles de supervisión humana, tasas de error, escenarios de uso indebido, transferencia internacional, lógica de retención y canales para ejercer derechos.

Una mala práctica muy extendida consiste en copiar una DPIA genérica de “analítica avanzada” y cambiar dos nombres. Eso puede servir para tranquilizar a alguien internamente durante una semana. No sirve cuando la autoridad pide por qué se incluyeron determinados campos, cómo se descartaron alternativas menos intrusivas o qué métricas usa la organización para validar impacto desigual sobre grupos de personas.

Si tras la evaluación persiste un alto riesgo que no pueda mitigarse, el art. 36 obliga a consultar a la autoridad de control antes del tratamiento. No ocurre a menudo porque las empresas prefieren rediseñar antes que tocar esa puerta. Pero la existencia misma del mecanismo recuerda algo básico: no todo proyecto de IA es jurídicamente desplegable con una política bonita y un vendor conocido.

Entrenar con datos públicos no te saca del problema

Otra comodidad habitual: si los datos están “públicamente disponibles”, la organización asume que el uso para entrenamiento o ajuste es libre desde el punto de vista de protección de datos. No lo es. Público no significa huérfano de derechos. Si el dato permite identificar a una persona y se trata para una finalidad nueva, el RGPD sigue aplicando. Entonces vuelven a aparecer las preguntas de siempre: base jurídica, transparencia, compatibilidad de finalidad, minimización, conservación y ejercicio de derechos.

Esto es especialmente incómodo con scraping masivo, recopilación de foros, repositorios abiertos, redes sociales o páginas corporativas. El hecho de que un dato sea accesible no implica que el interesado espere razonablemente su ingesta en un modelo entrenado para otros fines. El art. 14 puede exigir informar cuando los datos no se obtienen del interesado, salvo que concurra alguna excepción. Y esas excepciones no están diseñadas para absolver cualquier recolección a gran escala porque técnicamente sea posible.

Aquí hay además un riesgo reputacional que a veces pesa más que el jurídico inmediato. Decir “los datos ya eran públicos” como defensa frente a usos opacos de IA suele sonar peor una vez se traduce al lenguaje llano del cliente, empleado o paciente afectado. Y conviene no perder de vista otra capa: además del RGPD, pueden entrar propiedad intelectual, condiciones de uso de plataformas, competencia desleal o normativa sectorial.

Transferencias internacionales: la IA adora la nube, el RGPD adora preguntar a dónde viajan los datos

Muchos despliegues de IA dependen de proveedores fuera del EEE o de cadenas complejas de subencargados. Eso devuelve al primer plano los arts. 44 a 49 del RGPD sobre transferencias internacionales. No porque la IA tenga una cláusula especial, sino porque la arquitectura real del servicio suele ser transfronteriza por diseño.

Si usas un proveedor de modelos, una plataforma de fine-tuning, un servicio de embeddings, un filtro de seguridad y un sistema de observabilidad, puede que intervengan varias entidades en varias jurisdicciones. El contrato principal rara vez cuenta toda la historia a simple vista. Hay que saber dónde se procesan prompts, logs, archivos cargados, feedback de usuarios y datos de telemetría; qué subencargados participan; qué medidas suplementarias existen si no hay decisión de adecuación; y si el proveedor reutiliza datos para entrenar modelos propios.

La última cuestión es explosiva. Muchos servicios han ido ajustando sus términos para ofrecer opciones enterprise sin uso de datos del cliente para entrenamiento general, pero no conviene asumir nada. Debe estar contractual y técnicamente delimitado. Si no, puedes acabar enviando datos personales a un proveedor que, de facto, expande finalidades y multiplica riesgos mientras tu organización sigue diciendo que usa la herramienta “solo como apoyo”.

Qué deberían estar haciendo ya CISOs y compliance, sin teatro regulatorio

La respuesta útil no es crear un comité grandilocuente que se reúna una vez al trimestre para hablar de “ética de la IA”. La respuesta útil es construir control sobre el ciclo de vida real del dato dentro de cada caso de uso. Eso empieza por un inventario serio de sistemas de IA, incluyendo herramientas adquiridas por negocio sin pasar por TI, extensiones SaaS con funciones generativas y modelos embebidos en productos de terceros. Si no ves el perímetro, no gobiernas nada.

Después toca clasificar. ¿Hay datos personales? ¿Qué categorías? ¿Hay menores? ¿Categorías especiales del art. 9? ¿Se generan inferencias? ¿Existe perfilado? ¿Hay decisiones con efectos significativos? ¿Qué roles jurídicos asume la empresa y cuáles el proveedor? ¿Existen transferencias fuera del EEE? ¿Se conservan prompts o logs? ¿Se usan datos para reentrenamiento?

Con esa cartografía, el siguiente paso es bajar a controles concretos:

Un estándar interno para aprobar casos de uso; exigencia de base jurídica documentada por fase del tratamiento; revisión del deber de información; criterios de minimización de atributos; prohibición o fuerte restricción de datasets no depurados; cláusulas contractuales sobre no reutilización para entrenamiento salvo autorización expresa; controles de acceso a corpus y artefactos; retención diferenciada; DPIA cuando proceda; y pruebas de supervisión humana en los sistemas sensibles.

El CISO tiene además una tarea poco glamourosa y decisiva: integrar IA en el programa normal de seguridad, no tratarla como un juguete de innovación. Eso significa threat modeling específico, inventario de activos, gestión de terceros, pruebas de resiliencia, control de secretos, hardening de pipelines MLOps, revisión de APIs, protección de repositorios y respuesta a incidentes. Si DLP, IAM y logging se quedan en la puerta porque “esto lo lleva el equipo de datos”, la organización está fabricando su próximo post mortem.

Compliance, por su parte, debe dejar de preguntar solo por la política y empezar a pedir evidencia operativa. No “tenemos supervisión humana”, sino quién revisa, con qué formación, con qué margen de discreción y con qué tasa de modificación de resultados. No “aplicamos minimización”, sino qué campos se excluyeron y por qué. No “somos transparentes”, sino qué dice exactamente la capa uno del aviso y cómo se informa cuando los datos no se obtienen del interesado.

Una tabla simple para no perderse entre conceptos jurídicos y tareas reales

Implicaciones para entidades financieras europeas: no basta con decir que el modelo ayuda al riesgo

Para banca, seguros, pagos y fintech, el choque entre IA y protección de datos tiene una intensidad especial. No solo por volumen de datos, sino porque muchas decisiones afectan acceso a crédito, cobertura, fraude, AML, continuidad de servicio y atención al cliente. Son ámbitos donde la automatización resulta irresistible y, precisamente por eso, donde el escrutinio será mayor.

Una entidad financiera que use IA para scoring, prevención de fraude o priorización de alertas no puede tratar el art. 22 como una nota a pie de página. Si una alerta del modelo termina provocando bloqueo de cuenta, revisión reforzada o denegación de servicio, hay que analizar si existe un efecto jurídico o equivalente. Si se usa IA generativa para asistencia al agente, el riesgo quizá esté menos en art. 22 y más en precisión, confidencialidad, logging y uso secundario de datos del cliente por terceros proveedores.

A esto se añade la convergencia regulatoria. DORA, aplicable desde el 17 de enero de 2025, no regula privacidad, pero sí resiliencia operativa digital, gestión de riesgos TIC, terceros críticos e incidentes. Si una entidad integra IA en procesos críticos o importantes, la conversación con DORA aparece enseguida: dependencia de terceros, continuidad, pruebas, inventario y concentración de proveedores. El RGPD te preguntará si tratas lícitamente datos personales. DORA te preguntará si ese sistema es resiliente y gobernable. Responder bien a una sola de las dos preguntas ya no basta.

En entidades sujetas también a AML y prevención de fraude, el equilibrio es aún más delicado. Los sistemas deben ser eficaces, sí, pero la eficacia no deroga proporcionalidad, minimización ni supervisión. La tentación de conectar todas las fuentes posibles para que el modelo “vea más” es enorme. Justo por eso conviene recordar que un dataset exuberante puede mejorar un AUC y empeorar de forma dramática tu posición jurídica.

El problema de fondo no es la IA; es la indisciplina documental

La mayoría de fiascos de cumplimiento en IA no nacen de una red neuronal malvada. Nacen de decisiones humanas muy tradicionales: no delimitar finalidades, reutilizar datos porque ya estaban ahí, comprar a un proveedor sin revisar términos de uso, dejar que negocio pilote herramientas por su cuenta, posponer la DPIA y confiar en que una cláusula genérica arreglará lo que la arquitectura estropeó.

La buena noticia es que el RGPD no exige perfección matemática. Exige responsabilidad demostrable. El art. 5.2, principio de responsabilidad proactiva, es la bisagra de todo esto. No basta con cumplir; hay que poder demostrarlo. En IA, demostrarlo implica trazabilidad documental unida a controles reales. Si tu organización no puede contestar con precisión qué datos alimentan qué modelo, para qué, durante cuánto tiempo, con qué base legal y con qué salvaguardas, entonces no tiene un programa de gobernanza de IA. Tiene entusiasmo asistido por procurement.

La ironía final es bastante europea: cuanto más autónomos y sofisticados pretendemos que sean los sistemas, más disciplina humana exigen alrededor. Licitud, transparencia y minimización no son reliquias de una era analógica. Son las tres preguntas que distinguen un uso defendible de IA de un experimento caro con riesgo regulatorio acumulativo.

Si eres CISO o responsable de cumplimiento, la pregunta correcta no es si tu empresa usa IA. Seguro que sí, aunque algunos aún no lo sepan. La pregunta correcta es si puedes demostrar, caso por caso, que ese uso respeta los arts. 5, 6, 22, 25, 32 y 35 del RGPD, y cómo se alinea con las obligaciones crecientes del AI Act. Si la respuesta depende de una presentación de PowerPoint y de la buena voluntad del proveedor, ya conoces el diagnóstico.