# AI Incident Report: [Short incident title]

> Report for an event in which the development, use or malfunction of an
> AI system caused harm (an AI incident) or could plausibly have caused
> harm (an AI hazard or near miss). Concepts follow the OECD paper
> "Defining AI incidents and related terms" (2024); the notification
> section lists the serious incident reporting duty in Article 73 of the
> EU AI Act (Regulation (EU) 2024/1689) for providers of high-risk AI
> systems. Replace every `[bracketed]` value and every row marked
> *Example*. This is a documentation format, not legal advice.

<!--
Guidance: How to use this template
- Open the report as soon as the incident is declared and update it as
  facts arrive; mark unconfirmed facts as such.
- Fill sections 1 to 5 first; regulators and leadership need them early.
- Decide on notifications (section 9) within hours, not after the root
  cause analysis; legal deadlines start when you become aware.
- Write the root cause without blame: describe conditions and decisions,
  not people's failings.
-->

| Field | Value |
|---|---|
| Incident ID | [AI-INC-2026-001] |
| Classification | [AI incident / AI hazard (near miss)] |
| Severity | [SEV1 / SEV2 / SEV3 / SEV4] |
| Status | [Open / Contained / Resolved / Closed] |
| Incident lead | [@incident-lead] |
| Report author | [@author] |
| Date detected | YYYY-MM-DD HH:MM [timezone] |
| Last updated | YYYY-MM-DD |
| Confidentiality | [Confidential / Legal privilege, if advised] |
| Related | [Model card], [AI risk assessment], [Postmortem], [Ticket link] |

## 1. Incident summary

<!-- Guidance: Three to five sentences a non-specialist can read: what happened, who was affected, how bad, current status. -->

[Summary.] *Example:* "Between 2 and 4 October the loan pre-screening
model rejected applicants from one postcode area at four times the usual
rate after an address-normalisation change upstream. About 1,150
applicants received automated rejections. The model was switched to
manual review on 4 October at 16:20 and affected applications are being
re-assessed."

## 2. System and version

<!-- Guidance: Identify exactly what was running. Without versions the root cause cannot be confirmed. -->

| Field | Value |
|---|---|
| AI system | [Name and purpose] |
| Model and version | [Model ID, version, training date] |
| Prompt or configuration version | [Version or commit] |
| Data pipeline version | [Version] |
| Deployment environment | [Production region, channel] |
| Our role | [Provider / Deployer / Both] |
| Risk classification | [Internal tier; EU AI Act category if assessed] |

## 3. Timeline

<!-- Guidance: Use one time zone. Include the change that introduced the problem, detection, escalation, containment and each notification. -->

| Time (UTC) | Event | Source |
|---|---|---|
| *Example:* 2026-10-01 22:10 | Upstream address normaliser v2.3 deployed | Change log CHG-8812 |
| *Example:* 2026-10-02 08:00 | Rejection rate for postcode area rises from 11% to 44% | Monitoring dashboard |
| *Example:* 2026-10-04 09:30 | Complaint from broker escalated to model owner | Ticket SUP-5531 |
| *Example:* 2026-10-04 11:05 | Incident declared SEV2 | Incident channel |
| *Example:* 2026-10-04 16:20 | Model routed to manual review (containment) | Feature flag |
| [time] | [event] | [source] |

## 4. Harm and affected parties

<!-- Guidance: Use broad harm types (OECD concepts): health or injury, disruption of critical infrastructure, violation of human or fundamental rights or legal obligations, harm to property, communities or the environment. Separate actual harm from plausible harm. -->

| Harm type | Actual or potential | Affected parties | Number | Description |
|---|---|---|---|---|
| *Example:* Rights and legal obligations (non-discrimination) | Actual | Loan applicants in postcode area | 1,150 | Wrongful automated rejection |
| *Example:* Economic harm | Potential | Same applicants | Up to 1,150 | Delayed access to credit |
| *Example:* Reputational harm | Actual | The organisation | n/a | Broker complaints, press enquiry |
| [Harm type] | [Actual / Potential] | [Parties] | [n] | [Description] |

Vulnerable groups affected: [yes or no, with description].

## 5. Severity

<!-- Guidance: Use your incident severity scale; record the reasoning so that later reviews can check it. -->

| Level | Definition used in this organisation |
|---|---|
| SEV1 | Death or serious harm to health, serious disruption of critical infrastructure, large-scale rights infringement, or likely regulatory reportable incident |
| SEV2 | Harm to many people or material financial loss; contained within days |
| SEV3 | Limited harm to few people; quick containment |
| SEV4 | Near miss with no harm; control weakness found |

Assigned severity: [SEV2], because [reasoning].

## 6. Detection

<!-- Guidance: Say how the incident was found and why earlier detection did not happen. -->

- **Detected by**: [monitoring alert / user complaint / staff / audit /
  external report].
- **Time from start to detection**: [n] hours.
- **Why not earlier**: *Example:* "Drift alerts are computed on the whole
  population; a shift in one area did not cross the global threshold."

