What to Do When an AI Vendor Changes Its Privacy Policy
Most policy-change emails need ten minutes and no action. Telling those apart from the ones that do is a repeatable process.
Read the diff, not the email. A vendor's summary of its own policy change is written by the people who made the change, and the useful information is in which clauses moved. Four of them can create work for you. The rest almost never can.
This comes up more often than it used to, partly because AI vendors are still working out their data handling in public, and partly because features ship ahead of the policies describing them. The ZCode indexing episode this month is the sharper version of the same problem: developers found a client uploading workspace data that the privacy policy did not mention at all. A policy that has not caught up with the product is a worse position than a policy that changed.
The four clauses that matter
**Training on your data.** The question is whether your inputs and outputs may be used to improve the vendor's models, and whether the default is opt-in or opt-out. A change here is the one most likely to require action, because for many businesses it is the difference between an approved tool and a prohibited one. Check whether the change applies to your plan tier, since consumer and business tiers frequently differ and announcements rarely say which one you are on.
**Retention.** How long inputs are kept, and whether there is a separate abuse-monitoring copy with its own longer clock. Zero retention and thirty-day retention are different products from a compliance standpoint, and the abuse-monitoring carve-out is the detail people miss, because it often persists even when the main retention is set to zero.
**Subprocessors.** Who else touches the data, and where. A new subprocessor in a new jurisdiction is the change most likely to ripple into your own customer commitments, since many data processing agreements require you to notify customers when your subprocessor list changes. If you have signed a DPA with anyone, this clause is the one that can create a contractual obligation with a deadline attached.
**Purpose scope.** What the vendor says it may do with the data beyond serving your request. Broad new language about product improvement, analytics or safety research is worth reading closely, because it is where narrow permissions quietly widen.
Everything else, and there is usually a lot of it, is typically restructuring, jurisdiction boilerplate or cookie language that does not touch your obligations.
A ten-minute review
Get the actual diff. Many vendors publish a change log or keep prior versions; when they do not, an archived copy of the previous version compared against the current one takes two minutes and is more reliable than the summary.
Search the new version for the four clauses above rather than reading top to bottom. Useful search terms: "train", "retain", "subprocessor", "improve our services".
Decide the tier question. Confirm the terms apply to the plan you are actually on, including whether an API and a consumer subscription are covered by the same document.
Write one line in a running note: date, what changed, whether it affects you. Most entries will say no. The value is in having a record when a customer asks what changed and when.
When you have to tell your own customers
You have an obligation to pass a change along in three situations.
Your own privacy policy names the vendor, or describes a data flow that the change makes inaccurate.
You have signed a DPA with a customer that requires notification of subprocessor changes, which most enterprise agreements do, often with a fixed window and an objection period.
The change materially alters what happens to customer data, most commonly a shift to training on inputs by default.
If none of those apply, the correct action is the note in step four and nothing else. Notifying customers about every upstream policy revision trains them to ignore the notifications, which costs you the one time it matters.
The structural fix, if you are doing this repeatedly, is to write your own policy so it does not need editing every time a vendor moves. Naming categories of subprocessor and maintaining a linked list, rather than naming vendors inline, is the standard approach. How to write a privacy policy for an AI app covers the drafting, and a data processing agreement for an AI product covers the contract layer underneath it.
When a change is bad enough to leave
Rare, and worth naming in advance rather than deciding under pressure. A reasonable threshold: training on your data with no opt-out available on your tier, or a retention period you cannot reconcile with a commitment you have already made to a customer. Both are objective, both are checkable, and having written them down beforehand turns an anxious afternoon into a decision you already made.
Before acting on one, confirm it. Policy changes get reported inaccurately, frequently by summaries of summaries, and vendors do sometimes clarify or reverse within days. Read the primary document.
Questions
How do I find out about changes at all?
Vendors are inconsistent about emailing them. Subscribe to the vendor's status or change log where one exists, and set a calendar reminder to check the policies of your two or three most critical vendors quarterly. Assume you will not be told.
Does an opt-out actually stop training?
It stops the vendor using your data to train, per the terms. It does not usually affect abuse-monitoring retention, which is a separate system with its own window. Read both clauses, since one commonly answers the question people think the other answers.
What if the vendor changed behaviour but not the policy?
That is the harder case and the one the ZCode reports illustrate. A policy that does not describe what the software does is a reason to verify the software's behaviour directly rather than to trust the document. Whether to turn off codebase indexing works through that check for coding tools specifically.
Do I need a lawyer for this?
Not for the routine review. Get advice when a change collides with a commitment you have made in a signed contract, which is the situation where being wrong is expensive rather than merely awkward.
What should I write in my own client agreements?
Enough flexibility that a vendor's ordinary policy revision does not breach your contract, and enough specificity that a client knows what happens to their data. How to write an AI usage policy for clients covers the balance.
The wider set of vendor-dependency risks worth tracking is in AI risks: a practical guide for builders.
How did this land?
About the author
Senior Editor, AI & Product
Cecilia leads the Swarmz editorial desk. She has spent a decade turning complex AI and product topics into writing people actually finish, and she owns the blog's quality bar.
