DPIA for AI Systems (2026): Template, Walkthrough, and AI Act FRIA Pairing

A complete Data Protection Impact Assessment template for AI systems — including the new Fundamental Rights Impact Assessment fields the AI Act requires for high-risk use cases.

Your auditors will ask for both. Most DPIA templates were written before the EU AI Act existed. They cover GDPR Article 35 adequately but leave a gap that has become operational in 2026: high-risk AI systems now require a Fundamental Rights Impact Assessment (FRIA) alongside the DPIA, and the two documents must speak to each other. This guide gives you a single walkthrough that pairs both artifacts, along with the 9 mandatory GDPR sections, the 4 new AI-specific additions, and practical examples for ML, LLM, and agentic systems.

For the broader governance context — risk classification, prohibited practices, and the 90-item framework — see the complete AI compliance checklist.

When a DPIA is Mandatory for AI under GDPR and the AI Act {#when-required}

Under GDPR Article 35, a DPIA is required when processing is "likely to result in a high risk to the rights and freedoms of natural persons." For AI systems, the EDPB's guidelines identify three processing types that always trigger this threshold:

Systematic and extensive profiling — scoring, predicting, or inferring attributes (creditworthiness, health, behavior) that produces decisions with legal or similarly significant effects.
Large-scale processing of special category data — health, biometric, political opinion, ethnicity, or religion data used in training or inference.
Systematic monitoring of publicly accessible areas — includes CCTV analytics, location tracking, and behavioral observation at scale.

Beyond these three, any combination of two or more of the EDPB's additional criteria (innovative technology, matching or combining datasets, processing of vulnerable subjects, automated decision-making) creates a strong presumption of DPIA obligation. In practice, most ML and LLM deployments in enterprise settings will cross one of these thresholds.

The AI Act adds a second trigger layer. Deployers of high-risk AI systems listed in Annex III must conduct a FRIA under Article 27 before deployment. The obligation is separate from GDPR — it runs even if the system processes no personal data — but in real-world deployments the two assessments are almost always co-triggered. Running them in parallel, with shared system description and risk register, reduces duplication significantly.

The practical rule: if the system is on your high-risk AI inventory, run DPIA and FRIA together. If it isn't high-risk under the AI Act but meets any GDPR Article 35 trigger, run the DPIA alone. Never substitute one for the other.

The 9 Mandatory DPIA Sections — and the 4 New AI-Specific Ones {#structure}

GDPR Article 35 specifies minimum content for a DPIA. The EDPB's WP248 guidelines expand this into a structured format. For AI systems, four additional sections address gaps that pre-AI templates leave open.

System Description and Purpose {#system-description}

The description must go beyond what a traditional IT system description covers. Required elements for AI:

Model type and architecture — not the full technical specification, but enough to distinguish between a rule-based system, a supervised ML model, an LLM, and an agentic system with autonomous tool-use. Auditors use this to assess the degree of unpredictability.
Training data sources — origin, collection date, pre-processing steps, and whether personal data was used in training. If the model is a third-party foundation model fine-tuned internally, both the base model provenance and the fine-tuning dataset must be described.
Intended purpose and deployment context — the system's declared function, who operates it, who is subject to its outputs, and the organizational process it supports or replaces.
Scope boundaries — explicit statement of what the system does not do, to prevent scope creep invalidating the assessment later.

Data Flow and Lawful Basis {#data-flow}

For AI systems, data flows during inference often differ substantially from data flows during training. Both must be mapped:

Training data flow — where data originated, how it was transferred into the training environment, what retention applies, and whether it has been deleted post-training.
Inference data flow — what inputs the system receives at runtime, what outputs it produces, where outputs are stored or transmitted, and whether outputs are used to retrain the model (feedback loops require separate assessment).
Lawful basis per processing operation — a single AI system may process data on multiple legal bases for different purposes. Each must be stated explicitly. Consent-based systems require documentation of withdrawal mechanisms.
Third-party processors — API-hosted models, vector databases, embedding services, and logging infrastructure are all processors under Article 28. DPAs must be in place before processing begins.

Necessity and Proportionality {#necessity}

This section is where most AI DPIAs fail EDPB scrutiny. The assessment must demonstrate that the AI approach is necessary relative to the purpose — not merely convenient — and that the data used is the minimum required.

For ML systems, this requires explicit justification of: why a predictive model is necessary rather than a deterministic rule; why the training dataset size and feature set are required; and why less privacy-invasive alternatives (aggregated data, synthetic data, reduced feature dimensionality) were considered and rejected.

For LLMs processing personal data in prompts, the necessity analysis must address whether real personal data is required or whether anonymized or synthetic test data would serve the purpose during development.

Risks to Rights and Freedoms {#risks}

The risk register must address four dimensions that are specific to AI:

Discrimination and bias — systematic underperformance on protected characteristic groups, documented with bias metrics where available.
Opacity and explainability — the degree to which subjects and oversight personnel can understand why the system produced a given output.
Behavioral influence — for systems that influence decisions, content, or user behavior at scale, the risk of manipulation or nudging must be assessed.
Autonomy and human oversight — for agentic systems with tool-use capability, the risk of consequential actions without adequate human review.

The AI Act FRIA — What's New and How It Pairs with the DPIA {#fria}

The Fundamental Rights Impact Assessment is not a GDPR instrument — it is an AI Act instrument, established under Article 27 for deployers of high-risk AI systems. Its purpose is distinct: while the DPIA asks "what risks does this processing create for data subjects," the FRIA asks "what risks does this AI system create for fundamental rights more broadly" — including rights that are not primarily about data (freedom of expression, access to justice, non-discrimination in employment and services).

When FRIA is Required (Article 27 Trigger Conditions) {#fria-trigger}

FRIA is mandatory for deployers, not providers. If your organization uses a high-risk AI system developed by a third party, you bear the FRIA obligation — the provider's technical documentation does not discharge it.

Trigger conditions:

The system is classified as high-risk under Annex III of the EU AI Act (biometric identification, critical infrastructure, education and vocational training, employment and workforce management, access to essential private services and public services, law enforcement, migration and asylum, administration of justice).
The deployer is a body governed by public law, or a private organization providing services of public interest (utilities, financial services, healthcare, employment services).
Deployment occurred or will occur after the Article 27 application date (2 August 2026 for most deployers).

For a detailed classification guide, see AI Act high-risk systems.

Risk Classification and Human-Oversight Evidencing {#fria-oversight}

The FRIA requires a structured assessment of impact across eight fundamental rights categories: human dignity; freedom and security; non-discrimination; data protection and privacy; consumer protection; workers' rights; rule of law; and access to justice.

For each category, the assessment must:

Identify which rights could be affected by the AI system's outputs or errors.
Assess the likelihood and severity of adverse impact, cross-referencing the risk management system from Article 9.
Document the mitigation measures in place — technical controls, procedural controls, and human oversight mechanisms.
Confirm that human oversight personnel are identified, trained, and have operational authority to intervene, override, or halt the system.

The human-oversight evidencing section is where the human-in-the-loop AI policy template becomes operationally relevant: the FRIA must name the oversight mechanism, not merely assert it exists.

DPIA–FRIA pairing in practice: Both documents share the system description and data flow sections verbatim. The risk register from the DPIA should be cross-referenced in the FRIA — risks that involve personal data appear in both; rights impacts that do not involve personal data appear only in the FRIA. Maintaining one system description section and two risk registers (one per framework) is the most efficient structure for a combined artifact.

Generate your DPIA and AI policy scaffolding in minutes. The AI policy template generator produces a pre-filled DPIA structure with AI-specific sections and FRIA cross-references — free to use, no account required.

DPIA Template Walkthrough — Section by Section {#walkthrough}

The following walkthrough covers the 9 mandatory GDPR sections plus the 4 AI-specific additions (marked [AI]). Each step maps to a HowToStep in the schema; the full template is generated by the tool above.

Step 1 — Controller and system identity. Organization name, DPO contact, AI system name and version, assessment date, and prior DPIA reference if this is an update.

Step 2 — System description and purpose [described in detail above].

Step 3 — Consultation of the DPO. Document when the DPO was consulted, their advice, and whether it was followed. GDPR Article 35(2) makes DPO consultation mandatory for the DPIA process, not optional.

Step 4 — Data flow and lawful basis [described in detail above].

Step 5 — Necessity and proportionality [described in detail above].

Step 6 — Risks to rights and freedoms [described in detail above].

Step 7 [AI] — Model performance and accuracy documentation. Declare the accuracy metrics used, the evaluation dataset, the performance thresholds that constitute acceptable operation, and what happens when the system operates below threshold. This section does not exist in standard DPIA templates — it is required for AI systems because output quality directly affects the severity of rights impacts.

Step 8 [AI] — Automated decision-making and Article 22 compliance. If the system produces outputs that constitute "solely automated decisions" with legal or significant effect, document: the safeguard mechanisms (right to human review, right to object, right to explanation); how subjects are informed; and how requests are operationally handled.

Step 9 [AI] — Bias and non-discrimination assessment. Bias metrics by protected characteristic group, methodology, dataset used for bias evaluation, findings, and remediation steps taken. If bias evaluation has not been completed, document the plan and timeline.

Step 10 [AI] — Human oversight and intervention capability. Technical and procedural evidence that a designated person can monitor the system in real time, intervene, override, or halt it. Name the oversight role. Document the escalation path.

Step 11 — Measures to address risks. For each risk identified in Step 6: the measure taken, residual risk after the measure, and the decision on whether residual risk is acceptable. If any residual risk is assessed as high, DPA prior consultation (Article 36) is triggered.

Step 12 — DPA prior consultation trigger. If the DPIA concludes that residual risk is high and cannot be mitigated by the controller, GDPR Article 36 requires consultation with the supervisory authority before processing begins. Document the determination and, if triggered, the consultation record.

Step 13 — Sign-off and review schedule. DPO sign-off, controller sign-off, approval date, next scheduled review date, and the events that would trigger an unscheduled review (significant system modification, new use case, change in data categories).

Practical Examples for ML, LLM, and Agentic Systems {#examples}

Supervised ML model (credit scoring): High-risk Annex III (access to financial services) + GDPR Article 35 (profiling with significant effect) — both DPIA and FRIA required. Bias section must include demographic parity and equal opportunity metrics across protected groups. Article 22 safeguard must specify the human review process for declined applications.

LLM with retrieval-augmented generation (internal knowledge base): GDPR Article 35 trigger depends on whether personal data is in the retrieval corpus. If yes, DPIA required. Necessity analysis must justify why real employee data in the retrieval index is required rather than anonymized data. Logging requirements (who queried what, what was retrieved) must be documented.

Agentic system with tool-use (automated sales outreach): Human oversight section must document turn limits, action approval gates, and what tools the agent is permitted to call autonomously. The FRIA applies if the agent produces outputs affecting recipients in an Annex III domain. Even where it does not, the DPIA must address the behavioral influence risk at scale.

Common Pitfalls Flagged by EDPB {#pitfalls}

The EDPB's published DPIA opinions consistently flag these shortcomings in AI assessments:

Purpose limitation failures — stating a broad purpose to preserve optionality, then using the system for purposes not covered by the lawful basis.
Superficial bias assessment — asserting that bias testing was conducted without documenting methodology, dataset, or findings. "We tested for bias and found none" without evidence is not compliant.
Missing third-party processor documentation — treating a hosted API model as infrastructure rather than a processor. If the API provider can access the data (even transiently), an Article 28 DPA is required.
Generic human oversight statements — writing "human oversight is maintained" without identifying the oversight role, the technical capability to intervene, and the escalation path.
No review schedule — a DPIA is not a one-time artifact. The absence of a review schedule is treated as a gap in the risk management system.

Stakeholder Review and DPA Consultation Thresholds {#stakeholder-review}

The DPIA must be reviewed internally before deployment and, in specific cases, by the supervisory authority before deployment.

Internal review participants and sequence:

DPO — mandatory under Article 35(2). Must be consulted on the DPIA and their advice documented.
Legal/privacy counsel — reviews lawful basis, Article 22 compliance, and DPA coverage.
AI system owner / technical lead — validates system description accuracy and confirms oversight mechanisms are operational.
Security — reviews technical controls in the risk register.
Senior management sign-off — documented authorization before deployment.

DPA prior consultation (Article 36) is triggered when the DPIA concludes that residual risk remains high after all feasible mitigation. The threshold is not "any high risk identified" but "high residual risk that cannot be mitigated by the controller alone." Supervisory authorities have 8 weeks (extendable to 14) to respond; do not deploy during this period.

The Article 36 consultation package must include: the DPIA, the proposed processing description, the mitigation measures considered, the DPO's advice, and a contact point for the authority. Some national DPAs (ICO, CNIL, Datatilsynet) have published specific guidance on what additional documentation they expect for AI systems — check the relevant authority's website before filing.

How to Keep the DPIA Living, Not a One-Time Artifact {#lifecycle}

A DPIA filed pre-deployment and never revisited is a compliance liability, not an asset. EDPB guidance is explicit: the DPIA must be kept under review throughout the system lifecycle.

Events that require DPIA update:

Significant modification to the AI system — new model version, expanded training data, new features, or change in the processing purpose.
New use case that was not in scope of the original assessment.
Change in data categories processed — particularly if special category data is added.
Incident involving the system — bias incident, adversarial manipulation, unexpected output, or personal data breach.
Change in the legal or regulatory environment — new EDPB guidance, supervisory authority decision affecting the processing type, or AI Act Annex III amendment.
Periodic review — minimum annually for systems in active production; more frequently for high-risk systems.

For organizations running multiple AI systems, the review cadence becomes a governance process in its own right — one that requires tooling, not manual tracking. The ISO 42001 checklist for AI management covers the management system requirements for maintaining this at scale. For automation-heavy environments, AI compliance automation in fintech documents the workflow patterns that make continuous DPIA maintenance tractable.

The second Knowlee architectural principle relevant here: every significant system modification that triggers a DPIA update should also trigger a review of the complete AI compliance checklist for the affected system — the DPIA is one artifact in a broader compliance posture, not a standalone gate.

Frequently Asked Questions {#faq}

Is a DPIA always required for AI systems, or only high-risk ones?

A DPIA is required under GDPR Article 35 whenever processing is "likely to result in a high risk to the rights and freedoms of natural persons" — not as a function of AI Act risk classification, but as a function of the data processing characteristics. An AI system that does not process personal data has no GDPR DPIA obligation regardless of its AI Act risk tier. Conversely, an AI system that processes personal data for profiling, behavioral scoring, or automated decisions affecting individuals will trigger the DPIA obligation even if it is not classified as high-risk under the AI Act. The two frameworks use "high risk" to mean different things. Apply both tests independently.

What's the difference between a DPIA and a FRIA under the EU AI Act?

A DPIA (Data Protection Impact Assessment) is a GDPR instrument focused on risks to data subjects arising from personal data processing. A FRIA (Fundamental Rights Impact Assessment) is an AI Act instrument focused on risks to fundamental rights broadly — including rights that do not involve personal data. The FRIA applies to deployers of high-risk AI systems under Annex III; the DPIA applies to any controller processing personal data where Article 35 thresholds are met. When both apply to the same system, the most efficient approach is a combined document with shared system description and data flow sections and separate risk registers for each framework. Running them independently creates duplication and risks inconsistency between the two artifacts — which auditors will flag.

Can we reuse a GDPR DPIA template for AI, or does it need a new structure?

Existing GDPR DPIA templates cover the 9 mandatory sections adequately but leave four AI-specific gaps: model performance and accuracy documentation; automated decision-making and Article 22 compliance; bias and non-discrimination assessment; and human oversight evidencing. These are not optional additions — EDPB guidance and supervisory authority published opinions confirm they are expected for AI system assessments. If you are adapting an existing template, add these four sections. Do not assume compliance with a pre-AI-Act template, particularly if it was written before the EDPB's 2023 guidance on AI and the GDPR was published.

Who signs off on the DPIA — the DPO, the AI lead, or both?

GDPR Article 35(2) requires that the controller seek the advice of the DPO when carrying out a DPIA. The DPO's advice must be documented, and if it is not followed, the reasons must be recorded. However, the DPO does not make the final authorization decision — the controller (typically the organization's senior management or the AI system owner in their capacity as controller) signs off on the DPIA and the decision to proceed. In practice, the recommended sign-off chain is: DPO advice documented → legal review → technical lead confirmation → controller/senior management authorization. For high-risk AI systems, adding a second-line risk review before final sign-off is consistent with Article 9 risk management system requirements.

How often should the DPIA be re-run for an AI system in production?

There is no prescribed frequency in GDPR Article 35 beyond "where necessary, carry out a review." EDPB guidance interprets this as requiring review when there is a change in the risk represented by the processing operations — which, for AI systems in active development, occurs more frequently than for static processing systems. A minimum annual review is the floor for systems in production. Systems with active model updates, expanding use cases, or high-volume personal data processing should be reviewed more frequently — quarterly reviews are appropriate for high-risk deployments. Review triggers also include: incidents involving the system, regulatory updates, significant performance degradation, and any change in the categories of data subjects affected.

What Good Compliance Looks Like in Practice

The organizations that handle DPIA and FRIA obligations efficiently share one characteristic: they treat these assessments as structured outputs of their existing AI governance process, not as separate documentation projects. The system description is written once and referenced by both documents. The risk register is maintained in the governance system, not in a Word file. The review schedule is a recurring governance calendar item, not a manual reminder.

When the assessment is integrated into the AI deployment process — triggered automatically by the same gate that triggers risk classification — the marginal cost of keeping DPIAs current drops substantially. Organizations that run compliance as a parallel track to AI development, rather than a pre-deployment checkpoint, find the assessment is already half-complete by the time the system reaches deployment review.

Book a 20-minute compliance review to validate your DPIA structure, confirm FRIA applicability, and identify any gaps before your next audit or DPA inquiry.