Blog/Governance

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

1 September 20269 min readObstruo team
GovernanceProcessorsGDPR

The cloud you bought is an infrastructure boundary, not the whole processing chain. The same model can send your prompts to different parties depending on how it is hosted, routed and retained.

There is a sentence that comes up often in conversations about enterprise AI: "We are fine on data protection, everything runs on Azure." Sometimes it is AWS. Sometimes Google Cloud. The assumption is understandable. The organisation reviewed its cloud provider years ago, signed a DPA, ran a security assessment, selected European regions, and built its governance around that environment.

Then generative AI arrives, and the application inside that trusted cloud starts calling Claude, Gemini, Llama, Mistral, Qwen or DeepSeek. The old mental model quietly breaks, because the question is no longer "which cloud are we using" but "who can actually receive, process, retain or inspect the data inside each AI request." Those are not the same question, and the second one is the one an auditor will eventually ask.

The model provider is not always the processor

It would be convenient to say that if you use an Anthropic model, Anthropic processes your data. That is not universally true. The same model family can have materially different data flows depending on whether it is consumed through Microsoft Azure, Amazon Bedrock, Google Cloud Vertex AI, the model provider's own API, or from open weights inside your own infrastructure. From a GDPR perspective, that architecture is the point.

The European Data Protection Board recognises that a single processing activity can involve multiple processors: a controller may engage several processors directly, or one processor may engage sub-processors with the appropriate authorisation. So the presence of Microsoft, Amazon or Google in your vendor register does not tell you they are the only entities involved. You have to trace the actual path of the data, and that path looks surprisingly different across the three major clouds.

Azure: the infrastructure provider is not the whole chain

Claude on Microsoft Foundry is a clean example. Microsoft's Foundry data-privacy page states that for Claude models offered through Foundry, Anthropic is the seller and operator of the model and acts as an independent data processor for prompts and outputs. That holds for both hosting options Microsoft offers, and the difference between them matters.

With Hosted on Azure, request ingress, API services and GPU inference run on Azure infrastructure, and data at rest is stored in the selected Azure geography. Anthropic is still part of the relationship: automatic safeguards can flag content, and flagged content may in exceptional cases be sent to Anthropic's Trust and Safety team for review. With Hosted on Anthropic infrastructure, Microsoft is explicit that prompts and outputs are processed on infrastructure hosted by Anthropic, and the data may be processed outside your selected Azure region.

So a security questionnaire that answers "AI infrastructure provider: Microsoft Azure" can be technically correct and still incomplete. The infrastructure provider is not necessarily the entire processing chain.

AWS: the opposite assumption is also dangerous

Now turn the assumption around. Because Anthropic built Claude, it is tempting to assume a Claude call inside Amazon Bedrock must reach Anthropic. AWS describes a different architecture. Bedrock uses what it calls Model Deployment Accounts: model providers deliver their inference and training software to AWS, which makes a deep copy into deployment accounts operated by the Bedrock service team. AWS states that model providers have no access to those accounts, to Bedrock logs, or to customer prompts and completions. Same concept, a third-party foundation model. A very different data path.

Even here the cloud is not the end of the story, because Bedrock exposes explicit data-retention modes that interact with the specific model. One of them, provider_data_share, governs whether inference data may be shared with the model provider. It is not on by default: it has to be selected deliberately, and AWS has revised how it behaves over time, steering current configurations toward retention and any required review staying inside the AWS boundary rather than reaching the provider. Separately, if you configure zero data retention and then call a model that requires retention, AWS blocks the request rather than quietly downgrading your setting. The version details keep moving, and that is exactly the point: whether a provider can receive your prompts, and under which mode, is a per-account and per-model configuration question you have to check against the settings in force, not something the model's logo answers.

Google Cloud: why you have to think in deployment models

Vertex AI adds another layer, because Model Garden supports several fundamentally different ways to consume a model. You might use a Google-owned model such as Gemini, consume a partner model as a managed API, or deploy an open or partner model into your own environment. These should not be treated as equivalent for governance.

Google describes Claude on Vertex AI as fully managed, serverless models exposed through the Vertex AI API: your application calls a Vertex endpoint rather than an Anthropic one. And here the data path is counterintuitive. Anthropic's commercial terms for Claude on Vertex AI, the GA terms dated March 2024, state that the technology Anthropic provides to Google does not give Anthropic access to the customer's GCP instance, including the prompts or outputs within it. The same terms say Anthropic receives usage data that excludes Customer Content, and that it may not train models on Customer Content from the service. Using an Anthropic model, in this configuration, does not mean Anthropic receives the content of your prompt. Identifying processors by the model's publisher is simply the wrong instrument.

Model Garden also supports self-deployed models, open or partner, running inside your own Google Cloud project and VPC rather than as a serverless API. Picture an organisation that deploys the weights of a model built by Company X and runs inference entirely inside its own environment. Company X created the model and may license the weights, but unless there is a remote service, telemetry, licensing callback or safety API in the loop, Company X is simply not in the runtime path. The nationality of the company that produced the weights and the destination of your production data are two different questions.

