You are signing three documents, and you negotiated one of them.
Every AI agreement a mid-market operator signs is really a stack of three. There is the one in front of you, the vendor's own master agreement or order form. Underneath it sits the model provider's terms, which govern the component doing the actual work and which your vendor accepted on your behalf before you were in the room. And wrapped around both are the obligations you already carry to your own clients, the engagement letters, confidentiality terms, carrier requirements and professional duties that follow your records into whatever system you point at them.
The buyer negotiates the first document. The second is usually invisible. The third is the one nobody thinks to read against the other two. That is not a criticism of buyers; it is a description of how the paperwork arrives, as one document, at the end of a sales process, at the point where everybody wants to start.
The practical consequence is that the questions worth an argument are not the general ones about limitation of liability and governing law, which competent counsel handles on any software contract. They are the specific ones that exist only because this purchase has a model in it, is built partly out of your own material, and runs on infrastructure your vendor does not control either. Five of those are worth the hour. This piece is about those five, written for the operator deciding what to push on and what to let go. It is general information rather than legal advice; the version that binds anyone is the one your counsel writes against your actual document.
Two adjacent pieces cover ground this one deliberately does not. The ownership argument, meaning why a code handoff is worth paying for at all and what a real one contains, is settled elsewhere and assumed here. So is the security and data diligence that produces the subprocessor list and the deletion scope. This piece starts after both of those conversations have happened and the document is on the table.
Ownership has to name the artifacts, because the code is the cheap part.
The standard ownership clause in a custom build says the vendor assigns to the customer all right, title and interest in the deliverables, with deliverables defined somewhere earlier as the software developed under the statement of work. On a conventional software project that sentence does its job. On an AI build it covers perhaps a third of what you paid for.
The rest of the system is a set of artifacts that are not obviously software and are almost never listed. The prompts and system instructions, which after weeks of iteration encode most of what the vendor learned about your business. Any fine-tuned weights or adapters trained on your material. The embeddings and the vector index built from your documents, which are a derived representation of your corpus and expensive to regenerate at scale. The evaluation set, which is quietly the most valuable artifact in the whole engagement, because it is the labelled record of what your people said good output looks like and it is the thing that lets a successor prove a replacement works. The retrieval configuration, the routing logic, the guardrail definitions, and the golden examples your staff curated by hand.
None of that is source code, and a clause assigning the software can leave every one of those items in the vendor's hands without anybody acting in bad faith. The fix is not clever drafting. It is a list. Name the artifacts in the deliverables definition, in the words a technical person would use, and require them at handoff in a format someone else can load. A vendor who intends to hand things over will agree to the list in an afternoon. A vendor who does not will negotiate the list, and that negotiation is the information you were trying to get.
There is a second-order point worth understanding before you spend leverage on the wrong sentence. An assignment clause transfers whatever rights the vendor holds. It does not manufacture rights that do not exist. The Copyright Office's January 2025 report on copyrightability concludes that copyright does not extend to purely AI-generated material, or material where there is insufficient human control over the expressive elements, and that based on the functioning of current generally available technology, prompts do not alone provide sufficient control. The same report is careful about the other half: copyright protects the original expression in a work created by a human author even if the work also includes AI-generated material, and using AI tools to assist rather than to stand in for human creativity does not affect protection. The D.C. Circuit reached the narrower question in March 2025 in Thaler v. Perlmutter, affirming that a machine cannot be the recognized author because the Copyright Act of 1976 requires all eligible work to be authored in the first instance by a human being.
The operational read is simple even though the law around it is not. A clause reading that the vendor assigns all intellectual property in the outputs may be an assignment of very little, because there may be nothing there to assign. What protects you is not the assignment. It is possession of the artifacts, a licence broad enough to use, modify and sublicense them, and the absence of any reciprocal licence running back to the vendor over your material. Secure those three and the copyright question stops touching your operations, whichever way it settles.
The related trap is the account layer, and it is the cheapest thing in this category to fix at the start. Whose name sits on the model provider account, the cloud subscription, the vector database, the observability tool. A buyer can own every artifact on the list and still be unable to run the system, because the credentials that make it work belong to somebody else. The handoff piece describes what that looks like a year later.
The training sentence, and the two places it hides.
Buyers ask whether their data will be used to train the model, get told no, and stop. The answer is usually true and usually incomplete, for two reasons.
The first is tier. Model providers commonly apply different terms to the consumer product and to the API or business product carrying the same brand name, and the sentence a buyer reads on a marketing page is often the one governing the tier they are not buying. The question is not what the vendor's policy is. It is which agreement governs the specific deployment you are paying for, followed by a request for that document.
The second is direction. Training on your inputs is the version everybody asks about. Retention of the outputs for abuse monitoring, quality review or evaluation is a separate permission, granted in a separate sentence. So is the vendor's own right to use your material to improve their product, which is a different party from the model provider and a different clause from the one you just read. On a commissioned build there is a third direction that exists only in bespoke work: whether the vendor may reuse what they learned building your system in the next client's system. That is a legitimate thing for a vendor to want and there are honest versions of it, but it belongs on the table rather than inside a definition of background intellectual property nobody reads.
None of these questions is answerable from marketing copy. They are answerable from the subprocessor list and the governing terms, which is why requesting both in writing before signing is the highest-yield hour of diligence in this category. We surveyed what published vendor terms across four verticals actually say about training and export in the renting versus owning analysis, and the distribution is wide: a few vendors commit to no training in plain language, several are silent, and at least one promises no training on a homepage while excluding subscriber content in the policy underneath.
The model has a retirement date, and your contract term is longer than it is.
This is the clause almost nobody writes, and it is the one most likely to cost a mid-market buyer real money inside the first agreement term.
A custom AI system is accepted against a specification, on a particular model, at a particular version. That model has a published end of life. The dates are not secret, they sit on the provider's own documentation, and they are shorter than most buyers assume.
OpenAI's deprecations page states minimum notice periods of at least six months for generally available models, at least three months for specialized variants of them, and as little as two weeks for preview models, with specific shutdown dates published per model. Anthropic's deprecation documentation states that it provides at least sixty days of notice before retirement for publicly released models and that requests to retired models will fail; its own published history records Claude Opus 4.1 deprecated on June 5, 2026 and retired on August 5, 2026, and the Claude Sonnet 4 and Opus 4 models deprecated on April 14, 2026 and retired on June 15, 2026. Microsoft Foundry sets a generally available model's retirement date programmatically at launch to eighteen months out, gives at least sixty days of notice, returns 410 Gone to every inference request after retirement, and answers the obvious question in its own frequently asked questions: retirement dates are not extendable.
Three details in that documentation matter more to a buyer than the headline numbers. The first is that the lifecycle is not uniform even within one platform. Microsoft's page states that generally available models from Anthropic, DeepSeek, Fireworks and Mistral AI follow a twelve-month lifecycle on Foundry rather than the standard eighteen. Anthropic's page states that partner-operated platforms including Amazon Bedrock and Google Cloud set their own retirement schedules, so a model's dates can differ from the ones published by the model's own maker. The date governing your system is the one for the platform your vendor actually deployed on, which is a question most buyers have never asked.
The second is that on some deployment types the model is changed underneath you automatically. Microsoft's documentation describes auto-upgrades on Global Standard, Data Zone Standard and Standard deployments, scheduled on a rolling region-by-region basis, while provisioned deployments are not auto-upgraded and must be migrated by hand. A deployment property controls this, and setting it to never auto-upgrade carries a consequence stated just as plainly: the deployment stops working at retirement. So the two available postures are that the component under your accepted system changes without your involvement, or that it stops. There is no third posture where it stays the same indefinitely, and the contract should stop implying there is.
The third is that preview models are a different animal. Microsoft's page states that preview deployments are force-upgraded with at least thirty days of notice and that there is no option to remain on a retiring preview model. If any part of the system a vendor demonstrated to you runs on a preview model, that is worth knowing before acceptance rather than after.
Put those together and the arithmetic is uncomfortable. A three-year agreement, or a one-year one signed at the wrong point in a model's life, can outlast the component the system was accepted on. When that happens somebody has to re-run the acceptance tests against the replacement, tune the prompts back toward the quality the old model produced, and absorb whatever regression shows up in between. That work is real, it is billable, and in most agreements it is unassigned, which in practice means the customer pays for it twice, once in fees and once in the weeks the system is worse than it was.
The clause itself is not complicated. Name the model and version in the specification rather than leaving it as an implementation detail. Require notice from the vendor within a set number of days of the provider announcing a retirement or a version change, including automatic upgrades the vendor did not choose. Require the vendor to re-run the agreed acceptance tests against the replacement, at their cost, inside the term, and to report the results. Say what happens if the replacement fails those tests, which is the sentence doing the real work. And say who owns the re-tuning effort, because that is where the invoice arrives. Vendors who build for a living agree to this readily, since it describes work they were going to do anyway. The ones who resist are usually resisting the measurement rather than the labour, which is its own answer.
The indemnity you are offered covers the risk you do not have.
Ask a vendor about AI risk and you will usually be pointed at an indemnity. The major model providers all publish one, they are real, and they are worth having. They also cover something narrower than most buyers hear.
OpenAI's Service Terms extend its indemnification obligations to API customers to cover any third party claim that the customer's use or distribution of Output infringes a third party's intellectual property right. Anthropic's Commercial Terms commit it to defend the customer against a third party claim that the customer's paid use of the Services or Outputs generated through that use violates a third-party intellectual property right. Microsoft's Customer Copyright Commitment, announced in September 2023, says that if a third party sues a commercial customer for copyright infringement for using its Copilots or the output they generate, Microsoft will defend the customer and pay the amount of any adverse judgments or settlements. Google's Service Specific Terms extend its indemnification obligations to allegations that an unmodified Generated Output from a Generative AI Indemnified Service infringes a third party's intellectual property rights.
Read the common noun in all four. Every one of them is an intellectual property indemnity, answering the case where somebody else claims the output infringed their rights. That is a genuine exposure and it is good that it is covered. It is not the exposure that keeps a mid-market operator awake, which is that the system produced something wrong, a person relied on it, and a client or a regulator is now asking about it. No indemnity in this list addresses that, and a buyer who negotiates hard for an AI indemnity and then relaxes has protected the rarer of their two risks.
The exclusions matter more than the grant, and they share a shape worth knowing. OpenAI's list excludes output the customer knew or should have known was infringing, cases where the customer disabled, ignored or did not use relevant citation, filtering or safety features, output that was modified, transformed, or used in combination with products or services not provided by or on behalf of OpenAI, cases where the customer lacked the right to use the Input or fine-tuning files, trademark claims arising from use of Output in trade or commerce, and output derived from a Third Party Offering. Anthropic's exclusions run parallel, covering customer modifications, combination with non-Anthropic technology or content, claims arising from Inputs, knowledge that the use infringed, the practice of a patented invention in an Output, and trademark claims from commercial use.
Now hold that against how a commissioned system is actually built. The output is post-processed. It is combined with retrieval over your own corpus, routed through business logic, and written into another product. A custom system is very close to a literal description of output used in combination with products or services not provided by the model provider. Whether the indemnity still reaches the architecture you bought is a real question with a real answer, and it belongs to whoever designed the system. Ask it before you rely on the protection rather than afterwards.
Two of the four carry conditions that land on the buyer rather than on the vendor. Microsoft's commitment requires customers to use the content filters and other safety systems built into the product and not to attempt to generate infringing material; for Azure OpenAI and configurable services its documentation states the customer must also have implemented all the mitigations the documentation requires, a list that includes a metaprompt directing the model away from infringement, red team testing with a retained report, and use-case-specific content filters. That is an evidence obligation. Somebody has to be able to produce the report on the day a claim is tendered, and on a mid-market engagement that somebody is usually nobody. Google's version applies to services on a published list and only where the service is not provided free of charge, so a team that prototyped on a free tier and never migrated the account is outside it.
Then the question that decides whether any of this reaches you at all. These indemnities run from the provider to the provider's customer. If your vendor holds the model provider account, which is the common arrangement, the indemnified party is your vendor and not you. So the clause to look for in your own agreement is a pass-through: does the vendor extend equivalent protection to you, in what amount, and does their own limitation of liability swallow it. An indemnity capped at fees paid, on a fixed-fee build, is a promise to refund your money in a situation where refunding your money is not the problem.
The wrong-output risk lives somewhere else in the document, and it is worth putting it there deliberately. A warranty that the system will perform materially in accordance with the specification, tied to the acceptance criteria rather than to a general standard of workmanship. A named human review obligation for whichever outputs leave the building, which is a design decision as much as a legal one and is settled in the governance piece as one of five decisions with a name beside each. And a liability position that does not treat a confidentiality failure, a data breach and a typo as the same category of harm. Those three paragraphs do more for a mid-market buyer than any amount of argument about the indemnity, and they are the ones vendors have the least defensible reason to refuse.
Service levels for a system that degrades instead of stopping.
Software service levels measure availability, because software fails by being unreachable. An AI system reaches that failure mode too, but it is not the one that hurts. The characteristic failure is that the system stays up, answers every request, and gets quietly worse: a model version changes, an upstream document set drifts, a prompt is edited to fix one case and breaks four others, and the output slides from useful to plausible. Nobody files a ticket, because nothing is down. Usage falls away instead, which is the same outcome as an outage with none of the alerting.
An uptime commitment does not touch this, and on most engagements the uptime number is largely the cloud provider's anyway, passed through. Writing a harder availability term is negotiating over the wrong variable.
What belongs in the agreement is the quality half, and the raw material for it already exists if the engagement was scoped properly. The acceptance criteria are the criteria the system had to meet to be accepted. Turn them into a standing obligation rather than a one-time gate: the same tests, run on a stated cadence against a stated sample, with the results reported to the customer and a defined response when the system falls below the threshold. That converts a vague expectation of continued quality into something a person can check and a contract can enforce.
Two drafting notes decide whether this works. The measurement method has to be named, including who holds the evaluation set and who runs the test, because a quality threshold measured only by the party being measured is a reporting exercise. And the remedy has to be worth invoking. A service credit computed as a percentage of a modest monthly fee is not a remedy on a system carrying a real workflow; the meaningful remedies are a cure period with a named engineering commitment, and a termination right that triggers if the cure fails. Our own build process sets acceptance criteria and go/no-go thresholds in the specification phase for exactly this reason, and the scoping piece covers how to write criteria that different vendors will answer comparably.
The last day, in one paragraph.
Termination language is where a vendor's real intentions about ownership become visible, and it is covered at length in the handoff piece, so this is the short version for a document review rather than the argument.
Four things need to be present. What you receive, named as the artifact list from the ownership section rather than as a general promise of reasonable assistance. In what format, since a repository you cannot deploy is not a handover. Within how many days, counted from a defined trigger. And what happens to the copies that stay behind, which means a deletion scope naming backups, the vector store, logs and traces, the evaluation set, development and staging environments and the vendor's own support tickets, with written certification inside a stated window. Add the account transfer, since the credentials are as load-bearing as the code, and a transition period during which the vendor will keep the system running at a pre-agreed rate while you stand up the replacement. That last item is the one buyers forget and then pay a premium for at the worst possible moment.
The honest counter-case: when to sign the paper as written.
Most of this diligence is wasted on most purchases, and pretending otherwise is how a company spends six weeks reviewing a drafting assistant and then rushes the system that writes to the general ledger.
Sign the standard agreement and move on when the fee is small, the term is short, the data going in would not hurt you if it appeared publicly tomorrow, the system cannot take an action on its own, and a replacement exists that you could switch to in a week. Under those conditions there is nothing to protect and the negotiation costs more than the exposure. That is the majority of the tools a mid-market operator buys.
The clauses in this piece start earning their keep when at least one of the following is true: the system writes to a system of record, it touches material you hold under an obligation to somebody else, the artifacts are built out of your own accumulated material rather than off the shelf, or the fee is large enough that the switching cost is the real lock-in. Scaling the diligence to what the system can do rather than to what it can see is the same test applied one layer up, and the AI Maturity Index asks the two questions that usually settle it in about ten minutes.
Our own position, since it would be strange to write this and stay quiet about it: ColabContent sells commissioned builds and signs contracts with the operators who buy them. We hand over the code and the artifacts at handoff and the system runs in the operator's own cloud tenant, which is the entire commercial argument of the practice, so we have a plain interest in buyers caring about ownership language. A reader should weigh that. The parts of this piece that cut against us are the counter-case above, which tells most readers not to do any of this, and the model substitution clause, which is an obligation on the vendor and therefore on us.
What to do this week, with no vendor in the room.
Four things, in order, none of which requires a negotiation to start.
Pull the agreements you have already signed for anything with a model in it, and find the training sentence and the termination paragraph in each. Not to renegotiate them, which you mostly cannot do mid-term, but to know what you are already carrying. Most operators discover at least one surprise, and the common one is a tool nobody classified as an AI purchase because it was sold as something else.
For anything currently running, write down which model and version it uses and go look up that model's published lifecycle page. This takes about fifteen minutes per system and it is the single highest-information act in this whole piece, because the answer is a date and dates can be planned against.
Ask your vendors, in writing, for the subprocessor list and the governing terms for your specific tier. The request is routine before signing and awkward afterwards, but it is still worth making, and the speed of the answer tells you something regardless of what the documents say.
Then, for the next purchase, put the five items into your own template rather than reacting to theirs: the artifact list in the deliverables definition, the training and reuse permissions stated in both directions, the model substitution and re-acceptance clause, an indemnity read for what it actually covers alongside a warranty and liability position that addresses wrong output, and a termination paragraph naming contents, format, days and deletion scope. The buyer checklist covers the questions that come before the document, and what a mid-market engagement costs sets the number the document sits underneath.