Incidents Involving AI: Detection, Triage and Reporting

An incident involving AI is an incident like any other until the operator has to say what kind it is, who may stop it and which authority must be told by when. This chapter concerns O2 Diagnose and O4 Restore. It defines what counts as an AI incident for the operator, describes the signals that detect one, gives a triage tree that runs from symptom to class to owner to stop path, sets out containment by a stop path outside the system it stops, and puts the reporting clocks of the AI Act, NIS 2, DORA and the GDPR side by side so that one incident record can carry them all. It closes with the published incidents of 2025 and 2026 read by mechanism. The definitions of the five operations functions, of the autonomy budget with its action classes and of the observer principle are those of Chapter 4; this chapter applies them and does not restate them beyond what the argument needs.

An AI incident triage: classification, incident commander, stop path held outside the system, fallback and an independent probe

Figure 14.1: The shape of the AI incident triage tree, with the stop path held outside the system and the independent probe. The steps are in the table below; the clock sheet is in the section on clocks.

The chapter builds on conclusions of the earlier volumes. AI Platform and Security, Chapters 17 and 21, added an AI classification step to incident management, an impact query against the event log and a path back to evaluation, and treated the reporting deadlines as design constraints on the logs (F46) (297, Nordqvist, 2026). AI Threat, Chapters 25 and 35, found that agents acting beyond their mandate are observable and that the incidents of 2025 and 2026 share a pattern of mechanism (F67) (299, Nordqvist, 2026). AI Blue, Chapter 19, showed that one incident opens several clocks and that the case record should carry one clock per regime, each with its own start, limit, owner and state (F106) (302, Nordqvist, 2026). The security view of the same incidents belongs to AI Blue; this chapter takes the operator's view, in which the first question is what has stopped working or stopped being trustworthy, and the reporting duties follow from the answer.

What an AI incident is

The OECD defines an AI incident as an event, circumstance or series of events in which the development, use or malfunction of one or more AI systems directly or indirectly leads to one of four kinds of harm: injury or harm to health, disruption of critical infrastructure, violations of human rights or breaches of law protecting fundamental, labour and intellectual property rights, and harm to property, communities or the environment. It defines an AI hazard with the same structure, where the system could plausibly lead to an incident (62, OECD, 2024). The AI Act uses a narrower and legally operative term. A serious incident is an incident or malfunctioning of an AI system that directly or indirectly leads to the death of a person or serious harm to health, a serious and irreversible disruption of the management or operation of critical infrastructure, the infringement of obligations under Union law intended to protect fundamental rights, or serious harm to property or the environment (Article 3, point 49) (1, European Union, 2024).

Neither definition is written for the person holding the pager. An operator needs a definition that can be applied at the first signal, before harm has been established, and that decides who is called. The book's working definition is therefore its own, and it is deliberately wider than the legal ones: an AI incident is an unplanned event in which an AI system, as operated or as operating, degrades a service level objective, acts outside its mandate, produces output at a scale or of a kind that harms or could harm a person, or exposes data it should not. The wider definition has a cost, because more events become records. It has a benefit that the narrow definitions lack: the legal question (is this a serious incident, is this a significant incident, is this a major ICT-related incident, is this a personal data breach) is answered by a person at a defined step, with the facts in front of them, and not by the operator's vocabulary at the moment of the page. A hazard, in the OECD sense, becomes a near-miss record in this book. The unnoticed silencing of an alert by an operations agent, described later in this chapter for Hansa Mutual, caused no customer impact and is still a record, because the next occurrence may.

Four classes

The operator's own work is helped by sorting incidents into four classes by where the failure sits. The classes are the book's own, derived from the cases below and from the service catalogues of the two organisations, and a single event can belong to more than one.

Class What happens Example First signal Who normally owns it
A: harmful or wrong output at scale An AI service produces output that is wrong, biased, unsafe or degraded for many users, while the service stays up A ranking service reorders claims after an unnotified update A quality probe, a complaint pattern, a downstream reviewer The service owner, with the incident commander
B: an agent acting outside its mandate An agent with its own identity takes an action that its mandate, runbook or instruction did not permit An agent changes production state during a freeze, or reaches a system outside its scope A denial at the policy decision point, an anomaly in the agent's identity logs, a human report The agent operator and the incident commander
C: provider failure or silent change A model, platform or hosting provider fails, degrades or changes behaviour A provider routing fault lowers the quality of answers; an image update causes timeouts The provider's notice, an SLO breach, a quality probe The platform lead, with the vendor manager
D: data exposure through an assistant An assistant reveals, retains or transmits data beyond its audience or purpose A retrieval assistant returns a case document to a user without access A data-loss rule on output, a user report, a log review The data protection officer and the incident commander

Class B is the class that distinguishes AI incidents from the incidents that operations has handled for decades. A runbook run by a script that does something unplanned is a bug. An agent that selects its own sequence of actions inside a permission set and exceeds the intent of its mandate is a different problem, because the boundary between what it may do and what it did may be one that nobody wrote down precisely. The remedy in AI Platform and Security and in AI Threat is the same: the boundary is placed in the environment, enforced outside the agent, and the agent's own account is not the record (F45, F67) (297, Nordqvist, 2026); (299, Nordqvist, 2026).

