Mapping your AI processors: a per-path checklist

Your AI runs on Azure, AWS or GCP. That does not tell you who processes the data.

Companion to "Your AI runs on Azure, AWS or GCP". Engineering guidance, not legal advice.

The register that lists your cloud provider is not wrong, it is just answering a different question. This checklist works the other way round: start from each path a request can take, and establish who is actually in it. Run it per path, not per vendor, and run it again whenever a model, provider, hosting mode or route changes.

1. Enumerate the paths, not the vendors

A single approved vendor can host several data paths with different properties. List the paths first.

For each AI feature, write down every model it can reach, including fallbacks and secondary models an agent may select. Record how each model is consumed: the provider's own API, a cloud-managed API (Azure Foundry, Bedrock, Vertex), or self-deployed weights inside your own environment. Note which paths are chosen at runtime by a router or agent rather than fixed in configuration. Flag any path where the same model is available through more than one route, because they may not share a data flow.

2. Establish who is in the data flow

For each path, the model's publisher is not the answer. Confirm the actual parties.

Identify who operates the inference infrastructure for this path (the cloud, the model provider, or you). Confirm who can access the prompt and the output in normal operation. Determine whether the model publisher receives any customer content, only telemetry or usage data, or nothing at all. Check the contractual role of each party for the category of data on this path (controller, processor, sub-processor). For managed models, read the cloud's own statement of the data path rather than assuming it from the model name. On Azure Foundry, note whether the deployment is "Hosted on Azure" or "Hosted on Anthropic infrastructure", because the answer differs.

3. Pin down retention and residency

Residency and retention are per-endpoint and per-model settings, not properties of the cloud account.

Record the geographic endpoint each path uses, and whether a global or dynamically routed endpoint can move processing outside your chosen region. Confirm how long request data is retained on this path, and whether retention can be disabled. Check whether any model on the path requires retention or review, and what happens if you request zero retention (some platforms block the call rather than downgrade it). For open or self-deployed weights, confirm there is no telemetry, licensing callback or safety API quietly leaving your environment. Separate the model's country of origin from the destination of your production data. They are different questions and need different evidence.

4. Account for abuse monitoring and human review

Safety systems can move content to a party that never appears in the main data path.

Identify any automated safeguard or abuse-monitoring system on the path, and where flagged content can be sent. Confirm whether flagged content can reach a model provider's Trust and Safety function, or stays inside the cloud's own review boundary. Record who performs any human review and under what conditions it is triggered.

5. Follow the tools, agents and the dynamic graph

Once an agent invokes tools, the processing chain stops being a single call.

List every external service a path can invoke through tools, grounding, search, OCR or retrieval, and treat each as its own processor question. Confirm whether a router or agent can substitute a different provider or region at runtime, and whether that substitution is recorded. Establish whether personal data is removed before the request leaves your controlled environment, and whether that removal is evidenced per request. Decide, for each path, whether a non-compliant call could be stopped before the data left the boundary, not just detected afterwards.

6. Turn the answers into evidence, then keep them current

A one-time map ages the moment the architecture changes.

Capture, per request where it matters, which provider, endpoint, region and retention mode were actually used. Confirm you can answer "which model processed this record, through which endpoint, in which region, with which tools" for a specific past request. Set a trigger to re-run this checklist on any change to a model version, provider, hosting mode or routing rule, rather than on an annual cycle. Reconcile the live picture against your vendor register and DPIA, and update the documents where they have drifted from what runs.