# AI Impact Assessment Template

**Organisation:** [ORGANISATION NAME]
**Owner:** [NAME / ROLE]
**Date:** [DATE]
**Version:** 1.0

---

## Purpose

Use this template to assess the impact of an AI system on the people it affects before you deploy it, and to keep that assessment current for as long as the system runs. It covers the ground shared by the main assessment formats in use today: the fundamental rights impact assessment (FRIA) required by Article 27 of the EU AI Act, the algorithmic impact assessments used in the public sector, and the voluntary AI impact assessments that mature governance programs run on any system that makes or informs consequential decisions about people.

The output is a single document your organisation can stand behind: what the system does, who it affects, what could go wrong for those people, how likely and how severe each harm is, what you have done to reduce it, and who accepted the residual risk. Completed assessments become audit evidence for regulators, customers, and certification bodies.

---

## How to Use

1. Run the screening questionnaire in Part 1 to determine whether an assessment is legally required, contractually required, or recommended as best practice. Record the screening outcome even when no assessment is needed.
2. If an assessment is required or recommended, complete Sections A to I in Part 2 in order. Sections A to C are factual groundwork; do not start rating risks until they are complete.
3. Involve the right people: the business owner of the system, a data protection or privacy lead, a security representative, and someone who understands the affected population. One person filling in every field alone is a warning sign.
4. Rate every identified risk using the likelihood and severity scales in Section D, then record mitigations and re-rate the residual risk in Section F.
5. Consult affected groups or their representatives where practicable and record the consultation in Section G.
6. Obtain sign-off in Section I before the system goes live. For EU AI Act Article 27 assessments, notify the market surveillance authority as required.
7. Revisit the assessment whenever a review trigger in Section H fires, and at least annually. An impact assessment describes a system at a point in time; the system will not stay still.

---

## Part 1: Screening. When Is an Impact Assessment Required?

### Mandatory triggers

**EU AI Act, Article 27 (fundamental rights impact assessment).** Certain deployers must complete a FRIA before first use of a high-risk AI system:

- Bodies governed by public law, and private entities providing public services (for example education, healthcare, housing, social services), deploying any high-risk system listed in Annex III, except systems for critical infrastructure management (Annex III, point 2).
- Any deployer, public or private, of a high-risk system used to evaluate creditworthiness or establish a credit score for natural persons (Annex III, point 5(b)). Banks and other lenders fall here.
- Any deployer of a high-risk system used for risk assessment and pricing in life and health insurance (Annex III, point 5(c)). Insurers fall here.

Article 27 requires the assessment to describe the deployer's processes in which the system will be used, the period and frequency of use, the categories of natural persons and groups likely to be affected, the specific risks of harm to those groups, the human oversight measures, and the measures to be taken if the risks materialise, including internal governance and complaint arrangements. The completed assessment must be notified to the market surveillance authority, and the AI Office is developing a template questionnaire to support compliance. Sections A to I of this document cover all of these elements.

**Timing.** Following the digital omnibus package formally adopted at the end of June 2026, the EU AI Act's high-risk obligations, including the Article 27 FRIA duty, apply from 2 December 2027 for stand-alone Annex III systems, and from 2 August 2028 for AI embedded in Annex I regulated products. Do not read the deferral as a reason to wait: an assessment takes weeks to do well, and systems deployed now will still be running when the obligations bite.

**GDPR, Article 35 (data protection impact assessment).** If the system processes personal data in a way likely to result in high risk to individuals (large-scale profiling, automated decision-making with legal or similar effects, systematic monitoring), a DPIA is required regardless of the AI Act. Under Article 27(4) of the AI Act, a FRIA complements a DPIA rather than replacing it: run them together and cross-reference, rather than duplicating content.

**Public sector directives.** Canada's Directive on Automated Decision-Making requires federal institutions to complete an Algorithmic Impact Assessment before deploying automated decision systems. Similar obligations exist or are emerging in public sector procurement rules in several jurisdictions; check the rules that apply to your public sector customers as well as to you.

