The GSA's New AI Contract Clause: A Framework 39% of State Survey Respondents Still Need

Why AI contracts require different terms

Software contracts written before the emergence of large language models were not designed for systems that generate text, make inferences from prompts, or change behavior with each model update. The practical difference is behavioral non-determinism: the same input does not guarantee the same output across model versions, and a vendor's decision to update or replace the underlying model can change how a deployed system behaves without any action from the agency.

Four specific problems follow from this, each requiring a contract provision that standard enterprise software agreements do not typically include:

• Training data use. Some AI vendor agreements, particularly at commercial or self-serve tiers, permit using customer data to improve or fine-tune the model unless the customer affirmatively opts out. For state governments processing resident personal information, HIPAA-covered data in Medicaid and behavioral health systems, or federal tax information (FTI) governed by IRS Publication 1075, a training-data permission is a compliance problem, not merely an unfavorable commercial term. The agency may be legally prohibited from permitting that use, which means the prohibition must be in the contract. Review the governing enterprise terms rather than assuming defaults are acceptable.
• Model version changes. When a foundation model is updated or replaced, the deployed system's behavior changes. A benefits eligibility decision-support tool or automated case review system that passed acceptance testing may produce materially different outputs after a model update. Traditional software contracts treat version management as a maintenance matter; AI system contracts need explicit provisions defining the agency's testing window before behavioral changes go into production and the vendor's obligation to notify the agency of what changed.
• Intellectual property over fine-tuned outputs. When a state agency customizes a model using its own data and workflows, the contract must define who owns the resulting fine-tuned capability. Review vendor enterprise agreements on IP terms; ownership of agency-funded customization should be addressed explicitly in the contract.
• Vendor lock-in at the model layer. AI systems trained on proprietary infrastructure may be difficult to migrate even when the underlying data is portable. Standard cloud contract data portability clauses predate the model layer and do not automatically address model-layer dependencies. An agency that cannot migrate to a different vendor or platform without losing trained capability has compounded its dependence on the vendor's pricing and roadmap decisions.

Each of these requires explicit contract language to address.

What GSAR 552.239-7001 covers

The GSA clause addresses these problems directly. It applies where LLM functionality is a *material feature* of the purchase and Government Data goes directly to or comes from the LLM — it self-deletes for contractor back-office use and for incidental or ancillary LLM features. That scope matters for state procurement officers using it as a model: it may not cover every AI feature embedded in a platform, depending on how central the LLM capability is to what is being purchased.

Key provisions from the finalized clause, issued as a GSA Regulation Deviation effective October 19, 2026:

Data use and intellectual property rights. The clause establishes an outright prohibition on using Government Data for general model training or improvement; other uses are permitted only if the contracting officer expressly authorizes them in writing. It also vests ownership of Custom Developments — modifications made specifically for the government — in the government. Outputs are a separate category of Government Data that the government also owns. The contractor retains its underlying LLM, base models, and pre-existing multi-customer materials.

Model version evaluation window. Under section (i)(2), contractors must make reasonable efforts to provide concurrent access to new model versions for evaluation before discontinuing the previous version: 30 days for major versions and 15 days for minor versions. Where the version change originates with a third-party provider, the contractor must notify the contracting officer within 5 business days and use best efforts to provide a successor version. A 30-day advance notice of material changes applies under section (i)(1) except where concurrent access is already provided. (The same 30/15-day window appeared in a draft GSA circulated in early 2026 for comment beginning March 6 and in a revised proposal published June 17, 2026 in the Federal Register.)

Safety, bias, and performance change notification. Contractors must notify the government within 7 calendar days of changes that materially increase bias or decrease safety guardrails, or that degrade performance or truthfulness of outputs. The 7-day clock runs from when the contractor identifies the change, which may be after deployment, so this is a prompt-notice requirement rather than an advance-warning gate.

Government performance testing. The government may run benchmark tests of the system at any time and may suspend the system at any time — suspension is not threshold-gated. If the contractor fails to remediate deficiencies after written notice, the government may terminate for cause; decommissioning costs in that scenario are capped at 25% of the value of the affected order.

Data portability. Section (h)(4) requires tooling to migrate both Government Data and Custom Developments, which include fine-tuned modifications the agency has developed. Fine-tuned weights are deleted at contract end unless the contracting officer directs otherwise. The federal clause already reaches the capability layer, not just the data layer.

Clause priority over commercial terms. GSAR 552.239-7001 supersedes conflicting commercial licensing terms related to AI, supplementing FAR 52.212-4 without overriding law or mandatory clauses. State contracts that do not include analogous override language leave conflicting vendor terms to govern.

Security and performance standards. The clause addresses security protocols and performance standards for AI systems in government operations.

Eligible state and local buyers ordering under GSA cooperative purchasing could benefit from these protections once the clause is added to the underlying schedule contract — planned for MAS Refresh 34, scheduled for November 2026 — and the material-feature test is met. States procuring directly through their own ELAs, statewide contracts, or agency-level agreements operate under their own terms.

What the NASCIO data shows

The 2026 NASCIO State CIO Survey, which 51 state and territory CIOs completed, shows the practical exposure:

• 98% of responding CIOs reported enterprise policies and procedures for AI development and use, up from 76% in 2025.
• 78% reported adopting an AI governance framework, up from 65%.
• 61% reported implementing procurement terms and contract provisions for generative AI, up from 41% in 2025 — a 20-percentage-point increase in one year.
• 57% reported data governance provisions covering sources, quality, bias, and privacy.
• 49% reported requiring software providers to disclose their AI capabilities.
• 35% reported instances of enterprise-scale GenAI projects across the executive branch.

