On June 17, 2026, the General Services Administration (“GSA”) formally published its revised draft of a new GSAR clause, “Basic Safeguarding of Data within Large Language Model Artificial Intelligence Systems (LLMs),” in the Federal Register. The clause is a significantly reworked version of the version that sent shockwaves through the government contracting community earlier this year in March. The comment period runs through August 3, 2026, with a public listening session set for July 14.

For contractors with GSA Schedule contracts, or tech companies whose products touch federal procurement, the new clause warrants immediate attention even in draft form. GSA has signaled it intends to move quickly, and the 60-day acceptance window after final adoption will leave little room for last-minute scrambling.

Here's what contractors should be doing right now.

First, Understand What Actually Changed

The March draft was broad enough to justify the alarmed responses. It applied to any contract "for AI capabilities" without defining that term or distinguishing between the different parties in an AI supply chain. And its data ownership provisions were written with sufficient breadth that it was reasonably read as potentially reaching contractor background IP and commercially developed models. Amid substantial industry pushback, GSA extended the comment period and substantially reworked the draft. The revised clause is meaningfully narrower, but don't mistake "narrower" for "toothless."

The most important scoping change is that the clause now applies only when government data is processed by an LLM as part of contract performance. That's a real carve-out. LLMs embedded in common commercial products (e.g., word processors and navigation tools) are explicitly excluded, as are situations where LLM functionality is merely incidental to a contract's primary purpose.

That said, the core obligations that drew the most industry fire remain. Government ownership of data inputs and outputs is intended to ensure that sensitive federal information and any insights derived from it cannot be retained or repurposed by a vendor. The prohibition on using government data to train or improve AI models targets the concern that commercial providers might quietly improve their products on the government's dime, though critics note this restriction may make it harder to deploy the most capable and up-to-date models on federal contracts. And the "no refusals" requirement reflects the government's desire to ensure it gets what it pays for, without a vendor's commercial or political risk calculus getting in the way. The revised clause does not resolve the central tension of imposing obligations that AI systems (and their providers’ standard terms) may not be capable of satisfying. In previous Navigator posts, we have been tracking related tensions in our series about the Anthropic and the US Department of War (see our posts from March 3, March 9, April 27, and May 15).

The clause also introduces a structured supply chain framework, distinguishing between LLM Developers, System Operators, System Integrators, and Service Providers, with tailored flow down requirements for each tier. This is more sophisticated than the earlier March draft, but it also creates additional new complexity for prime contractors who must now identify which roles apply to each entity in their vendor stack.

Step One: Mapping LLM Exposure

Before a contractor can assess compliance, they need an accurate picture of where LLMs actually touch their government contracts. This is harder than it sounds.

Consider the following three questions:

1. Is the contractor selling AI? If a contractor has a GSA Schedule contract that includes LLM-based products or services (e.g., chatbots, document review tools, or data analytics platforms), the new clause almost certainly applies to those offerings.
2. Is the contractor using AI to perform the contract? This is the sleeper issue. A contractor selling sensors, IT services, or professional services may be using a third-party LLM internally to help with deliverables. If government data flows through that tool (and in many engagements it will), the clause may apply.
3. What counts as government data? The revised definitions now explicitly include user prompts, queries, generated responses, and derived data. Contractors must think beyond structured data in databases. A government employee's prompt to a contractor-deployed chatbot is likely to be treated as government data under the clause’s definitions.

This analysis should be tied to both contract scope and data lineage (i.e., how government data is introduced, transformed, and potentially exposed across systems). Taken together, these three questions define a compliance perimeter that is wider than most contractors expect. The instinct to ask only “are we selling AI?” misses the second and third questions entirely. Question two is the one that will keep contractors — particularly those incorporating third party AI tools or subprocessors — up at night. 

Step Two: Auditing the Vendor Stack

One of the most operationally challenging aspects of this clause is the flow-down requirement. Prime contractors bear responsibility for ensuring that subcontractors and service providers, at every applicable tier, comply with the relevant clause provisions. For most contractors, this surfaces three interconnected challenges.