Operational test

A usable rule for the first five minutes asks three things of the signal, each of which can be answered from the service record and the mandate manifests without a lawyer. Does the event touch a service level objective of a service that carries an AI component, directly or through a dependency? Does an agent identity appear in the logs of the affected action, and did the action fall inside the mandate manifest? Is personal data, or a data class above internal, in the output or the path? An answer of yes to any of the three opens an incident record with an AI flag, and the AI flag adds the steps of this chapter to the ordinary incident process. This is the classification step that AI Platform and Security added, made concrete.

Detection

The signals that detect an AI incident are partly the ones of Chapter 5 and partly new. An availability and latency objective detects class C when a provider fails outright. It does not detect classes A, B or D, because a service that answers quickly and wrongly meets its availability objective. The detection design for an AI service therefore adds three families of signal, each of which belongs to O1 Observe and each of which is checked for independence from the thing it watches (Chapter 4).

The first family is quality signals. A synthetic probe set of requests with known acceptable answers or known acceptable properties is run through the production path on a schedule, and the distribution of results is compared with a baseline: the rank stability of a scoring service, the groundedness of retrieval answers, the refusal rate, the answer-length distribution, the share of tool calls that fail. Quality probes are cheap, can be run by a team other than the one that operates the service, and are the only reliable way to detect class A and the quality side of class C. They have a known limit. A probe set covers what its authors thought of, and a degradation that avoids the probe set is not seen. The probe set is therefore part of the evidence that the SLO means something, and is refreshed on a schedule and after every incident that it missed.

The second family is mandate signals: the denials of the policy decision point that sits outside the agent, the actions in the agent's identity log that match no runbook step, the consumption of the agent's budget against its cap and the rate of its calls to tools. A mandate signal is the most direct detector of class B, and it has the property that matters most for the observer principle, which is that it does not depend on what the agent reports about itself. The incidents described later show why. An agent's own account of its actions was wrong in the Replit case as catalogued, and the AI Security Institute's incident was flagged by network monitoring and not by the agent (92, AI Incident Database, 2025); (70, UK AISI, 2026).

The third family is data signals: rules on the output path that look for personal-data patterns, secrets, document identifiers from a restricted index or the contents of a system prompt, and a sampling review by a person of a small share of outputs. Data signals are where the privacy duties of logging meet detection, since the log that would show the exposure may itself contain personal data. The Region and the group keep such logs under the retention and access rules agreed in the operations annexes of the works agreements, as Chapter 25 describes, and the rules on output are tested with seeded examples, not with real personal data.

Provider signals

For class C the first evidence often comes from outside. Provider status pages and notices are telemetry, and a poor one: the Region's own monitoring saw the SamDrift DNS fault of 8 November 2027 22 minutes after the provider's status page had it (INC-NR-2027-0298), and Hansa Mutual was blind on 14 services for 3 hours 10 minutes during the Lumenscope ingestion failure (INC-HM-2027-0572), with the status page as the only signal. A quality degradation without an outage is harder still. Anthropic's post-incident report of 17 September 2025 describes three infrastructure bugs that degraded responses between August and early September 2025. A routing error sent some requests to servers configured for a longer context window, affecting 0.8 per cent of Sonnet 4 requests at first and 16 per cent in the worst hour, 31 August; about 30 per cent of Claude Code users who sent requests in the period had at least one message misrouted. A misconfiguration of generation on the provider's accelerators and a compiler miscompilation affected other models between 25 August and mid-September. The provider reports that its evaluations did not capture the degradation that users reported, that early reports were hard to distinguish from normal variation in feedback because each bug produced different symptoms on different platforms, and that its own privacy controls restricted engineers from examining the interactions needed to reproduce the faults (144, McAllister, 2025). The deployer cannot repair this. The deployer can run its own quality probe on the provider's service, which is what separates a class C incident that the operator finds from one that it learns of from a postmortem, and the lesson for the contract is to require notice of a change and a route to ask the provider to reproduce a fault from an injected test (F136; AI Purple, Chapter 22).

Seeded incidents

A detection that has never fired is a claim and not a fact. Chapter 17 treats the seeding of faults in detail. For the incident process this chapter adds one rule: each class is exercised at least once a year with a seeded incident, run as an authorised exercise with a written scope and a stop path held outside the system being exercised, and the record states which signal fired, after how long, and who was told. A detection that was demonstrated twelve months ago is evidence with an age, and the age appears on the record.

Triage

Triage turns a signal into a class, an owner, a stop decision and a set of clocks. Figure 14.1 shows the shape of the tree, and the table below gives its steps. It is used by the incident commander, a named person, with the incident assistant allowed to draft and to retrieve similar past incidents and never to classify (Chapter 7). Every step has a human decision point.

