AI Vendor Changed Its Terms of Service: What to Do

When an AI vendor changes its terms of service, four clause types decide whether you can ignore it: training rights, data retention, liability, and termination or pricing. Everything else in the diff is usually housekeeping. The problem is that the notice arrives as an email with a subject line like 'Updates to our Terms', thirty days before it takes effect, and the person who reads it is rarely the person who would recognise what changed. Here is how to triage one quickly and what it obliges you to do next.

Find the diff, do not read the document

Reading forty pages of terms in full is how this task gets postponed until it is moot. Most vendors publish a change log or a summary of material changes, and many keep previous versions available. Start there. If neither exists, save a copy of the current terms and compare against the one you saved last time, which is a habit worth starting today even though it does not help you today.

Then look only for the four things below. A change that touches none of them is genuinely fine to note and move on from.

1. Training rights

The clause that says whether your inputs and outputs can be used to improve their models. This is the one that changes most often, usually in the direction of a new default with an opt-out, and it is the one with the sharpest consequences.

What to check: whether business or enterprise tiers are carved out, whether the opt-out is account-wide or per-workspace, and whether it applies retroactively to data already sent. If you told customers their data would not train third-party models, a change here can put you in breach of your own privacy policy, which is a worse problem than the vendor change itself. The mechanics of confirming the current position are in how to check if an AI tool trains on your data.

2. Retention and sub-processors

How long they keep your data, where it sits, and who else touches it. A new sub-processor in a new jurisdiction is easy to miss and matters if you have made commitments about data location.

If you process personal data through the tool, this is not just a preference question. Under Article 28 of the GDPR, a processor engaging another processor is subject to conditions including notice to you, so a sub-processor change is something you are entitled to know about and, in many arrangements, to object to. Most vendors maintain a sub-processor page you can subscribe to. Doing that once is a better use of an hour than reading any set of terms.

3. Liability, indemnity and warranties

Dry, and the reason it matters is concrete. Several vendors offer some form of copyright indemnity for generated output, and the conditions attached to it get narrowed more often than the headline is withdrawn. A cap that moves from twelve months of fees to three months is a real change in your exposure that reads like nothing.

Check whether the indemnity still covers your use case, whether it now requires you to have kept certain safety settings enabled, and whether the cap changed. If you resell work produced with the tool, this clause is the one your own client contracts are quietly leaning on.

4. Termination, deprecation and price

How much notice they owe you before shutting something down, what happens to your data afterwards, and how much notice you get before a price change. Rate limits and fair-use language belong here too, because an unchanged price with a changed usage allowance is a price change wearing a different hat.

Deprecation is not hypothetical, and it does not always arrive through the terms at all. Vendors maintain their own schedules, and a dated shutdown notice for an API you depend on can sit on a documentation page for a year before anything happens, as with OpenAI's published deprecations list. Subscribing to that page is worth as much as reading the terms.

The first week, in order

1. Confirm the effective date and whether continued use counts as acceptance. It usually does, which means the deadline is real.

2. Triage against the four clause types. Ten minutes if you have a diff, an hour if you do not.

3. Check what you have promised downstream. Your privacy policy, your customer contracts, your data processing agreement, any security questionnaire you have filled in. A vendor change becomes your problem the moment it contradicts one of these.

4. Take the settings action while you remember. If there is an opt-out, use it and screenshot the confirmation with the date visible. Future you will want proof of when it was set.

5. Notify anyone who needs to know. If the change affects how customer data is handled, silence is a decision, and not a good one.

6. Write down what you decided and why, in two lines. This is the note that answers a due diligence question in eighteen months.

Step 3 is the one that separates a nuisance from an incident. The vendor changed their terms, but you are the one who told your customers something about their data.

When to actually leave

Rarely, and it is worth being honest about why. Switching costs are high, the replacement vendor will change its terms too, and a change you dislike is not the same as one you cannot live with.

Three situations genuinely justify migration: the new terms contradict a commitment you cannot retract, such as a contractual promise to an enterprise customer; the change signals a direction that will keep going, such as a second retention expansion in a year; or the tool sits somewhere critical enough that losing your negotiating position is the real risk. That last case is an argument for having the conversation early, which negotiating a contract with an AI vendor covers. Above a certain spend, terms are negotiable in ways the public page does not advertise.

If you do decide to go, export first and cancel second, in that order, every time. The related failure mode where the decision is not yours at all is covered in what happens to your data when an AI company shuts down.

Frequently asked questions

Do I have to accept a terms change?

Practically, you accept it by continuing to use the service after the effective date. Some agreements let you reject a material change by terminating before it takes effect, occasionally with a refund of prepaid fees. If you are on an annual contract rather than the public terms, read your own agreement, because it may override the online version entirely.

How do I find out about changes without reading every email?

Subscribe to the vendor's sub-processor and changelog pages where they exist, and put a recurring twenty minute slot in the calendar each quarter to check the terms of your three most critical tools. That covers most of the risk for very little time, and it is more reliable than hoping the right person opens the right email.

Does a terms change affect data I already sent?

Sometimes, and it is the specific question to ask. Training and retention clauses are usually written to apply going forward, but not always clearly. If the terms are ambiguous on retroactivity, ask support in writing and keep the reply, which is worth more than any interpretation you arrive at yourself.

Should I have a process for this before it happens?

Yes, and it is smaller than it sounds: a list of your AI vendors, what data each one sees, and what you have promised about it. Build that once and every future terms change becomes a ten minute triage instead of a research project. Building the list is step one of vetting an AI vendor, and it sits alongside the broader AI risks overview.