AI Supplier Contracts and Exit Conditions

A fictional regional property insurer finished a pilot of an assistant that summarizes claim files for adjusters. The pilot met its acceptance thresholds, and the business owner wants production by the end of the quarter. Procurement then received the model supplier’s standard agreement: 36 months, a commitment of \$120,000 a year, a data processing addendum incorporated by reference to a web page, and model availability “as described in the documentation.” Legal asked what to negotiate. Engineering said switching would be easy because the integration is one API call. Finance asked what happens to the commitment if volume falls short. The insurer, its volumes, and every price in this article are invented for illustration.

Each of those questions was reasonable, and the pilot report answered none of them. A pilot shows that a model can do the task at an acceptable quality on the day it was tested. The agreement decides how long that model will exist, what the supplier may do with the claim files, what happens when the service is down, and what it costs to leave. This article takes the standard agreement apart along those lines and prices the consequences with numbers the insurer can recompute.

Build and buy are decisions about layers

An AI feature is a stack of layers, and “build or buy” has a different answer for each. The workflow and application sit on top: how a claim file reaches the assistant and what the adjuster does with the summary. Below that are the prompts, retrieval, tool definitions, and the evaluation set that decides whether a change is an improvement. Below those is the model, and beneath the model is the compute that serves it. The general discipline for combining build, buy, keep, replace, and stop into complete strategies is covered in Five Verbs and One Question. The AI-specific point is which layers carry the insurer’s advantage and which can be rented.

The insurer’s advantage is in the top two layers: its claims knowledge, the adjuster-reviewed examples that make up its evaluation set, and the workflow integration. Those are also the layers that make leaving expensive if the supplier owns them. General language capability is the layer that several suppliers sell and that changes every year, so renting it is reasonable. The practical rule is to buy the model and build, or at least own, everything that would have to be reconstructed if the model changed. A gateway that every model call passes through, as described in Every Team Had Its Own Key, keeps provider credentials, quotas, and model identifiers in one place, so that changing a supplier is a configuration and testing task rather than a rewrite.

“Buy” also has several forms with different counterparties. The insurer can contract with the model developer directly, contract with a cloud provider that hosts models from several developers, or run an open-weight model on its own capacity. The cloud route may fit existing procurement, security review, and committed-spend arrangements, but it adds a lifecycle that belongs to the host rather than the developer. Anthropic’s documentation says that dates on its own page apply to platforms it operates, while Amazon Bedrock and Google Cloud set their own retirement schedules for the same model. The contract that matters is the one that governs the endpoint the application calls.

Self-hosting an open-weight model is the way to hold the weights and decide when to change them. Its cost is mostly people. Suppose the claims workload is 250,000 claim packets a month, each with 12,000 input tokens and 1,000 output tokens. At hypothetical hosted prices of \$3 per million input tokens and \$15 per million output tokens, one packet costs 12,000 × \$3 / 1,000,000 + 1,000 × \$15 / 1,000,000 = \$0.036 + \$0.015 = \$0.051, so the month costs 250,000 × \$0.051 = \$12,750. Now assume self-hosting needs \$9,000 a month of GPU capacity plus one and a half engineers at a hypothetical \$15,000 a month each in loaded cost, or \$31,500 a month in total. The break-even volume is \$31,500 / \$0.051, about 617,600 packets a month, roughly 2.5 times the base case. That figure also assumes that an open model matches the hosted model’s quality on the insurer’s evaluation set and that the capacity can absorb peaks. Below that volume, self-hosting buys control at a price the volume does not repay; it can still be justified by a data-handling requirement that no supplier can meet.

Fine-tuning sits between the two. On a hosted service, a tuned model remains hosted by the supplier and its life is tied to its base model. Microsoft’s lifecycle documentation, for example, lists separate training and deployment retirement dates for fine-tuned models, with training retiring no earlier than the base model. Unless the contract provides otherwise, what the insurer can take elsewhere is its training data, not the tuned model. Treat fine-tuning as a purchase of dependence and price it that way.

What the supplier does with the claim files

Data terms answer four separate questions, and a clause that answers one of them says nothing about the others. The first is whether prompts and outputs are used to train the supplier’s models. OpenAI states that data sent to its API is not used to train or improve its models unless the customer opts in, Anthropic states that by default it does not train on inputs or outputs from its commercial products, with exceptions for feedback a customer submits and for opt-in, and Microsoft states that prompts, completions, embeddings, and training data in its Azure-sold models are not used to train foundation models without the customer’s permission or instruction. A contract should repeat the commitment that applies to the endpoint in use, including what counts as opt-in, rather than rely on a web page that can change.