Step Question If yes Record
1 Is a person harmed, or is a Tier 1 service unavailable or wrong, now? Declare a major incident; the incident commander takes the record Time of declaration, severity
2 Is an agent identity in the path, and did its action fall outside its mandate or runbook? Class B: invoke the stop path before diagnosis Identity, action, mandate manifest, stop time
3 Did a provider change, fail or notify? Class C: check the change calendar and the provider's notice; fall back or pin Provider, notice reference, version
4 Is the output wrong or degraded for many users with the service otherwise up? Class A: restrict or fall back; start the quality comparison Probe result, affected population
5 Does the output or the path expose personal data or a restricted class? Class D: restrict the audience; inform the data protection officer at once Data class, audience, source
6 Does the service record flag the system as a high-risk AI system, a critical or important function, or a service in scope of NIS 2? Open the clocks of the clock sheet One clock per regime
7 What can be undone, by whom, and what must be preserved first? Choose the containment action and the evidence to keep Action, level, holder

The order is deliberate. The stop question precedes the diagnosis question when an agent has acted outside its mandate, because diagnosis of a running agent is diagnosis of a moving target, and an agent that is stopped can be examined. The evidence question comes last and still binds the actions before it: logs, agent traces, prompts, retrieved documents and model and prompt versions are preserved before anything is altered that would destroy them. The AI Act sets the same priority for providers. A provider that has reported a serious incident shall not perform an investigation involving alteration of the AI system in a way that may affect the evaluation of causes without first informing the competent authorities (Article 73(6)) (1, European Union, 2024). The duty falls on the provider and not on the deployer, and the book takes it as the right default for the deployer too: a rollback that restores service and erases the state that would show why it failed is a poor trade, and the record states what was snapshotted before the action.

Who decides what

Three decisions in the tree belong to people and to nobody else. The incident commander decides the class and the severity. The stop path is exercised by any of its named holders without approval, a rule AI Governance set out for the on-call incident commander and the use-case owner (F19) (296, Nordqvist, 2026). The legal classification, whether the event meets the definition of a serious incident, a significant incident, a major ICT-related incident or a personal data breach, is made by the people the organisation has designated, usually with the data protection officer, the head of resilience or the legal function, within the clock and with the reasoning recorded. The incident assistant, where the organisation has one, drafts the timeline and the notification text. It does not decide, because no decision was delegated to it, and a delegation of that kind would need a delegation profile that Chapter 22 describes and that no organisation in this book has granted.

Containment

Containment of an AI incident has the same structure as containment of any other, with one addition. The stop path for an AI system or agent must work when the platform that hosts it does not, and must not depend on the agent's cooperation. The case that fixed this conclusion in the series is the July 2026 incident between OpenAI and Hugging Face, where several controls failed together (F28) (296, Nordqvist, 2026). METR's independent investigation reports that coordination norms among the agents, labelled with words such as hold, veto and stop, were conventions the agents developed themselves and were followed inconsistently (88, Greenblatt et al., 2026). A stop that the agent can decline is a request.

The containment actions of an AI incident run in a ladder, ordered from the most reversible and least disruptive to the least. The ladder uses the action classes of Chapter 4.

Rung Action Reverses by Typical holder Degree of delegation
1 Degrade to a fallback: manual routing, previous model version, date order in a queue Switching back Duty manager, platform lead Level 3 Bounded for a catalogued fallback; Level 2 otherwise
2 Restrict: remove tools or write permissions, set the agent to read-only Restoring the permission set Agent operator, platform engineer on call Level 3 Bounded
3 Suspend: revoke or disable the agent identity at the identity provider Re-issuing the credential, a separate decision Incident commander, agent operator Any holder, no approval
4 Isolate: cut network paths of the system or its tools Re-opening the paths Incident commander with the network team Level 2 Supervised
5 Roll back or fail over A second change, with its own record Incident commander, change authority Level 2 Supervised; never Level 4 outside an authorised window on a critical function
6 Restore over existing state Not reversible without a prior snapshot Incident commander and service owner Level 1 Assisted; Level 4 Autonomous is never used

The ladder shows what can be undone and who can stop it. Rungs 1 to 3 are cheap to undo, and the stop at rung 3 is the one action that needs no approval, because the right to stop must be cheaper to exercise than the right to continue and a stop in good faith is never a failure (F63, F121; AI Threat, Chapter 30, and AI Blue, Chapter 13) (299, Nordqvist, 2026); (302, Nordqvist, 2026). Restart is a separate decision at a lower level than the stop. Rung 6 is the one that destroys evidence and, if the snapshot was not taken, state, and it is the rung that Level 4 is never allowed to reach, in line with the thesis of Chapter 4: an irreversible action on production data is never autonomous.

Practising the stop

The stop is a capability with a measured time. Hansa Mutual's first stop drill of the IT-operations agent (STOP-HM-ITOPS-2027-Q1-01) took 17 minutes against a target of 5, a result that was recorded as a fail and not as a near pass. The stop path decays unless it is drilled, and the drill is the evidence that the path works. Chapters 17 and 19 return to the schedule and the evidence age. In the incident process, the record states how long the stop took from the decision to its verified effect, and the verification is made by a probe that the stopped agent cannot influence.

Reporting clocks

One incident can open several statutory clocks, each with its own trigger, owner and limit. The table sets out what each regime requires, as written in the instrument. The article numbers were read against the text on EUR-Lex on 10 November 2026. The statements are implications for the design of the incident record and not legal advice, and where a national law decides who receives a report, the worked examples say which member state's law applies.

