Start with the enacted scope and dates
Illinois enacted the Artificial Intelligence Safety Measures Act through SB 315, Public Act 104-0538, signed July 6, 2026. The annual independent audit provision applies to large frontier developers, a defined category that includes preceding-year gross revenue above $500 million together with affiliates and a covered frontier-model definition: training computation above 10^26 integer or floating-point operations, including specified subsequent modifications. The audit trigger is January 1, 2028, or 90 days after first qualifying as a large frontier developer, whichever is later. The Act's general effective date is January 1, 2027; the audit duty follows its separate trigger. California's March 2026 Executive Order N-5-26 takes a different procurement step: it directs agencies to recommend possible vendor certifications and safeguards.
Buyers must check the implementing procurement documents to see which requirements apply to a particular award. Both developments matter to buyers, but their legal reach and implementation mechanisms differ. Illinois: Public Act 104-0538, enacted text.
Understand what an independent audit adds
An attestation records a vendor's representations. An independent audit adds a separate review, provided its scope, evidence access, and independence are meaningful. Illinois's provision specifies auditor qualifications and independence, necessary access, findings, and certification. That is useful structure for an assurance conversation; it is not a promise of complete access for every buyer to all proprietary model materials. Ask which obligations the auditor examined, what evidence was unavailable, what limitations remain, and who receives the report. A developer may meet a framework obligation while a downstream application still performs poorly.
Procurement teams should distinguish a legal compliance review, a technical safety evaluation, and a deployment-specific acceptance test rather than call all three an AI audit.
Use the lead time in current contracts
State agencies considering multi-year AI purchases before the audit requirement applies need a plan for the interval. Waiting for a future compliance date can leave the contract silent about current evidence, later findings, or model changes. That is a negotiating issue, not proof that every covered vendor currently lacks independent evaluation. Request whatever evaluation evidence already exists and define how it will be supplemented. A supplier that cannot commit to reasonable disclosure and remediation terms presents a risk that should be assessed, but refusal alone does not establish unsafe technology: confidentiality, scope, and the supplier's position in the delivery chain also matter.
The contract should resolve those practical questions before the service becomes difficult to replace.
Translate the framework into proportionate requirements
A state can consider using elements of the Illinois framework as a procurement reference, subject to its own procurement authority, competition rules, and counsel's review. Specify the needed evidence and outcomes instead of simply requiring compliance with another state's law for every AI product. A small application integrator may not be a covered frontier developer and may not control the underlying model audit. Requirements should identify who supplies the evidence, when it must arrive, what equivalent assurance is acceptable, and what happens if the model or developer changes.
This preserves the original procurement lesson: assurance is easier to negotiate before award than after operational dependence develops. It also avoids making a statutory label do work it was never designed to do.
Manage the patchwork without assuming equivalence
State AI requirements are developing at different layers: vendor disclosures, developer duties, use-case restrictions, and procurement safeguards. A consistent state policy should map those layers rather than assume one framework supersedes the others. California's procurement recommendations and Illinois's developer obligations can be useful references, but neither replaces the buyer's own data protection and service responsibilities. Establish a common minimum evidence package, then add requirements according to consequence: an internal drafting assistant and a system affecting resident eligibility need different acceptance tests. Record the rationale for equivalence decisions and require refreshes when the service changes.
That creates consistency without pretending the patchwork has disappeared.
Close the verification gap throughout the contract
The verification gap is the distance between a claim and evidence sufficient to rely on it. An independent audit can narrow that distance, but its findings need an owner, a review process, and contractual remedies. Our recommendation is to connect procurement, program, security, and legal teams around a shared assurance record. Track unresolved findings, accepted limitations, operating constraints, and the next reassessment date. Where no audit is yet available, specify interim evidence and decision limits rather than treating the future mandate as a present guarantee.
The result should be a system whose continued use is justified by current evidence, not a file containing a certificate nobody revisits.
Put assurance into the contract
The following acquisition steps translate the assurance problem into evidence a buyer can request and act on. They are recommendations, not additional duties imposed by the Illinois law.
- Establish applicability. Identify the model developer, model version, service provider, and whether the developer and model meet the law's definitions.
- Ask for the evidence now. Request existing evaluations, audit scope, evaluator qualifications, conflicts disclosures, limitations, and a schedule for future reports.
- Test the deployed use case. Measure error, bias, privacy, security, and escalation behavior using representative state workflows; a model-level audit cannot replace this.
- Write a change and remediation clause. Require notice of model changes, access to relevant findings, a corrective-action deadline, and an option to suspend unsafe functionality.
- Schedule reassessment. Identify triggers such as new data, changed models, a safety incident, a material audit finding, or a different decision-making role.
Sources and further reading
- Illinois: Public Act 104-0538, enacted text
- Illinois legislature: SB 315 status
- California: Executive Order N-5-26
Spartan X brings AI and cybersecurity knowledge to the buyer's side of this question: what evidence is enough for the intended use, which limitations matter, and how those answers should shape deployment and oversight.
