DPIA for AI systems: Data Protection Impact Assessment under revDSG Art. 22 and GDPR Art. 35

What is a DPIA?

The Data Protection Impact Assessment (DPIA, German Datenschutz-Folgenabschätzung / DSFA) is a documented prior review of a planned data processing for its risks to personality and fundamental rights of data subjects. In Switzerland regulated in Art. 22 of the revised Federal Act on Data Protection (revDSG, in force since 1 September 2023). In the EU regulated in Art. 35 of the GDPR (Regulation 2016/679). The two texts are close but not identical – whoever must satisfy both regimes typically runs a combined DPIA with the GDPR as the baseline.

The DPIA is not a formal act but an iterative process. It starts at the concept stage (before procurement), is completed before go-live, and is updated on material changes. A complete DPIA covers four blocks: description of the processing, assessment of necessity and proportionality, risk analysis with damage scenarios, mitigation measures. Residual risk must be named explicitly, and submitted to the supervisor (FDPIC in CH, national authority in EU) for prior consultation if it remains high despite measures.

The EDPB published a harmonised DPIA template on 19 November 2025, in consultation until 9 June 2026, now serving as the de-facto standard for EU authorities. The CNIL PIA tool (free open-source software from the French supervisor) remains the most-used implementation in Europe and is compatible with the EDPB template. In Switzerland the FDPIC publishes a DPIA guidance without a binding template – practice uses the CNIL tool and translates the results.

Why it matters

AI systems typically hit several DPIA triggers at once – the DPIA is then not nice to have but a legal duty. A violation is not a mere formal defect: it triggers fines (up to CHF 250,000 in CH under Art. 60 revDSG, up to EUR 10 million or 2 % of group turnover in EU under Art. 83(4) GDPR) and – more seriously – supervisor-ordered cessation of processing.

Trigger 1: systematic comprehensive evaluation. Profiling in the GDPR sense is automated processing of personal data to evaluate personal aspects (performance, economic situation, health, preferences, interests, reliability, behaviour, location, movements). AI systems do this practically always.

Trigger 2: large-scale special categories. Art. 9 GDPR / Art. 5 lit. c revDSG: health, religion, ethnicity, sexual orientation, biometric data, genetic data, trade-union membership. Also criminal data under Art. 10 GDPR. Law firms, doctors, insurers are regularly affected.

Trigger 3: systematic monitoring of publicly accessible areas. Video surveillance, biometric identification in public spaces.

Trigger 4: new technologies. LLM, generative AI, biometric verification, autonomous decisions – all currently count as "new technology" in the supervisors' DPIA trigger lists.

Trigger 5: solely automated individual decisions with legal effect. Art. 22 GDPR / Art. 21 revDSG. Examples: AI credit scoring, AI recruiting filter, AI insurance pricing, AI tenant screening.

If a trigger applies, the DPIA is mandatory. If none apply, it is voluntary – but for any sizeable AI project practically always recommended, because it makes the risk architecture visible and eases later defence in a supervisor proceeding.

DPIA methodology in four blocks

Block 1 – Description of the processing. Data types, data categories (regular / special), sources (client, public, purchased), recipients (internal, external, third countries), processing phases (collection, storage, model training, inference, logging, deletion), retention per phase, technical architecture (model, hosting region, gateway, vector DB, logging system), processors involved with their sub-processors. Diagram required: data-flow diagram with arrows from source to sink.

Block 2 – Necessity and proportionality. Check against the principles of Art. 5 GDPR / Art. 6 revDSG: lawfulness (Art. 6 ground), purpose limitation (clear, explicit, legitimate purpose), data minimisation (no field too many), accuracy (correction mechanisms), storage limitation (clear retention), integrity and confidentiality (encryption, access restriction). For legitimate interest additionally the three-step test.

Block 3 – Risk analysis. Three protection goals are weighed against threats: confidentiality (unauthorised access), integrity (unauthorised modification), availability (outage, loss). Risk rating in two dimensions: likelihood (negligible / limited / significant / maximum) and severity (negligible / limited / significant / maximum). The CNIL PIA software computes a 4×4 matrix; red cells require measures.

Typical AI-specific risks: training-data leak via membership-inference attacks; prompt injection with data exfiltration; hallucination with false statements about subjects; discrimination bias in automated decisions; LLM-provider sub-processor chain transferring data to a non-permitted third country; logging with system-prompt leakage; re-identification from supposedly anonymised training data.

