# AI Impact Assessment

> Combines a GDPR Article 35 DPIA with the wider socio-technical questions expected by
> ISO/IEC 42005 and the NIST AI RMF *Map* function. If the system processes personal data
> and meets an Art. 35(3) trigger, sections 1–4 and 7–9 satisfy the Art. 35(7) minimum
> content. Complete **before** processing or deployment begins.

| Field | Value |
|---|---|
| System name / ID | |
| Assessment owner | |
| DPO consulted (Art. 35(2)) | Name / date |
| Version | |
| Date | |
| Review due | |

---

## 1. Systematic description of the processing

**What the system does, in plain language:**

**Decision or output it produces:**

**Who is affected** (customers, employees, applicants, public — include estimated numbers):

**Personal data categories processed:**

**Special category data (Art. 9)?** ☐ No ☐ Yes → condition relied on:

**Data sources** (first-party, third-party, scraped, synthetic, purchased):

**Retention period and justification:**

**Recipients / onward disclosures:**

**International transfers?** ☐ No ☐ Yes → mechanism (Art. 45 / 46 / 49) and transfer impact assessment reference:

**Our role:** ☐ Controller ☐ Joint controller ☐ Processor — and under the EU AI Act: ☐ Provider ☐ Deployer

---

## 2. Lawful basis and necessity

**Art. 6 lawful basis:** and why it applies:

**If legitimate interests — the three-part test:**

1. *Purpose:* what is the interest?
2. *Necessity:* why can't this be achieved with less data or a non-AI method?
3. *Balancing:* effect on the individual, their reasonable expectations, and safeguards applied.

**Art. 9(2) condition (if applicable):**

**Necessity and proportionality assessment.** Address explicitly:
- Could a simpler, non-AI approach achieve the same purpose?
- Is every data field actually needed (data minimisation)?
- Is the retention period the shortest workable one?

---

## 3. Automated decision-making (GDPR Art. 22)

| Question | Answer |
|---|---|
| Is the decision *solely* automated? | ☐ Yes ☐ No |
| Does it produce legal or similarly significant effects? | ☐ Yes ☐ No |
| If both yes — which Art. 22(2) exception applies? | ☐ Contract ☐ Law ☐ Explicit consent |
| Human intervention route | |
| How the subject expresses a view / contests | |
| Information given about the logic involved | |

> If a human reviews the output, record their authority and competence to overturn it.
> Review that cannot realistically change the outcome does not take you outside Art. 22.

---

## 4. Risks to individuals

For each risk: describe it, rate likelihood and severity, then record mitigation and residual risk.

| # | Risk | Affected group | Likelihood (L/M/H) | Severity (L/M/H) | Mitigation | Residual |
|---|---|---|---|---|---|---|
| 1 | Discriminatory outcomes across protected groups | | | | | |
| 2 | Inaccurate output leading to a wrong decision | | | | | |
| 3 | Lack of transparency / inability to explain | | | | | |
| 4 | Training-data extraction or membership inference | | | | | |
| 5 | Function creep beyond the stated purpose | | | | | |
| 6 | Over-reliance by human reviewers (automation bias) | | | | | |
| 7 | Exclusion or accessibility harm | | | | | |

---

## 5. Fairness and bias

**Protected characteristics considered:**

**Fairness metric(s) chosen and why** (e.g. demographic parity, equalised odds — note that these
can be mathematically incompatible; state the trade-off you accepted):

**Test results by subgroup:**

**Data used for bias testing, and the Art. 9(2) condition permitting it:**

**Threshold at which the system is withdrawn:**

---

## 6. Robustness, security and performance

- Accuracy / performance against the agreed benchmark:
- Behaviour on out-of-distribution inputs:
- Adversarial testing / red-teaming performed:
- Art. 32 security measures (access control, encryption, pseudonymisation):
- Model-specific threats considered (inversion, extraction, prompt injection, poisoning):

---

## 7. Transparency and rights

- How affected people are informed (Art. 13 / 14), and where the notice lives:
- If data was not collected from the subject, is Art. 14(5)(b) relied on? Justify:
- How access, rectification, erasure and objection requests are handled for this system:
- How model outputs about a person are corrected:

---

## 8. Measures to address the risks

| Risk # | Measure | Owner | Due | Status |
|---|---|---|---|---|

---

## 9. Outcome

**Residual risk after measures:** ☐ Low ☐ Medium ☐ High

**Art. 36 prior consultation required?** ☐ No ☐ Yes — if residual risk remains high, you must
consult the supervisory authority *before* processing.

**Decision:** ☐ Proceed ☐ Proceed with conditions ☐ Do not proceed

**Conditions:**

| Role | Name | Date |
|---|---|---|
| Assessment owner | | |
| DPO opinion | | |
| Accountable executive | | |

**Review triggers:** material change to purpose, data, model version, population affected, or
following any incident.