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

Una empresa puede tener una política de privacidad impecable, un registro de actividades actualizado y un proveedor de IA contratado con todas las cláusulas habituales. Y aun así estar tratando datos personales de forma ilícita. El problema suele aparecer antes de que nadie pulse el botón de despliegue: cuando el equipo técnico incorpora a un modelo datos cuya procedencia, finalidad o necesidad no puede explicar con precisión.

La inteligencia artificial no crea una excepción al RGPD. Tampoco convierte en lícito todo lo que pueda mejorar un modelo. El Reglamento europeo sigue preguntando lo mismo que preguntaba antes de que la IA se convirtiera en la palabra favorita de cualquier comité ejecutivo: qué datos se tratan, para qué, con qué base jurídica, durante cuánto tiempo, con qué riesgos y bajo qué controles.

La diferencia es que los modelos de IA complican cada respuesta. Un sistema de selección de personal puede inferir características sensibles a partir de datos aparentemente inocuos. Un asistente interno puede recuperar información de clientes para responder a una consulta distinta de la finalidad original. Un modelo entrenado con historiales puede conservar patrones que nadie sabe localizar ni borrar de forma individual. La opacidad técnica no elimina la obligación jurídica; solo hace más cara la prueba.

El Comité Europeo de Protección de Datos ha abordado estas tensiones, entre otros trabajos, en su Dictamen 28/2024 sobre determinados aspectos de protección de datos relacionados con el tratamiento de datos personales en el contexto de modelos de IA. Su mensaje útil para un CISO o un responsable de cumplimiento no es que la IA esté prohibida. Es más incómodo: cada fase del ciclo de vida puede constituir un tratamiento distinto y necesita su propia justificación.

La primera pregunta no es qué modelo usar, sino qué tratamiento se está haciendo

Las organizaciones tienden a hablar de la IA como si fuera un producto único. Desde el punto de vista del RGPD, no lo es. Recopilar datos para entrenar un modelo, ajustar el modelo con información propia, introducir datos en una interfaz de un proveedor, generar una predicción y utilizarla para tomar una decisión son operaciones diferentes, aunque aparezcan bajo la misma etiqueta comercial.

El artículo 4.2 del RGPD define el tratamiento de forma amplia: incluye la recogida, consulta, utilización, organización, modificación, extracción, comunicación y supresión de datos personales. Una entidad que carga tickets de soporte en un servicio de IA externo no está simplemente usando una herramienta. Está comunicando datos a otro proveedor y, posiblemente, permitiendo que se empleen para una finalidad adicional. El contrato y la arquitectura deben reflejar esa realidad.

La clasificación de las partes también importa. El proveedor del modelo puede actuar como encargado del tratamiento si procesa los datos siguiendo instrucciones documentadas y sin decidir por sí mismo los fines y medios esenciales. Pero puede ser responsable independiente, o existir una corresponsabilidad, si determina que los datos se usarán para mejorar el servicio, combina información de distintos clientes o decide la finalidad del entrenamiento. El artículo 28 del RGPD no convierte automáticamente en encargado a todo proveedor que firma un acuerdo de tratamiento.

La primera tarea práctica consiste en dibujar el flujo completo. No basta con registrar la aplicación final. Hay que identificar el origen de los datos, los conjuntos utilizados en entrenamiento o ajuste, los prompts, los logs, las salidas, los sistemas de almacenamiento, los subencargados y los países desde los que se presta el servicio. En una entidad financiera, por ejemplo, el diagrama debería distinguir entre datos de identificación del cliente, información transaccional, grabaciones de llamadas, documentación de solvencia y metadatos de uso. Tratar todos esos elementos como un único paquete de datos de IA es una forma elegante de perder el control.

La base jurídica debe cubrir la finalidad real, no la presentación comercial

El artículo 6 del RGPD ofrece seis bases de licitud, pero ninguna funciona como comodín para proyectos de innovación. El consentimiento del artículo 6.1.a exige que sea libre, específico, informado e inequívoco. Si el usuario no puede negarse sin perder un servicio esencial, la libertad es discutible. Si se recaba para una finalidad vaga como mejorar nuestros sistemas de inteligencia artificial, la especificidad tampoco sale bien parada.

