What Is a Subprocessor?

When you buy an AI service, you’re rarely buying from just one company. Behind the vendor sits a chain of subcontractors who also process your data. Subprocessor is the name for that link – and it’s often where the real data protection questions hide, far from the logo on the invoice.

The Definition

A subprocessor is the data processor’s own vendor in the processing chain. You’re the data controller, your vendor is the processor, and the subcontractors the processor in turn engages to deliver the service are subprocessors.

The important thing is the principle: it’s the chain, not the brand, that decides where the data sits and which responsibility applies. Two services with the same logo on the outside can have completely different subprocessor chains – and therefore different jurisdiction and risk. Anyone who only looks at the vendor’s name sees only the top of the chain.

For you as the data controller, this isn’t a theoretical nicety. Responsibility for the entire chain ultimately rests with you: choose a vendor, and you’re indirectly choosing its subprocessors too. That shows up concretely in the record of processing activities, where every processing activity has to be traceable to where the data actually ends up, and in any audit, where you need to be able to account for the links – not just name your direct vendor. Understanding the subprocessor concept is therefore a prerequisite for documenting your AI services correctly.

The AI Examples That Make It Concrete

In the AI world, this becomes tangible quickly, since the models are often run via cloud platforms:

• Run Claude via AWS Bedrock, and AWS becomes the processor in that link while Anthropic becomes the subprocessor. The data passes through Amazon’s infrastructure, with Anthropic’s model further down the chain.
• Run OpenAI, and Microsoft Azure is the primary subcontractor. That means OpenAI data carries US exposure even when you’ve chosen EU storage – the subprocessor pulls in a jurisdiction that the storage choice doesn’t remove.

The point is that jurisdiction and exposure follow the chain. A scenario: a company chooses an AI service with a European profile and assumes the data stays in the EU. Mapping the subprocessors shows that one link in the chain sits in the US – and that the CLOUD Act is therefore relevant, despite the European surface.

The Buyer’s Rights in the DPA

Since the chain is decisive, you need to be able to see it. A proper data processing agreement (DPA) gives you three things:

1. A current subprocessor list – which subcontractors are included right now.
2. Notice of changes – word when the vendor adds or swaps a subprocessor.
3. The right to object – the ability to protest a new subprocessor you don’t accept.

If these rights are missing from the contract, that’s a red flag. Without them, you lose visibility into and control over the lower part of the chain – where a large share of the risk actually lives.

Multi-Model Platforms Create Several Chains

One last thing to keep track of: multi-model platforms. A service that provides access to models from several vendors creates several parallel subprocessor chains, each with its own jurisdiction.

It’s then not enough to map the platform as if it were a single vendor. Every model route has its own chain, and all of these need to go into the record of processing activities. An organization using several models therefore needs to document several chains in parallel.

How to Map the Chain

To get control over the subprocessors, here’s how to do it in practice:

1. Start from the data, not the logo. Follow the actual flow: where does the prompt go, which infrastructure processes it, which model answers? That route is what determines the jurisdiction.
2. Request the subprocessor list. Read it against the flow. Do the links you found match what the vendor discloses? If something’s missing, it’s worth a question.
3. Note the jurisdiction per link. Mark which links sit outside the EU and what exposure that brings, for example via the CLOUD Act.
4. Enter every chain into the record of processing activities. If you use several models or platforms, that means several chains – all of them need documenting, not just the most visible one.

Want to see how the subprocessor question connects to residency, transfer mechanisms, and government access across a full AI project? There’s more on our AI page. Need help mapping the subprocessor chains for your AI services? Get in touch.