The gap between the 98% that report enterprise AI policy and the 61% that report procurement terms is the structural problem. An enterprise policy establishes internal requirements for how agency staff use AI. It does not bind a vendor. A contract term does. Survey respondents with policy but without contract provisions have defined intent without the legal mechanism to enforce it in the vendor relationship.

For the 39% of responding CIOs without AI-specific procurement terms, the exposure is immediate: AI features are being embedded into existing software platforms and added at renewal. Any such feature that arrives under a vendor's standard commercial terms — without agency-negotiated provisions — is subject to whatever those default terms say about training data, IP, and model changes. One state CIO quoted in the survey described the operational reality: "We still lack broad understanding and socialization of our AI policy, making enforcement and governance difficult."

What state contracts need that the federal clause doesn't fully address

GSAR 552.239-7001 is a federal standard for federal procurement. State contracts need it as a starting point, not a complete answer. Several areas require state-specific additions:

Sensitive data categories with federal requirements. IRS Publication 1075 governs federal tax information and carries specific cloud computing requirements, including 45-day notification requirements, FIPS 140 encryption, and SLA conditions on state agencies. HIPAA-covered data in Medicaid and behavioral health systems has its own obligations. State contracts need to name these categories explicitly and verify that the vendor's technical architecture supports compliance rather than relying on contractual assertion alone.

State AI procurement and transparency laws. Several states have enacted laws requiring state agencies to assess AI deployments before putting them into service. Connecticut's Public Act 26-15, for example, includes a provision effective October 1, 2026 under which state agencies may not procure AI systems unless they comply with Connecticut OPM and DAS policies and standards, and must post a public impact assessment at least 60 days before deployment. For state agencies subject to similar requirements, contract provisions need to bind the vendor to provide the documentation and access needed to complete that assessment. Some state laws also include employment AI decision-notice requirements whose duties apply to future deployments (Connecticut's employment AEDT provisions, effective October 1, 2026, apply to deployments on or after October 1, 2027); those timelines should be tracked and addressed in contract renewals before the obligations are live.

Accuracy accountability. The federal clause establishes 7-day notice and benchmark testing rights but does not set a numeric accuracy floor. For decision-support systems, an accuracy SLA should specify what constitutes a degraded performance event, what the vendor's diagnostic and remediation timeline is, and what the agency's remedies are beyond suspension. Defining what accuracy means in the specific use case before the contract is signed is the prerequisite to negotiating this term.

Audit rights. The federal clause includes documentation-on-request, benchmark testing, and access-log provisions as a model. State AI programs face additional state audit and legislative oversight requirements. Explicit audit provisions covering model evaluation data, bias testing results, inference logs for sampled decisions, and vendor security assessment documentation need to be negotiated for each deployment — the federal clause provides a foundation, but states often need broader access rights than federal contracting requires.

The procurement decision

The operational decision for a state CIO or chief procurement officer is not whether to develop AI contract terms in principle — most responding CIOs have now committed to that — but which contracts to act on first and what the minimum viable provision set looks like.

A recommended four-step sequence:

1. Audit current ELAs and enterprise contracts for AI features that have been activated, are licensed but inactive, or are scheduled to become available in the next renewal cycle. Any contract due for renewal in the next 12 months that includes an AI feature should have AI-specific provisions added at renewal. An AI feature that is licensed but not yet activated is still subject to the vendor's default data terms.
2. Add the core provision set to contract templates. The minimum follows the GSA clause: explicit prohibition on training data use without written authorization, model version evaluation window with defined timeline, safety and bias change notification requirement with a deadline, data portability that addresses the model layer, government ownership of fine-tuned modifications, and benchmark testing rights.
3. Add state-specific requirements. For each sensitive data category — FTI, HIPAA, CJIS — specify how the AI system must handle that data and require vendor attestation that their technical architecture supports compliance. Add state-law-specific assessment and disclosure requirements as they apply to each system.
4. Require vendor disclosure as a default. The NASCIO finding that 51% of responding CIOs had not yet required vendor disclosure means those states are negotiating without a complete picture of what AI capabilities their vendors are running in the environment. A disclosure requirement should be part of any ongoing vendor management program, not just new procurement.

The GSA clause gives state procurement teams a documented federal standard to work from. Adapting it for state contracts requires modification and state-specific additions — it is not a template to use as-is — but it removes the need to develop the core provisions from scratch.

Spartan X works with state technology leadership on AI strategy and governance frameworks, including the gap between an enterprise AI policy and the contract terms that make it enforceable. A recommended starting point is an inventory of existing vendor agreements and what AI capabilities are currently active or accessible, followed by a prioritized list of contracts to address at their next renewal cycle — a sequence that also serves as a defensible audit trail if state oversight bodies ask how the agency is managing its AI vendor risk.

Sources and further reading

• GSA, Class Deviation RGO-2026-01, including GSAR 552.239-7001, "Basic Safeguarding of Data within Large Language Model Artificial Intelligence Systems," finalized September 28, 2026, effective October 19, 2026. Full text (PDF).
• GSA draft clause (early 2026, released for comment March 6, 2026): "Basic Safeguarding of Artificial Intelligence Systems." Revised proposal published June 17, 2026: Federal Register 2026-12205.
• NASCIO, "The 2026 NASCIO State CIO Survey: The State CIO in Motion: Priorities, Pressures and Progress." Available at nascio.org.
• IRS Publication 1075, "Tax Information Security Guidelines for Federal, State and Local Agencies." Available at irs.gov.
• Connecticut Public Act 26-15 (2026 session). Sec. 38 effective October 1, 2026; employment AEDT disclosure provisions (Secs. 9–10) effective October 1, 2026 but apply only to deployments on or after October 1, 2027.
• Signal: [Connecticut's CART Act: The State AI Obligations to Prepare for Now](/signal/connecticut-cart-act-state-agency-ai-compliance) (September 16, 2026).