Block 4 – Measures and residual risk. Technical and organisational measures (TOM) per risk: encryption at rest and in transit, access control with audit log, pseudonymisation before LLM transmission, output filter against PII leak, human-in-the-loop on critical decisions, low default retention, sub-processor whitelist, regular penetration tests. Name residual risk explicitly; if it remains high: prior consultation with FDPIC / national supervisor under Art. 23 revDSG / Art. 36 GDPR.

EU AI Act overlay. For high-risk AI systems under Annex III, Art. 27 AI Act additionally requires a Fundamental Rights Impact Assessment (FRIA) – applicable from 2 August 2026 for public-sector deployers or for high-risk AI in creditworthiness and life/health insurance. DPIA and FRIA may be consolidated – Art. 26(9) AI Act explicitly allows it.

DPIA for AI in 7 steps

1. 01Trigger check: review the 9 WP248 criteria. Two or more hits = DPIA required. Document the "not required" outcome with reasoning too.
2. 02Description of processing: data-flow diagram, data types, phases, recipients, retention, technical architecture – complete for all AI-pipeline stations (ingestion, embedding, retrieval, inference, logging).
3. 03Necessity + proportionality: check against Art. 5 GDPR / Art. 6 revDSG. For legitimate interest document the three-step test.
4. 04Risk analysis: CNIL PIA tool or EDPB template. Per risk: likelihood × severity. Do not omit AI-specific risks (hallucination, prompt injection, bias).
5. 05Measures: TOM per risk. Encryption, access control, pseudonymisation, output filter, human-in-the-loop, audit log, sub-processor whitelist.
6. 06Residual-risk assessment: if it remains high despite measures – prior consultation with FDPIC (CH) or national supervisor (EU) under Art. 23 revDSG / Art. 36 GDPR.
7. 07Documentation + review cycle: link the DPIA in the record of processing activities, update on every material change, review at least annually.

When the DPIA is mandatory

The DPIA duty arises as soon as "likely high risk" is present (revDSG Art. 22(2), GDPR Art. 35(1)). Supervisors have published trigger lists. Rule of thumb: two or more of the following criteria together = DPIA mandatory.

Criteria list (WP29 Guidelines WP248, adopted by the EDPB): evaluation or scoring; automated decisions with legal effect; systematic monitoring; special categories or criminal data; large data volume; combined datasets; data on vulnerable subjects (employees, children); new technology; prevents data subjects from exercising their rights.

Concrete Swiss examples where the DPIA is mandatory: a law firm uses an LLM for client triage (special categories + new technology + large data volume) – DPIA required. A fiduciary runs AI-assisted AML screening (scoring + automated decisions + data on beneficial owners) – DPIA required. An insurer uses an AI model for premium calculation (automated decision with legal effect + profiling + possibly health data) – DPIA required plus FRIA under Art. 27 AI Act from 2 August 2026. HR uses an LLM to pre-screen applications (scoring + automated decisions + new technology) – DPIA required.

Timing: before processing starts. For ongoing systems that went live before 1 September 2023 and had no material change, a grandfathering rule applies – but any non-trivial change triggers a retroactive DPIA. An LLM upgrade or provider switch is a material change.

When the DPIA is not required – and its limits

The DPIA is not required when (a) there is no high risk (trigger list empty), (b) a pre-existing DPIA exists for a comparable processing operation and is transferable to the new case (Art. 35(1) sentence 2 GDPR), (c) the processing is based on a legal provision that itself contained an equivalent impact assessment.

For LLM setups (b) is the relevant exemption path: whoever did a DPIA for a first AI use case may run a simplified update for the next comparable use case instead of a fresh DPIA – provided data categories, recipients, providers and legal bases are unchanged.

Limits of the DPIA. The DPIA assesses data protection risks, not all AI risks. It does not cover: AI-security assessment under the NIS-2 Directive, IT security under ISO 27001 / 42001, business continuity, comprehensive anti-bias review, explainability of model decisions, EU AI Act compliance. Full AI governance needs DPIA + FRIA + AI risk assessment + security assessment.

This is not legal advice. For binding assessment of the DPIA duty for your specific AI project, please consult a Swiss attorney specialised in data protection or an external data protection advisor. *Dies ist keine Rechtsberatung. Für verbindliche Auslegung CH-Anwalt / Datenschutzberater.*

Trade-offs

FAQ

Related topics

Sources

1. EDPB – Harmonised DPIA Template (adopted 19 Nov 2025) · 2025-11
2. CNIL – PIA Software (Open Source DPIA Tool) · 2026-04
3. EU AI Act – Article 27 Fundamental Rights Impact Assessment (FRIA) · 2026-05
4. WP29 Guidelines WP248 on DPIA (endorsed by EDPB) · 2017-10
5. EDÖB – Leitfaden zur Datenschutz-Folgenabschätzung · 2026-02