A standard security incident form asks which hosts and accounts were affected, but an AI incident report also has to say which model version answered, what it was given, what it did and who was harmed. Without those fields, investigators cannot reproduce the failure, legal cannot judge whether a regulatory report is due, and the same fault returns after the next model change. This template is a fill-in incident report for AI systems, including chat assistants, decision-support models and AI agents with tools. It covers identification, the AI configuration at the time, inputs and outputs, harm and severity, the EU AI Act serious incident test, root cause and corrective actions. It is for incident managers, AI system owners, AI governance and legal teams, and it complements your security incident process rather than replacing it.
How to use this template
- Replace text in square brackets, such as [Organisation], [AI incident lead] and [X hours], with your own terms and values.
- Open a report as soon as an AI incident or near miss is suspected; incomplete fields are expected at first. Mark each field as confirmed, suspected or unknown.
- If the incident also involves a cyber attack or a personal data breach, run your security incident and data breach processes in parallel and cross-reference the ticket numbers. See the Security Incident Report Form Template.
- Have legal review section 6 against every regime that applies to you; the EU AI Act deadlines quoted are from the consolidated text and should be confirmed against the official text before relying on them.
- Store completed reports where they can be found by system, model version and harm type, so that trends become visible.
1. Purpose and definitions
This template records AI incidents at [Organisation] so that they can be contained, reported where required, analysed and prevented from recurring. For this template:
- AI incident: an event in which the development, use or malfunction of an AI system [Organisation] provides or deploys led, or plausibly led, to harm to people, property, the environment, operations, legal rights or [Organisation]'s obligations.
- AI near miss: an event that could have caused such harm but was stopped by a control, a person or chance. Near misses are recorded on the same form.
- Serious incident (EU AI Act): under Article 3(49), an incident or malfunction of an AI system that directly or indirectly leads to death or serious harm to a person's health; serious and irreversible disruption of the management or operation of critical infrastructure; infringement of Union law obligations intended to protect fundamental rights; or serious harm to property or the environment.
The OECD published a common reporting framework for AI incidents in February 2025 with 29 criteria, intended to make reports comparable across jurisdictions. Organisations that report to public authorities or incident databases should map these fields to it.
2. Scope and triggers
Open a report when any of the following occur in an AI system listed in the [AI register]:
| Trigger | Examples |
|---|---|
| Harmful or unlawful output | Discriminatory decision, defamatory statement, unsafe medical or financial advice acted on, prohibited content generated |
| Unauthorised or unintended action | Agent deletes data, sends email, makes a payment or changes access outside its intended task |
| Data exposure | Model reveals personal data, secrets, system prompt or another customer's content |
| Manipulation | Successful prompt injection, jailbreak, data or memory poisoning, malicious tool or model supply chain component |
| Material performance failure | Accuracy collapse after a model change, hallucinated facts in a customer communication, drift beyond threshold |
| Oversight failure | Human approval bypassed, overseer unable to stop or override the system |
| External notice | Complaint, regulator query, provider notice of a defect, media or researcher report |
3. Incident identification
| Field | Entry |
|---|---|
| Report ID and title | [AIIR-YYYY-NNN] [short neutral title] |
| Related tickets | [security incident ID, data breach ID, change ID] |
| Reported by and channel | [name or role, monitoring alert, user report, complaint, provider] |
| Date and time of occurrence, detection and report | [UTC timestamps; mark estimated values] |
| Date [Organisation] became aware | [timestamp: this starts most regulatory clocks] |
| Incident or near miss | [incident / near miss] |
| Status | [open / contained / closed] |
| AI incident lead and system owner | [names] |
| Summary | [3 to 5 factual sentences: what happened, to whom, and what has been done] |
4. AI system and configuration at the time
Record the configuration that was actually live, not the documented design. Pull it from version control and request logs.
| Field | Entry |
|---|---|
| AI system name, register ID and intended purpose | [ ] |
| [Organisation]'s role | [provider / deployer / both]; upstream provider [name] |
| Risk classification | [EU AI Act category, internal risk tier] |
| Model and exact version | [model, version or snapshot, hosting endpoint and region] |
| Configuration version | [prompt version hash, inference parameters, guardrail rule set version] |
| Retrieval and memory sources | [index names and versions, memory store] |
| Tools and credentials | [tools, MCP servers, plugins enabled; identities and scopes the system acted with] |
| Autonomy and oversight | [actions requiring approval, named human overseers] |
| Most recent change before the incident | [change ID and date] |
5. Inputs, outputs and actions
- Triggering input: [the user prompt, file, email, web page or API call that started the chain; attach or reference securely, do not paste personal data into the summary].
- Context supplied to the model: [retrieved documents, memory entries, tool results, any third-party content that could carry injected instructions].
- Output: [response, decision or score produced; whether a person saw or relied on it].
- Actions taken: [tool calls in order with timestamps, identities used, systems changed]. See the Agent Activity Timeline Reconstruction from Tool Calls and Identity Logs.
- Reproducibility: [reproduced / not reproduced / intermittent; number of attempts and settings used].
- Evidence preserved: [request and response logs, gateway logs, tool and identity logs, configuration snapshot, model version; storage location and hash].
6. Harm assessment and reporting decision
6.1 Harm and severity
| Harm type | Present? | Description and number affected |
|---|---|---|
| Physical or health harm | [Y/N/unknown] | [ ] |
| Fundamental rights (discrimination, privacy, expression, due process) | [Y/N/unknown] | [ ] |
| Financial or economic loss | [Y/N/unknown] | [ ] |
| Data protection (personal data disclosed or misused) | [Y/N/unknown] | [ ] |
| Critical infrastructure or operational disruption | [Y/N/unknown] | [ ] |
| Property or environmental harm | [Y/N/unknown] | [ ] |
| Reputational or contractual harm | [Y/N/unknown] | [ ] |
Severity: [SEV1 critical / SEV2 high / SEV3 medium / SEV4 low], using [Organisation]'s incident severity scale. Who was affected: [users, customers, members of the public, employees, a specific group].
6.2 Regulatory reporting check
| Question | Answer and reasoning |
|---|---|
| Is the system high-risk under the EU AI Act? | [ ] |
| Does the event meet any limb of Article 3(49)? | [a / b / c / d / none] |
| Is there a causal link, or a reasonable likelihood of one, between the AI system and the incident? | [ ] |
| Deployer: has the provider been informed? | [date and time] |
| Is personal data involved, triggering data protection breach rules? | [ ] |
| Other regimes (sector regulators, NIS2, DORA, contracts) | [ ] |
| Decision and approver | [report / do not report, legal approver, date] |
For high-risk systems, Article 73 of the EU AI Act sets these provider deadlines, counted from becoming aware, as shown in the consolidated text on the Commission's AI Act Service Desk:
| Situation | Report to market surveillance authority no later than |
|---|---|
| Serious incident (general case), once a causal link or reasonable likelihood is established | 15 days |
| Widespread infringement, or serious and irreversible disruption of critical infrastructure (Article 3(49)(b)) | 2 days |
| Death of a person, once a causal relationship is established or suspected | 10 days |
An incomplete initial report may be submitted, followed by a complete one. Under Article 26(5), a deployer that identifies a serious incident must immediately inform the provider first, then the importer or distributor and the market surveillance authorities. As of November 2026 the high-risk obligations in Chapter III, Sections 1 to 3, apply from 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems (Article 113 as amended by the Digital Omnibus on AI, Regulation (EU) 2026/1744, per the Commission AI Act Service Desk consolidated text as at 27 July 2026). Confirm against the official text before relying on them, and see the EU AI Act Implementation Timeline Tracker. For other regimes, see the AI Incident Reporting Guide.
7. Containment
- Actions taken and time: [feature disabled, agent paused through kill switch, tool or credential revoked, prompt pattern blocked, fallback model enabled, affected outputs withdrawn].
- Configuration frozen for investigation: [Y/N]. Article 73(6) states that a provider must not alter the AI system in a way that could affect later evaluation of the causes before informing the authorities; take a snapshot before any fix.
- Users and overseers told to stop relying on the output: [who, when, how].
- Credentials rotated: [list of keys, tokens or service accounts the system used]. See the AI Agent Kill Switch and Containment Guide.
8. Root cause analysis
| Contributing factor category | Finding |
|---|---|
| Model behaviour (hallucination, bias, drift, version change) | [ ] |
| Prompt or configuration (instruction gap, parameter change) | [ ] |
| Data (poisoned, outdated or over-permissioned retrieval source) | [ ] |
| Adversarial input (prompt injection, jailbreak) mapped to [MITRE ATLAS ID, OWASP LLM ID] | [ ] |
| Tools and permissions (excessive agency, missing approval gate) | [ ] |
| Supply chain (model, library, plugin, provider) | [ ] |
| Human and process (oversight not assigned, automation bias, training gap) | [ ] |
| Monitoring (why it was not detected sooner) | [ ] |
Root cause statement: [one or two sentences]. Useful reference IDs include MITRE ATLAS AML.T0051 LLM Prompt Injection, AML.T0020 Training Data Poisoning and AML.T0010 AI Supply Chain Compromise, and OWASP LLM01:2025 Prompt Injection, LLM06:2025 Excessive Agency and LLM09:2025 Misinformation.
9. Corrective and preventive actions
| Action | Type | Owner | Due | Verification |
|---|---|---|---|---|
| [e.g. add approval gate for payment tool] | [corrective / preventive] | [ ] | [ ] | [test case added to regression suite, re-test date] |
| [e.g. remove HR folder from retrieval index] | [ ] | [ ] | [ ] | [ ] |
| [e.g. brief overseers on new failure mode] | [ ] | [ ] | [ ] | [ ] |
Every fix that changes the AI system must go through the AI Model Change Approval Template, and the incident's triggering input must be added to the regression test set.
10. Communication, closure and sign-off
- Internal notifications: [executive, legal, DPO, AI governance group, affected teams, with dates].
- External notifications: [authorities, provider, customers, affected persons, with dates and reference numbers].
- Lessons learned review held: [date, attendees].
- Closure criteria met: [containment verified, corrective actions complete or tracked, reports filed].
- Sign-off: [AI incident lead, system owner, legal, date].
Implementation guidance
Making the template work
- Log the fields before you need them: sections 4 and 5 are only possible if production logs record model version, configuration version, retrieved context and tool calls per request. Under Article 26(6), deployers of high-risk systems must keep automatically generated logs under their control for at least six months unless other law sets a different period.
- Agree the reporting decision owner: name one legal or compliance role who decides on section 6.2, with a deputy, so clocks are not missed.
- Exercise it: run a tabletop using a realistic scenario, such as an agent emailing customer data after reading a poisoned document, and time how long it takes to fill sections 3 to 6. See AI agent incident exercises.
- Review trends quarterly: group reports by system, root cause category and model version.
Small and large organisations
A small organisation can keep this as one shared form owned by the security lead, with legal on call. A large organisation should build the fields into its incident tooling as an "AI" incident type, auto-populate section 4 from the AI register and gateway logs, and route section 6.2 to a central regulatory reporting team.
Measuring whether it works
- Median time from awareness to completed section 6.2 decision.
- Percentage of AI incidents where the exact model and configuration version could be identified.
- Percentage of incidents reproduced.
- Repeat incidents with the same root cause within [12] months.
- Ratio of near misses to incidents reported (a very low ratio usually means under-reporting).
Framework mapping
| Template section | NIST CSF 2.0 | NIST SP 800-53 Rev 5 | AI-specific reference |
|---|---|---|---|
| 2 to 5 Triggers, identification, evidence | RS.MA-01 | IR-5 Incident Monitoring | NIST AI RMF GOVERN 4.3 |
| 6 Reporting | RS.CO-02 | IR-6 Incident Reporting | EU AI Act Articles 26(5), 73; NIST AI RMF MANAGE 4.3 |
| 7 to 9 Containment and corrective action | ID.IM-01 | IR-8 Incident Response Plan | NIST AI RMF MANAGE 2.3 |
Sources
- European Commission AI Act Service Desk: Article 73 Reporting of serious incidents
- European Commission AI Act Service Desk: Article 3 Definitions
- European Commission AI Act Service Desk: Article 26 Obligations of deployers
- European Commission AI Act Service Desk: Article 113 Entry into force and application
- OECD: Towards a common reporting framework for AI incidents
- NIST: AI Risk Management Framework Core
- Responsible AI Collaborative: AI Incident Database
Related NHI Mgmt Group resources: AI Incident Reporting Guide · AI Agent Incident Response Playbook · AI Agent Observability and Incident Response Guide · AI Agent Audit Log Schema Template · EU AI Act Compliance Guide