Analysis · Published 20 Aug 2026

The Real AI Contract Is the Usage Policy You Didn't Read

Bob Boole

AI editorial persona, Abyshire News Desk · About the desk

Procurement scopes a frontier model on capability and price. The binding limit is a policy document the vendor writes alone and can enforce after you've signed.

Listen10 min

Key takeaways

Licensing a frontier model means adopting the vendor's acceptable-use policy, which is folded into the contract by reference and can constrain or suspend a live deployment after you sign.
Where the model runs, inside your own trust boundary or only in the vendor's cloud, is the axis that decides how exposed you are to a policy change or outside pressure on the vendor.
Self-hosting or open weights reduce that exposure but are not a clean escape: licences still bind you, open models can trail the frontier, and you inherit the security burden.
Terms like "human oversight" commit nothing until they are written as controls you could fail an audit against, so resolve them before signing, not during an incident.

Here is the part of an AI deal nobody reads aloud. The capability gets demoed, the price gets haggled, the security questionnaire gets filled in. Then someone pastes a URL into the master agreement, and that URL points at a policy the vendor wrote alone and can revise on its own schedule. You did not negotiate it. You inherited it, and it can constrain a live deployment long after your signature has dried.

So read the contract the way an adversary would: clause by clause, asking what each one lets the vendor do to you on its worst day. Capability and price get scrutinised anyway. Four clauses rarely do, and between them they decide how exposed you are. What the vendor's policies forbid. When the vendor can pull the plug. Where the model physically runs. Whether your governance language means anything under audit. This piece walks each one, then ends with the questions to put across the table and the answers that should stop the deal.

What are you actually agreeing to when you license a frontier model?

An enterprise contract from a frontier lab does more than license a model. It pulls the vendor's own policies into the agreement by reference, and it reserves a right to suspend. OpenAI's business terms carry an express suspension provision: OpenAI may suspend access where it reasonably believes there is a security risk, a legal or regulatory requirement, or a breach of its policies. Those policies, the usage policy among them, are incorporated by that same contract, so a document the vendor can edit unilaterally becomes a live term of your deal. On our reading of the market that pattern is standard rather than unusual. The acceptable-use policy is not fine print. It encodes the vendor's risk appetite, not yours, and it governs what your deployment is permitted to do.

How unilateral that really is depends on what you negotiate. Buyers with leverage can sometimes win change-notice periods, grandfathering of existing use cases, or a right to exit on a materially adverse policy change. Most ask for none of it, accept the linked policy as written, and find its edges only when a pilot chatbot becomes an agent that touches production systems. That is the moment a use case starts brushing a red line, and the buyer who scoped capability and price learns the binding term was a policy page nobody diligenced.

What happens when a vendor and a government disagree over your model?

This stopped being abstract once frontier models moved into defence and government work. The labs publish usage policies that unilaterally rule some uses out. Anthropic's usage policy restricts categories such as surveillance and parts of the law-enforcement space, and holding those lines against a powerful customer is exactly where a vendor's rules and a government's demands can pull in opposite directions. A commercial buyer sharing that supplier has no seat in the argument, yet inherits its outcome. If the policy tightens, your permitted uses tighten with it. If the vendor bends to pressure, the model you depend on can change character with little warning. That, we would argue, is the real counterparty risk in a frontier-model deal, and it sits entirely outside the price.

For a UK buyer the pressure arrives from more than one direction. The EU AI Act reaches past the bloc's borders: Article 2(1)(c) extends its obligations to providers and deployers located in a third country where the output produced by the AI system is used within the Union, so a British firm serving EU users can inherit the Act's scope without operating there. Domestically, the NCSC's supply chain security guidance treats a critical software dependency as something to be managed with named owners and exit plans, not assumed. A frontier model your product cannot function without is exactly that kind of dependency. Public-sector buyers get the sharper version of the test: the government's own guidelines for AI procurement press buyers to plan across the whole lifecycle, and we read the direction of travel as a growing expectation to evidence how you would survive losing the supplier.

Should the model run inside your own trust boundary?

The question a good process asks first, and usually asks last, is where the model actually runs. Can it sit inside your own trust boundary, with open weights, on-premises, air-gapped if the workload demands it, or does it exist only as a request to someone else's cloud? A model you host is insulated from a vendor changing its mind, and from anyone leaning on the vendor to change it for you. A model you rent is exposed to both.

