Does a municipality need a FRIA? Article 27 EU AI Act

Yes, a municipality must conduct a FRIA (fundamental rights impact assessment) as soon as it deploys a high-risk AI system from Annex III of the AI Act, except for critical infrastructure (Annex III, point 2). For new systems that applies from 2 December 2027; for systems the municipality already uses before that date, only once the system is significantly changed, and by 2 August 2030 at the latest (Article 111(2)). What a FRIA is and how to complete it is covered in FRIA under the AI Act: what it is, who needs one and how to complete it. This page is about how a municipality or other public body organises it in practice, all the way up to the board.

Municipalities do not usually struggle with the idea that AI can affect rights. They struggle with the moment the abstract legal question turns into an operational one. The procurement is done, the vendor says the system is compliant, the policy team wants to go live, and someone asks the uncomfortable question: have we actually done the FRIA yet?

That question matters because under Article 27, the FRIA is not a provider task. It is a deployer obligation. For municipalities, public bodies, and other public sector teams using high-risk AI, it is one of the clearest moments where the EU AI Act says: the vendor’s file is not enough, you need your own assessment.

When a municipality actually needs a FRIA

The short version is not “always” and not “never.” It depends on two things.

First, the AI system must be a high-risk AI system referred to in Article 6(2), which means the system falls within the Annex III logic rather than the product safety route.

Second, the deployer must fall into one of the categories named in Article 27. That includes bodies governed by public law, private entities providing public services, and deployers of high-risk AI systems referred to in points 5(b) and 5(c) of Annex III.

For municipalities, the first category is the key one. A municipality is a public body. So if it deploys a qualifying Annex III high-risk AI system, the FRIA is in play.

There is one important exclusion written directly into Article 27(1): high-risk AI systems intended to be used in the area listed in Annex III point 2 are excluded from the FRIA obligation. That is the critical infrastructure carve-out.

So the municipality question is never just “are we a public authority?” It is “are we a public authority deploying a qualifying Annex III high-risk AI system outside the Annex III point 2 exception?”

If that classification work is still fuzzy, use the risk assessment tool and compare the use case against the categories explained in our guide to Annex III of the EU AI Act.

From when does the FRIA apply to a municipality?

For a new system, from 2 December 2027. Since the Digital Omnibus (Regulation (EU) 2026/1744) the Annex III high-risk rules, and with them Article 27, apply from that date.

For a system the municipality already uses before 2 December 2027, a transition rule applies. Under Article 111(2) the regulation catches such a system only once its design is significantly changed. For systems intended for use by public authorities there is a backstop: the provider and the municipality must comply by 2 August 2030 at the latest. For an algorithm that has been running for years, 2 December 2027 is therefore not automatically the deadline. Do not simply wait for 2030 though: a significant change, such as a new model or a new purpose, brings the date forward.

Public sector teams should stop treating FRIA as a late-stage form

A FRIA is not the last document before go-live. It is supposed to shape the deployment decision.

That is obvious when you read Article 27 carefully. The assessment must be performed prior to deploying the high-risk AI system. In plain English, before first use.

If a municipality starts the FRIA after procurement is locked, after workflows are designed, and after internal ownership has already been assigned, the assessment quickly becomes defensive. The team is no longer asking whether the deployment should change. It is asking how to justify the deployment already chosen.

That is exactly the wrong mindset for public sector AI.

What Article 27 requires in practice

Article 27(1) lists six elements. The best way to read them is not as six legal boxes, but as six operational questions.

1. In which municipal process will the AI system be used?

The FRIA must describe the deployer’s processes in which the system will be used, in line with the intended purpose.

That means you need a real process description, not a product description.

If the AI system is used in social benefits work, where exactly does it enter the chain? Intake? Prioritisation? Risk scoring? Human review? Escalation? Final decision support?

If the system is used in HR, is it screening applicants, ranking candidates, or supporting interviews?

A FRIA that only repeats vendor marketing language is already weak.