The second question is retention, which is separate from training. OpenAI’s documentation says abuse-monitoring logs, which contain prompts, responses, and derived metadata, are kept for up to 30 days by default unless longer retention is required by law or reasonably necessary to protect its services. Microsoft describes an abuse-monitoring store in which a flagged sample of prompts and completions can be reviewed by authorized staff, and a process for approved customers to modify abuse monitoring so that this storage and human review do not occur. Zero data retention arrangements exist for eligible customers, but coverage depends on the endpoint and feature. OpenAI states that its fine-tuning endpoints store application state until deleted and are not eligible. Features such as stored conversations, uploaded files, and vector stores create copies with their own retention rules. The insurer should therefore list every feature it will use and ask for the retention of each, instead of asking for “zero retention” in general.

The third question is where processing happens. Microsoft’s documentation separates where data is stored at rest, which stays in the designated geography, from where a request is processed, which can be anywhere the model is deployed for a Global deployment type or anywhere within a defined zone for a DataZone type. OpenAI documents regional data residency with approval requirements for abuse-monitoring controls outside the United States and a 10 percent price uplift for regional storage on eligible newer models. For a claims workload with personal data, data residency must be read as storage, processing, and access, and the price of the compliant deployment type belongs in the cost model, because it changes the unit price used above.

The fourth question is who else touches the data and what happens at the end. When a supplier processes personal data on the insurer’s behalf, the UK Information Commissioner’s guidance lists terms such as processing only on documented instructions, prior authorization of sub-processors with notice of changes and a chance to object, assistance with data subject requests and breach handling, audit rights, and deletion or return of all personal data when the contract ends unless the law requires storage. Those are UK GDPR terms, and the insurer’s own jurisdiction determines which regime applies, but the structure is useful anywhere: the sub-processor list, the deletion deadline, and the return format are contract terms, and they are easiest to obtain before signature.

One principle ties these together. Product documentation describes the service today, and the supplier can revise it. Microsoft’s own data-privacy page points to its data protection addendum as the governing document. The commitments the insurer relies on should appear in the signed agreement or in documents it incorporates, together with a duty to notify the insurer before a change that weakens them and a right to terminate if the change is material.

When the model changes under you

Hosted models are retired on the supplier’s schedule. That is the largest difference between buying a model and buying a conventional software license, and it makes the lifecycle terms some of the most valuable in the agreement. The published policies show how much they vary. OpenAI states minimum notice before shutdown of at least six months for generally available models, at least three months for specialized variants, and as little as two weeks for preview models, and it reserves the right to move faster for safety or compliance reasons. Anthropic states at least 60 days’ notice for publicly released models on its own platforms. Microsoft’s Foundry documentation describes an 18-month life for generally available models, 12 months for generally available models from several partner developers including Anthropic, and at least 60 days’ notice before retirement. It also states that retirement dates are not extendable, that Standard deployments may be upgraded automatically to a replacement unless the customer chooses otherwise, that provisioned deployments are not, and that it can invoke an emergency retirement with shortened notice for security or compliance reasons.

Those policies describe the supplier’s practice, and the contract determines what the insurer can rely on. The question to answer first is how long the insurer needs. Assume its migration plan takes 14 weeks: six weeks of prompt and schema rework, four weeks to refresh and rescore the evaluation set, three weeks of shadow running against production traffic, and one week of staged rollout. Fourteen weeks is 98 days. Against a 60-day notice period the insurer is 38 days short. Against six months, about 182 days, it has roughly 12 weeks of slack. Azure’s practice of naming the official replacement only 90 to 120 days before retirement leaves a window that can be shorter than the insurer’s 98 days, so the insurer cannot wait for the announcement to start testing; it has to evaluate candidate models on its own schedule. A pinned model version prevents the unintended change an alias would cause, but it does not remove the end date.

