IA y datos personales: la licitud no se arregla con una casilla de consentimiento

La pregunta difícil no es si un sistema de inteligencia artificial utiliza datos personales. La pregunta difícil es si la organización puede demostrar, para cada uso concreto, que tenía derecho a utilizarlos, que utilizó los datos estrictamente necesarios y que la persona afectada pudo entender qué estaba ocurriendo.

Ahí es donde muchos proyectos de IA se quedan sin suelo jurídico. El equipo técnico habla de conjuntos de entrenamiento, embeddings, ajuste fino y registros de inferencia. El equipo de privacidad pregunta por la base jurídica. El negocio responde que el modelo mejora con más datos. Y alguien propone añadir una casilla de consentimiento para cerrar la discusión. Es una solución cómoda, pero con frecuencia jurídicamente débil.

El Reglamento General de Protección de Datos no prohíbe la inteligencia artificial. Sí impide que la organización convierta la escala, la opacidad o la complejidad técnica en una excusa para relajar sus obligaciones. Los artículos 5 y 6 del RGPD siguen gobernando la entrada de datos en el sistema; los artículos 13 y 14, la información que recibe la persona; el artículo 22, las decisiones automatizadas; y los artículos 25, 32 y 35, el diseño, la seguridad y la evaluación de impacto.

El Reglamento de IA de la Unión Europea añade otra capa, no una vía de escape. El AI Act regula el riesgo del sistema de IA, mientras que el RGPD regula el tratamiento de datos personales. Un sistema puede cumplir una obligación del AI Act y seguir incumpliendo el RGPD. También puede ocurrir lo contrario. La frontera entre ambos textos no es decorativa: determina qué controles debe conservar el CISO, qué evidencias debe pedir compliance y qué promesas no debería hacer ventas al cliente.

La licitud empieza antes del modelo

El artículo 6 del RGPD exige una base jurídica para cada tratamiento de datos personales. No para “la IA” en abstracto, sino para operaciones concretas: recopilar datos de clientes, extraer información de documentos, entrenar un modelo, ajustar sus parámetros, conservar logs, generar perfiles o utilizar una salida para adoptar una decisión.

Ese desglose importa porque una base jurídica válida para prestar un servicio no se traslada automáticamente al entrenamiento de otro sistema. Los datos obtenidos para gestionar una cuenta corriente, tramitar un siniestro o atender una solicitud de soporte no quedan disponibles por defecto para desarrollar un modelo generalista. El principio de limitación de la finalidad del artículo 5.1.b obliga a explicar la compatibilidad entre la finalidad original y la nueva. Si la organización no puede describir esa compatibilidad en términos comprensibles, probablemente tampoco podrá defenderla ante una autoridad de control.

Consentimiento: una opción, no un salvoconducto

El consentimiento del artículo 6.1.a puede ser adecuado en algunos escenarios, pero no es una solución universal. Debe ser libre, específico, informado e inequívoco. En una relación de dependencia —por ejemplo, entre empleador y trabajador— la libertad puede resultar difícil de acreditar. En una aplicación de consumo, mezclar el acceso al servicio con la autorización para utilizar conversaciones en el entrenamiento puede hacer que el consentimiento deje de ser realmente opcional.

Hay otro problema operativo: retirar el consentimiento no equivale simplemente a borrar una fila en una base de datos. Si los datos ya se incorporaron a un conjunto de entrenamiento o influyeron en los parámetros del modelo, la organización debe haber diseñado de antemano cómo responderá a la retirada. No siempre será técnicamente posible identificar y eliminar la influencia de un único registro sin reentrenar el modelo, pero esa dificultad no permite ignorar el derecho. El análisis debe cubrir la arquitectura, la trazabilidad de los datos y las alternativas disponibles.

La organización que elige consentimiento también debe poder demostrar cómo lo obtuvo y cómo gestiona la retirada. El artículo 7 exige que el responsable pueda demostrarlo. Un banner genérico, una política de privacidad de cuarenta páginas y una casilla premarcada no forman un sistema de prueba; forman, como mucho, una futura conversación con el regulador.

Interés legítimo: el test que no puede redactar una máquina

El artículo 6.1.f permite tratar datos cuando existe un interés legítimo del responsable o de un tercero, siempre que no prevalezcan los intereses o derechos de la persona afectada. En proyectos de IA, esta base puede ser relevante para detección de fraude, ciberseguridad, mejora de productos o automatización interna. Pero requiere un análisis en tres pasos: identificar un interés real y lícito, demostrar que el tratamiento es necesario y ponderarlo frente a las expectativas y derechos de las personas.