El contrato del artículo 6.1.b solo cubre tratamientos necesarios para ejecutar un contrato con el interesado. Que una empresa incluya una función de recomendación en su producto no significa que todo entrenamiento posterior sea necesario para prestar el servicio. La necesidad debe demostrarse, no declararse en una cláusula de condiciones generales.

El interés legítimo del artículo 6.1.f puede ser viable en determinados tratamientos, pero exige superar tres preguntas acumulativas: existe un interés legítimo, el tratamiento es necesario para ese interés y los derechos y libertades del interesado no prevalecen. La evaluación debe documentarse. En modelos de IA, el segundo y el tercer paso suelen ser los más débiles.

Una empresa puede tener un interés legítimo en detectar fraude o mejorar un sistema de atención. Eso no demuestra que necesite conservar indefinidamente todas las conversaciones de clientes, ni que deba transferirlas a un proveedor para entrenar un modelo generalista. Antes de invocar el artículo 6.1.f conviene comparar alternativas menos intrusivas: datos sintéticos, anonimización efectiva, muestreo, extracción de características, exclusión de campos libres o uso de un modelo que no reutilice las entradas del cliente.

El análisis de ponderación también debe incorporar las expectativas razonables del interesado. Un cliente que entrega documentos para solicitar una hipoteca espera que se evalúe su solvencia; no necesariamente que esos documentos se utilicen para entrenar un asistente comercial. Un empleado que conversa con un chatbot corporativo puede aceptar que se registre la interacción para resolver una incidencia, pero no que la conversación se utilice después para valorar su rendimiento.

El artículo 6 no opera solo. Cuando el conjunto de datos contiene categorías especiales —salud, biometría, opiniones políticas, afiliación sindical, orientación sexual, origen racial o étnico, entre otras— entra en juego el artículo 9. La existencia de una base del artículo 6 no autoriza por sí sola el tratamiento. Hace falta además una excepción del artículo 9.2, y algunas de ellas exigen garantías adicionales o una habilitación específica.

La trampa más habitual es la inferencia. Un modelo puede deducir una condición médica, una situación económica o una afiliación política sin que ese atributo aparezca literalmente en la base de datos. Que la empresa no haya guardado una columna llamada salud no significa que el sistema no esté tratando información relacionada con la salud. El análisis debe mirar también las salidas, los embeddings, los vectores y las variables proxy que permiten reconstruir características protegidas.

Minimización: menos datos no significa solo menos columnas

El artículo 5.1.c del RGPD exige que los datos sean adecuados, pertinentes y limitados a lo necesario en relación con la finalidad. En proyectos de IA, la minimización se suele reducir a una operación cosmética: eliminar el nombre y sustituirlo por un identificador. Eso puede reducir el riesgo de identificación directa, pero no resuelve la exposición de información financiera, geográfica, conductual o sensible.

La pregunta correcta no es cuántos campos tiene el dataset. Es qué información necesita realmente el modelo para producir una salida fiable y qué daño puede causar conservar el resto. Para un clasificador de incidencias quizá sean suficientes el texto técnico, el producto afectado y la fecha. Incluir el nombre del cliente, su dirección, el historial completo de pagos y todas las conversaciones anteriores puede mejorar marginalmente una predicción, pero no por eso resulta necesario.

La minimización debe aplicarse en varias capas:

• Recogida: no incorporar al proyecto datos que no tengan una función definida y documentada.
• Preparación: eliminar campos libres, identificadores directos y atributos proxy cuando no sean necesarios.
• Entrenamiento: separar los conjuntos de desarrollo, validación y producción, con controles de acceso independientes.
• Interacción: impedir que usuarios introduzcan datos de clientes en herramientas no aprobadas y aplicar filtros antes de enviar prompts.
• Conservación: fijar plazos para datasets, logs, salidas y copias de seguridad, no solo para la aplicación que consume el modelo.

