AI PrivacyMarch 13, 2026· 11 min read

What happens when an AI provider changes their terms

Three real 2025-2026 vendor term changes (Anthropic's August 2025 consumer pivot, OpenAI's Mixpanel sub-processor removal, and Microsoft's January 2026 Anthropic addition) and the four-step playbook for when the notification email arrives.

TLDR

Three real vendor changes in the last twelve months drove this article: Anthropic's 28 August 2025 consumer terms pivot, OpenAI's April 2025 sub-processor list update plus the November 2025 Mixpanel removal, and Microsoft's 7 January 2026 addition of Anthropic as a default sub-processor for Microsoft 365 Copilot in most regions. Each one moved a compliance line that DPIAs and processing registers were resting on.
The hardest part of vendor-terms drift is that the most consequential changes are not in the document with "Terms" in the title. They are in a sub-processor list update, a privacy notice tweak, a quiet default flip, or a vendor breach disclosure that triggers a sub-processor removal nobody asked for.
The Article 28(2) right to object to a sub-processor change is real but only meaningful if the contract gives you somewhere to go. The EDPS view is that "your only remedy is to terminate" is not a meaningful objection right. Read the objection clause before you need it.
Anthropic's consumer pivot did not apply to API or commercial customers. Most teams that panicked about it were not affected. The teams that did need to act were the ones using personal Claude Pro accounts on company laptops and never built an enterprise relationship in the first place.
The four-step playbook when an email arrives: classify the change, map it to your documents, decide accept / negotiate / migrate, and update the artefacts. Most changes are minor. Having the playbook means the rare serious one does not catch you sideways.

Why this article exists right now

The reason to write this in April 2026 instead of as a generic "monitor your vendor terms" piece is that the last twelve months produced three vendor changes that each moved an important line for builders running AI features in production. None of them was a hypothetical. None of them was uniformly handled well. The pattern across them is the actual lesson, and the playbook in the second half of this piece is reverse-engineered from how the well-prepared teams responded.

Most articles on this topic stop at "set up monitoring." That is not the hard part. The hard part is the moment a notification email lands in someone's inbox (or worse, a sub-processor list updates without one), and a senior engineer or DPO has 30 days to decide what to do about it. The walk-through that follows is the one I would want in front of me if I were the engineer.

Case 1: Anthropic, 28 August 2025

On 28 August 2025 Anthropic updated its consumer terms and privacy policy with two material changes. New conversations and coding sessions on Claude Free, Pro, and Max would be used for model training unless the user opted out. Data from users who allowed training would be retained for up to five years, up from the previous 30-day default. Existing users had until 28 September 2025 to make the choice in their privacy settings, later extended to 8 October. Pre-existing chats were not included unless the user resumed them.

The press coverage in the days that followed was loud and largely confused. The confusion mattered.

The Anthropic consumer change did not apply to commercial customers, the API, Claude for Work, Claude for Government, Claude for Education, or Claude Code accounts associated with those tiers. The company's news post and the privacy policy were explicit about this. The teams that needed to react were not the ones running production features through the API. They were the ones whose developers had been using personal Claude Pro accounts on work machines, exactly the shadow AI pattern, and had been pasting client code into a tier whose terms had just shifted under them. If your team uses Anthropic on a commercial plan, the change was not your problem. If your team uses Anthropic on personal plans, the change was a forcing function to migrate to a commercial plan (or Claude Code with a Console account) before the new training default kicked in. The lesson is the second one, not the first.

The compliance question for any team that did have personal-tier Claude usage in scope was: did your DPIA reference Anthropic's previous 30-day retention as a load-bearing fact? If yes, the DPIA was now wrong. The privacy notice that pointed at the old retention was now wrong. The risk register that scored Anthropic on retention was now wrong. None of those were marketing problems. They were each a small documentation update with a paper trail and an owner.

The other thing the August 2025 change made obvious is that the consumer/commercial split is now part of the threat model. If your processor register lists "Anthropic" without specifying which tier, the register is incomplete. Tier matters more than it used to.

Case 2: OpenAI, April 2025 sub-processor list update and the Mixpanel removal

OpenAI publishes its sub-processor list at a stable URL and revises it on an irregular cadence. In April 2025 the company published a discrete sub-processor list update document, the kind of artefact that signals "this matters, please notice." Most teams did not notice. The notification mechanism for OpenAI customers depends on the tier and the contract: enterprise customers get email notifications, API customers are expected to monitor the page. The page does carry a "last updated" date, which is more than some competitors offer, but the notification path is shallow if you have not subscribed to the right list.

The harder case came eight months later. On 9 November 2025 Mixpanel, a third-party analytics provider that OpenAI had been using on parts of its platform, was breached. An attacker exfiltrated a dataset that included user names, email addresses, approximate geolocation from browser settings, operating system, browser type, referring sites, and OpenAI API user identifiers. No chat content, API requests, API usage data, passwords, payment details, or government IDs were compromised, per OpenAI's incident disclosure. Mixpanel notified OpenAI on 9 November and shared the affected dataset on 25 November. OpenAI removed Mixpanel from production services and, after the review, terminated the use of Mixpanel entirely.

The Mixpanel incident is a sub-processor change that arrived as a security incident first. From the customer's viewpoint, the timeline was: a vendor breach disclosure on 25-26 November, a sub-processor list change shortly after as Mixpanel was removed, and an implicit DPA refresh because the processing chain had a node less in it. None of those were a "terms change" in the literal sense of the word. All three required a documentation pass, an Article 33 GDPR notification analysis (the data was personal data, the impact assessment was the controller's call), and a processing-record update to remove Mixpanel from your own register if you had inherited it through OpenAI. The civil litigation that followed (lawsuits filed against both Mixpanel and OpenAI in December 2025) is a reminder that sub-processor failures are the controller's problem, not just the processor's.

