GSA AI clause would box out open models, BSA says
A provenance test built for closed models can turn security hygiene into procurement favoritism without saying the word ban.
TL;DR
Business Software Alliance told the General Services Administration that its revised artificial intelligence (AI) acquisition clause still functions as an open-source restriction, even after GSA narrowed a broader foreign-component ban to allow incidental foreign-developed components under conditions. Primes, AI contractors and agencies face the practical problem: tracing model lineage, ownership and foreign control can be infeasible for open models. Comments close Aug. 3, and the final wording may decide whether cheaper open-weight options survive federal procurement.
Inside Cybersecurity reports that the Business Software Alliance used a July 14 General Services Administration listening session to object to the second draft of GSA’s artificial intelligence acquisition language. The draft would add GSAR 552.239-7001, Basic Safeguarding of Artificial Intelligence Systems, to GSA solicitations and contracts for AI capabilities, according to the posted draft. GSA has narrowed a broader foreign-component ban into a conditional allowance for incidental foreign-developed components. That sounds like flexibility. BSA’s point is that flexibility disappears if the proof obligation cannot be performed.
Shaundra Watson, BSA’s senior director of policy, said routine work such as fine-tuning open-source models or distilling them into smaller, faster versions can obscure original lineage. Her conclusion was blunt: requiring contractors to trace all components or measure foreign control effectively bans open source because the traceability work can be practically infeasible. The affected party on paper is the prime. The operational pressure lands on every AI integrator deciding whether an open-weight model is worth the certification risk.
Where the clause fits closed models
NVIDIA senior AI strategist Shane Shaneman put a cleaner architecture problem on the table: the draft’s flowdown duties treat open-weight and closed large language models as if the same actor controls development, hosting and access to government data. For a closed hosted model, that assumption often works. For an open model deployed inside a government-authorized environment, the upstream model developer may publish weights, then never receive prompts, outputs or deployment information. That assignment is paperwork aimed at the wrong legal entity.
Shaneman’s Linux analogy is useful because it names the procurement actor. The government does not make Linus Torvalds attest to every federal Linux deployment. It makes the accountable packager or integrator, such as Red Hat, carry the obligation. His proposed fix follows the same logic: apply developer flowdown only when the developer receives, accesses or processes government data, and put operational duties on the operator or integrator for open models run inside an authorized enclave.
What GSA needs to answer
GSA’s own open-source order says the agency takes an “open-first approach” to data, application programming interfaces, artificial intelligence and source code, and lists vendor diversity, competition and security among the reasons for doing so. The draft AI clause points in the other direction if it forces contractors toward proprietary models because those vendors can paper lineage more cleanly. The security review should decide model acceptability. A traceability requirement that only closed supply chains can satisfy decides it earlier, and for a different reason.
Before Aug. 3, contractors commenting on the draft have two practical asks: define “practical feasibility” for provenance and foreign-control tracing, and create an express path for open-source and open-weight models that meet security and data-protection safeguards. Otherwise the final clause will let GSA say it permits open models while telling contracting teams to buy the easier paperwork.
Published ·Deep Fathom