La anonimización puede sacar los datos del ámbito del RGPD, pero el estándar es exigente. Pseudonimizar no es anonimizar: los datos pseudonimizados siguen siendo datos personales conforme al artículo 4.5. Un dataset deja de ser personal cuando la reidentificación resulta imposible de forma razonable, teniendo en cuenta medios, costes, tiempo y tecnología disponible. En modelos de IA hay que evaluar también si el sistema permite memorizar o recuperar fragmentos del conjunto de entrenamiento.

Por eso el borrado de un registro individual plantea una dificultad técnica que no conviene esconder bajo la alfombra jurídica. Si un modelo ha absorbido patrones de un historial de clientes, eliminar la fila original puede no eliminar su influencia. La organización debe definir antes del entrenamiento qué mecanismos utilizará para responder a derechos de supresión y oposición: exclusión del dataset, reentrenamiento, ajuste del modelo, bloqueo de recuperación o una combinación de controles. No existe una solución universal, pero sí existe la obligación de poder responder al interesado y demostrar diligencia.

Transparencia: el aviso de privacidad no puede ser un prospecto ilegible

Los artículos 13 y 14 del RGPD obligan a informar sobre el responsable, las finalidades, la base jurídica, los destinatarios, los plazos de conservación, los derechos y, cuando proceda, la existencia de decisiones automatizadas y la información significativa sobre la lógica utilizada. El artículo 15 permite al interesado obtener información sobre sus datos y sobre determinados aspectos del tratamiento.

En IA, una política de privacidad de veinte páginas que menciona de pasada el uso de algoritmos no cumple necesariamente con el objetivo de transparencia. La información debe permitir que una persona entienda qué va a ocurrir con sus datos. Si una compañía utiliza conversaciones de soporte para ajustar un modelo, debe explicarlo con un nivel de detalle suficiente para que el usuario pueda valorar las consecuencias. Decir que los datos se procesan para prestar servicios digitales es demasiado genérico si también se destinan a entrenamiento, evaluación o personalización.

La transparencia tampoco exige revelar secretos industriales ni publicar el código fuente completo. Sí exige explicar los factores relevantes, las categorías de datos utilizadas, la finalidad de la predicción, sus consecuencias y las posibilidades de intervención. En un sistema de concesión de crédito, no basta con decir que se usa inteligencia artificial. El interesado debería saber qué tipos de información influyen en la evaluación, cómo puede corregir datos inexactos y cómo puede impugnar el resultado.

La información debe aparecer en el momento adecuado. Un aviso genérico en la web no sustituye necesariamente a una explicación contextual dentro del proceso de contratación, atención al cliente o evaluación laboral. Tampoco sirve informar al empleado en 2024 de que quizá se utilicen herramientas automatizadas y considerar cubierto cualquier nuevo caso de uso que aparezca en 2026.

El AI Act añade obligaciones propias de transparencia que no desplazan las del RGPD. El artículo 50 del Reglamento (UE) 2024/1689 establece obligaciones para determinados sistemas de IA, incluidas algunas relacionadas con informar de la interacción con un sistema de IA y con marcar determinados contenidos generados o manipulados. La etiqueta de que una respuesta fue producida por IA puede satisfacer una obligación del AI Act y seguir siendo insuficiente para explicar el tratamiento de datos personales conforme a los artículos 13, 14 y 15 del RGPD. Son capas distintas, no casillas intercambiables.

El artículo 22 no prohíbe toda automatización, pero sí la comodidad de no decidir

El artículo 22 del RGPD reconoce el derecho a no ser objeto de 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. Esa formulación tiene dos elementos que suelen diluirse en las presentaciones comerciales: la decisión debe ser únicamente automatizada y el efecto debe tener suficiente relevancia.

Un filtro que ordena consultas de soporte puede no alcanzar ese umbral. Rechazar una solicitud de crédito, cancelar una póliza, excluir a un candidato de un proceso de selección o bloquear una cuenta por riesgo de fraude sí puede producir efectos jurídicos o significativamente similares. La clasificación no depende de que la empresa llame al resultado recomendación, puntuación o señal de riesgo.