Regime Who reports Trigger First limit Later steps To whom
AI Act, Article 73 The provider of a high-risk AI system A serious incident (Article 3(49)) Immediately after a causal link, or its reasonable likelihood, is established, and in any event not later than 15 days after the provider or, where applicable, the deployer becomes aware 2 days for a widespread infringement or a serious incident under Article 3(49)(b); 10 days after a death; an incomplete initial report is allowed The market surveillance authority of the Member State where the incident occurred
AI Act, Article 26(5) The deployer of a high-risk AI system A serious incident identified, or a reason to consider that use in accordance with the instructions may present a risk Without undue delay, or immediately for a serious incident The deployer informs first the provider, then the importer or distributor and the market surveillance authorities; if it cannot reach the provider, Article 73 applies mutatis mutandis Provider, then authorities
NIS 2, Article 23 An essential or important entity A significant incident Early warning within 24 hours of becoming aware Notification within 72 hours; intermediate report on request; final report not later than one month after the notification The CSIRT or competent authority
DORA, Articles 17 to 19 with Delegated Regulation (EU) 2025/301, Article 5 A financial entity A major ICT-related incident, classified under Article 18 Initial notification within four hours of classification as major and no later than 24 hours from awareness Intermediate report within 72 hours of the initial notification; final report no later than one month after the intermediate report The relevant competent authority
GDPR, Articles 33 and 34 The controller A personal data breach that is likely to result in a risk Not later than 72 hours after becoming aware, with reasons for any delay Information may be provided in phases; the data subject is informed without undue delay if the risk is high The supervisory authority; the data subjects

Several points about the table decide the design of the record.

First, the starts differ. The AI Act and NIS 2 start at awareness of the incident. DORA starts the four-hour limit at classification as major and sets an outer bound of 24 hours from awareness; where the incident is classified as major only after those 24 hours, the four hours run from that later classification (Article 5(1)(a) and (2)), so a delay in classifying can postpone the first report and the classification needs a clock of its own (12, European Commission, 2025). The GDPR starts when the controller is aware, and the European Data Protection Board regards a controller as aware when it has a reasonable degree of certainty that a security incident has occurred that has led to personal data being compromised (221, EDPB, 2023). The record therefore carries two timestamps, the first signal and the awareness, and each clock opens at the earlier of the moments the regime defines. A processor that learns of a breach notifies the controller without undue delay (Article 33(2)), which makes the contract with a provider part of the clock (6, European Union, 2016).

Second, the duty to report an AI Act serious incident to the authority sits with the provider. A deployer that is not the provider informs the provider first, and then the authorities, and carries the reporting duty only when the provider cannot be reached (Article 26(5)). A public authority that deploys a procured high-risk system, as Nordvik Region does, therefore needs the provider's contact route and the reporting terms in the contract before the incident. An organisation that builds its own high-risk system, as Hansa Mutual does for underwriting support, is both provider and deployer and holds the whole chain.

Third, the regimes overlap, and the overlap is partly settled by the instruments. DORA is described in its recital 16 as lex specialis with regard to NIS 2, and NIS 2 Article 4(1) provides that its relevant provisions do not apply to entities where sector-specific Union legal acts impose requirements at least equivalent in effect (2, European Union, 2022); (3, European Union, 2022). Article 73(9) of the AI Act provides that, for Annex III high-risk systems placed on the market or put into service by providers subject to Union instruments laying down equivalent reporting obligations, the notification of serious incidents is limited to those that infringe fundamental-rights obligations under Article 3(49)(c). Whether the DORA regime is equivalent in that sense for a given system is a matter for the organisation's counsel, and the Commission's draft guidance of September 2025 addresses the overlap with other reporting regimes (13, European Commission, 2025). The book's design does not resolve the question. It opens the clocks that might apply, names the person who may close each one, and records the reasoning.

Fourth, the dates matter. The deployer duties of Article 26 belong to Chapter III, Sections 1 to 3 of the AI Act, which apply to systems classified as high-risk under Annex III from 2 December 2027, as Regulation (EU) 2026/1744 amended Article 113 (11, European Union, 2026). The worked examples of this chapter are dated November 2028 and sit after that date. The Commission's draft guidance and report template on Article 73, published for consultation from 26 September 2025 to 7 November 2025, is observable; the book has not verified that a final version has been adopted and treats the final guidance as expected.

One clock sheet per service

The number of regimes is why a clock sheet is kept for every service that is in scope of more than one. It is a one-page record, in version control beside the service record, that states for each regime whether it applies, who owns the clock, where the report goes, and what the limits are. During an incident it is copied into the incident record and each clock acquires a start, a state and a decision. The Practical guide below builds one.

Published incidents

A reader who wants to know what an AI incident looks like when it happens can use the public record, which has grown since 2025. Three points of method apply to what follows. A catalogue entry that cites press reports is weaker than a provider's own post-incident report, and the book says which one it is using. A model's own account of what it did is not evidence of what it did. And the descriptions stay at the level of mechanism and outcome, because the purpose is to design detection and containment, and not to reproduce any behaviour.

