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, 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).
- 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.
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).
How to use the log
- Make reporting easy and blame-free. One link or email address, and a clear message that early reports are welcome.
- Preserve evidence. Keep the conversation, inputs, outputs and logs. Do not delete them, even if embarrassing.
- Contain first, investigate second. Stop the harm, then work out why. Our guide to AI incident response covers containment for live systems.
- 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.
- Close with a fix and update the register. Link every incident to an entry in your AI risk register.
- 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 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 capture enough to fill fields 4 and 5 for any system you run, and train staff with managing AI mistakes and escalation. If you want someone else watching live systems and handling incidents, see managed AI operations.
Sources
- Privacy Act 2020, New Zealand Legislation, version as at 1 October 2026
- Notify us of a privacy breach, Office of the Privacy Commissioner, accessed 19 October 2026
- Report a cyber security incident, NCSC New Zealand, accessed 20 October 2026
- RBNZ and FMA outline supervisory expectations on cyber and AI risks, Reserve Bank of New Zealand, 15 October 2026
Written by the Levy Street team in Wellington. Last updated 19 October 2026.