Las excepciones del artículo 22.2 permiten la decisión cuando es necesaria para celebrar o ejecutar un contrato, está autorizada por el Derecho de la Unión o de los Estados miembros, o se basa en el consentimiento explícito. En los supuestos contractuales o de consentimiento, el artículo 22.3 exige salvaguardas, al menos el derecho a obtener intervención humana, expresar el punto de vista e impugnar la decisión. La intervención humana debe ser real: una persona que se limita a validar automáticamente la recomendación no aporta el control que la norma pretende.

La entidad debe poder demostrar quién intervino, qué información tenía esa persona, si podía apartarse del resultado, cuánto tiempo dedicó a revisar el caso y qué criterios utilizó. Un botón de aprobar en una pantalla no es supervisión humana; es decoración de interfaz.

El artículo 22 se relaciona con los artículos 5.1.a, 5.1.d y 5.1.f: licitud y transparencia, exactitud, e integridad y confidencialidad. Un modelo puede producir una decisión discriminatoria aunque su precisión estadística general parezca buena. Puede también generar falsos positivos concentrados en un grupo concreto. El control debe revisar métricas agregadas y segmentadas, errores, cambios de distribución, datos ausentes y vías de reclamación.

El AI Act refuerza este análisis cuando el sistema se clasifica como de alto riesgo. El artículo 10 exige prácticas de gobernanza y gestión de datos; el artículo 13 trata la transparencia y la información a los responsables del despliegue; el artículo 14 regula la supervisión humana. Además, determinados responsables del despliegue deben realizar una evaluación de impacto sobre los derechos fundamentales conforme al artículo 27. La calificación de alto riesgo bajo el AI Act no sustituye una evaluación de impacto de protección de datos del artículo 35 del RGPD. En muchos casos obliga a coordinar ambas evaluaciones para no producir dos documentos que describan dos realidades distintas.

La evaluación de impacto debe probar decisiones, no decorar expedientes

El artículo 35 del RGPD exige una evaluación de impacto cuando el tratamiento pueda entrañar un alto riesgo para los derechos y libertades de las personas. El uso de nuevas tecnologías, la evaluación sistemática y exhaustiva de aspectos personales basada en perfiles y el tratamiento a gran escala de categorías especiales son indicadores evidentes del tipo de riesgo que debe analizarse.

Una EIPD útil para IA debe describir el modelo y el tratamiento con suficiente precisión. No basta con indicar que se usará un proveedor externo. Hay que documentar el propósito, las entradas, las salidas, los grupos afectados, los errores previsibles, el proceso de revisión humana, los controles de acceso, el régimen de conservación y el procedimiento para ejercer derechos.

También debe incluir pruebas. Por ejemplo, una entidad que utiliza un modelo para detectar fraude debería conservar evidencia de la tasa de falsos positivos, la comparación entre grupos relevantes, las pruebas de robustez frente a datos incompletos y el análisis de los casos en que una persona revisora revocó la recomendación. Si el proveedor solo entrega una puntuación de exactitud global, la organización no tiene una evaluación de riesgo; tiene material de marketing.

La EIPD debe actualizarse cuando cambie el tratamiento. Un nuevo proveedor, una nueva fuente de datos, una ampliación del ámbito geográfico, un cambio de finalidad o una modificación sustancial del modelo pueden alterar el riesgo. La revisión no tiene que esperar a un incidente. El artículo 35.11 exige, cuando proceda, revisar si el tratamiento se realiza conforme a la evaluación al menos cuando cambien los riesgos.

El delegado de protección de datos, cuando exista, debe ser consultado conforme al artículo 35.2. Su función no consiste en bendecir el proyecto ni en convertirse en el propietario del riesgo. La decisión corresponde al responsable, que debe aceptar las limitaciones, financiar los controles y detener el despliegue cuando las medidas no reduzcan el riesgo a un nivel aceptable. Si el riesgo residual continúa siendo alto y no puede mitigarse, el artículo 36 prevé la consulta previa a la autoridad de control.