2. How often and for how long will it be used?

Article 27 also requires a description of the period and frequency of use.

This sounds administrative, but it is not trivial. A tool used once a month in a pilot has a different risk profile from a system used daily at scale in municipal operations.

3. Which people and groups are likely to be affected?

This is where many municipalities get too generic. “Residents” is not enough.

The FRIA should identify affected categories concretely. Benefit applicants, job applicants, parents, students, people in debt support trajectories, residents in vulnerable neighbourhoods, or municipal employees can all be affected in different ways.

And indirect impact matters too. If a system is used to prioritise cases, the people whose cases are deprioritised may be just as affected as the people actively flagged.

4. What are the specific risks of harm?

This is the core analytical step. Article 27(1)(d) requires an assessment of the specific risks of harm likely to affect the identified persons or groups, taking into account the provider information supplied under Article 13.

That means the municipality should not guess blindly, but it also cannot stop at the provider’s paperwork. Provider documentation is input, not a substitute for context-specific analysis.

For public sector teams, the rights lens is usually broader than privacy alone. Non-discrimination, access to services, human dignity, due process, and access to remedy often matter just as much as data protection.

5. How is human oversight actually implemented?

Article 27 asks for a description of human oversight measures in line with the instructions for use.

This is where Article 14 and our human oversight guide become highly relevant. Public sector teams should name who reviews outputs, what competence those people have, when they can override the system, and what happens if they disagree with it.

A municipal FRIA becomes flimsy very quickly if “human oversight” is written as a generic sentence rather than a real workflow.

6. What happens if risks materialise?

Article 27(1)(f) requires measures to be taken if risks materialise, including internal governance arrangements and complaint mechanisms.

This is where public bodies often expose whether they are serious. If a resident wants to challenge an AI-supported outcome, is there a route? If the system shows subgroup bias after deployment, who acts? If the provider’s assumptions no longer fit reality, who pauses the system?

Without those answers, the FRIA is not really finished.

FRIA and DPIA are not the same, but they should speak to each other

Public sector teams often ask whether the FRIA replaces the DPIA. It does not.

Article 27(4) says that where an obligation is already met through a GDPR Article 35 DPIA, the municipality may cross-refer in the FRIA to the relevant sections of that DPIA or include the relevant parts. Since the Digital Omnibus that cross-reference is written into the text.

That is a useful legal instruction. Privacy is not the whole public sector rights picture, but it is usually part of it. So the practical move is to connect the two assessments instead of running them in different silos.

If your municipality already has a solid DPIA process, build the FRIA around it. Then expand beyond privacy into discrimination, procedural fairness, accessibility, explainability, human oversight, and complaint pathways. The DPIA vs FRIA comparison is useful if your team is still mixing the two up.

Typical municipal use cases that deserve immediate review

Not every AI tool in local government is automatically high-risk. But some categories should make your team sit up straight.

Access to essential public services

If a municipality uses AI in processes affecting access to essential public services or benefits, Annex III analysis should happen early. This is one of the clearest zones where fundamental rights risk is real.

HR and recruitment

Municipal recruitment, candidate ranking, or workforce management tools can fall within the employment-related high-risk category. Public bodies sometimes forget that “internal” HR use can still trigger major AI Act duties.

Education and youth-related decision support

Where municipal functions intersect with education allocation, assessment, or youth services, the rights analysis should be careful and concrete, especially where minors or vulnerable groups are involved.

Public order, enforcement, and risk scoring

Anything that looks like risk classification, prioritisation of enforcement action, or profiling in a public authority setting deserves immediate legal and rights scrutiny.

In all these cases, the Annex III classification and the FRIA should be examined before operational enthusiasm outruns legal discipline.

A practical FRIA workflow for municipalities

If you want a workable municipal process, keep it simple and serious.