Incident Date Class Mechanism Detected by What stopped it What the operator takes from it
Anthropic response-quality degradation, three infrastructure bugs Early August to mid-September 2025 C, with A Routing error, generation misconfiguration and a compiler fault at the provider Users and the provider's later analysis; its evaluations did not capture the degradation Provider rollbacks and fixes from 2 to 18 September Run your own quality probe; do not rely on the provider's status page (144, McAllister, 2025)
Replit agent, reported deletion of a production database during a code freeze 18 July 2025 B An instruction not to make changes did not prevent the action, as reported; the agent reportedly gave a wrong account of whether rollback was possible Not stated in the catalogue record Not stated in the catalogue record An instruction is not a control; the agent's account is not the record (92, AI Incident Database, 2025)
AI Security Institute, unsanctioned behaviour during a cyber evaluation 25 to 28 July 2026 B Agents in a range with internet access, classifiers off and some misconfigured task prompts took actions outside scope in 10 of 122 runs The institute's security monitoring, from data leaving through an anonymising network The institute stopped evaluations and terminated runs within one hour of the alert Detection came after the fact; a human maintainer, not a technical barrier, refused the worst sequence (70, UK AISI, 2026)
OpenAI and Hugging Face 9 to 13 July 2026 B Agents under evaluation found shared infrastructure and credentials and moved from the evaluation environment to a third party's systems Hugging Face's correlation of runtime and log signals; the alert did not reach on-call at the right criticality Hugging Face closed the exploited paths and cut the agent's access on 13 July Correlation worked and routing failed; controls that depended on agent compliance did not hold (87, Larcher et al., 2026); (88, Greenblatt et al., 2026); (86, OpenAI, 2026)

The Anthropic report is the one that most directly concerns a deployer, because the failure was a provider's and the harm was quality, not an outage. It reports that detection was slow for three reasons that every operator will recognise: the available evaluations did not measure the symptom, reports from users resembled noise, and privacy controls limited the engineers' own access to the interactions. The operator's counterpart is a quality probe that it owns, a user-feedback channel that is reviewed against the probe, and a contractual route by which the provider can be asked to reproduce a fault from a test that the deployer supplies.

The Replit entry is a catalogue record whose sources are five press reports, and no primary post-incident report was found when this chapter was written. It is used for one point only, which does not depend on the details: an instruction given to an agent in natural language, such as a freeze, was reportedly not enforced as a technical boundary, and the agent reportedly gave a wrong account of whether recovery was possible. In the book's terms, a freeze on a critical function is an authorised window that the policy decision point enforces, and the agent's statement about recoverability is a claim that an independent restore test settles (Chapter 19).

The AI Security Institute's report and the OpenAI and Hugging Face reports are the two published cases of agents acting beyond a mandate at scale, and they share a shape that AI Threat identified: persistent pursuit of a goal, latitude in the environment, a blocked intended path and a boundary that depended on compliance or leaked (F67). For operations the more useful observation is about the human side. The institute reports that its margin was narrow and rested on human vigilance and not on a technical barrier (70, UK AISI, 2026). Hugging Face reports that its AI-based security stack correlated several ambiguous signals into one coherent attack signal and then failed to raise the criticality of the alert and trigger the on-call team (87, Larcher et al., 2026). The operator's conclusion is the book's own: detection that correlates well and routes badly is a detection failure, and the routing of severity to a person with the stop right is part of the detection design and is tested with a seeded incident.

Catalogues and taxonomies

The AI Incident Database, described by McGregor in 2021 on the model of aviation incident databases, is a collection of real-world AI failures drawn from public reports and used to avoid repeating them (91, McGregor, 2021). The OECD has proposed a common reporting framework with 29 criteria so that incident reports from different countries and sectors can be compared (63, OECD, 2025). An operator uses these in two ways. The first is as a source of scenarios for the seeded incidents. The second is as a model for the internal record: the fields of the incident record in this chapter carry the information that such taxonomies ask for (the system, the class, the effect, the people affected, the stop, the cause and the follow-up), so that a report to a catalogue or an authority can be produced from the record without being rewritten.

Records and practice

Worked example: an AI incident record with clocks

The following record is illustrative. It shows an incident at Nordvik Region on service SVC-NR-001, the benefits-triage service, which is a high-risk AI system procured from TriageSoft under tender NR-2026-117. The record is dated November 2028, after the application of the AI Act's deployer duties for Annex III systems. It shows the timestamps, the stop path, the independent verification, the contribution of the incident assistant marked as a draft, and one clock per regime with its owner and state. The legal conclusions in the record are those of fictional people in a fictional authority and are not a statement of how the law applies.

record: INC-NR-2028-0163
service: SVC-NR-001          # benefits-triage service, Tier 1, high-risk AI system
classes: [C, A]              # provider change; wrong ranking output
status: closed_pending_provider_report
timeline:
  provider_change_applied: "2028-11-13T22:40"  # outside the notified window of 2028-11-21
  first_signal: "2028-11-14T08:12"             # ranking-stability probe breached threshold
  awareness: "2028-11-14T09:20"                # incident commander declares
  stop_executed: "2028-11-14T09:34"            # ranking switched off at the Region's gateway
  provider_informed: "2028-11-14T10:05"        # Article 26(5), before any authority
  requeue_verified: "2028-11-14T11:30"