Contratación y arquitectura: el proveedor no puede convertirse en una caja negra jurídica

Los contratos con proveedores de IA deben responder a preguntas concretas. ¿El proveedor utiliza las entradas para entrenar modelos propios? ¿Puede conservar prompts y respuestas? ¿Dónde se almacenan? ¿Qué subencargados participan? ¿Cómo se atienden las solicitudes de acceso y supresión? ¿Qué evidencias ofrece sobre controles de seguridad, segregación entre clientes y gestión de incidentes?

El artículo 28.3 del RGPD exige que el contrato con el encargado regule, entre otros aspectos, el tratamiento siguiendo instrucciones documentadas, la confidencialidad, la seguridad, la asistencia al responsable, la supresión o devolución de datos y las auditorías. Una cláusula que autoriza al proveedor a usar los datos para mejorar servicios sin describir esa finalidad, categorías, conservación y controles deja demasiadas decisiones fuera de la instrucción del responsable.

El artículo 32 obliga a aplicar medidas técnicas y organizativas adecuadas al riesgo. Para una plataforma de IA, eso puede incluir prevención de pérdida de datos en prompts, gestión de identidades, separación de entornos, cifrado, registros de actividad, controles sobre plugins y conectores, pruebas de extracción de información y revisión de permisos. La confidencialidad del modelo no sustituye a la seguridad de los datos que entran en él.

El diseño más seguro suele ser el que reduce la información antes de que llegue al modelo. Un proxy puede detectar identificadores y bloquearlos. Un servicio de recuperación puede limitar los documentos accesibles a una colección aprobada. Un registro puede conservar la finalidad, el usuario, el modelo, la versión, la fuente de datos y la respuesta, aplicando al mismo tiempo una política de retención. No todos los casos necesitan estas medidas, pero ningún proyecto serio debería asumir que el proveedor hará el trabajo por defecto.

Las transferencias internacionales requieren un análisis separado. Si el proveedor accede desde fuera del Espacio Económico Europeo o los datos se almacenan en una jurisdicción tercera, la entidad debe examinar el capítulo V del RGPD, incluidos los artículos 44 a 49. Una promesa comercial de residencia europea no demuestra por sí sola dónde pueden acceder los subencargados, dónde se procesan las copias de seguridad o qué soporte técnico puede consultar los datos.

Los derechos del interesado chocan con el modelo probabilístico

El derecho de acceso del artículo 15 puede exigir información sobre los datos tratados, las finalidades, las categorías, los destinatarios y, cuando se produzcan decisiones automatizadas, información significativa sobre la lógica aplicada. En un sistema de IA generativa, responder con una explicación abstracta sobre redes neuronales no permite al interesado comprender por qué se produjo una salida concreta.

El derecho de rectificación del artículo 16 plantea otra dificultad. Si el sistema utiliza un dato incorrecto para generar una recomendación, corregir la base de datos de origen puede no cambiar automáticamente el modelo ni los índices que alimentan la recuperación. El responsable debe saber qué componente contiene el dato, qué procesos lo replican y cómo se propaga la corrección.

El derecho de supresión del artículo 17 tampoco se resuelve siempre eliminando el perfil del CRM. Hay que localizar copias, datasets de entrenamiento, logs, cachés, almacenes vectoriales y exportaciones. El artículo 17 contempla excepciones, pero no permite ignorar la solicitud porque el sistema sea difícil de modificar. La dificultad técnica debe abordarse en el diseño y en la selección del proveedor, no descargarse sobre el interesado.

El artículo 21 reconoce el derecho a oponerse a tratamientos basados en el artículo 6.1.e o 6.1.f, incluida la elaboración de perfiles. Cuando el tratamiento se realiza para mercadotecnia directa, la oposición es especialmente contundente. En otros casos habrá que valorar si existen motivos imperiosos, pero el proceso debe ser accesible y trazable. Un enlace escondido en una política de privacidad no es un mecanismo de oposición operativo.

