A designation raises an applicability question
When federal authorities designate a technology supplier as a risk, state CIOs need to determine whether that action binds their purchase, informs it, or requires a separate state decision. The answer depends on the legal authority, funding, and contract involved. A contentious vendor case can expose the difference between following a federal restriction and borrowing a federal assessment for convenience. A procurement decision can outlast the news cycle surrounding a disputed designation.
The state needs an accountable process for checking applicability, evaluating evidence, and recording the basis for continued use, restrictions, or replacement. California: signed Executive Order N-5-26.
What California's order does—and does not do
California's Executive Order N-5-26, signed March 30, 2026, directed DGS and CDT to recommend possible procurement certifications within 120 days. It also directs the state CISO to review new federal supply-chain risk designations; if the CISO finds one improper, DGS and CDT are to issue guidance enabling state procurement from the company. This is an independent state procurement review mechanism, not authority to nullify binding federal law or disregard an applicable federal award condition. Nor does the order by itself prove that every recommended certification became an operative contract rule.
The 120-day period has elapsed as of October 1, 2026. Buyers should distinguish the signed direction from subsequent implementation and check both before describing what vendors must do today.
Use federal evidence without confusing its purpose
Federal tools serve different purposes. A purchasing vehicle can simplify acquisition; a cloud security assessment can provide evidence about a service boundary; a supply-chain determination may impose a particular restriction. None is a general certificate that an AI application is suitable for every state workflow. The original attraction of reuse remains sound: states should not needlessly repeat expensive evidence collection. But they must understand what the evidence covers, when it was produced, and which risks remain theirs. Controversy is also not proof that a technical finding is wrong.
A defensible process examines the basis and applicability of a designation instead of accepting or rejecting it solely because federal and state political priorities differ.
Match independent review to available capacity
Independent review requires staff and expertise. California's order assigns named departments and the state CISO clear roles, but its existence does not establish that every state can reproduce the same depth of evaluation. A small team may lack capacity to evaluate model provenance, run adversarial tests, and monitor a broad portfolio on its own. Shared assessments, qualified outside reviewers, and risk-tiered reviews can help without outsourcing the acceptance decision. Focus the strongest review on the services with the greatest consequences, and record where evidence is incomplete.
The goal is proportionate judgment with traceable accountability, not a separate state laboratory for every product or uncritical dependence on another government's list.
Require disclosure throughout the software supply chain
Contract disclosure is a near-term control available to buyers. Cloud and software products can add AI features through updates, so ask vendors to identify both current and planned AI components rather than assume the original statement of work is complete. Require information about model providers, data handling, retention, training use, hosting, and material substitutions. Draft federal clauses may provide ideas, but a draft is not a final requirement and a clause number should not substitute for reading the current text. State counsel and acquisition staff should tailor provisions to their authority and the supplier's actual role.
The practical objective is visibility into the delivered service and timely notice when its behavior or risk changes.
A concrete reference is GSA's June 2026 proposed update to GSAR 552.239-7001, addressing safeguards for government data processed by large language model systems. The notice identifies January 12, 2026 as the first draft date and includes exceptions for LLMs embedded in common commercial products or incidental to the core purchase. The June document is a proposal requesting comments before a future deviation or rulemaking, not an enacted GSAR amendment or universal disclosure mandate. Buyers should check the current solicitation and any applicable subsequent deviation or rule before relying on its terms. States can study its supplier roles and data safeguards while tailoring their own terms. Federal Register proposed clause.
Use each contract cycle to improve governance
AI vendor risk is an ongoing governance task. Contract renewals, new task orders, and modifications are opportunities to obtain missing disclosures, clarify evidence access, and set change-control obligations. Waiting for national policy to settle can postpone those useful steps indefinitely. At the same time, state independence does not mean dismissing federal work: retain relevant assessments and explain how they informed the decision. Assign someone to review disclosures, follow up on missing evidence, and trigger reassessment after a material change. A contract can require transparency, but the state still needs the capacity to interpret the response and act on it.
That combination is the foundation of a defensible vendor-risk practice.
Work through a changed supplier before renewal
Take a hypothetical case-management service whose supplier plans to add an AI summarization feature using a different model provider. The existing contract file contains a cloud security assessment and a purchasing-vehicle reference. Neither document necessarily answers whether case records may be sent to the new provider or whether the summaries are reliable for the agency's intended use.
Start with applicability. Acquisition staff and counsel identify any binding restriction, funding condition or contractual limit. Technical reviewers then map the proposed data path: what leaves the service, who processes it, where it is retained and what the subcontractor can change. Program officials determine whether staff will use the summary merely to locate source material or as input to a consequential decision. That difference changes what errors the evaluation must examine.
Reuse the existing assessment where its scope remains relevant. Request additional evidence for the changed component and workflow rather than treating the whole file as either worthless or sufficient. If the supplier cannot establish the data path or applicable permissions, that missing evidence is itself a decision constraint. A reassuring reference to a federal list cannot fill it.
Keep authority and technical merit on separate lines
A legally prohibited purchase cannot be approved simply because a technical test looks favorable. Conversely, the absence of a prohibition does not establish fitness for a state workflow. Record both determinations so that an official reading the file later can tell why the service was allowed and why the agency considered its use supportable.
The renewal decision may have more than two outcomes. Depending on the contract and system design, an agency might retain the existing service with the new feature disabled, permit a bounded evaluation using approved data, require a supplier repair or arrange a transition. Those are options to assess, not assurances that every product supports them. If the supplier cannot isolate the new feature, a proposed limitation may be technically meaningless.
Give each condition an owner and a date for reassessment. A restriction recorded at approval but never checked after a vendor update provides little continuing protection. The renewal file should identify what event reopens review: a provider substitution, a changed data-use term, an applicable legal determination or a material performance failure.
This process also protects against unnecessary replacement. A relevant federal assessment may provide strong reusable evidence, and a supplier may resolve a narrow gap without a new procurement. Compare that option with transition cost, service continuity and the risks that would remain. The objective is a defensible decision about this deployment, with enough evidence to change course when the facts change.
What the vendor-risk file should contain
Keep the record small enough to maintain and specific enough to support a real decision. These five items are a useful starting point.
- Identify the applicable authority. Ask counsel whether a federal restriction, grant condition, state rule, or contract clause binds this purchase.
- Inventory embedded AI. Require the prime vendor to identify model providers, versions, hosting, subcontractors, processed data, and functions that affect decisions.
- Ask for usable evidence. Obtain risk evaluations, test limits, security documentation, and known failure modes relevant to the state's intended workflow.
- Control changes. Require advance notice of model substitutions, new subprocessors, changed training-data use, and material changes in deployment or access.
- Retain the state's decision. Document who approved the risk, accepted limitations, conditions of use, review date, and the option to stop or replace the service.
Sources and further reading
- GSA: June 2026 proposed LLM safeguards clause
- California: signed Executive Order N-5-26
- California: March 30 procurement announcement
Spartan X's AI consulting and cybersecurity work addresses the gap between supplier claims and a deployment decision. A state should know what it is buying, how it can change, and what evidence supports continued use.
