Article 27 of the EU AI Act introduced a new compliance artefact: the Fundamental Rights Impact Assessment, or FRIA. If you deploy a high-risk AI system in employment, banking, insurance, essential public services, or law enforcement, you have to complete one before deployment. There is no required template in the legislation — but the European AI Office is expected to publish guidance, and the shape of a defensible FRIA is already clear from the text.
This guide covers what a FRIA must contain, how to structure it, and what each section should actually say. It includes a worked example for a credit-scoring AI system. For the bigger picture on which systems land in the high-risk tier, see Annex III explained. For the full compliance plan, see our EU AI Act compliance guide for SaaS.
When you need a FRIA
The FRIA obligation applies to deployers of high-risk AI systems, not providers. Specifically:
- Public-sector bodies deploying any high-risk system listed in Annex III
- Private bodies acting on behalf of public services when deploying a high-risk system
- Private deployers of AI systems in:
- Creditworthiness and credit scoring (Annex III point 5(b))
- Risk assessment and pricing in life and health insurance (Annex III point 5(c))
- Biometric categorisation, emotion recognition (where high-risk)
- Employment, workers' management (Annex III point 4)
If you're a SaaS provider, the FRIA obligation usually sits on your customer who deploys your AI feature against EU users. But you'll be on the hook to help them — their FRIA depends on the technical documentation, performance characteristics, and human-oversight design you provide. Expect customers to ask.
The seven sections of a FRIA
The Act doesn't dictate a structure but Article 27(1) lists seven items the FRIA must contain. We treat each as a section.
1. Description of the deployer's processes in which the AI system will be used
Plain-language description of the business process the AI system is embedded in. Who uses it, in what workflow, to what end. Include scope (which products, which markets, which user segments) and operational tempo (volume of decisions per day, weeks, year).
Worked example (credit scoring AI):
"Our consumer-credit business uses an AI-driven credit-scoring model to assess applications for unsecured personal loans up to €25,000. The model is invoked at the application-decision stage of the loan workflow, after KYC checks but before credit committee review. It returns a probability-of-default score that is used as one of five inputs to the human credit officer's decision. The model is invoked approximately 4,500 times per business day across our EU operations (DE, FR, NL, IE)."
2. The period and frequency of intended use
How long the system will be in production, the frequency of operation, and the planned review cadence.
Worked example:
"The model has been in production since March 2024 and is intended to remain in production indefinitely, subject to quarterly performance review and annual full re-evaluation. Re-training is performed semi-annually using a rolling 12-month data window. Significant model changes (e.g., feature set updates) trigger a fresh FRIA cycle."
3. The categories of natural persons and groups likely to be affected
Who is affected — applicants, employees, beneficiaries — and the relevant protected categories (age, gender, ethnic origin, disability status, etc.).
Worked example:
"Affected persons are individual applicants for consumer credit aged 18 to 75, residing in DE, FR, NL, or IE. Approximately 51% are female; 49% male. We don't collect ethnic-origin data directly but our model is trained on historic decision data that may contain proxies (postcode, education history). Particular attention is given to potential disparate impact on younger applicants (18-25), older applicants (65-75), and applicants with thin credit files (common in recent migrants)."
4. The specific risks of harm likely to impact the affected categories
The substance of the assessment. What harms could occur, to whom, and how. The four canonical harm types worth considering for any FRIA:
- Material harm — financial loss, lost opportunity, denial of essential service
- Physical harm — usually limited unless the AI affects critical infrastructure or health
- Non-material harm — distress, reputational damage, discrimination, loss of autonomy
- Collective harm — chilling effects, systemic discrimination, erosion of trust in institutions
For each likely harm, identify the affected category, the mechanism by which the harm occurs, and the likelihood.
Worked example (extract):
"Material harm: denial of credit to creditworthy applicants. If the model under-scores certain demographic groups (e.g., younger applicants with thin credit files), creditworthy individuals may be denied credit and forced to use higher-cost alternatives. Likely affected: applicants aged 18-25, applicants with under 24 months of UK credit history. Mechanism: features correlated with age (employment duration, prior credit history length) may serve as proxies. Likelihood: moderate based on our 2025 fairness audit, which showed a 3.2 percentage-point gap in approval rates between 18-25 and 35-45 cohorts after controlling for income and stated affordability.
Non-material harm: erosion of autonomy through opaque decision-making. Applicants who are declined may not understand why, reducing their ability to challenge or improve. Likely affected: all declined applicants. Mechanism: the model produces a score, not a reason code. Mitigation: we provide standardised adverse-action notices and signpost the right to human review under Article 22 GDPR."
5. Human oversight measures
The description of how human oversight is designed, who exercises it, and what authority they have.
Worked example:
"The model output is not a final decision. Every loan decision is made by a credit officer who reviews the model score alongside affordability checks, credit-bureau data, and the application itself. The officer can override the model both ways: approve where the model declines, decline where the model approves. Overrides are tracked monthly, and override rates are reported to the Credit Risk Committee.
Model output is presented to officers with a confidence band and the top three contributing features (without revealing model weights). Officers receive quarterly training on appropriate weighting of the model output relative to other inputs.
The credit risk function reviews model performance monthly. The model can be paused or rolled back to the prior version within 4 hours of a detected anomaly via the runbook in our SOC 2 control register."
6. Measures to be taken in case of materialisation of the risks
The contingency plan. What you do if the risks identified in Section 4 actually occur.
Worked example:
"If disparate-impact gaps widen beyond agreed thresholds: the model is paused for new decisions within 24 hours; all open applications are routed to manual review. The fairness audit is rerun on a larger sample; root-cause analysis is performed; a remediation model is trained or feature engineering is adjusted; the FRIA is updated before redeployment.
If a high volume of complaints alleges discriminatory outcomes: each complaint is logged, the affected decisions are re-reviewed, the pattern is reported to the Credit Risk Committee, and the regulator (FCA, in the EU equivalent BaFin) is notified per the supervisory reporting framework.
If a model-drift incident occurs: the model is rolled back to the previous validated version within 4 hours. The drift event is logged as an Article 73 incident if it meets the serious-incident threshold (we treat any drift causing >50bps shift in approval rate as serious)."
7. Internal governance and complaint mechanisms
How the deployer governs the system internally and how affected individuals can complain or seek redress.
Worked example:
"Internal governance: the Credit Risk Committee owns the model; the Head of Credit Risk is accountable. Monthly performance review; quarterly fairness audit; annual full FRIA review. Material changes to the model trigger an FRIA cycle and Risk Committee sign-off before deployment.
Complaint mechanism: declined applicants are informed of the right to request a human review, in plain language, in the adverse-action notice. The review is performed by a credit officer who was not involved in the original decision. Complaint volumes and outcomes are reported quarterly. We also signpost the right to complain to the relevant data protection authority and to the financial regulator."
Three principles for a good FRIA
After reviewing dozens of drafts, three things separate FRIAs that survive regulatory scrutiny from those that don't.
1. Be specific, not abstract. Regulators have read every generic risk-management template ever written. A FRIA that says "we identify and mitigate risks" is worse than useless — it's a flag that you didn't do the work. Name the specific risks for your specific use case with specific numbers.
2. Show your work. Reference the fairness audit, the override-rate report, the complaint log, the drift detector. Where you have data, cite it. Where you don't, say "we don't yet measure this; here's the plan to start measuring it by Q4." The FRIA is your evidence trail, not a marketing document.
3. Acknowledge limits honestly. A FRIA that claims zero residual risk is a FRIA written by someone who hasn't thought about the system. Real systems have real residual risks; the FRIA's job is to identify them, justify them as acceptable trade-offs, and explain how they're monitored.
How to keep it current
A FRIA is not a one-time document. The Act requires it to be updated whenever the system changes materially — feature set, training data, intended use — or when monitoring detects new risks.
In practice this means a quarterly review cycle owned by a named person, with sign-off captured in the audit log. GreyScape.ai ships this as the FRIA capture form alongside per-system risk classification, with the FRIA versioned against the AI system entry and the evidence vault holding the supporting fairness audits.
You can keep the FRIA in a Word doc and version-control it manually — many organisations do. The form of the artefact matters less than the discipline of keeping it current and the evidence trail that supports it.
What to do this week
- For every high-risk AI system in your inventory, check if a FRIA is required (use the categories in the section above).
- For each one that requires a FRIA, draft the seven sections using the worked example above as a starting point.
- Stress-test the FRIA against your fairness audit results, override rates, and complaint log. If you can't back a claim with evidence, say so explicitly and start collecting the evidence.
For the wider compliance picture, see our EU AI Act compliance guide for SaaS. For the high-risk classification step that comes before the FRIA, see Annex III explained.