Skip to content
EU AI ActFRIAArticle 27IAMADPIApublic sector

FRIA Under Article 27 for Public Bodies

Who must perform a fundamental rights impact assessment, the six elements it contains, how it relates to a GDPR DPIA, and how the Dutch IAMA fits.

Landfall ยท Published 5 September 2026

The fundamental rights impact assessment, usually shortened to FRIA, is the AI Act duty that lands squarely on public bodies. Providers write the technical file; deployers in the public sector write the FRIA. For a Dutch reader the immediate question is how it relates to two documents they probably already produce: the GDPR data protection impact assessment and the IAMA. This article sets out who owes the FRIA, what Art. 27 says it must contain, and how to keep the three instruments from becoming three documents that disagree.

Who must perform one

Art. 27(1) names three groups of deployers of an Annex III high-risk system:

  • bodies governed by public law;
  • private entities providing public services;
  • any deployer of a system in Annex III point 5(b), creditworthiness assessment, or 5(c), risk assessment and pricing in life and health insurance.

The first two are about who you are. The third is about what the system does, and it binds a private bank or insurer as much as a ministry. One exclusion applies to all three: systems intended for the area in Annex III point 2, critical infrastructure, are out.

The duty falls on the deployer, not the provider. A municipality that buys a benefits scoring system from a vendor owes the FRIA for its own use of it. The vendor's documentation is an input, not a substitute, although Art. 27(2) does allow reliance on an assessment the provider has already carried out where it covers the same ground.

What it contains

Art. 27(1) lists six elements, and it is easiest to treat them as headings:

  1. Processes. A description of the deployer's processes in which the system will be used, in line with its intended purpose.
  2. Period and frequency. How long, and how often, the system is intended to be used.
  3. Affected people. The categories of natural persons and groups likely to be affected.
  4. Specific risks of harm. The risks to those categories, taking into account the information the provider supplies under Art. 13.
  5. Human oversight. The oversight measures as actually implemented, following the instructions for use.
  6. Response measures. What will be done if the risks materialise, including internal governance and complaint mechanisms.

Three procedural rules follow. Under Art. 27(2) the assessment is done before first use, and must be updated when any element changes or is no longer current. Under Art. 27(3) the deployer notifies the market surveillance authority of the results, using the template the AI Office is to develop under Art. 27(5). The notification can be waived in the urgency situations of Art. 46(1). And under Art. 27(4), where a GDPR DPIA already discharges part of the work, the FRIA complements it rather than repeating it.

How it relates to the DPIA

A DPIA under GDPR Art. 35 asks whether processing of personal data is likely to result in a high risk to the rights and freedoms of natural persons, and what measures address that risk. A FRIA asks about the impact of using a high-risk AI system on fundamental rights as a whole. The overlap is large: both describe the process, the people affected, the risks and the safeguards.

The differences matter in two directions. The FRIA reaches rights the DPIA does not centre: non-discrimination, human dignity, access to an effective remedy, the rights of the child. And the DPIA carries duties the FRIA lacks: the necessity and proportionality analysis of Art. 35(7)(b), the advice of the data protection officer under Art. 35(2), and the possibility of prior consultation with the supervisory authority under Art. 36 when residual risk stays high.

The practical answer is one assessment record with a section map. Each section states which Art. 27(1) element and which Art. 35(7) element it satisfies. Where a section serves only one instrument, it says so. That way the FRIA and the DPIA cannot drift apart, and a reviewer can see at a glance what is missing.

Where the Dutch IAMA fits

The IAMA, the Impact Assessment Mensenrechten en Algoritmes, was developed for the Dutch government and is structured in four parts: Waarom (why), Wat (what), Hoe (how) and Mensenrechten (fundamental rights). The Dutch House of Representatives has pressed for it to be mandatory for government algorithms that affect people. Its fundamental-rights sweep is at least as wide as Art. 27 and in places wider.

Mapped onto Art. 27(1): Waarom covers the processes and the purpose, elements (a) and (b); Wat covers the data, the affected people and the risks, elements (c) and (d); Hoe covers oversight and governance, elements (e) and (f); and Mensenrechten deepens element (d). Two gaps remain. The IAMA has no step corresponding to the Art. 27(3) notification to the market surveillance authority, so that stays a separate action even where an IAMA exists. And the IAMA's wording should be checked against the official text before you rely on any published summary of its structure, including this one.

The Algoritmeregister, the national register, expects a reference to the impact assessment. One record for IAMA, FRIA and DPIA gives it one reference.

A worked example

The fictional municipality of Kessemer is about to use a vendor's model to prioritise home visits for its youth care team. Annex III point 5(a): essential public services. The municipality is a body governed by public law, so Art. 27 applies.

