EU AI Act Art.27 FRIA Template & Methodology: Step-by-Step Assessment Guide for High-Risk AI Deployers (2026)

Post #2 in the sota.io EU AI Act FRIA 2026 Series

Post #1 established who must conduct a Fundamental Rights Impact Assessment (FRIA) under Art.27. This post answers the follow-up question: once you have determined you are in scope, what exactly do you assess, and how?

The EU AI Act does not provide a single official FRIA template. Art.27 sets out the required content and procedure, but the format is left to deployers. This guide synthesises the statutory requirements into a concrete seven-section template you can adapt.

Why No Official Template Exists

Unlike GDPR Art.35 DPIAs — where supervisory authorities have published detailed guidance — Art.27 FRIA methodology is newer. The European Data Protection Board (EDPB) has indicated it will publish joint guidance with the AI Office, but as of mid-2026 that guidance is still in development.

This means deployers must construct their FRIA from three sources:

• Art.27 itself, which lists required content
• Recitals 110–114 of the AI Act, which explain the purpose and scope
• Analogous DPIA methodology under GDPR Art.35, which shares structural similarities

The template below integrates all three.

The Seven Mandatory Assessment Sections

Art.27(1) specifies that the FRIA must address the following:

Section 1: Deployer Description and System Context

Document who is conducting the assessment and what system is being assessed.

Required elements:

• Legal identity and role of the deployer (public body, private entity providing public service, or other in-scope entity under Art.27(1))
• Name, version, and provider of the high-risk AI system
• Intended purpose as described in the provider's instructions
• Actual deployment context: where, by whom, and for which decisions will the system be used
• Whether the system is used jointly with other deployers, and if so, who

This section establishes the scope boundary. A system used differently from its intended purpose may face additional scrutiny — Art.26 requires deployers to use systems only for their intended purpose, and deviations affect the FRIA scope.

Section 2: Categories of Affected Persons

Identify who will be subject to decisions or significant influences from the AI system.

Required elements:

• Primary affected population (workers, applicants, students, loan seekers, benefit claimants, etc.)
• Whether any Annex III categories are especially vulnerable (children, persons with disabilities, minorities)
• Estimated volume: how many individuals per month or year
• Whether affected persons have meaningful awareness that an AI system influences decisions about them

Art.27 explicitly requires assessing impact on "natural persons" — this section makes that concrete. The EDPB has consistently emphasised in DPIA guidance that accurate data subject counts and category descriptions are foundational, and the same logic applies to FRIAs.

Section 3: Fundamental Rights at Stake

Map which EU Charter rights and secondary law rights may be affected.

Work through the following rights systematically:

For each right affected, note: (a) what the AI system does that creates the risk; (b) the severity (minor inconvenience, significant disadvantage, or severe harm); (c) whether affected persons can exercise effective recourse.

This section is the analytical core of the FRIA. Superficial mapping — checking boxes without substantive analysis — will not satisfy an NCA inspection.

Section 4: Likelihood and Severity Assessment

For each identified fundamental rights risk, assess:

Likelihood: How probable is it that the identified risk will materialise in practice?

• Low: System is rarely used for the affected use case
• Medium: System is regularly used, risk depends on operator decisions
• High: System structure makes risk near-certain for a class of affected persons

Severity: How serious is the impact if it does materialise?

• Minor: Inconvenience or delay with no lasting consequence
• Moderate: Disadvantage that affects important life decisions but is correctable
• Severe: Irreversible harm, denial of essential services, or deprivation of rights

Combined risk matrix: A likelihood × severity matrix helps prioritise which risks require mitigation measures before deployment.

Document the reasoning behind each assessment — do not just assign scores. NCAs reviewing FRIAs will look for substantive justification.

Section 5: Existing Safeguards and Mitigations

Identify what measures are already in place, distinguishing between:

Provider-side safeguards: These come from the AI system itself. The provider's Art.13 transparency notice and Art.14 human oversight mechanisms are relevant here. Review these documents before completing this section.

Deployer-side safeguards: These are within your control. They typically include:

• Human review protocols for AI-assisted decisions
• Appeal mechanisms for affected persons
• Staff training on the system's limitations
• Monitoring for discriminatory patterns in outputs
• Data minimisation and purpose limitation controls

Gap analysis: For each identified risk from Section 4, assess whether existing safeguards are adequate. A "high likelihood, severe severity" risk with no meaningful deployer-side safeguard is a clear deployment blocker.

Section 6: Residual Risks and Deployment Decision

After accounting for existing safeguards, document the residual risk profile:

• Which risks remain after safeguards are applied?
• Are any residual risks at a level that would make deployment incompatible with fundamental rights obligations?
• If residual risks are acceptable, what conditions or limitations should apply to deployment?

