The GSA's New LLM Clause: Scope First, Then Controls

By Josh Hammer, CEO, H&V Complynt

Published October 8, 2026

The General Services Administration’s new clause for large language model procurements is already generating the wrong first question.

Many contractors are asking, “Do we use artificial intelligence anywhere in the business?”

That is not the right starting point.

The better question is: Is the government buying AI functionality from us, and is government data submitted to or produced directly by that model?

That distinction is the center of GSAR 552.239-7001, Basic Safeguarding of Data within Large Language Model Artificial Intelligence Systems. GSA issued the final class-deviation clause on September 28, 2026. It becomes effective October 19, 2026, although contracting officers may incorporate it into new procurements immediately and may exercise discretion to add it to existing contracts.

The clause is not an AI ban. It is not a mandate to purchase a particular compliance platform. It is a scope question wearing a control requirement’s clothes.

If you scope the clause too broadly, you may spend time and money implementing obligations that do not apply. If you scope it too narrowly, you may miss a live contractual requirement tied to data handling, subcontractors, incident reporting, and intellectual property.

My position is straightforward: AI governance is a scope question before it is a tooling question. First determine whether the clause applies. Then map the obligations to the controls and processes you already operate. Only after that should you select technology.

Tier 1: What the GSA Clause Actually Covers

The two-part applicability test

The final clause applies when two conditions are present:

1. The LLM or similar capability is a material feature of what the government is buying.
2. Government data is submitted directly to, or produced directly by, the LLM.

Both parts matter.

A contractor cannot determine scope simply by searching its network for AI software. The presence of an AI assistant in an employee’s productivity suite does not automatically mean the clause applies. Nor does the fact that an employee may use a general-purpose tool while performing administrative work.

The real question is whether AI is part of the material functionality being delivered to the government and whether government data enters or comes directly from the model.

This is why the final clause is narrower than earlier drafts. As Crowell & Moring explains in its analysis of the final rule, the clause self-deletes for incidental or ancillary LLM use and for internal business, back-office, operational, or performance-support systems that the government is not buying directly and does not access.

In plain language, a contractor’s internal use of AI is not the same thing as delivering an AI-enabled capability to the government.

Why “Do we use AI internally?” is the wrong first question

Consider two contractors.

The first provides a facility-management platform that uses an LLM to interpret maintenance requests, recommend work orders, and generate operational responses for government users. The AI capability is material to the offering. Government data is submitted to the model, and the model produces outputs that support the service.

That contractor should treat the clause as potentially in scope.

The second contractor uses a general-purpose assistant to help its finance team summarize internal meeting notes, draft routine correspondence, or organize administrative tasks. The assistant is not delivered to the government, and the government does not access the internal system.

That use may fall within the clause’s self-deleting carve-out.

The difference is not whether both companies use AI. The difference is what the government is buying, who accesses the system, and how government data moves through the model.

The Federal Scoop summary of the GSA policy captures the central change: the final clause applies when the government is buying AI, while internal use generally remains outside the clause unless the contracting officer identifies otherwise.

The effective date is not the scope analysis

October 19, 2026, is the clause’s effective date. It is an important contractual fact. It is not a substitute for reading the solicitation, contract, task order, or delivery order.

Contracting officers may incorporate the clause into new procurements immediately. They may also exercise discretion to add it to existing contracts. That means scope cannot be assessed only at the corporate policy level. You need a contract-specific analysis.

Ask:

• What capability is the government purchasing?
• Is LLM functionality material to that capability?
• What government data is submitted directly to the model?
• What data does the model produce?
• Does the government access the AI system or its outputs?
• Which subcontractors design, develop, deploy, operate, or monitor the capability?
• What does the contract say about data handling, reporting, and system changes?

The answer should be documented. A scope decision that exists only in an informal conversation will be difficult to defend during a review.

Tier 2: The Obligations and Their Control Families

Once the clause is in scope, the work becomes more concrete. The final rule includes a set of operational and contractual obligations that should look familiar to a mature security program.

Government data cannot train the model

The clause prohibits contractors from training LLMs on government data.

That prohibition should reach beyond the model-development team. Your organization should understand whether data can enter:

• Base-model training pipelines
• Fine-tuning workflows
• Retrieval or embedding systems
• Prompt libraries
• Testing and evaluation environments
• Vendor improvement programs
• Analytics or advertising systems

The controls must reflect the actual data path, not merely the language in a policy.

This is where NIST SP 800-171 Rev. 3 becomes useful for contractors protecting CUI in nonfederal systems. Its families include Access Control, Audit and Accountability, Configuration Management, Incident Response, Risk Assessment, System and Communications Protection, System and Services Acquisition, and Supply Chain Risk Management. The clause does not replace those requirements. It adds an AI-specific use restriction that must be implemented across the relevant system boundary.

Encryption and data protection

The clause requires encrypted transmission of government data and encryption at rest as applicable.

That obligation should be connected to your existing encryption architecture:

• Where is data transmitted?
• Which services receive it?
• Where is it stored temporarily?
• Are logs, caches, embeddings, backups, and model artifacts included?
• Which keys protect the data?
• Who can access those keys?
• Are subcontractors using separate or shared environments?

Encryption is not only a technical setting. It is also an evidence problem. You need configuration records, architecture documentation, key-management evidence, and a way to demonstrate that the controls remain in place over time.

The relevant NIST families are primarily SC, System and Communications Protection, and AC, Access Control. In NIST SP 800-53 Rev. 5, these families sit within a broader catalog that also includes audit, incident response, risk assessment, configuration management, and acquisition controls.

Audit logging without capturing government data

The clause requires audit logging that tracks processing without capturing government data itself.

That is a subtle but important requirement. A log should help establish what happened without becoming a second repository of sensitive content.

Your logging design should answer questions such as:

• Which system processed the request?
• When did the processing occur?
• Which account, service, or component initiated it?
• What operation took place?
• Was the data transmitted, stored, transformed, or deleted?
• Did an error or policy violation occur?

At the same time, the log should avoid recording prompts, outputs, attachments, or other government data unless specifically necessary and authorized.

This maps naturally to AU, Audit and Accountability, with supporting controls in CM, Configuration Management, AC, and SC. The objective is not to collect the maximum amount of telemetry. It is to collect useful evidence while minimizing exposure.

The 120-day disclosure requirement

The clause requires contractors to submit required disclosures within 120 days of commencing work.

That means disclosure preparation should begin during contract startup, not near the end of the reporting window. The responsible team should identify:

• What must be disclosed
• Which AI system and components are covered
• Which subcontractors participate
• What data flows through the system
• Which policies and procedures govern operation
• How changes will be recorded and reported

This is a governance and project-management requirement as much as a technical one. It belongs in the contract implementation plan.

The 72-hour incident report

The clause requires reporting incidents to the Contracting Officer and CISA within 72 hours.

The practical challenge is deciding what constitutes a reportable incident and ensuring that the reporting workflow reaches the right government recipients. Your incident-response plan should address AI-specific scenarios, including:

• Unauthorized disclosure of government data through prompts or outputs
• Accidental use of government data in model training or fine-tuning
• Compromise of an AI service provider
• Exposure of embeddings, model artifacts, or cached content
• Unauthorized model or configuration changes
• A failure that affects confidentiality, integrity, or availability

This is a direct connection to IR, Incident Response, but incident reporting also depends on AU, AC, RA, and SA controls.

The clause should be integrated into the broader incident-response process rather than handled as a separate AI procedure that no one remembers to activate.

Subcontractor flow-down and vetting

Prime contractors must flow the requirements down to subcontractors performing AI design, development, deployment, or monitoring tasks involving government data. They must also use best efforts to vet those subcontractors.

This changes the question from “Do we trust the vendor?” to “Can we demonstrate that the vendor’s role, data access, controls, and reporting duties are understood and governed?”

Your subcontractor review should cover:

• The specific AI task being performed
• The government data the subcontractor can access
• Whether data is stored, retained, trained on, or otherwise handled
• Incident-notification commitments
• Logging and evidence availability
• Model and service-change procedures
• Deletion and closeout responsibilities
• Flow-down language in the subcontract

This is where SA, System and Services Acquisition, and supply-chain risk management become especially important.

Protection of contractor background data and intellectual property

The final clause expands protections for contractor pre-existing intellectual property and background data.

Software, tools, workflows, documentation, models, scripts, analytics, know-how, and related materials used or improved during performance do not automatically transfer to the government merely because they are used in contract performance.

That distinction matters for contractors whose AI capability is built on reusable commercial technology. Before performance begins, document what existed before the contract, what was developed specifically for the government, and what general capability improvements occur during performance.

Contract language, architecture records, development histories, and asset inventories all help establish that boundary.

Termination and decommissioning costs

Noncompliance can lead to termination for cause and liability for decommissioning costs. That liability is capped at 25% of the affected task or delivery order value.

The cap does not make decommissioning planning optional. A contractor should know how it would:

• Stop processing government data
• Disable or replace the affected model
• Delete data, embeddings, and related artifacts as required
• Preserve records
• Transition services
• Coordinate with subcontractors
• Demonstrate closeout

The cost and operational consequences should be modeled before the system is deployed.

Mapping the Clause to NIST and the AI RMF

The GSA clause references the NIST AI Risk Management Framework 1.0, including categories for AI design, development, deployment, operation, and monitoring.

The AI RMF’s four functions (Govern, Map, Measure, and Manage) provide a useful operating structure:

• Govern: Assign responsibility, establish policies, define data and model ownership, and manage third parties.
• Map: Identify the intended use, affected stakeholders, data flows, model dependencies, and contractual scope.
• Measure: Test security, accuracy, safety, logging, access, and performance against defined expectations.
• Manage: Respond to incidents, correct deficiencies, manage changes, and retire systems safely.