The team opens one assessment record. Section 1 describes the intake process and where the score enters it (element (a), IAMA Waarom). Section 2 records that the model runs on every new referral for a twelve-month pilot (element (b)). Section 3 lists families with children, and separately families with a migration background, because the training data over-represents them (element (c), DPIA Art. 35(7)(a)). Section 4 works through discrimination, family life and the rights of the child, using the vendor's Art. 13 accuracy figures per subgroup (element (d), IAMA Mensenrechten). Section 5 names the two senior caseworkers who review every score before a visit is scheduled, with their authority to override (element (e), and GDPR Art. 22 evidence). Section 6 sets out the complaint route and the monthly override review (element (f)). The DPO signs the DPIA sections. The results are notified to the market surveillance authority. The register entry cites the record's identifier.

How Landfall helps

Landfall derives whether Art. 27 applies from three answers: the Annex III area, the deployer role and the kind of body, and prints that basis on the FRIA row of the report. For a public-sector project the generated work item for the assessment carries the instruction that one record can serve the IAMA, the FRIA and the DPIA, with the section map, and the evidence checklist asks for that record's identifier because the register expects it. The two places the instruments do not overlap are stated rather than glossed. Landfall does not write the assessment; it tells you it is due and what it must cover.

Explore the underlying obligations

This article is grounded in the obligations Landfall maps from source legal text. Browse them yourself:

Questions this article answers

Who must perform a FRIA?
Deployers of an Annex III high-risk system that are bodies governed by public law or private entities providing public services, and any deployer of a creditworthiness or life and health insurance system (Annex III points 5(b) and 5(c)). Systems in Annex III point 2, critical infrastructure, are excluded.
When must the FRIA be done?
Before the first use of the system (Art. 27(2)). For later similar uses the deployer may rely on an earlier assessment or the provider's own, but must update it when any element changes. The results are notified to the market surveillance authority using the AI Office template (Art. 27(3)).
Does a DPIA replace a FRIA?
No. Art. 27(4) says that where a GDPR Art. 35 DPIA already covers part of the ground, the FRIA complements it. The two can share one record, but the FRIA's scope, all fundamental rights, is wider than data protection.
Can the Dutch IAMA serve as the FRIA?
In practice a single assessment record can serve the IAMA, the FRIA and the DPIA, provided every Art. 27(1) element is answered and the Art. 27(3) notification is done separately. The IAMA has no step for that notification, so it stays a distinct action.

Sources

For informational purposes only. This guide is summary-level, informational writing โ€” not legal advice, not a risk score, and not regulatory approval. It does not create an attorney-client relationship. Always consult qualified legal counsel for compliance decisions about your specific product.

What Landfall Is NOT

Critical Boundaries

Understanding these boundaries is essential before using this product. Misuse of this tool for purposes outside its scope may create legal, regulatory, or commercial risk for your organization.

NOT Legal Advice

This product does not provide legal advice and does not create an attorney-client relationship.

Interpretations are informational analysis, not legal counsel. Always consult qualified legal professionals for compliance decisions.

NOT a Risk Score

We do not quantify, calculate, or certify your compliance risk level.

No numerical risk rating, compliance percentage, or safety score. Risk assessment requires human judgment about your specific context.

NOT Runtime Enforcement

This is a planning and mapping tool, not a runtime enforcement system.

Does not integrate with your production systems. Does not block, filter, or enforce compliance in real-time. Implementation is your responsibility.

NOT Regulatory Approval

Using this tool does not mean you are compliant with any regulation.

No certification, seal of approval, or compliance guarantee. Regulators will evaluate your actual implementation, not your use of this tool.

NOT Authoritative Interpretation

Our interpretations are not binding and may differ from regulatory guidance.

Only regulators and courts provide authoritative interpretation. Our analysis reflects our reading of requirements, which may be incomplete or incorrect.

NOT a Safe Harbor

This tool does not shield you from enforcement actions or liability.

Documentation of your process is valuable, but does not constitute a legal defense. Compliance is ultimately your organization's responsibility.

NOT an AI Compliance Agent

AI features assist analysis but do not make compliance decisions for you.

AI-generated interpretations require human review and approval. Automated suggestions are starting points, not final answers.

NOT Complete Coverage

We do not cover all regulations, all obligations, or all jurisdictions.

Regulatory landscape is vast and evolving. Gaps in our coverage do not mean those requirements don't apply to you.

What This Tool IS:

  • A structured workflow for mapping regulatory requirements to implementation tasks
  • A documentation system for compliance decisions (audit trail)
  • A collaboration platform for compliance, legal, and engineering teams
  • An informational resource for understanding regulatory obligations