An AI risk threshold needs a response attached to it

Bill Gates’s August 26 essay argues that AI’s transition brings risks to employment, security and human relationships. It mixes observations, forecasts and policy proposals. On evidence about AI companions, he explicitly describes the research as small and mixed. The essay makes a case for preparation; it is not a deployment acceptance test.

That is the distinction I would preserve when an executive asks whether we have crossed an AI danger threshold. Before answering, name the system, the relevant harm and the action that crossing would trigger.

A threshold without a response can organise a conversation. It cannot operate a release gate.

I do not need to dismiss a broad warning to ask for that precision. Public arguments can identify priorities before the evidence supports a single universal metric. The enterprise still has to decide what it will observe and what it will do next.

Turn the concern into an observable condition

Take a hypothetical internal assistant with permission to update business records. A concern about loss of control is too broad to serve as its only acceptance criterion. I would translate it into conditions that the specific system can be tested against.

One condition might concern whether the assistant can make an unauthorised write. Another might concern whether it continues a consequential workflow after a stop instruction. Each requires a defined environment, a clear expected result and evidence that distinguishes a model’s verbal agreement from the surrounding system’s actual behaviour.

The policy should say what happens when the condition fails. The response could be blocking a release, narrowing permissions or requiring a different review path. The owner should be named before the result arrives, especially if the result would delay a launch.

Those are illustrative conditions for that assistant. They are not proposed universal thresholds for every AI risk domain, and passing them would not prove that the system is safe in all respects.

Keep uncertainty inside the decision

I would also define how much evidence is enough to act. A severe, credible failure may justify stopping after one observation. A noisy performance change may require repeated measurement. The evidence rule should match the consequence rather than use the same pass percentage everywhere.

Then I would record the limits of the test. A system can pass within a constrained environment while behaving differently with new tools, longer tasks or broader access. The release approval should name those boundaries so that a later expansion triggers a new assessment.

For the hypothetical assistant, I would rehearse the escalation path with a synthetic failure. Can the team disable the relevant capability? Can it identify affected work? Does someone have authority to decide when service resumes? A score without that operating response is an incomplete control.

This is where a sweeping warning can become useful local work. It directs attention toward a risk; the team supplies the concrete system boundary, measurement and action. Those steps should remain visible instead of borrowing certainty from the person who delivered the warning.

The public debate can continue about the speed and scale of AI’s effects. Our release process still needs an answer that someone can implement on Monday.

Define the signal, the evidence standard and the response owner before calling something a risk threshold.