# AI incident log template.

URL: https://levystreet.com/resources/ai-incident-log-template/
Updated: 2026-10-19

Free AI incident log template: 16 fields, a four-level severity scale, near misses and the New Zealand privacy breach notification test for AI incidents.

## Short answer

An AI incident log is a running record of every time an AI system produced a harmful, wrong or unexpected result, or nearly did: what happened, the impact, whether personal information was involved, the cause, the fix and who closed it. This template has 16 fields, a four-level severity scale and the Privacy Act 2020 test for notifying the Privacy Commissioner.

- Log near misses as well as failures; they are cheaper lessons.
- Record the model, prompt version and inputs so the incident can be reproduced.
- A privacy breach likely to cause serious harm must be notified as soon as practicable.
- The Privacy Commissioner asks for notification ideally within 72 hours.

Set the log up before you need it. An incident log started after the first serious problem is missing the near misses that would have warned you. Keep it in a shared spreadsheet or your ticketing system, with one row per incident and restricted access, because entries may contain personal information.

## The AI incident log template

| # | Field | What to record |
|---|---|---|
| 1 | Incident ID | AI-2026-001 and so on |
| 2 | Date and time found | When it was noticed, and when it is thought to have started |
| 3 | Reported by | Name and role |
| 4 | System and version | Tool or system, model name, prompt or configuration version |
| 5 | What happened | Facts only: input, output, action taken, who saw it |
| 6 | Category | Wrong output used; data exposure; unintended action; prompt injection; outage; cost spike; unfair treatment; near miss |
| 7 | Severity | S1 to S4, from the scale below |
| 8 | People affected | Number, and whether customers, staff or others |
| 9 | Personal information involved | Yes or no; what kind |
| 10 | Privacy breach assessment | Serious harm likely? Decision, who decided, when; date the Privacy Commissioner and individuals were notified |
| 11 | Containment | What was done immediately to stop it and limit harm |
| 12 | Root cause | Prompt, source data, permissions, model change, process gap or human error |
| 13 | Fix and prevention | What changed so it does not happen again |
| 14 | Owner | Who is responsible for closing it |
| 15 | Date closed | And who approved closure |
| 16 | Lessons and links | Risk register entry updated; policy or training changes |

## Severity scale

| Severity | Description | Response |
|---|---|---|
| S1 Critical | Harm to people, a privacy breach likely to cause serious harm, or significant money lost | Contain within the hour; tell the owner and a director immediately; run the notification test |
| S2 High | Wrong output or action reached a customer or third party; personal information exposed | Contain the same day; owner investigates within two working days |
| S3 Moderate | Internal error with rework or delay; nobody outside affected | Log and fix within a week |
| S4 Low or near miss | Caught before use, or no effect | Log; review in the monthly summary |

## The New Zealand notification test