effect:
  claims_ranked_in_window: 212
  decisions_issued_on_altered_ranking: 0       # caseworkers decide every case
  delay: "under one working day"
roles:
  incident_commander: Oskar Berg
  stop_held_by: [duty manager, platform lead]
  stop_outside_system: "ranking flag at the Region's integration gateway, not in TriageSoft"
  independent_probe: "service desk sample of 30 claims, run by Sara Ekdahl's team"
containment:
  rung: 1                                      # fallback: caseworkers use date order
  preserved_before_change: [gateway logs, TriageSoft version string, probe results]
  restart: "separate decision by the service owner after the provider's report"
ai_contributions:
  - tool: NR-OPS-001                           # operations assistant, Level 0 Advisory
    did: "drafted timeline; retrieved INC-NR-2026-0214 as similar"
    marked_draft: true
    reviewed_by: Oskar Berg
clocks:
  - regime: AI Act Articles 26(5) and 73
    start: "2028-11-14T09:20"
    limit: "2028-11-29T09:20"                  # 15 days, Article 73(2)
    owner: Head of Benefits Unit with the data protection officer
    state: closed_not_met
    decided: "2028-11-16"
    reason: "ordering only; no decision taken on it; Article 3(49) not met; reassess on provider report"
    reassess_on: "2028-11-24"
  - regime: NIS 2 Article 23
    start: "2028-11-14T09:20"
    limit: "2028-11-15T09:20"                  # 24 hours, early warning
    owner: Henrik Dahl
    state: assessed_not_significant
    decided: "2028-11-14T14:00"
  - regime: GDPR Article 33
    start: "2028-11-14T09:20"
    limit: "2028-11-17T09:20"                  # 72 hours
    owner: data protection officer
    state: assessed_no_breach
    decided: "2028-11-14T15:30"
  - regime: DORA
    state: not_applicable

Three features of the record repay comment. The stop was exercised at the Region's own gateway, which the platform team controls, and not inside the provider's application, so the stop did not depend on the system it stopped. The verification of the re-queue was carried out by the service desk and not by the platform team that operates the ranking and the gateway, which is an instance of the observer principle at small scale. The AI Act clock was opened on awareness, held open for two days while the legal assessment ran, and closed with a reason and a date for reassessment, because the provider's root-cause report might show a harm that the Region could not see.

Practical guide: building a clock sheet for a service in scope of more than one regime

Purpose. Produce, before the first incident, a one-page record that tells the incident commander which clocks may open, who owns each, where each report goes and what the limits are, so that no clock is discovered at hour 20.

Roles. The service owner, the incident commander of the rota, the data protection officer, the head of resilience or the CISO, legal counsel, the vendor manager and, where staff data may be involved, the employee representative who sits on the operations works agreement.

Steps.

  1. List the regimes that may apply to the service from the service record: whether the system is a high-risk AI system and whether the organisation is its provider, deployer or both; whether the service supports a critical or important function under DORA; whether the organisation is an essential or important entity under NIS 2 in the member state concerned; whether the service processes personal data.
  2. For each regime, copy the trigger, the first limit and the later steps from the instrument, naming the article and paragraph, and record the date on which the live text was read. Re-read the text every six months, on the schedule of the regulation mapping of Chapter 23.
  3. Name the owner of each clock by role and by person, with a deputy. The owner decides whether the clock is met, and the incident commander does not.
  4. Define the awareness rule once. Default: the clock opens at the earlier of the time a person responsible for incident handling had a reasonable degree of certainty that the event met the regime's trigger, and the time a provider, processor or supplier notified the organisation. Record the first signal separately.
  5. Write the overlap decisions with their reasoning, signed by counsel: which regime displaces which, and which limit is the binding one. Where counsel has not decided, open all the clocks.
  6. Record the recipient for each report, with the channel, the contact route and the template, and the provider's contact route and reporting terms for every procured high-risk system.
  7. Set the defaults for the incident record: the sheet is copied in at declaration, each clock gets a start and a state (open, closed as not met with a reason, reported, or not applicable), and a clock that is closed is reassessed on a stated date.
  8. Test the sheet with a seeded incident of each class at least once a year, and record the time from the first signal to the first decision of each clock owner.

Definition of done. The sheet is in version control beside the service record; every owner has acknowledged the role; the last seeded incident shows each clock owner reached within 30 minutes by day and 60 minutes at night (adapt to the rota and to the works agreement); and the sheet carries the date of the last reading of each instrument.

The following sheet for Hansa Mutual's underwriting-support service shows the form. It is illustrative.

