Your Model Now Comes With Terms

On Friday, a procurement fight that looks like inside baseball suddenly became a blueprint. Reuters reported that the U.S. General Services Administration drafted new guidance for civilian AI contracts that would require vendors to allow "any lawful" use of their models. In plain English, the buyer is trying to pre-negotiate the answer to the question every AI vendor dreads. What happens when your product policy collides with what the customer wants to do.

If you are a founder or operator, the interesting part is not which lab wins the argument. The interesting part is that this is what the next phase of AI adoption looks like. The model is not just a tool you subscribe to. It is a vendor relationship with terms that can change your product and your risk profile overnight.

Here is the context. The report says the draft would require AI groups seeking U.S. government business to grant the U.S. an irrevocable license to use their systems for all legal purposes. Reuters also reported that the Pentagon designated Anthropic a "supply-chain risk" in a separate action that bars contractors from using Anthropic technology in work for the U.S. military. Those two stories together point to a single operational reality. AI is being pulled into procurement, and procurement is where idealism goes to get converted into contract language.

Most teams are not set up for that conversion. You have been thinking about model quality, prompt libraries, and whether your team likes Tool A or Tool B. Meanwhile, large buyers are asking different questions. Can we rely on this vendor across administrations. Can we use the model for every lawful purpose we might need. Will the vendor refuse certain uses. Will the vendor change its terms. Can we keep using the model if someone calls it a security risk.

The turn is that once AI becomes a procurement category, your leverage shifts. When a tool is a tab in your browser, you can swap it with minimal pain. When it is embedded in workflows, data handling, and customer deliverables, the switching cost rises. That is exactly when contract terms start to matter. Not because you suddenly enjoy legalese, but because the legalese is now shaping your operational freedom.

So what do you do with this if you are not selling to the government. You treat government procurement as a preview market. Rules created for the biggest buyer in the country tend to leak. They show up as standard clauses in enterprise contracts. They show up as vendor questionnaires. They show up as ‘please attest’ checkboxes in procurement portals. Eventually they show up in your inbox, even if you run a ten person company.

There is a simple mental model that helps. Your AI stack has two parts. The model and the contract. The model determines what is possible. The contract determines what is permitted, who owns what, and what happens when something goes wrong. For the last two years, most teams obsessed over the first part and ignored the second. The next two years will punish that imbalance.

The Reuters report also noted additional provisions described by the Financial Times. The draft would mandate that contractors must not intentionally encode partisan or ideological judgments into AI system outputs. It would require disclosure of whether models have been modified or configured to comply with non U.S. government or commercial regulatory frameworks. Even if you ignore the politics, you can see the pattern. Buyers want control over how the model behaves, and they want visibility into what shaped it.

If you buy AI, you should start asking procurement style questions earlier in your adoption curve. Where does your data go. What rights does the vendor claim over your inputs and outputs. What logging exists. What happens if a regulator or a customer demands an audit. Can you reproduce a critical output six months later. Can you route the same workflow to an alternative model without rebuilding everything.

This is where most teams get tripped up. They think ‘vendor risk’ means a vendor goes down. In practice, vendor risk is more subtle. A vendor can stay up and still become unusable for you because the rules changed. Your customer changes requirements. Your legal counsel changes policy. A new clause appears in an MSA. Your security team decides the vendor is now a problem. Same tool, same UI, different reality.

You can design for this without becoming a lawyer. Start by separating low risk and high risk usage. Low risk is internal drafting with no sensitive data. High risk is anything that touches customer data, regulated information, contracts, or external promises. The mistake is treating these as one bucket. They are different systems with different failure costs.

Then build one exit ramp. Pick one mission critical workflow and make it portable. That means your prompts are stored somewhere other than an individual chat window. Your inputs are templated. Your outputs are saved with context. You can re run the workflow on another model and get a comparable result. You are not aiming for perfection. You are aiming for survivability.

If you ship software, the same idea applies at the product layer. Do not hardwire a single model provider into a single end user experience. Create an abstraction for model calls. Log the decisions that matter. Keep a path to swap vendors for specific features. AI is becoming infrastructure, and infrastructure needs redundancy.

The punchline is not that the government is strict. The punchline is that AI is graduating from a productivity hack into a governed dependency. That is good news if you operate it like a dependency. You get leverage without fragility. You get faster work without losing control.

This week, take one practical step. Find the place where AI output becomes an external commitment. A customer email. A contract redline. A policy memo. A pricing doc. Put a small receipt next to it. What went in, what model was used, what came out, and who approved it. That tiny habit is how you turn AI from a magic trick into an operable system.

Your model now comes with terms. Treat them like product requirements. Because they are.