El primer error habitual es describir el interés como “innovar con IA”. Es demasiado amplio. Un interés defendible se formula de manera concreta: detectar patrones de fraude en transferencias, clasificar alertas de seguridad o reducir el tiempo de revisión de determinados documentos. El segundo error es llamar necesario a cualquier tratamiento que mejore el rendimiento del modelo. Que un modelo funcione mejor con diez veces más datos no demuestra que esa escala sea necesaria para la finalidad perseguida.

La ponderación debe considerar la naturaleza de los datos, la relación con las personas, sus expectativas razonables, el efecto del tratamiento, la posibilidad de exclusión y las salvaguardas. También debe documentarse. Si la única conclusión del análisis es que “los beneficios superan los riesgos”, falta precisamente el razonamiento que una auditoría necesitará reconstruir.

Datos sensibles y reutilización

Los datos de categorías especiales del artículo 9 —salud, biometría utilizada para identificar de manera unívoca, opiniones políticas, afiliación sindical, religión u orientación sexual, entre otros— requieren una condición adicional, además de una base del artículo 6. La reutilización de grandes volúmenes de texto, imágenes, expedientes o grabaciones puede introducir estas categorías aunque el proyecto no las haya solicitado expresamente.

Por eso, “no pedimos datos de salud” no basta cuando el sistema ingiere informes médicos, correos electrónicos o reclamaciones que pueden contenerlos. El responsable debe decidir si los excluye antes de la entrada, si los detecta y elimina, si restringe el uso a una finalidad cubierta por el artículo 9 o si descarta el caso de uso. La detección automática de información sensible ayuda, pero no sustituye la responsabilidad jurídica: un clasificador imperfecto no convierte el dato sensible en dato ordinario.

Minimización: menos datos, no solo más filtros

El artículo 5.1.c exige que los datos sean adecuados, pertinentes y limitados a lo necesario en relación con la finalidad. En proyectos de IA, este principio choca con una intuición técnica muy extendida: cuantos más datos, mejor modelo. El RGPD no reconoce esa intuición como criterio jurídico.

La minimización debe aplicarse en varias capas. Primero, al definir el caso de uso: quizá el modelo necesita el importe, la fecha y el tipo de operación, pero no el nombre completo, la dirección o el contenido íntegro de las comunicaciones. Segundo, al preparar los datos: seudonimizar, eliminar campos innecesarios, truncar textos y separar identificadores de atributos analíticos. Tercero, durante la inferencia: no todos los usuarios ni todas las consultas necesitan acceder al mismo contexto. Cuarto, en la conservación: los logs de entrada y salida no deberían mantenerse indefinidamente solo porque el almacenamiento sea barato.

La seudonimización del artículo 4.5 reduce el riesgo, pero no convierte la información en anónima. Si la organización puede volver a vincular el identificador con una persona utilizando información adicional, el RGPD sigue aplicándose. La anonimización exige que la reidentificación no sea razonablemente probable atendiendo a los medios disponibles, el coste, el tiempo y la tecnología. Llamar “anonimizado” a un dataset porque se eliminaron los nombres es una afirmación técnica y jurídica que necesita pruebas.

Para un CISO, la minimización tiene una consecuencia que a veces se pierde entre controles de acceso y cifrado: reduce la superficie de ataque. Un proveedor que recibe solo atributos necesarios para generar una respuesta tiene menos material que exfiltrar que otro que recibe el expediente completo. La privacidad no es únicamente una obligación de legal; es también una decisión de arquitectura.

Los datos sintéticos no son una palabra mágica

Los datos sintéticos pueden disminuir la exposición, pero no ofrecen inmunidad automática. Si el sistema generador memoriza ejemplos reales, reproduce registros o permite inferir información sobre personas concretas, habrá que analizar si el resultado sigue siendo dato personal. El riesgo también aparece cuando los datos sintéticos se combinan con fuentes auxiliares.

La validación debería incluir pruebas de memorization, ataques de inferencia y reidentificación, además de una revisión de la utilidad del conjunto. Un dataset sintético que conserva sesgos o permite recuperar atributos sensibles puede cumplir la etiqueta comercial de “privacy-enhancing” y fallar la prueba práctica de protección de datos. La decisión debe quedar documentada con la metodología, los umbrales y las limitaciones conocidas.

Transparencia: explicar el tratamiento, no recitar jerga

