Buying an AI agent looks like buying software, but the contract you inherit from standard software terms often does not fit. The agent acts on your behalf, depends on a model you do not control, and changes behaviour when someone upstream updates it. This article is for the person who has to choose the vendor and sign: which questions to ask, and what to get written down.
It does not repeat how to run the agent safely once it is live. For that, see incident response and kill switches and data handling and retention. For the earlier decision of whether to buy at all, see the buy vs build checklist.
Map the chain before you talk to the vendor
The company on the invoice is rarely the only party that touches your data or your agent's output. A typical agent product combines a platform vendor, one or more model providers, hosting, and integrations with tools such as email, CRM, or payments. Ask for the list and put it in the contract:
- Which model providers and versions power the product, and can you be told before they change?
- Which subprocessors handle your data, in which countries, and how are you notified when the list changes?
- Which third-party tools does the agent call, and under whose terms?
OWASP lists supply chain weaknesses among the main risks for LLM applications: models, data, and plug-ins you did not build are part of your risk. NIST's work on cyber supply chain risk management gives a general frame for assessing suppliers; you do not need all of it, but its basic idea applies: you remain responsible for risk that arrives through a supplier.
Ask for service levels that fit agents
A 99.9% uptime figure tells you the service answers. It does not tell you the agent does the job well. Ask for these in addition:
- Latency and capacity. Typical and worst-case response time, and what happens at rate limits. An agent that silently queues work for hours may be "up" and useless.
- Change notice. How long before the vendor changes a model, a default prompt, or a tool behaviour that affects output? Can you pin a version for a defined period?
- Support response. A named contact and response times for incidents, especially for the case where the agent is doing something wrong, not just offline.
- Remedies. Service credits are usual and small. Decide what you actually need: a right to pause, roll back, or terminate if a serious problem is not fixed in a stated time.
Do not rely on the vendor's quality claims as a commitment. If accuracy matters, define a test set with the vendor, run it before signing and after each major change; see evaluating AI agent reliability. Put the agreed measures in an appendix, even if they are targets and not guarantees.
Settle the data terms in writing
Most data questions can be answered with a clear sentence in the contract. Check each of these:
- Use of your data. Is it used to train or improve models for others? The answer should be no unless you have decided otherwise.
- Retention and deletion. How long are prompts, outputs, and logs kept, and can you trigger deletion? Is deletion also applied to backups, within what time?
- Location and access. Where is data processed, and which vendor staff can see it?
- Subprocessors. The list, the notice period for changes, and your right to object.
- Breach notice. A fixed time to inform you, and what the notice must contain.
If you handle personal data of people in the EU, the GDPR requires a written contract with processors. Article 28 lists what it must cover, including instructions, confidentiality, security, subprocessors, and deletion or return of data. Your legal contact should confirm that the vendor's data processing terms meet it; do not accept a link to general terms as the only answer.
Be clear about who is liable when the agent is wrong
Vendors usually limit liability to the fees paid in a period and exclude indirect losses. For an ordinary tool this may be acceptable. For an agent that sends messages or moves money, ask two direct questions: what happens if the agent causes a loss, and what is excluded from the cap? Common candidates for higher limits or separate treatment are data breaches, confidentiality, and intellectual property claims.
Be realistic. Many vendors will not accept unlimited liability, and the model's mistakes are hard to prove. A better use of negotiation is to reduce the chance of loss through your own controls: approval for high-impact actions (human approval and audit trails), permission limits (identity and least privilege), and spending caps. Then ask whether your insurance covers losses caused by an automated system.
The EU AI Act also distributes duties along the value chain. Article 25 describes when a distributor, importer, or deployer takes on the obligations of a provider, for instance by changing the intended purpose of a high-risk system. If your use may fall in that category, ask the vendor in writing which role each party has, and what documentation they will supply.
Plan the exit before you sign
Leaving is where lock-in shows. Before signing, write down what you would need to move:
- Your content. Prompts, instructions, knowledge sources, workflow definitions, and evaluation sets, in a documented, readable format.
- Your records. Logs and approval records, in a form you can store yourself. Regulators and customers may ask for them after the contract ends.
- A transition period. Continued service at the same price for a stated time after notice.
- Deletion proof. Written confirmation that your data has been deleted, with a date.
Also check termination rights. You want the right to end the contract for a serious or repeated failure, for a material change in the model or subprocessors you cannot accept, and for a change of control of the vendor. Short initial terms, or a pilot with a defined end, keep the commitment small; see a staged rollout plan.
Keep the contract alive after signing
The contract is not finished when it is signed. Assign an owner who, each quarter, reviews the subprocessor list, change notices, incident history, and cost against the agreed terms; for the cost side see cost controls for AI agents. Keep a short record of vendor incidents and how quickly they were handled. It will be useful at renewal.
A one-page checklist
- A written list of the supply chain: model providers, hosting, subprocessors, tools.
- Service levels that cover latency, change notice, and version pinning, not only uptime.
- Data terms: no training on your data, retention, deletion, location, breach notice.
- A liability clause that you have read with your legal contact, and an insurance check.
- An exit plan: export formats, transition period, deletion proof, termination rights.
- A named internal owner and a quarterly review date.
