A subprocessor is a company your vendor uses to deliver its service, which means it is a company handling your data because of a decision you did not make.
You approved one vendor. That vendor approved five more. Those five have their own. The list is longer than it used to be, and at AI vendors it is growing faster than anywhere else in software.
Why the chain got longer
Legacy SaaS could plausibly run on its own infrastructure with a cloud provider underneath. An AI feature typically cannot.
A single assistant inside a product you already license routinely involves the model provider, the cloud that model runs on, a content moderation service, an analytics provider and security tooling. Five parties for one feature, most of them invisible from your side, none of them chosen by you.
None of that is improper. It is how the stack is assembled, and a vendor building all five in-house would be worse at four of them. The problem is not the existence of the chain. It is that your diligence stops at the first link while your data does not.
The notice window is the real issue
Well-drafted DPAs commit the vendor to publishing its subprocessor list, giving notice before adding to it, and providing a mechanism for you to object.
The mechanism has been hollowed out by the calendar. At most AI vendors the realistic notice window has compressed to somewhere between 14 and 30 days.
Consider what that asks of you. You receive notification that a new company will process your data. You have two to four weeks to assess an organisation you have never evaluated, form a view, and object, with objection typically meaning you may terminate. In practice nobody does this, and everybody knows nobody does this. The clause is satisfied and the diligence is theatre.
Negotiate the window if you have leverage. Thirty days is a floor worth holding, sixty is worth asking for, and a vendor that will not commit to publishing the list at all has told you something useful.
What to actually do about it
The realistic goal is not evaluating every subprocessor. You will not, and pretending otherwise produces a process that gets abandoned. The goal is knowing which links matter and noticing when they change.
- Get the list, dated. Save a copy rather than bookmarking the page. Vendors update these quietly and you want to be able to diff.
- Subscribe to the notification list. Most vendors offer one and it is not on by default. Route it to a shared inbox rather than one person, because the one person changes jobs.
- Care about two categories. Anyone processing content rather than metadata, and anyone in a jurisdiction that changes your transfer position. The analytics provider counting page views is not your risk. The model provider reading everything your staff type is.
- Check the model provider specifically. Frequently the most consequential name on the list, and frequently the one buyers assume is the vendor itself. A product with its own branded assistant may be routing to somebody else’s model entirely.
- Re-read after any acquisition. Your vendor being acquired can change its subprocessor chain wholesale, and the notice you get will be about the acquisition rather than about the data.
The version nobody catches
Everything above assumes a change you are told about. The harder case is the one that arrives as a product announcement.
A vendor ships an AI feature into a tool you have used for years. To deliver it they add a model provider. Your contract has not changed, your vendor list has not changed, and the number of companies processing your data has gone up. If the subprocessor page was updated, it was updated quietly, and the release notes described a feature rather than a data flow.
This is the same failure that runs through everything on this blog. Your records stayed accurate and the product moved. Watching vendor releases and changelogs for the ones that change data handling is what CopperFeed exists to record.
The broader checklist is in AI Vendor Due Diligence, and the training question in Does Your AI Vendor Train on Your Data.
Notice windows and subprocessor practices described here reflect published guidance at the time of writing and vary by vendor and contract. General guidance, not legal advice. Your own DPA governs.