FRIA Template: Fundamental Rights Impact Assessment Under Article 27

Who Actually Needs a FRIA

Not every organization deploying AI needs to complete a Fundamental Rights Impact Assessment. Article 27 targets three specific categories of deployers of high-risk AI systems (as defined under Annex III):

1. Bodies governed by public law — government departments, agencies, municipalities, and other public authorities.
2. Private entities providing services of a public nature — specifically in banking, insurance, healthcare, education and vocational training, and employment/worker management.
3. Any deployer using AI for creditworthiness assessment, credit scoring, or life and health insurance risk assessment and pricing (Annex III, points 5(b) and (c)) — regardless of whether the organization is public or private.

High-risk AI systems used in the management or operation of critical infrastructure are explicitly exempt from this specific obligation, though other deployer duties under the Act still apply.

If your organization falls outside these categories, Article 27 does not apply to you directly — but the underlying discipline (mapping who is affected, what could go wrong, and how you'd catch it) is good practice for any consequential AI deployment.

What the FRIA Must Contain

Per Article 27(1), the assessment consists of six elements:

1. Deployment process and purpose — a description of the deployer's processes in which the high-risk AI system will be used, in line with its intended purpose.
2. Period and frequency of use — how long and how often the system will operate, to assess longer-term impact.
3. Affected persons and groups — the categories of natural persons and groups likely to be affected by its use in the specific context.
4. Specific risks of harm — the risks likely to impact those categories, taking into account the information the provider supplied under Article 13.
5. Human oversight measures — how human oversight is implemented, according to the provider's instructions for use.
6. Mitigation measures — the steps to be taken if identified risks materialize, including internal governance arrangements and complaint mechanisms.

The assessment must be completed before the system's first use, and updated when the deployment context or risk profile changes materially. Once complete, the results must be reported to the relevant national market surveillance authority (unless an exemption applies).

The EU AI Office is expected to publish an official template and supporting tool under Article 27(5); until it is available, deployers work from the statutory elements directly — which is what the template below structures.

Free FRIA Template

Use this structure as a working document per high-risk use case — not per organization. A single deployer may need multiple FRIAs if it runs several distinct high-risk AI systems.

1. System and deployment context

• System name, provider, and version.
• Intended purpose, as documented by the provider.
• Description of the deployer's process in which the system is used — where it sits in the broader workflow.
• Legal basis for the deployment (which Annex III category applies, and why the FRIA obligation is triggered).

2. Duration and frequency of use

• Expected duration of the deployment (pilot, ongoing, time-limited).
• Frequency of use (per case, per day, continuous).
• Any planned review or renewal points.

3. Affected persons and groups

• Categories of natural persons or groups likely to be affected, directly or indirectly.
• Whether any affected group is a vulnerable population (children, persons with disabilities, economically vulnerable individuals) — the Act specifically calls out impact on children where applicable.
• Estimated scale (how many people, over what period).

4. Specific risks of harm

• Risks to fundamental rights specifically (non-discrimination, privacy, due process, access to services) — not only operational or security risks.
• Risk sources: model limitations documented by the provider, data quality issues, context-specific misuse potential.
• Severity and likelihood assessment per identified risk.

5. Human oversight measures

• Who has oversight authority, and what training/competence they hold.
• At what point in the process human review or approval occurs.
• What triggers escalation to a human decision-maker.
• How oversight is technically enforced (not just documented as a policy).

6. Mitigation and governance

• Concrete mitigation measures per identified risk.
• Internal governance: who owns this FRIA, and how often it is reviewed.
• Complaint and redress mechanism: how an affected person can raise a concern, and how it is handled.
• Reporting: confirmation of notification to the relevant market surveillance authority, where required.

How This Connects to a DPIA

If your organization already completes Data Protection Impact Assessments (DPIAs) under GDPR for the same system, do not start from scratch. A DPIA and a FRIA overlap substantially — both assess risk to individuals from a data-driven process — but a FRIA's scope is broader (fundamental rights generally, not only data protection) and is triggered by different criteria. Cross-reference the two documents rather than duplicating the risk analysis.

How NeuroCluster Supports the Evidence

The elements a FRIA asks for — who used the system, what data it accessed, what human oversight was applied, and what happened when — are exactly what NeuroCluster's deployment snapshots and action logs record automatically. Populating sections 5 and 6 above from a NeuroCluster deployment is a matter of exporting the evidence pack, not reconstructing it from memory or scattered documentation.

See the full EU AI Act compliance guide for how classification, logging, and human oversight fit together, or plan a readiness assessment to map your specific high-risk use cases.