Gobernar datos, privacidad y finalidad

La existencia de una función de IA no autoriza a introducir cualquier información. El gobierno de datos empieza antes del prompt: qué finalidad existe, qué datos son necesarios, quién decide sobre ellos y por qué deben atravesar cada componente.

Cuando hay datos personales, el análisis debe integrar el RGPD y cualquier normativa aplicable. Este curso no sustituye al DPO, asesoría jurídica ni análisis sectorial; proporciona un método para detectar qué debe documentarse y cuándo escalar.

Dibuja el flujo completo

No escribas «los datos van a la IA».

Representa:

origen → aplicación → proveedor → almacenamiento → modelo → herramientas → salida → logs → archivo/borrado

Para cada etapa registra:

• categorías de datos;
• personas;
• finalidad;
• base o justificación a revisar;
• ubicación;
• destinatarios;
• acceso;
• transformación;
• retención;
• eliminación;
• evidencia contractual;
• controles.

Incluye datos indirectos:

• prompts;
• archivos;
• metadatos;
• embeddings;
• feedback;
• logs;
• trazas;
• resultados de herramientas;
• cachés;
• backups.

Aplica los principios del RGPD cuando proceda

El artículo 5 incluye principios como:

• licitud, lealtad y transparencia;
• limitación de la finalidad;
• minimización;
• exactitud;
• limitación del plazo;
• integridad y confidencialidad;
• responsabilidad proactiva.

No basta con ponerlos en una política. Conviértelos en decisiones técnicas.

Minimización

Pregunta por cada campo:

«Si eliminamos este dato, ¿la función deja de cumplir su finalidad?».

Si no, considera no enviarlo.

Finalidad

Un dato recogido para prestar un servicio no queda automáticamente disponible para entrenar, evaluar o crear perfiles.

Exactitud

Una salida generada puede convertirse en dato personal almacenado. Si se reutiliza, debe existir un mecanismo para detectar y corregir errores.

Conservación

Define plazos por categoría. «Lo guardamos porque puede ser útil» no es una política.

Distingue tratamiento y entrenamiento

Enviar datos a un servicio para inferencia no significa necesariamente que se utilicen para entrenar modelos. Y que un proveedor diga «no entrenamos con datos empresariales» no resuelve por sí solo:

• retención;
• abuso monitoring;
• subencargados;
• logs;
• backups;
• región;
• soporte;
• otras finalidades.

Revisa el servicio y plan concretos.

Decide quién es responsable y quién encargado

En determinados escenarios de tratamiento de datos personales, un proveedor puede actuar como encargado por cuenta de la organización. El artículo 28 del RGPD establece requisitos específicos para esa relación.

No presupongas el rol contractual. Un proveedor puede tratar determinados datos bajo roles distintos para finalidades distintas.

La ficha debe registrar:

• responsable;
• encargado;
• subencargados;
• finalidades;
• instrucciones;
• medidas;
• devolución o borrado;
• asistencia;
• auditoría;
• transferencias.

La calificación final corresponde a revisión jurídica.

Identifica categorías especiales y alto riesgo

Si el caso implica:

• salud;
• biometría;
• ideología;
• religión;
• orientación sexual;
• datos de menores;
• monitorización extensa;
• decisiones significativas;
• nuevas tecnologías combinadas con alto impacto;

escala temprano.

No esperes al final del piloto para descubrir que el diseño necesita una evaluación formal.

DPIA

El artículo 35 del RGPD exige una evaluación de impacto cuando un tipo de tratamiento probablemente entrañe un alto riesgo para derechos y libertades.

Una DPIA no equivale a una matriz genérica de riesgos de IA. Tiene finalidad y contenido propios.

El triaje debe poder decir:

posible alto riesgo de protección de datos → revisar necesidad de DPIA con el responsable competente

No debe decir:

score > 7 → DPIA obligatoria

Decisiones automatizadas

El artículo 22 del RGPD regula determinadas decisiones basadas únicamente en tratamiento automatizado que producen efectos jurídicos o afectan de modo similar significativamente, con excepciones y salvaguardias.

No toda recomendación de IA entra automáticamente. Tampoco basta con insertar un clic humano sin capacidad real para afirmar que la decisión deja de ser automatizada.

Documenta:

• qué decide el sistema;
• qué decide la persona;
• qué información ve;
• qué tiempo tiene;
• si puede apartarse;
• qué ocurre cuando discrepa.

Privacidad desde el diseño

Antes de implementar:

• separa tenants;
• aplica mínimos privilegios;
• cifra cuando corresponda;
• limita logs;
• evita secretos en prompts;
• diseña borrado;
• documenta retención;
• minimiza contexto;
• valida exports;
• controla acceso a evaluaciones.

La privacidad no es una fase posterior.

Ejemplo: asistente de RR. HH.

Un equipo quiere resumir entrevistas de candidatos.

El flujo incluye audio, transcripción, notas y resumen. Antes de usar IA se revisan finalidad, categorías de datos, acceso, proveedor, retención, transferencias y la relación con el proceso de selección.

Si el sistema además puntúa candidatos o influye en decisiones, el caso cambia de naturaleza y necesita un análisis más profundo.

Ejercicio

Construye un mapa de datos para un caso real e identifica:

• datos imprescindibles;
• datos eliminables;
• responsables;
• proveedores;
• subencargados;
• retención;
• acceso;
• transferencia;
• logs;
• evidencia;
• posibles triggers de DPIA;
• posibles decisiones automatizadas significativas.

No concluyas legalidad. Entrega una lista de preguntas resueltas, pendientes y escaladas.

Resultado de la lección

Debes terminar con un mapa que conecte finalidad, datos, personas, componentes, roles y controles. La siguiente lección extiende el análisis a proveedores y a los cambios que pueden alterar ese mapa sin que el equipo modifique su propio código.