A company adopting a third-party AI tool is usually handed the vendor's standard form and asked to sign. That form is drafted for the vendor. Six categories of terms — data, intellectual property, indemnity, warranties, liability, and exit — decide where the risk actually sits, and each rewards a slower reading than most procurement gives it.
An AI vendor agreement is a commercial contract like any other, and it should be read like one. What makes it distinct is the subject matter: the company is sending its documents, its questions, and sometimes its customers' information to a system it does not control, and taking back output it intends to use and sell. The agreement decides who owns the inputs and the outputs, whether the vendor may reuse what it receives, who bears the cost if an output infringes someone else's rights, what the vendor promises about security, how losses are capped, and what happens when the relationship ends. Most of those answers live in clauses a hurried buyer skips, and the standard text rarely starts in the customer's favor.
This article is the full treatment of that agreement. It walks the six categories a company should work through before it signs, in the order a negotiation tends to reach them, and it states what a careful customer looks to strike, add, or clarify in each. It is written for the business procuring the tool — the founder, the general counsel, the operations lead who has been handed a contract to approve — rather than for the vendor selling it. The aim is to give a working map of where the exposure sits in an AI procurement, not a model contract, because the terms that fit one deal rarely fit another.
It is general commercial guidance, not legal advice on any particular contract, and one caution runs through all of it: what a specific AI agreement should say depends on the tool, the data the company will put into it, the company's own legal obligations, and a body of law that is moving quickly. The points below are stated generally and as the landscape stands in 2026. A vendor agreement of any consequence should be reviewed by counsel against the actual terms and the company's actual facts, and reading or relying on this article does not create an attorney-client relationship. The recurring lesson is that the standard form is a starting position, not a settled one, and the customer who reads it closely negotiates from a stronger place.
Data rights and the right to train
The first category is the data the company puts in and gets back. A well-drafted agreement confirms that the customer keeps all rights in the inputs it submits — the prompts and the content within them — and that the customer owns or is licensed to use whatever the tool generates in response, the outputs. Standard vendor terms are often vaguer: they may grant the vendor a broad license over inputs, decline to say who owns the outputs, or reserve rights in generated material a customer expects to hold outright. Alongside ownership sit the confidentiality, sub-processing, residency, and deletion terms that govern how the data is handled while the vendor holds it. The clause that deserves the closest reading is the one on model training, because many default terms permit the vendor to use customer inputs and outputs to train or improve its models, and that permission is frequently buried in a definitions section or a usage policy rather than flagged. A careful customer looks for an explicit statement that the vendor will not train on its data, or, where training is on by default, a clear opt-out that takes effect by contract rather than by a setting that can change.
Because the data clauses carry so much of the exposure, they are treated on their own in the firm's field note on what an AI vendor contract should say about your data, which walks the input, output, training, confidentiality, sub-processor, retention, and deletion provisions clause by clause. This article does not repeat that walk-through. What matters at the level of the whole agreement is how the data terms connect to everything that follows: who owns the inputs shapes the intellectual-property analysis in the next section, what the vendor may do with the data shapes the security commitments later, and the deletion obligations are part of the exit terms at the end. The data clauses are not a self-contained corner of the contract; they are the foundation the rest of it is built on.
Two practical points deserve emphasis even in an overview. First, a broad license to inputs can function as a training permission even where the word training never appears, so the question is not only how a clause is labeled but what the license actually allows the vendor to do with the data over time. Second, where the company will feed in personal or regulated data, the handling terms belong in a data-processing addendum that addresses sub-processors, residency, security, and breach notification, rather than in a single sentence promising reasonable care. How hard to press on these points is a function of what the company is putting into the tool — a governance question as much as a contract one, and one the company should answer before it negotiates.
A broad license to inputs can function as a training permission even where the word training never appears.
Intellectual property in the outputs
The second category is ownership of what the tool produces, and it is more complicated than a contract alone can resolve. As a matter of the agreement, the customer wants the outputs assigned to it or licensed broadly enough to use, modify, and sell them for its own purposes, with the vendor retaining no rights that would limit that use. A clear assignment or license clause is the contractual half of the answer. But the contract operates against a copyright question it does not control: under United States law, material that lacks sufficient human authorship may not be protectable by copyright at all, which means a company can hold a clean contractual grant of output and still find that the output is something competitors are free to copy. The agreement decides what rights pass between the company and the vendor; it does not decide whether those rights amount to protectable property.
That distinction is why the contract and the copyright analysis have to be read together. A vendor can grant generous usage rights while the copyright in the generated material remains weak or absent, so that the company is free to use the content but cannot stop others from using the same. The firm's article on who owns AI-generated content takes up the copyright side in full — the human-authorship requirement, why prompts alone are generally treated as too little, and what human selection and revision can do to support protection. For the purposes of the vendor agreement, the point is narrower: the company should not assume that a strong assignment clause delivers a strong copyright, and it should not represent to its own clients or buyers that AI-assisted deliverables are fully owned when that has not been established.
The agreement should also be clear about the company's own materials that go into the tool. Where the customer's inputs include its proprietary content, the contract should confirm that submitting them to the tool grants the vendor only the limited license needed to deliver the service, and not a broader right to use that content for its own products. The same caution applies to any feedback the company gives the vendor, which standard terms often claim the vendor may use without restriction. Intellectual property in an AI procurement runs in both directions — what the company gets back and what it sends in — and a contract that addresses only the outputs leaves the inputs to a license the company may not have read.
Indemnification for infringement claims
The third category is indemnification, and in an AI agreement it carries unusual weight because of where the outputs come from. An indemnity is a contractual promise by one party to cover certain losses of the other, typically the cost of defending and resolving a third-party claim. The claim a company most worries about here is that an output infringes someone else's intellectual property — that a generated image, passage, or block of code reproduces protected material the model learned from. Some AI vendors have offered indemnities against certain third-party infringement claims arising from use of their outputs, and the presence of such a promise is a meaningful term. Its value, though, lies entirely in its scope, and the scope is where the negotiation happens.
Vendors commonly seek carve-outs that narrow an output indemnity considerably, and a company should read for them rather than take the headline promise at face value. An indemnity may exclude claims arising from the customer's own inputs, from the customer modifying the output, from using the tool outside the permitted scope or against the usage policy, or from failing to use filtering or safety features the vendor provides. Each exclusion is reasonable in isolation, but together they can hollow the indemnity out, leaving it to apply only to the cases least likely to arise. The questions to settle are concrete: what claims are covered, what conditions the customer must satisfy, who controls the defense, and whether the vendor's obligation is to defend, to indemnify, or both. A promise to indemnify after the company has paid to defend is a weaker thing than a promise to take over the defense from the start.
An indemnity should also be read against the limitation of liability discussed in the next section, because the two clauses interact and a company that reads them separately can misjudge what it has. A generous indemnity that is then subjected to a low liability cap may be worth far less than it appears, since the cap can limit what the customer recovers under the indemnity itself. The more protective drafting carves the indemnity out from the general cap, or sets a higher cap for it, so that the promise is not quietly undone by a limitation elsewhere in the contract. Reading the indemnity and the liability cap as one question, rather than two, is among the differences between a contract a company understands and one it merely signed.
A promise to indemnify after the company has paid to defend is a weaker thing than a promise to take over the defense from the start.
Warranties, security, and service levels
The fourth category gathers what the vendor promises about how the tool will perform and behave. Warranties are the vendor's affirmative commitments — that the service will conform to its documentation, that the vendor has the right to provide it, that it will be delivered with reasonable care — and disclaimers are the vendor's attempt to limit them, often by stating that the output is provided as is and that the vendor does not warrant its accuracy. With a generative tool, a broad accuracy disclaimer is common and not unreasonable on its face, because the vendor cannot guarantee what a model will produce; the company's task is to make sure the disclaimer does not swallow the commitments that matter, such as the promise that the service will meet its description and that the vendor has the rights it purports to grant. Acceptable-use terms sit alongside the warranties and bind the customer: they define what the company may not do with the tool, and because violating them can void an indemnity, the company should know what they require before it relies on the tool for sensitive work.
Security and privacy commitments are the part of this category a company with its own obligations should press hardest. A clause promising industry-standard measures without naming any is difficult to enforce and easy to satisfy, and a company subject to privacy laws, sector rules, or its own client commitments should make sure the vendor's commitments are concrete enough to support them. Where personal data is involved, the security terms, breach-notification obligations, and the vendor's privacy commitments belong in a data-processing addendum rather than in general prose. The company should also confirm that the contract does not quietly shift compliance responsibility onto the customer for data the vendor controls, because a disclaimer that disowns the vendor's own handling obligations is a term to negotiate, not accept.
Service levels, model changes, and transparency round out the category and are easy to overlook until they matter. A company relying on the tool for ongoing work should look for defined availability commitments and for notice and continuity terms covering model changes and deprecation, because an AI vendor can alter or retire the underlying model in ways that change the tool's behavior, and a contract silent on the point leaves the customer exposed to a change it did not choose. Transparency and audit terms — a right to receive third-party security reports, or commitments about how and where data is processed — give the company a way to verify that the vendor is doing what it promised. How much assurance the company needs depends on what it has entrusted to the tool, which is again a governance question; the firm's checklist for companies deploying AI sets out the internal program — who approves a tool, what data may go into it, who signs off — that decides which of these contract protections the company actually requires.
Liability caps and exit
The fifth and sixth categories — limitation of liability and exit — are where a company learns what its other terms are worth. Limitation of liability clauses cap the amount one party can recover from the other and usually exclude certain categories of loss, such as indirect or consequential damages, and they are standard in commercial contracts. The questions for an AI agreement are how high the cap sits relative to the company's potential exposure, what it is measured against, and which obligations fall outside it. As the indemnity section noted, a low general cap can undercut an otherwise strong indemnity, so a company should confirm how the cap interacts with the indemnity and with the vendor's data and confidentiality obligations, and consider whether those obligations should carry their own higher cap or sit outside the general limit. A cap is not objectionable in itself; a cap that silently limits the protections the company negotiated hardest for is a term to revisit.
Exit and transition are the terms that govern the end of the relationship, and they deserve attention at the start, because the moment a company most needs them is the moment it can no longer bargain for them. The contract should say what happens to the company's data on termination: that the vendor will return or delete the customer's inputs and outputs within a stated period, will extend deletion to copies held by sub-processors, and will confirm in writing that it has done so. The company should also confirm that it can export its data in a usable form before the relationship ends, so that termination does not strand the work inside the vendor's system. Deletion that does not reach backups and derived data is incomplete, and where the vendor has already used customer data to train a model, deleting stored inputs does not remove their influence from the model — which is one more reason the training clause in the first section matters, because deletion on exit cannot fully undo what training has already absorbed.
The last question of exit is which terms survive termination, because some obligations must outlast the agreement to be worth anything. A company should make sure that confidentiality obligations, the deletion commitment, the indemnity for claims arising during the term, and any license the company needs to keep using outputs it generated all survive the end of the contract by their terms, rather than lapsing with it. A survival clause that omits the protection the company most relies on is a quiet gap that only appears when the relationship is already over. The constant across all six categories is the same: the standard form is the vendor's opening position, the exposure lives in the language, and the company that reads the contract as a whole — data, intellectual property, indemnity, warranties, liability, and exit, each in light of the others — is the company that signs knowing what it has agreed to.
The moment a company most needs its exit terms is the moment it can no longer negotiate for them.
Common questions
- Can we just sign the vendor's standard AI contract as written?
- You can, but the standard form is drafted for the vendor and usually starts from terms that favor it. The provisions that decide your exposure — who owns inputs and outputs, whether the vendor may train on your data, what the indemnity covers, how liability is capped, and what survives termination — are exactly the ones a standard form tends to set in the vendor's favor. A company should treat the form as an opening position to review with counsel against its own facts, not as a settled agreement.
- What should an AI vendor indemnity actually cover?
- The indemnity most companies care about covers third-party claims that an output infringes someone else's intellectual property. Its value depends on its scope, so read for the carve-outs vendors commonly seek — exclusions for your own inputs, for modified outputs, for use outside the permitted scope, or for not using provided safety features. Settle what claims are covered, what conditions you must meet, who controls the defense, and how the indemnity interacts with the liability cap, since a low cap can undercut an otherwise strong indemnity.
- What happens to our data when the contract ends?
- That depends on what the exit terms say, and standard forms are often silent or reserve broad retention rights. Look for a clear deletion obligation on termination — return or deletion of your inputs and outputs within a stated period, extension to sub-processors, and written confirmation — along with the ability to export your data in usable form before you leave. Note that if the vendor already used your data to train a model, deleting stored inputs does not remove their influence, which is why the training terms matter from the start.