GDPR for AI Inference

Why GDPR applies to inference

Prompts are rarely anonymous. Customer messages, support tickets, documents, code with credentials, medical or legal text - all routinely carry personal data, and the moment your application sends them to an inference API, GDPR governs that processing. You remain the controller (you decide why and how the data is used); the provider running the model is a processor acting on your instructions. GDPR's core duties follow: a lawful basis for the processing, data minimization, purpose limitation, and a written Data Processing Agreement under Article 28.

This is easy to overlook because an API call feels like a technical detail rather than a data transfer. But inference reads your actual production data on every request - it is one of the most sensitive data flows in a modern application, not a background utility. Where and by whom that processing happens is therefore a GDPR question, not just an engineering one.

GDPR compliance is not data sovereignty

The hard question for AI is not whether you can be GDPR-compliant, but what compliance actually buys you. Sending personal data to a provider outside the EU is an international transfer to a third country, which GDPR allows only with specific safeguards - Standard Contractual Clauses, or an adequacy decision such as the EU-US Data Privacy Framework. Those safeguards can make a transfer lawful. What they cannot do is make it sovereign: a US hyperscaler's European region can be fully GDPR-compliant and still leave your data reachable by US authorities. In Schrems II the EU's top court struck down the previous transfer framework for exactly this reason - US surveillance law (FISA Section 702, backed by the CLOUD Act) can compel a US-controlled provider to disclose data wherever it is stored, whatever the contract says.

So compliance and sovereignty are two different bars. GDPR compliance is about processing personal data lawfully - a lawful basis, a DPA, valid transfer safeguards - and a provider under almost any jurisdiction can meet it. Data sovereignty is stronger: that no foreign law can reach your data at all. What decides it is the provider's jurisdiction, not where the model was built - an open-weight model of any origin, served by an EU provider on EU infrastructure, is both compliant and sovereign, while the same model behind a US-controlled API can be compliant yet never sovereign. Residency, jurisdiction, and the DPA are the dimensions that, together, close that gap.

Compliant and sovereign at Infercom

On its EU-hosted models, Infercom gives you both. Your inference runs in the EU, under an EU operating entity with no US parent, with a signable Article 28 DPA and sub-processors listed in our Trust Center - so the inference layer is compliant and sovereign, not a standing exception you justify in an audit. It does not make you compliant on its own: a lawful basis, data minimization, and your own controller duties remain yours. And we are transparent about the edges, because sovereignty is something to verify, not take on trust - our catalog also offers a global tier of models routed outside the EU, clearly labelled non-sovereign in the portal so you can keep a workload EU-only when it must be, and some operational data is processed by a US sub-processor under Standard Contractual Clauses: lawful under GDPR, but a transfer nonetheless, which is why we name it in the DPA rather than hide it.

Related terms