TPRM PlatformAgentic GRCMSME AssuranceVoice AI for GRCAI Voice AuditCredit-AIPortfolioBlogAbout Crest
Skip to main content

crest.digital

AI GOVERNANCE & THIRD-PARTY RISK

GSA’s AI Clause Takes Effect October 19. Your Subcontractors’ AI Is Now Your Problem.

GSAR 552.239-7001 makes the prime contractor answerable for large language model systems run by its subcontractors, and it expects incidents to be reported and flowed down the chain. Most vendor registers cannot yet show where that AI sits.

Crest.Digital Editorial October 12, 2026 8 min read Risk & Compliance

On October 19, 2026, a new General Services Administration contract clause becomes mandatory for relevant federal procurements. Its number is GSAR 552.239-7001, and its title, “Basic Safeguarding of Data within Large Language Model Artificial Intelligence Systems,” describes a narrow technical subject. Its practical effect is wider: it turns the AI used somewhere in a contractor’s supply chain into a contractual obligation of the prime.

This matters well beyond US federal suppliers. Any enterprise that buys AI-enabled services, or sells to customers who do, will soon face similar questions in its own contracts and audits. Below we read the clause the way a third-party risk and internal audit team would: what it requires, where the exposure really sits, and what evidence you will want in hand before a customer or auditor asks. It extends themes from our earlier pieces on why the AI inventory starts with the vendor inventory and why AI agents need audit trails.

You cannot flow down what you cannot see.

Crest.Digital’s Agentic GRC turns AI obligations into controls, tests and evidence, so compliance can be shown between audits rather than reconstructed for them.

Explore Agentic GRC

What the GSA AI Clause Actually Says

GSA first published a draft of the clause in March 2026 and invited comment. A contractor-advisory summary of the final version, published this week, sets out the main points. The clause is effective October 19, 2026, and contracting officers may apply it earlier at their discretion. Its core obligations are:

Responsible design. Contractors must make reasonable efforts to design, train and configure the language model so that it prioritises accuracy, scientific inquiry and objectivity, and the government may run automated assessments of the model for factors such as bias, truthfulness and safety.

Incident reporting. Incidents affecting a language model used in contract performance, where government data may be affected, must be reported. For systems already authorised under FedRAMP, existing FedRAMP or CISA reporting may satisfy the requirement in some cases.

Subcontractor flowdown. The clause flows to subcontractors that perform AI design, development, deployment, operation or monitoring. The prime remains responsible for implementing it and must use best efforts to flow it down to AI subcontractors where applicable.

Bounded liability. After a termination for cause, the contractor’s liability for decommissioning costs is capped at 25% of the affected task or delivery order.

⚠
Responsibility Stays With the Prime. The clause reaches subcontractors that design, deploy, operate or monitor AI, but the prime must implement it and flow it down. A subcontractor’s weak AI governance becomes your compliance finding.

A caution on sources. We have worked from public legal and contractor commentary rather than the full clause text, and the final language differs in places from the March draft, which for example described specific notice periods and reporting windows. Contract teams should read the clause as it appears in their solicitation and confirm details with counsel before relying on any summary, including this one.

Who Is In Scope, and Who Thinks They Are Not

The clause applies when the government buys language-model-based systems that receive or produce government data. Based on the published summary, it does not reach internal back-office use that is never delivered to or accessed by the government, nor incidental AI features inside commercial products whose main purpose is not AI, unless the contracting officer says otherwise.

That carve-out is where many organisations will misjudge their position. “Incidental” is a judgement call, and it is made by someone outside your company. A project-management tool with a generative summary feature, a ticketing platform with an AI assistant, or a transcription service used on a government programme can all quietly move from incidental to material once government data passes through them. Before concluding that you are out of scope, test the assumption against a real inventory of the AI features your delivery teams and suppliers actually use.

The Flowdown Problem: Three Gaps in Most Vendor Registers

Flowdown clauses are routine in procurement. What makes this one difficult is that the thing being flowed down, AI, is poorly captured in the records most companies keep about their suppliers. Three gaps recur.

1. The register records suppliers, not the models behind them. A vendor master shows who you pay. It rarely shows which foundation models a supplier calls, where prompts and outputs are stored, or whether the supplier has handed work to a fourth party. Without that, you cannot say which subcontractors “operate or monitor” AI on your behalf. We explore the same weakness in AI governance and vendor due diligence.

2. Features change after onboarding. AI is often switched on through a software update, long after the due diligence file was closed. An annual questionnaire cannot detect that a supplier enabled a new assistant last month. Continuous monitoring of supplier change notices, public documentation and trust-centre pages is the only realistic way to keep pace, and it is the kind of work AI agents are well suited to, with a human deciding what to accept.

3. Incident clauses do not match incident reality. A reporting duty is only as good as the supplier’s ability to detect and tell you. If a subcontractor’s agent misbehaves or a model leaks data, how fast do you learn, in what form, and with what logs? The audit-trail controls we describe in our agent audit-trail guide are the evidence you will need to answer a contracting officer or a regulator. For concentration questions, see also AI third-party concentration risk.

A Six-Step Plan to Evidence Third-Party AI Compliance

We deliver this kind of assurance as a configurable pod rather than a bespoke build: reusable connectors, workflow, evidence repository and audit trail, with client-specific effort focused on data mapping, control logic and reporting. The sequence is Discover, Design, Connect, Deploy, Validate, Transfer.

1

Discover Where Language Models Touch Contract Data

For each in-scope contract, list the systems that receive or produce customer or government data and identify which contain language models, whether built in-house, bought, or embedded in a supplier’s service.

2

