AI Impact Assessment Template (EU AI Act, 2026)

An AI impact assessment is the practice; the law is what it feeds. The EU AI Act, Regulation (EU) 2024/1689, never uses the phrase "AI impact assessment" — but a single structured assessment of who an AI system affects, what could go wrong, and what you have done about it is the input that populates three separate statutory duties at once: the Article 27 Fundamental Rights Impact Assessment (FRIA), the Article 9 risk-management system, and, where personal data is involved, a GDPR Article 35 Data Protection Impact Assessment (DPIA). Build one good assessment and you stop writing the same facts three times.

This template is deliberately broader than the statutory FRIA. The FRIA is a narrow, mandatory document required only of specific deployers (see below). The AI impact assessment here is a voluntary, general-purpose practice you can run on any AI system — high-risk or not, provider or deployer — to decide early whether a system is worth building, what controls it needs, and which formal documents it will eventually have to produce. Think of it as the front door that routes a system to the right statutory paperwork.

---

What this assessment is — and what it is not

A general AI impact assessment captures, in one place: the system's purpose, the people it affects, the risks to their health, safety and fundamental rights, the mitigations applied, and the oversight in place. It is a management practice, not a legal artefact in itself. It becomes legally load-bearing only when its content is lifted into a document the Act does require.

Three of those documents matter most, and they are not interchangeable:

The FRIA and the DPIA overlap but are not the same. Article 27(4) is explicit that a FRIA may cross-reference or incorporate the relevant parts of a DPIA already carried out — so doing the impact assessment once, in a shared structure, is exactly what the Act invites.

---

Who actually owes a FRIA (and who does not)

This is where most teams over-scope. The Article 27 FRIA is not a duty on every deployer of a high-risk system. It binds two groups: (1) deployers that are public bodies or private operators providing public services, and (2) deployers of two specific Annex III system types — creditworthiness/credit-scoring (Annex III 5(b)) and risk assessment and pricing in life and health insurance (5(c)). A private manufacturer deploying a high-risk recruitment tool does not, on that basis alone, owe a FRIA — though it still has deployer duties under Article 26, and the provider still owes the Article 9 risk-management system.

So the AI impact assessment serves two readers. The provider uses it to seed Article 9. The in-scope deployer uses it to seed the Article 27 FRIA. Everyone else uses it as good practice and as the evidence trail an authority will ask for under Article 26.

---

The dated-deadline caveat

For stand-alone high-risk systems (Annex III, Article 6(2)) the high-risk requirements — including the Article 9 risk-management system and the Article 27 FRIA — are tied to the high-risk application date. That date was originally 2 August 2026; the Digital Omnibus on AI — Regulation (EU) 2026/1744, published in the Official Journal on 24 July 2026 and in force since 27 July 2026 — moved it. The stand-alone high-risk Annex III date is now 2 December 2027, the single legal date. Running an AI impact assessment now, before that date bites, is the cheap move.

---

The template — fields to capture

1. System identification and purpose — name, version, owner; the intended purpose in plain terms; whether you are acting as provider (Art 16) or deployer (Art 26); preliminary risk classification under Articles 5 and 6.

2. Affected persons and groups — who is subject to or affected by the system's outputs (applicants, patients, customers, employees, the public); vulnerable groups; estimated numbers and frequency of use.

3. Risks to health, safety and fundamental rights — the specific harms: discrimination, loss of access to a service, safety failure, privacy intrusion, lack of redress. Map each to the right and the affected group. This is the column that flows straight into a FRIA.

4. Risk to data subjects (DPIA linkage) — personal data processed; lawful basis; the GDPR Article 35 DPIA reference where one exists or is required.

5. Mitigations — technical and organisational measures reducing each risk; residual risk after mitigation; what cannot be mitigated and the decision to proceed (or not).

6. Human oversight — the Article 14 oversight design (for providers) and the competent persons assigned to operate it (deployer duty, Article 26); how an overseer can intervene, override or stop.

7. Governance and review — owner, sign-off, review trigger (model change, new data, incident), and the link to the Article 9 risk-management record and, where applicable, the Article 27 FRIA.

---

Worked example: a city authority's benefits-triage tool

Stadtwerk Nordhafen, a municipal services body with about 240 employees serving a mid-sized German city, plans to deploy a high-risk system that triages housing-benefit applications (Annex III, access to essential public services). Because it is a public body deploying a high-risk system, it owes an Article 27 FRIA. Rather than start with the FRIA form cold, it runs the AI impact assessment first: it lists affected persons (roughly 9,000 applicants a year, including elderly and disabled residents), names the rights at stake (access to social assistance, non-discrimination, the right to a reasoned decision), and records the risk that the tool de-prioritises non-standard cases. It assigns two trained caseworkers as the Article 14 competent overseers under Article 26, who can override any triage outcome. It reuses its existing GDPR Article 35 DPIA for the data-protection section under Article 27(4). The completed assessment then populates the FRIA directly — one analysis, two documents, no contradiction between them.

---

How Confir helps

Confir runs the impact analysis as structured intake — purpose, affected persons, risks to fundamental rights, mitigations and Article 14 oversight — and routes the answers to the right output: the Article 27 FRIA for in-scope deployers, the Article 9 risk-management record for providers, and a cross-reference to the GDPR DPIA so the two never duplicate. Because the logic is deterministic and rule-based, the same facts produce the same routing and the same finding every time, with the rule that fired shown in plain English.

---

Related guides

• Article 27 fundamental rights impact assessment (FRIA)
• FRIA template
• FRIA vs DPIA — how they differ
• Article 9 risk management system
• Risk management plan template
• GDPR and EU AI Act intersection
• Deployer obligations under the EU AI Act