The first is the terms mismatch. Standard commercial terms from major AI providers almost certainly conflict with some aspects of this clause, particularly the prohibition on using government data to train models, the "eyes off" data handling requirements, and the government data ownership provisions. Most end-user license agreements are designed around the opposite assumption. This places prime contractors in the position of bearing compliance risk they do not fully control.

The second is understanding renegotiation leverage. Not all vendor relationships are equal, and knowing which can realistically be renegotiated is worth assessing sooner rather than later.

The third is documentation. We have helped clients work through the process of mapping each AI vendor against the clause's new taxonomy, identifying which flow-down provisions apply, and tracking gaps between current terms and what the clause requires. This work aids organizations both with compliance and the rulemaking comment process.

Step Three: Understanding the Complexity of “No Refusals”

Paragraph (b) of the clause requires that AI systems not refuse to produce outputs or conduct analyses based on the contractor's or service provider's "discretionary policies." This provision is generating significant controversy, and for good reason (have you clicked through to our Anthropic series yet?).

Most commercial AI systems have content moderation policies, safety guardrails, and usage restrictions baked into the model at a level that cannot be overridden by contract. These reflect decisions made by the AI provider about what the system will and won't do.

Contractors don't have to look far for a preview of where this may lead. The ongoing dispute between Anthropic and the Department of War (in active litigation as this is written) is largely a fight about whether the government can require an AI vendor to remove usage restrictions as a condition of doing business with the federal government. Neither side has prevailed definitively, and the DC Circuit has the question on expedited review. The outcomes of this litigation will almost certainly inform contractors how GSA's no-refusals requirement is interpreted and enforced, making it one of the more important pending cases for government contractors weighing compliance with this provision.

The clause explicitly states this requirement "must not be construed to require retraining of the model or alteration of model weights," but it's not clear how a contractor ensures compliance with a no-refusals obligation without those technical changes. In effect, it attempts to contract around model-level safety architecture, which is something vendors may not be technically or commercially able to do. This tension is unresolved in the current draft. For many contractors, this is a technical constraint rather than a contractual one: if the model will not generate the requested output, the contractor may have no ability to compel it to do so.

For many contractors, compliance with this provision will turn less on contract language and more on whether their chosen model provider can technically support the required behavior. In the meantime, contractors should document instances where commercially deployed LLMs decline government-relevant queries. This empirical record will be useful both in commenting and in any future compliance defense.

Step Four: Providing Comments and Feedback

The upcoming August 3 deadline is real, and GSA has demonstrated it takes industry feedback seriously. This is an opportunity that sophisticated contractors should not pass up.

GSA specifically asked for comment on five questions in the Federal Register notice:

1. Does the narrowed scope adequately address earlier concerns about overbreadth?
2. Are government data ownership and contractor accountability provisions clearly defined?
3. Are the LLM supply chain roles and flow-down requirements clearly articulated?
4. Do commenters understand how to implement the flow-down clauses in practice?
5. Does the clause adequately address foreign ownership and control risks?

Questions 3 and 4 are unique opportunities. The practical mechanics of flowing down obligations to commercial AI vendors that are not parties to the government contract, and operate under standardized, non-negotiable terms, remain deeply underexplored in the draft. A well-constructed comment that walks through real-world implementation challenges, with specific suggested language, will carry real weight with GSA.

GSA will also hold a public listening session on July 14, 2026, from 11 a.m. to 2 p.m. ET at George Washington Law School’s Lerner Hall, and virtually. Registration closes July 3. Speakers must register separately and commit to one of four topic tracks: Government Data Ownership and Protection Requirements, Prime Contractor Requirements, Clause Flow-down Requirements, or Other Clause Requirements.

For contractors with strong stakes in this rule, appearing at the listening session (even virtually) sends a signal. More practically, contributing to the conversation (in any format) creates a contemporaneous record of contractors’ concerns that can be referenced in subsequent comments and, if litigation ever becomes relevant, in briefing. A well-developed comment record may also become relevant if aspects of the clause are later challenged or require interpretation in disputes.

For more information about AI governance, federal compliance, or government contracting, please contact the Jones Walker Privacy, Data Strategy and Artificial Intelligence team. Stay tuned and subscribe for continued insights from the AI Law and Policy Navigator.