# GDPR and EU AI Act Compliance Reference

Purpose: Assess compliance with the EU General Data Protection Regulation (GDPR) and the EU AI Act. Drive article-level control mapping (Art. 5/6/7/13/14/15-22/25/32/33/34), DPIA triggers, Records of Processing Activities (ROPA), lawful-basis selection, cross-border transfer controls, DSAR fulfillment workflow, and AI Act risk classification (prohibited / high-risk / limited / minimal). Every control references the exact regulation article — never generic "privacy best practice".

## Scope Boundary

- **Comply `gdpr`**: GDPR + EU AI Act regulatory mapping, article-level evidence, DPIA / ROPA / SCC design, DSAR workflow, lawful-basis documentation, AI Act conformity assessment.
- **Cloak (elsewhere)**: hands-on privacy engineering — PII detection scanners, data-flow graphing, consent-SDK implementation, pseudonymization code, DPIA facilitation workshops.
- **Crypt (elsewhere)**: cryptographic key management and KMS integration under Art. 32 (encryption at rest / in transit / envelope encryption / HSM attestation).
- **Warden (elsewhere)**: V.A.I.R.E. pre-release functional quality gate (not a regulatory audit).
- **Vigil (elsewhere)**: detection rule authoring for exfiltration / breach alerts (Art. 33/34 detection coverage, not notification workflow).

If the question is "what article applies and what evidence does the DPA expect?" stay in `gdpr`. If it is "implement the consent banner / encrypt this column / run the DPIA workshop", hand off to Cloak or Crypt.

## Article-to-Control Map

| Article | Control domain | Assessment focus |
|---------|----------------|------------------|
| Art. 5 | Principles (lawfulness, purpose limitation, minimization, accuracy, storage limitation, integrity, accountability) | Trace every personal-data field to at least one principle; flag over-collection |
| Art. 6 | Lawful basis | One of six bases must be selected and documented per processing activity |
| Art. 7 | Conditions for consent | Granular, withdrawable, separate from ToS; no pre-ticked boxes |
| Art. 13 / 14 | Information to data subject | Privacy notice completeness at collection (13) and indirect collection (14) |
| Art. 15-22 | Data subject rights | Access, rectification, erasure, restriction, portability, objection, automated decision-making (Art. 22) |
| Art. 25 | Data protection by design and by default | Pseudonymization, minimization, default privacy settings |
| Art. 28 | Processor obligations | DPA (Data Processing Agreement) signed before processing starts |
| Art. 30 | ROPA | Records maintained by controller and processor |
| Art. 32 | Security of processing | Encryption, pseudonymization, confidentiality/integrity/availability/resilience, regular testing |
| Art. 33 | Breach notification to DPA | 72-hour clock from awareness, documented regardless of risk |
| Art. 34 | Breach notification to data subject | Required when high risk to rights; plain-language communication |
| Art. 35 | DPIA | Mandatory for high-risk processing (see trigger list below) |
| Art. 44-49 | International transfers | SCC 2021 modules, BCR, adequacy decision, Art. 49 derogations |

### EU AI Act Risk Tiers

| Tier | Examples | Comply check |
|------|----------|--------------|
| Prohibited (Art. 5) | Social scoring, real-time public biometric ID, emotion recognition in workplace | Flag as non-shippable — block release |
| High-risk (Annex III) | Employment screening, credit scoring, critical infrastructure, biometric ID | Conformity assessment, FRIA, registration in EU database, post-market monitoring |
| Limited-risk | Chatbots, deepfakes, emotion recognition (non-prohibited contexts) | Transparency obligation (Art. 50) — user must know they interact with AI |
| Minimal-risk | Spam filters, recommenders outside Annex III | Voluntary codes of conduct |

General-purpose AI (GPAI) models have separate transparency + copyright obligations from August 2025; systemic-risk GPAI adds evaluation, incident reporting, and cybersecurity duties.

## DPIA Trigger Checklist

A DPIA is required when any of the following is true. Document the reason the DPIA was or was not performed — "we did not think it applied" is an audit failure.

- Systematic and extensive automated decision-making with legal or similarly significant effects (Art. 22).
- Large-scale processing of special-category data (Art. 9) or criminal convictions (Art. 10).
- Systematic monitoring of publicly accessible areas on a large scale.
- Innovative use of technology (AI scoring, biometric ID, IoT personal data).
- Any processing on the supervisory authority's published DPIA list.
- AI Act high-risk system — FRIA (Fundamental Rights Impact Assessment) is additionally required.

## ROPA Template (Art. 30)

