For Australian businesses running AI in front of customers, staff or money

Building an AI Incident Response and Escalation Plan

Sooner or later an AI system in your business gets something wrong in a way that reaches the outside world. A wrong quote emailed to a customer. An appointment booked into a clinic that is closed. A client name in an output another client can see. A confident fact in a document that turns out to be invented. A sync to your accounting package that quietly stopped and told nobody. The question worth answering now is whether the next fifteen minutes are a controlled response or four people guessing on a group chat at 8pm. Yes AI writes the plan, builds the controls it depends on, and rehearses it with your team before go live.

Severity tiers that match your real blast radius, one named owner per level, a first hour checklist, a kill switch anyone can operate, preserved logs and transcripts, customer notification wording drafted in advance, Notifiable Data Breaches assessment where personal information is involved, and a review that turns every incident into a guardrail and a test. If you have no documented rollback, you have not finished deploying.

Book a Incident Readiness Call (03) 9003 0111

Realistic ROI

Minutes

From first alert to switched off

A tested kill switch operated by a named person, instead of an hour spent working out who to ring and whether anyone is allowed to stop it

One owner

Named at every severity level

Every tier has a person and a backup with a mobile number in the plan, so an incident never starts with the words who owns this

Full trail

Logs and transcripts preserved

Evidence is snapshotted before anything is redeployed, so you can answer a customer, a regulator or your insurer with facts rather than recollection

1 to 3 weeks

From workshop to rehearsed plan

Most Australian SMEs get a written, owned and drilled plan inside a fixed, agreed timeframe once we have mapped the failure modes

Why Build Your AI Incident Plan With Yes AI

Plenty of consultancies will sell you an incident response template, and a template is worth roughly what an unrehearsed fire drill is worth. The plan only earns its place if the controls it refers to actually exist, if the people it names have used them, and if it survives contact with a real Tuesday afternoon. Four things we do differently.

The plan is written before go live, not after the incident

We treat the incident plan as a go live gate, in the same way you would not turn on a new phone system without knowing how to fall back to the old one. Before an AI system takes a call, drafts a document, touches a customer record or writes to your accounting package, we have already agreed what a serious failure looks like for that specific deployment, who gets told, what gets switched off, and what the business does in the meantime. Writing it afterwards means writing it during an argument.

We build the controls, not just the document

Plenty of the incident plans we are handed refer to a kill switch that does not exist, logs that were never enabled, and an alert that goes to a shared inbox nobody watches. We build the parts the plan depends on: a per channel off switch a non-technical manager can operate from a phone, a defined graceful degrade so calls, forms and sync jobs fail to a human path rather than into silence, structured logging of inputs, outputs and the configuration version in force at the time, and alerts that fire on absence of activity as well as on errors.

Australian obligations handled properly, not hand waved

Where personal information is involved, we work the plan against the Privacy Act 1988 and the Australian Privacy Principles, including the Notifiable Data Breaches scheme and its assessment window. We are honest about which parts apply to your business, because the small business turnover exemption has real carve outs and health service providers are covered regardless of size. Where something is voluntary or proposed rather than law, such as the Australian Government Voluntary AI Safety Standard, we say so plainly rather than selling you compliance with a rule that does not exist yet. This is general information rather than legal advice, and where the stakes are high we will tell you to run the plan past your own lawyer.

Rehearsed with your actual staff, not filed in a drive

We run a tabletop walkthrough with the people who will really be on the end of it: the practice manager, the office coordinator, the operations lead, the owner. We give them a scenario, they work the plan, and we watch where it breaks. Rehearsals routinely surface something, commonly that the only person who can switch the system off is on annual leave, or that nobody is sure which mailbox the alerts land in. Better to find that in a meeting room than at 7pm on a Friday.

The Six Parts of a Plan That Actually Works

