Cómo proteger datos personales en un proyecto de IA

El despliegue de sistemas de inteligencia artificial en el entorno empresarial español ha dejado de ser una aspiración estratégica para convertirse en una realidad operativa cotidiana. Con esa realidad llega, de forma inevitable, una exposición regulatoria que muchas organizaciones no han comenzado a gestionar. El Reglamento General de Protección de Datos (RGPD) y la Ley Orgánica de Protección de Datos y Garantía de los Derechos Digitales (LOPDGDD) son plenamente aplicables a los proyectos de inteligencia artificial que traten datos personales, con independencia de que el modelo haya sido desarrollado internamente o adquirido a un tercero.

Por qué la inteligencia artificial plantea un desafío específico de protección de datos

Un proyecto de inteligencia artificial no es un tratamiento de datos convencional. La singularidad reside en tres elementos que agravan el riesgo de cumplimiento.

El primero es el volumen y la variedad de los datos de entrenamiento. Para que un modelo aprenda, necesita datos. Muchas organizaciones recurren a conjuntos de datos históricos que contienen, de forma más o menos explícita, información personal de clientes, empleados o usuarios. El tratamiento de esos datos con una finalidad distinta a la que motivó su recogida original puede infringir el principio de limitación de la finalidad que establece el RGPD.

El segundo elemento es la opacidad del proceso. Los modelos de aprendizaje automático son, con frecuencia, cajas negras cuyas decisiones resultan difícilmente explicables. Esto entra en tensión directa con el derecho a no ser objeto de decisiones exclusivamente automatizadas que produzcan efectos jurídicos significativos. La normativa de protección de datos exige que el afectado pueda obtener una explicación de la lógica aplicada.

El tercer factor es la persistencia del dato en el modelo. A diferencia de una base de datos relacional, la información personal puede quedar "incrustada" en los pesos del modelo de manera que resulte imposible eliminarla sin reentrenar el sistema. Esto dificulta el ejercicio del derecho de supresión por parte del interesado y obliga a diseñar soluciones técnicas desde el origen.

En nuestra práctica hemos observado que las empresas que abordan el proyecto de IA sin una evaluación de impacto previa descubren estos problemas cuando el sistema ya está en producción. En ese momento, el coste de corrección es considerablemente superior al que habría supuesto un diseño preventivo.

¿Qué exige el marco normativo aplicable a un proyecto de IA que trata datos?

El marco de referencia en España es dual. Por un lado, el RGPD establece las obligaciones de carácter horizontal aplicables a cualquier tratamiento de datos personales. Por otro, la LOPDGDD complementa y especifica ese marco para el contexto nacional, con reglas sobre el delegado de protección de datos, los derechos digitales en el ámbito laboral y otras particularidades.

A estas dos normas se añade un tercer elemento en proceso de maduración: el Reglamento de Inteligencia Artificial de la Unión Europea, cuya aplicación progresiva introduce una capa específica de obligaciones para los sistemas de IA de "alto riesgo". Las empresas que operen sistemas clasificados en esa categoría se enfrentarán a requisitos de transparencia, supervisión humana, robustez y documentación técnica que se superponen con los de protección de datos.

Desde la perspectiva del RGPD, las obligaciones más relevantes para un proyecto de IA son las siguientes:

• Base jurídica del tratamiento. Todo tratamiento de datos personales en el proyecto – incluyendo el entrenamiento, la validación, la inferencia y el almacenamiento de resultados – requiere una base jurídica válida. El consentimiento, el interés legítimo o la ejecución de un contrato son las más habituales, pero cada una impone condiciones específicas que conviene analizar antes de comenzar el desarrollo.
• Evaluación de impacto relativa a la protección de datos (EIPD). Cuando el tratamiento sea susceptible de entrañar un alto riesgo para los derechos y libertades de las personas físicas, la normativa exige realizar una evaluación de impacto previa. Los sistemas de IA que toman decisiones automatizadas sobre personas, que procesan datos sensibles o que supervisan a escala son candidatos directos a este requisito.
• Privacidad desde el diseño y por defecto. La normativa obliga a integrar los principios de protección de datos en el propio diseño del sistema, no como un parche posterior. Esto implica decisiones técnicas concretas: seudonimización de los datos de entrenamiento, control de acceso granular, minimización del dato que entra en el modelo.
• Registro de actividades de tratamiento. La empresa debe documentar los tratamientos asociados al proyecto en su registro de actividades. Este registro es el primer documento que revisa la AEPD en una inspección y el primero que se solicita en un litigio.
• Contratos con encargados del tratamiento. Si el desarrollo del modelo, el alojamiento de la infraestructura o el suministro de datos los realiza un tercero, la relación debe formalizarse mediante un contrato de encargado del tratamiento que cumpla los requisitos de la normativa. Los contratos estándar de proveedores de servicios en la nube rara vez cubren estos requisitos de forma completa.