The terms to negotiate follow from that arithmetic. Notice should be at least as long as the insurer’s measured migration time plus a margin, and a contract can ask for a longer period than a public policy promises. The supplier should not change the behavior of a version the insurer has pinned without notice, and should give access to the replacement for testing before the cutover. The price and rate limits of the successor should be stated or capped, because a commitment priced against one model does not protect the insurer if the replacement costs more per token. A material removal, such as a retirement without a comparable replacement, should give the insurer a right to end the commitment without penalty. The insurer should also agree internally who tracks the retirement calendar, since a notice sent to the subscription owner’s email does not help if that person has left.

These forced migrations are a recurring cost, not an exception. Over a 36-month term, a model chosen at the start should be planned to be replaced at least once, and possibly twice. The exit analysis below prices a migration at \$77,500 under hypothetical labor rates, so two of them cost \$155,000, which belongs in the total cost of ownership next to the token bill. The general method for that model is in The Case Said Four Million and the Cost Was Nine.

What a service level promises, and what it leaves out

A service level agreement attaches consequences to a measured commitment, and for AI services the measured commitment is availability. The Amazon Bedrock SLA is a public example. It states a 99.9 percent monthly uptime commitment, credits of 10 percent for uptime from 99.0 to 99.9 percent, 25 percent from 95.0 to 99.0 percent, and 100 percent below 95.0 percent, a long list of exclusions including factors outside AWS’s reasonable control and customer actions, and a requirement that the credit request arrive by the end of the second billing cycle after the incident. Other suppliers define unavailability, exclusions, and claims differently, so the insurer must read each definition.

Turn those percentages into time. A 30-day month has 43,200 minutes. A 99.9 percent commitment allows 43.2 minutes of downtime, 99.0 percent allows 432 minutes, and 95.0 percent allows 2,160 minutes, or 36 hours. Suppose an eight-hour outage, 480 minutes, hits the insurer’s endpoint in the base-case month. Availability for the month is 1 − 480 / 43,200 = 98.9 percent, which falls in the 25 percent tier. On a \$12,750 monthly bill the credit is \$3,187.50. If 60 adjusters wait for those eight hours at a hypothetical \$45 an hour, the idle time alone is 60 × 8 × \$45 = \$21,600. The credit is a price adjustment, not compensation for the disruption, and the insurer’s availability plan has to come from architecture: a tested fallback model, a queue that holds claim files, and a manual procedure for adjusters.

Three gaps in typical AI service levels deserve attention. First, availability is not capacity. OpenAI’s rate-limit documentation says limits apply at the organization and project level, vary by model, and are enforced by 429 errors, and it points enterprise customers with persistent ramp-rate problems to its Scale Tier and Reserved Tier for more predictable capacity. A service can be available and still reject the insurer’s month-end batch. If throughput matters, the contract needs a capacity commitment, with its own price, rather than an uptime percentage. Second, nothing in an availability commitment covers quality. A silent change in output length, refusals, or formatting can break the workflow while the SLA reports 100 percent. The insurer’s own evaluation set, run on a schedule, is the quality measure, and the contract can require notice of model or safety-layer changes that affect behavior. Third, support is a separate promise: severity definitions, hours, response and restoration targets, and an escalation path with named contacts. The Supplier Changed Its Roadmap and Ours Changed With It covers how to read severity rules and credits in more detail.

The commitment itself deserves a stress test, since it converts a usage forecast into a fixed obligation. The table assumes the \$120,000 annual commitment, uses the per-packet price from earlier, and assumes usage above the commitment is billed at the same list prices.

Scenario	Packets per month	Usage at list, per year	Paid under the commitment	Difference from usage
Low	100,000	\$61,200	\$120,000	\$58,800 paid for unused capacity
Base	250,000	\$153,000	\$153,000	\$33,000 above the commitment
High	400,000	\$244,800	\$244,800	\$124,800 above the commitment

The commitment protects the insurer’s discount in two of the three cases and costs \$58,800 a year in the low case, which is 49 percent of the commitment. A commitment sized at 70 percent of the base forecast would be \$107,100 a year and would leave \$45,900 unused in the low case, so the sizing question is how much of the forecast the pilot evidence supports. Terms that change the exposure include reducing the commitment at each anniversary, carrying unused amounts forward, applying the commitment across products and successor models, and the treatment of pricing if the model changes. A quantity that can rise but not fall, as true-up terms often work in licensing, is the pattern to avoid.

Who is responsible for which part of the agreement