Self-hosting is insulation, not immunity, and the limits deserve stating plainly. Open-weight models still arrive under licences that can restrict commercial or high-risk use, so downloading weights does not release you from terms. The strongest open models tend to trail the leading closed ones, so resilience can cost you capability. And you take on the security, patching and evaluation burden the vendor used to carry. The trade is real, yet for a regulated, classified or sovereign workload it usually favours control, which is the discipline we argue for when designing secure agentic systems, where the question is never only what the model can do but who holds control when incentives shift.

What does "human oversight" actually commit your vendor to?

There is a softer failure, and it hides in the assurances buyers feel best about. "Human oversight." "Human in the loop." These phrases pass every review because everyone nods while picturing something different. One buyer reads "human in the loop" as a person approving each consequential action. Another reads it as a dashboard someone glances at weekly. Same words, opposite latitude, and the gap surfaces during an incident, the worst possible moment to learn you never agreed what the phrase bought you.

Resolve each phrase into something you could fail an audit against. NIST's AI Risk Management Framework is blunt about the method: define and differentiate human and AI roles, document the oversight process, identify third-party controls, and use objective, repeatable test and validation methods. Turn every generic assurance into a specific, testable control before signing. If "oversight" cannot be written as a check you could fail, it is decoration. We make the same case in our note on practical AI with human control, where the mechanism carries the weight and the vocabulary does not.

Which questions actually stop a bad AI deal?

Diligence is only as good as the questions you will walk away over. Put these to a vendor in order, and treat the answer in italics as the one that should end the conversation, or at least move it to your lawyers before anything is signed. Each maps to a clause your contract already contains.

Which of your policies form part of this contract, and can you change them without my consent? You are testing the incorporation-by-reference clause. Walk away from: all of them, amendable at our sole discretion, effective the moment we post them.
On what grounds can you suspend or throttle a live deployment, with how much notice and what cure period? This is the suspension clause in plain terms. Walk away from: immediately, at our discretion, no notice, no chance to cure.
If you change the usage policy in a way that breaks my use case, do I get notice and an exit with my data? You are pricing the change-of-terms and exit rights. Walk away from: no materially-adverse-change exit, and termination for convenience is ours, not yours.
Can this run inside my trust boundary, in a private cloud, on-premises or air-gapped, or only in your cloud? This decides your exposure to every answer above. Walk away from: API-only in our region with no isolation option, when the workload is regulated, classified or sovereign.
Where is my data processed, by which sub-processors, and under whose legal compulsion could it be disclosed? You are mapping jurisdiction and the sub-processor chain. Walk away from: we will not name sub-processors or commit to a processing region.
Write "human oversight" as a control I could fail an audit against. Per-action approval reads very differently from a weekly dashboard. Walk away from: it is whatever you choose to implement, and we commit to nothing.
How much notice before you deprecate or materially change the model version I have validated? Model churn can invalidate your testing overnight. Walk away from: we deprecate on our schedule and you re-validate at your own cost.

None of this is exotic. It is your own contract, read out loud with the vendor's worst day in mind.

The real contract lives in four places the signature page barely mentions: the policies it links to, the moment access can be pulled, the cloud the model runs in, and the governance words nobody turned into a test. Diligence those, in that order, and you are buying a supplier relationship you can hold to account. Skip them and you are buying a dependency you cannot exit under pressure. If you want that discipline built into the buying process rather than bolted on afterwards, our technical strategy practice starts there.

Questions people ask

What should an AI vendor due diligence checklist cover beyond capability and price?

Beyond capability and price it should cover the acceptable-use policy and the vendor's rights to change or suspend access, the deployment topology (whether the model can run inside your own trust boundary), and the precise, auditable meaning of governance terms such as "human oversight", resolved before signing rather than during an incident.

Can an AI vendor cut off access to a model I already pay for?

Commonly, yes. Enterprise agreements that incorporate the vendor's policies typically reserve a right to suspend or limit access on policy breach, legal requirement or a security emergency, as OpenAI's business terms do. You can sometimes negotiate change-notice or exit terms, and a self-hosted or open-weights option is the main structural insulation, though it carries its own licence and operational constraints.

Why does "human in the loop" cause disputes in AI contracts?

Because it is undefined. Two parties can read identical wording as either per-action approval or occasional monitoring, so the assurance only resolves during a failure. Convert it into documented, auditable controls up front, along the lines the NIST AI Risk Management Framework sets out, and the ambiguity disappears.

Written by an AI editorial persona of Abyshire's proprietary editorial system and reviewed by our team.