The Multi-Model Chain Is a Legal Structure, Not Just an Architecture

When you build a fallback chain of AI models, you are not making a purely technical decision. You are making a series of legal decisions, one per model in the chain, that your privacy policy probably does not disclose, your data processing agreement schedule does not list, and your users have not consented to.

The architecture looks clean: if the primary model is unavailable or over capacity, the request falls through to the secondary, then the tertiary. The legal structure looks different: the same user data is being transferred to three distinct legal entities, each governed by a different national law, each operating under a different data retention policy, each subject to a different regime of government access requests.

Nobody in the AI space is talking about this.

The sub-processor chain

Under GDPR Article 28, a controller must engage processors under a binding contract (Article 28(3)) covering the subject-matter and duration, the nature and purpose, the type of personal data, the categories of data subjects, and the controller's obligations and rights. A processor may bring in a sub-processor only with the controller's prior written authorisation (Article 28(2)), and must impose the same data-protection obligations on it by contract, remaining fully liable to the controller (Article 28(4)). When your chain contains three model providers, each is a processor or sub-processor that the chain must bring under such a contract.Sources: GDPR Article 28

Most companies building on AI APIs have one DPA: with the provider they primarily use. Fallback providers are either not on the sub-processor list at all, or listed without a binding DPA in place. When a request falls through to the secondary model, the data transfer is technically unauthorised under GDPR.

This is not theoretical. Data protection authorities have issued substantial fines for disclosing personal data to recipients without a valid basis, or transferring it without adequate safeguards — Norway's NOK 65 million fine against Grindr for sharing data with advertising partners without valid consent, and the Dutch DPA's EUR 290 million fine against Uber for transferring driver data to the US without adequate safeguards under Article 44. The fact that the transfer was automated and the controller did not know it happened does not eliminate the liability. It may increase it.Sources: Grindr decision · Uber decision

The jurisdiction problem

Data residency and legal jurisdiction are not the same thing. A model provider can operate servers in Frankfurt while remaining subject to the laws of its country of incorporation. This distinction matters acutely when the chain includes providers incorporated in countries with extraterritorial data access laws.

Article 7 of China's National Intelligence Law (2017, amended 2018) provides that all organisations and citizens shall 'support, assist, and cooperate with national intelligence efforts in accordance with law' — a broad cooperation duty, albeit qualified by that 'in accordance with law' standard and the protections in Article 8. China's Personal Information Protection Law adds its own outbound-transfer regime (Articles 38-39). Both apply to companies incorporated in China regardless of where their servers are located.Sources: National Intelligence Law

There is no EU-China adequacy decision. A transfer of personal data from a European user to a Chinese AI provider — including via an API to a provider whose servers may sit in Europe but whose parent entity is Chinese — must rely on a GDPR Chapter V transfer tool, in practice standard contractual clauses backed by a transfer impact assessment and any necessary supplementary measures (explicit consent under Article 49 is only a narrow exception). Unlike EU-US transfers, the adequacy of these safeguards for China has not been adjudicated by the CJEU as it was in Schrems II, leaving exporters to assess Chinese surveillance law — including the National Intelligence Law — themselves.Sources: Schrems II (C-311/18) · EDPB Recommendations 01/2020

When your chain includes providers from multiple jurisdictions, each model hop is potentially a cross-border transfer. The user consented to using your platform. They did not consent to each individual transfer.

The retention cascade

Each provider in your chain has its own data retention policy. Even if all three claim not to train on API data, the retention windows for logging, abuse monitoring, and infrastructure purposes differ. A request that falls through to the tertiary model may be retained for a different period under a different policy than a request handled by the primary.

The practical problem is that you cannot audit this. You can read the privacy policy. You cannot inspect the actual retention infrastructure. When a user exercises their GDPR Article 17 right to erasure, you can delete the data from your systems and submit deletion requests to each provider. You cannot verify that those deletions were executed. You cannot produce evidence of compliance.Sources: GDPR Article 17

The disclosure gap

GDPR Articles 13(1)(e) and 14(1)(e) require controllers to inform data subjects, at the time of collection, of the recipients — or at least the categories of recipients — of their personal data. A sub-processor list that names your primary model provider but not your fallback providers is incomplete. When a fallback is triggered, you have transferred data to a processor not disclosed in the privacy notice.Sources: Article 13 · Article 14

This matters most when the fallback is silent: the user sends a query, the primary model is unavailable, the request is re-routed to the secondary, and the user receives a response with no indication that a different provider processed their data. Their reasonable expectation at the moment of submission was not met.

What the minimum viable compliance architecture looks like

The solution is not to eliminate fallback chains. Reliability engineering has legitimate reasons for them. The solution is to treat the legal structure of the chain with the same rigour as its technical structure.

That means: a signed DPA with every provider in the chain before any data is processed. A sub-processor list that reflects the actual chain, including fallbacks. A privacy notice that discloses the full set of potential processors, or at minimum the categories of processor by jurisdiction. A logging mechanism that records which provider handled each request, so erasure requests can be directed accurately. A transfer impact assessment for any provider subject to extraterritorial government access laws.

None of this is technically complex. The complexity is organisational: it requires treating the model selection layer as a legal interface, not just an infrastructure decision.

The gap that matters

The AI industry has invested heavily in explaining what models do. It has invested almost nothing in documenting where data goes when models are chained. The former is a model transparency problem. The latter is a data governance problem, and it is the one that will surface first in enforcement.

The chain that processes data is a legal structure. It should be designed as one.