¿Qué sucede si la empresa omite estos pasos? La AEPD puede abrir un procedimiento sancionador de oficio o a raíz de una denuncia. Las sanciones previstas en el RGPD son significativas y, en los casos más graves, pueden alcanzar un porcentaje relevante de la facturación global de la organización. El historial de resoluciones de la AEPD refleja que los proyectos tecnológicos mal diseñados desde la perspectiva de datos son una fuente recurrente de expedientes.

Fase 1 – Diagnóstico y mapeo de datos antes de arrancar el desarrollo

La primera fase del proceso es la más crítica y la más frecuentemente omitida. Antes de escribir una sola línea de código o de contratar la infraestructura de computación, la dirección debe conocer con precisión qué datos va a tratar el proyecto.

El punto de partida es un inventario de fuentes. ¿De dónde proceden los datos de entrenamiento? ¿Fueron recogidos con el consentimiento del interesado o bajo otra base jurídica? ¿Se van a usar para un fin distinto al original? ¿Contienen categorías especiales de datos – datos de salud, datos biométricos, datos de afiliación política o sindical?

La respuesta a estas preguntas determina el régimen jurídico aplicable. Los datos biométricos o de salud están sujetos a restricciones adicionales bajo el RGPD, y su uso en proyectos de IA requiere una justificación jurídica reforzada.

A continuación, corresponde realizar el mapeo de flujos de datos. Este ejercicio documenta cómo se mueven los datos dentro del proyecto: desde la ingesta inicial hasta el almacenamiento del modelo entrenado, pasando por las fases de preprocesamiento, entrenamiento, validación y puesta en producción. Cada nodo de ese flujo puede implicar un tratamiento diferenciado que debe justificarse y documentarse.

En nuestra experiencia asesorando a empresas en proyectos de IA, el mapeo revela con frecuencia la existencia de tratamientos derivados que no habían sido previstos en el diseño inicial: logs de inferencia que contienen datos personales de los usuarios que interactúan con el sistema, vectores de embeddings que permiten reconstruir información personal, o transferencias internacionales de datos hacia proveedores de infraestructura con servidores fuera del Espacio Económico Europeo.

El resultado de esta fase debe materializarse en dos documentos: el borrador del registro de actividades de tratamiento correspondiente al proyecto, y un primer análisis de riesgos que oriente la decisión sobre si es necesario realizar una evaluación de impacto formal.

Fase 2 – Evaluación de impacto: cuándo es obligatoria y cómo se realiza

La evaluación de impacto relativa a la protección de datos – conocida habitualmente por sus siglas EIPD o DPIA, de la expresión inglesa Data Protection Impact Assessment – es una herramienta de análisis preventivo que la normativa exige en determinados supuestos.

La AEPD ha publicado orientaciones sobre los tipos de tratamientos que la requieren. En el contexto de la inteligencia artificial, la EIPD es prácticamente siempre obligatoria cuando concurre alguna de estas circunstancias: el sistema toma decisiones automatizadas con efectos jurídicos o similares sobre personas físicas; el tratamiento implica datos de categorías especiales; el sistema supone una vigilancia o supervisión sistemática a gran escala; o se procesan datos de personas vulnerables.

La evaluación de impacto no es un simple cuestionario. Es un análisis estructurado que debe documentar la descripción del tratamiento y sus finalidades, la valoración de la necesidad y proporcionalidad de las medidas adoptadas, la evaluación de los riesgos para los derechos y libertades de los interesados, y las medidas previstas para afrontar esos riesgos. Si el análisis concluye que el riesgo residual es alto, la normativa obliga a consultar previamente a la AEPD antes de comenzar el tratamiento.

Una EIPD bien realizada tiene valor más allá del cumplimiento normativo. Funciona como una auditoría técnica del diseño del sistema que permite identificar vulnerabilidades antes de que se materialicen. Hemos implantado este proceso en empresas tecnológicas e industriales que, gracias a él, rediseñaron componentes del modelo que habrían generado riesgos legales y técnicos en producción.

¿Debe involucrarse el delegado de protección de datos en este proceso? Si la empresa está obligada a designar un delegado de protección de datos (DPD), la normativa establece expresamente que debe participar en la evaluación de impacto. El DPD actúa como asesor interno y como interlocutor con la AEPD, lo que hace especialmente relevante su implicación temprana en el proyecto.

Fase 3 – Diseño técnico con privacidad integrada

Una vez completado el análisis de riesgos, las conclusiones deben traducirse en decisiones técnicas concretas sobre la arquitectura del sistema. Este es el momento en que la protección de datos deja de ser un ejercicio de documentación para convertirse en ingeniería.

Las medidas más relevantes en esta fase son las siguientes:

1. Seudonimización y anonimización de los datos de entrenamiento. Cuando sea técnicamente posible, los datos personales deben sustituirse por identificadores que impidan la reidentificación directa. La anonimización efectiva sitúa los datos fuera del ámbito de aplicación del RGPD; la seudonimización, en cambio, los mantiene dentro pero reduce el riesgo asociado.
2. Minimización de datos. El principio de minimización exige que solo se traten los datos estrictamente necesarios para la finalidad del sistema. En la práctica, esto significa revisar críticamente cada campo de dato que entra en el modelo y justificar su necesidad.
3. Control de acceso y trazabilidad. El sistema debe implementar controles de acceso granulares que limiten quién puede interactuar con los datos de entrenamiento, los modelos entrenados y los resultados de la inferencia. La trazabilidad de los accesos es fundamental para detectar brechas de seguridad y para demostrar el cumplimiento ante la autoridad supervisora.
4. Retención y supresión. Deben definirse plazos de retención para cada categoría de dato y mecanismos técnicos que garanticen la supresión efectiva al finalizar esos plazos. En el caso de modelos de aprendizaje profundo, esto puede requerir estrategias específicas de "machine unlearning" o de reentrenamiento periódico.
5. Transferencias internacionales. Si la infraestructura del proyecto implica el tratamiento de datos fuera del Espacio Económico Europeo, deben adoptarse las garantías adecuadas previstas en la normativa. Las cláusulas contractuales tipo son el instrumento más habitual en ausencia de una decisión de adecuación de la Comisión Europea para el país de destino.

La coordinación entre el equipo jurídico y el equipo técnico es determinante en esta fase. En nuestra experiencia, los proyectos que no establecen un canal de comunicación fluido entre ambos equipos acaban produciendo sistemas que superan la auditoría técnica pero incumplen los requisitos normativos, o viceversa.

Fase 4 – Protocolo de brechas de seguridad y canal de denuncias

El RGPD impone una obligación de notificación de brechas de seguridad que muchas empresas subestiman hasta que se produce el incidente. La normativa establece un plazo de setenta y dos horas para notificar a la AEPD las brechas que sean susceptibles de entrañar un riesgo para los derechos y libertades de las personas físicas. Se trata de un plazo muy breve que exige contar con un protocolo operativo probado antes de que ocurra la incidencia.

Los proyectos de IA son especialmente vulnerables a determinados tipos de brecha. Los ataques de extracción de información – que permiten recuperar datos de entrenamiento a partir de las respuestas del modelo – son una amenaza documentada y creciente. Los ataques de envenenamiento de datos, que manipulan el conjunto de entrenamiento para alterar el comportamiento del modelo, pueden no detectarse hasta que el sistema está en producción. Y los fallos en el control de acceso a los artefactos del modelo constituyen una de las causas más frecuentes de exposición no intencionada de datos personales.

El protocolo de brechas debe definir, con claridad y sin ambigüedad, al menos los siguientes elementos: los criterios para clasificar un incidente como brecha de seguridad, los responsables internos de tomar la decisión de notificación, la forma y el contenido de la notificación a la AEPD y, cuando corresponda, a los interesados afectados, y el procedimiento de investigación y corrección posterior.

El compliance penal de la organización es otro vector que merece atención en este contexto. Las empresas con sistemas de compliance penal implantados – en particular, los modelos de prevención de delitos que contemplan la revelación de secretos y la vulneración de datos personales – deben revisar que el protocolo de IA se integra coherentemente con ese marco. Un canal de denuncias interno funcional es también un elemento que la normativa puede exigir en determinados contextos, y que actúa como mecanismo de detección temprana de incidentes internos relacionados con el tratamiento de datos.

El RGPD exige, además, que la empresa sea capaz de demostrar el cumplimiento, no solo de cumplirlo. Esto significa que el protocolo de brechas debe estar documentado, que los ejercicios de simulación deben quedar registrados y que la cadena de decisiones tomadas ante un incidente debe poder reconstruirse. Esa trazabilidad es la que, en la práctica, determina si la AEPD considera que la empresa actuó diligentemente.

¿Cuándo debe intervenir el delegado de protección de datos?

La designación de un delegado de protección de datos (DPD) es obligatoria para las empresas que realicen tratamientos que requieran una observación habitual y sistemática de interesados a gran escala, o que traten a gran escala categorías especiales de datos. Muchos proyectos de IA caen directamente en uno o en ambos supuestos.

Con independencia de la obligación formal, la figura del DPD – sea un profesional interno o externo – aporta un valor operativo que trasciende el cumplimiento normativo. El DPD actúa como punto de contacto con la AEPD, lo que resulta especialmente valioso en situaciones de brecha o de consulta previa. Participa en la evaluación de impacto, aportando criterio jurídico especializado al análisis de riesgos. Y, de cara a terceros – clientes, inversores, socios comerciales –, su presencia es un indicador de madurez en el gobierno del dato.

