EU AI Act Article 27: Fundamental Rights Impact Assessment
EU AI Act Article 27 requires public bodies and credit/insurance deployers to complete a FRIA before first use. Scope, content, and Dec 2027 deadline.
Article 27 of Regulation (EU) 2024/1689 requires certain deployers of high-risk AI systems to complete a Fundamental Rights Impact Assessment — a FRIA — before putting a system into operation. This is not a provider obligation. It is not conformity assessment (that is Article 43). It is a deployer-facing exercise, targeted at organisations whose use of high-risk AI carries the greatest risk of harm to individuals' rights, and it must be finished before the first deployment.
The deadline for stand-alone high-risk Annex III systems is 2 December 2027, following the Digital Omnibus agreement reached between the European Parliament and Council in May 2026, which deferred the original 2 August 2026 date.
What Article 27 is — and what it is not
Before going further, two common confusions to clear up.
Article 27 is the FRIA obligation. It is not conformity assessment (Article 43), not the general deployer obligations checklist (Article 26), and not provider risk management (Article 9). The FRIA is a separate, deployer-specific instrument. Its logic is: the provider assessed systemic risks during development; the deployer assesses what those risks mean in their specific operational context, for their specific population of affected people.
Article 27 does not apply to all deployers of high-risk AI. The trigger is narrower. You must qualify on who you are (your organisational type) or what domain you are deploying into. A private logistics company using an Annex III route-optimisation system internally does not trigger Article 27. A private lender using an Annex III credit-scoring system to decide on loan applications does.
Who must conduct a FRIA
Article 27(1) sets out two routes to the obligation. Either one is sufficient.
Route 1 — Bodies governed by public law
Any body governed by public law — at national, regional, or municipal level — that deploys a high-risk AI system listed in Annex III must conduct a FRIA before deployment, regardless of the use case. This covers central government agencies, regional authorities, local councils, public hospitals, state-owned enterprises exercising public functions, and public educational institutions.
A municipality deploying an Annex III benefits-eligibility system falls squarely here. So does a regional police authority using an Annex III risk-assessment tool for crime prevention. The FRIA obligation is unconditional for these bodies: if the system is high-risk under Annex III, the FRIA is mandatory.
Private entities that exercise public authority or deliver services under a public mandate are included on the same basis. A private hospital operating under a national health service contract, providing services the state would otherwise provide, qualifies. A commercially independent private clinic does not.
Route 2 — Deployers of specific Annex III categories
Even without any public-law character, a private organisation must conduct a FRIA if it deploys a high-risk AI system that falls into either of these two Annex III categories:
- Annex III point 5(b) — creditworthiness assessment and credit scoring (excluding fraud detection). This covers banks, lenders, credit unions, and buy-now-pay-later providers using AI to evaluate loan applications, set credit limits, or assess repayment risk.
- Annex III point 5(c) — risk assessment and pricing in life and health insurance. Insurers using AI to evaluate applicant risk profiles, set premiums, or determine coverage terms fall into this category.
These two categories are singled out because of the acute potential for discriminatory outcomes affecting individuals' access to essential financial services. A 30-person fintech deploying a creditworthiness model at a regional lender must conduct a FRIA. The company's size does not change the obligation.
When the FRIA must be completed
Article 27 requires the assessment before the system is first put into operation — before it begins processing real data about real people and informing real decisions.
For systems that are already deployed when the obligation comes into force on 2 December 2027, the FRIA must be completed at that point. For systems being newly deployed from 2 December 2027 onwards, the FRIA must precede first use.
Importantly, where a deployer runs subsequent deployments of the same system in a substantially similar context — the same municipal authority deploying the same benefits-eligibility system in two different departments, for instance — the original FRIA can be updated and reused rather than reconstructed from scratch. The assessment should be refreshed whenever the system's use materially changes: new population of affected persons, new use case, significant update to the AI system itself, or new risks identified through monitoring.
What the FRIA must contain
The FRIA is not a free-form document. Article 27(2) sets out what must be covered.
A description of the deployer's processes in which the system will be used. This grounds the assessment in operational reality. For a lender: how does the credit-scoring model sit within the loan origination workflow? At what point does its output reach a decision-maker, and in what form?
The period and frequency of intended use. Is the system queried for every application, or only above a certain threshold? Is it used continuously or for specific campaigns? Frequency affects cumulative impact, particularly for affected populations who interact with the system repeatedly.
The categories of natural persons and groups likely to be affected. Who are the subjects of the system's outputs? For a benefits-eligibility system: claimants, including potentially vulnerable sub-groups (elderly applicants, persons with disabilities, low-income households). For a credit-scoring model: loan applicants across varying demographic profiles. The FRIA requires this to be specific, not generic.
The specific risks of harm likely to impact those persons and groups. This is the analytical core. The deployer draws on the provider's Article 13 transparency information — the instructions for use, known limitations, technical characteristics — and translates it into deployment-specific risk. A credit model with known lower accuracy for thin-file applicants poses a higher risk of discriminatory denial to individuals with limited credit history. That causal chain must be traced in the FRIA.
Human oversight measures. The deployer must document the oversight procedures it has in place, consistent with Article 14 requirements and the provider's instructions for use. Who reviews borderline outputs? What training do those reviewers have? What authority do they hold to override the system?
Measures to address materialised risks. What happens when something goes wrong? Internal escalation paths, complaint mechanisms available to affected individuals, remediation procedures. The FRIA should specify how an affected person can challenge a decision, and what governance process handles that challenge.
Relationship to Article 26 deployer obligations
The FRIA sits within a broader set of deployer obligations under Article 26. These include monitoring the system's operation, ensuring inputs meet the quality standard the provider specified, logging where Article 26 requires it, and implementing the human oversight procedures the provider's instructions describe.
Article 27 complements Article 26 rather than substituting for it. Article 26 is operational — it governs how the system is used day-to-day. Article 27 is analytical — it requires the deployer to think through, in advance, what the rights exposure of that day-to-day operation is. The two overlap: the human oversight measures documented in the FRIA should correspond to the oversight procedures implemented under Article 26, and the monitoring data collected under Article 26 can feed FRIA reviews.
Deployers should treat FRIA preparation as part of Article 26 implementation, not as a separate process. The risk inventory and governance documentation they build for Article 26 purposes will directly inform the FRIA.
Relationship to the GDPR Data Protection Impact Assessment
Where Article 35 GDPR requires a Data Protection Impact Assessment (DPIA) — which it does when processing is likely to result in a high risk to natural persons' rights and freedoms, as will often be the case for Annex III systems — the FRIA and DPIA address overlapping but distinct concerns.
The DPIA focuses on risks arising from personal data processing: lawful basis, data minimisation, retention, accuracy. The FRIA focuses on fundamental rights risks arising from the AI system's operation in context: discrimination, access to essential services, dignity, procedural fairness.
Article 27(4) of the EU AI Act explicitly acknowledges this overlap and states that where a DPIA is required, the FRIA shall complement it — meaning the two can be conducted together and documented in an integrated record, so long as both obligations are separately addressed. Running them in parallel saves time and avoids duplicating stakeholder consultations. Deployers should not assume that completing a DPIA discharges the FRIA requirement, or vice versa.
Notification to the market surveillance authority
Article 27(3) requires deployers to notify the relevant market surveillance authority of the FRIA results. The AI Office is developing a template or questionnaire to standardise this notification process.
Public bodies are additionally required to register their FRIAs in the EU database. The Commission is responsible for maintaining that database; the registration obligation for providers is Article 49, and the FRIA registration for public bodies feeds into the same system. This creates a public record of which high-risk systems public bodies are deploying and what rights assessment underpinned the deployment decision.
Two worked examples
Example 1 — Municipality deploying a benefits-eligibility system
A mid-sized city (population 200,000) decides to deploy an Annex III AI system to assist case workers in assessing housing-benefit eligibility. The system is procured from a third-party provider.
The municipality is a body governed by public law, so Article 27 applies regardless of use case. Before the system goes live, the municipality must complete a FRIA covering: the intake and case-assessment processes where the system will be used; the frequency (every new application and annual review); the affected population (benefit claimants, including elderly residents, persons with disabilities, and low-income households with limited digital literacy); the specific risks the provider's Article 13 documentation identifies (known lower accuracy for atypical household structures; potential for algorithmic bias against non-native language applicants); the human oversight measures (mandatory case-worker review before any denial; supervisor review for cases involving vulnerable persons); and the complaint procedure (standard administrative review channels, with the system's output disclosed to appellants on request).
The municipality notifies the regional market surveillance authority of the results and registers the FRIA in the EU database. When it subsequently deploys the same system to process emergency-shelter applications, it updates the FRIA to reflect the different affected population and use context rather than starting over.
Example 2 — Lender deploying a credit-scoring system
A regional lender with 40 employees deploys an Annex III creditworthiness model to streamline personal loan approvals. The system falls under Annex III point 5(b), so Article 27 applies.
The FRIA documents: the loan origination workflow (system queried at underwriting stage, output presented as a risk score alongside other inputs); frequency (every personal loan application); affected persons (loan applicants, with particular attention to thin-file applicants — young adults, recent immigrants, self-employed — who are identified as higher-risk groups for accuracy gaps); specific risks (the provider's instructions note the model performs less accurately below a certain credit-history threshold; the FRIA maps this to a risk of systematically higher denial rates for groups with limited credit history); human oversight (a senior underwriter reviews all borderline scores between defined thresholds; any denial triggers a right of the applicant to request a human-only review); and complaint mechanism (internal complaints procedure per consumer credit regulation, with the applicant informed of the AI system's role in the decision).
The lender's data protection officer confirms the GDPR Article 35 DPIA already required for this processing can be expanded to address FRIA requirements in an integrated document. The combined record is filed with the national market surveillance authority.
How Confir helps
Confir's AITO module — Transparency and Human Oversight — runs the Article 27 FRIA workflow for qualifying deployers. The intake questionnaire first establishes whether you are a public body, a private entity providing public services, or a deployer of an Annex III point 5(b) or 5(c) system. If you qualify, the rule-based engine guides you through each mandatory element of the FRIA: the process description, the affected populations, the risk mapping drawn from your provider's Article 13 documentation, the human oversight procedures, and the complaint and remediation mechanisms. The output is a structured, dated FRIA document ready for market surveillance authority notification.
The engine is deterministic and rule-based — the same intake answers produce the same assessment structure, which is auditable and explainable without black-box outputs. For deployers who also need a GDPR DPIA, Confir flags the overlap and maps the shared elements so you are not completing two parallel exercises independently.
Penalties and enforcement
Violations of Article 27 fall under Article 99(4) of the EU AI Act: fines up to €15,000,000 or 3% of total worldwide annual turnover for the preceding financial year, whichever is higher. For smaller organisations, Article 99(6) provides that the fine is capped at the lower of the percentage or the fixed amount — a proportionality protection worth noting.
The enforcement date for stand-alone Annex III systems is 2 December 2027, following the Digital Omnibus deferral agreed in May 2026. That gives public bodies, lenders, and insurers roughly 18 months from now to identify whether Article 27 applies to their deployments, obtain the provider's Article 13 documentation, and complete the FRIA before the system goes live — or before the deadline arrives for systems already in operation.
Starting now rather than in late 2027 makes practical sense. Assembling the FRIA requires input from legal, operations, and data teams, and for systems procured from third parties, it depends on the provider supplying adequate Article 13 information. Chasing that documentation under deadline pressure is the preventable version of an Article 27 compliance problem.
Frequently asked questions
Does Article 27 apply to all deployers of high-risk AI?
No. Article 27 applies to two categories: bodies governed by public law deploying any Annex III high-risk system, and private deployers using Annex III systems in the creditworthiness/credit-scoring category (point 5(b)) or life/health insurance risk and pricing category (point 5(c)). A private company deploying an Annex III recruitment tool, for example, does not trigger Article 27 unless it also operates as a public body or under a public service mandate.
What is the difference between a FRIA (Article 27) and conformity assessment (Article 43)?
Conformity assessment under Article 43 is a provider obligation — it proves, before placing a system on the market, that the system meets the technical requirements of Articles 9–15. The FRIA under Article 27 is a deployer obligation — it assesses, before first use, what fundamental rights risks the system poses in the deployer's specific operational context. The two are separate instruments. A deployer conducting a FRIA is not discharging a provider's conformity assessment obligation, and vice versa.
When must the FRIA be completed?
Before the system is first put into operation. For new deployments from 2 December 2027 onwards, the FRIA must precede first use. For systems already deployed when the obligation comes into force, the FRIA must be completed by 2 December 2027.
Can the same FRIA be used for multiple deployments?
Yes, with updates. Article 27 allows the FRIA to be updated and reused for subsequent similar deployments by the same deployer. If the system, affected population, or use context changes materially, the assessment should be revised rather than copied wholesale. A public body deploying the same benefits-eligibility system across two departments can update rather than redo the FRIA, provided the deployment contexts are substantially the same.
Must the FRIA be submitted to an authority?
Article 27(3) requires deployers to notify the relevant market surveillance authority of the results. Public bodies are additionally required to register their FRIAs in the EU database. The AI Office is developing a standardised template to facilitate this notification.
How does the FRIA relate to GDPR's DPIA?
They are separate obligations with overlapping scope. The GDPR Article 35 DPIA covers data protection risks; the EU AI Act Article 27 FRIA covers fundamental rights risks from AI deployment more broadly. Article 27(4) explicitly anticipates that both may be required and states that the FRIA shall complement the DPIA — they can be conducted together and documented in an integrated record, provided each obligation is separately addressed. Completing a DPIA does not discharge the FRIA requirement.
What are the penalties for not completing a FRIA?
Article 99(4) sets the maximum fine at €15,000,000 or 3% of total worldwide annual turnover, whichever is higher. For SMEs and start-ups, Article 99(6) caps the fine at the lower of the two figures. The deadline for stand-alone Annex III systems is 2 December 2027.
Related guides
- Annex III crime prediction systems
- Annex III border control AI
- law enforcement risk assessment tools
- determine if your AI is high-risk
- Article 26 deployer obligations
- high-risk AI system definitions
- Article 13 transparency requirements
- SaaS compliance framework
- provider versus deployer roles
- startup compliance implementation
Manage your EU AI Act compliance in one place
Confir automates risk classification, technical documentation, and audit trails for any company. No consultants. No 6-month projects. 7-day free trial.
Start free trial →