Privacy and GDPR: What Local AI Changes

Using a cloud service for AI is not just a matter of convenience: for anyone processing personal or professional data, it is a question of legal obligations. The GDPR does not forbid sending data to the cloud, but it sets requirements that every extra-EU transfer must satisfy. Local AI changes the equation: no transfer, no foreign sub-processor, no dependence on contractual clauses. Here is what the regulation says, point by point.

The cloud problem, in GDPR terms

When you use ChatGPT, Claude, Gemini or similar, three things happen that carry obligations:

1. Transfer to a third country. Your data leaves the European Economic Area and goes to servers in countries without full and stable adequacy. The transfer is legitimate only if it rests on a legal basis: an adequacy decision (Art. 45), standard contractual clauses (SCCs), binding corporate rules (BCRs), or the Art. 49 derogations. For US services the basis in force is the EU-US Data Privacy Framework adequacy decision, approved in July 2023 after the Privacy Shield fell in Schrems II (C-311/18). A framework a court can overturn at any time: when that happened in 2020, ongoing transfers lost their legal basis overnight.
2. Processing of your data by the provider. Terms of service decide whether your prompts are stored, used to improve models, or not. The "off" settings exist, but they are contractual promises, not technical guarantees: you have no visibility and no control over what remains in logs, security systems or backups.
3. Sub-processing. The provider is a sub-processor (Art. 28) with obligations you should monitor: security measures, breach notification, deletion at the end of the contract. In practice, for most businesses, that monitoring does not exist.

What the GDPR says, and what changes with local AI

The articles that matter for the cloud vs local choice:

Article	Obligation	Cloud	Local
Art. 5(1)(c) — minimisation	Data adequate and limited to what is necessary	Every prompt carries more data than the provider can need: context, metadata, logs	The model only sees what you give it; the rest stays yours
Art. 25 — protection by design	Protection built into the design	You protect it by contract, not by architecture	The architecture itself does not expose data to third parties
Art. 28 — sub-processors	Contract and monitoring of the processor	Extra-EU sub-processor to supervise	No sub-processor: the model runs in-house
Art. 32 — security of processing	Adequate technical measures (incl. encryption)	Depends on the provider's measures	Yours: encryption, network, access — and air-gap if needed
Art. 44 — transfers to third countries	Valid legal basis for every extra-EU transfer	Requires adequacy or safeguards, re-reviewed after each ruling	No transfer: the article does not apply

The point is not that the cloud is illegal — it is legal, with the right documents. The point is that compliance is continuous work: DPIAs, a maintained records-of-processing register, sub-processor monitoring, re-review at the next transfer ruling. With local, that work shrinks to managing an in-house application, with a security perimeter you control.

The three benefits, stated precisely

No transfer, no legal basis to defend. This is the biggest technical-legal advantage: Art. 44 simply does not trigger. You no longer depend on adequacy decisions that EU courts have already overturned twice.

No sub-processor. No Art. 28 to negotiate, no clauses to update when the provider changes terms. The chain of responsibility is short: you, your machine, your data.

Control of the data lifecycle. Data does not end up in logs, does not go into the provider's backups, does not enter training (unless you decide otherwise). This matters most for data you cannot reveal: clinical records, contracts in negotiation, client documents.

The use cases where it truly makes a difference

Sector	Typical use	What it avoids
Law firms	Review and synthesis of contracts	Exposing client data to an extra-EU sub-processor
Healthcare	Analysis of clinical records	Transferring health data (Art. 9: special category)
Finance	Summarising client documents	Breach of confidentiality duties to clients
Press	Analysis of investigative documents	Risk that sources are exposed to third parties
Public sector	Assistants for citizens	Transferring citizens' data to third countries

None of these uses is forbidden in the cloud — but in each of them, the risk of a confidentiality breach, or a change in the provider's terms, carries a cost you cannot pass to the client.

And the limits? Honestly stated

Local AI is not a compliance declaration: the GDPR still applies to the processing, whether it happens in-house or in the cloud. The legal basis (Art. 6), the records of processing (Art. 30), the impact assessment (Art. 35) where required, and the security measures (Art. 32) remain owed. A local model that reads clinical records is still a processing of health data.

On top of that, local has two practical limits a DPO should know: open-weight models do not have the same quality as frontier models for complex tasks, and the responsibility for security measures stays yours — there is no provider to call in when something is lost, which makes technical measures even more important.

How to move, in practice

1. Inventory: which flows of personal data would AI touch, and where they end up today.
2. Classification: is the data sensitive (Art. 9) or professional? That goes local first.
3. Hardware: for the use cases above, 16–24 GB of VRAM or unified memory, an 8B–32B quantized model, and an interface are enough. The Hardware for Local AI guide sizes the machine by budget; Running LLMs Locally takes you from first install to a model that answers.
4. Documents: update the records of processing, do the DPIA where needed, define local security measures (access, encryption at rest, network).
5. Assess: for tasks a local model does not cover well, the cloud remains — but only there, with transfer documents in order.

In short

Local AI does not make the GDPR invisible: the obligations remain. What it does is remove the extra-EU transfer and the foreign sub-processor, the two most fragile points of cloud compliance. For anyone handling sensitive or professional data, it is the most direct way to shrink the risk perimeter to what you actually control.

Sources

• GDPR — Art. 5 (principles, including minimisation at 5(1)(c))
• GDPR — Art. 32 (security of processing)
• GDPR — Art. 44 (general principle on transfers to third countries)
• EDPB — Opinion 28/2024 on data-protection aspects of the development and deployment of AI models
• Court of Justice of the EU — Schrems II judgment (C-311/18)

Article generated with AI