TechCrunch reported on September 20 that AI leaders are arguing over whether the industry can “pace the frontier.” Anthropic CEO Dario Amodei has called for slowing capability growth by one to two years so safety work can catch up. OpenAI, Anthropic, and Google have also been discussing an industry-funded standards body for powerful AI systems.
That sounds like a policy debate. For business leaders, it is an operating question: if an AI system your team depends on becomes risky, expensive, or misaligned with your standards, can you actually move?
Most companies do not know the answer. They are treating AI vendor choice like software procurement, when it is becoming something closer to workflow infrastructure. Once the system is inside daily work, switching is not a preference. It is a migration.
The free market assumes you can leave
The most useful line in the TechCrunch discussion came from Sean O’Kane, who argued that there is not much consumer choice driving this market. His example was plain: companies are not going to move from OpenAI’s Codex to Anthropic’s Claude Code just because they disagree with something OpenAI did.
That is the part leaders should sit with.
A normal market check works when customers can punish bad behavior by leaving. But AI systems are not only products anymore. They are getting wired into support queues, sales research, code review, financial workflows, internal knowledge bases, document drafting, and executive decision support. The more useful they become, the harder they are to remove.
That does not mean companies should avoid AI. It means dependency has to be designed, not discovered later.
The real risk is not that one vendor makes a bad public statement. The risk is that your team builds six months of process around a system with no exit path. Prompts live in one tool. Work history lives in another. Automations depend on a model-specific feature. Employees build habits around an interface nobody documented. Then pricing changes, policy changes, or risk tolerance changes, and the business discovers it cannot move without breaking work.
That is not an AI ethics problem first. It is an operations problem.
Safety becomes practical when it touches work
The public debate is going to keep orbiting big questions: should frontier labs slow down, who audits them, whether regulation helps, whether global coordination is possible. Those questions matter. They are not the questions most leaders can act on Monday morning.
The question you can act on is simpler: which AI dependencies would hurt if you had to change them in 30 days?
If the answer is “we do not know,” you have work to do.
The organizations ahead of this will not be the ones with the most dramatic AI principles. They will be the ones with clean dependency maps. They will know which workflows rely on which vendors, which outputs need human review, which data enters which systems, which agents can take action, and which parts of the work can be moved if a vendor relationship changes.
This is what mature AI adoption starts to look like. Less theater. More plumbing.
When OpenAI, Anthropic, and Google discuss shared testing standards, they are admitting that trust cannot be left to marketing copy. When Amodei argues for a one-to-two-year slowdown, he is admitting that capability is moving faster than the control layer. When Nvidia’s Jensen Huang pushes back and says the industry should keep moving fast, he is making the countercase.
Your company does not need to resolve that fight. It needs to stop pretending the fight has operational consequences.
What to ask before the next AI renewal
Most AI procurement still sounds like tool selection. Which product is better? Which model is smarter? Which vendor has the best roadmap? Those are not useless questions, but they are incomplete.
The better questions are about reversibility.
Can we export the work product, prompts, evaluation history, and audit logs in a usable format? Can another system perform the same workflow if we have to move? Are our employees learning a transferable process, or are they learning one vendor’s interface? Which tasks are too sensitive to depend on a single outside provider? Who owns the decision to pause, replace, or restrict a tool if risk changes?
Those questions feel boring until the day they are urgent.
I have watched teams make the same mistake with AI that they made with every other system that became operational infrastructure. They evaluate capability first, adoption second, governance third, and exit paths never. Then the pilot succeeds, the workflow spreads, the vendor becomes load-bearing, and nobody wants to reopen the architecture because the team is finally getting value.
That is how lock-in happens. Not through one bad contract. Through useful work that was never designed to be portable.
The first step is a dependency map
Do not start with a policy memo. Start with a table.
List every AI system your team uses for real work. Not experiments. Real work. For each one, capture five things: what process it supports, what data it touches, what outputs it influences, who owns it, and how hard it would be to replace in 30 days.
The replacement score matters. If a tool is hard to replace, it deserves more governance. If an agent can take action, it deserves clearer boundaries. If a workflow depends on one model-specific feature, it deserves a backup path. If nobody owns it, that is not innovation. That is unmanaged infrastructure.
This is also where AI safety becomes concrete for business leaders. Not abstract risk. Not public debate. Operational readiness.
The market may eventually sort out which labs were right about pacing the frontier. Regulators may create standards. Auditors may get access. Vendors may publish better controls. All of that will take time.
Your dependency map can start this week.
That is the gap between waiting for the industry to become safe and making your own use of AI safer. One is a debate you watch. The other is work you own.