Skip to content
ASA
← Back to home
JournalSeptember 15, 2026

When AI Leaders Ask to Slow Down, Ask Who Gets Slowed

When AI Leaders Ask to Slow Down, Ask Who Gets Slowed

The biggest names in AI are asking the industry to slow down.

The first question is whether the danger is real. The second is who gets slowed by the solution.

Anthropic CEO Dario Amodei published an essay called "We Must Pace the Frontier". OpenAI CEO Sam Altman said he agreed. Elon Musk said Amodei was right. Google DeepMind's Demis Hassabis supported the direction too.

This is not a fringe warning. It is coming from people building some of the most capable AI systems in the world.

Their concerns deserve serious attention. So does the market position from which they are speaking.

A speed limit written by the companies already in front is never economically neutral. If the rules require expensive audits, permanent evaluators, specialist compliance teams, and government coordination, the largest labs can absorb that cost. A startup, university team, or open-weight developer may not be able to.

Both things can be true: AI may need stronger safety controls, and badly designed controls may protect incumbents.

What Amodei actually proposed

The proposal is more specific than a blanket call to stop AI.

Amodei says pacing does not mean halting model training or technical progress. His plan has three parts:

  1. Frontier labs give independent evaluators ongoing access to their systems, processes, and safety work.
  2. Labs in democratic countries coordinate on safety standards and limits, with government involvement where antitrust rules make coordination difficult.
  3. Governments pursue international agreements on dangerous uses, testing, and potentially the speed of advanced AI development.

He also suggests capability checkpoints. If a model can perform a dangerous action, it should have to pass defined safety tests before development or release continues.

That is a more useful idea than regulating a company simply because it is called an AI lab. Rules based on demonstrated capability can apply to any model, regardless of who built it.

But the design still matters. Coordination between the largest competitors can improve safety. It can also become a gate that smaller competitors cannot pass.

The missing open-weight question

Amodei's pacing essay runs for thousands of words. It does not discuss open-source AI or open-weight competition directly.

That omission matters, but it is not proof of a hidden plan.

It does leave a major policy question unanswered: what happens to models that people can download, run privately, fine-tune, and deploy without a frontier provider?

The language is important here. Many models described as open source are more accurately called open weight. Their trained parameters can be downloaded, but their training data, code, or full development process may not be open.

Open-weight models are not a side issue. They give businesses more control over data, hosting, cost, and vendor choice. They also create a harder safety problem because a provider cannot withdraw the model or enforce safeguards after the weights are released.

Independent research from Epoch AI estimated that, since January 2026, leading open-weight models trailed the closed frontier by an average of about four months on its capability index. That does not mean every open model matches every closed model. It does mean the alternative ecosystem is close enough to matter.

Anthropic has separately stated that it has never advocated for a blanket ban on open-weight models. It calls less capable open-weight models a public good and argues that mandatory safety testing should apply to sufficiently capable models, whether open or closed.

That is an important concession. It should be written into any real policy, not left as a separate company statement.

The safety concern is not invented

It is easy to treat every warning from an AI company as marketing. That would be a mistake too.

Amodei points to faster capability development, models helping to build their successors, cyber misuse, biological risk, and systems behaving in ways their developers did not intend. Researchers have also left leading labs because they believed the race was becoming unsafe.

You do not have to accept every catastrophic forecast to support independent testing, incident reporting, sandboxing, access controls, and human approval for high-impact actions.

Those are ordinary production controls. Businesses should already be using them.

The problem begins when a reasonable safety objective becomes a broad rule that only the market leaders can satisfy.

A simple test for any AI slowdown proposal

Before supporting or opposing a new rule, ask seven questions.

1. Does it regulate capability or identity?

A rule should respond to what a model can do and the harm it can cause. It should not assume that every open model is dangerous or every closed model is controlled.

2. Does it apply equally to open and closed systems?

The same dangerous capability should trigger the same testing standard. Deployment conditions may differ, but the safety threshold should not quietly favor one business model.

3. Can a smaller company comply?