An AI incident plan is not a generic IT runbook with the word AI pasted over it. AI systems fail differently: quietly, confidently, at scale, and in ways that generate a plausible looking output rather than an error message. These are the six components we build for every deployment we put in front of customers, staff or money.

Three levels

Severity tiers defined by blast radius

We grade incidents by how far the damage reaches and how reversible it is, not by how loudly someone complained. A serious incident means personal information was exposed, money moved or was committed, or many customers were told something materially wrong. A moderate incident means one customer was affected and it is contained. A minor incident means quality degraded with no external impact. Each tier has its own response time, its own owner and its own notification list, and the tiers are written against your business, so a wrong dosage instruction and a wrong opening hour are never in the same box.

Named pager

One named owner per level, with a backup

The plan carries real names and real mobile numbers, plus a nominated backup for each, because AI systems answer at 11pm and on public holidays. It also states who is allowed to declare an incident, which matters more than people expect: junior staff routinely notice the problem first and then wait for permission to raise it. We give them explicit authority to escalate and to trigger the shutdown, and we make sure the person on the pager is inside your business rather than only your supplier.

Contain first

A first hour checklist that contains before it diagnoses

The single most common mistake is trying to work out why while the system keeps doing it. The checklist is ordered deliberately: stop the automation, switch the affected channel to the human fallback, freeze any outbound queue, capture the evidence, then start diagnosing. It names the exact screens and buttons rather than describing them, states how to check what else went out in the same window, and finishes with a short written note of what was seen and when, timestamped in local time, while it is still fresh.

Tested before go live

A kill switch tested against the real system

Every AI deployment needs a documented, tested way to turn it off, per channel, before it goes live. Not a support ticket, not a call to a developer. We make it operable by a non-technical manager, we define what happens once it is off so the business keeps running, and we test it against the live system before go live and again on a schedule. Off must mean calls divert with a sensible message, web forms email a person, drafting reverts to a blank document, and sync jobs pause and queue rather than dropping records on the floor.

Snapshot first

Evidence preserved before anything is fixed

The instinct to fix it immediately destroys the record of what happened. We snapshot the transcripts, the inputs and outputs, the exact prompt and configuration version in force, whatever source material was retrieved, the timestamps, and the downstream action taken in your other systems. This matters because retention windows on platforms are often short and a redeploy overwrites the configuration that caused the problem. Preserved evidence is what lets you answer a customer, an insurer or a regulator with facts.

Drafted in advance

Customer notification and privacy assessment

We write the notification wording before you need it: what a customer is told when a quote was wrong, when a booking was never real, or when their information appeared where it should not have. The plan names who signs it off, whether it goes by phone or in writing, and how the record is corrected rather than quietly patched. Where personal information is involved, it steps through the Notifiable Data Breaches assessment: whether there was unauthorised access, disclosure or loss, whether serious harm is likely, and whether the OAIC and the affected individuals need to be told.

Six AI Incident Scenarios and What the Plan Changes

Task	Traditional	With Yes AI	Notes
A wrong quote is emailed to a customer	Discovered when the customer accepts it, then argued about internally for a day	Detected on a price sanity check, sent quotes frozen, customer phoned within the hour	The plan says correct the record by phone, not by a silent second email. It also asks the question most businesses forget in the moment: how many other quotes went out on the same faulty logic before anyone noticed.
A booking is made into a closed clinic or an unstaffed slot	Nobody knows until the patient arrives at a locked door and posts a review	Booking channel paused, the day and the following week audited, affected patients called first	The detail that matters is the audit sweep. One bad booking is almost never one bad booking, it is a rule that has been wrong since the change was made, so the plan forces a look back over the whole affected window.
Personal information appears in an output it should not	Treated as an embarrassing glitch and quietly deleted, with no assessment done	Treated as a possible eligible data breach, evidence preserved, assessment started that day	This is the one with a statutory clock attached where the Privacy Act applies to you. Deleting the output does not undo the disclosure, and it destroys the evidence you would need to show the assessment was done properly.
A hallucinated fact appears in a document that went out	Found weeks later by a client, damaging trust in every other document you sent	Source checking flags the unsupported claim, the document is reissued with a correction	The recovery work is not the fix, it is the sweep of every other document produced by the same process. The plan sets that expectation up front so nobody has to argue for the time to do it.
An integration silently stops syncing to your accounting package	Noticed at month end when the numbers do not reconcile and a week of records are missing	A heartbeat alert fires the same day on volume dropping to zero, the queue is replayed	Silent failures are the ones that hurt most, because no error is ever raised. The plan treats a suspicious quiet period as an incident in its own right rather than as good news.
A voice agent gives wrong information at volume overnight	Hours of bad calls before anyone opens the inbox in the morning	Out of hours alert reaches the named owner, the line diverts to voicemail within minutes	This is why the after hours owner and the graceful degrade are written down. Diverting to a clear voicemail message is a far better outcome than an agent confidently continuing to be wrong until nine in the morning.

