Module 5: GDPR for AI Systems

Documentation and the DPO in AI contexts

Next →

Description

GDPR requires records of processing activities (Art. 30). For AI, that means specific documentation: what data the model processes, what decisions it automates, what safeguards apply.

In addition, certain systems require a DPO (Data Protection Officer). This capsule tells you when you need a DPO and what responsibilities they have in AI contexts.

By the end you'll be able to:

  • Produce the Art. 30 records for your AI system
  • Identify whether your organization needs a DPO
  • Define the DPO's role in the AI development cycle
  • Implement a DPIA (Data Protection Impact Assessment) for high-risk AI

Records of Processing Activities (Art. 30)

Every controller has to maintain records. For AI, at minimum:

# 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 the 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 the 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]

Keep it up to date every time the system changes significantly.

Do you need a DPO? (Art. 37)

Designating a DPO is mandatory if:

Criterion A: Public authority

Your organization is public sector → a DPO is mandatory.

Criterion B: Large-scale monitoring

"Core activities consist of regular and systematic monitoring of data subjects on a large scale"

If your product: monitors users at general scale (millions), tracks behavior, etc. → DPO.

AI examples: behavior tracking, surveillance, location tracking systems.

Criterion C: Large-scale special category data

Sensitive data processing at large scale.

AI examples: health AI systems, facial recognition, criminal record processing.

If NOT mandatory

For a typical AI engineering startup:

  • 50 tenants, 50K end-users total → probably NOT mandatory
  • The data isn't a sensitive special category → NOT mandatory
  • Even if NOT mandatory, it's best practice to designate someone (often legal counsel or a compliance lead)

The DPO's role in AI development

If you have a DPO, their involvement in AI projects:

Pre-development

  • Review the purpose of the new system
  • Assess the appropriate legal basis
  • Suggest less intrusive alternatives where applicable
  • Approve the DPIA

Development

  • Review the data flow diagrams
  • Validate the technical safeguards (encryption, access controls)
  • Approve privacy policy updates
  • Sign off before production

Post-deployment

  • Monitor complaints and data subject requests
  • Audit periodic compliance
  • Update the records as the system evolves
  • Act as the liaison with regulators if needed

Critical: DPO INDEPENDENCE

The DPO must be independent — they can't report to the engineering manager who builds the AI. They can be an external consultant or in-house, but with a direct reporting line to the highest level of management.

DPIA — Data Protection Impact Assessment

Required when the processing is "likely to result in high risk" (Art. 35).

When a DPIA is mandatory

Always for:

  • Automated decision-making that significantly affects people (your Art. 22 system)
  • Large-scale monitoring of public areas
  • Large-scale sensitive data processing
  • Innovative technologies (this often catches AI systems)

Probably for:

  • Any high-risk AI system under the EU AI Act
  • Profile-based decisions
  • Vulnerable group data (children, employees)

The structure of a 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 the processing necessary for the purpose?
- Were 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 on significant changes

Documentation as path artifacts

If you followed the full path, you have many artifacts that are part of your GDPR documentation:

Path artifactServes GDPR as...
Architecture Design Doc (M8 system-design)Records of processing activities
Bias Audit Toolkit (M2 ethics)Risk assessment for bias
Privacy Assessment (M3 ethics)The privacy section of the RoPA
Risk Classification (M4 ethics)EU AI Act risk + GDPR DPIA
GDPR Checklist (M5 — your deliverable)The compliance checklist
Standards Mapping (M6)Standards documentation
Ethics Audit Report (M8 ethics)Periodic compliance review

Efficiency: you aren't doing new compliance work. You're organizing what you already produce.

Common traps

Trap 1 — An outdated RoPA. The system changes, the RoPA doesn't get updated. In an audit: "describe your actual processing" doesn't match what's documented → a red flag.

Trap 2 — The DPO reports to the dev manager. Not independent. A conflict of interest when dev wants to ship and the DPO has to slow things down.

Trap 3 — A DPIA done once, never updated. Major changes to the system (a new model, a new data source) with no re-DPIA.

Trap 4 — Documentation only legal can understand. Engineers don't know what to say when regulators ask. Documentation must be accessible to everyone.

Trap 5 — No DPIA because "it isn't high risk." But your system automatically decides things about users. It is high risk. Don't skip the DPIA out of inconvenience.

Exercise

For your AI system from the path:

  1. Draft a RoPA following the template
  2. Do you need a DPO? Justify it against the criteria
  3. Draft a basic DPIA (high-level)
  4. Map your path artifacts to GDPR documentation
See the solution (skeleton)

RoPA: use the module's template, filling it in with the specific details of your system (the Knowledge Assistant).

Is a DPO necessary?:

  • 50 tenants, 50K end users: not definitively "large scale"
  • The data: work emails, conversations, feedback → not a sensitive category
  • Monitoring: not systematic surveillance
  • Conclusion: NOT mandatory, but recommended (a designated compliance lead)

A basic DPIA:

  • Description: an AI assistant that automates customer support
  • Necessity: the 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:

  • The M8 architecture system → the RoPA's technical sections
  • The M2 bias toolkit → the risk assessment for fairness
  • The M3 privacy assessment → the privacy sections
  • The M4 risk classification → the high-risk determination
  • The M7 framework checklist → ongoing compliance verification

Summary

You learned:

  • ✅ Records of Processing Activities (Art. 30) — what to include
  • ✅ DPO designation criteria (when it's mandatory)
  • ✅ The DPO's role in AI development (pre, during, post)
  • ✅ The DPIA structure and when it's required
  • ✅ Path artifacts serve as GDPR docs (efficiency)
  • ✅ The traps: outdated docs, a DPO with no independence, one-off DPIAs

Checkpoint: if you can produce a defensible RoPA + DPIA for your system, you're ready.

Next capsule

08 — Project: GDPR Compliance Checklist for AI consolidates M5 into an actionable checklist.

Resources

  1. GDPR Article 30 — Records of processing.
  2. Article 35 — DPIA and Article 37 — DPO.
  3. EDPB DPIA template.
  4. ICO DPO guide.
← PreviousLegitimate Interest vs ConsentNext →Project: GDPR Compliance Checklist for AI