Design Supplier Obligations You Can Actually Test

Turn clause language into a short set of supplier requirements: disclosure of models and subprocessors, incident notification timing and content, logging, and change notification. Each requirement needs an owner and an evidence type.

3

Connect Contracts, Vendor Records and Evidence

Link the contract repository, vendor master, security attestations and incident tickets so one view shows which subcontractor supports which obligation, and what proof exists.

4

Deploy Continuous Supplier AI Monitoring

Automate outreach and evidence collection, watch for supplier changes that add or alter AI features, and route exceptions to the right owner. Start with suppliers that handle sensitive or regulated data.

5

Validate With an Incident Tabletop

Run a scenario in which a subcontractor’s model exposes contract data. Measure how long detection, escalation and customer notification take, and fix the gaps before a real event.

6

Transfer to Procurement, Security and Legal Owners

Hand the process to named owners or run it as a managed service, and report coverage, open exceptions and incident readiness to the risk committee on a regular cadence.

Step five is the one that earns trust. Internal audit can independently test the sample, which aligns with the Institute of Internal Auditors expectation of assurance over governance and risk management, and the NIST AI Risk Management Framework offers a widely used vocabulary for documenting the result. Our article on independent AI audits and assurance covers what credible testing looks like.

Supplier AI is a third-party risk problem first.

Crest.Digital’s vendor intelligence platform assesses supplier governance, collects evidence and monitors change continuously across the industries we cover.

Why This Matters Beyond Federal Contracts

Procurement clauses are a leading indicator. Large buyers copy language that works, and regulators look to contract practice when defining what “reasonable” oversight of a supplier means. The EU AI Act already allocates duties along the AI value chain, and ISO/IEC 42001 assumes an organisation understands the AI it relies on from others, a point we make in why an ISO 42001 certificate is not proof of AI governance. A company that can evidence supplier AI controls for one demanding customer will find the same evidence answers the next questionnaire, the next audit and the next board question.

The practical conclusion for risk leaders is modest and urgent. Know which suppliers use language models on your data, write obligations you can test, and keep proof that the controls run. October 19 is a useful deadline for contractors, but the same discipline is worth building for everyone else.

Three Questions to Answer Before October 19

  • Where is the AI? Can you list every supplier and internal system that applies a language model to data from your federal or other regulated contracts?
  • Who is bound? Which subcontractors design, deploy, operate or monitor that AI, and does each contract carry the flowdown and reporting terms you now need?
  • Where is the proof? If a contracting officer asked tomorrow, could you produce incident procedures, logs and supplier disclosures in a day rather than a month?

Where does your organisation stand? Share your view when you pass this on through LinkedIn.

Crest Perspective

AI governance programmes that treat AI risk as a technology problem will be underprepared for the regulatory environment taking shape in 2025–26. The EU AI Act, NIST AI RMF, and emerging FCA guidance all frame AI risk as a governance and accountability question first — the technology controls follow from having clear answers to who is responsible, what decisions the AI influences, and what the escalation path is when the system behaves unexpectedly.

Frequently Asked Questions

GSAR 552.239-7001, titled “Basic Safeguarding of Data within Large Language Model Artificial Intelligence Systems,” is a General Services Administration contract clause for federal procurements involving language-model-based systems that receive or produce government data. According to published contractor commentary, it takes effect on October 19, 2026, can be used earlier at a contracting officer’s discretion, and covers responsible design, incident reporting and flowdown to AI subcontractors. Always confirm the exact wording in the solicitation you are bidding on.

Yes, in effect. The clause flows down to subcontractors that perform AI design, development, deployment, operation or monitoring. The prime contractor stays responsible for implementing the clause and must use best efforts to flow it down to AI subcontractors where it applies. That means a prime needs to know which of its suppliers fall into those roles, and to hold contract terms and evidence that show it has passed the obligations along.

Published summaries say incidental AI features in commercial products whose primary purpose is not AI are generally outside the clause, unless the contracting officer decides otherwise, and that internal back-office use not delivered to or accessed by the government is also excluded. Because the line depends on judgement, organisations should maintain an inventory of AI features in the tools used on government work and document why each is or is not treated as in scope.

Start by extending the vendor register to record which suppliers use language models, on what data, and through which fourth parties. Add AI-specific questions to due diligence, require incident notification and logging commitments, and monitor suppliers for changes that add AI features after onboarding. Then test the process with an incident tabletop. Automation and AI agents can handle outreach, evidence collection and change monitoring, while people decide risk acceptance.

Useful evidence includes an inventory of AI systems and the suppliers behind them, executed contracts showing flowdown and incident terms, supplier disclosures and attestations such as FedRAMP authorisation or an AI management-system certificate with its scope, records of monitoring and exceptions, incident procedures with tabletop results, and logs that let you reconstruct what an AI system did. Keeping these linked to each contract makes responses to customers, auditors and regulators much faster.

GSA AI Clause Third-Party AI Risk AI Governance Supply Chain Compliance Agentic AI Vendor Risk

Sources & References

  1. NIST AI Risk Management Framework (AI RMF 1.0)
  2. EU AI Act — Regulation (EU) 2024/1689
  3. OECD AI Principles (Recommendation of the Council on Artificial Intelligence)
  4. FCA: Artificial Intelligence — Our Approach
  5. The Institute of Internal Auditors (IIA): Global Internal Audit Standards

See how Crest can help

AI-powered TPRM, compliance automation and GRC intelligence for enterprise teams.

Request a Demo →

Ready to get started?

Bring structure, automation, and continuous intelligence to your GRC Process — without adding headcount.

★ Schedule a Demo