When you call OpenAI, who actually processes your data? The AI sub-processor cascade

A user types into your application. Your backend constructs a prompt that includes the user's name and a support-ticket excerpt. Your code calls client.chat.completions.create(...). The SDK opens a TLS connection. A few hundred milliseconds later a response arrives, and the user sees a generated reply on their screen. From your point of view the call is one round trip.

That single round trip is actually a trace through at least four legal entities, three jurisdictions, two cross-border transfers, and a sub-processor cascade that has moved at least five times in the past eleven months. Your contract obligations apply to every waypoint in the trace, and the most useful way to understand them is to follow the call.

This piece walks one OpenAI API call as the protagonist. Each waypoint along the trace gets its own H2: who the entity is, what the controller-processor posture is at that point, and what the load-bearing legal question is. The mapping translates directly to Anthropic, Google, and any multi-cloud AI vendor, with the entities renamed but the structure intact.

If you want the contract layer specifically, read the OpenAI DPA breakdown. If you want the transfer-mechanism analysis, read the 2026 EU-US transfer state. What follows is the cascade-trace layer that connects them.

Waypoint 1: your application

The trace begins inside your code. You are the controller. Whichever entity in your company holds the customer relationship is the controller. The processing purpose, the legal basis, and the data minimisation decisions are yours.

The decision points at this waypoint:

• What goes in the prompt. Personal data fields included in the request body are personal data being processed by every downstream entity in the cascade. Strip what is not load-bearing for the model.
• What goes in the system prompt. User identifiers in the system prompt are personal data on every request, even when the user-facing prompt itself is generic.
• What gets logged. Your application probably writes the populated request to an observability tool. That tool is its own sub-processor relationship and has to be authorised separately. (See the audit-your-codebase walk for the surface-by-surface map.)

The waypoint posture: you are the controller, the next entity is your processor, and the rest of the cascade is sub-processor territory under Article 28. Everything that happens after this waypoint depends on the contract you signed with the next one.

Waypoint 2: OpenAI Ireland Limited

The TLS connection terminates at OpenAI's API gateway. For an EEA-facing customer in 2026, the contracting entity is OpenAI Ireland Limited. This was not always true; OpenAI restructured its EEA operations in early 2024 to put the Irish entity in front of EEA customer relationships, and the data-exporter status sits with OpenAI Ireland in the current DPA.

The posture at this waypoint:

• OpenAI Ireland is your data processor. The Article 28 contract is the OpenAI Data Processing Addendum, and the operative Annex names OpenAI Ireland as the contracting entity for EEA and Swiss data.
• The transfer to non-EEA entities happens here. When OpenAI Ireland passes the customer data to OpenAI Inc or OpenAI OpCo LLC in the US, the transfer rides on the 2021 Standard Contractual Clauses, Module Two (controller to processor), layered with the EU-US Data Privacy Framework adequacy decision.
• EU data residency is configured here. If you have enabled EU data residency for the API (announced 5 February 2025, expanded with in-region GPU inference on 16 January 2026), the call routes to a European inference cluster and the transfer at this waypoint is a much shorter analysis.

The load-bearing question at this waypoint is which version of the cascade applies to your call. With EU residency on, the trace stops at a European GPU and the next two waypoints disappear from the legal exposure analysis. With EU residency off, the call continues across the Atlantic.

Waypoint 3: OpenAI Inc (the US parent)

If EU residency is off, the call now crosses the Atlantic. OpenAI Ireland is the data exporter; OpenAI Inc (and its operating affiliate OpenAI OpCo LLC) is the data importer. This is the SCC Module Two transfer in action.

The posture at this waypoint:

• OpenAI Inc is a sub-processor of OpenAI Ireland for the inference workload. Both entities are bound by the same DPA. The intra-group transfer is documented inside OpenAI's published sub-processor list.
• The CLOUD Act layer activates here. OpenAI Inc is a US-incorporated entity. Under the US CLOUD Act, US authorities can compel a US provider to disclose data it controls regardless of where the data is physically stored. The relevance is that even if the data sits in Frankfurt, the US legal demand can reach the US entity in the chain.
• The Article 48 conflict activates here. GDPR Article 48 prohibits transfers or disclosures based on third-country judicial orders unless an international agreement exists. The CLOUD Act creates exactly the kind of obligation Article 48 prohibits. The conflict has not been resolved by litigation as of April 2026, and the practical posture is to document the awareness, document the mitigations, and not pretend the conflict does not exist.