Los artículos 13 y 14 del RGPD exigen información sobre el responsable, las finalidades, la base jurídica, los destinatarios, los plazos de conservación y los derechos, entre otros elementos. Cuando existe elaboración de perfiles o una decisión automatizada, la persona debe recibir información significativa sobre la lógica utilizada y las consecuencias previstas. El reto de la IA no elimina estas obligaciones; obliga a traducirlas.

Una frase como “utilizamos algoritmos avanzados para mejorar nuestros servicios” no explica nada operativo. La persona necesita saber qué datos se utilizan, para qué resultado, si interviene una persona, qué factores pueden influir y qué puede hacer si considera que la salida es incorrecta. La explicación no tiene que revelar secretos comerciales ni publicar el código fuente, pero sí debe permitir entender el tratamiento y ejercer derechos de forma efectiva.

La transparencia también debe llegar al usuario interno. Un analista que recibe una puntuación de riesgo no debería tratarla como una verdad objetiva si desconoce qué datos la alimentan, cuándo se calculó, cuál es su margen de error o qué situaciones quedan fuera del modelo. El artículo 5.1.a, con sus principios de licitud, lealtad y transparencia, afecta tanto a la comunicación externa como a la gobernanza interna.

El proveedor no puede absorber la responsabilidad

Comprar una API de IA no transfiere automáticamente la responsabilidad al proveedor. El responsable del tratamiento sigue necesitando saber si las entradas se conservan, si se utilizan para entrenar modelos, en qué regiones se procesan, qué subencargados intervienen y cómo se atienden las solicitudes de derechos. El artículo 28 del RGPD exige que el encargado ofrezca garantías suficientes y que el contrato regule, entre otros extremos, instrucciones documentadas, confidencialidad, seguridad, subcontratación y asistencia.

La evaluación del proveedor debería pedir respuestas verificables, no solo un certificado o una promesa de “no training”. ¿Qué significa exactamente? ¿No se entrenan modelos públicos, pero sí sistemas internos? ¿Se conservan los prompts durante treinta días para detectar abuso? ¿Los datos pueden ser accesibles al personal de soporte? ¿Qué ocurre con las copias de seguridad? ¿Puede el cliente auditar o recibir evidencias?

Las transferencias internacionales exigen un análisis separado. Si el proveedor accede a datos desde fuera del Espacio Económico Europeo, entran en juego el capítulo V del RGPD, incluidas las garantías del artículo 46 cuando proceda. Una cláusula contractual no corrige por sí sola los riesgos del acceso remoto, la legislación del país receptor o la falta de medidas suplementarias. El equipo de compras no debería aprobar una herramienta de IA antes de que privacidad, seguridad y arquitectura hayan revisado el flujo completo.

Decisiones automatizadas: el artículo 22 se activa con el efecto, no con la etiqueta

El artículo 22 del RGPD reconoce el derecho a no quedar sujeto a una decisión basada únicamente en un tratamiento automatizado, incluida la elaboración de perfiles, que produzca efectos jurídicos o le afecte significativamente de modo similar. El análisis no depende de que la empresa llame al sistema “asistente”, “recomendador” o “clasificador”. Depende de lo que la salida provoque en la vida de la persona.

Denegar automáticamente un crédito, cancelar una póliza, bloquear una cuenta, rechazar una candidatura o fijar una condición económica desfavorable son ejemplos claros de decisiones con impacto potencialmente significativo. En cambio, priorizar internamente una cola para revisión humana puede quedar fuera del artículo 22 si el efecto sobre la persona no se produce hasta la intervención posterior. Pero la etiqueta “revisión humana” no sirve si el empleado solo confirma la recomendación sin examinar los datos.

Cuando concurre una excepción del artículo 22.2 —por ejemplo, necesidad contractual, autorización legal o consentimiento explícito— deben existir garantías adecuadas. El artículo 22.3 menciona el derecho a obtener intervención humana, expresar el propio punto de vista y contestar la decisión. Eso requiere un canal real, un empleado con autoridad para cambiar el resultado y acceso a los elementos necesarios para revisar el caso.

La calidad de la intervención humana se puede probar. La organización debería registrar quién revisó, qué información tenía, si podía apartarse de la recomendación, qué razones motivaron la decisión final y si existían indicadores de automatización ciega. Una bandeja donde cientos de alertas se validan con un clic no es control humano; es automatización con una firma al final.

Sesgo, exactitud y derechos

