# AI System Impact Assessment: [AI system name]

> Impact assessment of an AI system on individuals, groups of people and
> society, covering benefits as well as harms, across the system's life
> cycle. Structure aligned with ISO/IEC 42005:2025, *Information
> technology, Artificial intelligence, AI system impact assessment*
> (edition 1, published May 2025), and usable as the impact assessment
> record an ISO/IEC 42001 AI management system expects. It is not a GDPR
> data protection impact assessment (DPIA) nor an EU AI Act fundamental
> rights impact assessment (FRIA); see section 1.4. Replace every
> `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- Run the assessment early (at design), then update it at each life cycle
  stage and whenever a trigger in section 10 occurs. A single assessment
  signed at launch and never revisited does not meet the intent.
- Look at people outside the organisation first: users, people the system
  makes decisions about, bystanders, communities. Organisational risk
  (reputation, cost) belongs in the AI risk assessment.
- Record benefits as carefully as harms, so the decision in section 11
  weighs both.
- Involve people with different viewpoints, including domain experts and,
  where practical, representatives of affected groups (section 4.2).
- ISO/IEC 42005 is a copyrighted guidance standard; this template uses its
  topics in original words. Obtain the standard for its full guidance.
-->

## Document control

<!-- Guidance: Identify the system version and life cycle stage assessed, and who is accountable for the result. -->

| Field | Value |
|---|---|
| Document ID | [AIIA-001] |
| AI system and version | [Name] [version] |
| Life cycle stage | [Inception / Design and development / Verification and validation / Deployment / Operation and monitoring / Retirement] |
| Assessment type | [Initial / Stage update / Change-triggered / Periodic / Post-incident] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Assessment owner | [@owner] |
| Assessment team | [@product], [@ml-lead], [@legal], [@domain-expert], [@ethics-reviewer] |
| Last updated | YYYY-MM-DD |
| Next review due | YYYY-MM-DD |
| Related records | [AI risk assessment], [DPIA], [FRIA], [Model card], [AI system card], [AIMS impact assessment procedure] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| System owner | [@name] | [Proceed / Proceed with conditions / Do not proceed] | YYYY-MM-DD |
| AI governance lead | [@name] | [Decision] | YYYY-MM-DD |
| Independent reviewer | [@name] | [Decision] | YYYY-MM-DD |
| Accountable executive (if high residual impact) | [@name] | [Decision] | YYYY-MM-DD |

## Revision history

<!-- Guidance: Each life cycle stage and each trigger produces a revision. State what prompted it. -->

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | Initial assessment at design stage |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Updated before deployment with validation results |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* Reassessed after extension to a new country |

## Contents

<!-- Guidance: Keep aligned with the headings below. -->

1. [Scope and context of the assessment](#1-scope-and-context-of-the-assessment)
2. [AI system description](#2-ai-system-description)
3. [Intended uses and reasonably foreseeable misuse](#3-intended-uses-and-reasonably-foreseeable-misuse)
4. [Stakeholders and affected parties](#4-stakeholders-and-affected-parties)
5. [Impact identification](#5-impact-identification)
6. [Evaluation of severity and likelihood](#6-evaluation-of-severity-and-likelihood)
7. [Mitigation measures](#7-mitigation-measures)
8. [Residual impacts](#8-residual-impacts)
9. [Documentation, communication and reporting](#9-documentation-communication-and-reporting)
10. [Monitoring and review triggers](#10-monitoring-and-review-triggers)
11. [Conclusion and decision](#11-conclusion-and-decision)
12. [Glossary and references](#12-glossary-and-references)

## 1. Scope and context of the assessment

<!-- Guidance: Define what is assessed, why now, against which organisational criteria, and how this assessment relates to other assessments. -->

### 1.1 Purpose and trigger

[Why this assessment is being done now.] *Example:* Initial assessment
for a new AI system that ranks applicants for a municipal social housing
waiting list, at the design stage, before data collection.

### 1.2 Boundaries

| In scope | Out of scope |
|---|---|
| *Example:* The ranking model, its inputs, the case-worker interface, the appeal process | The housing allocation policy itself (set by the council) |
| *Example:* Effects on applicants, case workers, landlords and the local community | Internal IT infrastructure risks (covered by security risk assessment) |

### 1.3 Organisational context and criteria

| Item | Value |
|---|---|
| Organisation role | [Developer / Provider / Deployer / Developer and deployer] |
| AI policy and objectives | [Link to AI policy] |
| Impact criteria and scales | [Section 6 scales, approved by AI governance on YYYY-MM-DD] |
| Acceptance thresholds | *Example:* No residual impact rated "High" without executive approval; no "Critical" accepted |
| Applicable laws and standards | *Example:* National housing law, GDPR, EU AI Act (likely high-risk: access to essential public services) |

### 1.4 Relationship to other assessments

| Assessment | Purpose | Relationship to this one |
|---|---|---|
| AI risk assessment ([NIST AI RMF] or ISO/IEC 23894 based) | Risks to the organisation and its objectives | Impacts rated High feed its risk register |
| GDPR DPIA (Article 35) | Risks to rights and freedoms from personal data processing | Shares data flow description; this assessment covers non-data impacts too |
| EU AI Act FRIA (Article 27) | Deployer's legal duty for certain high-risk systems | This assessment can supply evidence; the FRIA has its own required content and notification |
| ISO/IEC 42001 AIMS | Management system requiring an impact assessment process | This document is the record of that process for this system |

## 2. AI system description

<!-- Guidance: Describe the system enough for an outside reviewer to understand how it could affect people: purpose, functions, data, models, outputs, human involvement and deployment environment. -->

| Attribute | Description |
|---|---|
| Purpose | *Example:* Prioritise applications by assessed housing need |
| Functions | *Example:* Scores each application 0 to 100 and explains the top three factors |
| AI techniques | *Example:* Gradient-boosted model plus rule-based eligibility checks |
| Inputs | *Example:* Household size, income, current housing condition, medical priority flags, time on list |
| Outputs | *Example:* Priority score and band (A to D) shown to case workers |
| Decision role | *Example:* Decision support; case worker makes the final ranking decision |
| Data sources | *Example:* Application form, council records, health assessments with consent |
| Deployment environment | *Example:* Council case management system; 25 case workers |
| Scale | *Example:* About 9,000 applications per year |
| Third-party components | *Example:* None; model trained in-house |

```mermaid
flowchart LR
  A["Applicant form"] --> E["Eligibility rules"]
  E --> M["Priority model"]
  R["Council records"] --> M
  M --> C["Case worker review"]
  C --> D["Ranking decision"]
  D --> N["Notice to applicant"]
  N --> AP["Appeal"]
  AP --> C
