How to Draw a Subprocessor Map for Your AI Service
A subprocessor map for AI shows the full chain of parties that process your data. It's harder than for regular SaaS because the path in determines the chain: the same model can have the model company as a direct processor or as a subprocessor reached via a hyperscaler. Chart the party, role, country, transfer mechanism, and retention for each link.
A subprocessor map charts the entire chain of parties allowed to touch your data – who, in what role, in what country. For a regular cloud service, that’s a fairly straightforward exercise. For AI, it’s trickier, for a reason that’s easy to miss: it’s the path into the model that determines what the chain looks like.
Why AI Breaks the Pattern
For a typical SaaS service, the provider publishes a list of its subprocessors and the matter is settled. AI works differently because the same model can be reached in several ways – and the way you reach it determines the roles.
If you have a direct contract with the model company, that company is your processor. If you reach the same model via a hyperscaler or reseller, the model company instead becomes a subprocessor further down the chain, and it’s the middle party that’s your processor. The model is the same, but the map looks completely different depending on which door you walked in through.
That’s why you can’t copy someone else’s map. Your chain depends on your contracts, not on the model’s name.
What Needs to Appear in the Map
The source material points to a few concrete chains that often come as a surprise and should be clearly documented:
- Microsoft Azure as OpenAI’s primary subcontractor. If you use OpenAI’s models, Azure is often part of the chain, even when you haven’t signed anything with Microsoft directly.
- Anthropic’s dependence on AWS and Google for the EU path. Claude in the EU rests on the hyperscalers’ infrastructure, which adds links to the map.
- Multi-model platforms’ parallel chains. An interface that routes between several model companies has several chains at once – one per model it can call.
If these links don’t appear, the map isn’t finished, no matter how polished it looks.
The Map’s Columns
A useful subprocessor map for AI has at least these fields:
| Column | What it captures |
|---|---|
| Party | Which company processes data at this link |
| Role | Processor or subprocessor |
| Country | Where the processing takes place |
| Transfer mechanism | The basis for any third-country transfer |
| Retention per link | How long data is kept at that specific link |
| On model swap | What changes if the model is replaced |
The last column is the one most often missing – and the most important in the long run. A model swap can silently replace the entire chain behind the service: new provider, new jurisdiction, new retention. Without that column, you only discover it at the next audit.
Where the Map Usually Breaks Down
Even people experienced at drawing these maps often miss the same things. Three recurring pitfalls:
- An interface is drawn as a single chain. A multi-model platform looks like one provider but can route your data to several model companies depending on the query. Every possible path is its own chain and needs to be shown.
- Stopping at the first-tier provider. The fact that your provider is based in the EU says nothing about where their subprocessors are. The chain is only mapped once you’ve followed it all the way down, not just to the first link.
- The map reflects the contract, not reality. A direct contract and a path via a hyperscaler produce different chains for the same model. Draw it based on how you actually reach the model, not how you think you do.
A useful check is to ask, for every link: “can I name the party, the country, and what happens to the data here?” If you can’t, the map isn’t finished, no matter how tidy it looks.
Upkeep: A Map That Stays Alive
A subprocessor map that’s drawn once and filed away is worthless within six months. Treat it as a living document:
- Subscribe to subprocessor notices from your providers, so a change in their subprocessors reaches you automatically.
- Version the map, so you can show what the chain looked like at a given point in time – often a question that comes up in an audit.
- Link the map to the DPIA, so a change in the chain triggers a review of the impact assessment instead of getting forgotten.
A small, concrete example: a provider announces that a new subprocessor in a third country has been added. If you have notices, versioning, and a DPIA link in place, it becomes a controlled update. If you don’t, an auditor discovers it, at the worst possible moment.
Mapping the chain correctly requires understanding both the contracts and the technology behind them. If you’d like help drawing and maintaining your subprocessor map, read about our AI services or get in touch with a description of which AI workflows you run today.
Frequently asked questions
Why is a subprocessor map harder for AI than for SaaS?
For regular SaaS, the chain is usually given by the provider. For AI, the path in determines which chain applies: the same model can have the model company as a direct processor if you have a direct contract, or as a subprocessor if you reach it via a hyperscaler or reseller. Same model, different maps.
Which parties need to appear in the AI map?
Every link that processes data. Examples from the source material: Microsoft Azure as OpenAI's primary subcontractor, Anthropic's dependence on AWS and Google for the EU path, and multi-model platforms' parallel chains, where several model companies sit behind the same interface.
What columns should the map have?
At minimum: party, role (processor or subprocessor), country, transfer mechanism, retention per link, and what happens if the model changes. That last column is easy to forget but crucial – a model swap can silently replace the entire chain behind the service.
How do we keep the map current?
Subscribe to your providers' subprocessor notices so you learn when subprocessors change, version the map so the history is preserved, and link it to your DPIA so a change in the chain triggers a review of the impact assessment.
What happens to the map when we switch models?
A model swap can change the entire chain: new provider, new jurisdiction, new subprocessors, and new retention. That's why the model-swap column matters – it forces you to redraw the link that's actually affected instead of assuming the map stands still.