Two developments on opposite sides of the world, arriving within weeks of each other, mark the same turn in how governments intend to deal with AI. In one jurisdiction, legislation has advanced that places a national AI safety institute on a statutory footing and grants it the legal right to inspect frontier models before they are deployed - not to read incident reports afterwards, but to test beforehand. In another, an updated national governance framework for generative AI now specifies technical testing standards - named, measurable checks for prompt-injection resistance, jailbreak susceptibility and hallucination rates in enterprise software. Behind both sits one idea: that AI systems above a certain capability or deployment threshold should be examined before release, the way vehicles, aircraft and medical devices are. Type approval, in short, is coming to software that until now shipped on its maker's word.
The significance is easiest to see against what preceded it. The first generation of AI governance ran on voluntary commitments: developers promised evaluations, published safety frameworks and invited external testers on terms they controlled - arrangements that produced genuine work but had the structural weakness of all self-regulation, in that participation, scope and disclosure remained gifts. A statutory inspection power changes the grammar. The examiner chooses what to probe; findings do not depend on the developer's decision to share; and pre-deployment means the question is asked while the answer can still change the outcome. The parallel shift in the enterprise frameworks is subtler but may matter more in practice: by specifying which tests and which metrics, they begin converting AI safety from a rhetorical property - our model is safe - into a measured one, comparable across vendors, checkable by buyers, and citable in contracts.
Honesty requires stating the hard problem: nobody yet knows exactly what a pre-deployment inspection can promise. Vehicle certification works because failure modes are enumerable and physics is stable; a general-purpose model's behaviour space is vast, its failure modes are partly unknown, and the science of evaluating it is years old, not decades. Inspections can catch known classes of problems - measurable rates of fabrication, susceptibility to known attacks, dangerous capabilities that current probes elicit - and that is worth having; they cannot certify the absence of what no test yet elicits. There is a real institutional risk that a passed inspection reads as a broader warrant of safety than the underlying tests support. The sober framing is that AI inspection today is where crash testing was in its first decade: crude relative to what it will become, better than nothing by a wide margin, and the mechanism by which testing itself improves - because a statutory examiner accumulates cross-model evidence no single developer sees.
For businesses that buy rather than build AI, the near-term effects are mostly useful. Certification regimes generate artifacts - test results, conformity marks, published metrics - and those artifacts flow into procurement: expect enterprise AI contracts to start referencing named tests and thresholds, and expect vendors, in time, to compete on measured robustness the way manufacturers compete on safety ratings. When that happens, the standards written by these early statutory bodies become the de facto vocabulary of the market, well beyond their own jurisdictions - the pattern by which strictest-regulator standards travel is already familiar from privacy and product safety. The practical advice, then, is modest: when next selecting an AI vendor, ask what has been tested, by whom, against which standard, and treat the quality of the answer as evidence in itself. The era in which that question had no possible answer is ending; the era in which not asking it looks negligent has begun.