**A note on US state laws.** Several US states have moved away from mandating impact assessments. Colorado's SB 189 (signed May 2026, effective 1 January 2027) repealed and replaced the 2024 Colorado AI Act, dropping the impact assessment mandate, the deployer risk-management program requirement, and the duty of care in favour of transparency and disclosure duties. Texas (TRAIGA) and Illinois (HB 3773), both effective 1 January 2026, regulate prohibited uses and AI-driven employment discrimination rather than mandating assessments. Fewer US mandates does not mean lower expectations: anti-discrimination liability under existing law is unchanged, and a documented impact assessment remains your best evidence of reasonable conduct.

### Voluntary and best-practice triggers

Complete an assessment even where no law requires it when any of the following apply:

- The system makes or materially informs consequential decisions about individuals: hiring, promotion, termination, lending, insurance, housing, healthcare, education, benefits, or access to essential services.
- The system processes biometric data, infers emotions, or profiles people at scale.
- Affected groups include children, patients, benefit recipients, job seekers, or others with limited ability to contest outcomes.
- Your organisation is implementing ISO/IEC 42001, which expects AI system impact assessments as part of the management system (ISO/IEC 42005 provides dedicated guidance), or is following the NIST AI Risk Management Framework, where impact identification sits in the Map function.
- A customer contract, procurement process, or insurer requires evidence of AI impact assessment.
- The deployment is novel for your organisation, high profile, or likely to attract media or regulator attention.

### Screening questionnaire

Answer every question. One yes is enough to proceed to Part 2.

| # | Screening question | If yes |
|---|--------------------|--------|
| 1 | Are we a public body, or a private entity providing a public service, deploying a high-risk (Annex III) AI system in the EU? | FRIA required under EU AI Act Article 27 before first use |
| 2 | Does the system evaluate creditworthiness, establish credit scores, or set risk-based pricing for life or health insurance for natural persons in the EU? | FRIA required under EU AI Act Article 27 before first use |
| 3 | Does the system process personal data in a way likely to create high risk to individuals? | DPIA required under GDPR Article 35; use this template to cover the AI-specific ground alongside it |
| 4 | Does the system make or materially inform consequential decisions about individuals? | Assessment strongly recommended; may be required by sector rules or contracts |
| 5 | Does the system affect children or other vulnerable groups, use biometric data, or infer emotions? | Assessment strongly recommended |
| 6 | Is an impact assessment required by a contract, procurement rule, public sector directive, or certification program (for example ISO/IEC 42001)? | Assessment required by that instrument |

**Screening outcome record**

| Field | Response |
|-------|----------|
| Screening completed by | [NAME / ROLE] |
| Date of screening | [DATE] |
| Outcome | [Assessment required (legal) / required (contractual) / recommended / not required] |
| Legal bases or triggers identified | [e.g. EU AI Act Art. 27; GDPR Art. 35; contract clause] |
| Rationale (especially if not required) | [WHY] |
| Re-screening date or trigger | [DATE / EVENT] |

---

## Part 2: The Assessment

### Section A: System Description and Intended Use

| Field | Response |
|-------|----------|
| System name and internal ID | [NAME / ID] |
| Provider / vendor and model or product version | [PROVIDER, MODEL, VERSION] |
| Deployer business owner | [NAME / ROLE] |
| Intended purpose (as stated by the provider) | [PURPOSE] |
| Our actual use case, in plain language | [USE CASE] |
| Business processes in which the system will be used | [PROCESSES, e.g. loan origination step 3 of 6] |
| Decisions or outputs the system produces | [OUTPUTS, and whether they are advisory or determinative] |
| Period and frequency of use | [e.g. continuous; approx. 2,000 decisions per month] |
| Geographic scope of deployment | [COUNTRIES / REGIONS] |
| Deployment status | [Planned / pilot / production, with dates] |
| EU AI Act risk classification and rationale | [Tier, cross-reference to classification record] |
| Provider documentation received | [Instructions for use, transparency information, model documentation] |
| Related assessments | [DPIA reference, security review, vendor assessment] |

### Section B: Affected Persons and Groups

List every category of natural persons the system could affect, directly or indirectly. Include people the system makes decisions about, people whose data it processes, and people affected by aggregate outcomes (for example a community affected by a resourcing model).

| Group | How they are affected | Approximate scale | Vulnerability factors |
|-------|-----------------------|-------------------|-----------------------|
| [e.g. Loan applicants] | [Decision subject: credit decision informed by model score] | [e.g. 24,000 per year] | [Financial stress; low financial literacy segment] |
| [e.g. Existing customers] | [Data subjects: repayment history used as training data] | [e.g. 300,000] | [None identified] |
| | | | |

