Will AI vendors soon need independent safety audits?

Illinois has enacted the first reported US state law requiring annual independent safety-plan audits for frontier model developers above a large revenue threshold, reported around 500 million dollars; that figure should be read as reported rather than confirmed, and the statute name and effective dates are not asserted here. The direction of travel is the point: independent audit of AI developers is moving from voluntary commitment to legal duty, jurisdiction by jurisdiction, and it is a real development. But an audit of the developer is not an audit of your deployment.

The question matters because buyers increasingly cite a vendor's safety credentials as if they answer the enterprise's own compliance question, and they do not. A vendor's safety plan says nothing about which model version you ran, on what data, under whose approval, inside your organisation.

What does a vendor safety audit actually check?

The developer's own processes: how it evaluates a model before release, what safety commitments it has made, and whether its stated plan matches its practice. That is a legitimate and useful check on the organisation building the model. It tells a regulator, and by extension a buyer, something about the supplier's discipline at the point of manufacture.

Why does a vendor audit not cover your deployment?

Because the audit stops at the factory gate. It cannot see which model version your organisation actually runs, since a developer may operate many versions across many customers. It cannot see what data reached the model in your environment, since that lives inside your systems, not the vendor's. It cannot see who in your organisation approved a given use, since approval is an internal control, not a vendor property. And it cannot see what the model actually did on your behalf, since output logs, where they exist at all, sit wherever your contract and your logging choices put them.

What is the enterprise question a vendor audit cannot answer?

Whether your own use of the system is auditable. Not whether the developer was audited, but whether an independent party, your own internal audit function, a regulator, a court, can verify what your organisation's AI did without having to simply trust either you or the vendor's word for it. That is a property of your deployment, not the vendor's compliance certificate.

Does the EU AI Act already require this kind of check?

Partially, and on a deferred timeline. The EU AI Act builds conformity assessment into its high-risk regime, but the Annex III high-risk obligations, once due 2 August 2026, were deferred by the Digital Omnibus to 2 December 2027, with Annex I embedded systems pushed to 2 August 2028. So a comparable EU mechanism exists in law, but it is not live yet for most high-risk uses, and it still primarily targets providers and deployers of specific high-risk systems rather than every enterprise AI use.

How should a buyer respond to a vendor's audit claim?

By treating it as one input, not the answer. A useful question to ask a vendor citing an audit is narrow and specific: does the audit cover the exact model version and configuration we run, and does it say anything at all about our data or our usage. In almost every case the honest answer is no, which is not a criticism of the vendor, it simply marks the boundary of what a developer-level audit can ever certify.

What makes an enterprise deployment auditable by construction?

Verifiability that does not depend on trusting either party after the fact. Offline verifiability means the record of what the AI did can be checked without needing the vendor's cooperation or your own unverified word. A post-quantum signed audit ledger, built on FIPS 204, means the record cannot be quietly altered once written. Hardware-attested identity means every action ties back to a specific, checkable actor. Put together, these turn your deployment into something a genuinely independent party can verify, which is the property no vendor safety audit was ever designed to provide.

“A vendor audit certifies the factory; only your own sealed record certifies what happened on your floor.”

How offline verifiability, hardware-attested identity and a post-quantum signed ledger combine into one auditable architecture is set out at /sovereign-ai, and the film at /film shows the interface in operation.

Frequently asked questions

If my AI vendor is independently audited, do I still need my own audit trail?

Yes. A vendor audit examines the developer's processes and safety plan, not the specific model version, data and approvals inside your own organisation's use of the system. Your own auditable record is a separate requirement that a vendor audit does not satisfy.

Is the Illinois law already in force everywhere in the US?

No. It is reported as a single state law, and its exact scope, effective dates and statute name are not confirmed here. It should be read as an early example of a direction of travel rather than a national requirement.

Does the EU AI Act require independent audits of AI deployers today?

The high-risk Annex III conformity assessment obligations that would touch many deployers were deferred by the Digital Omnibus to 2 December 2027, so most enterprise deployers are not yet under a live EU audit duty of that kind, though the deferred requirement exists in the adopted text.

What is the single best question to ask a vendor about its safety audit?

Whether the audit says anything at all about the specific model version, configuration and data path you actually run. If the answer is no, the audit is real but does not extend to your deployment, and your own auditable record remains your responsibility.

Can a mutable application log serve as an audit trail if a dispute arises?

It can be presented as evidence, but a record that could plausibly have been altered after the event invites exactly that challenge. A record's evidential weight rests on whether it is cryptographically sealed and independently verifiable, not merely on its existence.

Should procurement teams start asking vendors about safety audits now?

Yes, as one input among several, alongside the sharper question of whether the audit says anything about the specific version and configuration actually being purchased. Asking early costs nothing and signals to vendors that deployment-level auditability, not just developer-level certification, is part of the buying decision.