FRIA Template: Fundamental Rights Impact Assessment Under Article 27
EU AI Act Article 27 FRIA template: six required sections, scope limited to public bodies and Annex III 5(b)/5(c) deployers. Deadline 2 December 2027.
Article 27 of the EU AI Act (Regulation (EU) 2024/1689) requires specific deployers of high-risk AI systems to complete a Fundamental Rights Impact Assessment before first use — not after, not as a rolling project, but as a documented gate before the system goes live. This page provides the statutory template structure, explains who must complete it, and walks through each required section with practical guidance on what a regulator will actually want to see.
For the legal background on Article 27 — including the penalty exposure for deployers who miss this obligation — see the Article 27 legal guide.
Who Must Complete a FRIA
Article 27's scope is narrow. Not every deployer of a high-risk AI system owes a FRIA. Three categories are in scope:
1. Bodies governed by public law. This covers government ministries and agencies, local authorities, public universities, national health services, courts, law enforcement authorities, and social security bodies. If your organisation is established to serve a public interest and is subject to public administrative law, you are almost certainly a body governed by public law.
2. Private entities providing public services. The Act does not define this category exhaustively, but it is generally understood to include private operators that have been entrusted with a public-service mandate — for example, a private company running a public social-benefits eligibility system under government contract, or a private operator managing critical public infrastructure. A private bank assessing credit for retail customers is not, for this reason alone, a private entity providing a public service; it is in scope on a different basis (see below).
3. Deployers of Annex III point 5(b) or 5(c) systems. Regardless of whether they are public or private bodies, deployers of systems used to assess creditworthiness or credit scores (Annex III, point 5(b)) or to evaluate risk and price life insurance and health insurance (Annex III, point 5(c)) must complete a FRIA. A regional bank using a credit-scoring model for consumer lending is in scope. A life insurer using an AI system to price policies is in scope. This is the category most often missed by private-sector compliance teams.
One explicit exclusion: Article 27(1) carves out Annex III point 2 (critical infrastructure management systems) from the FRIA requirement. All other in-scope Annex III categories remain subject to it when the deployer falls into category 1 or 2 above.
The obligation applies to the first use of the system (Article 27(2)). A deployer may rely on a previously completed FRIA for comparable deployments, or on a FRIA already carried out by the provider, but must verify that the earlier assessment covers the current deployment context. If any element listed in Article 27(1) has changed, the deployer must update the assessment.
Under the Digital Omnibus (political agreement reached 7 May 2026), obligations for stand-alone high-risk AI systems under Annex III — including Article 27 — apply from 2 December 2027 (deferred from the original 2 August 2026 date). For high-risk AI embedded in regulated products covered by Annex I, the date is 2 August 2028. That is still less than 18 months away for many in-scope deployers, and a FRIA for a credit-scoring system at a large lender will take months to prepare properly.
The Six Required Sections (Article 27(1)(a)–(f))
Article 27(1) specifies six items the assessment must cover. Every in-scope deployer must address all six in writing. There is no statutory discretion to omit a section because it seems less relevant.
Section A — Description of the Deployer's Processes and Intended Use [Article 27(1)(a)]
Document the specific processes in which the high-risk AI system will be used, in line with the provider's intended purpose. This is more than a product description: it should describe the organisational workflow, the decisions the system will support or automate, the business unit responsible, and the geographic and temporal scope.
A credit-scoring deployer would document: which loan products the system evaluates, at what stage of the application process, whether outputs are used as a sole determinant or as one input among several, and who in the organisation acts on those outputs.
This section is also where you confirm that your intended use falls within the provider's intended purpose as documented in the instructions for use. If your deployment extends beyond that intended purpose, you may be taking on provider-level obligations under Article 25.
Section B — Period and Frequency of Use [Article 27(1)(b)]
State the period during which the system will be in use and the frequency with which it will be deployed — how many decisions per day or month, whether use is continuous or periodic, and any planned review points.
This matters for two reasons. First, a system used to process thousands of individual credit decisions per week poses different aggregate harm risks than one used for occasional high-stakes decisions. Second, frequency data informs the monitoring obligations under Article 26 and the review triggers for keeping the FRIA current.
Section C — Categories of Affected Persons and Groups [Article 27(1)(c)]
Identify all categories of natural persons and groups whose interests are likely to be affected by the system's operation. This includes the direct subjects of AI-assisted decisions (loan applicants, insurance policyholders), but also individuals who are indirectly affected — for example, dependants of a policyholder whose claim is affected, or households affected by a credit decision.
Pay specific attention to potentially vulnerable groups: people in financial difficulty, older persons, persons with disabilities, migrants or persons with atypical credit histories, and minorities whose characteristics may correlate with protected grounds in ways the model has not fully accounted for. Vulnerability is not a reason to exclude a group from the analysis; it is a reason to give their assessment greater weight.
Section D — Specific Risks of Harm [Article 27(1)(d)]
Assess the specific risks of harm likely to affect the categories of persons identified in Section C, taking into account the information provided by the provider under Article 13 (the transparency and information obligations for high-risk AI systems).
This is the analytical core of the assessment. The analysis must be specific to your deployment. Generic statements — "the system may produce discriminatory outputs" — do not satisfy Article 27(1)(d). You must identify:
- Which fundamental rights are at risk. For a credit-scoring system: the right to non-discrimination (Charter Article 21), the right to an effective remedy (Charter Article 47), and dignity (Charter Article 1). For a life-insurance pricing system: similar non-discrimination risks, plus the right to health protection (Charter Article 35).
- For which groups. If the model performs less accurately for applicants with non-standard income patterns — freelancers, seasonal workers, recent migrants — document that.
- With what assessed severity. Being denied a mortgage is a materially different harm from being denied a premium insurance add-on. Calibrate accordingly.
- Taking into account provider-supplied information. The provider's Article 13 disclosure should include accuracy metrics, known limitations, and foreseeable risks. If the provider's documentation is insufficient, that is itself a compliance flag to raise with the provider under Article 26.
Article 27(4) creates a useful bridge: if a GDPR Data Protection Impact Assessment (DPIA) under Article 35 of Regulation (EU) 2016/679 has already been conducted for the same processing, the FRIA must complement it — not duplicate it. Coordinate the two assessments. The DPIA covers privacy and data-protection risks. The FRIA covers the broader fundamental rights picture: non-discrimination, access to remedies, dignity, fair process. Both may apply to the same system, and they should be prepared in a coherent sequence.
Section E — Human Oversight Measures [Article 27(1)(e)]
Describe the human oversight measures you will implement, in accordance with the provider's instructions for use. This section translates the provider's Article 14 oversight design into your specific operational reality.
State concretely:
- Who holds oversight responsibility (job title and minimum qualification or training required).
- What decision-making authority the human overseer has: can they override the AI output, and in what circumstances are they required to do so?
- What information the overseer receives to make that judgment — not just the AI output, but the supporting inputs and any confidence indicators.
- What happens when the overseer is unavailable (escalation path, minimum staffing threshold).
- How override decisions are recorded and whether they feed back into the provider's post-market monitoring under Article 72.
The instruction "a qualified officer reviews high-risk decisions" is not enough. Specify what "high-risk" means in your context (e.g., any application where the model's output falls below a defined confidence threshold, or all applications from persons over 70), and document what the officer reviews and how the decision is recorded.
Section F — Measures If Risks Materialise [Article 27(1)(f)]
Document the measures you will take if the risks identified in Section D actually occur — both the operational response and the governance and complaint mechanisms that affected persons can access.
This section has two distinct parts:
Internal governance response: What does your organisation do when a risk materialises? Define the escalation chain: who is notified, within what timeframe, and who has authority to suspend use of the system pending investigation. Note that under Article 26, deployers must inform providers of risks and serious incidents, and must flag those incidents to market surveillance authorities where the AI system presents a risk. Document how that reporting chain operates.
Complaint and remedy mechanisms: Affected persons whose interests are harmed by an AI-assisted decision have a right to an effective remedy under Charter Article 47. Your FRIA must document how someone denied credit or charged an elevated insurance premium because of an AI output can challenge that decision. This means identifying the complaint channel (DPO, ombudsman, internal review team), the review process, and the standards applied. A mechanism that exists in theory but is not communicated to affected persons will not satisfy this requirement.
How to Run the Assessment
Start by obtaining the provider's instructions for use, technical documentation summary, and Article 47 Declaration of Conformity — these supply the facts for Sections A, D, and E. If the provider has not supplied them, request them under Article 26 before proceeding.
Work through the six sections in order, involving your DPO and legal team for the rights analysis (Section D) and the complaint mechanisms (Section F). Section D requires the most time: work through each relevant Charter right systematically, document the severity assessment for each group identified in Section C, and note the source of each judgment (provider documentation, internal testing, sector comparables).
Once complete, notify the relevant national market surveillance authority and submit the filled-out template under Article 27(3). The AI Office is required by Article 27(5) to publish a standard questionnaire — monitor its publications for the release. Retain the notification record.
Establish review triggers before the assessment is filed, not after. Revisit the FRIA on: any change to the system or deployment scope; any change to the affected populations; any incident identified under your Article 26 monitoring; and at least once annually. A FRIA that is never updated is a compliance risk, not a compliance asset.
A Note on Using a Template Honestly
A template structures the work; it cannot do the analysis. The six sections of Article 27(1) are not boxes to fill — they are prompts for genuine organisational reasoning about specific harms to specific people in a specific deployment context. A FRIA that is thorough on paper but generic in substance will not satisfy a market surveillance authority conducting a review, and it will not serve the people whose fundamental rights are at stake.
The assessment must reflect your actual deployment: your processes, your oversight capacity, your complaint mechanisms, and your honest evaluation of the risks the system creates. A credit-scoring model at a 40-person fintech will require a different analysis than the same model at a large retail bank processing 10,000 applications per month — even though both must complete all six sections.
How Confir Helps
Confir runs the FRIA workflow as a structured, rule-based process within its AITO (Transparency and Human Oversight) compliance area — stepped questions mapped to each of the six Article 27(1) sections, with applicability determined automatically during the AIRC classification phase. The completed assessment is recorded in the audit log and available for submission to the market surveillance authority.
Related guides
- public sector FRIA requirements
- Article 27 compliance guide
- Annex III asylum processing systems
- Annex III social benefits assessment
- Annex III law enforcement AI
- fintech AI compliance standards
Frequently Asked Questions
What is a Fundamental Rights Impact Assessment under the EU AI Act?
A Fundamental Rights Impact Assessment (FRIA) is a pre-deployment analysis required by Article 27 of Regulation (EU) 2024/1689. Certain deployers of high-risk AI systems must document, in writing, how the system is likely to affect the fundamental rights of the people whose interests it touches — covering the deployment context, affected populations, specific risks of harm, human oversight measures, and the measures to be taken if those risks materialise. It must be completed and notified to the national market surveillance authority before first use.
Who must complete a FRIA?
Three categories of deployer: (1) bodies governed by public law (government agencies, public authorities, courts, public hospitals); (2) private entities providing public services; and (3) any deployer — public or private — of a high-risk AI system used for creditworthiness or credit scoring (Annex III, point 5(b)) or for life/health insurance risk assessment and pricing (Annex III, point 5(c)). Deployers of Annex III point 2 (critical infrastructure) systems are explicitly excluded. A private employer using a recruitment AI system is not automatically in scope — it would need to qualify as a public body or public service provider separately.
Is a FRIA the same as a GDPR Data Protection Impact Assessment?
No. A DPIA (under GDPR Article 35) focuses on risks to personal data and privacy. The FRIA covers the broader range of fundamental rights under the EU Charter — including non-discrimination, access to effective remedies, dignity, and fair trial guarantees. Where a DPIA has already been completed for the same processing, Article 27(4) requires the FRIA to complement it, not replace it. Both assessments may apply to the same AI system and should be coordinated.
When must the FRIA be completed and notified?
The FRIA must be completed before the first use of the system (Article 27(2)). Once complete, the deployer must notify the relevant national market surveillance authority and submit the filled-out AI Office template (Article 27(3)). Under the Digital Omnibus agreed in May 2026, the Article 27 obligation for stand-alone high-risk Annex III systems applies from 2 December 2027 (deferred from the original 2 August 2026 date). For high-risk AI embedded in regulated products under Annex I, the date is 2 August 2028.
Can a deployer rely on a FRIA completed by the provider?
Yes, in part. Article 27(2) allows a deployer to rely on an existing FRIA carried out by the provider for comparable deployments. But the deployer must verify that the earlier assessment covers the specific deployment context — the same processes, affected populations, and organisational oversight setup. If any of the six elements listed in Article 27(1) has changed or is no longer current, the deployer must update the assessment before use.
What happens if the FRIA needs updating after deployment?
Article 27(2) requires the deployer to update the FRIA if any element listed in Article 27(1) changes during use. Update triggers include: changes to the AI system itself (which may also require re-assessment under Article 26), changes to the deployment scope or affected populations, changes to applicable legislation, and material findings from the ongoing monitoring the deployer must conduct under Article 26. Treat it as a living document with defined review intervals, not a one-time filing.
Last reviewed June 2026. Cites Regulation (EU) 2024/1689 (EU AI Act).
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 →