Sub-processors in AI: what your DPA needs in 2026.

The new shape of an AI sub-processor stack

A typical document AI request, in production, touches:

1. Cloud infrastructure — compute, storage, networking, KMS (one or two providers)
2. At least one LLM provider — OpenAI, Anthropic, sometimes both for failover
3. An embedding/retrieval provider — sometimes the same as the LLM, sometimes specialized
4. An observability vendor — New Relic, Datadog, Grafana Cloud — receives logs, metrics, traces
5. A transactional comms vendor — Twilio, SendGrid, Postmark — for verification messages, webhook callbacks, email
6. A fraud or device-intelligence vendor — Fingerprint, Castle — increasingly common for KYC workflows
7. An edge / security vendor — Cloudflare, Akamai, Fastly — terminates TLS, runs the WAF
8. (Sometimes) a payment vendor — Stripe, Adyen, Mollie — when the product handles its own billing rails

That's eight categories. Most teams ship with five to seven of them active. Each one is a sub-processor under GDPR Art. 28(2) and a third party under CCPA §1798.140. Each one needs to be on the public list, in the DPA, and bound by terms equivalent to the controller-vendor contract.

The reality most teams underweight:

Observability is the leakiest category.

Logs, traces, and metrics ship freely into the observability vendor by default. Body scrubbing is opt-in. Almost every audit finding we've seen for AI startups in 2025 had observability as the source of an unintentional sub-processor escalation.

What changed in 2025–2026

A few specific developments make the 2026 sub-processor regime tighter than the 2023 one.

EDPB guidelines on AI processors

Early 2025 EDPB guidance clarified that LLM providers are sub-processors, not "tools," and that the controller's right to object to a sub-processor extends to a right to specific information about how the sub-processor processes data. "We use OpenAI" is no longer enough; the controller is entitled to know which API endpoint, with what retention configuration, under what model versioning regime.

Schrems III considerations

The EU-US Data Privacy Framework remains in place but has been challenged. Vendors processing EU data through US LLM providers cannot rely solely on the DPF; SCCs with a Transfer Impact Assessment are now table stakes.

The CCPA service-provider line

California's regulator has been increasingly literal about the difference between "service provider" (lawful, no consent needed) and "third party" (sale or share, consent triggers). Sub-processors that retain customer data for their own purposes — including model training — flip the vendor relationship from service provider to third party. The 2025 enforcement actions made this expensive.

Notification SLAs hardened

30-day customer notification has hardened from "nice to have" to regulatory expectation. Some major customers (financial institutions, healthcare) demand 60.

The net effect: looser sub-processor governance that worked in 2023 quietly creates audit findings, customer churn, and regulatory exposure in 2026.

The LLM provider problem

LLM providers are the highest-stakes sub-processors in an AI stack, and they're the ones most teams misconfigure. Three things matter.

Zero-retention vs default-retention APIs

OpenAI and Anthropic both offer zero-retention modes for enterprise customers — data is processed in-memory, never persisted, never used for training. The default is not zero-retention. If your account isn't explicitly configured this way, your sub-processor is doing additional processing — retention, evaluation, sometimes training — that isn't in your DPA.

Model versioning

Both providers update models over time. From a DPA perspective, "GPT-4" is not one sub-processor decision; it's an ongoing series of decisions. Mature setups pin model versions in production and treat upgrades as deliberate sub-processor changes, with notification.

The "Enterprise" tier matters

OpenAI's API has different terms for ChatGPT (training opt-in by default) vs the Enterprise API (training opt-out by default) vs the Enterprise account-level settings (more granular controls). Anthropic has parallel tiers. The DPA the LLM provider signs depends on which tier the AI vendor uses. Customers asking "do you train on my data?" need a clear answer that traces from your DPA, through your LLM provider's terms, to the actual API configuration in production.

If you can't trace this in 60 seconds, you've underspecified the LLM relationship.

Observability vendors are sub-processors

This is the surprise category. Logs, metrics, and traces from your application contain customer data unless you actively scrub them. The observability vendor receives, indexes, retains, and (sometimes) trains on this data. They are unambiguously sub-processors.

Most DPAs miss this. The fix is mechanical:

• List the observability vendor explicitly in your sub-processor list
• Configure log scrubbing at the application boundary (before egress)
• Disable any "service improvement" or training settings at the observability vendor account level
• Document the scrubbing as a control — auditors will want to see the configuration

In 2026, "we use Datadog" without scrubbing is an audit finding waiting to happen.

The customer notification SLA

Adding or replacing a sub-processor isn't ad-hoc anymore. The mechanism the regulator expects:

1. Public sub-processor list — versioned, with current and historical state visible
2. Customer notification mailing list — opt-in, but expected to be opt-in by default for enterprise contracts
3. 30-day notice before the sub-processor goes live for customer data
4. Right to object — the customer can object; if they do, the processor either provides an alternative or the customer can terminate

This is implementable. Most teams under-build it because they don't change sub-processors often. The trap: when the change comes — typically in a hurry, often pressured — the lack of mechanism becomes a one-week scramble. Build it once.

Right to object — and what happens then

Few customers exercise the right to object. But the architecture has to support it. If a customer says "we object to your use of OpenAI; we want Anthropic only" — what happens?

For a serious AI vendor:

• Per-tenant LLM provider routing — the same workflow can run against either provider, configured per tenant
• No-LLM workflows — for the most paranoid customers, a fully deterministic extraction path that doesn't call any external LLM
• Documented termination process — if neither alternative works, the processor honors the contract's exit terms

For a vendor without these in place: an objection becomes an existential customer-loss event. Build the optionality early; it's cheaper than a custom enterprise contract negotiated under pressure.

What your DPA needs to say

A 2026 AI sub-processor DPA needs to explicitly cover:

1. Categories of sub-processors with named examples and their roles (the public list is the canonical source)
2. Notification mechanism — list URL, mailing list, SLA
3. Specific LLM provider terms — provider, API tier, retention configuration, training opt-out
4. Observability scrubbing — vendor names, what's scrubbed, where the scrubbing happens
5. Right to object with concrete alternative options
6. Cross-border transfer mechanism — SCCs, module identification, TIA reference
7. Audit substitute — most customers can't audit sub-processors directly; the vendor's SOC 2 / ISO 27001 / equivalent serves as the audit artifact
8. Termination triggers — the conditions under which a sub-processor change creates a unilateral termination right for the customer

DPAs that omit any of these create either (a) audit findings or (b) the inability to onboard enterprise customers who pressure-test the contract. Both are expensive.

The bare-minimum sub-processor list (annotated)

For reference, the fluex sub-processor list currently contains seven entries:

The annotation rule: every entry needs to be defensible under questioning. "We use them" isn't enough. "We use them for X, configured Y, under DPA terms Z" is the bar.

Closing thought

Sub-processor governance is the slow-moving boundary that determines what AI vendors can and can't sell to. Get it wrong in 2026 and you discover it during enterprise procurement — three months too late, with a deal slipping. Get it right and you compound a procurement advantage that gets harder for competitors to catch up to.

The seven-vendor stack above isn't a maximum, it's a typical. Some workflows need fewer; some need more. What matters isn't the count — it's that every entry has a documented purpose, a current DPA, a transfer mechanism, and a position on the customer's right to object. That's the bar in 2026.

For the fluex DPA template, our standard sub-processor terms, and our 30-day notification mailing list, see our trust page or email legal@fluex.com.