La adaptación al RGPD de un proyecto de IA no es un proyecto estático. La normativa impone una revisión periódica de las medidas implantadas a medida que evoluciona el sistema, cambia su finalidad o se incorporan nuevas fuentes de datos. El DPD debe ser informado de cualquier cambio relevante en el proyecto antes de que se implemente, no después.

¿Qué riesgos concretos corre la empresa que no gestiona este cumplimiento?

La respuesta a esta pregunta no se agota en el riesgo sancionador, aunque este sea el más visible. La AEPD puede imponer multas cuya cuantía, en los casos más graves, está vinculada a la facturación global de la empresa. Pero el régimen sancionador es solo una de las consecuencias de la falta de cumplimiento.

Un segundo riesgo es la paralización del proyecto. La AEPD tiene potestad para ordenar la suspensión provisional o definitiva de tratamientos que vulneren la normativa. En el caso de un sistema de IA que esté generando valor operativo para la empresa, esta medida puede tener un impacto económico directo e inmediato.

El tercer riesgo es la responsabilidad civil frente a los interesados. Las personas cuyos datos hayan sido tratados de forma ilícita pueden reclamar una indemnización por los daños sufridos. Este vector de riesgo es especialmente relevante cuando el sistema de IA toma decisiones que afectan a empleados, clientes o usuarios.

El cuarto riesgo afecta a las relaciones comerciales. Cada vez con mayor frecuencia, los clientes empresariales y los inversores incluyen en sus procesos de diligencia debida (due diligence) una revisión del estado de cumplimiento de protección de datos. Una empresa que no puede acreditar un programa de compliance robusto frente a la inteligencia artificial puede perder operaciones o ver condicionada su valoración.

La creencia de que con una cláusula de privacidad en la web ya se cumple el RGPD es uno de los errores conceptuales más extendidos que encontramos en nuestra práctica. El RGPD es un sistema de obligaciones materiales y documentales que exige, entre otras cosas, el registro de tratamientos, el protocolo de brechas y un modelo de compliance efectivo. La mera publicación de una política de privacidad no acredita el cumplimiento de ninguna de esas obligaciones.

El registro de tratamientos, el protocolo de brechas y el modelo de compliance, implantados de forma coherente y documentada, son los elementos que, en la práctica, reducen tanto la probabilidad de sanción como la cuantía de las que eventualmente se impongan. La autoridad supervisora valora la diligencia demostrada, y esa diligencia se acredita con documentación, no con intenciones.

Checklist de cumplimiento para un proyecto de IA con datos personales

El siguiente esquema sintetiza las acciones que la dirección debe verificar antes del lanzamiento de un sistema de inteligencia artificial que trate datos personales:

• Inventario de fuentes de datos de entrenamiento completado y base jurídica identificada para cada categoría.
• Mapeo de flujos de datos documentado, incluyendo transferencias internacionales y relaciones con proveedores.
• Análisis de necesidad de evaluación de impacto (EIPD) realizado y, si procede, EIPD finalizada antes del inicio del tratamiento.
• Contratos de encargado del tratamiento firmados con todos los proveedores que accedan a datos personales en el contexto del proyecto.
• Medidas técnicas de privacidad por diseño implementadas: seudonimización, minimización, control de acceso, trazabilidad.
• Plazos de retención definidos y mecanismos de supresión técnicamente operativos.
• Protocolo de brechas de seguridad documentado, probado y con responsables designados.
• Mecanismo para el ejercicio de derechos de los interesados operativo y con plazo de respuesta inferior a un mes.
• DPD informado del proyecto y con acceso a la documentación de cumplimiento.
• Registro de actividades de tratamiento actualizado con las entradas correspondientes al proyecto.
• Revisión de compatibilidad con el Reglamento de IA de la UE si el sistema puede calificarse como de alto riesgo.
• Integración del protocolo con el sistema de compliance penal de la empresa y con el canal de denuncias interno, si existe.

Este listado no sustituye al análisis jurídico específico de cada proyecto, pero sirve como herramienta de diagnóstico preliminar para la dirección. Los elementos que queden sin marcar son los que definen la prioridad de la agenda de cumplimiento.

Servicios relacionados

La protección de datos en proyectos de IA es una materia transversal que conecta de forma natural con otras áreas de asesoramiento. La implantación de un programa de protección de datos y compliance proporciona el marco institucional en el que el cumplimiento del proyecto de IA debe integrarse. Para las empresas del sector industrial, nuestra guía de protección de datos para la industria y la manufactura ofrece un análisis adaptado a los retos específicos de ese entorno. Cuando el proyecto de IA se enmarca en una operación corporativa, el análisis de los riesgos de datos debe incorporarse al proceso de diligencia debida de datos en operaciones de M&A.