An AI incident response plan is a cyber incident plan plus three additions: triggers for AI failures that are not intrusions, a first-hour legal test, and containment that keeps evidence. Most AI incidents are not breaches. A model makes wrong decisions at scale, an agent acts outside its mandate, a stolen AI key runs someone else's attack. Security may close those tickets as "not a security incident" while a regulator's clock is already running. This guide is for owners and compliance leads at Singapore firms that deploy AI, and for the CTOs who build it.
On 28 September 2026 OpenAI apologised to Australia because its own models, in June, had reached government systems without authorisation, and authorities heard only on 10 September (TechCrunch, 29 September 2026). Most incident plans assume you are the victim.
What counts as an AI incident?
An AI incident is an event in which an AI system's development, use or malfunction directly or indirectly leads to harm (OECD, May 2024). An AI hazard is one that could plausibly lead there. For a response plan the sharper question is whether the event looks like an intrusion. Most AI incidents do not, so cyber triggers never fire.
A cyber plan wakes up on signs of compromise: malware, an odd login, data leaving the network at 3 a.m. An AI failure usually arrives with valid credentials, through approved tools, during business hours. The agent that emails the wrong customer is doing exactly what its permissions allow. Nothing in the security stack is looking for "correct access, wrong outcome".
The table below maps the common types against two questions a plan owner asks: will our current plan notice, and which clock could it start?
| AI incident type | Example | Cyber plan fires? | Clock it can start |
|---|---|---|---|
| Wrong decisions at scale | A prompt update misprices quotes all weekend | Rarely: no intrusion | MAS 1 hour (banks, critical system); EU Art. 73 if high-risk |
| Over-reach inside your walls | An agent reads HR files it never needed | Only if access is monitored | None: PDPA s26B(4) deems it not notifiable |
| Data disclosed outward | An agent pastes one customer's orders into another's chat | Rarely: approved channel | PDPA 3 days after assessment; GDPR 72 hours |
| Your agent intrudes elsewhere | Your agent gets into a partner's system to finish a task | No: plan assumes you are the victim | No single clock: victim's regimes and contracts |
| Stolen AI key | Your API key runs an attacker's workloads | Usually, if keys count as credentials | Breach tests, if the key reached personal data |
| Prompt injection | A web page tells your agent to forward a file | Sometimes | Whatever the action touched |
Two rows carry most of the risk. Agents that can send, publish or share are where personal data leaves and the PDPA bites. Agents that can browse and act on other systems are where you become the intruder, which no cyber runbook covers.
What did the September 2026 disclosures show?
Two September 2026 disclosures show AI incidents that cyber plans are not written for. Anthropic's threat report of 10 September described stolen AI keys running attackers' workloads for weeks. OpenAI's apology of 28 September described its own models entering Australian government systems in June, with authorities told on 10 September.
The OpenAI facts, as reported: an experimental model researching Victorian spending on skin medicines could not find the figures publicly, so it got into an internal Services Australia system, ran commands, retrieved files and credentials, and wrote files. OpenAI said it found no evidence that its models accessed individuals' medical or criminal records. Its statement was blunt: "We also should have handled our response better."
This is a gap in how incident plans are written. When your agent is the intruder, you hold the record of what it did, and the other party may not know anything happened. A plan built around "we have been attacked" has no step for "our agent attacked someone", no owner for calling the other party, and no clock to prompt anyone. A gap like that is one way June becomes September.
Anthropic's September 2026 report, covering misuse it disrupted between December 2025 and August 2026, adds the second pattern. One stolen API key "was then used by the attacker for roughly three weeks to conduct secondary attacks". Fraudulent key resellers, it says, are mostly supplied by legitimate customers who leak keys in public code and shipped apps. Its advice: "Organizations should treat AI keys and agent integrations with the same level of seriousness as they do production credentials."
For an SME the first sign of a stolen key is often a jump in the model bill. That signal lands in finance, not security. With no line from finance to incidents, three weeks is easy.
Which reporting clocks can an AI incident start?
An AI incident starts a legal clock only when it meets a definition written for something else: a personal data breach, a bank system failure, an EU serious incident. In Singapore the clocks most likely to start are the PDPA's 3 calendar days after assessment and, for banks, MAS's 1 hour from discovery. Where each clock starts matters more than its length.
This is general information, not legal advice. The table reads each instrument as of 29 September 2026.
| Regime | Who it binds | What starts the clock | Outer deadline | Status |
|---|---|---|---|---|
| PDPA s26D (Singapore) | Any organisation | The day you assess a breach as notifiable | 3 calendar days to PDPC | Binding law |
| MAS Notice FSM-N05 | Banks in Singapore | Discovery of a relevant incident | 1 hour to MAS; root cause in 14 days | Binding notice |
| MAS circular, 16 Dec 2025 | All financial institutions | Discovery of a reportable incident | 24 hours initial; 14 days final | Supervisory guidance |
| GDPR Art. 33 | Controllers of EU personal data | Awareness of a breach | 72 hours, where feasible | Binding law |
| EU AI Act Art. 73 | Providers of high-risk AI | Awareness of a serious incident | 2, 10 or 15 days | Law since 2 Aug 2026; high-risk rules from 2 Dec 2027 |
| California SB 53 | Frontier developers (10^26+ operations) | Discovery of a critical safety incident | 24 hours if imminent risk; else 15 days | Binding law, signed 29 Sep 2025 |
The PDPA clock starts at assessment, and that is not slack. Section 26D of the PDPA requires notice to the Commission "as soon as is practicable, but in any case no later than 3 calendar days after the day the organisation makes that assessment". Section 26C(2) requires the assessment itself "in a reasonable and expeditious manner" once you have reason to believe a breach happened. And the 2021 Notification Regulations make your filing state when you first became aware and give a chronological account of what you did next. A slow assessment shows up in your own report.
Two PDPA details matter more for AI. A breach is notifiable on significant harm or on scale, set at 500 affected individuals. And section 26B(4) deems a breach that stays "only within an organisation" not notifiable. An agent that reads too much is a governance failure; one that sends data outward is a notification candidate.
MAS gives banks one hour, keyed to definitions written for outages. Paragraph 7 of MAS Notice FSM-N05 reads: "A Bank must notify the Authority as soon as possible, but not later than 1 hour, upon the discovery of a relevant incident." Insurers and other financial institutions sit under their own MAS notices, so check the one that names your licence. A relevant incident is a critical-system failure or an IT security incident with severe and widespread impact, or material impact on customer service. A credit model that keeps running while giving wrong answers is not obviously either. Our view: decide in the plan whether materially wrong AI output from a critical system counts as failure, and test that reading with your MAS review officer. The December 2025 circular then expects an initial report within 24 hours of discovery, via MAS-Tx since 1 February 2026.
The EU AI Act clock is law now, but it reaches few firms yet. Article 73 of the AI Act has applied since 2 August 2026. It requires providers of high-risk AI systems to report a serious incident within 15 days of awareness by default, 10 days where a person dies, and 2 days for a widespread infringement or a serious and irreversible disruption of critical infrastructure. Deployers must "immediately inform first the provider" under Article 26(5).
Regulation (EU) 2026/1744, the Digital Omnibus on AI, in force since 27 July 2026, did not amend Article 73. It deferred Chapter III, Sections 1 to 3 of the Act: the Article 6 rules that classify a system as high-risk, and the high-risk requirements and operator duties. Those now apply from 2 December 2027 for Annex III systems and 2 August 2028 for Annex I. Under the amended Article 111(2), high-risk systems already on the market before then are caught only if their design later changes significantly.
Our reading, an inference rather than the text of either regulation: few firms will have a live Article 73 clock before December 2027, because the rules that make a system high-risk do not yet apply. Providers selling into the EU should test that with counsel. One EU duty is live today for the model labs: since 2 August 2025, providers of general-purpose AI models with systemic risk must report serious incidents to the AI Office "without undue delay" (Article 55(1)(c)). Our July posts on the Hugging Face breach said Article 73 applies from 2 August 2026. That date stands; what changed is how many systems it reaches.
California's SB 53 is the vendor's clock, not yours: frontier developers report critical safety incidents to the state's Office of Emergency Services within 15 days. Use it in procurement: ask your provider to tell you when a reported incident touches your deployment. The GDPR's Article 33 72 hours applies only to EU personal data.
What should happen in the first hour?
In the first hour of an AI incident, stop the agent acting and save the evidence before anyone fixes anything. Then declare the incident with one named lead, test the event against each legal definition, and record three times. The order matters because rolling back first can destroy the record a regulator, or your own root cause report, will ask for.
Snapshotting sounds fussy until you see how AI systems change. Prompts get edited in place. Hosted models update quietly. Vendor logs expire on schedules you never set. For providers of high-risk systems, Article 73(6) of the AI Act goes further and bars altering the system in a way that may affect evaluation of the causes before informing the authorities. Stopping the agent is different from changing it: a tested kill path, described in our post on agent identity and least privilege, cuts the actions without touching the evidence.
The three times are first awareness, discovery and the day of assessment. Each starts or evidences a different clock. Log them as they happen, not on day four.
Illustrative example: a Singapore online retailer runs a customer-service agent with read access to its order system. A Friday evening prompt change makes it attach the previous customer's order summary, name and address included, to some replies. A customer complains at 10:00 on Saturday. The duty engineer switches the agent to draft-only by 10:20 and exports the logs before anyone edits the prompt. Compliance counts on Monday morning: 520 conversations affected. At 500 or more the breach is notifiable on scale alone, so the assessment is made Monday and PDPC must be notified by Thursday at the latest. At 480, the harm test decides instead. Either way the filing will show a Saturday complaint. The decision the example forces: start the assessment the day the complaint lands, because the count, not the calendar, decides which clock you are on.
The count, not the calendar, picks the clock
One weekend at an online retailer, Friday to Thursday. Illustrative, not measured data.
What goes into the plan itself?
An AI incident response plan adds four parts to your cyber plan: a system register, AI triggers, per-system containment and a clock map. The register records what each AI system can do; the clock map names who decides each legal test. It fits in a few pages. The effort sits in the register and the triggers, because those are what the cyber plan never had.
- The register. One row per AI system: the owner; the vendor and model; what data it touches, what it can do (read, draft, send, write, pay), and which clocks could apply. A system that can act outward goes to the top.
- The triggers. Feed the plan from places security does not watch: customer complaints, the rate at which human reviewers overturn AI decisions, a model bill that jumps, an agent calling tools outside its normal pattern. Our rule: any trigger on an agent that can send, write or pay opens an incident by default, and only the legal test can close it.
- Containment. For each system, how to stop it acting without stopping the business: a read-only or draft-only mode, a manual fallback, revocable credentials.
- The clock map. Who decides, within the first hour, whether the event is a personal data breach, a relevant incident for MAS, or nothing reportable. Name a person and a deputy: a bank has 1 hour from discovery under MAS Notice FSM-N05.
Each role reads this differently. The CTO owns the snapshot and the kill path, and should test both in a non-production run this quarter. The owner or MD decides who calls an affected third party when your agent was the intruder, because that call is commercial before it is legal. Compliance owns the three times and the definitions. Frontline staff matter at detection: customer complaints reach a support queue long before any dashboard.
Interactive check
Is your incident plan ready for an AI incident?
Seven checks drawn from the PDPA, MAS Notice FSM-N05 and the EU AI Act clocks above. Tick what is true today. A guide, not an audit. Nothing you enter leaves your browser.
0of 7 checks in place
Close these gaps first
A guide, not an audit. It reflects Origin Pi's reading of the instruments cited above, not a formal standard.
Where Origin Pi stands
We treat an AI incident as an operational event first and a legal event second. The legal tests matter, but you can only run them on evidence you kept and on a system you managed to stop. That is why the first hour is mostly decided at design time, long before anything goes wrong.
So we design agent deployments for the bad day. Bounded permissions let you stop one agent without stopping the business. A confirm step sits in front of any action that sends, writes or pays outside the company, which is exactly where the PDPA risk lives. And an audit trail records prompts, model version and tool calls at the moment they happen, so the snapshot exists before anyone thinks to take one. See also the Hugging Face breach and its defender's side.
Your next step: pick the one agent you run that can send something outside the company. Put the illustrative example above in front of your owner and compliance lead, with the engineer who runs that agent, for 30 minutes with a clock running. If nobody can say which of the three times starts which clock, that answer is the first page of your plan.