| Field | Content |
|-------|---------|
| Processing activity name | Short descriptor (e.g., "Customer support ticket handling") |
| Controller / joint controllers / DPO | Legal entity + contact |
| Purposes | Precise purpose, not "business operations" |
| Categories of data subjects | Customers, employees, visitors, minors |
| Categories of personal data | Identifiers, contact, financial, special-category |
| Recipients | Internal teams + external processors (subprocessor chain visible) |
| International transfers | Country + transfer mechanism (SCC module, BCR, adequacy) |
| Retention period | Specific duration tied to purpose, not "as long as necessary" |
| Security measures | Art. 32 controls mapped (encryption, access control, pseudonymization) |
| Lawful basis | Art. 6 basis + Art. 9 condition if special-category |

## Cross-Border Transfer Decision Order

1. Adequacy decision in place (e.g., UK, Japan, EU-US DPF for certified US entities)? → transfer lawful, document the decision reference.
2. If no adequacy → SCC 2021 modules (controller-to-processor / processor-to-processor etc.) + Transfer Impact Assessment (TIA).
3. BCR for intra-group transfers (requires DPA approval, typically 12-24 months).
4. Art. 49 derogations — explicit consent / contract necessity — only for occasional, non-repetitive transfers. Never treat as a steady-state basis.

## DSAR Handling Workflow

```
RECEIVE   →  verify requester identity proportionate to request risk
          →  log timestamp — 30-day clock starts (extendable +60 days if complex)
          →  classify: access / rectification / erasure / restriction / portability / objection / Art. 22

LOCATE    →  search all systems holding personal data (ROPA is the map)
          →  include processors and subprocessors (contractual obligation)
          →  flag third-party personal data requiring redaction

FULFILL   →  prepare machine-readable export (JSON / CSV) for portability requests
          →  apply Art. 23 restrictions (legal privilege, ongoing investigations)
          →  document decisions + rationale for partial / refused responses

RESPOND   →  send within 30 days; communicate free of charge unless manifestly unfounded / excessive
          →  if refused: inform of right to complain to DPA and seek judicial remedy
```

## Consent vs Legitimate Interest

| Dimension | Consent (Art. 6(1)(a)) | Legitimate interest (Art. 6(1)(f)) |
|-----------|------------------------|-------------------------------------|
| When to pick | Marketing to prospects, special-category data, AI training on personal data | B2B outreach to existing contacts, fraud prevention, internal analytics |
| Proof burden | Granular, timestamped, withdrawable record per purpose | Documented Legitimate Interest Assessment (LIA) — purpose / necessity / balancing |
| Withdrawal | Equally easy as giving; stop processing on withdrawal | Honor objection (Art. 21) unless compelling legitimate grounds |
| Children | Parental consent up to 13-16 (Member State) | Rarely appropriate — balance test usually fails |
| Never use for | Contractual necessity, legal obligation | Cookies (ePrivacy requires consent), direct marketing to new users |

## Anti-Patterns

- Treating GDPR as "privacy policy updates" — missing ROPA, missing DPIA, missing lawful-basis register.
- Collecting consent once at signup then claiming it covers every future purpose — violates Art. 7(2) granularity.
- Using Art. 49 derogations as an ongoing transfer basis instead of a one-off exception.
- "Legitimate interest" applied to AI training on user data without LIA documentation or opt-out path — the UK ICO and EDPB have both pushed back on this pattern.
- DPIA written after launch — Art. 35(1) requires it **prior to** processing.
- Treating EU AI Act obligations as 2027 work — prohibited-use bans were enforceable from Feb 2025, GPAI transparency obligations from Aug 2025, and high-risk obligations phase in through Aug 2026.
- Confusing DPA (controller-processor contract, Art. 28) with DPIA (impact assessment, Art. 35) — they are different instruments.
- Running DSAR search only against the primary database and missing logs, backups, analytics warehouses, and subprocessor systems.

## Handoff

**To Cloak** — implementation of privacy-by-design patterns: consent SDK integration, PII scanner wiring, pseudonymization of identified fields, DPIA facilitation.

**To Crypt** — Art. 32 cryptographic controls: key hierarchy, KMS choice (AWS KMS / GCP KMS / Azure Key Vault / HSM), envelope encryption for special-category data, TLS 1.2+ with forward secrecy.

**To Builder** — DSAR fulfillment endpoints, consent-withdrawal hooks, data-export job, retention-based deletion jobs.

**To Scribe** — ROPA document, DPIA report, privacy notice revision, DPA template for new processors.

**To Beacon** — breach-detection alert thresholds feeding the Art. 33 72-hour clock; DSAR SLA dashboard.