On 20 September 2026, US Treasury Secretary Scott Bessent said Washington had proposed a mechanism for notifying China about AI incidents with national-security implications. The proposal, reported by Reuters, raises a useful question for business leaders: if an AI-enabled process caused a serious problem, how would the right people find out?

An organisation can spend considerable effort approving a system and still leave the response to failure poorly defined. Someone must recognise the incident, raise the alarm and have authority to intervene.

What happened

According to Reuters’ account of the New York talks, Bessent presented the notification proposal following discussions with Chinese Vice Premier He Lifeng. China’s response was unclear in that report. The mechanism was a proposal for consideration, not an established hotline or a completed agreement.

An international notification arrangement and a company’s internal incident process serve different purposes. The business lesson is an analogy: agreeing how to communicate when something goes wrong deserves attention before a crisis creates its own improvised chain of command.

Why it matters

Imagine an AI assistant repeatedly sending a customer the wrong contractual explanation. The first complaint reaches a service adviser, the second reaches an account manager and a third becomes a technical ticket. Each person may see an isolated problem while nobody recognises the pattern.

A useful reporting process brings those signals together. The initial report should identify the affected workflow, the observed behaviour, the possible consequence and whether the process is still running. It should preserve relevant evidence without spreading sensitive records through an unrestricted chat channel.

The person receiving that report needs a decision to make. They might hold outgoing messages, switch to an approved manual process or call in a specialist. Merely forwarding the concern to another inbox leaves the operational question unanswered.

I would also distinguish reporting from proving the cause. Employees should be able to flag a credible concern before they can establish whether the model, data, integration or instruction was responsible. Investigation can refine the explanation; the first response may need to contain the effect.

The bigger shift

As AI takes part in actions rather than simply producing drafts, management needs visibility into what happened after an instruction was given. A successful demonstration says little about the organisation’s ability to handle conflicting evidence, an unexpected recipient or a repeated action.

That makes response design part of the operating model. The owner must know how information reaches them, which decisions they can make and which consequences require an executive’s attention. The CEO’s Guide to AI Governance places these responsibilities within a wider structure of accountable ownership.

A reporting channel also depends on behaviour. If raising a problem is treated as an admission of incompetence, staff may wait for certainty. Leaders should reward clear early reporting and separate a good-faith warning from the later assessment of what caused the incident.

My take

I would test the alarm before expanding an AI workflow. Give the team a realistic scenario, such as an assistant sending an unsupported answer, and ask them to work through the response using their normal systems.

Can the first person identify the owner? Can that owner suspend the affected action? Does someone know how to continue essential work? What information would trigger an executive update, and who communicates with affected customers?

Record the delays and unresolved decisions. A named contact who is unavailable, or a stop control that requires someone nobody can reach, is a design gap to fix.

The goal is a response people can use under pressure. Prevention remains necessary, but leaders also need an honest route for bad news to travel and a clear person responsible for acting on it.