Six Honest Realities About AI Incidents

The failures that hurt most never raise an error

A traditional system breaks loudly. An AI system produces a fluent, well presented, completely wrong answer and returns success. A stopped sync returns nothing and looks like a quiet week. So error monitoring alone only ever catches the failures that announce themselves, and those are rarely the expensive ones. We instrument for absence and for shape: expected volume by hour, output distributions, records that should have appeared and did not, and a heartbeat that alerts when a job simply stops running. The absence of alerts is not evidence that anything is working.

The system cannot reliably tell you when it is wrong

Do not build your escalation on the model reporting its own confidence, because that confidence is not calibrated and it will be just as certain when it is inventing a fact as when it is reading one. Escalation triggers have to be structural and checkable from outside: did this number come from the source system or from nowhere, is this booking inside published opening hours, does this customer exist in the CRM, does the total match the line items. AI can draft, summarise and route very well. It is not a reliable judge of its own output, so the guardrail has to sit around it, not inside it.

What has already gone out cannot be recalled

Rollback is much harder than rollout, and this is the part most plans skip. You can revert a configuration in seconds. You cannot un-send an email, un-say something on a phone call, un-lodge a booking in a patient system, or un-post a journal in your accounting package. So the plan has to separate stopping the cause from repairing the effect, and the repair is almost always human work: phone calls, credit notes, corrected documents, apologies. We size that honestly at design time, which is usually the argument that wins you a human approval step on the highest risk actions.

Your incident logs are personal information too

Transcripts, prompts and captured outputs frequently contain customer names, health details, addresses and financial information, which means the evidence you preserve for good reasons quietly becomes a second privacy surface. Logging everything forever is not the safe option, it is a larger breach waiting to happen. We set retention periods, restrict who can read transcripts, redact where redaction does not destroy the evidential value, and store the material somewhere you can actually account for. Decide this before go live, because you will not want to be designing it while an incident is running.

A plan nobody has rehearsed is a filing exercise

The failure mode of unrehearsed plans is depressingly consistent: the only person who understands the shutdown is on leave, the alert address belongs to someone who left, the document lives in a drive nobody can find at 7pm, or the kill switch turns out to require your supplier to be awake. A twenty minute tabletop walkthrough surfaces that kind of thing while it still costs you nothing. We rehearse before go live, again after any significant change, and at least twice a year, and we treat anything the rehearsal breaks as a defect to fix rather than a note to file.

Do not let the AI run its own incident

When something has gone wrong, the last thing you want is the same system apologising to customers, writing the incident summary or deciding what severity it was. It has already demonstrated it cannot be trusted on this particular thing, and an automated apology can create commitments you did not intend to make. During an incident, communication is human, the severity call is human, and the decision to switch it back on is human and written down. Automation comes back once the fix is tested, not because the alert stopped firing.

How Yes AI Helps

The written plan and severity ladder

