If you are deploying an AI agent in a regulated workflow — financial-crime triage, payments screening, loan onboarding, claims adjudication — you almost certainly owe a Data Protection Impact Assessment under GDPR Article 35. And if that same system is high-risk under the EU AI Act, you also owe a Fundamental Rights Impact Assessment under Article 27. The two assessments overlap heavily, the regulation expects you to reuse the overlap, and yet most teams run them as two disconnected paperwork exercises that drift apart the moment the model changes. This guide does the opposite: it gives you a DPIA structure that maps cleanly onto your FRIA — and onto your legitimate-interests assessment — so you produce one combined evidence pack instead of three documents that contradict each other in audit. You can generate that combined pack with the DPIA + FRIA generator. The KLA thesis throughout: an impact assessment is only worth the paper it is on if the controls it promises actually run at the moment the agent acts — govern by execution, not by PDF.
When is a DPIA mandatory for an AI system?
A DPIA is not optional bureaucracy. Article 35(1) makes it a legal obligation before processing begins whenever the processing — "in particular using new technologies" — is likely to result in a high risk to the rights and freedoms of natural persons. AI agents that act on personal data in a regulated workflow are close to the paradigm case the drafters had in mind.
Article 35(3) lists three statutory triggers, any one of which makes a DPIA mandatory. The Article 29 Working Party guidance (WP248) — endorsed by the EDPB — adds nine criteria and a rule of thumb: if your processing meets two or more of them, treat a DPIA as required. National supervisory authorities also publish their own "blacklists" of processing that always needs one. The table below maps the criteria that AI agents in financial services and insurance trip most often.
The practical takeaway for a regulated AI deployer: do not spend a week debating whether you are technically obliged. If your agent profiles people, scores them, or feeds a decision that affects access to credit, payments, or an insurance payout, you are almost certainly in scope — document the screening and move on to the substance.
| Trigger | Source | Typical AI-agent scenario that hits it |
|---|---|---|
| Systematic and extensive evaluation or profiling, based on automated processing, on which decisions are based | Art. 35(3)(a) | Transaction-monitoring agent that scores customers for financial-crime risk; behavioural fraud scoring |
| Decisions producing legal or similarly significant effects on the person | Art. 35(3)(a) / Art. 22 | Automated loan-onboarding decisioning; automated claims acceptance or denial |
| Large-scale processing of special-category or criminal-offence data | Art. 35(3)(b) | AML screening against sanctions/adverse-media that infers ethnicity, political exposure, or criminal history |
| Systematic monitoring of a publicly accessible area on a large scale | Art. 35(3)(c) | Less common for back-office agents; relevant to identity/biometric onboarding |
| Matching or combining datasets | WP248 | Enriching an applicant record by joining KYC, device, and third-party bureau data |
| Data concerning vulnerable data subjects | WP248 | Retail credit or insurance pricing affecting consumers with limited bargaining power |
| Innovative use of new technological solutions | WP248 | Deploying an LLM-based or agentic decision system — a near-automatic flag |
What a DPIA must actually contain: Article 35(7)
Article 35(7) is short and prescriptive. A compliant DPIA contains at least four elements, and a regulator will look for each one explicitly — not buried in narrative.
Two procedural duties sit alongside the content. Under Article 35(2) the controller must seek the advice of the Data Protection Officer, and under Article 35(9) must, where appropriate, seek the views of data subjects or their representatives. For an agentic system, the DPO sign-off and the record of who was consulted are part of the evidence — not an afterthought. And under Article 36, if residual risk remains high after mitigation, you must consult the supervisory authority before going live.
The four mandatory content elements are:
- (a) A systematic description of the envisaged processing operations and the purposes of the processing, including, where applicable, the legitimate interest pursued by the controller.
- (b) An assessment of the necessity and proportionality of the processing operations in relation to the purposes — the part most DPIAs skip, and the part most likely to fail in audit.
- (c) An assessment of the risks to the rights and freedoms of data subjects.
- (d) The measures envisaged to address the risks, including safeguards, security measures, and mechanisms to ensure the protection of personal data and demonstrate compliance.
The overlap: where the DPIA and the FRIA are the same document
The EU AI Act does not ask you to start from scratch. Article 27(4) is explicit: where the obligations of the FRIA are already met through a DPIA conducted under Article 35 GDPR, the FRIA "shall complement" that data protection impact assessment. In other words, the legislator expects reuse — and penalises duplication that drifts.
The two assessments are not identical. A DPIA is a controller duty about personal data; a FRIA is a deployer duty about all fundamental rights in the EU Charter — including rights that have nothing to do with data protection, like non-discrimination, human dignity, and access to an effective remedy. The FRIA is broader, and it must be evaluated right by right (you cannot offset a discrimination harm with an efficiency gain). But the structural backbone — describe the system, justify it, identify the risks, state the mitigations — is shared almost element for element.
The table below maps each Article 35(7) DPIA element to its Article 27(1) FRIA counterpart. Where a cell says FRIA only, that is content the DPIA does not capture and you must add. Treat the shared rows as write-once: author them in the combined pack and reference them from both assessments rather than copying.
| DPIA element — GDPR Art. 35(7) | FRIA element — AI Act Art. 27(1) | Reuse status |
|---|---|---|
| (a) Systematic description of processing and purposes | (a) Description of the deployer's processes in which the high-risk system will be used; (b) period and frequency of intended use | Shared — one system/process description serves both |
| Categories of data subjects and personal data (within the (a) description) | (c) Categories of natural persons and groups likely to be affected | Shared — extend the data-subject list to affected groups for FRIA |
| (b) Necessity and proportionality assessment | Implicit in Art. 27 context-of-use; reinforced by Charter proportionality | Shared — necessity/proportionality reasoning carries across |
| (c) Risks to rights and freedoms of data subjects | (d) Specific risks of harm likely to impact affected persons and groups | Shared but broaden — FRIA covers all Charter rights, not just data protection |
| (d) Measures, safeguards and security to address the risks | (f) Governance measures, including human oversight, and (g) complaint/redress arrangements | Shared but broaden — FRIA requires human-oversight and redress measures explicitly |
| DPO advice (Art. 35(2)); views of data subjects (Art. 35(9)) | (e) Human oversight measures per the instructions for use | Partially shared — keep the consultation record once, satisfy both |
| — (not required by GDPR) | Notification of the FRIA to the market surveillance authority (Art. 27(3)) | FRIA only — add this step; no DPIA equivalent |
Folding in the legitimate-interests assessment (LIA)
If your lawful basis for the processing is legitimate interests under Article 6(1)(f) — common for fraud detection and AML, which the GDPR recitals expressly recognise as legitimate interests — you also owe a Legitimate Interests Assessment. The good news: the LIA is not a third silo. Its three-part test slots directly into the DPIA you are already writing.
The LIA's purpose test (is there a legitimate interest?) and necessity test (is the processing necessary for it?) are the same analysis Article 35(7)(b) demands. The LIA's balancing test — does the interest override the data subject's rights, given their reasonable expectations? — is a sharper version of the Article 35(7)(c) risk assessment. Author the legitimate interest once in your DPIA's systematic description (Article 35(7)(a) explicitly invites it: "including, where applicable, the legitimate interest pursued"), and reference it from the LIA generator output.
One caution specific to AI agents: an LLM-driven agent can quietly expand the purpose of processing as you add tools and context. A legitimate interest assessed for "screening transactions against sanctions lists" does not automatically cover "profiling the customer's lifestyle from transaction narratives." The balancing test has to be re-run when the agent's effective purpose changes — which is exactly why the assessment cannot live only in a static document.
One combined evidence pack — and why it has to be live
Running the DPIA, FRIA, and LIA as three separate Word files is how teams end up defending contradictions in an audit: the DPIA promises human review, the FRIA describes a different oversight model, and the LIA balances against a purpose neither of the others mentions. The fix is a single combined evidence pack with shared, write-once sections and three assessment-specific overlays. Build it with the DPIA + FRIA generator, which produces the Article 35(7) and Article 27(1) elements as one mapped document.
But the harder problem is not authoring — it is drift. An impact assessment describes the system as it was on the day you wrote it. The moment someone adds a tool to the agent, swaps the model, or widens its data access, the assessment is stale, and a stale DPIA is a non-compliant one. This is the core KLA position: govern by execution, not paperwork. The mitigations your DPIA promises — human review of high-impact decisions, blocks on out-of-scope data, escalation when confidence is low — should not be sentences in a PDF; they should be controls that run when the agent acts.
In the KLA control plane that mapping is concrete. The measures you commit to in Article 35(7)(d) and FRIA Article 27(1)(f) become Policy Builder gates with explicit decisions — allow, warn, require_approval, or block. The human-oversight and redress arrangements (FRIA Art. 27(1)(e)–(g)) become a Decision Desk two-person, maker-checker approval on the decisions that carry legal or significant effect. And every gated action — what the agent did, which policy fired, who approved — lands in the Evidence Room as a sealed, tamper-evident execution record. That is the difference between an assessment that claims a safeguard and an evidence pack that can prove the safeguard ran on a specific transaction at a specific time.
The Article 27(5) template gap — and how to act now
Article 27(5) instructs the AI Office to develop a template questionnaire — including an automated tool — to help deployers carry out the FRIA in a simplified manner. As of June 2026, that template has not been published. Deployers asking "should we wait for the official format?" are asking the wrong question: the obligation does not wait for the template, and the underlying content elements in Article 27(1) are already fixed in the Regulation.
There is a second timing wrinkle. The EU's Digital Omnibus package, provisionally agreed in May 2026, would defer several high-risk obligations — but it is not yet law and the original dates remain binding until it is published in the Official Journal. Treat any deferral as a planning convenience, not a reason to stop preparing. (See the FRIA template guide for the current deadline picture.)
The pragmatic path, then, is to build on the structure that is stable today: the GDPR Article 35(7) skeleton, mapped to the Article 27(1) elements as in the table above. When the AI Office template lands, you re-export into its format — but your substance, your risk analysis, and your evidence are already done and already running.
Häufig gestellte Fragen
Is a DPIA always required for an AI system?
Not literally always, but very often. A DPIA is mandatory under GDPR Article 35(1) whenever processing is likely to result in a high risk to people's rights and freedoms, especially using new technologies. Article 35(3) lists three automatic triggers — systematic profiling that feeds decisions, large-scale special-category data, and large-scale public monitoring — and WP248 guidance treats two-or-more of its nine criteria as a threshold. Most regulated AI agents that profile, score, or drive a consequential decision hit at least one trigger, so the safe default is to assume a DPIA is required and document your screening.
What is the difference between a DPIA and a FRIA?
A DPIA (GDPR Article 35) is a controller obligation focused on risks to personal data and privacy. A FRIA (EU AI Act Article 27) is a deployer obligation focused on all fundamental rights in the EU Charter — including non-discrimination, human dignity, and access to remedy — and applies even where little or no personal data is involved. They share a structural backbone (describe, justify, assess risks, mitigate), which is why Article 27(4) says a FRIA should complement an existing DPIA rather than duplicate it.
Can one document satisfy both the DPIA and the FRIA?
You can satisfy both with one combined evidence pack that contains shared, write-once sections plus assessment-specific overlays — and Article 27(4) actively encourages reuse. But they are not interchangeable: the FRIA is broader (all Charter rights, evaluated right-by-right) and adds steps the DPIA lacks, such as notifying the market surveillance authority under Article 27(3). So map them together, but keep both assessments distinctly addressable.
What are the four required elements of a DPIA under Article 35(7)?
(a) a systematic description of the processing and its purposes, including any legitimate interest pursued; (b) an assessment of the necessity and proportionality of the processing relative to those purposes; (c) an assessment of the risks to the rights and freedoms of data subjects; and (d) the measures envisaged to address those risks, including safeguards and security. Alongside these, Article 35(2) requires DPO advice and Article 35(9) requires seeking data-subject views where appropriate.
Has the AI Office published the Article 27 FRIA template yet?
No. As of June 2026 the AI Office has not published the template questionnaire and automated tool envisaged by Article 27(5). The obligation itself does not depend on that template — the content elements are fixed in Article 27(1) — so the practical approach is to build on the stable GDPR Article 35(7) structure now and re-export into the official format when it is released.
How does a legitimate-interests assessment fit into the DPIA?
If your lawful basis is legitimate interests under Article 6(1)(f) — common for fraud and AML — the LIA's three-part test (purpose, necessity, balancing) maps directly onto the DPIA. The purpose and necessity tests are the Article 35(7)(b) necessity-and-proportionality analysis, and the balancing test sharpens the Article 35(7)(c) risk assessment. Author the legitimate interest once in the DPIA's systematic description, which Article 35(7)(a) explicitly invites, and reference it from your LIA.
Die wichtigsten Erkenntnisse
A DPIA, a FRIA, and an LIA are not three competing chores — they are three views of the same question: is this AI system necessary, proportionate, and adequately governed before it acts on a real person? GDPR Article 35(7) gives you the most stable, regulator-tested scaffold available today, and Article 27(4) all but instructs you to build your FRIA on top of it rather than beside it. Map the elements once, fold in the legitimate-interests analysis, and you have a single combined evidence pack instead of three documents that drift apart. The final step is the one paperwork can never deliver on its own: the mitigations you commit to have to run — as gates, as two-person approvals, as sealed execution records — at the moment the agent acts. Start the combined assessment with the DPIA + FRIA generator, and build the controls so the evidence proves itself.