The clause also maps across familiar NIST control families:

• AC, Access Control: Limit who and what can submit, retrieve, or administer data and models.
• AU, Audit and Accountability: Record processing events without capturing the government data itself.
• SC, System and Communications Protection: Encrypt data in transit and at rest as applicable.
• IR, Incident Response: Report qualifying incidents within 72 hours.
• RA, Risk Assessment: Determine whether the AI capability, data path, and providers create material risk.
• CM, Configuration Management: Govern model versions, integrations, prompts, and system changes.
• SA, System and Services Acquisition: Flow requirements to relevant subcontractors and evaluate suppliers.

This is the key practical point: a mature control environment already covers much of the clause. The clause introduces an AI-specific scope and data-use problem. It does not create an entirely alien security discipline.

Tier 3: The Compliance Platform Comes After the Plan

Compliance tools and the compliance process are not the same thing.

A platform can map controls, collect evidence, monitor systems, identify gaps, and organize work. It cannot decide whether GSAR 552.239-7001 applies to your contract. It cannot determine whether LLM functionality is material to the government’s procurement. It cannot replace contract interpretation, executive accountability, or a documented risk decision.

That is why I recommend this sequence:

1. Audit your current state.
2. Determine and document scope.
3. Build a remediation and evidence plan.
4. Then select the tools that support the plan.

H&V Complynt supports the operating layer after those decisions are made. The platform provides automated control mapping, evidence collection, continuous monitoring, pre-built content packs, and policy-as-code across more than 150 frameworks, including CMMC, NIST SP 800-171, NIST SP 800-53, RMF, SOC 2, HIPAA, and ISO 27001.

For organizations that need to map once and satisfy many requirements, that shared-control model can reduce duplicated work. Complynt runs on FedRAMP High and DoD IL5 authorized infrastructure on Palantir’s federal cloud.

To be clear, H&V does not issue certifications and cannot guarantee an assessment outcome. A platform cannot decide your scope, and automation cannot substitute for a functioning compliance program.

If you want to understand the operating model, review our compliance automation services. If you are still establishing the baseline, begin with a free readiness check.

What to Do This Week

Use the following checklist to begin a defensible scope and control review:

• Identify every contract, task order, and delivery order that includes or may include AI functionality.
• Determine whether AI is a material feature of what the government is buying.
• Document whether government data is submitted directly to or produced directly by the model.
• Record internal AI use separately from government-facing AI capabilities.
• Map government data flows, including prompts, outputs, embeddings, logs, backups, and subcontractor access.
• Confirm that government data is not used for model training or fine-tuning.
• Review encryption in transit and at rest as applicable.
• Design audit logs that track processing without capturing government data itself.
• Assign ownership for the 120-day disclosure.
• Test the 72-hour incident-reporting path to the Contracting Officer and CISA.
• Identify subcontractors performing AI design, development, deployment, operation, or monitoring tasks.
• Review flow-down language and best-efforts vetting records.
• Inventory pre-existing software, models, tools, workflows, documentation, and know-how.
• Document model decommissioning and data-deletion procedures.
• Build the remediation plan before selecting or expanding compliance tooling.

Read Next in This Series

• The CMMC Pause Is Now in Writing: What Class Deviation Revision 3 Changes, and What It Doesn’t
• The Copy-Paste SOC 2 Report Is Over: What the AICPA’s Crackdown Means for Your Controls and Your AI
• The FAR CUI Rule: Revision 3 Is Coming for Every Federal Contractor
• Technical Guide #4: How to Map Your CUI Boundary
• Compliance Tools Are Not a Compliance Program

Frequently Asked Questions

1. Is GSAR 552.239-7001 an AI ban?

No. The clause does not ban artificial intelligence or require contractors to use a particular technology. It establishes safeguarding, reporting, flow-down, data-use, and related obligations when the clause’s scope test is met.

2. Does every contractor that uses an AI assistant have to comply?

No. The first question is whether AI is a material feature of what the government is buying and whether government data is submitted directly to or produced directly by the model. Incidental use and certain internal back-office use may fall within the clause’s self-deleting provisions.

3. When does the clause become effective?

GSA issued the final class-deviation clause on September 28, 2026. Its effective date is October 19, 2026. Contracting officers may incorporate it into new procurements immediately and may exercise discretion to add it to existing contracts.

4. What are the most important operational obligations?

The major obligations include prohibiting training on government data, protecting data through encryption, maintaining audit logs without capturing government data itself, submitting required disclosures within 120 days of commencing work, reporting incidents to the Contracting Officer and CISA within 72 hours, flowing requirements to relevant subcontractors, and managing contractor background intellectual property.

5. Should a contractor buy a compliance platform before analyzing the clause?

No. Audit your current state, determine scope, and build a plan first. A compliance platform can support control mapping, evidence collection, and monitoring, but it cannot determine whether the clause applies or replace the compliance process.