DECISION BRIEF 18 | TRUST, RISK AND DECISION INTEGRITY | 12 SEPTEMBER 2026

AI Incident Response: Who Can Stop and Restart the System?

An organization should not wait for an AI failure to discover who can stop the system. The CEO must establish stop authority, evidence-preservation rules, communication duties, and restart approval before a material AI-enabled workflow goes live.

AI changes incident response because a failure may spread through decisions, content, transactions, or connected tools before anyone sees a conventional outage. The business therefore needs an operating command, not only a technical ticket.

Decision Brief 18 | Evidence reviewed 12 September 2026 | Scope: Indonesia and Southeast Asia, informed by ASEAN guidance and international risk-management evidence

Decision Brief Library

Baca dalam Bahasa Indonesia

Editorial diagram showing five stages of AI incident response: detect, stop, preserve evidence, decide, and restart

Key evidence signals

The evidence does not show that every AI deployment will produce a serious incident. It shows that response authority, reporting, and traceability must be designed before harm occurs.

Signal	Leadership implication	Scope and limitation
About 17,501 incidents and hazards	AI risk is diverse enough to require structured classification, not a single generic escalation path.	OECD AIM result displayed on 11 September 2026. It is a beta automated media monitor; the count is not a prevalence estimate and does not represent official OECD views.
15 days	The EU AI Act sets an outer reporting window for many serious incidents involving high-risk systems once a causal link or reasonable likelihood is established.	Article 73 applies to defined providers and deployers in the EU market. It is not automatically an Indonesian reporting rule. Shorter windows apply in specified cases.
2 days	Widespread infringement or serious disruption of critical infrastructure can trigger a much faster reporting deadline.	EU AI Act scope and definitions apply. The number is useful design evidence, not a universal company deadline.
Internal and external reporting	ASEAN guidance says organizations need internal reporting channels, tools, training, incident-management processes, and external reporting capacity where required.	Expanded ASEAN Guide on AI Governance and Ethics, January 2025. It is regional guidance, not binding law.
Current disclosure pressure	Reporting from 5 to 11 September documented further disclosures about unintended or unauthorized agent activity, including more than ten sites and a separate RubyGems incident.	Reuters reporting concerns research and testing. OpenAI confirmed parts of the activity, while RubyGems disputed or could not verify other details. It does not establish an enterprise incident rate.

Direct answer

Give the nearest accountable operator authority to stop a workflow, but reserve high-consequence restart approval for the executive who owns the business outcome. The CEO should set the thresholds, not personally manage every alert.

The response model should separate five decisions: detect, stop, preserve, communicate, and restart. Each needs a named owner, a time threshold, and evidence that can be reviewed after the event.

The decision question

If an AI-enabled workflow begins causing material harm at 2 a.m., who can stop it without waiting for a committee, and who can restart it the next morning? If the organization cannot answer both questions, the deployment is not operationally ready.

The useful unit is the workflow, not the model alone. The incident may involve the model, data, prompts, retrieval, permissions, integrations, a vendor change, or a human decision made from an AI output.

The conventional assumption being challenged

The legacy assumption is that an AI failure is either a cybersecurity incident or a software defect. That is too narrow.

An AI incident can occur without a breach or outage. A system may produce plausible but wrong recommendations, discriminate across customer groups, disclose confidential information, execute an unauthorized action, or silently degrade after a model or data change.

Traditional incident teams are optimized for availability, integrity, confidentiality, and recovery. Those capabilities remain essential. They need an AI-specific layer that can judge output quality, business harm, affected decisions, model provenance, and whether a safe fallback exists.

What AI changes

AI increases the speed of propagation while making causality harder to reconstruct. It also distributes responsibility across suppliers, internal teams, data owners, workflow owners, and users.

Five changes matter:

A system can be available and still be unsafe. Uptime does not reveal whether the output is inaccurate, biased, manipulative, or outside policy.
The same input may not always produce the same output. Reproduction requires prompt, model, version, system instructions, retrieval context, tool calls, and user actions.
Connected agents can turn a poor answer into an action. Permission design and transaction controls become part of incident containment.
Vendor changes can alter behavior without a conventional release inside the company. Contracts and monitoring must make consequential changes visible.
Human reliance becomes part of the failure. The organization must examine how people interpreted, checked, overrode, or followed the system.

AI can augment anomaly detection, log correlation, case clustering, and response drafting. It should not decide alone whether to suspend a critical service, disclose an incident, compensate affected people, assign accountability, or authorize a restart.

Point of View

