The DPIA and FRIA, run jointly: one assessment, two regimes, no duplicate work
The short answer
One investigation, two sign-offs
The DPIA and the FRIA examine the same system. Do the investigation once, then present the findings under both the Article 35 and Article 27 headings. Running two separate investigations produces duplicated work and contradictory documents.
What you will be able to do
- Distinguish what a Data Protection Impact Assessment (DPIA) under Article 35 of the GDPR (General Data Protection Regulation, Regulation (EU) 2016/679) is legally required to cover from what a Fundamental Rights Impact Assessment (FRIA) under Article 27 of the EU AI Act (Regulation (EU) 2024/1689) is legally required to cover.
- Apply the DPIA trigger test and the FRIA trigger test to one AI system and state, with reasons, whether each assessment is legally required for that system.
- Build a single crosswalk that maps every mandatory field of both regimes onto shared and regime-specific sections, so overlapping content is written once and the unique content of each is not lost.
- Produce a joint DPIA and FRIA for a high-risk system in your own organization that names the affected groups, the specific fundamental-rights harms, the mitigations, and the human-oversight measures.
- Explain why a data-protection-only assessment can pass while a discrimination harm goes unrecorded, using the difference in legal scope between the two regimes.
- Defend the joint assessment against the objection that combining the two documents weakens either one, and state the condition under which combining is legally safe.
- Identify where the joint assessment consumes your earlier artifacts (the AI systems inventory, the risk classification, the data provenance file, the conformity file) and where it feeds the evidence annex and the dossier.
- Sequence the assessment correctly in the deployment lifecycle: confirm the high-risk classification, obtain the provider's information and the data provenance, run one investigation, notify the authority, then deploy.
- Write a mitigation with teeth: a named owner, a metric broken down by the affected group, and a stop threshold, and explain why a mitigation lacking any of the three is boilerplate.
The lesson
Imagine two auditors arriving at your organization on the exact same morning to inspect the exact same AI system. The first auditor is your data protection officer. She wants to know what personal data the system touches, whether your processing has a lawful basis, and how securely that information is stored under the GDPR.
The second auditor is a fundamental rights reviewer. She is holding the EU AI Act, and she wants to know something entirely different. Does this system, working exactly as designed, treat a disabled claimant or a single mother worse than everyone else? Faced with these two distinct demands, most organizations do the work twice.
They write one document for the first auditor, and months later, under a different deadline, with a completely different team, they start writing a second document from a blank page. Running two separate investigations for one system creates a massive compliance failure. The two teams produce contradictory red lines, and the most critical risks fall right through the gap between them.
Organizations rely heavily on the General Data Protection Regulation because it is a familiar baseline. They know how to write a Data Protection Impact Assessment, or DPIA. But Article 27 of the AI Act contains a specific instruction that almost nobody acts on.
It states that where a fundamental rights obligation is already met by a Data Protection Assessment, the new Fundamental Rights Impact Assessment shall complement the existing DPIA, not repeat it. The law itself gives deployers the explicit license to build one integrated assessment that satisfies both legal regimes. The operational mandate for your compliance team is to achieve a single outcome.
One investigation, two sign-offs. Mapping the investigation to both laws simultaneously creates a defensible record that identifies discrimination risks a data-only lens would otherwise leave unrecorded. Before you begin writing a joint assessment, you have to prove exactly who owes a FRIA under the AI Act.
This decision tree maps the three specific deployer categories caught by Article 27. The first two obligations fall strictly on bodies governed by public law and private entities providing public services. The third trigger ignores the deployer's public or private status entirely.
Any deployer operating a system classified under Annex 3.5b for credit scoring or 5c for life and health insurance must complete a FRIA. There is one strict carve-out to check. If a public body deploys an AI system for the management of critical infrastructure under Annex 3.2, they are explicitly exempt from the FRIA requirement.
We can test this logic. If a private commercial bank deploys a credit worthiness evaluation model, they are caught directly by the 5b trigger. They owe a FRIA despite being a private entity.
Contrast that with a private firm deploying an internal high-risk screening tool to evaluate job applicants. They are not providing a public service, and hiring is not credit or insurance. That firm does not owe a FRIA.
However, because that same HR tool performs systematic automated evaluation of candidates, the firm is still legally required to conduct a DPIA. The rule here is absolute. The triggers for a DPIA and a FRIA are completely independent.
You can never infer that owing one assessment means you automatically owe the other. This Venn diagram illustrates the structural relationship between the two laws. The scopes of the assessments overlap heavily in the center, but neither regime entirely contains the other.
Relying solely on a data protection lens is a severe failure mode for AI safety because it misses the precise harm that sinks algorithms, discrimination. A DPIA is designed to evaluate whether processing personal data is necessary, proportionate, lawful, and secure. Nothing in those four mandatory DPIA checks forces the assessor to ask if the resulting algorithm systematically produces worse outcomes for a demographic group.
The consequences of this gap played out at the French Council of State in late 2024, involving a national benefits algorithm operated by the CNF. The algorithm analyzed claimant data to assign a fraud risk score. On paper, a DPIA could easily conclude that analyzing income and employment data was proportionate and necessary for the business goal of fraud detection.
Yet the algorithm, working exactly as designed, systematically assigned higher suspicion scores to people who spent a large share of their income on rent, who were unemployed, and who worked while disabled. A DPIA alone is insufficient because disparate treatment is a fundamental rights harm before it ever becomes a data protection issue. To merge these assessments without dropping mandatory legal fields, you build a crosswalk matrix.
The center of the matrix holds the shared content, the systematic description of the AI model, the categories of people affected, and the core risk and mitigation framework. You write this shared center exactly once, eliminating all duplicative investigation for your teams. Next, you map the DPIA-only wing.
This includes the lawful basis for processing, the necessity and proportionality analysis, and the data security safeguards. Practitioners often drop these fields when they build their joint document off a FRIA template. Do not make that mistake, or your GDPR obligations will remain unmet.
Then, you map the FRIA-only wing. This begins with the rigorous non-discrimination analysis, mapping disparate outcomes directly to specific EU charter rights. You complete the FRIA wing by documenting the human oversight measures, the complaint mechanisms for affected individuals, and the market surveillance notification form.
When filling out the affected groups analysis, a desk-only review is legally fragile. You must consult the affected people or their representatives directly to prove your assessment is grounded in reality. This single crosswalk matrix is your ultimate shield.
It proves to regulators from both regimes that no mandatory field was dropped. When compliance teams discover a severe risk of harm, their first instinct is often to soften the language in the assessment to reduce apparent legal liability. The harm exists whether you document it or not.
Obscuring the risk falsifies your compliance record. Naming the harm plainly and proving you mitigated it is exactly what makes your deployment defensible. To address a named harm, you must build a mitigation with teeth.
This requires three interlocking elements. First, the mitigation must have a specifically named owner inside your organization who holds personal accountability for the measure. Second, you must establish a continuous monitoring metric broken down by the specific affected demographic group.
Third, you define a hard stop threshold. This is a specific numeric limit that, if crossed, automatically pauses the deployment for review. If your mitigation says we will monitor for fairness without an owner, a specific metric, and a stop threshold, it is meaningless boilerplate.
In court, that leaves you entirely exposed. The deployment sequence is strict. You classify the risk, obtain the system data from your provider, run your single investigation, complete the crosswalk matrix, notify the authorities, and only then do you turn the system on.
Both the GDPR and the AI Act mandate that this assessment remains a living record, subject to review as the system and its risks evolve. Retraining your model, introducing a new data source, or discovering a new affected demographic group all immediately trigger a mandatory review of your assessment. When those triggers hit, you do not start over from scratch.
You update the specific fields within your existing joint document and re-notify the authority with the changes. Ultimately, your completed crosswalk will sit on the desks of data protection regulators and market surveillance authorities. Running a joint DPIA and FRIA proves to the board, to the regulator, and to the public that you looked for harm and you mitigated it before the algorithm ever touched a human life.
The ideas, one by one
The regimes overlap but neither contains the other
The DPIA is scoped to personal data; the FRIA is scoped to all fundamental rights but only for specific deployers. Some DPIA content (lawful basis, security) has no FRIA home; some FRIA content (non-discrimination analysis, human oversight, complaint mechanism, regulator notification) has no DPIA home. The shared center is written once.
Article 27(4) is the license to merge
The AI Act itself says the FRIA complements the DPIA where the DPIA already meets a FRIA obligation. Building one integrated document is not a shortcut; it is the legally sanctioned design.
The discrimination harm is what a data-only lens misses
A fully compliant DPIA can be produced for a system that discriminates, because disparate treatment is a fundamental-rights harm before it is a data-protection harm. The FRIA's affected-groups-and-specific-harms content is what forces the discrimination onto the page.
Know exactly who owes a FRIA
Public bodies (except Annex III point 2), private entities providing public services, and any deployer of creditworthiness or life-and-health-insurance systems. A private firm's internal high-risk hiring tool generally does not trigger Article 27, though it still owes a DPIA.
The assessment is a living document
Both regimes require review when the risk or situation changes. Build the joint assessment to be revised, and revise it when the model, the data, or the affected groups change.
Name the harm, then mitigate it
An honest assessment that names a serious harm and pairs it with an owned mitigation and a monitoring threshold is more defensible than a clean one that hides the harm. Softening a harm removes the trigger for the mitigation and leaves the harm to be found by a regulator or court.
File the FRIA
For Article 27 deployers, the assessment must be notified to the market-surveillance authority on the AI Office template. An unfiled FRIA is incomplete.
The joint assessment is load-bearing evidence
It consumes your inventory, classification, provenance, and conformity artifacts, and it feeds your evidence annex and dossier. It is one of the documents the board audit in Module 13 will pull first.
Sequence the assessment, do not tack it on
Confirm the high-risk classification, obtain the provider's Article 13 information and the data provenance file, then run one investigation, then notify, then deploy. Starting the FRIA before you have the provider's documentation forces a rewrite.
Reuse is allowed, blind reuse is not
A provider's or a prior assessment can seed the shared center, but the deployer must rewrite the context-specific FRIA wing (affected groups, frequency, human oversight). Adopting someone else's document wholesale leaves your own deployment unassessed.
The two triggers are independent
A DPIA is triggered by risky processing of personal data; a FRIA is triggered by the deployment of a high-risk Annex III system by an in-scope deployer. You can owe one without the other in either direction, so never infer one trigger from the other.
Consult the affected, do not guess about them
The most defensible affected-groups analysis draws on the people the system affects and their representatives. A desk-only analysis is the pattern a rights coalition later shows was done without genuinely looking.
You read it. Now prove it.
Explain this lesson in your own words, the way you would to a colleague, without looking back at it. It is graded against the lesson itself, by the same grader our learners face. One free try a day, no account needed.
The conversation
The same lesson, talked through at length by two hosts: the full transcript of the audio deep dive.
Listen to it as episode 79 of the podcast.
Read the full conversation
So, welcome to today's Deep Dive. Today's mission is really about mastering one of the most critical legal frameworks in AI deployment right now. Yeah, it's a huge topic.
It really is. And for our sources today, we are pulling directly from a really intense executive level training module on evidence engineering. Specifically, we're looking at Module 10, Topic 10.4. Right, which is focused entirely on integrating the Data Protection Impact Assessment, the DPIA, with the Fundamental Rights Impact Assessment, or the FRIA.
Exactly. And to really get into this, I want you to imagine a scenario. Just imagine two auditors arriving at your office lobby on the exact same morning to inspect the exact same AI system you just deployed.
Oh, the classic nightmare scenario. Right. So, Auditor A walks in and she's holding a copy of the GDPR.
She operates like a fire inspector. She wants to know if the building's going to burn down, right, are your servers secure, what personal data are you collecting. Do you even have a lawful basis to hold that data? Yeah, she's looking purely at the data as an asset.
Exactly. But then Auditor B walks in right behind her holding the EU Artificial Intelligence Act. Yeah.
And she operates more like an ADA compliance officer. She doesn't really care about the fire alarms. No, she wants to know if a wheelchair user can actually get through the front door.
Yes. She wants to know if your system working exactly as it was mathematically designed to work fundamentally disadvantages a single mother. Or treats a disabled claimant as a suspect by default.
And the scary thing is you can pass that fire inspection with flying colors and still get sued into the ground for locking out vulnerable people. Right. And that tension right there, that is the defining reality of modern AI governance.
It really is. I mean, ideally, we'd want these regulatory regimes to live in neat, separate buckets, right? The data privacy team over here and the AI ethics team over there. But that's not reality.
No, not at all. When you step into high stakes AI deployment, those buckets overlap aggressively. And that friction between them is where massive corporate liabilities are born.
And the standard corporate reaction to that friction is basically just panic. Right. Which leads to incredible inefficiency.
We see organizations faced with those two auditors and they just do the work twice. Oh, constantly. They spin up a massive DPIA for the first auditor.
And then six months later, under a totally different deadline, using a different team that doesn't even talk to the first team, they start a FRIA from a completely blank page. Which is just wild. It is the fastest way to sabotage your own compliance strategy.
Because by writing two separate documents with two separate teams, you aren't just burning budget. You are guaranteeing duplicated work. Right.
And you're creating a paper trail. Exactly. You are creating a massive documented risk of contradicting yourself in writing.
You're literally proving to a regulator that your data team and your AI deployment team do not understand the system in the same way. And when those documents overlap and contradict each other, it just creates this dangerous scene down the middle. The critical risks, the algorithmic harms that actually sink multi-million dollar deployments, they fall right through that crack.
Yeah, they do. So for you listening, you are a sharp, busy professional. You don't have time for duplicate paperwork, and you certainly don't have the luxury of missing a discrimination harm that could blow up a major system launch.
Nobody does. Right. So we are treating this as high-stakes executive education.
The core idea today is how to run one investigation with two sign-offs. We are going to teach you how to build a single bulletproof impact assessment. And to build that unified assessment, we really have to forensically dissect what each of these frameworks is legally demanding from you.
Because the regimes overlap, but neither contains the other. Right. That's a crucial point.
We need to know where the borders actually lie. Right. So let's start with the older one, right? The DPIA under Article 35 of the GDPR.
Yeah, the DPIA has been part of the European corporate landscape since, what, 2018? And the muscle memory for this is already built into most large organizations. Which is comforting, but maybe a bit of a trap. It's totally a trap.
Because the DPIA's center of gravity is entirely focused on personal data. Under Article 35, if a type of processing is likely to result in a high risk to the rights and freedoms of natural persons, you have to assess it. But it's very specific about what it wants.
Very. It requires a systematic description of the processing, an assessment of necessity and proportionality, an assessment of risks to data subjects, and specific security safeguards. So the lens is strictly about the data itself.
Like, do we actually need this specific data set? Is it in a secure environment? Is there a legal justification sound? The necessity and proportionality tests, the encryption standards, these are pure data protection concepts. They are about input and storage. But you have to contrast that heavily with the FRIA.
Right. The Fundamental Rights Impact Assessment under Article 27 of the AI Act. Yeah.
Its scope is entirely different because it actually cares about outputs and human impact. And the AI Act is deliberately narrower on who has to do FRIA, but the aperture of what you have to look at is massively wider. Massively.
The FRIA is not scoped just to data protection. It covers all fundamental rights in the EU Charter. So we're talking about things way beyond just privacy.
Oh, yeah. You have to assess impacts on human dignity under Article 1. You have to look at non-discrimination under Article 21, the rights of the child under Article 24, and the right to good administration under Article 41. Wow.
Okay. So data protection is in the Charter, right? Article 7 and 8. But in a FRIA, it's just one single right among dozens. Exactly.
So to visualize this... Yeah. Let's unpack this visually for the listener. Think of a Venn diagram.
You have the DPIA circle on the left, focused on data lifecycle. You have the FRIA circle on the right, focused on broad human rights outcomes. Circles overlap, but neither swallows the other.
Okay. So what's in that DPIA-only crescent? Like the far left side that doesn't touch the FRIA at all? That's your rigid GDPR requirements. Your lawful basis for processing, your data retention schedules, and your specific cryptographic security safeguards.
The FRIA doesn't care about your encryption key management. That lives solely in the DPIA. Makes sense.
And on the far right, the FRIA-only crescent? There you find the non-discrimination analysis specifically broken down across affected demographic groups. You find the descriptions of human oversight measures, the structural mechanisms for handling citizen complaints, and the requirement to notify the market surveillance authority. The GDPR's DPIA never asks for any of that.
But the magic really is in that shared center, right? Yes. The shared center is the foundational reality of your AI system. It's where you put the description of the architecture, the categories of affected persons, the intended purpose, and the baseline risks.
Both laws demand this exact same foundational information. But wait, let me push back on this for a second. If the FRIA covers all fundamental rights, and data protection is literally a fundamental right, why doesn't the FRIA just absorb the DPIA entirely? Like, why do we still need both? It's a really logical question, but legally it's a fatal assumption.
The FRIA cannot swallow the DPIA because the GDPR have highly specific, rigid requirements that simply do not have a home in the text of the FRIA. Like the lawful basis and security stuff. Right.
You cannot just write a broad FRIA that says, you know, we respect human rights and privacy, slap a label on it, and assume those GDPR obligations vanish. If you do that, your AI Act compliance might look great, but you will instantly fail a GDPR audit. Okay, so the scopes overlap, but the regimes are distinct, which brings up the real operational question.
Does the law actually allow us to merge these workflows? People worry regulators will demand two distinct files. Exactly. If I'm a compliance director, I need to know if I can actually combine them.
You absolutely can. And actually, the European legislator explicitly engineered the law to invite this. Article 27.4 is the license to merge.
Article 27 of the AI Act, right? Yes. It explicitly states that if an obligation is already met through DPIA, the FRIA shall complement that DPIA. Shall complement.
That's a very deliberate phrasing. Very deliberate. It doesn't say, shall run parallel to, or shall be filed separately.
The legislators knew they were creating a heavy burden. They knew a good DPIA already has the system description and baseline risks, so they are legally inviting organizations to build one integrated assessment. So the DPIA is the core, and the FRIA builds outward from it.
Exactly. And this requires a total shift in how teams operate. A senior practitioner operates on one strict rule, one investigation, two sign-offs.
Right, because the amateur approach is sending a 50-page questionnaire from the privacy team to the engineers, and then six months later, the AI ethics team sends a slightly different 50-page questionnaire to those same engineers. And the engineers just get exhausted. They give inconsistent answers.
You end up with documents that overlap by 70% but contradict each other. The senior practitioner refuses to run the investigation twice. So what do they do instead? They build a crosswalk.
They take all mandatory fields from both regimes, put them in a matrix, and run a single evidence-gathering pass. So you have one master file. If the GDPR regulator asks, you hand them the file highlighting Article 35 sections.
If the AI authority asks, you hand them the same file highlighting Article 27 sections. One truth, two views. It is the only way to stay sane.
But here's where it gets really interesting, and I know a nervous director might say this. Combining these puts all our liability in one basket. By putting data vulnerabilities and bias vulnerabilities in one document, aren't we just painting a target on our backs? Doesn't this weaken both documents? I hear that all the time.
It's a common misconception from traditional legal defense. But it's completely backward. Combining them is what makes you defensible.
How so? Because siloed liability is a myth. If you write two separate documents with two different teams, they will contradict each other. The privacy team says the AI deletes data every 30 days.
The AI team says it trains on a rolling 90-day window. Oh, wow. Yeah, that's a disaster waiting to happen.
It is lethal in court. Contradictory evidence is what destroys organizations. Plaintiffs' counsel will subpoena both, put them side by side, and prove you have no idea how your own system works.
So the unified crosswalk is actually your proof of control. Yes. It proves no required field was dropped, and that the organization actually understands the technology it deployed.
OK, so we know we can merge them, and procedural consistency says we should merge them. But there's a critical operational reason why we must merge them. And that is to catch the fatal blind spot inherent in data privacy laws.
Yes, the discrimination gap. The discrimination harm is what a data-only lens misses. Let's break that down, because this is the intellectual core of why the FRA even exists, right? Right.
You can execute a flawless DPIA. You can be 100% compliant with the GDPR. And that exact same AI system can still systematically discriminate against marginalized people at scale.
Because the DPIA is structurally blind to outcomes. It only asks about the inputs. Exactly.
It asks, is data processing necessary and proportionate? A bank can process financial data securely and legally to assess loan risk, but the underlying scoring formula might output massive rejection rates for minority applicants based on proxy variables. And disparate treatment is a fundamental rights harm charter Article 21 before it's a data protection harm. Yes.
The FRIA forces you to analyze the output to break those outcomes down by affected subgroups. To really see this in action, we have to look at the real-world anchor case from our sources, the French National Family Benefits Fund, CNAF. This is the perfect example.
It's not hypothetical. Right. This was October 2024.
A coalition led by La Quadresse Urunette and Amnesty International challenged CNAF's fraud risk scoring model before France's highest administrative court, the Council of State. And this system actively processed data for about 32 million people. 32 million.
And the way it calculated suspicion is just staggering. It didn't look for explicit fraud markers. It assigned higher risk scores based on markers of vulnerability.
Yeah, proxy variables. If a household had a low income, their fraud score increased. If they were unemployed, the score went up.
If a massive percentage of their income went to rent, the algorithm flagged them as a higher risk. It's essentially treating poverty as a statistical proxy for fraud. And it actually gets worse.
If an individual was working while registered as disabled, the algorithm increased their fraud score. Right. So put Auditor A, the data protection officer, in front of that system.
What do they say? They say, processing income data is proportionate to detecting fraud. The data is secure. The DPIA passes.
Exactly. The DPIA passes because the data is safe. But the humans are being targeted.
Now bring in Auditor B with the FRIA. The FRIA forces the question, does this system treat a disabled claimant as a suspect by default? Yes. The FRIA demands that you take the output, the fraud scores, and break them down by demographic subgroups.
If you run these separately, the bias question might never even get asked. The joint assessment forces it to be an unavoidable section of the exact same file the data privacy officer is reviewing. But OK, what does this mean for the listener? If I follow this framework and I document a severe discrimination risk in my joint assessment, aren't I just handing a plaintiff their entire lawsuit on a silver platter? It's a harsh truth, but the harm exists whether you write it down or not.
An algorithm doesn't stop discriminating just because you refuse to document it. Actually, falsifying an impact assessment by omitting known risks is a massive governance failure in itself. The cover-up becomes the primary offense.
So you can't just plead ignorance? No. Look at the CNF case. The scandal didn't happen because they documented a risk.
It exploded because they ran the system on 32 million people while the risk sat undocumented and unmitigated. Naming the harm plainly and pairing it with a concrete mitigation is the exact definition of defensibility. You're proving you looked for the harm and took action.
If you hide it and a whistleblower finds it, you have zero defense. Zero. Because your paperwork proves you didn't even check.
OK, so the stakes are immense. We need to get practical. The listener needs to know exactly when this dual regime obligation applies to their own business.
Know exactly who owes a FRIA. Let's start with the DPIA triggers under GDPR Article 35-3. Just to ground us.
You owe a DPIA if your system performs systematic and extensive automated evaluation of people, including profiling, that produces legal or significant effects. Also, if you process large-scale special categories of data like health or biometrics. So if the AI makes consequential decisions about humans, you're hitting a DPIA trigger.
Yes, but the FRIA triggers under Article 27 of the AI Act operate on a completely different logic. Right, because high-risk status alone is not enough to trigger a FRIA, is it? No, it's not. Article 27 is highly specific.
It targets three categories. First, bodies governed by public law. So government agencies.
With one major exception, we'll get to. Right. Second, private entities providing public services, like a private utility company.
Third, any deployer, public or private, of Annex 3.5b and .5c systems. OK, let's translate those Annex 3 points. What are 5b and 5c? .5b is creditworthiness and credit scoring.
.5c is life and health insurance pricing. So if I'm a private tech company not providing public services, I'm mostly insulated from the FRIA. Mostly, yes.
Unless your software touches credit scoring or health and life insurance, those are considered so critical that they pull you in regardless of being a private commercial entity. Let's run some real-world examples to stress test this. Example 1, a bank deploys an AI creditworthiness model.
Private entity but .5b triggers the FRIA. Financial data triggers the DPIA. Joint assessment is legally mandatory.
Simple enough. Example 2, a private firm running an internal high-risk HR screening tool to sort resumes. This is where they diverge.
The HR tool evaluates personal aspects to make a significant decision, so that triggers a DPIA. But it does not trigger a FRIA. It's not a public service, and it's not credit or insurance.
So they owe a DPIA, but not a FRIA, even though HR tools are notorious for bias. Right. A smart governance team would run the FRIA voluntarily to protect against employment lawsuits.
But under the letter of the AI Act, it's not strictly mandated. Example 3, a public transport authority deploys traffic management AI. Ah, the exception.
They are a public body, which normally triggers a FRIA. But they fall under Annex 3.2, the carve-out for critical infrastructure management, like road traffic and utilities. So they may not owe a FRIA, even though a DPIA might be heavily required if cameras capture license plates.
OK, we need a currency check here. What is the timeline for all this? When do regulators actually start demanding these joint documents? The digital omnibus package on AI simplification was finalized on June 29, 2026. That deferred the standalone Annex 3 obligations, including the Article 27 FRIA, to December 2, 2027.
So there's a bit of a runway. There is. But do not wait.
That is the worst strategic decision you could make. The internal friction of merging these teams takes months. Build the discipline now.
Wait, I have one edge case question on triggers. What if a public agency is deploying a high-risk system that uses zero personal data? Like, maybe just environmental readings for drought relief. Do they get to skip both? Absolutely not.
And assuming they do as a critical failure, the triggers are totally independent. No personal data means no DPIA. But a public body deploying a high-risk system still owes a FRIA because it dictates resource allocation.
Ah, so in that rare case, you run a standalone FRIA. Yes, never infer one trigger from the other. The AI Act cares about the output, even if the inputs are just soil moisture readings.
OK, so we know the why and the when. Let's get into the exact how. The step-by-step framework for executing the joint assessment.
It all comes down to sequencing. Governance by design. You cannot do this at the end of the software build when the architecture is locked in.
If you run it post-build, you have zero leverage to fix discrimination risk without spending millions on rework. So what's the exact sequence? Confirm high-risk classification. Then, this is non-negotiable, obtain the provider's Article 13 information.
That's the instructions and capabilities. Then pull your data provenance. Then run the joint investigation.
Notify the authority if required, and then deploy. Why is that provider's information so critical up front? Because if you assess before you have the provider's final documentation on what the system mathematically does, you are assessing a ghost. You'll spend weeks writing a compliance document based on how you assume the AI functions.
When the vendor delivers it, you'll find out it has totally different capabilities and you have to rewrite the whole thing. Okay, so once we have the ground truth, how do we build the crosswalk mechanics? Like, in a spreadsheet? Yeah, simple three-column table. Column 1 is the field.
Column 2 is required by DPIA. Column 3 is required by FRIA. And you fill the shared center first.
Right. System description, affected persons, and a crucial rule. Reuse your conformity file here.
Do not force an officer to rewrite technical descriptions from scratch. Now, here's a trap I want to highlight from the sources. I can totally see someone copy-pasting the DPIA's categories of data subjects lists and using it for the FRIA's affected groups section to save time.
That is one of the four most common traps. A data subject list just says whose data is present. We process benefit recipients' data.
The FRIA requires you to split those categories by outcomes. It's an active analysis, not a passive inventory. Exactly.
Do disabled recipients receive a different score than non-disabled ones? A data list is not an impact analysis. And you can't just guess those impacts from your desk. Both GEPR Article 35-9 and the FRIA require consultation.
You have to ask real people. You must identify organized representatives, disability rights bodies, tenant unions, and ask if the described pattern matches harms they see on the ground. What if they don't answer your emails? An honest, written record saying, we could not identify a representative body or we reached out and got no response, is a defensible record.
You proved you attempted governance. A silent gap where you just skipped it because it was hard. That is a massive red flag to regulators.
Because it shows you didn't even try to understand the human impact. Which brings us to the ultimate output. The mitigations.
If the mitigations are weak, the whole document is useless. We need mitigations with teeth. Using vague verbs like ensure fairness or monitor for bias is legally worthless boilerplate.
So what does a mitigation with teeth actually look like? It has three specific elements. One, a named owner, like the head of investigations, not a vague committee. Two, a specific metric broken down by the affected group, like the referral rate ratio for disabled claimants.
And three. A numeric stop threshold. Right, the kill switch.
Exactly. If the ratio exceeds 1.25 for two months, deployment automatically pauses. That pre-commits the organization in writing before financial incentives cloud their judgment.
The FRIA also demands human oversight and redress, right, to prevent automation bias. Yeah. Affected people must have a route to learn a decision involved AI and to contest it to a human who can actually override it.
If a human investigator is just rubber stamping the AI's 85% fraud score, that's not oversight. I love this phrase in the module. The assessment is a living document.
And that's not just a nice idea. It's the law. GDPR Article 3511 and AI Act Article 27 both mandate reviews when risks change.
So if you retrain a model on new data, or add a new input feature six months post-launch, the original assessment is dead. It is no longer valid. You don't start from zero, but you must open that master crosswalk, update the specific fields that changed, and reassess.
That's the beauty of the modular crosswalk. What about relying on the vendor? If the software provider already did an impact assessment, can I just stick their PDF in our file and call it a day? Article 27 too allows you to rely on a provider's assessment only to the extent applicable. The provider doesn't know your specific frequency of use, your local affected groups, or your internal human oversight procedures.
Right, a model trained in California might act totally differently on a rural population in France. Exactly. Blind reuse leaves your specific deployment totally unassessed.
You use their doc for the shared center, but you must rewrite the FRIA wing for your exact context. This has been incredibly dense, but so valuable. Let's summarize the absolute must-remembers.
The FRIA complements the DPIA under Article 27.4. The unified crosswalk is your ultimate defense against duplicate work. And remember the discrimination gap. The fundamental rights lens catches the harms that a data privacy lens naturally misses.
Mitigations need owners, metrics, and stop thresholds. Okay, it's time for the Monday morning move. The single most valuable action you should take this Monday.
Open your AI systems inventory. Take your highest risk system, map its existing DPIA against the FRIA requirements using a simple three-column crosswalk, and identify exactly which fundamental rights gaps you need to fill before the December 2027 enforcement deadline. It will expose your blind spots immediately.
Yes, and I'm going to leave you with a final thought to mull over. For decades, legal compliance was just about protecting the organization's data. But the FRIA forces us to hold up a mirror.
When you have to document exactly how your algorithm treats the most vulnerable people in society, compliance stops being just a legal checkbox. It becomes a permanent written record of your organization's actual values. Are you ready for what that mirror is going to show?
Real cases
These examples show the DPIA-and-FRIA relationship as it appears in real deployments and enforcement, with the assessment reasoning made explicit. The anchor case (France, CNAF) is treated in depth in the Section 5 scenario; here it is referenced only to connect the pattern.
Example 1: A public welfare fraud-scoring system (the pattern behind the anchor). A national benefits agency runs an algorithm that assigns every recipient a fraud-risk score. Because it processes personal data of tens of millions of people through systematic automated evaluation, a DPIA is mandatory under Article 35(3)(a) of the GDPR. Because the deployer is a public body running an Annex III high-risk system (public assistance benefits eligibility, Annex III point 5(a)), a FRIA is mandatory under Article 27 once that obligation is in force. The DPIA can find the data processing proportionate; only the FRIA's affected-groups analysis forces the agency to record that the scoring flags disabled claimants, single parents, and low-income households at higher rates. This is the anchor case pattern examined in Section 5.
Example 2: A bank's creditworthiness model (private, but still in FRIA scope). A commercial bank deploys an AI system to evaluate loan applicants' creditworthiness. The bank is a private entity, so a public-body FRIA trigger does not apply, but Annex III point 5(b) (creditworthiness and credit scoring) pulls any deployer, public or private, into the FRIA obligation. The bank also processes personal financial data at scale, triggering a DPIA. Here the joint assessment is unavoidable: both regimes apply to the same system. The DPIA covers lawful basis and data-subject rights; the FRIA covers whether the model's decisions disadvantage protected groups and what human-oversight and complaint routes exist for a rejected applicant.
Example 3: A life-insurance pricing model. An insurer uses AI to assess risk and set prices for life and health insurance. Annex III point 5(c) puts this squarely in FRIA scope for any deployer. The DPIA addresses the health data (a special category under GDPR Article 9); the FRIA addresses whether pricing produces discriminatory outcomes and whether affected people can contest a price. Two regimes, one system, one joint file.
Example 4: A city's public-transport surveillance system (FRIA yes, but note the carve-out). A municipal transport authority (a public body) wants to deploy an AI system. If the system falls under Annex III point 2 (safety components in the management of critical infrastructure, including road, rail, and other transport), the public-body FRIA trigger is expressly carved out for that point. A DPIA may still be required for the personal data. This example is the reminder that the FRIA scope has a specific exception, and reading Annex III point by point matters before you conclude a FRIA is owed.
Example 5: An internal HR screening tool at a private firm. A private company deploys a high-risk hiring-screening AI (Annex III point 4). Because it is a private entity not providing a public service, and hiring is not point 5(b) or 5(c), the Article 27 FRIA obligation generally does not bite, even though the system is high-risk and the firm has other deployer duties. A DPIA is still required because of the systematic automated evaluation of candidates. This is the case where the two regimes come apart: DPIA yes, FRIA generally no. The joint-assessment discipline still helps: running the fundamental-rights analysis voluntarily surfaces the discrimination risk that hiring tools are notorious for, even where Article 27 does not compel it. (see Topic 5.4) for the deeper treatment of hiring-AI law.
Example 6: A cross-border deployment where only one regime applies. A deployer outside the EU serves EU residents. Depending on the facts, the GDPR may apply through its territorial scope (Article 3) while the AI Act's deployer obligations attach differently. The lesson: do the regime-applicability analysis first, per system, per jurisdiction, and never assume that because one assessment is required the other automatically is, or the reverse. (see Topic 5.1) for the "does the law apply" gate.
Example 7: A hospital's diagnostic-support AI (special-category data drives the DPIA). A public hospital deploys an Annex III high-risk AI system that supports clinical decisions. As a public body deploying an Annex III system that is not point 2, it owes a FRIA. Because it processes health data at scale (a special category under GDPR Article 9), it also owes a DPIA under Article 35(3)(b). The joint assessment's shared center describes the clinical processes and the patients affected once; the DPIA wing handles the Article 9 lawful-basis and safeguards analysis; the FRIA wing handles whether the system's support decisions risk harming vulnerable patient groups and how a clinician's human oversight is exercised so the model advises rather than decides. This example shows the two wings doing genuinely different work on one system.
Example 8: A provider's assessment a deployer wants to reuse. A software provider has already produced a thorough impact assessment for its high-risk system. A deploying public body wants to avoid redoing it. Article 27(2) allows a deployer to rely, to the extent applicable, on a FRIA previously conducted or on one done by the provider, updating for its own context. The deployer cannot simply adopt the provider's document wholesale: the affected groups, the frequency of use, and the human-oversight arrangements are context-specific to the deployer. The defensible move is to take the provider's assessment as the base for the shared center and rewrite the deployment-specific FRIA wing. Reuse is permitted; blind reuse is not.
Example 9: A high-risk system with no personal data. A public authority deploys a high-risk Annex III system that operates only on aggregate, non-personal environmental readings to allocate a public service. Because no personal data is processed, no DPIA is triggered under Article 35. But because a public body deploys an Annex III system, a FRIA is still owed under Article 27. The result is a standalone FRIA, not a joint assessment. This example proves the two triggers are independent: the absence of a DPIA does not remove the FRIA, and reasoning from one trigger to the other is a mistake in both directions.
Example 10: A regulator comment mid-deployment. After a public deployer files its FRIA, the market-surveillance authority responds within the comment window and raises a concern about the human-oversight arrangements. Article 27(3), which puts the FRIA results before the market-surveillance authority, contemplates exactly this dialogue: the deployer must engage with the authority's view. The living-document design pays off here, because the deployer folds the comment and its response into the same assessment rather than starting a side document, and the exchange becomes part of the evidence that the deployment was scrutinized before launch. This is the pattern the Section 5 scenario dramatizes.
Where people go wrong
- "A DPIA is enough for a high-risk AI system." Wrong for the deployers Article 27 names. A DPIA satisfies the GDPR's data-protection scope. It does not, on its own, satisfy the FRIA's fundamental-rights scope, which reaches non-discrimination, dignity, good administration, and effective remedy. For a public body or a credit or insurance deployer, a DPIA alone leaves the Article 27 obligation unmet.
- "A FRIA replaces the DPIA." Also wrong. The two regimes are separate legal instruments with separate triggers and separate content. Article 27(4) says the FRIA complements the DPIA where the DPIA already meets a FRIA obligation; it does not say the FRIA absorbs or cancels the DPIA. Some DPIA content (lawful basis, security measures) has no FRIA home and must still be produced.
- "Combining the two documents weakens both." The opposite is true when done correctly. Combining prevents the two assessments from contradicting each other and forces one consistent set of findings. The condition for doing it safely is that every mandatory field of both regimes is present and traceable in the joint document. A crosswalk is how you prove that condition is met.
- "The FRIA is only about data protection because that is where AI risk lives." No. Data protection is one Charter right. The FRIA's defining feature is that it looks at all fundamental rights, and its most valuable output is usually the non-discrimination analysis, which a data-protection lens can miss entirely.
- "Every deployer of a high-risk system must do a FRIA." No. Article 27 targets three groups: public bodies (with the Annex III point 2 critical-infrastructure carve-out), private entities providing public services, and any deployer of creditworthiness or life-and-health-insurance systems (Annex III points 5(b) and 5(c)). A private firm running an internal high-risk hiring tool generally is not caught by Article 27, though it still owes a DPIA and other deployer duties.
- "The assessment is a one-time gate before launch." Both regimes make it a living document. The DPIA must be reviewed when the risk changes (GDPR Article 35(11)); the FRIA must be updated where the situation changes (AI Act Article 27(2)). Build the joint assessment to be revised, and revise it when the model, the data, or the affected groups change.
- "Naming a serious harm in the assessment creates liability, so soften it." The harm exists whether documented or not. Softening it removes the trigger for a real mitigation and leaves the harm to be discovered by a regulator, journalist, or court. A defensible assessment names the harm plainly and pairs it with a mitigation and a monitoring threshold. The falsification of an impact assessment is itself a governance failure.
- "Once the FRIA is written, the obligation is done." For the Article 27 deployers, the assessment must be notified to the market-surveillance authority (Article 27(3)) using the template the AI Office provides (Article 27(5)). An unfiled FRIA is an incomplete FRIA.
- "The provider did an assessment, so the deployer does not need to." Article 27(2) lets a deployer rely on a provider's or a prior assessment only to the extent applicable, updating for its own context. The affected groups, the frequency of use, and the human-oversight arrangements are deployer-specific. Blind adoption of the provider's document leaves the deployer's own context unassessed.
- "A high-risk system that does not use personal data needs neither assessment." The FRIA is not conditional on personal data; it applies to the deployment of a high-risk Annex III system by an in-scope deployer regardless of whether personal data is processed. A system could conceivably trigger a FRIA without triggering a DPIA. Do not use the absence of personal data to conclude no assessment is owed.
- "The affected-groups analysis can be done entirely from our own desk." An affected-groups section written with no input from the people the system affects, or their representatives, is the exact kind of assessment a rights coalition later shows was performed without genuinely looking. The GDPR's consultation duty (Article 35(9)) and the FRIA's affected-groups duty both point toward hearing from the affected, not guessing about them.
Questions people ask
- What is Data Protection Impact Assessment (DPIA)?
- An assessment required by Article 35 of the GDPR (Regulation (EU) 2016/679) before processing that is likely to result in a high risk to the rights and freedoms of natural persons. It must contain a systematic description of the processing, an assessment of necessity and proportionality, an assessment of the risks to data subjects, and the measures to address those risks. More on Data Protection Impact Assessment (DPIA)
- What is Fundamental Rights Impact Assessment (FRIA)?
- An assessment required by Article 27 of the EU AI Act (Regulation (EU) 2024/1689) before certain deployers put a high-risk Annex III AI system into use. It must describe the processes and intended use, the period and frequency of use, the categories of persons and groups affected, the specific fundamental-rights risks, the human-oversight measures, and the measures to be taken if risks materialize, including governance and complaint mechanisms. More on Fundamental Rights Impact Assessment (FRIA)
- What is GDPR (General Data Protection Regulation)?
- Regulation (EU) 2016/679, the European Union's data-protection law, in force since May 2018. It governs the processing of personal data and is the source of the DPIA obligation in Article 35. More on GDPR (General Data Protection Regulation)
- What is EU AI Act?
- Regulation (EU) 2024/1689, the European Union's horizontal law on artificial intelligence, in force since 1 August 2024. It is the source of the FRIA obligation in Article 27 and of the high-risk classification in Annex III. More on EU AI Act
- What is Annex III?
- The annex of the EU AI Act listing the categories of AI systems classified as high-risk, including (point 4) employment and worker management, (point 5(a)) access to essential public assistance benefits and services, (point 5(b)) creditworthiness evaluation and credit scoring, and (point 5(c)) risk assessment and pricing in life and health insurance, among others. More on Annex III
Keep going
This lesson builds AI risk and impact assessment, and that page shows the roles that hire for it. Every Certified AI Governance Professional (CAIGP) lesson.