Apple Foundation Models Goes Multi-Provider: The AI Compliance Trap

The most consequential developer announcement at WWDC 2026 was not a consumer feature. It was that Apple's Foundation Models framework became a multi-provider layer. With a new LanguageModel protocol, an app can route a request to Apple's on-device model, to Apple's Private Cloud Compute, to Google Gemini, or to Anthropic Claude, and switch between them by changing a Swift Package dependency rather than rewriting any code. That is a remarkable engineering convenience. It is also a compliance trap, because the thing you are casually swapping is who processes your users' data and where. This post explains what changed and the data-governance questions you need to answer before you ship.

What changed at WWDC 2026

Until now, the Foundation Models framework mostly meant Apple's own on-device model. At WWDC 2026 Apple turned it into a common interface. The new LanguageModel protocol is a public Swift API that model providers implement, so you can prototype against the on-device model and then route harder queries to Gemini or Claude without touching your session logic. Google confirmed Gemini integration through Firebase's Apple SDK, and Anthropic published its own Swift package implementing the protocol.

Apple also broadened the framework in other ways: multimodal image input, a Python SDK, and support for running on Linux. Developers in the App Store Small Business Program, with fewer than two million first-time downloads, can use the next generation of Apple's models on Private Cloud Compute at no cloud API cost. The framework ships built-in tools as well, including barcode and OCR readers and Spotlight-powered local retrieval.

The pitch is simple: one API, many models, pick the right tier for the job. The compliance reality is more involved.

The three tiers: on-device, Private Cloud Compute, and the open cloud

To reason about the compliance side you have to understand where a request can actually run. Apple's design has three tiers, and they are very different from a data-protection point of view.

On-device runs on the Neural Engine. Data never leaves the phone, which is the strongest possible privacy posture and the easiest to defend to a regulator.

Private Cloud Compute runs on Apple's stateless Apple Silicon servers for queries that are too heavy for the device. Apple says requests are anonymized, stripped of Apple ID linkage, and tokenized before transmission, and that they are never stored. This is still Apple processing, with Apple's privacy guarantees.

Cloud routing sends the heaviest queries to third-party infrastructure, for example Google Cloud for Gemini or Anthropic's stack for Claude. This is the tier where your users' data leaves Apple's environment entirely and is processed by another company.

The jump from tier two to tier three is the one that matters. On-device and Private Cloud Compute keep you inside Apple's privacy story. Routing to Gemini or Claude does not.

Why swapping providers is a compliance event, not just an API change

Here is the trap. Apple made it so easy to change providers that it feels like a configuration tweak. From a code perspective it is. From a legal perspective, changing which model serves your users changes your data processor, and that has consequences that a Swift Package update does not surface.

If user content flows to Anthropic or Google, those companies become processors of your users' personal data. That means you need the right data-processing terms in place, your privacy policy has to name them, and you have to know where the processing physically happens for data-residency purposes. The same prompt that was private on-device yesterday can be leaving for a third-party cloud today, simply because someone bumped a dependency. Nothing in the build will warn you that your disclosures are now out of date.

The EU AI Act and GDPR questions to answer first

Before you route anything off-device, work through these.

Disclosure. The EU AI Act expects transparency about AI-generated content and about the fact that a user is interacting with an AI system. If you add generative features, your users need to be told.

Processors and contracts. Under GDPR, every company that processes personal data on your behalf is a processor you are responsible for. If you enable Gemini or Claude routing, you need the data-processing terms and you need to list them.

Data location. Where does the heavy-query tier run, and does that match what you promise users and what your market requires? Cloud routing on third-party infrastructure can move data across borders.

Purpose and minimization. What user data actually goes into a prompt, and is all of it necessary? On-device processing makes this easy to defend. Sending the same data to an external model raises the bar.

Provenance. If your feature produces content that affects users, you need to be able to say what model produced it and on what basis, which gets harder when the provider can change without a code change.

A pre-ship checklist for AI features

Before you ship an AI feature built on Foundation Models, confirm the following. Decide which tier each feature uses, and treat on-device as the default unless you have a reason to leave it. Document what data goes into each prompt and why. If any feature routes to a third-party provider, put the data-processing terms in place and update your privacy policy to name that provider. Add the AI-interaction and AI-content disclosures the EU AI Act expects. And write down your data-location position for the cloud tier so you can answer a regulator or an enterprise customer without scrambling.

The deeper point is that AI features are now part of your supply chain, and your supply chain is exactly what compliance scanning is for. This is the same discipline we describe for third-party code in our guide to auditing third-party SDKs: you have to know what you ship, where data goes, and what each component does. A platform like AppCompliance can scan your app and flag where data flows and third-party processing are out of step with your declarations, so an AI feature that quietly started routing user prompts to an external cloud becomes an alert rather than a surprise in an audit. For the wider conference context, see our WWDC 2026 compliance preview, and for the EU regulation that frames a lot of this, our piece on the Cyber Resilience Act.

FAQ

What changed with Apple's Foundation Models at WWDC 2026?

Apple introduced a LanguageModel protocol that turns the Foundation Models framework into a multi-provider layer. An app can route requests to Apple's on-device model, to Private Cloud Compute, or to third-party models like Google Gemini and Anthropic Claude, and switch providers by changing a Swift Package dependency rather than rewriting code.

Can I really swap between Apple, Claude, and Gemini without code changes?

Largely yes, at the code level. Providers implement the same protocol, so you change a dependency rather than your session logic. But the swap changes who processes your users' data, which is a legal and compliance change even though it is not a code change.

Which tier is best for privacy?

On-device is strongest, because data never leaves the phone. Private Cloud Compute keeps processing within Apple's stated privacy guarantees. Routing to a third-party cloud like Gemini or Claude sends user data outside Apple's environment and makes that provider a processor you are responsible for.

What do I have to do under GDPR if I route to Gemini or Claude?

Treat the provider as a data processor: put the data-processing terms in place, name the provider in your privacy policy, and know where the processing physically happens for data-residency purposes.

What does the EU AI Act require for these features?

Transparency. You generally need to disclose that a user is interacting with an AI system and that content is AI-generated, and you should be able to explain what data feeds the model.

How do I keep this from drifting out of compliance?

Treat AI providers like any other part of your supply chain. Document the tier and data flow for each feature, keep disclosures and processor lists current, and use continuous scanning so a change in where user data goes is caught before it ships.