Run this for any incident involving personal information. A notifiable privacy breach is one it is reasonable to believe has caused, or is likely to cause, serious harm. The Act lists factors to consider, including what has been done to reduce the harm, how sensitive the information is, the nature of the harm, who has obtained the information and whether it is protected by security measures ([Privacy Act 2020](https://www.legislation.govt.nz/act/public/2020/31/en/latest/), sections 112 and 113).


- We have recorded what personal information was involved and whose.
- We have considered each of the Act's serious-harm factors and written down our reasoning.
- If serious harm is likely, we notify the Privacy Commissioner as soon as practicable; the Commissioner asks for this ideally within 72 hours of becoming aware ([OPC](https://www.privacy.org.nz/responsibilities/privacy-breaches/notify-us/)).
- We notify affected people as soon as practicable, unless an exception in the Act applies.
- If the incident involved a cyber attack, we have considered reporting it to the [NCSC](https://www.ncsc.govt.nz/report/).


Failing to notify the Commissioner of a notifiable breach without reasonable excuse is an offence with a fine of up to $10,000 (section 118). Regulated entities have extra expectations: in October 2026 the Reserve Bank and the FMA set out supervisory expectations on cyber and AI risk, including that boards know where AI is used and who is accountable ([RBNZ](https://www.rbnz.govt.nz/news-and-events/news/2026/10/rbnz-and-fma-outline-supervisory-expectations-on-cyber-and-ai-risks)).

## How to use the log


1. **Make reporting easy and blame-free.** One link or email address, and a clear message that early reports are welcome.
2. **Preserve evidence.** Keep the conversation, inputs, outputs and logs. Do not delete them, even if embarrassing.
3. **Contain first, investigate second.** Stop the harm, then work out why. Our guide to [AI incident response](/engineering/ai-incident-response/) covers containment for live systems.
4. **Find the root cause.** Look for the prompt, source document, permission or model change that let it happen; "the AI got it wrong" is not a root cause.
5. **Close with a fix and update the register.** Link every incident to an entry in your [AI risk register](/resources/ai-risk-register-template/).
6. **Review monthly.** Count incidents by category and severity, and look for repeats.


## Filled-in example

Illustrative example: a 30-person Christchurch recruitment agency uses an AI assistant to draft candidate summaries for clients, following the [candidate communication drafting](/industries/recruitment/candidate-communication-drafting/) pattern.

| Field | Entry |
|---|---|
| ID, found | AI-2026-014; 14 October, 10:20 am |
| What happened | A summary emailed to Client B included a line about a different candidate's salary expectations, carried over from an earlier draft in the same chat |
| Category, severity | Data exposure; S2 |
| People affected | One candidate; one client contact |
| Personal information | Yes: name and salary expectation |
| Breach assessment | Recipient confirmed deletion in writing within two hours; information moderately sensitive; no sign of further disclosure. Serious harm judged unlikely by the privacy officer on 14 October; reasoning recorded; not notified. Candidate told and apologised to |
| Root cause | Consultants reused one long chat for several candidates |
| Fix | New chat per candidate; review step added to check every name in the summary |
| Closed | 21 October, by the privacy officer; risk R1 updated |

## Common mistakes

- **Logging only big failures.** Near misses are where you learn cheaply.
- **Blaming the model.** "AI hallucinated" is not a root cause. Ask what let the error reach someone.
- **Deleting the evidence.** You cannot assess harm or fix the cause without it.
- **Skipping the notification reasoning.** Even when you decide not to notify, write down why.
- **Never closing the loop.** An incident without a fix and a register update will recur.

## Next step

Make sure your [audit logs](/engineering/ai-audit-logs/) capture enough to fill fields 4 and 5 for any system you run, and train staff with [managing AI mistakes and escalation](/learn/managing-ai-mistakes-and-escalation/). If you want someone else watching live systems and handling incidents, see [managed AI operations](/services/managed-ai-operations/).

## Questions people ask

### What counts as an AI incident?

Any time an AI system produced or did something harmful, wrong or unintended that was used or acted on, or would have been if someone had not caught it. Examples: an incorrect answer sent to a customer, personal information shown to the wrong person, an agent taking an action nobody approved, a prompt injection, or a sudden spike in usage costs.

### Do AI privacy incidents have to be reported in New Zealand?

If a privacy breach is one it is reasonable to believe has caused, or is likely to cause, serious harm, the Privacy Act 2020 requires you to notify the Privacy Commissioner and affected people as soon as practicable. The Privacy Commissioner asks for notification ideally within 72 hours. Failing to notify the Commissioner without reasonable excuse is an offence with a fine of up to $10,000.

### Should near misses go in the AI incident log?

Yes. A near miss, such as a wrong draft caught by a reviewer, shows where controls are working and where the system is weak, without anyone being harmed. Logging them is how you spot patterns early. Mark them severity 4 so they do not crowd out serious incidents in reports.

### Who should own the AI incident log?

One named person, usually whoever owns AI governance or the privacy officer in a smaller business. Anyone should be able to add an entry, but the owner assigns severity, makes sure each incident is closed with a fix, and links it to the risk register. In a small business the same person often owns the AI policy.


## Sources

- [Privacy Act 2020](https://www.legislation.govt.nz/act/public/2020/31/en/latest/)
- [Notify us of a privacy breach](https://www.privacy.org.nz/responsibilities/privacy-breaches/notify-us/)
- [Report a cyber security incident](https://www.ncsc.govt.nz/report/)
- [RBNZ and FMA outline supervisory expectations on cyber and AI risks](https://www.rbnz.govt.nz/news-and-events/news/2026/10/rbnz-and-fma-outline-supervisory-expectations-on-cyber-and-ai-risks)

Published by Levy Street (https://levystreet.com), Wellington, New Zealand.