The EU AI Act's Fundamental Rights Impact Assessment (FRIA) requirement goes live in three months. If your team is deploying high-risk AI systems as a public body or regulated private entity, Article 27 applies to you. Non-compliance carries fines up to €30 million or 6% of global annual turnover.
This isn't theoretical. A compliant data processing register won't protect you from deploying a model that systematically disadvantages specific groups. Your Data Protection Impact Assessment (DPIA) was never scoped to catch that pattern. The FRIA is designed to do just that.
Here's how to build the process before August 2, 2026.
The Problem: Your DPIA Doesn't Cover This
You've run DPIAs on every AI system that processes personal data. Your data processing register is current. You believe you're compliant.
You're not, because the FRIA evaluates a different category of harm. It asks whether your system treats people fairly, creates systemic disadvantage, and whether affected individuals can challenge decisions made about them. These questions are outside the GDPR's scope.
Consider a team deploying an AI model for loan application review. The data processing is lawful. The DPIA is complete. Eighteen months post-deployment, an audit reveals applicants from certain postal codes are declined at rates far above baseline. The pattern looks like indirect discrimination. The DPIA never caught it because it wasn't designed to.
That's the gap Article 27 addresses. If you deploy high-risk AI systems under Annex III definitions (creditworthiness evaluation, life and health insurance pricing, public service delivery, or any deployment by a public body), you need a FRIA process operational before August.
What You Need Before Starting
System inventory with risk classification
Review your AI deployments against Annex III categories. Tag anything that evaluates creditworthiness, prices insurance policies, supports public service delivery, or operates within a public body. These are your Article 27 candidates.
Cross-functional team assignment
The FRIA requires input that legal, data science, HR, product, and risk can't provide individually. Assign ownership across functions before you start. One person coordinates, but the assessment itself is collaborative.
Your existing DPIA documentation
The EU AI Act permits combining a FRIA with an existing DPIA where genuine overlap exists. Pull your current data protection assessments for the systems you've tagged. You'll reuse portions of this work.
Fundamental rights reference framework
You're evaluating impact on dignity, equality, privacy, non-discrimination, freedom of expression, access to justice, and the right to good administration. Your team needs a shared understanding of what these rights mean in operational terms before you assess whether your system affects them.
Documentation repository
Article 27 creates an audit trail requirement. Set up a structured location for assessment records, findings, and mitigation decisions before you begin. You'll need to produce this documentation on request.
Step-by-Step Implementation
Step 1: Map fundamental rights to system functions
For each high-risk AI system, identify which fundamental rights it touches. Don't guess. Bring legal, product, and data science into the same room and work through it together.
Ask: Does this system make decisions about people? Does it evaluate, score, rank, or recommend actions that affect access to services, employment, credit, or legal processes? Which rights does that implicate?
Document the mapping. If your system evaluates loan applications, you're affecting equality (through potential discrimination), privacy (through data processing), and access to services. Write it down.
Step 2: Identify affected populations
Who is subject to this system's decisions? Be specific. "Loan applicants" is too broad. Break it down: first-time borrowers, applicants in specific geographic regions, applicants with non-traditional credit histories.
The AI Office encourages stakeholder involvement. For systems with significant public impact, consider consulting affected groups or independent experts during this phase. The feedback will surface risks your internal team didn't consider.
Step 3: Assess potential harms
This is where the FRIA diverges sharply from your DPIA. You're not evaluating data protection risk. You're evaluating human impact.
What happens when the system is wrong? Can it deny someone access to credit, housing, employment, or public services? Does it create barriers for specific demographic groups? Can it amplify existing societal disadvantages?
Your data science team should model error distribution across affected populations. If your false negative rate varies significantly by postal code, age bracket, or any protected characteristic, document it and explain why.
Step 4: Document accountability and oversight
Article 27 requires you to specify who is accountable when the system produces harmful outcomes and what oversight mechanisms exist.
Define: Who reviews model outputs before they become final decisions? What escalation path exists for contested outcomes? How do affected individuals challenge a decision? What human review is available, and at what threshold does it trigger?
If your answer is "the model decides and there's no review process," you have a compliance gap and a design problem.
Step 5: Establish mitigation controls
For each identified risk, document your mitigation. This might include adjusting the objective function, adding human review for high-stakes decisions, implementing fairness constraints, or building in transparency mechanisms.
Mitigation isn't optional. If you identify a risk and deploy anyway without documented controls, you've created an audit finding before the system goes live.
Step 6: Integrate with your DPIA where overlap exists
Pull your existing DPIA documentation for this system. Where the FRIA addresses data protection (Individual Rights, lawfulness of processing), reference the DPIA rather than duplicating work. The EU AI Act permits this explicitly.
Where the FRIA addresses rights your DPIA doesn't cover (non-discrimination, access to justice, dignity), complete the assessment independently.
Validation: How to Verify It Works
Pre-deployment checklist
Before first use, confirm you can answer these five questions in writing:
- Which fundamental rights does this system affect?
- How might it compromise dignity, equality, privacy, or access to legal remedy?
- What happens to specific individuals when the system is wrong?
- Who is accountable for those outcomes, and what oversight exists?
- How can an affected person challenge a decision made about them?
If you can't answer all five with documented evidence, your FRIA is incomplete.
Cross-functional sign-off
Your legal, data science, product, and risk functions should all review and approve the final FRIA. If any function identifies gaps or disagrees with the risk characterization, resolve it before deployment. The FRIA is your documented consensus on acceptable risk.
Regulatory readiness test
Assume a regulator requests your Article 27 documentation tomorrow. Can you produce the FRIA, the supporting analysis, the mitigation controls, and the accountability framework within 48 hours? If not, your documentation structure needs work.
Maintenance and Ongoing Tasks
Update triggers
The FRIA isn't static. You must update it when the system changes, when its use case expands, or when you identify new risks post-deployment.
Define your update triggers explicitly: model retraining, deployment to new populations, changes in decision thresholds, or material changes in regulatory guidance.
Periodic review cadence
Even if nothing changes, review your FRIA annually. Your understanding of the system's impact will improve with operational data. Edge cases you missed during initial assessment will surface. Update your documentation to reflect what you've learned.
Incident linkage
When your AI system produces an adverse outcome (a wrongful denial, a discrimination complaint, a legal challenge), link it back to your FRIA. Did your assessment predict this risk? Were your mitigations insufficient? Document the finding and adjust your controls.
Organizations that treat the FRIA as a living governance document rather than a pre-deployment formality will have something competitors won't: a documented track record of responsible AI deployment that predates regulatory pressure. That matters when regulators show up, and it matters when something goes wrong.
You have three months. Build the process now, or complete templates under audit pressure in July. The organizations that start this week will have time to do it properly.