The right control is not a universal kill switch. It is a pre-authorized stop path for each material workflow, paired with a credible fallback and a higher bar for restart than for launch.

A universal shutdown can create new harm in healthcare, financial operations, logistics, or customer service. The business should be able to isolate the affected function, revoke risky permissions, switch to a manual or rules-based path, and preserve evidence without destroying the entire operating environment.

This is why the CEO owns the design of decision rights, while operational leaders own execution. A committee that must assemble before a stop decision is not a control; it is a delay mechanism.

Thought Process

Start from business harm, then work backward to detection, containment, evidence, communication, and recovery. Model-centric monitoring alone will miss incidents that appear only in customer, employee, or transaction outcomes.

1. Define materiality before the incident

Materiality should reflect the workflow. Useful categories include financial loss, customer harm, safety, legal or regulatory exposure, confidentiality, discrimination, operational disruption, and loss of decision integrity.

Use three levels:

Level 1: contained deviation. No material external impact; the owner can correct it within normal operations.
Level 2: significant incident. Repeated or material impact; the workflow owner must stop or isolate the affected function and notify risk, security, legal, and communications.
Level 3: enterprise crisis. Severe, widespread, regulated, safety-related, or reputation-threatening impact; the CEO or delegated crisis leader owns the business decision and board escalation.

The thresholds should be quantitative where evidence permits, but they must also include qualitative triggers. One discriminatory hiring decision or one disclosure of highly sensitive data may matter more than a large count of harmless errors.

2. Put stop authority close to the workflow

The person who detects the failure should not need CEO approval to contain immediate harm. Pre-authorized actions can include pausing automated decisions, revoking agent permissions, disabling a tool connection, routing cases to human review, or switching to a tested fallback.

The CEO decides which actions are pre-authorized and which business consequences require escalation. The operating owner executes. Security, risk, data, legal, and communications provide specialist judgment.

3. Preserve evidence before changing the system

Response teams often fix first and reconstruct later. AI makes that dangerous because prompts, retrieved documents, tool calls, model routing, safety settings, and human overrides may be ephemeral.

The evidence bundle should capture:

affected inputs and outputs, with lawful privacy controls;
model, version, provider, and routing information;
system instructions, retrieval context, and tool calls;
permissions and transactions executed;
timestamps, monitoring alerts, and human interventions;
affected customers, employees, decisions, or records;
vendor notifications and configuration changes.

Evidence preservation should respect privacy, legal privilege, employment rules, and data-minimization requirements. More logging is not automatically better if it creates a second source of risk.

4. Separate containment from communication

Stopping the workflow is not the same as deciding what to disclose. The organization needs a communications path for affected people, customers, suppliers, regulators, insurers, employees, and the board.

Early communication may be incomplete. It should distinguish confirmed facts, working hypotheses, unknowns, immediate protections, and the next update. False certainty can damage trust as much as silence.

5. Require evidence for restart

The team that fixed the issue should not be the only party deciding that the workflow is safe. Restart should require independent challenge proportionate to the consequence.

Minimum restart evidence includes:

the failure mode is understood well enough to control;
affected permissions or integrations are constrained;
the fix passes representative and adversarial tests;
the fallback path remains available;
monitoring can detect recurrence;
required notifications and remedies are underway;
a named executive accepts the residual risk.

Three operating options

Most companies should integrate AI incidents into existing crisis and cyber-response systems, then add AI-specific triggers, evidence, and restart rights. A separate command structure is justified only when the risk and scale require it.

Option	Advantage	Trade-off	Best fit
Extend the existing cyber process	Fast to implement; uses an established command structure	Can over-focus on breach and uptime while missing output and decision harm	Early AI portfolio with limited autonomy
Create a separate AI incident team	Deep technical focus and clearer specialization	Risks fragmentation, duplicated escalation, and unclear business ownership	Large, high-risk AI estate with dedicated capability
Integrate one enterprise command with an AI playbook	Combines business, legal, security, operational, and model evidence	Requires disciplined decision rights and cross-functional exercises	Most enterprises scaling AI across workflows

The integrated model is the default recommendation. It keeps one crisis command while recognizing that AI evidence and restart decisions are different from conventional software recovery.

Decision rights

The CEO should decide the materiality framework, delegated stop authority, disclosure principles, and high-consequence restart rights. The CEO should not become the first-line incident manager.

Action	Primary owner	CEO role
Detect and classify	Workflow owner with risk and security	Require coverage and thresholds
Stop or isolate	Pre-authorized operator	Approve the delegation model
Preserve evidence	Security, data, legal, and model owner	Require traceability as a deployment condition
Assess harm and notify	Legal, risk, communications, and business owner	Decide material trade-offs and board escalation
Remediate and test	Product, engineering, vendor, and control owners	Demand independent challenge for material systems
Restart	Accountable business executive; CEO for Level 3	Accept residual risk or refuse restart