Consider at minimum: employees and job applicants, customers and applicants, children and young people, elderly people, people with disability, people from non-English-speaking backgrounds, First Nations people, people experiencing financial hardship, and any group historically disadvantaged in the domain where the system operates.

### Section C: Data and Model Inputs

| Field | Response |
|-------|----------|
| Input data categories | [e.g. transaction history, application form fields, bureau data] |
| Special or sensitive categories present | [e.g. health, biometric, ethnicity; or none] |
| Personal data processed | [Yes / no; if yes, cross-reference the DPIA] |
| Data provenance | [Internal systems, third-party sources, data brokers] |
| Training data (if known) | [What the model was trained on, per provider documentation] |
| Known gaps in representativeness | [Populations under-represented in the data] |
| Potential proxies for protected attributes | [e.g. postcode, first name, employment gaps] |
| Data quality controls | [Validation, freshness, error rates] |
| Retention and deletion | [Periods, and vendor retention of prompts or inputs] |
| Cross-border data flows | [Where inputs and outputs are stored and processed] |

### Section D: Risks to Fundamental Rights and Individuals

Identify specific risks of harm to the groups listed in Section B. Work through each prompt category below; not every category will apply to every system, but record "considered, not applicable" rather than leaving categories silent.

**Prompt categories**

- **Discrimination and equality:** could outcomes differ unjustifiably across groups defined by protected attributes or their proxies? Could the system entrench historical bias present in training data?
- **Privacy and data protection:** could the system expose, infer, or misuse personal information? Could inputs be retained or reused by the provider?
- **Economic harm:** could an incorrect or unfair output cost a person money, credit access, insurance cover, a job, or a livelihood?
- **Procedural fairness:** can affected people understand that AI was involved, obtain an explanation, contest the outcome, and reach a human with authority to change it?
- **Other rights and interests:** dignity, freedom of expression, access to essential services, physical or psychological safety.

**Rating scales**

| Rating | Likelihood | Severity |
|--------|-----------|----------|
| Low | Conceivable but not expected during the system's lifetime | Inconvenience or minor detriment, easily reversed |
| Medium | Could plausibly occur; isolated cases expected | Meaningful detriment to rights, finances, or opportunities; recoverable with effort |
| High | Expected to occur without intervention; systematic pattern possible | Serious or irreversible harm; loss of essential services, livelihood, or legal rights |

Risk level: High if either dimension is High; Medium if both are Medium or one is Medium and one Low; otherwise Low. Override the formula with judgement where scale of exposure warrants it, and record why.

**Risk register**

| Risk ID | Risk description | Rights / interests affected | Groups affected | Likelihood | Severity | Risk level |
|---------|------------------|-----------------------------|-----------------|------------|----------|------------|
| R-01 | Model trained on historical lending data scores applicants from postcodes with high migrant populations lower than identical applicants elsewhere; postcode acts as a proxy for ethnicity | Non-discrimination; economic participation | Loan applicants in affected postcodes | Medium | High | High |
| R-02 | Staff paste free-text case notes containing applicant health details into the vendor tool; vendor retains prompts for 18 months under default settings | Privacy and data protection | All applicants whose cases are processed | High | Medium | High |
| R-03 | Applicants receive an automated decline with no plain-language reason and no stated route to human review, so errors go uncorrected | Procedural fairness; effective remedy | Declined applicants | Medium | Medium | Medium |
| [R-04] | [Description] | [Rights] | [Groups] | [L] | [S] | [Level] |

The example rows above show the expected quality bar: name the mechanism of harm, not just the theme. "Bias risk" is not a risk description; "postcode acts as a proxy for ethnicity in credit scoring" is.

### Section E: Human Oversight Measures

Describe how humans oversee the system in practice, per the provider's instructions for use and your own operating procedures.

| Field | Response |
|-------|----------|
| Oversight model | [Human-in-the-loop / human-on-the-loop / human-in-command] |
| Which outputs a human reviews, and when | [e.g. all declines reviewed before issue; approvals sampled at 5%] |
| Who performs oversight | [ROLE(S), team size, reporting line] |
| Competence and training of overseers | [Training completed, refresh cycle] |
| Information available to the overseer | [Score, key factors, input data, confidence indicators] |
| Authority to override | [Can the overseer change the outcome? Recorded how?] |
| Automation bias controls | [Override rates monitored; blind re-review sampling; rotation] |
| Escalation path | [Who is called when the system misbehaves, and how fast] |
| Kill switch / withdrawal | [How the system is paused or withdrawn, and who decides] |

