AI Workflows: Everyone Needs a “Pause” Button

This recent blog from The AI Consultancy discusses Open AI’s decision to pause reinforcement-learning training on its latest Astra model for two weeks due to concerns about a potential mismatch between the model’s capabilities and its controls around training and evaluation.  The blog says that everyone using AI can learn from Open AI’s example, observing that while most companies have invested in policies for approving AI, far fewer have devoted attention to the conditions that should cause them to pause an AI tool – before it’s too late.

This excerpt discusses the features that are essential components of a “stop” rule:

A usable stop rule answers four questions before an incident begins.

First, what can be paused? The answer should be more precise than “the AI”. A business may need to stop one task, a queue, a connector, a model version or the complete workflow. Granular control prevents a problem in one route from causing unnecessary disruption elsewhere. It also makes leaders more willing to intervene early because the operational cost is bounded.

Second, who has the authority? The owner of the business process should not be the only person able to suspend it. Delivery pressure can make that owner reluctant to stop a system that appears commercially successful. Security, operations or a designated duty manager needs independent hold authority for defined events. Staff using the workflow should have a visible escalation route and protection from blame when they report a credible concern.

Third, what triggers the hold? Vague wording such as “unexpected behaviour” leaves every decision open to argument. Triggers can include access to data outside the approved scope, use of an unapproved tool, missing audit records, a provider security notice, a material rise in error rates, repeated attempts to work around a constraint or a model change that has not passed regression testing.

Some triggers should stop activity automatically. Others should create a short review window. The choice depends on potential impact and how easily an action can be undone.

Fourth, how will the business operate while the workflow is unavailable? A stop rule without a fallback can become politically unusable. Teams will leave a risky system running when suspension means losing an essential service with no alternative. Manual handling, a reduced-function route or a queue that safely holds work can preserve continuity while evidence is examined.

The blog says that these decisions need to be made during the product design process because they affect the product’s architecture.  It also argues that the restart process deserves the same level of attention as the decision to pause, and that supplier contracts should expressly incorporate a right of the buyer to hit a stop button.