A smallest credible 30 to 90 day test

Run one live tabletop exercise on the highest-consequence AI-enabled workflow that already has real users. Do not begin with a policy workshop disconnected from operating systems.

Setup

Choose one scenario, such as confidential data disclosure, unauthorized transaction, discriminatory recommendation, vendor model change, or agent action outside approved permissions.

Success conditions

the team detects and classifies the event within the agreed time;
the authorized operator stops or isolates the workflow without waiting for an ad hoc committee;
the fallback preserves the most important business service;
the evidence bundle can reconstruct the event;
communication owners produce a fact-based first update;
restart reviewers identify the control changes and residual risk;
every decision has a named accountable owner.

Failure conditions

no one is willing or able to stop the system;
logs cannot identify the model, prompt context, permissions, or actions;
the vendor owns information the company cannot obtain promptly;
the fallback is untested or creates a larger risk;
business, security, risk, and legal teams disagree about who leads;
restart occurs because commercial pressure rises, not because evidence improves.

Stop conditions

Suspend expansion of the workflow if the exercise cannot reproduce material decisions, revoke dangerous permissions, activate a safe fallback, or identify the executive who accepts restart risk.

The decision test

Do not scale a material AI-enabled workflow unless the organization can answer yes to all five questions.

Can the right person detect and classify harm using workflow-specific thresholds?
Can an authorized operator stop or isolate the affected function immediately?
Can the team preserve enough lawful evidence to reconstruct what happened?
Can the company communicate confirmed facts and meet applicable duties?
Can an accountable executive refuse restart until controls are proven?

If any answer is no, the next investment should fund operational readiness before additional autonomy.

Testable hypotheses

Pre-authorized stop rights will reduce containment time without increasing unnecessary shutdowns when thresholds are workflow-specific.
An AI evidence bundle will shorten root-cause analysis compared with conventional application logs alone.
Independent restart review will reduce recurrence in material workflows.
A tested fallback will increase adoption because employees and customers can see that AI failure does not remove human accountability.

These are operating hypotheses. Each organization should test them against its own risk, workflow, regulation, and customer expectations.

Implications for decision-makers

AI incident response is an operating-model obligation, not a document owned by security. Boards should ask whether the company can stop, explain, and safely restart the systems that influence consequential decisions.

For the CEO, the practical implication is to fund traceability and fallback capacity as part of value creation. For the board, it is to test whether escalation and restart rights remain clear under pressure. For the CIO and CISO, it is to connect model, data, identity, tool, and transaction evidence. For business leaders, it is to remain accountable for the workflow even when the model comes from a vendor.

FAQ

What counts as an AI incident?

An AI incident is a failure or harmful event in which an AI-enabled workflow contributes to material business, customer, employee, safety, legal, security, or decision-integrity impact. It can occur without an outage or cyber breach.

Who should own AI incident response?

The accountable business owner should own the outcome. Security, risk, legal, data, product, communications, and the vendor support the response. The CEO sets enterprise thresholds and owns Level 3 trade-offs rather than managing every alert.

When should a company stop an AI system?

Stop or isolate the affected function when credible evidence indicates material harm, unauthorized action, loss of control, or an inability to verify critical outputs. The threshold should be defined before deployment and tied to the workflow’s consequence.

Is the vendor responsible for the incident?

The vendor may be responsible for part of the failure, but the deploying company still owns its use, permissions, customer impact, and operating decisions. Contracts should require prompt evidence, change notification, support, and remediation.

What should the board ask after an incident?

Ask what happened, who was affected, how the system was stopped, what evidence was preserved, what obligations were triggered, what remains unknown, and who has authority to restart. The board should also ask what will prevent recurrence.

Source notes

Evidence reviewed on 12 September 2026.

Geographic limitation: ASEAN guidance is regional and voluntary. EU reporting deadlines apply only where the regulation’s scope and definitions are met. The Reuters incidents concern AI research and testing and should not be generalized into an enterprise incident rate.

Continue Reading

About the author

Antovany Reza writes CEO Decision Lab, an independent decision platform for AI-fluent leaders who must turn AI and digital transformation into business value, stronger judgment, and accountable execution.

Discuss this decision

If your organization is defining stop authority, evidence requirements, or restart conditions for an AI-enabled workflow, start a focused conversation.

Facebook

Copy link