### Section F: Mitigation and Residual Risk

For every risk rated Medium or High in Section D, record the mitigation, the owner, and the residual rating after mitigation. Residual High risks must be escalated to the approver in Section I with an explicit accept-or-stop decision.

| Risk ID | Mitigation measures | Owner | Due date | Residual likelihood | Residual severity | Residual level |
|---------|--------------------|-------|----------|--------------------|-------------------|----------------|
| R-01 | Remove postcode and derived geo-features from model inputs; quarterly disparate-impact testing across protected groups with a documented threshold; retrain vendor model contractually required if threshold breached | Head of Credit Risk | [DATE] | Low | High | Medium |
| R-02 | Enterprise agreement with zero-retention configuration; DLP rule blocking health terms in prompts; staff retraining on data classification | CISO | [DATE] | Low | Medium | Low |
| [R-03] | [Measures] | [OWNER] | [DATE] | [L] | [S] | [Level] |

**Complaints and redress arrangements**

| Field | Response |
|-------|----------|
| How affected persons are told AI is used | [Notice text, location, timing] |
| Complaint channel | [Channel, response-time commitment] |
| Route to human review of a decision | [How requested, who reviews, timeframe] |
| Remedies available | [Decision reversal, re-assessment, compensation policy] |
| Governance of this system | [Committee or forum that owns escalations, meeting cadence] |

### Section G: Consultation Record

Consult affected groups, their representatives, or subject-matter experts where practicable. For public sector deployments this is increasingly expected; for all deployers it is the cheapest way to find harms you did not think of.

| Date | Stakeholder / group | Method | Input received | Response / change made |
|------|--------------------|--------|----------------|------------------------|
| [DATE] | [e.g. Consumer advocacy body] | [Workshop / survey / interview] | [Summary] | [What changed, or why nothing changed] |
| | | | | |

### Section H: Review Triggers

Re-open this assessment when any of the following occurs. Tick the triggers you will monitor and name the monitoring mechanism.

- [ ] Material change to the system, model version, or provider
- [ ] Change to the use case, decision threshold, or population the system is applied to
- [ ] New data sources or input categories added
- [ ] Monitoring shows drift, rising override rates, or disparate outcomes beyond threshold
- [ ] A complaint, incident, or near-miss involving this system
- [ ] Relevant legal or regulatory change (for example AI Act guidance, sector rules)
- [ ] Scheduled review date reached (at least annually)

| Field | Response |
|-------|----------|
| Review owner | [NAME / ROLE] |
| Monitoring mechanism | [e.g. model monitoring dashboard, incident register feed] |
| Next scheduled review | [DATE] |

### Section I: Approval and Sign-Off

The assessment is not complete until the accountable executive has made an explicit decision: approve deployment, approve with conditions, or do not deploy. Record conditions verbatim and track them to closure.

**Decision:** [Approve / approve with conditions / do not deploy]

**Conditions (if any):** [CONDITIONS AND CLOSURE DATES]

| Role | Name | Decision / contribution | Signature | Date |
|------|------|-------------------------|-----------|------|
| Assessment author | [NAME] | Prepared assessment | | |
| Privacy / data protection lead | [NAME] | Reviewed Sections C, D, F | | |
| Security lead | [NAME] | Reviewed Sections C, E | | |
| Legal / compliance | [NAME] | Confirmed legal triggers and obligations | | |
| Accountable executive | [NAME] | Final decision | | |

**Regulatory notification (EU AI Act Article 27 assessments)**

| Field | Response |
|-------|----------|
| Market surveillance authority notified | [AUTHORITY, DATE, REFERENCE] |
| Template / questionnaire version used | [e.g. AI Office template version, when available] |
| Exemption relied on (if any) | [e.g. Article 46(1) derogation, with rationale] |

---

*Provided free by [Aona AI](https://aona.ai). Aona discovers every AI tool in use across your organisation, monitors what data flows into them, and keeps your AI inventory audit-ready.*