The UK government’s AI Playbook tells public bodies to work with commercial colleagues from the start, and it names intellectual property rights, acceptable liability, and the same expectations for responsible use of procured and in-house systems as topics for the contract. The point carries beyond government: an AI agreement combines technical, legal, and commercial risks, and no one function holds all of them. The division that works treats each term as a question with an accountable owner.

Procurement runs the process: comparable quotes, the commitment structure, renewal and price terms, and the commercial alternatives. Legal owns liability, indemnity, termination rights, and how the documents referenced by the agreement are fixed in time. The privacy and security functions own the data-protection addendum, sub-processors, security evidence, and the assessment of where data goes. Engineering supplies the evidence that makes the others’ positions concrete: the migration time, the volume forecast, the evaluation results, and a tested export or replacement. The business owner decides which service failures and which residual dependence the business can accept, and finance owns the commitment and the budget line. A job title does not by itself grant any of these approvals, and the agreement should not be signed until each owner has seen the clauses in their area.

Intellectual property indemnities are a good example of a term where the headline hides conditions. Google Cloud describes two indemnities, one for claims that its use of training data infringes third-party rights and one for claims about generated output from listed products, and says neither covers a customer who deliberately tries to infringe or ignores responsible-use practices. Microsoft’s Customer Copyright Commitment requires the customer to have implemented documented mitigations for the covered Azure OpenAI offerings, including a copyright-protection instruction in the system message, an evaluation report retained by the customer, and, depending on the use case, content filters configured in specified modes. Anthropic says it will defend commercial customers against copyright claims arising from authorized use of its services or their outputs, including through Amazon Bedrock. These commitments differ in scope and conditions, and all of them address intellectual property claims. None of them makes the supplier answerable for a wrong claim summary that leads to a wrong payment, which falls under the limitation-of-liability clause. The insurer’s legal team should read the cap and the exclusions together with the indemnity, and engineering should know which mitigations the indemnity requires, because a lapse can void it.

Regulation adds a question of roles. The EU AI Act assigns obligations by activity, as The Invoice Gave the Instructions explains. Article 25 says that a deployer or other party becomes the provider of a high-risk system if it rebrands one, substantially modifies one, or changes the intended purpose of a general-purpose system so that it becomes high-risk, and it requires written agreements between providers of high-risk systems and the third parties that supply components or services. Whether the insurer’s summarization tool falls into a high-risk category is a classification question for legal counsel. The contract consequence is that the supplier should commit to providing the documentation, information about limitations, and technical access that a downstream party would need to meet its own obligations. The EU’s Community of Practice on public procurement of AI publishes non-binding model contractual clauses organized around AI Act requirements for high-risk and other systems, which can serve as a checklist even for a private buyer.

What leaving costs, and what makes it cost that

Engineering’s claim that switching is one API call refers to the cheapest part. Exit cost includes moving data, rewriting logic, rebuilding operations, running two systems, contract obligations, and people, and for an AI service each has a specific form. Prompts and schemas are tuned to one model’s habits, so they need rework. The evaluation set can move, but its results must be rescored on the new model, and adjusters must review disagreements. Embeddings are specific to the embedding model, so a retrieval index built on one supplier’s embeddings must be rebuilt for another. Stored threads, files, and vector stores created through supplier-specific features have to be exported or recreated. Guardrail settings, monitoring, and quotas are configured in each supplier’s console.

Here is the arithmetic for the insurer, at a hypothetical \$4,000 per engineer-week. Engineer-weeks measure effort, while the 14-week plan above measures calendar time, and the week of staged rollout is absorbed in the integration line. Re-embedding 2 million documents of 1,500 tokens each is 3.0 billion tokens, which at a hypothetical \$0.10 per million tokens costs \$300, so the compute is trivial and the validation is not. Shadow running means paying for two models for a while; two months of the base-case bill is 2 × \$12,750 = \$25,500.

Cost item	Basis	Cost	Also needed for a forced migration within the same supplier
Prompt and schema rework	6 engineer-weeks × \$4,000	\$24,000	Yes
Evaluation refresh and rescoring	4 engineer-weeks × \$4,000	\$16,000	Yes
Shadow run	3 engineer-weeks × \$4,000 = \$12,000, plus 2 × \$12,750 = \$25,500 of duplicate usage	\$37,500	Yes
Integration, authentication, monitoring	3 engineer-weeks × \$4,000	\$12,000	No
Security, privacy, and legal review of the new supplier	2 engineer-weeks × \$4,000	\$8,000	No
Re-embedding the retrieval index	3.0 billion tokens at \$0.10 per million	\$300	No
Total to change supplier		\$97,800
Forced migration to a new model at the same supplier	First three rows	\$77,500