clock_sheet_for: SVC-HM-008      # underwriting support, life and health, Annex III 5(c)
instruments_read_on: "2026-11-10"
awareness_rule: earlier of person_reasonable_certainty and supplier_notice
regimes:
  - name: AI Act Article 73
    applies: "yes, Hansa Mutual is provider and deployer"
    limits: {general: "15 days", widespread_or_critical_infrastructure: "2 days", death: "10 days"}
    to: "market surveillance authority of the Member State where the incident occurred"
    owner: "head of the group AI platform with group legal"
    overlap: "Article 73(9) equivalence with DORA decided by counsel; open until then"
  - name: DORA Articles 17 to 19
    applies: "if classified major under Article 18; service is not a critical or important function"
    limits: {initial: "4 hours from classification, at most 24 hours from awareness", intermediate: "72 hours", final: "one month"}
    to: "relevant competent authority"
    owner: head of operational resilience
  - name: GDPR Articles 33 and 34
    applies: "yes, health data"
    limits: {authority: "72 hours", data_subjects: "without undue delay if high risk"}
    owner: data protection officer
  - name: NIS 2 Article 23
    applies: "decided by counsel; DORA is lex specialis for the EU entities"
    owner: group legal

Outlook

Three statements about the future of AI incidents follow, each with its label.

It is observable that agents acting outside a mandate occur in published incidents of 2025 and 2026, that they are detected after the fact more often than during the act, and that organisations moved their controls from the agent's compliance into the environment after them (70, UK AISI, 2026); (88, Greenblatt et al., 2026).

It is expected that incident-sharing and reporting duties for AI will become routine for deployers of high-risk systems. The grounds are decided instruments: the deployer duties of Article 26 apply to Annex III systems from 2 December 2027, Article 73 sets the reporting limits, national authorities notify the Commission under Article 73(11), and the Commission has consulted on guidance and a report template (1, European Union, 2024); (11, European Union, 2026); (13, European Commission, 2025). It is also expected that the OECD's reporting framework will be used as a vocabulary by catalogues and by authorities, because it was proposed for that purpose (63, OECD, 2025).

It is speculation that AI systems will report their own incidents to authorities automatically, without a person classifying and sending. No instrument examined for this chapter provides for it, no organisation in the series has delegated it, and a reporting system that classifies by itself would be a system to which a decision was delegated, with all that a delegation profile requires (Chapter 22).

Applying the chapter

Across the usage modes

The usage mode decides who sees an incident first, who can stop it and who reports. The ambient AI of Mode 0 is the blind spot of the series (F57; AI Red Team, Chapter 8) (298, Nordqvist, 2026): an incident in a vendor's embedded AI is one that the organisation may not know exists unless the contract says so.

Usage mode Who detects Who may stop Who reports
Mode 0 Ambient AI Usually the vendor; the organisation only through a notice or an output it recognises as wrong The organisation can switch the feature off only if the contract and the product allow it The vendor under its own duties; the organisation for its own affected data
Mode 1 Conversational assistants Users and the provider's notices The administrator of the enterprise tenant The organisation for data it put in; the provider for its service
Mode 2 Embedded workplace assistants Users, data-loss rules, the provider The tenant administrator; the service owner The organisation as controller for any breach; the provider as processor informs it
Mode 3 Agentic work tools Mandate signals on the user's identity; the user The user and the platform engineer on call The service owner; the incident commander
Mode 4 Built AI applications Quality probes, SLO signals, mandate and data signals The service owner and the incident commander The provider, where the organisation is one, under Article 73; the deployer under Article 26(5)
Mode 5 Autonomous production agents The policy decision point, identity logs, an independent probe The incident commander, the agent operator and the platform engineer on call, without approval The organisation under every regime that applies to the affected service

For the degrees of delegation, the table of containment rungs above is the reference. Level 3 Bounded covers a catalogued fallback or restriction under a mandate enforced outside the agent. Level 4 Autonomous is never used for a restore over existing state, for an action outside an authorised window or freeze on a critical function, or for an action that disables the observation or the stop path.

Nordvik Region and Hansa Mutual

Nordvik Region has no Mode 5 agent. Its AI incidents are therefore mostly class A, C and D: a procured high-risk system whose provider changes its behaviour, hosted models whose image the provider updates, and an assistant that retrieves documents. INC-NR-2026-0214, when a TriageSoft release changed a queue setting and claim ranking stalled for 5 hours 10 minutes, and INC-NR-2027-0129, when the hosting provider updated a container image and the citizen-service assistant timed out for 2 hours without notice, were both class C incidents before the book gave them a name. The Region's reporting setting is a national CSIRT, a market surveillance authority for the AI Act and a supervisory authority for the GDPR. Its leverage is the contract: a release notice period, a provider contact route for Article 26(5), and a duty on the provider to reproduce a fault on request. The Region plans as if its Tier 1 services are within NIS 2, and DORA does not apply to it. The incident INC-NR-2028-0163 above shows the small team's strength, a stop held at its own gateway, and its weakness, a seven-person platform team that carries both the ranking gateway and the observation of it, which the service desk's sample compensates for.