Art.27 does not explicitly require a "go / no-go" framing, but this is the logical conclusion of the assessment. If the residual risk profile reveals material rights violations without adequate mitigation, the FRIA documents the basis for not deploying — or for conditioning deployment on additional safeguards.

Document the deployment decision clearly, with reasoning.

Section 7: Stakeholder Consultation Record

Art.27(3) requires consultation with workers' representatives where relevant, and the AI Act's broader framework encourages involving affected communities in risk assessment. Document:

• Who was consulted during the FRIA process
• What concerns or objections were raised
• How those concerns were addressed (or why they were not)
• Whether affected persons or their representatives were informed of the assessment

This section satisfies both the Art.27 consultation requirement and creates an audit trail demonstrating good faith engagement.

Step-by-Step FRIA Process

Step 1: Scope Determination (Week 1)

Before drafting, confirm scope:

• Is this deployer an in-scope entity under Art.27(1)?
• Does the system appear in Annex III?
• Is this a genuinely high-risk use case (not an excluded research prototype or national security application)?

Assign a FRIA owner — a senior role with authority to delay or condition deployment based on FRIA findings.

Step 2: Document Collection (Week 1–2)

Collect from the provider:

• Art.13 transparency notice / instructions for use
• Any available technical documentation (summarised — you do not need the full Annex IV documentation)
• Provider's conformity assessment declaration (if available)
• Records of provider testing against Art.15 accuracy and robustness requirements

These documents inform Sections 1 and 5. Without them, the FRIA is incomplete.

Step 3: Rights Mapping (Week 2)

Complete Section 3 systematically. Do not limit the mapping to obvious risks. A recruitment AI's most visible risk is discrimination — but it may also affect Art.47 (right to effective remedy) if candidates have no meaningful appeal path, and Art.22 (linguistic diversity) if it penalises non-native language use.

Consider involving your Data Protection Officer. Where the system processes personal data, a DPIA under GDPR Art.35 may already be required, and the FRIA and DPIA can share significant content.

Step 4: Risk Assessment (Week 3)

Complete Sections 4 and 5. For high-severity risks, hold a structured workshop with operational staff who will actually use the system — they will identify practical risk scenarios that desk-based assessment misses.

Step 5: Stakeholder Consultation (Week 3–4)

If workers' representatives must be consulted under Art.27(3), allow adequate time for this. A consultation that runs for only 48 hours before a deployment deadline is unlikely to satisfy the requirement in spirit.

For public-sector deployers making decisions about citizens, consider proactive transparency: a public summary of the FRIA may build trust and reduce future scrutiny.

Step 6: Final Review and Sign-Off (Week 4)

The completed FRIA should be reviewed by:

• Legal (rights analysis and deployment decision)
• DPO (DPIA interface and data processing dimensions)
• Operational management (safeguards feasibility)
• Senior leadership (deployment decision accountability)

Sign-off should be documented, with the signing authority identified.

Step 7: Archive and Review Schedule

Once completed, the FRIA must be:

• Provided to national competent authorities upon request (Art.27(4))
• Retained for the operational lifetime of the AI system
• Reviewed and updated whenever the deployment context changes materially

Set a calendar reminder for annual review at minimum.

FRIA vs. DPIA: Integration Points

If your deployment also triggers a GDPR Art.35 DPIA, substantial content can be shared between the two assessments. However, they are not interchangeable:

Conducting both as integrated assessments — with shared sections on data processing, affected populations, and safeguards — reduces duplication while satisfying both requirements.

Documentation Standards

A FRIA is a legal document that may be reviewed by an NCA. The documentation standard should reflect this:

What NCAs will look for:

• Genuine engagement with identified risks, not checkbox compliance
• Evidence that safeguards are actually implemented, not just described
• Clear reasoning for the deployment decision
• Dated, signed records showing when the assessment was completed
• Records of any material updates

What will attract scrutiny:

• Generic, system-agnostic text that could apply to any deployment
• Risk assessments that identify severe risks but conclude no mitigation is needed
• Consultation records that show engagement only after deployment began
• Assessments completed after deployment rather than before it

What Comes Next in the FRIA Series

Post #3 covers FRIA and DPIA integration in depth — how to conduct a single combined assessment that satisfies both Art.27 and GDPR Art.35, including the EDPB's current position on scope alignment.

If you need to start the FRIA process now, the template above gives you the structural framework. The August 2, 2026 deadline leaves 59 days — enough time for a thorough assessment if started immediately.

sota.io is a European PaaS — GDPR-compliant infrastructure for teams building EU-compliant AI systems. Start deploying →