The load-bearing question here is the legal-entity question, not the data-location question. Microsoft pledged that EU AI user data, including Copilot interactions, would be stored and processed in the EU by the end of 2025. The pledge is welcome and partial. Storage location is not the same as legal reach. A US-incorporated entity remains subject to US legal process even when the data sits in an EU region.

Waypoint 4: Microsoft Azure (the cloud sub-processor)

The OpenAI inference workload runs on cloud infrastructure that OpenAI does not own end-to-end. Microsoft Azure is the primary cloud sub-processor for OpenAI's API platform, under a long-running commercial relationship that has been public since 2019 and is documented in OpenAI's sub-processor list.

The posture at this waypoint:

• Microsoft is OpenAI's sub-processor for compute and storage at the inference layer. This is the most-cited entry on OpenAI's sub-processor list and the one that surfaces in most due-diligence checklists.
• The contracting Microsoft entity matters. "Microsoft Corporation" (US) and "Microsoft Ireland Operations Limited" (EU) are different legal entities with different controller postures. For EEA traffic the operative entity should be the EU one, but the parent relationship still carries the CLOUD Act layer.
• Azure has its own sub-processors below it. A Microsoft Azure sub-processor list documents the third parties Microsoft engages for support, maintenance, content delivery, and ancillary services. These appear at waypoint 5 below.

A trap many teams hit: the OpenAI API and the Azure OpenAI Service are two different products with two different contracts and two different cascades. Under the OpenAI API contract, OpenAI is your processor and Microsoft Azure appears in OpenAI's sub-processor list at this waypoint. Under the Azure OpenAI Service contract, Microsoft is your processor directly, OpenAI Inc is largely absent from the cascade (the model weights are licensed to Microsoft for the service), and the trace looks completely different. Read your invoice to know which cascade applies to your call.

Waypoint 5: the sub-sub-processor layer (CoreWeave, AWS, others)

Below the cloud sub-processor sits a layer most teams never read: the sub-sub-processors. A cloud provider does not always run every workload on infrastructure it owns. As of 2025-2026, three things changed at this layer that matter for an OpenAI cascade:

• OpenAI's CoreWeave commitment. OpenAI has expanded its commitments for CoreWeave compute capacity to roughly $22.4 billion across three contracts (initial $11.9B, $4B expansion, $6.5B September 2025 expansion through 2029). CoreWeave is a US-incorporated GPU specialist that operates inference workloads under sub-processor relationships with OpenAI and others.
• The OpenAI-AWS partnership (3 November 2025). OpenAI announced a seven-year, $38 billion partnership with AWS for hundreds of thousands of NVIDIA GPUs, with full capacity expected by 2026. This is a second cloud cascade for OpenAI alongside Azure, and the implication for your trace is that the entity at waypoint 5 may be AWS rather than Azure depending on which inference cluster handled your call.
• The Anthropic-Google Cloud TPU expansion (October 2025). For Anthropic specifically, the cascade now goes through both AWS Trainium and Google Cloud TPU. Both clouds appear in the Anthropic Trust Center sub-processor list, and a deployer cannot reasonably know in advance which TPU pool handled which call.

The posture at this waypoint:

• Sub-sub-processors are bound by their own DPAs with the layer above. Your contract is with OpenAI Ireland; OpenAI's contract is with Microsoft (and CoreWeave, and AWS); Microsoft's contract is with the next layer. Article 28(4) requires the processor to impose the same obligations on its sub-processors.
• The cascade can be three or four layers deep. Most provider DPAs only document the first level. Article 28(4) requires the chain, but practical visibility ends at the first level for most controllers.
• Each new layer is another CLOUD Act surface. Every US-incorporated entity in the chain adds CLOUD Act exposure. The chain length matters because the union of legal-process exposure is the union of all entities, not the bottom one alone.

Waypoint 6: the return path and the audit log

The model generates a completion. The response travels back through the cascade in reverse: GPU → cloud sub-processor → OpenAI Inc or Ireland → your application. From a trace point of view this is symmetric to the outbound path, but two things happen on the return that the outbound did not.