El artículo 5.1.d exige exactitud y actualización. En modelos que generan perfiles o recomendaciones, un dato inexacto puede contaminar la salida y desencadenar una decisión injusta. El artículo 16 permite rectificar datos personales inexactos, pero la rectificación no resuelve por sí sola qué hacer con una predicción ya generada, un perfil histórico o un parámetro que incorporó información errónea.

La gobernanza debe conectar el inventario de datos con el inventario de modelos. Para cada sistema conviene identificar qué campos personales utiliza, cuál es su procedencia, cuándo se actualizan, qué controles de calidad existen y cómo se propaga una corrección. También deben medirse resultados desiguales entre grupos cuando el caso de uso pueda afectar al acceso a crédito, empleo, seguros, servicios esenciales o fraude.

El artículo 35 exige una evaluación de impacto relativa a la protección de datos cuando el tratamiento pueda entrañar un alto riesgo para los derechos y libertades. La elaboración de perfiles sistemática, el tratamiento a gran escala de categorías especiales y determinadas decisiones automatizadas son señales claras. Una DPIA superficial que describe el modelo pero no sus consecuencias, usuarios, errores y medidas de mitigación no cumple su función preventiva.

La conexión con el AI Act: dos reglamentos, una sola realidad operativa

El Reglamento de IA de la Unión Europea, Reglamento (UE) 2024/1689, clasifica los sistemas por nivel de riesgo y establece obligaciones distintas para proveedores, responsables del despliegue y otros actores. Su artículo 6 delimita, entre otros supuestos, los sistemas de alto riesgo vinculados a determinados productos o usos enumerados en el anexo III. El artículo 10 aborda la gobernanza y gestión de datos para sistemas de alto riesgo; el artículo 13 exige transparencia y comunicación de información; el artículo 14 regula la supervisión humana.

La coincidencia temática con el RGPD puede confundir. Un conjunto de datos conforme al artículo 10 del AI Act no queda automáticamente legitimado por el artículo 6 del RGPD. Del mismo modo, proporcionar información al usuario conforme al artículo 13 del AI Act no sustituye necesariamente el deber de información de los artículos 13 y 14 del RGPD. Son obligaciones distintas, aunque puedan gestionarse con una misma evidencia técnica.

La mejor respuesta no consiste en crear dos burocracias paralelas. Consiste en construir un expediente único de sistema que separe claramente las preguntas. Para el RGPD: qué datos personales se tratan, con qué base, para qué finalidad, durante cuánto tiempo y con qué derechos. Para el AI Act: qué papel ocupa la organización, qué clasificación tiene el sistema, qué requisitos técnicos aplican, cómo se documentan los riesgos, qué instrucciones recibe el usuario y cómo se ejerce la supervisión humana.

La obligación de alfabetización en IA del artículo 4 del AI Act, aplicable desde el 2 de febrero de 2025, tiene una consecuencia práctica en 2026: formar a los usuarios ya no puede limitarse a enseñarles a escribir mejores prompts. Deben entender las limitaciones del sistema, los riesgos de introducir datos personales, los criterios para escalar una salida y las situaciones en las que está prohibido confiar en ella. Una política de uso aceptable sin formación y controles técnicos es una declaración, no una medida.

El artículo 27 del AI Act exige, para determinados sistemas de alto riesgo, una evaluación de impacto sobre derechos fundamentales por parte de los responsables del despliegue que sean entidades determinadas, incluidos organismos públicos y determinados operadores. Cuando coincida con una DPIA del artículo 35 del RGPD, la organización debería coordinar ambas evaluaciones, pero no dar por hecho que una reemplaza a la otra. La primera mira el impacto sobre derechos fundamentales en el sentido del AI Act; la segunda analiza los riesgos del tratamiento de datos personales y las medidas para mitigarlos.

Qué debe cambiar en la arquitectura y en el control

La privacidad de un sistema de IA no se demuestra con la política final, sino con decisiones de diseño que puedan observarse. El primer control es un registro de casos de uso: finalidad, propietario, modelo, proveedor, datos de entrada, usuarios, países de procesamiento, decisión que genera y nivel de impacto. Si una herramienta no aparece en ese inventario porque “la contrató marketing” o “solo es un copiloto”, la organización está gobernando por accidente.

El segundo control es la separación entre experimentación y producción. Un entorno de prueba no debería recibir datos reales por comodidad. Cuando sea imprescindible utilizarlos, deben existir autorización, minimización, segregación, plazo de borrado y registro de acceso. El uso de cuentas personales o herramientas públicas para pegar expedientes, contratos o información de clientes no es una innovación informal: puede constituir una divulgación no autorizada.