We produce a short, usable document rather than a forty page policy nobody opens: severity definitions written against your business, named owners and backups with contact details, the first hour checklist, notification wording, and the escalation path through to the owner. It is written in plain English so the person holding it at 7pm can follow it without an interpreter.

The controls the plan depends on

We build the parts that make the plan real: a per channel kill switch a manager can operate, a defined graceful degrade so the business keeps running with it off, structured logging of inputs, outputs and configuration versions, evidence snapshots, and approval gates on the highest risk actions. If the plan mentions a control, we make sure that control exists and has been tested.

Detection and alerting that catches the quiet failures

We monitor for the things that never throw an error: volumes dropping to zero, jobs that stopped running, outputs drifting out of their expected shape, queues backing up, retrieval returning nothing. Alerts go to a named person on a channel they actually watch, with thresholds tuned so they stay meaningful instead of becoming noise everyone learns to ignore.

Post-incident review and the feedback loop

We run the review blameless and fast, within a few business days while people still remember it, and we insist the output is concrete: a change to the prompt or the guardrail, a new structural check, an added approval step, and a regression test that reproduces the original failure. An incident that does not become a test case is an incident you have agreed to have again.

How We Build and Rehearse Your Plan

Five steps from a first conversation to a plan your team has actually used in anger, at least in a meeting room. Most Australian SMEs are done inside one to three weeks, depending on how many AI systems are in scope and how much of the underlying control work still needs building.

Map the failure modes that matter

We work through every AI system you have running or are about to switch on and ask the uncomfortable question for each one: what is the worst thing this could do before a human notices. Wrong money, wrong clinical or safety information, personal information in the wrong hands, a commitment made to a customer you cannot honour, a record silently lost. We rank them by blast radius and reversibility, and that ranking becomes the spine of the plan.

Write the severity ladder and the plan

We define your severity tiers against those real failure modes, name an owner and a backup for each, set response times you can genuinely meet with the staff you have, and write the first hour checklist naming actual screens and buttons. We draft the customer notification wording in advance and decide who signs it off, so nobody is composing a sensitive message under pressure.

Build the kill switch, the logging and the alerts

We build or verify every control the plan relies on: the per channel off switch, the graceful degrade behaviour, structured logging with configuration versions, evidence snapshotting, retention and access rules for transcripts, and alerting that fires on silence as well as on errors. Then we test the kill switch against the live system, because a control that has never been operated is an assumption.

Rehearse it with the people who will use it

We run a tabletop walkthrough with your real staff and a real scenario. They find the plan, they follow it, they operate the switch, they draft the customer message. We time it and note every point where it stalled. Anything the rehearsal breaks gets fixed before go live, and the rehearsal itself is repeated after major changes and at least twice a year.

Review, feed back, and keep it current

After any incident we run a blameless review within a few business days and turn it into specific changes: tighter guardrails, a new structural check, a revised prompt, an added approval step, and a test that reproduces the failure so it cannot silently return. The plan itself is reviewed when systems change and at a set interval, and it stays owned by a named person rather than by everybody.

FAQ

What actually counts as an AI incident?

Anything where an AI system in your business produced an outcome you would not have signed off on, and it reached the outside world or your systems of record. A wrong quote sent to a customer. A booking made into a slot that is closed or unstaffed. Personal information appearing in an output someone else could see. A confident invented fact in a document you issued. An integration that stopped syncing without raising an error. It is worth writing the definition down, because the failure mode we see most often is staff noticing something odd and deciding on their own that it probably does not count. Give people an explicit low bar for raising it, and grade severity afterwards.

Who should own the kill switch?

Someone inside your business who is normally reachable, with a named backup, and it must be operable without technical help. If the only way to stop the system is to email your supplier and wait, you do not have a kill switch, you have a support ticket. In practice the right owner is usually an operations lead or a practice manager rather than the business owner, because they are the person actually watching the day. We put the names and mobile numbers in the plan, give junior staff explicit authority to trigger it without waiting for permission, and test that each named person has genuinely operated it at least once.

