Guides · ← All guides
How to Read an AI Vendor's Terms of Service Like a Lawyer
Last updated: October 13, 2026 · 10 min read
This guide is informational, not legal advice.
Nobody reads terms of service. That's not laziness — it's design. The terms are long, the language is dense, and the clauses that matter are scattered across the Terms, the Privacy Policy, a Data Processing Addendum, and a help-center article linked from somewhere you'd never think to click. The asymmetry is the point: the vendor's lawyers spent weeks on the document; you're expected to spend seconds.
Here's the thing lawyers know that you don't need a law degree to use: you don't have to read every word. You have to read the right sections, in the right order, with a search box. This guide gives you the checklist.
Before you start: assemble the full document set
The first mistake is reading the Terms of Service as if it were the whole deal. It isn't. An AI vendor's data commitments typically live in four to six documents:
- Terms of Service / Terms of Use — the license you grant, acceptable use, termination, liability, dispute resolution.
- Privacy Policy — what data is collected, how long it's kept, who it can be shared with. Training-data disclosures often hide here, not in the ToS.
- Data Processing Addendum (DPA) — the GDPR-flavored document that governs how the vendor handles data as a processor. If you're in the EU or handle EU data, this is where the real commitments live.
- Subprocessor list — who else touches your data. Sometimes a separate page, updated without notice.
- Security documentation / trust center — certifications, encryption claims, incident response. Marketing-adjacent, but the specifics matter.
- Help-center articles — where opt-out instructions and "how we use your data" explanations live. Not legally binding in the same way, but practically decisive.
Bookmark all of them. In our experience watching vendor terms, the most consequential sentence about your data is as likely to be in a help-center article as in the ToS — and help-center articles change without any version control at all.
The seven clauses that matter
Open the terms, hit Ctrl+F (or Cmd+F), and work through these in order. For each one, we've listed the search terms and what good versus bad looks like.
1. Training-data use
Search: "train", "improve", "machine learning", "model", "opt-out".
You're looking for a plain statement of whether your inputs train or improve models, and whether you can opt out. The gold standard is a sentence like "we do not use your inputs to train our models." The red flags are vagueness ("we may use data to improve our services" — improvement frequently means training) and opt-out friction. Remember the Slack case from May 2024: training was the default, and opting out required a workspace owner to email the company with a specific subject line. An opt-out you have to write an email for is a very different thing from an opt-out that's a toggle in settings.
Also check whether the answer differs by tier. Many vendors exclude API and business-tier data from training while free consumer tiers train by default. Make sure you're reading the clause for the tier you're actually paying for — or not paying for.
2. Data retention and deletion
Search: "retain", "retention", "delete", "deletion".
Three questions: how long is data kept, can you request deletion, and does the vendor commit to a timeframe for completing it? Watch for the gap between "we delete your account" and "we delete your data" — they're routinely presented as one promise and they're not. And read the exceptions. A 30-day deletion promise followed by "except where retention is required for legal, security, or legitimate business purposes" can quietly extend to indefinite, depending on how the vendor defines those purposes.
3. The license you grant
Search: "license", "grant", "rights", "sublicensable".
Every AI vendor needs some license to your inputs just to process them. The question is scope. A license limited to "providing and operating the service" is normal. A worldwide, perpetual, sublicensable license "to develop and improve our products" is a training-data clause with extra steps. The broader the license, the more suspicious you should be of everything around it — and the more carefully you should cross-reference with the training-data section, because the two often tell different stories.
4. Liability and indemnity
Search: "liability", "indemnify", "damages", "warranty".
AI terms almost universally cap the vendor's liability — often at the fees you paid in the preceding 12 months — and disclaim warranties on outputs. That's standard across the software industry, not a scandal. What deserves your attention is the asymmetry: many terms require you to indemnify them against third-party claims arising from your use, including claims about the outputs the model generated for you. So the vendor caps its exposure at your subscription fee while you indemnify them against IP claims on content their model produced. Know which direction the indemnity flows before you build a revenue stream on the API.
5. Service changes and termination
Search: "modify", "discontinue", "suspend", "terminate".
Can the vendor change the service or the terms at any time? How much notice do you get — 30 days by email, or a "last updated" date change on a page nobody visits? Can they suspend or terminate your account without cause, and what happens to your data then? If your product depends on a vendor's API, a "we may discontinue the service at any time" clause is a business-continuity risk. Price it in: what's your migration plan if the model you're built on gets deprecated with 30 days' notice?
6. Dispute resolution
Search: "arbitration", "governing law", "jurisdiction", "class action".
Many AI vendors require binding arbitration and waive class actions, with the vendor's home state or country as governing law. You will never think about this clause until the week you need it. When something goes wrong — a data incident, a billing dispute, a terminated account holding your data — this clause decides where you fight and under what rules. For a small company in Belize or Brazil disputing with a vendor governed by California law with mandatory arbitration, the clause can make a claim economically impossible to pursue. That's worth knowing before the dispute, not during it.
7. Subprocessors and data sharing
Search: "share", "third part", "subprocessor", "affiliate".
Who else touches your data? Cloud infrastructure providers, annotation contractors, analytics tools, corporate affiliates. A vendor with a published, versioned subprocessor list that it updates with notice is meaningfully more transparent than one with a blanket "we may share data with service providers" line. And note the direction of change: subprocessor lists tend to grow, not shrink. Check it when you sign up and check it again when you renew.
The five-minute triage method
Here's the fast version for when someone on your team is about to sign up for a tool and you have five minutes. Open the privacy policy and the terms. Search "train" first — that single search answers the highest-stakes question. Then search "retain" for the retention window, then "share" for the subprocessor posture. Three searches, five minutes, and you'll know more about the vendor's data deal than 95% of their users.
Then do one more thing that almost nobody does: check the "last updated" date on each document. If the privacy policy was updated last week and the training-data language is vague, that's worth ten more minutes. Fresh terms with fuzzy data language are exactly where surprises live.
FAQ
Should I read the DPA too?
If you handle anyone's personal data under GDPR or similar regimes, yes. The DPA is where the vendor commits to processing data only on your instructions, assisting with data-subject requests, and notifying you of breaches. The ToS is the vendor's terms; the DPA is closer to your contract.
What if the terms say "we may update these terms at any time"?
Assume they will, and that you won't be told in a way you'll notice. This is the single biggest reason terms review has to be continuous. A one-time read gives you a snapshot; the vendor keeps editing the negative.
Are clickwrap terms actually enforceable?
Generally yes, in the US and EU, provided the user had reasonable notice and manifested assent — though courts have pushed back on terms hidden behind obscure links. But "enforceable" cuts both ways: it also means the vendor is bound by what it promised. That's why finding the promises matters.
How often should I re-check a vendor's terms?
Monthly for vendors that touch customer data or core workflows, quarterly for the rest, and immediately whenever the "last updated" date changes. In our tracking, AI vendor terms change far more often than traditional SaaS terms — the technology and the regulations are both moving, and the documents move with them.
How to make this sustainable
Doing this once per vendor is a solid afternoon's work. Doing it continuously — because the terms change — is where everyone gives up. That's the real lesson of this checklist: reading terms isn't a one-time task. It's a monitoring task.
Read the baseline carefully with the seven clauses above. Save a dated copy of every document you review. Then track the pages, so the next material change comes to you as a diff instead of hiding in a silent "last updated" edit. The vendors aren't going to slow down. Your review process has to stop being a project and start being a habit — or a machine that does it for you.