## 7. Root cause analysis

<!-- Guidance: Classify the contributing causes. Most AI incidents have more than one: a data change plus a missing control plus a misuse. -->

| Cause area | Finding | Contributing or root |
|---|---|---|
| Data | *Example:* Normaliser change mapped 6% of addresses to an unknown postcode, a feature the model associates with high risk | Root |
| Model | *Example:* Model relies strongly on postcode; no monotonic or fairness constraint | Contributing |
| Deployment | *Example:* Upstream change not covered by model owner's change review | Contributing |
| Human oversight | *Example:* Automated rejections below score 0.3 not reviewed | Contributing |
| Misuse or attack | *Example:* None found | n/a |

The causal chain from change to harm is shown below.

```mermaid
flowchart LR
  A["Normaliser v2.3 deployed"] --> B["Unknown postcode values"]
  B --> C["Model scores drop"]
  C --> D["Automated rejections"]
  D --> E["Applicants harmed"]
```

## 8. Containment and remediation

<!-- Guidance: List what stopped the harm, then what fixes the cause, then what makes good the harm already done. -->

| ID | Action | Type | Owner | Status | Date |
|---|---|---|---|---|---|
| *Example:* C-01 | Route all decisions to manual review | Containment | [@ops-lead] | Done | YYYY-MM-DD |
| *Example:* R-01 | Roll back normaliser to v2.2 | Remediation | [@data-eng] | Done | YYYY-MM-DD |
| *Example:* R-02 | Re-assess 1,150 rejected applications manually | Redress | [@credit-ops] | In progress | YYYY-MM-DD |
| [ID] | [Action] | [Type] | [@owner] | [Status] | YYYY-MM-DD |

## 9. Notifications

<!-- Guidance: Record each notification decision, including decisions not to notify, with reasoning. Check all regimes that apply: AI Act, data protection, sector regulators, contracts. -->

| Recipient | Basis | Deadline | Sent | By | Reference |
|---|---|---|---|---|---|
| Executive and risk committee | Internal policy | [4 h for SEV1/SEV2] | YYYY-MM-DD | [@incident-lead] | [ref] |
| Market surveillance authority | EU AI Act Article 73, serious incident involving a high-risk AI system (provider; deployer where applicable) | Immediately once a causal link is established or reasonably likely; at the latest 15 days after awareness, 10 days in case of death, 2 days for a widespread infringement or serious critical infrastructure disruption (check the current text) | [n/a or date] | [@legal] | [ref] |
| Data protection authority | [GDPR Article 33, if a personal data breach] | [72 h] | [n/a or date] | [@dpo] | [ref] |
| Sector regulator | [Rule] | [Deadline] | [n/a or date] | [@compliance] | [ref] |
| Affected individuals | [Law, contract or policy] | [Deadline] | YYYY-MM-DD | [@comms] | [ref] |
| Provider or deployer counterpart | [Contract; AI Act cooperation duties] | [Deadline] | YYYY-MM-DD | [@vendor-manager] | [ref] |

Decision not to notify: [reasoning, approved by @name on YYYY-MM-DD].

## 10. Lessons learned

<!-- Guidance: What went well, what did not, where were we lucky. Keep each lesson specific. -->

- **Went well**: [for example, the feature flag allowed containment in
  under 10 minutes once decided].
- **Did not go well**: [for example, two days passed before a complaint
  reached the model owner].
- **Where we were lucky**: [for example, the drift affected one area only].

## 11. Corrective and preventive actions

<!-- Guidance: Each action needs an owner, a due date and a way to verify it. Link to your tracker. -->

| ID | Action | Owner | Due | Verification |
|---|---|---|---|---|
| *Example:* CAPA-01 | Add segment-level drift alerts by region | [@ml-ops] | YYYY-MM-DD | Alert fires in replay of this incident |
| *Example:* CAPA-02 | Add upstream feature producers to model change review | [@ml-governance] | YYYY-MM-DD | Change policy updated and trained |
| *Example:* CAPA-03 | Human review of all automated rejections near threshold | [@credit-ops] | YYYY-MM-DD | Sample audit |

## 12. Closure

<!-- Guidance: Close only when containment, redress and notifications are complete and actions are tracked. -->

| Role | Name | Decision | Date |
|---|---|---|---|
| Incident lead | [@name] | [Close / Keep open] | YYYY-MM-DD |
| System owner | [@name] | [Decision] | YYYY-MM-DD |
| Risk or compliance | [@name] | [Decision] | YYYY-MM-DD |

## Standard and licence note

Based on the AI incident and AI hazard concepts in the OECD paper
"Defining AI incidents and related terms" (OECD Artificial Intelligence
Papers, 2024), used as general concepts only, and on Article 73 of
Regulation (EU) 2024/1689 (EU legislative text, free to reuse). The text
is original wording; consult the current consolidated Regulation and
applicable guidance for binding deadlines. This is a documentation
format, not legal advice. Template licence: MIT.