```

## 3. Intended uses and reasonably foreseeable misuse

<!-- Guidance: State the intended use precisely, then think about how the system could be used differently, by whom, and with what effect. Include unintended but predictable use, not only malicious misuse. -->

| ID | Use | Type | Users | Notes |
|---|---|---|---|---|
| U-01 | *Example:* Prioritise applications for case-worker review | Intended | Case workers | Core use |
| U-02 | *Example:* Report waiting list statistics to council | Intended | Analysts | Aggregated only |
| MU-01 | *Example:* Case workers accept scores without review because of workload | Foreseeable misuse | Case workers | Automation bias |
| MU-02 | *Example:* Scores reused to screen tenants for private landlords | Foreseeable misuse | Third parties | Purpose creep |
| MU-03 | *Example:* Applicants gaming inputs once factors are known | Foreseeable misuse | Applicants | Integrity |

## 4. Stakeholders and affected parties

<!-- Guidance: Identify everyone who could be affected, directly or indirectly, including groups who never use the system. Note vulnerable groups. -->

### 4.1 Affected parties

| ID | Party | Relationship | Vulnerability factors |
|---|---|---|---|
| SP-01 | *Example:* Applicants | Subject of the output | Low income, possible disability, language barriers |
| SP-02 | *Example:* Children in applicant households | Indirectly affected | Cannot represent themselves |
| SP-03 | *Example:* Case workers | Users | Workload pressure |
| SP-04 | *Example:* Current tenants and neighbourhoods | Indirectly affected | Community composition |
| SP-05 | *Example:* Society / public trust in public services | Indirect | n/a |

### 4.2 Consultation

| Who was consulted | Method | Date | Key input |
|---|---|---|---|
| *Example:* Tenant advocacy organisation | Workshop | YYYY-MM-DD | Concern about applicants with irregular income |
| *Example:* Case workers (6) | Interviews | YYYY-MM-DD | Need to see why a score is high or low |
| *Example:* Disability rights adviser | Review of draft | YYYY-MM-DD | Medical flags must be optional and explained |

## 5. Impact identification

<!-- Guidance: For each affected party, list potential benefits and harms to individuals, groups and society. Consider fairness, privacy, safety, autonomy, access to services, economic effects, environment, and accountability. -->

### 5.1 Benefits

| ID | Benefit | Parties | Level | Evidence or assumption |
|---|---|---|---|---|
| B-01 | *Example:* More consistent prioritisation across case workers | SP-01 | Group | Pilot showed 30% less variation between workers |
| B-02 | *Example:* Faster processing, shorter wait for a decision | SP-01, SP-03 | Individual | Assumed 2 weeks saved per application |
| B-03 | *Example:* Better data on unmet housing need for planning | SP-05 | Society | Aggregated reporting |

### 5.2 Harms

| ID | Potential harm | Parties | Level | Impact area | Cause |
|---|---|---|---|---|---|
| H-01 | *Example:* Lower scores for applicants with irregular income patterns | SP-01, SP-02 | Group | Fairness, access to services | Training data reflects past decisions |
| H-02 | *Example:* Applicants unable to understand or challenge their ranking | SP-01 | Individual | Accountability, autonomy | Opaque scores |
| H-03 | *Example:* Exposure of sensitive health information | SP-01 | Individual | Privacy | Medical flags in inputs |
| H-04 | *Example:* Case workers deskilled or over-reliant | SP-03 | Group | Autonomy, quality of service | Automation bias |
| H-05 | *Example:* Reduced public trust if errors become public | SP-05 | Society | Trust | Errors without explanation |
| H-06 | *Example:* Scores reused outside purpose | SP-01 | Individual | Privacy, discrimination | MU-02 |

## 6. Evaluation of severity and likelihood

<!-- Guidance: Rate each harm before mitigation using scales agreed in advance. Severity considers scale (how many), scope (how deep) and reversibility. -->

### 6.1 Scales

| Score | Severity | Likelihood |
|---|---|---|
| 1 | Minimal: minor inconvenience, easily reversed | Rare: not expected in the system's life |
| 2 | Moderate: noticeable effect, reversible with effort | Unlikely |
| 3 | Significant: material effect on rights, access or wellbeing | Possible |
| 4 | Severe: serious, hard to reverse, many people | Likely |
| 5 | Critical: irreversible or affecting fundamental rights at scale | Almost certain |

Impact rating $I = S \times L$, banded as Low (1 to 4), Medium (5 to 9),
High (10 to 15) and Critical (16 to 25).

### 6.2 Inherent rating

| Harm | Severity | Likelihood | Rating | Band | Rationale |
|---|---|---|---|---|---|
| H-01 | 4 | 4 | 16 | Critical | *Example:* Historic data shows lower allocation for self-employed applicants |
| H-02 | 3 | 4 | 12 | High | No explanation in current design |
| H-03 | 4 | 2 | 8 | Medium | Access controls exist but data is sensitive |
| H-04 | 3 | 3 | 9 | Medium | Workload is high |
| H-05 | 3 | 2 | 6 | Medium | |
| H-06 | 4 | 2 | 8 | Medium | No technical barrier to export |

## 7. Mitigation measures

<!-- Guidance: For each significant harm, state the measures, owner and deadline, and how effectiveness will be checked. Prefer design changes over notices. -->

| ID | Harm | Measure | Type | Owner | Due | Effectiveness check |
|---|---|---|---|---|---|---|
| MT-01 | H-01 | *Example:* Remove income volatility feature; fairness constraint on selection rate by employment type | Design | @ml-lead | YYYY-MM-DD | Selection rate ratio >= 0.9 on validation |
| MT-02 | H-02 | *Example:* Plain-language factor explanations in notices; appeal route | Design, process | @product | YYYY-MM-DD | Usability test with 10 applicants |
| MT-03 | H-03 | *Example:* Medical flags as yes/no category only; role-based access | Technical | @security | YYYY-MM-DD | Access review |
| MT-04 | H-04 | *Example:* Mandatory written reason when accepting band A or D; training | Process | @ops-lead | YYYY-MM-DD | Override and reason audit |
| MT-05 | H-06 | *Example:* Purpose limitation in data sharing agreements; no export function | Organisational | @legal | YYYY-MM-DD | Annual audit |

## 8. Residual impacts

<!-- Guidance: Re-rate each harm after mitigation and state whether the residual level is acceptable under the criteria in 1.3. -->

| Harm | Residual severity | Residual likelihood | Rating | Band | Acceptable? | Justification |
|---|---|---|---|---|---|---|
| H-01 | 3 | 2 | 6 | Medium | Yes | Fairness tests pass; monitored monthly |
| H-02 | 2 | 2 | 4 | Low | Yes | |
| H-03 | 4 | 1 | 4 | Low | Yes | |
| H-04 | 3 | 2 | 6 | Medium | Yes, with monitoring | Override audit |
| H-05 | 2 | 2 | 4 | Low | Yes | |
| H-06 | 4 | 1 | 4 | Low | Yes | |

Net assessment of benefits against residual harms: [*Example:* benefits
B-01 and B-02 are material for about 9,000 households a year; residual
harms are Medium or below with active monitoring. The team recommends
proceeding with conditions in section 11.]

## 9. Documentation, communication and reporting

<!-- Guidance: State where the assessment is stored, who receives it, and what is communicated to affected parties. -->

| Audience | What is shared | Channel | When |
|---|---|---|---|
| AI governance board | Full assessment | Governance meeting | Each version |
| Case workers | Summary, limitations, override duties | Training | Before go-live |
| Applicants | How the system is used, how to ask for review | Notice and website | At application |
| Public | Summary of the assessment | Council transparency register | At deployment |
| Regulators | On request, plus FRIA where required | Formal submission | As required |

Records are retained for [the system's life plus 10 years] in [document
management system], with version history.

## 10. Monitoring and review triggers

<!-- Guidance: Define indicators that show whether impacts are as assessed, and events that require reassessment at any life cycle stage. -->

### 10.1 Indicators

| Indicator | Target | Frequency | Owner |
|---|---|---|---|
| *Example:* Selection rate ratio by employment type | >= 0.9 | Monthly | @ml-lead |
| *Example:* Case-worker override rate | 5% to 25% (outside range investigated) | Monthly | @ops-lead |
| *Example:* Appeals upheld | < 10% | Quarterly | @product |
| *Example:* Complaints mentioning the system | Trend | Quarterly | @complaints-lead |

### 10.2 Reassessment triggers

| Trigger | Stage |
|---|---|
| New model version or retraining with new data | Development, operation |
| New input feature or data source | Development |
| Use in a new population, region or purpose | Deployment |
| Indicator outside target for two consecutive periods | Operation |
| Serious incident or upheld complaint about discrimination | Operation |
| Change in applicable law | Any |
| Decision to retire the system | Retirement: assess effects of withdrawal and data disposal |

## 11. Conclusion and decision

<!-- Guidance: Summarise the outcome, the conditions attached, and the decision of the accountable person. -->

| Item | Value |
|---|---|
| Overall residual impact | [Low / Medium / High] |
| Recommendation | [Proceed / Proceed with conditions / Redesign / Do not proceed] |
| Conditions | *Example:* MT-01 to MT-04 complete before go-live; monthly fairness report for the first 6 months |
| Decision by | [@accountable-person] on YYYY-MM-DD |
| Dissenting views recorded | [Summary or "none"] |

## 12. Glossary and references

<!-- Guidance: Define terms the readers may not share and list related documents. -->

| Term | Meaning in this document |
|---|---|
| Affected party | A person or group whose interests may be changed by the AI system, whether or not they use it |
| Impact | An effect, positive or negative, of the AI system on individuals, groups or society |
| Foreseeable misuse | Use other than intended that can be predicted from human behaviour or incentives |
| Residual impact | Impact remaining after mitigation measures |
| Selection rate ratio | Rate of favourable outcomes for a group divided by that of the most favoured group |

References: ISO/IEC 42005:2025; ISO/IEC 42001:2023; ISO/IEC 23894:2023;
[organisation AI policy]; [DPIA]; [FRIA].

## Standard and licence note

Structure aligned with ISO/IEC 42005:2025, AI system impact assessment
(edition 1, May 2025), for the topics an impact assessment record covers:
scope, system description, uses and misuse, affected parties, benefits
and harms, evaluation, mitigation, residual impact, documentation and
life cycle review. This template is original text written for this
collection and reproduces no text from the standard; obtain the standard
for its full guidance. It does not replace a GDPR DPIA or an EU AI Act
FRIA. Template licence: MIT.