Las solicitudes deben probarse con casos reales antes del despliegue. La entidad debería seleccionar registros sintéticos y reales bajo controles adecuados, ejercer acceso, rectificación, supresión y oposición, y medir cuánto tarda cada sistema en localizar y bloquear la información. El resultado debe alimentar la decisión de arquitectura. Si nadie puede explicar cómo se atiende una supresión, el modelo no está listo para datos personales.

Qué debe cambiar en la gobernanza interna

La gobernanza de IA no puede quedar atrapada entre el comité de innovación y el delegado de protección de datos. El CISO aporta controles de seguridad, pero no decide la base jurídica. El equipo jurídico interpreta la norma, pero no puede validar una arquitectura que no conoce. El propietario del producto entiende la finalidad, pero no debería aprobar por sí solo los riesgos para las personas.

Una estructura eficaz asigna responsabilidades por decisión. El propietario del caso de uso debe justificar la finalidad y los beneficios. Privacidad debe validar la base jurídica, la información y los derechos. Seguridad debe evaluar accesos, proveedores, registros, exfiltración y resiliencia. Riesgos y cumplimiento deben revisar el impacto regulatorio y la evidencia. El comité de aprobación debe tener autoridad para exigir cambios o prohibir el tratamiento.

El inventario de sistemas de IA debería incluir, como mínimo, la finalidad, el responsable interno, las categorías de datos, la base jurídica, el proveedor, la clasificación de riesgo, la interacción con personas, los países implicados, la fecha de última evaluación y el estado de los controles. En entidades financieras, ese inventario debe cruzarse con el registro de terceros TIC, los procesos críticos y las obligaciones de resiliencia operativa cuando el sistema se integre en servicios sujetos a DORA.

La formación también debe abandonar el enfoque de la charla anual. Un empleado que pega un extracto de una llamada de cliente en un chatbot público puede provocar una comunicación de datos en segundos. Las reglas deben indicar qué herramientas están autorizadas, qué datos están prohibidos, cómo se revisan las respuestas y dónde se reporta una exposición. Las instrucciones vagas producen incidentes muy concretos.

La prueba definitiva: poder explicar por qué se hizo cada cosa

El artículo 5.2 del RGPD establece el principio de responsabilidad proactiva. No basta con cumplir; hay que poder demostrar el cumplimiento. Para un sistema de IA, esa demostración debería conectar cada decisión con una evidencia: la finalidad aprobada, el análisis del artículo 6, la evaluación del artículo 9 cuando proceda, la EIPD del artículo 35, el contrato del artículo 28, las pruebas de minimización, los controles de seguridad del artículo 32 y el procedimiento para derechos.

La evidencia debe ser comprensible para más de un público. Un auditor necesita trazabilidad. El equipo técnico necesita requisitos ejecutables. El responsable de negocio necesita conocer las limitaciones. La autoridad de control necesita entender los riesgos. Si cada grupo recibe una explicación distinta y ninguna encaja con las demás, la organización no tiene gobernanza: tiene presentaciones.

La conclusión para 2026 es poco espectacular y por eso mismo útil. El RGPD no exige que una empresa renuncie a la IA, pero sí que deje de tratarla como una zona de excepción. La licitud se decide por finalidad y necesidad; la transparencia, por la información que puede entender el afectado; la minimización, por los datos que realmente hacen falta; y la automatización, por la capacidad de una persona de cuestionar una decisión que puede cambiar su vida.

El AI Act añade obligaciones de transparencia, gobernanza, supervisión y evaluación para determinados sistemas, pero no arregla una base jurídica insuficiente ni convierte un dataset excesivo en uno necesario. El orden correcto sigue siendo el menos glamuroso: definir el caso de uso, separar los tratamientos, justificar la finalidad, reducir los datos, probar los derechos y documentar quién puede detener el sistema. Solo después tiene sentido discutir qué modelo ofrece más precisión.