The lesson from the OpenAI cases is that sub-processor changes do not arrive on a schedule. They arrive when the vendor's reality changes. Sometimes that is a deliberate strategic move (April 2025). Sometimes that is a forced response to an incident (November 2025). Either way, the customer-side process has to handle both.

Case 3: Microsoft, 7 January 2026

On 8 December 2025 Microsoft posted an admin-center notification for global administrators of Microsoft 365 Copilot tenants: a new toggle would appear, defaulting to ON for most commercial-cloud customers and OFF for customers in the EU, EFTA, and the UK. On 7 January 2026 the toggle activated. Anthropic became a Microsoft sub-processor for Microsoft 365 Copilot, Researcher, Copilot Studio, Power Platform, Agent Mode in Excel, and Word/Excel/PowerPoint agents. Full availability was expected by the end of March 2026. Anthropic models remain unavailable in government clouds and other sovereign clouds.

The interesting feature of this change for the purposes of the present article is that the customer's exposure depended entirely on geography and on how much the customer's Article 28 documentation pinned the sub-processor list to a fixed date. A US-based commercial cloud customer with an out-of-date processing register woke up on 7 January with Anthropic in its processing chain and no documentation reflecting it. An EU-based customer woke up on 7 January with the toggle defaulted to OFF and a fresh question for the global admin: do we opt in, and if so, how do we update the DPA-annex sub-processor list for our own controllers downstream?

The structurally important point is that this was a default flip, not a terms change. The DPA itself did not change. The product terms did not change. The sub-processor list updated and the Microsoft 365 admin centre showed a new toggle. Most of the teams I have seen monitoring vendor terms manually were looking at the wrong document.

The pattern across the three

Three different vendors, three different mechanisms, three different consumer impacts. The shared structure is what matters.

First, the most consequential changes are not in the document with "Terms" in the title. Anthropic's August 2025 change was a privacy-policy update bundled with a consumer-terms revision. OpenAI's April 2025 change was a sub-processor list update, a separate artefact from the DPA. The November 2025 fallout was a security incident notice that produced a sub-processor removal. Microsoft's January 2026 change was an admin-centre toggle flip backed by a new sub-processor entry. If your monitoring process is "review the DPA quarterly," it would have caught zero of these.

Second, the consumer/commercial split is now part of every vendor relationship. Anthropic's August 2025 change made this explicit by carving out commercial tiers. OpenAI's tiers behave differently on training and retention. Microsoft's tier (and the admin centre's region-based defaults) determines which sub-processors run by default. The processor register entry "we use OpenAI" is an incomplete description. It needs to name the tier, the region, and the contract path.

Third, the right to object exists but requires somewhere to go. GDPR Article 28(2) lets a controller object to sub-processor changes under a general written authorisation. The 30-day window is the most common contractual implementation. The European Data Protection Supervisor's view, which has informed national DPA practice, is that the objection right has to be "meaningful." A clause that says "your sole remedy is to terminate the contract" is, in the EDPS view, not a meaningful remedy because for most production AI workloads termination is not actually available within 30 days. Negotiating an exit with continuity, an alternative sub-processor route, or a delayed activation is the meaningful version.

Read the objection clause before you need it. The first time you should look at your DPA's sub-processor objection mechanism is not when the email arrives. It is during contract negotiation, while the vendor still wants the deal. Look for three things: who has to be notified (a single named person is the worst case; a shared inbox is better), how long the objection window is (30 days is standard but some vendors give 15), and what happens if you object. If the only contractual outcome of objecting is "terminate the agreement," the right is not meaningful and the EDPS guidance gives you grounds to push back during negotiation. If you cannot negotiate this term, at least know which end of the spectrum your DPA is on so you can plan accordingly.

Fourth, the documents on your side are the work, not the documents on the vendor's side. The DPIA, the processing register, the privacy notice, the AI acceptable use policy, the DPA annex with sub-processors, the vendor risk assessment. Each one of these is a place a vendor change can break. The vendor has zero responsibility for keeping any of them current. That is your job. Most of the actual remediation work in all three cases above was small documentation updates that nobody had a single owner for.

The four-step playbook when an email arrives

When a vendor notification lands, a sub-processor list updates, or a security incident triggers a forced change, walk these four steps in this order. Most changes finish at step 1 with "no further action." The ones that escalate are the ones the playbook is for.

