Módulo 5: GDPR for AI Systems
Documentation y DPO en contextos AI
Descripción
GDPR exige records of processing activities (Art. 30). Para AI, esto significa documentación específica: qué datos procesa el modelo, qué decisiones automatiza, qué safeguards aplican.
Adicionalmente, ciertos sistemas requieren DPO (Data Protection Officer). Esta cápsula te dice cuándo necesitás DPO y qué responsabilidades tiene en contextos AI.
Al terminar vas a poder:
- Producir los records de Art. 30 para tu sistema AI
- Identificar si tu organización necesita DPO
- Definir rol del DPO en el ciclo de desarrollo AI
- Implementar DPIA (Data Protection Impact Assessment) para high-risk AI
Records of Processing Activities (Art. 30)
Todo controller tiene que mantener records. Para AI, mínimo:
# RoPA — AI Knowledge Assistant
## Activity name
Automated customer query response with RAG and LLM
## Purposes
- Provide rapid customer support
- Improve customer satisfaction
- Reduce support costs
## Categories of data subjects
- Employees of client organizations (50K individuals across 50 tenants)
## Categories of personal data
- User identifier (Slack user ID, work email)
- Query content (may contain personal context)
- Conversation history
- Feedback provided
## Categories of recipients
- Internal: development team (access logs only), support team
- External: OpenAI (LLM provider, US-based; SCCs in place)
- External: Pinecone (vector DB, AWS US; processed under DPA)
## Transfers outside EU
- Yes: USA (OpenAI, Pinecone)
- Safeguards: SCCs (Standard Contractual Clauses), DPAs with both providers
- Adequacy decisions reviewed quarterly
## Retention periods
- Conversation logs: 90 days for detailed; 24 months aggregated
- Training datasets: 12 months
- User feedback: 24 months
- Authentication tokens: until revoked + 30 days
## Technical and organizational security measures
- Encryption at rest (AES-256)
- Encryption in transit (TLS 1.3)
- Access controls (RBAC, MFA)
- Audit logs maintained
- Quarterly security reviews
- Annual DPIA review
## Legal basis
- Contract: providing the service
- Legitimate Interest: improving service (LIA documented)
- Consent: optional features (AI personalization)
## Automated decision-making (Art. 22)
- Yes, present for: automatic categorization, query routing
- NOT present for: final decisions affecting users
- Right to challenge: implemented via [link]Mantenelo actualizado cada vez que el sistema cambia significativamente.
¿Necesitás DPO? (Art. 37)
Designation de DPO es obligatorio si:
Criterion A: Public authority
Tu organización es public sector → DPO obligatorio.
Criterion B: Large-scale monitoring
"Core activities consist of regular and systematic monitoring of data subjects on a large scale"
Si tu producto: monitorea usuarios en general scale (millones), tracking behavior, etc. → DPO.
AI examples: behavior tracking, surveillance, location tracking systems.
Criterion C: Large-scale special category data
Sensitive data processing on large scale.
AI examples: health AI systems, facial recognition, criminal record processing.
Si NO obligatorio
Para AI engineering startups típicos:
- 50 tenants, 50K end-users total → probable NO obligatorio
- Datos no son sensitive special category → NO obligatorio
- Aún si NO obligatorio, best practice designar a alguien (often legal counsel or compliance lead)
Rol del DPO en development AI
Si tenés DPO, su involvement en AI projects:
Pre-development
- Revisar purpose de nuevo sistema
- Evaluar legal basis apropiada
- Sugerir alternativas less intrusive si applicable
- Aprobar el DPIA
Development
- Review data flow diagrams
- Validate safeguards técnicos (encryption, access controls)
- Approve privacy policy updates
- Sign-off antes de production
Post-deployment
- Monitor complaints y data subject requests
- Audit periodic compliance
- Update records as system evolves
- Liaison con regulators if needed
Critical: DPO INDEPENDENCE
DPO debe ser independent — no responder al engineering manager que builds the AI. Puede ser external consultant o in-house pero con report directo to highest management.
DPIA — Data Protection Impact Assessment
Requerido cuando processing "likely to result in high risk" (Art. 35).
Cuándo DPIA es obligatorio
Always for:
- Automated decision-making affecting people significantly (your Art. 22 system)
- Large-scale monitoring of public areas
- Large-scale sensitive data processing
- Innovative technologies (often catches AI systems)
Probably for:
- Cualquier high-risk AI system bajo EU AI Act
- Profile-based decisions
- Vulnerable group data (children, employees)
Structure of DPIA
# DPIA — AI Knowledge Assistant
## 1. Description of processing
[High-level: what does the system do, what data, who's affected]
## 2. Necessity and proportionality assessment
- Is processing necessary for purpose?
- Less intrusive alternatives considered?
- Lawful basis identified
## 3. Risk assessment to data subjects
- Risk 1: bias in responses leading to discrimination
- Risk 2: leakage of training data via memorization
- Risk 3: profile inference enabling tracking
- Risk 4: incorrect automated decisions
## 4. Mitigation measures
- Risk 1: bias audit toolkit (M2 deliverable) + quarterly fairness review
- Risk 2: training data anonymized + DP applied
- Risk 3: tenant isolation + access controls
- Risk 4: human-in-the-loop for significant decisions
## 5. Residual risk
- Low to medium after mitigations
- Documented + accepted by management
## 6. Consultation
- DPO consulted: yes (2026-XX-XX)
- Data subjects consulted: not feasible at this scale
- Regulator consultation: not required (residual risk manageable)
## 7. Review schedule
- Annual review
- Triggered review when significant changesDocumentación as artifacts del path
Si seguiste el path completo, tenés muchos artifacts que son parte de la documentación GDPR:
| Path artifact | Sirve para GDPR como... |
|---|---|
| Architecture Design Doc (M8 system-design) | Records de processing activities |
| Bias Audit Toolkit (M2 ethics) | Risk assessment for bias |
| Privacy Assessment (M3 ethics) | Privacy section of RoPA |
| Risk Classification (M4 ethics) | EU AI Act risk + GDPR DPIA |
| GDPR Checklist (M5 — your deliverable) | Compliance checklist |
| Standards Mapping (M6) | Standards documentation |
| Ethics Audit Report (M8 ethics) | Periodic compliance review |
Eficiencia: no estás haciendo trabajo nuevo de compliance. Estás organizando lo que ya producís.
Trampas comunes
Trampa 1 — RoPA outdated. Sistema cambia, RoPA no se actualiza. En audit: "describe processing actual" no es lo que está documentado → red flag.
Trampa 2 — DPO reporta a dev manager. No es independent. Conflicto de interés cuando dev quiere shipping, DPO debe slow down.
Trampa 3 — DPIA hecho una vez, never updated. Major changes al sistema (nuevo modelo, nueva data source) sin re-DPIA.
Trampa 4 — Documentation que solo legal entiende. Engineers no saben qué decir cuando regulators ask. Documentation debe ser accessible para todos.
Trampa 5 — No DPIA porque "no es high risk." Pero tu sistema automatically decides things about users. Es high risk. Don't avoid DPIA out of inconvenience.
Ejercicio
Para tu sistema AI del path:
- Drafteá un RoPA siguiendo el template
- ¿Necesitás DPO? Justificá con criteria
- Drafteá un DPIA básico (high-level)
- Mapea path artifacts a documentación GDPR
Ver solución (skeleton)
RoPA: usar template del módulo, llenar con detalles específicos de tu sistema (Knowledge Assistant).
¿DPO necesario?:
- 50 tenants, 50K end users: not "large scale" definitively
- Datos: work emails, conversation, feedback → not sensitive category
- Monitoring: not systematic surveillance
- Conclusión: NO mandatory, pero recomendable (compliance lead designado)
DPIA básico:
- Description: AI assistant que automatiza customer support
- Necesidad: scale requires automation
- Risks: bias, training data leakage, profile inference, false rejections
- Mitigations: bias audit, anonymization, isolation, human review
- Residual: low-medium, acceptable
- Review: annual + on major changes
Path artifacts → GDPR docs:
- Sistema de M8 architecture → RoPA technical sections
- M2 bias toolkit → risk assessment for fairness
- M3 privacy assessment → privacy sections
- M4 risk classification → high-risk determination
- M7 framework checklist → ongoing compliance verification
Resumen
Aprendiste:
- ✅ Records of Processing Activities (Art. 30) — qué incluir
- ✅ DPO designation criteria (cuándo obligatorio)
- ✅ Rol del DPO en development AI (pre, during, post)
- ✅ DPIA structure y cuándo es requerido
- ✅ Path artifacts sirven como GDPR docs (eficiencia)
- ✅ Trampas: outdated docs, DPO sin independence, DPIAs unique
Checkpoint: si podés producir un RoPA + DPIA defensibles para tu sistema, estás listo.
Siguiente cápsula
08 — Proyecto: GDPR Compliance Checklist for AI consolida M5 en una checklist accionable.