Region choice adds a final wrinkle. For Claude on Vertex, Google supports regional, global and, for supported models, multi-region endpoints. A regional endpoint keeps processing inside a chosen region. A global endpoint does not: Google states plainly that it does not guarantee requests are processed in any specific location. So two calls can use the same cloud and the same model and carry different data-residency properties. Model: Claude. Cloud: GCP. Still not enough information. You also need the endpoint.

The same logic applies to Chinese models

Chinese foundation models are often discussed as a single category of risk. That is too simple, because there is a real difference between using a Chinese AI service directly and running weights from a Chinese lab inside infrastructure you control.

Take DeepSeek. Its privacy policy states that the service collects prompts, uploaded files, chat history and other input, and that it directly collects, processes and stores personal data in the People's Republic of China. For an EU organisation using the DeepSeek service directly, that belongs in the privacy and international-transfer assessment. But an organisation that takes open weights from a Chinese lab and serves them from a private endpoint in Frankfurt, Paris or Warsaw is in a different scenario entirely: inference runs on infrastructure it controls, and the model's authors have no API in the path and receive no prompts.

So "Chinese model equals data goes to China" is the wrong statement. The better one is: the model's origin is something we investigate, and the deployment architecture is what tells us where the data actually goes. The same principle applies to American, European and every other vendor.

It gets harder the moment you use more than one model

The interesting governance problem starts when an enterprise moves past a single provider, and most already have. One team uses Claude, another Gemini, a coding workflow something else, a retrieval system an embedding model. An agent might have a primary model, a cheaper fallback and a separate model for document classification. Then the agent calls search, search calls an external service, an OCR provider reads a document, a tool pulls a record from a CRM, and the result flows back into the model context.

At that point, "who is our AI processor" is close to the wrong question. There is a processing graph, and it can change from request to request. Traditional vendor governance assumes something static: pick a vendor, review it, sign a DPA, add it to a register, and leave the architecture alone until someone deliberately changes it. Agents break that assumption. A router can send a request to a different provider because the first was unavailable. A developer can repoint a logical model without touching the rest of the app. A cloud can add a deployment mode. A tool can be invoked only for certain requests. The processing chain becomes runtime-dependent, and a gap opens between the compliance document and the technical reality.

Your documentation may say "approved AI provider: AWS." The more useful audit question is: at 14:37 yesterday, which model processed this customer record, through which endpoint, in which region, under which retention mode, and which external tools were called. Those are very different levels of visibility.

What a serious AI review actually asks

A real review goes deeper than "which model are we using." For each path through the system it is worth knowing: who operates the inference infrastructure; who can access the prompt and the output; whether the publisher receives any customer content or only telemetry; what abuse-monitoring or Trust and Safety mechanisms exist; how long request data is retained and whether retention can be turned off; which geographic endpoint is used and whether global routing can move processing elsewhere; which additional services are pulled in by tools, grounding, search, OCR or retrieval; and which contractual role each party holds for the relevant category of data. And it is worth asking those questions again whenever the model version, provider, hosting mode or routing changes, not once a year. The companion checklist below turns this into something you can work through path by path.

"We use AWS" is an infrastructure answer, not a governance answer

The broader lesson is that AI has broken a useful shortcut. Historically, knowing the cloud told you a lot about the infrastructure boundary. With foundation models it does not. On Azure, a third-party model provider may act as an independent processor. On Bedrock, the provider may have no access to your prompts, unless a particular retention or review mode applies. On Google Cloud, a managed model has one data path and a self-deployed copy of a model has another, and a global endpoint has different residency properties from a regional one. A model created in China can be called directly in China or run privately inside an EU region. These are not edge cases. This is what modern multi-model architecture looks like.

Which is why AI governance has to move closer to runtime. A spreadsheet of approved vendors is still useful. A DPA is still necessary where it applies. A DPIA is still valuable. None of that goes away. But those artefacts describe what should happen, and organisations increasingly also need evidence of what did happen. Which provider was selected. Which endpoint was called. Which jurisdiction was used. Whether personal data was removed first. Whether a fallback fired. Whether an agent invoked another service. Whether the provider was approved for that category of data. Whether the request could have been stopped before the information left the controlled environment.

That is the problem we work on at Obstruo: moving some of these decisions out of documents and into the request path, so rules about models, providers, regions and sensitive data can be enforced and recorded while the AI system is running. Obstruo does not operate foundation models; customers bring their own upstream provider relationships and credentials. But the larger point is independent of any product. Enterprise AI governance cannot stop at knowing which cloud you bought. You need the complete data path, because the question that matters is no longer "where is our AI hosted." It is "for this particular request, who could access the data, where was it processed, and can we prove it." That is a harder question. It is also the one that counts.

This is an engineering perspective on mapping AI data flows, not legal advice. The processor and transfer analysis for your systems turns on facts specific to your architecture, your contracts and your role in each processing activity. Vendor documentation also changes; verify the current version for the models and regions you actually use.

Sources

Companion checklistMapping your AI processors: a per-path checklistOpen the checklist