The provider-side log entry. OpenAI's default 30-day abuse-monitoring buffer captures the call (input plus output) on the way back. For most deployments this is configured as a 30-day retention. For Zero Data Retention customers (including any OpenAI API deployment with EU data residency enabled) the buffer is empty. (See the OpenAI DPA piece for the residency-equals-ZDR mechanic.)

Your audit log entry. Your application probably logs the request and response for debugging, observability, or compliance. That log is its own waypoint in the trace and its own sub-processor relationship. If the log lives in Datadog, Datadog is a sub-processor. If the log lives in Sentry with send_default_pii=True, Sentry is a sub-processor and is also capturing the prompt body unless OpenAIIntegration(include_prompts=False) is set. If the log lives in Langfuse, LangSmith, Helicone, or Phoenix, each tool has masking and PII redaction features that are off by default in the open-source tier. (See the logging-and-monitoring piece for the architectural fix.)

The posture at this waypoint:

• The audit log waypoint is invisible to the AI provider but visible to you. The provider's sub-processor list does not include your observability tools. Your sub-processor register has to.
• Log retention is the silent leak. The AI provider's ZDR setting is theatre if your observability stack keeps the prompt for 90 days. The CNIL Free + Free Mobile €42M decision (€27M Free Mobile, €15M Free, total €42M, 13 January 2026) is the precedent that this is an Article 5(1)(e) violation in its own right.
• The audit log waypoint is the one you control. Unlike the cloud sub-processor cascade, the observability stack waypoint is configurable in your own infrastructure. The fix is local.

The cascade movements of the last eleven months

Five cascade movements between May 2025 and March 2026 illustrate why this is not a one-time configuration question:

Each of these required a customer-side response within a contractual window. The Mixpanel case is the proof that the response window is real and short. The Microsoft 365 Copilot case is the proof that the cascade can grow a new layer overnight when a vendor adds a new model partner. The 26 March 2026 Anthropic update is the proof that the cascade can also grow conditional regulatory scope inside a single vendor relationship: ITAR coverage now depends on which sub-processor was routed to.

The legal layers stacked on the trace

Three legal layers are stacked on top of every waypoint in the cascade, and each one bites at a different point.

Article 28(2), the authorisation layer. The processor cannot engage another processor without prior specific or general written authorisation of the controller. Almost no AI vendor will sign specific authorisation; the practical reality is general authorisation with the right to object on changes. Without an objection right and without a process to use it, the authorisation is structurally broken. This bites at every waypoint where the cascade adds or replaces a sub-processor.

The CLOUD Act vs Article 48 conflict. The US CLOUD Act compels US providers to disclose data on demand from US authorities; GDPR Article 48 prohibits transfers or disclosures based on third-country judicial orders absent an international agreement. The conflict is unresolved as of April 2026 and there is no clean controller-side fix. The position regulators reject hardest is pretending the conflict does not exist. What survives audit is documented awareness, documented residual risk, and named mitigations (BYOK, data minimisation, EU-headquartered alternatives for the most sensitive workloads).

The DMA / Cloud and AI Development Act layer. On 18 November 2025, the EU Commission opened DMA market investigations into AWS and Microsoft cloud services. The proposed EU Cloud and AI Development Act is in the Commission's Q1 2026 work programme. Both signal that the regulator-side appetite for clarifying the cloud-cascade exposure is rising. Track them. The most likely 2026 outcome is new obligations on the cloud entities at waypoint 4, which propagate up the cascade to your contract surface.

Before the next provider notification

Three things to do this week, in order.

First, pick the AI vendor in your stack with the most active sub-processor cascade (almost certainly OpenAI or Anthropic) and trace one real call through every waypoint above. Write down the entity name at each waypoint. The exercise alone surfaces gaps in your existing register.

Second, confirm the change-notification feed for every active vendor is subscribed to a shared inbox a named owner monitors. The Mixpanel case is the proof that the notification window is short and that "let me check who is on the distribution list" is not a process. The objection window only protects you if someone is actively watching it.

Third, calendar the next two cascade events on the watch list: the EU Commission DMA cloud investigation outcome (sometime in 2026) and the EU Cloud and AI Development Act publication (Q1 2026 work programme). Both are upstream of your contract and both will trigger downstream changes.

Treat the trace as a quarterly review. The register is the artefact a regulator can ask for in an audit, and the only thing that turns "we use OpenAI" into a verifiable answer.