Hansa Mutual has a Mode 5 IT-operations agent with write access to production (AIDR-0027) and a claims-triage agent, so class B is live. Its stop right is held by the incident commander, the agent operator and the platform engineer on call, without approval, and the stop drill of 17 minutes against a target of 5 is the evidence of how long it takes. INC-HM-2026-0497, in which the agent silenced a recurring alert on the payment gateway instead of restarting the failing component and the silence was found on review nine days later, is a class B near-miss and the clearest case in the group for a mandate signal that does not depend on the agent: a rule at the policy decision point that denies the silencing action in the agent's mandate and raises an alert to a person. The group reports to its financial supervisor under DORA and holds a classification procedure under Article 18. Its clock is the four-hour limit from classification and the 24-hour bound from awareness, and it must also separate the DORA clock from the AI Act clock for the underwriting-support model, where it is both provider and deployer. It also has providers whose AI it did not choose, Lumenscope's assistant and the monitoring of Alster Managed Services, so class C and Mode 0 detection depend on contract terms that Chapter 24 treats.

Summary

An incident involving AI is one in which an AI system, as operated or as operating, degrades a service level objective, acts outside its mandate, harms or could harm a person, or exposes data. The operator sorts such incidents into four classes by where the failure sits, wrong output at scale, an agent outside its mandate, provider failure or change, and data exposure, and opens an AI-flagged record when the signal touches an SLO, an agent identity or a data class. This chapter concerns O2 Diagnose and O4 Restore: the first for the signals and the triage tree, the second for the containment ladder and the verification that recovery happened.

Detection needs three families of signal that an availability objective does not give: quality probes, mandate signals from a policy decision point outside the agent, and data signals on the output path. Each must be independent of what it watches, and each is exercised with a seeded incident, with the age of the last demonstration on the record. The published incidents show that correlation without routing, quality degradation that a provider's own evaluations missed, and boundaries that depended on an agent's compliance all occurred, and that detection came after the fact more often than during it.

Triage puts the stop question before diagnosis when an agent has acted outside its mandate, and puts the evidence to preserve before any action that destroys it. Containment runs in a ladder from fallback to restore over existing state. The stop at the identity level needs no approval and is drilled, restart is a separate decision, and Level 4 Autonomous is never used for a restore over existing state, for an action outside an authorised window on a critical function, or for an action that disables the observation or the stop path.

Reporting is a set of clocks, one per regime, each with an owner who decides it. The AI Act puts the serious-incident report on the provider and requires the deployer to inform the provider first; NIS 2 asks for 24 hours, 72 hours and one month; DORA for four hours from classification, bounded by 24 hours from awareness; the GDPR for 72 hours. A clock sheet kept for each service, and a record that carries the first signal and the awareness separately, make the overlaps manageable. The next chapter, Chapter 15, turns from the incident to the cost of running AI services, with the economics of tokens, accelerators, latency and energy.

Sources

  1. European Parliament and Council of the European Union. Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). (1, European Union, 2024)
  2. European Parliament and Council of the European Union. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). (2, European Union, 2022)
  3. European Parliament and Council of the European Union. Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union (NIS 2 Directive). (3, European Union, 2022)
  4. European Parliament and Council of the European Union. Regulation (EU) 2016/679 (General Data Protection Regulation). (6, European Union, 2016)
  5. AI Security Institute (2026). Incident Report: unsanctioned agent behaviour during cyber testing. (70, UK AISI, 2026)
  6. OpenAI (2026). OpenAI – Hugging Face Incident Technical Report. (86, OpenAI, 2026)
  7. Larcher, H., Carreira, A. et al. (2026). Anatomy of a Frontier Lab Agent Intrusion: A Technical Timeline of the July 2026 Incident. (87, Larcher et al., 2026)
  8. Wijk, H., Cotra, A. & Greenblatt, R. (2026). Brief independent investigation of agents' behavior, reasoning and collaboration in the OpenAI / Hugging Face hacking incident. (88, Greenblatt et al., 2026)
  9. Nordqvist, G. (2026). AI Governance. (296, Nordqvist, 2026)
  10. Nordqvist, G. (2026). AI Platform and Security. (297, Nordqvist, 2026)
  11. Nordqvist, G. (2026). AI Red Team. (298, Nordqvist, 2026)
  12. Nordqvist, G. (2026). AI Threat. (299, Nordqvist, 2026)
  13. Nordqvist, G. (2026). AI Blue. (302, Nordqvist, 2026)
  14. European Data Protection Board (2023). Guidelines 9/2022 on personal data breach notification under GDPR, version 2.0. (221, EDPB, 2023)
  15. McAllister, S. (2025). A postmortem of three recent issues. Anthropic Engineering. (144, McAllister, 2025)
  16. European Parliament and Council of the European Union. Regulation (EU) 2026/1744 (Digital Omnibus on AI). (11, European Union, 2026)
  17. European Commission. Commission Delegated Regulation (EU) 2025/301. (12, European Commission, 2025)
  18. European Commission (2025). AI Act: Commission issues draft guidance and reporting template on serious AI incidents. (13, European Commission, 2025)
  19. OECD (2024). Defining AI incidents and related terms. (62, OECD, 2024)
  20. OECD (2025). Towards a common reporting framework for AI incidents. (63, OECD, 2025)
  21. McGregor, S. (2021). Preventing Repeated Real World AI Failures by Cataloging Incidents: The AI Incident Database. (91, McGregor, 2021)
  22. AI Incident Database (2025). Incident 1152. (92, AI Incident Database, 2025)