If compliance requires a permanent legal team and millions in audit spending, the rule may become a market-entry fee. Shared testing facilities, published evaluation suites, grants, and proportionate requirements can reduce that risk.

4. Are the tests public and reproducible?

Nobody should have to ask a dominant lab what counts as safe. Evaluation criteria, failure definitions, and reporting rules should be available for independent review.

5. Is industry coordination narrowly limited?

Competitors may need to share safety information. They should not use that process to coordinate prices, release schedules, customer access, or rules that exclude new entrants. Government and antitrust oversight should be built in from the start.

6. Is there an appeal and review process?

Models change. Evidence changes. Every restriction should have a review date, a way to challenge a decision, and a process for updating the threshold.

7. Who is missing from the room?

Frontier labs should not write the final rules alone. Open-weight developers, researchers, startups, civil society, security experts, and the businesses using these systems all need representation.

What businesses should do now

You do not need to wait for governments or AI labs to settle this argument. Build your systems so one policy change or provider decision cannot trap you.

Step 1: List where each model is used

Create a simple register for every AI feature and workflow. Record the provider, model, data accessed, actions allowed, owner, monthly cost, and business impact if the service disappears.

You cannot manage concentration risk if you do not know where it exists.

Step 2: Separate your application from the model

Keep business rules, permissions, prompts, retrieval, and tool definitions outside a provider-specific interface where possible. Use a small model gateway or adapter so you can change providers without rebuilding the product.

Portability is not about switching models every week. It is about keeping the option.

Step 3: Build your own evaluation set

Take 50 to 200 real tasks from your business. Include normal cases, difficult cases, sensitive data, malicious instructions, and requests the system should refuse.

Run the same set against your current model and at least one alternative. Measure accuracy, harmful actions, latency, and total cost. Do not choose a fallback from a public leaderboard alone.

Step 4: Test an open-weight fallback

Pick one contained workflow that does not require the strongest frontier model. Test whether an open-weight model can handle it inside your own environment or through an independent host.

Start with classification, extraction, summarisation, routing, or internal search. Keep human review where an error would affect money, access, employment, health, or a customer account.

Step 5: Keep control of your data and logs

Store source documents, retrieval indexes, prompts, tool schemas, evaluation results, and audit logs in systems you control. A model provider should be replaceable. Your operational memory should not be.

Step 6: Add risk gates before model calls and actions

Check data sensitivity before sending information to a model. Check permissions again before the system takes an action. Put explicit approval in front of deletion, payment, account changes, external messages, and access grants.

Model choice does not replace system design.

Step 7: Prepare three policy scenarios

Write down what you would do if:

  1. Frontier APIs face new audit or identity requirements.
  2. A model you depend on is withdrawn or restricted.
  3. Open-weight models face new hosting or testing rules.

For each scenario, name the fallback model, migration owner, acceptable downtime, and data changes required.

The position worth defending

The choice is not "move fast and ignore safety" or "let the largest labs decide when everyone else can move."

There is a better position:

  • Test models against real, dangerous capabilities.
  • Apply thresholds to open and closed systems.
  • Give independent evaluators meaningful access.
  • Publish the standards and the evidence.
  • Keep compliance proportional for smaller teams.
  • Prevent safety coordination from becoming commercial coordination.
  • Review the rules as the technology changes.

AI safety and competition are not opposing goals. Competition can reduce dependence on a handful of providers. Safety rules can make every provider more accountable. Poor policy can damage both.

So when the companies in front ask everyone to slow down, do not dismiss them. Ask for the mechanism. Ask who pays. Ask who gets a seat. Ask whether a smaller competitor can still enter the market.

The danger may be real. The power created by the solution will be real too.

Need help reducing AI vendor risk?

If your business already depends on one model provider, I can help you map the risk, build a portable AI architecture, and create an evaluation process for alternative models.

Contact me through my website or send me a direct message on LinkedIn.

Sources

Share this article:

Stay ahead of the curve

Join my private newsletter for exclusive insights, tools, and thoughts straight to your inbox. No spam, just value.