1. Classify the use case. Confirm whether the AI system is high-risk under Article 6 and Annex III.
2. Request provider documentation early. Ask for the Article 13 information, intended purpose, known limitations, testing evidence, and required oversight measures.
3. Describe the municipal workflow. Map where the system enters the process and where humans intervene.
4. Identify affected groups and risks. Do not stop at privacy. Assess discrimination, access, due process, and practical harm.
5. Connect FRIA and DPIA. Where personal data is involved, the assessments should reinforce each other.
6. Define governance and challenge routes. Decide who owns the system, who pauses it, who handles complaints, and how updates are reviewed.
7. Use a real template. Our FRIA generator and FRIA template can structure the work instead of forcing the team to improvise.

The FRIA in the boardroom

A FRIA that lives only inside a specialist team rarely changes anything. The decision to deploy a system, not deploy it or deploy it differently ultimately lies with the board. This is how a municipality takes the FRIA there.

A team that goes beyond privacy

Privacy specialists do not own the FRIA. A workable core team consists of a lawyer, a data specialist who understands the model, a policy adviser who knows the domain and, where possible, an ethicist and a representative of residents, for example from a neighbourhood or client council. Recital 96 of the AI Act expressly mentions involving representatives of affected groups, independent experts and civil society organisations, in particular when AI is used in the public sector.

From fundamental rights to a risk map

For each fundamental right, set the system's operation against the possible harm. Is someone categorised? Do they get a label that is hard to contest? Score each risk on impact (how serious is the harm if it goes wrong?) and likelihood (how likely is it to go wrong?). The result is a colour coding that board members understand at once. Every red risk needs a measure: data quality checks, bias tests, a human mandate to reverse decisions, explanations for residents.

Let the model fail, on paper

The most important work happens in the conversation, not in the template. Work through scenarios in which the system is wrong. An example: a single father with irregular income is wrongly flagged as a fraud risk and temporarily loses income support. How does the municipality spot that error? What emergency brake does the resident have? Such scenarios show whether human oversight and the complaints route actually work.

What the executive board gets to see

Not a forty-page report, but an overview: the risk map, the measures taken and the residual risks. That allows the municipal executive, or the management of another public body, to take a real decision. If a system still scores red on non-discrimination, postponing or pausing until additional bias tests are done is a legitimate outcome of the FRIA.

What becomes public

The AI Act does not require a municipality to publish the full FRIA. What does apply:

• the municipality notifies the results to the market surveillance authority (Article 27(3));
• as a public authority, it registers itself and the use of a high-risk system from Annex III in the EU database (Article 49(3)), with a summary of the findings of the FRIA (Annex VIII, Section C, point 4). For law enforcement, migration, asylum and border control, that registration takes place in a secure, non-public section (Article 49(4)).

Publication in a national register, such as the Dutch government's algorithm register, is an additional national route to explain in plain language which risks exist and which safeguards were taken.

Where municipalities usually get this wrong

The first mistake is treating the FRIA as vendor paperwork. It is not. The provider can support it, but the deployer owns it.

The second mistake is starting too late. A FRIA begun after every substantive implementation choice has already been made will mostly produce compliance theatre.

The third mistake is reducing the analysis to privacy only. For public sector deployments, rights such as non-discrimination, fair treatment, and effective remedy are often just as important.

The fourth mistake is keeping human oversight vague. If nobody can explain who overrides the system, then oversight is probably not real.

The fifth mistake is forgetting that complaints and governance matter after go-live, not only before it.

The sixth mistake is token participation. A consultation evening with five residents is not an embedded resident voice. Involve a representative group in more than one phase and show what was done with their input.

The seventh mistake is one template for everything. A model for youth care needs different safeguards from a tool for parking permits. The format may be the same, the content never.

Where to go next

If your team needs the broader legal background, start with FRIA under the AI Act: what it is, who needs one and how to complete it. If you need a more operational starting point, use the FRIA generator or download the FRIA template. If you are unsure whether a specific use case falls under Annex III, submit it to the case check.

And if you are still at the earlier stage of figuring out whether your use case is even high-risk, do that first. A messy FRIA often starts with a messy classification exercise.