Two conclusions follow. The first is that most of the technical work of leaving is work the insurer must do anyway when a model is retired: changing supplier adds \$12,000 + \$8,000 + \$300 = \$20,300 to a migration it cannot avoid. That is a reason to invest in the evaluation set and the gateway, because they lower both costs. The second is that the technical total is small beside the contractual one. If the insurer needed to leave at the end of month 12, 24 months of the \$10,000 monthly commitment, or \$240,000, would remain. That is about 11.8 times the \$20,300 incremental cost of switching, and 2.5 times the entire \$97,800 technical cost. When the exit cost is dominated by what the contract obliges the insurer to pay, negotiating the contract is the main way of controlling it. Technical lock-in still matters, since dependence on architecture, features, data, and skills can persist under a flexible contract, but the numbers show where a leader’s attention buys the most.

The exit terms follow from this. The insurer wants a right to terminate or reduce the commitment on material change, such as a retirement without a comparable replacement, a weakening of data terms, or a price increase above a stated cap. It wants a term short enough, or a break clause early enough, that the remaining obligation at any decision point is bounded. Return of its data should be specified in format and timing, followed by verified deletion on a stated deadline. Transition assistance should cover a stated period during which the old service keeps running at agreed prices. The portability and exit plan should be tested before signature at the scope that matters: export a sample of prompts, evaluation results, logs, and stored files, and confirm the destination can use them. A successful sample is evidence for that sample, not for the whole service.

Leverage in the negotiation comes from the same preparation. A costed alternative, a measured migration time, and usage evidence make a request for shorter notice, a lower commitment, or a successor-price cap concrete. A supplier may or may not agree, and a credible alternative improves the insurer’s position without guaranteeing concessions. If a requested term is refused, the cost model should carry the consequence, such as the stranded commitment, so the business owner accepts it knowingly.

The agreement the insurer signed

In this fictional outcome, the insurer first sized the commitment to the pilot evidence and a conservative forecast instead of the base case, and negotiated an anniversary right to adjust it by up to 25 percent in either direction. It obtained 12 months’ notice of retirement for the pinned model, access to the successor for testing at least 90 days before cutover, and a cap on the successor’s per-token prices for the remainder of the term. The agreement incorporated the data protection addendum as signed, listed sub-processors with 30 days’ notice of changes, and named the endpoints and features covered by the retention and training commitments. It also added a right to terminate without penalty if the supplier weakened those commitments or retired the model without a comparable replacement. Support terms treated a blocked claims workflow as a high-severity incident, and the supplier agreed to a named technical contact. The legal team recorded the indemnity conditions as engineering requirements, and engineering added the corresponding evaluation report to its release checklist.

The supplier declined a capacity commitment on the standard tier, so the insurer’s month-end batch is queued with retries under its gateway’s limits, and the business owner accepted that trade-off in writing. Quarterly, the insurer runs the evaluation set against its pinned model and one alternative, so the migration time and the exit estimate in this article stay current. The agreement does not eliminate dependence on the supplier. It converts the dependence into terms the insurer has priced, assigned to owners, and rehearsed.

References:

• OpenAI, Deprecations
• OpenAI, Data controls in the OpenAI platform
• OpenAI, Rate limits
• Anthropic, Model deprecations
• Anthropic Privacy Center, Is my data used for model training?
• Anthropic, Expanded legal protections and improvements to our API
• Microsoft Learn, Foundry Models lifecycle and support policy
• Microsoft Learn, Data, privacy, and security for Foundry Models sold by Azure
• Microsoft Learn, Customer Copyright Commitment required mitigations
• Google Cloud, How Google Cloud is protecting customers with generative AI indemnification
• Amazon Web Services, Amazon Bedrock Service Level Agreement
• ICO, What needs to be included in the contract (controller and processor)
• EU Artificial Intelligence Act, Article 25: Responsibilities along the AI value chain
• Covington, EU’s Community of Practice publishes updated AI model contractual clauses
• GOV.UK, Artificial Intelligence Playbook for the UK Government (OGL v3.0)