Every organisation that uses a hosted model has signed something: click-through terms, an enterprise agreement, a data processing addendum, an acceptable use policy. Every organisation that sells an AI feature has promised something in return to its own customers. Those documents decide whether prompts can be used for training, how long they are kept, where they are processed, who owns the outputs, what uses are forbidden and what happens when a model is retired. Yet in most teams the documents live with procurement while the code that sends data lives with engineering, and nobody checks that the two agree.
This article treats AI use agreements as a source of runtime requirements. It catalogues the clauses that matter to engineers, shows how to turn them into an obligations register and gateway configuration, explains how to check that your promises to customers never exceed your vendors' promises to you, and works through a realistic example. The internal side, rules for what employees may do with AI tools, is covered in the companion piece on employee AI usage policies. This is engineering guidance, not legal advice; vendor terms change often, so read the current version of each document you rely on.
What an AI use agreement actually is
An "AI use agreement" is rarely one document. For a single vendor relationship you will typically find a master or enterprise agreement, a data processing addendum covering personal data, service-specific terms for the AI products, an acceptable use or usage policy listing prohibited uses, and an order form that sets volumes, regions and prices. Documents usually state an order of precedence for conflicts; find it, because a generous sentence in a marketing page or FAQ rarely binds anyone.
Consumer and business tiers of the same product can carry very different terms, particularly on whether inputs may be used to improve models. A team member who signs up with a personal email and a company card may accept consumer terms that the enterprise agreement was negotiated to avoid. Your agreement inventory therefore has to be tied to actual accounts and API keys, not to vendor names.
On the other side, your customer agreements may contain an AI addendum: commitments about training use, sub-processors, data location, human review, output ownership and disclosure. Each of those commitments depends on what your vendors permit, which is why the two sides must be managed together.
The clauses that matter to engineers
Read for these clauses. Each row lists the engineering question it answers.
| Clause | Engineering question | Typical runtime control |
|---|---|---|
| Use of inputs and outputs for training | May the vendor learn from what we send? | Only route data classes to vendors whose terms exclude training |
| Retention and deletion | How long do prompts and outputs persist, and can we delete them? | Per-vendor retention flag; deletion job on contract end |
| Abuse monitoring and human review | Can vendor staff read our prompts? | Keep restricted data away from endpoints with review rights |
| Sub-processors and locations | Who else touches the data, and where? | Region pinning; alert on sub-processor list changes |
| Acceptable use and prohibited uses | Is our use case allowed at all? | Use-case registry checked at feature launch |
| Output ownership and IP indemnity | Who owns results, and who defends claims? | Record which features rely on indemnified services |
| Model changes and deprecation | How much notice before behaviour changes? | Pin model versions; calendar retirement dates |
| Security and breach notification | When will we hear about an incident? | Map notice windows into incident runbooks |
| Rate limits and service levels | What can we promise downstream? | Capacity plans and customer SLAs derived from vendor SLAs |
Do not paraphrase the numbers from memory or from a blog post. Retention periods, notice windows and regional availability differ by product, tier and date, and vendors revise them. Copy each value from the governing document into the register, with the document version and the date you read it.
Architecture: from contract to runtime
The architecture mirrors how infrastructure teams handle compliance elsewhere. Clauses are captured as structured data in an obligations register, reviewed by legal and owned by engineering. A policy compiler turns the register into configuration for the AI gateway that fronts every model call. An inheritance check runs in CI and fails when a customer-facing promise is not backed by every vendor that might process that customer's data. A change watch tracks vendor notices, policy page revisions and model retirement dates, and opens tickets when something moves. The gateway writes an evidence store entry for each decision, which is what you show an auditor or a customer who asks how their data was handled; the article on audit logging for LLM systems covers its design.
An obligations register and inheritance check
A register entry is small. The values below are illustrative contract terms for a fictional vendor, not a description of any real provider.
vendors:
vendor_a:
agreement: "Enterprise AI terms v2026-07 + DPA v4"
read_on: 2026-09-14
endpoints: [vendor_a.eu]
trains_on_inputs: false
retention_days: 30
human_review: abuse_only
regions: [eu]
prohibited_uses: [biometric_id, credit_decision]
model_notice_days: 90
vendor_b:
agreement: "Click-through API terms (unreviewed)"
read_on: 2026-08-02
endpoints: [vendor_b.global]
trains_on_inputs: unknown
retention_days: unknown
human_review: unknown
regions: [us, eu]
customers:
acme_gmbh:
addendum: "AI addendum v3"
data_classes: [support_tickets]
promises: {no_training: true, max_retention_days: 30, regions: [eu], human_review: none_without_consent}Unknown is a legitimate value and an important one. An unreviewed vendor must be treated as the worst case for every attribute until someone reads the terms. The compiler then derives gateway rules, and the inheritance check confirms that each customer's promises are satisfied by every vendor the router could choose for that customer.
def satisfies(vendor: dict, promise: dict) -> list:
gaps = []
if promise.get("no_training") and vendor.get("trains_on_inputs") is not False:
gaps.append("training not excluded")
r = vendor.get("retention_days")
if not isinstance(r, int) or r > promise.get("max_retention_days", 10**9):
gaps.append(f"retention {r} exceeds promise")
if not set(vendor.get("regions", [])) <= set(promise.get("regions", vendor.get("regions", []))):
gaps.append("processing outside promised regions")
if promise.get("human_review") == "none_without_consent" and vendor.get("human_review") != "none":
gaps.append("vendor staff may review content")
return gaps
def eligible_vendors(customer, register):
promise = register["customers"][customer]["promises"]
return {name: satisfies(v, promise) for name, v in register["vendors"].items()}Run eligible_vendors in CI for every customer and fail the build if the router's configured candidates include a vendor with gaps. At request time the gateway only needs a lookup: customer to allowed endpoints, which the compiler has already computed.
Worked example: summarisation for an EU customer
A business software company adds ticket summarisation for its support product. Two vendors are configured: vendor A under a negotiated enterprise agreement, and vendor B, which a developer used during prototyping under click-through terms. A German customer's addendum promises no training on their data, retention of at most 30 days, processing in the EU, and no human review without consent.
The inheritance check reports two findings for that customer. Vendor A satisfies training, retention and region, but its terms allow vendor staff to review content flagged for abuse; the promise says none without consent. Vendor B has unknown values for training, retention and review and processes in the US. The build fails before launch.
The team has three options, each with a cost. It can remove vendor B from this customer's route, accepting lower availability when vendor A is down. It can ask vendor A whether an abuse-review exemption is available for its account, which may take weeks and may not be offered. Or it can amend its own addendum to disclose abuse-only review and seek the customer's consent. It chooses the first immediately and starts the second and third in parallel. When the vendor later issues a notice updating its sub-processor list, the change watch opens a ticket, the register is updated, and the inheritance check reruns: the product's guarantees track the contracts, rather than whatever was true on launch day.
Flowing usage restrictions down to your users
Vendor acceptable use policies do not stop at your boundary. If your provider forbids a category of use, such as generating content for political campaigns or making automated decisions about people without human oversight, you are usually responsible for making sure your own users do not do it through your product. That has two parts: the words in your customer terms, and the mechanisms in your product that make those words true.
Start with a use-case registry. Every AI feature gets an entry describing its purpose, the data it touches, the users it serves and the vendors it may call. At launch review, compare the purpose with each vendor's prohibited-use list in the register; a match blocks launch until the feature is redesigned or the route changes. For open-ended features, such as a general assistant or an API you resell, copy the relevant restrictions into your own terms, apply content classifiers at the gateway for the categories you can detect, and keep a documented process for suspending accounts that violate them.
Record which vendor policy version each restriction came from. When a vendor relaxes or tightens its policy, the register shows which features and which customer terms are affected, so the change is a reviewed edit rather than a scramble after a warning email.
Keeping agreements current
Agreements are not static. Vendors revise usage policies, add sub-processors, retire models and change data handling defaults, typically with notice by email or a changelog page. Give the register an owner, subscribe a shared mailbox to vendor notices, and treat each notice as a change request with a due date. Pin explicit model versions in configuration so that a vendor's retirement schedule appears as a dated task rather than a silent behaviour change in production.
Contract end deserves its own runbook: revoke keys, request or confirm deletion according to the agreement, export any fine-tuned artifacts you own, and record completion. Evidence from this step matters most when a customer asks, years later, where their data went.
Failure modes
- Shadow accounts. A prototype on a personal or click-through account quietly becomes production and the enterprise terms never apply to it.
- Promising more than you receive. Sales accepts a zero-retention clause that no configured vendor offers, and the gap is discovered in an audit.
- Fallback routing that ignores terms. A failover path sends traffic to any healthy model, including one outside the customer's region.
- Stale registers. Values copied once and never re-read drift from the current policy pages.
- Prohibited uses discovered late. A feature launches into a use the vendor's acceptable use policy forbids, such as an automated decision about individuals, and must be withdrawn.
- No evidence. The configuration was correct but nothing proves it; logs record prompts but not which agreement version governed each call.
Trade-offs
| Choice | Gain | Cost |
|---|---|---|
| Negotiated enterprise terms | Fit to your promises, named contacts | Time, minimum spend, lock-in |
| Click-through terms | Immediate access | Little leverage, terms change unilaterally |
| Single vendor per customer class | Simple inheritance, clear evidence | Lower resilience |
| Multi-vendor routing | Availability and price leverage | Every vendor must meet every promise |
| Narrow customer promises | Easy to honour | Harder sales conversations |
| Self-hosted models | Terms you control | Operations, capacity and model-quality burden |
The organisational trade-off matters as much as the technical one. Centralising the register in a governance team, as described in building an AI governance programme, gives consistency; leaving it with each product team keeps it close to the code. Most organisations do best with a central schema and distributed owners.
What to do next
- List every AI vendor account and API key in use, including prototypes and personal accounts.
- For each, record the governing documents, their versions and the date read.
- Fill an obligations register with training, retention, review, region, prohibited-use and notice values, using unknown where you have not checked.
- Route all model traffic through one gateway that reads compiled configuration from the register.
- Add the inheritance check to CI for every customer with an AI addendum.
- Pin model versions and calendar every announced retirement date.
- Log the agreement version alongside each gateway decision, then rehearse a customer evidence request.
- Write the contract-end runbook and test it on a vendor you no longer use. For data lineage behind these checks, see data governance for AI.