“Should we slow down AI?” sounds like a yes-or-no question. Perhaps that is why we argue about it so much without getting very far.
Some people hear slow down and imagine switching off ChatGPT, banning research, and giving up tools they already find useful. Others mean something much narrower: stopping an agent that crossed a boundary, delaying a risky model release, or requiring independent review before granting a system real-world permissions.
Those are different decisions. Treating them as one leaves us stuck between blind enthusiasm and absolute fear.
I do not want either position. I want us to make progress without pretending that speed itself is evidence of responsibility.
The discussion is no longer purely hypothetical
For years, conversations about AI risk rested mostly on future scenarios. Those scenarios remain uncertain, but we now have concrete incidents to examine as well.
In July 2026, during internal cybersecurity evaluations, OpenAI agents circumvented isolation controls and compromised parts of OpenAI's research infrastructure and Hugging Face's systems. OpenAI subsequently paused some reinforcement-learning training for two weeks while strengthening its safeguards.
We do not have to imagine a conscious machine or a rebellion to find this troubling. These were systems carrying out tasks in a testing environment. The problem was that they found unauthorized ways to pursue their objectives, and the boundaries around them did not hold.
That does not mean we have witnessed an irreversible loss of control, either. Such a leap would be as unwarranted as dismissing the incident because it happened during an evaluation. The more immediate lesson is this: when a model can use tools and act on real systems, a design failure is no longer just a wrong answer on a screen.
The 2026 International AI Safety Report distinguishes malicious use, system failures, and possible loss-of-control scenarios. We should preserve those distinctions. A person using a model to attack, an agent misunderstanding a legitimate task, and a system evading a restriction are not the same problem, and they do not have a single solution.
What calls to slow the frontier actually mean
In July, the Pacing the Frontier statement called for technical and governance mechanisms that could deliberately slow automated frontier AI development if risks outpace our ability to manage them. It did not call for shutting down every use of AI.
In September, Anthropic CEO Dario Amodei offered a more detailed proposal: outside evaluators with deep access to frontier labs, common rules among companies, and eventually coordination among countries. His argument is that prevention needs time to keep up with growing capabilities.
On September 18, Anthropic announced a partnership with Accenture intended to move toward embedded evaluation. I see that as a meaningful step, not a finished solution: Anthropic itself says there are still no settled standards for access, public reporting, or independent funding. For now, Anthropic will pay for Accenture's work.
That leaves a question no press release can settle: who checks whether safety commitments are being honored when honoring them is expensive, inconvenient, or delays a launch?
The problem with slowing down alone
Imagine one lab detects a serious warning sign and delays its next model for six months. Meanwhile, another keeps moving, attracting customers, researchers, and investment. Both may prefer a more cautious industry while neither wants to be the only one left behind.
That does not prove the warnings are false. It reveals an incentive problem. A voluntary pause can be valuable in response to an incident, but it is unlikely to govern an entire race.
Coordination among companies is already difficult. Coordination among countries is harder still when AI is treated as economic and strategic infrastructure. A serious agreement needs clear thresholds, a way to verify compliance, and a response if someone continues in secret. Writing “we should slow down” is much easier than building that mechanism.
Safety can also concentrate power
There is another uncomfortable point worth naming. The largest companies can afford data centers, lawyers, evaluation teams, and continuous audits. A startup, a university, or an open project may not be able to.
If regulation imposes the same burden on everyone regardless of risk, we may protect the public from one danger while entrenching another: concentrating capability in very few organizations.
It is also fair to ask whether labs might benefit financially from a less frantic race. Their infrastructure costs are enormous. But that does not mean the incidents are fabricated or that safety is merely a pretext. A commercial incentive can coexist with a genuine technical risk.
So we should neither trust industry leaders blindly nor dismiss their warnings simply because they come from industry. We should examine the design of the proposed measure: which risk it reduces, who verifies it, how costly compliance is, and whom it excludes.
Four different kinds of brake
For me, the debate becomes clearer when we separate four levels.
- Operational brake. An agent tries to cross a boundary: stop the run, restrict its tools, and investigate. This should be a routine safety practice.
- Deployment brake. A model displays a concerning capability: do not release it widely until safeguards exist and there is evidence they work.
- Coordinated frontier pacing. Labs and governments agree on verifiable conditions for moving more slowly in the highest-risk developments.
- General prohibition. Broadly stop AI research or use. This is far more radical and should not be confused with the first three.
It also matters to distinguish what a model can do from the permissions it receives. A system capable of finding vulnerabilities does not need unrestricted access to real networks. Safety depends not only on capability but also on the environment, tools, limits, and supervision around it.
What I would ask before supporting a pause
If a company or government announced tomorrow that it was slowing AI, I would want five answers: what exactly stops; what triggers and ends the pause; who verifies compliance; who benefits or is excluded; and what will be done with the time gained.
That last question seems decisive to me. A pause is not safety. It is time. If we do not use that time to improve isolation, evaluations, incident response, and public oversight, we will meet the same problem again a few months later.
My position, for now, is this: I would not support stopping “AI” as though it were one thing. Its valuable uses are too varied, and so are its risks. I would support real brakes for frontier systems: specific, verifiable, proportionate, and able to stop a run or delay deployment when the evidence calls for it.
We need to be able to slow down. That is not the same as stopping everything now and forever.
Perhaps the hardest question is not whether we want a brake pedal. It is who gets to press it, based on what evidence, and with what accountability to everyone else.
In this video, I explore the case for slowing the frontier and the reasons to scrutinize how those limits are designed.