How fast do we have to act?

Containment should be minutes, not hours, and it is the only part that has to be that fast. Switch the affected channel off, freeze the outbound queue, revert to the human path. Diagnosis can wait, and trying to diagnose while the system keeps running is how a small incident becomes a large one. From there the clocks are situational: customer contact is usually best the same day and by phone where money or trust is involved, and where personal information is involved the Notifiable Data Breaches scheme sets out an assessment window of up to 30 days from becoming aware of the circumstances, with notification as soon as practicable if the breach is assessed as eligible.

Do the Notifiable Data Breaches rules apply to our business?

It depends on who you are, and we will tell you plainly rather than assume. The Notifiable Data Breaches scheme sits under the Privacy Act 1988 and applies to entities covered by that Act. Many small businesses with annual turnover under three million dollars are exempt, but the exemption has significant carve outs: health service providers of any size are covered, as are businesses that trade in personal information, some contracted service providers, and organisations handling credit reporting or tax file number information. Removing the small business exemption has been raised in privacy reform work but has not happened, so we plan against the law as it stands while noting it may change. Where the scheme applies, an eligible data breach means unauthorised access, disclosure or loss of personal information that is likely to result in serious harm, and it requires notification to the OAIC and to the affected individuals. All of that is general information rather than legal advice. We build the plan so the assessment gets started properly and on time, and for the call on whether a specific breach is eligible we will point you to your own lawyer.

What do we tell the customer?

The short version is tell them early, tell them yourself, and correct the record rather than patching it quietly. We draft the wording in advance for each of your likely scenarios so nobody is composing something sensitive under pressure at the worst moment. Where money or trust is involved, a phone call from a person beats an email, and a second silent email correcting the first is the option most likely to be read as a cover up. The plan also names who signs off external communication, which stops well meaning staff sending three slightly different versions of the story to three different customers.

Do we need this if the AI only drafts and a human sends?

Yes, and the reason is worth understanding. A human review step reduces risk, it does not remove it, because reviewers wave through fluent, confident, correctly formatted output far more readily than output that looks rough. Over a few weeks the check quietly becomes a formality. You still need the plan for the case where something wrong got approved and went out, and you still need the logging to work out how many others were approved on the same basis. The plan for a drafting system is lighter than the plan for a system that acts on its own, but it is not nothing.

How long does it take and what does it cost?

For most Australian SMEs the plan itself takes one to three weeks from the first workshop to a rehearsed document, and the length depends far more on how much of the underlying control work still needs building than on the writing. If the kill switch, the logging and the alerting already exist, it is fast. If they do not, that build is the real work. We scope it honestly rather than quoting sight unseen: strategy engagements start at $1,000 for a focused BASIC piece, $3,000 for a STANDARD engagement, and $10,000 for a STRATEGIC one covering a broader estate. You get a fixed scope, timeframe and price before anything starts.

Is there an Australian standard we should be following?

There is guidance rather than a general legal requirement, and it is worth being precise about the difference. The Australian Government has published a Voluntary AI Safety Standard setting out guardrails covering accountability, risk management, testing, human oversight, record keeping and incident response, and as the name says it is voluntary. Mandatory guardrails for AI in high risk settings have been proposed and consulted on but are not law. Internationally, ISO/IEC 42001 provides a certifiable AI management system standard if you need something formal for enterprise or government customers. What does bind you already is the law that has always applied: privacy obligations where you hold personal information, consumer law obligations for what you tell customers, and your professional or sector specific duties. No regulator accepts the system said it as an explanation, so the practical answer is to build the plan around obligations you already have.

Write the Plan Before You Need It

Book a call and we will walk through every AI system you have running, work out what the worst realistic failure looks like for each one, and tell you honestly which controls you are missing. If you are already live without a documented rollback, that is the conversation to have this week.