AI Safety Needs to Move at the Speed of AI
The question isn't whether AI should move fast or safely. The question is whether our safety systems can move at the same speed as capability development.
By Oluwaseyi Ayodeji, Published on oluwaseyiayodeji.com | Regal Stack Newsletter
Over a week ago, Sundar Pichai shared a post from James Manyika, Google's SVP of Research, Labs, Technology & Society. In a few weeks, Google mapped all 9 billion possible single-letter genetic changes in the human genome and opened the data to researchers. It shipped WeatherNext 3, delivering precipitation forecasts 50% more accurate a day or more out. It built a Planetary Prediction Engine already in use against the Ebola outbreak in the Democratic Republic of the Congo and to identify vulnerable communities across 21 US health indicators. And it published an AI & Economy ATLAS tracking how people actually use AI worldwide.
I am bullish about this technology, genuinely. Reading that list is why.
But notice what kind of AI news that is. It is applied AI: models doing useful work in the open, after testing, under scrutiny. The argument raging among Dario Amodei, Sam Altman, Demis Hassabis, David Sacks and Jensen Huang sits upstream of that, over how fast to push frontier capability before the next model is even built.
A genomics atlas doesn't settle that argument. It is the reward for getting it right, and a reminder of what a bad answer puts at risk.
I lead GCL University, an enterprise learning program within Google Cloud Logistics. It exists partly because the AI infrastructure supply chain moves faster than most people's skills do. Our job is to upskill full-time employees to meet that pace and re-engineer how work gets done, giving people the know-how and tools to rebuild existing processes with systems relevant to their function.
The lesson I keep coming back to has little to do with technology. Some tensions aren't problems to solve. They're polarities to manage.
A polarity is a pair of things that pull against each other and that you need both of. Inhaling and exhaling. Nobody asks which to pick. Leadership is full of them: stability and change, standardization and autonomy. Pick one and you haven't solved the tension. You've simply slid into the downside of your favorite pole, felt the pain, and swung hard toward the other.
Safety and speed in AI are exactly this.
We don't need to choose one. Capability development is accelerating faster than the systems designed to test and contain its risks.
The real question is not speed or safety
On September 12, Amodei published an essay arguing frontier companies should slow how fast they improve model capabilities so risk prevention can keep up. Altman said OpenAI would match Anthropic's pledge of independent evaluators with employee-like access. Hassabis said the direction was right and pointed to his own standards-body proposal. Trump said the US leads China and intends to keep it that way. Sacks told the two labs to slow down themselves, without antitrust cover. Huang rejected pacing outright. Zuckerberg said each lab can decide for itself when to delay.
Map that as a polarity and the pattern becomes clearer: Amodei, Altman and Hassabis are watching the downside of speed: systems becoming capable of doing things their creators did not anticipate. Trump, Huang and Zuckerberg are watching the downside of safety: a pause that only one side observes while a rival pulls ahead.
Each camp can see the other's danger clearly and has a harder time seeing its own.
But they agree more than the headlines suggest. Amodei caps his slowdown at the size of America's lead over China. Sacks argues the market already punishes unpredictable models. Huang and Zuckerberg both back independent evaluation.
Almost everyone is managing both poles. The real disagreement is over who holds the dial, and how quickly it should move.
That is where I think the conversation needs to go next.
Instead of asking whether AI should move faster or slower, ask whether the assurance process can move as fast as the technology itself.
Testing cannot be an autopsy
A test that arrives after launch is an autopsy. It explains what happened. It stops nothing. I learned the opposite lesson as an automation testing engineer, building end-to-end acceptance testing into server manufacturing and assembly equipment.
The sequence was disciplined. Pre-test, where requirements were documented and validated. FAT, the Factory Acceptance Test, run at the equipment maker before anything shipped. SAT, the Site Acceptance Test, run again once installed. Post-test ramp, where the equipment proved itself under real production load.
The most important step was also the one people were most tempted to skip: validating the requirements at the beginning. A requirement that doesn't actually measure the outcome you care about can hand you a passing test and a false sense of safety.
That lesson translates surprisingly well to frontier AI.
Anthropic's own Responsible Scaling Policy does check capability thresholds during training, so it would be inaccurate to say nothing happens until the end. But the heaviest testing, including external red-teaming, policy vulnerability testing and evaluations that influence whether a model ships, still concentrates heavily near release.
That is the imbalance worth fixing, not the presence of testing itself. The manufacturing lesson is straightforward: build the test plan before you build the thing.
For frontier AI, that means defining the capabilities that matter, the risks that must be evaluated, the evidence required for release and the conditions that would stop or change deployment before training is complete.
Testing should not be the final inspection at the end of the production line. It should be part of the production line.
Move the warning signs upstream
Hassabis's proposal fits part of this model. Labs would share models with a FINRA-style standards body up to 30 days before release, with passing potentially becoming mandatory for the US market. That creates a gate at the end. Amodei's evaluators reach further into the process, assessing training pipelines and processes, not only finished models.
I would take that logic one step further.
Imagine the test plan written before training starts and sitting on the roadmap like any other deliverable: an owner, a date, a pass line and clearly validated requirements.
As the model trains, checkpoints are tested against it. The test environment itself is tested. Some evaluations are held back so models cannot simply optimize against everything they know they will face. Sandboxes are verified before cyber evaluations begin. By release day, most of the evidence already exists.
The passing score sheet can then be made public, including the risks identified, the limitations of the evaluation and the containment measures in place if something goes wrong anyway.
This isn't a claim that testing makes AI safe. No test is foolproof. It's a claim about timing. A defect found during design costs less than a defect discovered at launch.
Four practices would make that principle real.
First, write both goals at kickoff: capability targets and the safety evidence required to release them. This is mine, borrowed directly from how a manufacturing roadmap gets scoped.
Second, validate the requirements before testing against them. This is close to what Amodei himself proposes: if a model can do X, it needs certifications Y and Z before release. My addition is the manufacturing discipline underneath it, confirming that Y and Z actually measure the outcome we care about rather than serving as convenient proxies.
Third, test checkpoints while the model trains, and test the test bench. Is the grader isolated, are some tests held back, does the sandbox actually block outside network access. These aren't rhetorical questions. The testing environment can fail too, and OpenAI's own account of the Hugging Face incident showed exactly how.
Fourth, put independent evaluators inside the pipeline. This is Amodei's proposal outright. Anthropic has committed to it, and Altman says OpenAI will match it. None of this means pretending the process is free. Every additional deliverable creates coordination and operational weight. Testing is no exception.
Assurance isn't free. But we should pay that cost earlier, when problems are still cheaper to fix.
Safety needs an economic model too
Testing will only keep pace if the economics allow it to. These are my proposals, not anyone else's policy.
Create a fast lane for models with a pre-registered test plan and credible independent evidence. Give buyers and deployers a reason to prefer systems that can demonstrate how they were tested.
Build an insurance market in which underwriters price AI deployment risk and credible evidence can lower the premium.
Treat assurance, evaluation tooling, red-teaming and audit as an investable category rather than an overhead attached to model development. Zuckerberg and Sacks argue that liability and competition already push labs toward reliability. I partly agree. But liability is an autopsy too. It arrives after the damage. An assurance market moves discovery before launch.
There is an important caveat. Sacks has raised concerns about METR's relationships with Anthropic's investors and staff. The broader market therefore needs competing providers, published methods and held-out tests. Otherwise, "who audits the auditors?" becomes the next capture story.
I cannot prove a testing market will form. I am betting it will, because every safety-critical industry that scaled eventually had to build mechanisms for independent assurance.
Not everything is a polarity
There is one important limit to this framework. Some things are problems to solve, not tensions to balance.
Helping someone build a biological weapon is not a good to trade against speed. Amodei lists a ban on AI-enabled bioweapons production as the most feasible level of international agreement. Those are lines, not dials.
Economic disruption is another exception to the testing approach entirely. No testing schedule solves it. That requires policy, adaptation and public debate.
The polarity framework is useful precisely because it has limits. Not every difficult question is a polarity, and forcing one into that model can obscure rather than clarify the problem.
Africa is where this gets tested
If testing is going to move to the front of the roadmap, the test categories decided today will shape who that testing actually protects.
This is where Africa enters the conversation, not as a separate concern but as a test of whether the assurance model is honest about its blind spots.
A huge share of economic activity across Africa runs through the informal economy: street traders, roadside vendors, small importers, savings groups and cash-heavy small businesses that keep no formal books. A fraud or credit model trained and tested primarily on Western banking data has never seen how that economy behaves. It has no baseline for how a legitimate small trader's cash flow can be lumpy and irregular by design rather than because something is wrong. Deploy that model into African fintech without testing against this population, and the people who are economically active but least formally documented may be the ones it misreads first, locked out of credit or flagged as risk simply because they operate differently from the data the model learned from.
This is exactly the kind of thing a pre-registered test plan should be required to identify. If the passing evidence is made public, it should say plainly whether the model was tested against informal-economy transaction patterns, not just against Western fraud benchmarks. A model can pass every safety evaluation a standards body requires and still fail an entire population because nobody wrote that population into the requirements.
That's an assurance problem, not only an African one. Africa makes it visible.
There is also a second polarity here: moving fast enough to participate in the AI economy while retaining enough control over data, evaluation and context to remain sovereign. The assurance layer can help hold both.
But that requires more than algorithms. It requires audit talent, risk discipline and people who understand how money actually moves in different economies.
Stay in the polarity
Nobody wins the polarity. The goal is to stay in it well. That takes constant attention, not a one-time fix. AI will keep getting more capable. The question is whether the systems around it will mature at the same pace.
My proposal is simple: test at the speed of training, fund assurance to keep pace with capability, and make the evidence visible.
I have made my case. Tell me where I'm wrong. If you've seen a warning sign this framework would miss, or a place where lockstep testing breaks down, put it in the comments. I want the pushback.