Step 1: Classify the change. A change is material if it touches one of: training rights on customer data, retention windows, sub-processors, processing locations, breach notification timelines, audit rights, deletion commitments, or default behaviours that the customer was relying on. A change is not material if it touches: formatting, section numbering, defined-term clarifications that do not change scope, or new features the customer is not using and that are not enabled by default. Material changes go to step 2. Non-material changes get logged with a one-line note and the date and the diff URL, and that is all.

Step 2: Map the change to documents on your side. For each material change, list which of your own documents the change touches. The map is short and the same every time. Training-rights changes touch the legal basis and the privacy notice. Retention changes touch the DPIA and the data minimisation record. Sub-processor changes touch the DPA annex, the processing register, and the transfer impact assessment if the new sub-processor processes outside the EU. Processing-location changes touch the transfer mechanism (SCCs, DPF) and the DPIA. Breach-notification or audit-rights changes touch the DPA and the incident response runbook. Default-behaviour changes touch whichever artefact you used to argue the default was set the other way.

Step 3: Decide accept, negotiate, or migrate. Most material changes get accepted because they are within your risk tolerance and the cost of objecting is higher than the benefit. Document the acceptance with the date, the reviewer, and the reasoning. The reasoning is the part that matters for an audit later. A small subset of changes get negotiated. Bargaining power is unevenly distributed. Enterprise customers with material spend can sometimes get a delayed activation, an alternative sub-processor, or an explicit carve-out. API customers usually cannot, but it costs nothing to ask once and the answer goes into the file. Migration is the nuclear option. For most AI workloads, migration is a multi-quarter project that you should treat as a fallback rather than a default. The trigger for migration is usually a change that breaks a regulatory requirement rather than one that just shifts a risk dial.

Step 4: Update the artefacts and tell the people who need to know. The same short list as step 2, in reverse. Update the DPIA, the processing register, the privacy notice, the DPA annex, the AI acceptable use policy, the vendor risk assessment, the engineering handbook page if there is one. Send a short, specific Slack message to the people whose work the change actually affects. Not "please review the updated terms" (nobody reads that). Specific: "Anthropic moved to a 5-year retention default for personal-tier accounts on 8 October 2025. Personal Claude Pro accounts on company laptops are out of policy until they migrate to Console with the team plan. The migration steps are in the runbook."

Before the next change

The three cases above will not be the last. There are at least four vendor-side moves I am watching for in the next twelve months and that I would build the watchlist around: a follow-on Anthropic update that extends the consumer-tier shift to commercial tiers (I do not think this is likely but it is the change that would matter most); an EU residency commitment from one or more major frontier providers, possibly tied to the EU AI Act's August 2026 obligations; further sub-processor list movement at OpenAI as the post-Mixpanel review concludes; and a default flip somewhere in the Microsoft, Google, or AWS Copilot stacks similar in shape to the 7 January 2026 Anthropic activation. Each of these would arrive as a different kind of artefact, which is itself the recurring pattern.

The watchlist is not a tool. It is a small set of habits.

Subscribe to the legal-update mailing list of every AI provider you use, not the marketing list.
Bookmark the sub-processor list pages for OpenAI, Anthropic, Google, Microsoft, AWS, and any other AI vendor in your processing chain. Diff them quarterly with a saved baseline.
Route admin-centre notifications (Microsoft 365 admin, Google Cloud console, AWS Health Dashboard) to a shared inbox or channel that more than one person watches. Default flips show up there before they show up in legal channels.
Read the privacy policy, not just the DPA. The privacy policy is where consumer-tier shifts and default-behaviour changes tend to live first.
Pin a quarterly review on the processing register that asks specifically: which sub-processors changed, which tiers shifted, which defaults moved.

The five-minute answer test. For every AI vendor in your processing chain, you should be able to answer four questions in under five minutes today: which tier are we on, which sub-processors are in scope (and on what date was that list current), which defaults are we relying on, and what is our objection mechanism if the next sub-processor change is unacceptable? If any answer takes longer than five minutes, the gap is in the documentation, not in the vendor. The work for this week is closing it before the next email arrives. The Anthropic, OpenAI, and Microsoft cases above all caught at least some teams without the answer ready.

Sources

Continue reading

AI PrivacyMar 5, 2026

Anthropic vs OpenAI vs Google: privacy policy comparison

What changed for the three providers in 2025-2026: Anthropic's August 2025 consumer shift, the October 2025 Google TPU sub-processor expansion, the Court of Rome OpenAI annulment, and the Latombe DPF appeal pending at the CJEU.

12 min read

AI PrivacyApr 9, 2026

When you call OpenAI, who actually processes your data? The AI sub-processor cascade

A trace-walk of one OpenAI API call through every entity in the cascade, with the Article 28, CLOUD Act, Article 48, and DMA layers stacked on top.

13 min read

AI PrivacyMar 3, 2026

OpenAI's data processing agreement: what it actually says

A clause-by-clause read of OpenAI's DPA in April 2026: what changed in the last 12 months, what still trips deployers, and the operational decisions that follow each clause.