El tercer control es la trazabilidad. Hay que conservar la versión del modelo, la configuración relevante, el conjunto de datos utilizado, las instrucciones del sistema, los cambios realizados y los resultados de las pruebas. No hace falta guardar indiscriminadamente todas las conversaciones para demostrar control. De hecho, hacerlo puede crear un nuevo problema de minimización. Hay que definir qué evidencia es necesaria, quién puede verla y cuándo se elimina.

El cuarto control es la gestión de incidentes. Una extracción de datos personales mediante prompt injection, una respuesta que revela información de otro usuario o un fallo de filtrado pueden activar obligaciones del artículo 33 del RGPD, que fija un plazo de 72 horas para notificar una violación de seguridad a la autoridad de control cuando exista riesgo para los derechos y libertades. El cómputo no empieza cuando el comité termina de reunirse; comienza cuando el responsable tiene conocimiento suficiente de la brecha.

El CISO debería integrar estos escenarios en el plan de respuesta: quién conserva los logs, cómo se delimita el alcance, cómo se bloquean las credenciales, cómo se comprueba si el modelo memorizó información y quién decide sobre la notificación. Un sistema que no puede responder a esas preguntas no está preparado, aunque su proveedor exhiba una certificación de seguridad.

La evidencia que separa un programa defendible de una promesa

Ante una auditoría, la pregunta no será únicamente qué dice la política de IA. Será qué ocurrió con un caso concreto. La organización debería poder reconstruir la cadena completa: quién aprobó la finalidad, qué base jurídica se documentó, qué datos entraron, qué proveedor los procesó, qué controles de minimización se aplicaron, qué información recibió la persona, qué decisión produjo el modelo y qué revisión humana tuvo lugar.

Para ello resultan útiles, entre otros, estos registros:

• el inventario de tratamientos y sistemas de IA, con propietario y finalidad específica;
• el análisis de base jurídica y, cuando proceda, el test de interés legítimo;
• la DPIA del artículo 35 del RGPD y su relación con la evaluación de impacto del AI Act;
• el mapa de datos, transferencias, subencargados y plazos de conservación;
• los resultados de pruebas de reidentificación, filtración, sesgo, exactitud y robustez;
• los contratos del artículo 28 del RGPD y las garantías aplicables a transferencias internacionales;
• los registros de intervención humana, rectificación, oposición y reclamaciones;
• la evidencia de formación exigida por el artículo 4 del AI Act y de control de accesos.

La lista no es un ritual documental. Cada elemento debe permitir tomar una decisión. Si las pruebas detectan que el modelo expone nombres incluidos en los datos de entrenamiento, la respuesta no puede ser archivar el informe y continuar. Si la evaluación revela que el sistema discrimina a un grupo, hay que modificar los datos, el modelo, el umbral o el caso de uso. La gobernanza que no puede detener un lanzamiento es solo una función de archivo.

La decisión que los responsables deben tomar ahora

La cuestión no es si la organización utilizará IA. En 2026, muchas ya lo hacen, incluso cuando el comité de dirección no ha aprobado formalmente ningún programa: empleados que resumen contratos, equipos que analizan llamadas, desarrolladores que introducen código en asistentes y proveedores que incorporan funciones generativas en productos existentes.

El problema real es si la empresa sabe dónde ocurre ese tratamiento y puede defenderlo. Un programa serio empieza por localizar los usos existentes, no por comprar otra plataforma de gobierno. Después distingue los casos de bajo impacto de los que afectan a derechos, exige una finalidad concreta, limita los datos, examina al proveedor y define qué decisión humana sigue a la salida del modelo.

El criterio más útil es sencillo: si una persona afectada preguntara “¿qué datos míos utilizasteis, para qué, con qué autoridad y cómo puedo impugnar el resultado?”, la organización debería poder responder sin esconderse detrás de la palabra algoritmo. El RGPD no exige que cada sistema sea perfecto. Exige que el tratamiento sea lícito, transparente, proporcionado y controlable. El AI Act añade obligaciones técnicas y de gobernanza, pero no cambia esa regla de fondo.

La casilla de consentimiento puede ser una herramienta válida. Nunca será un sustituto del análisis. En IA, la privacidad se gana antes de entrenar el modelo: al elegir la finalidad, reducir los datos, diseñar la revisión humana y conservar las pruebas que permiten demostrar que la organización sabía lo que estaba haciendo.