Key Takeaways
- Architecture is compliance: Local open-weight LLMs eliminate GDPR Article 44 cross-border transfer risk by keeping data on EU hardware.
- Qwen 3.6 27B: Apache 2.0 licence, 92.1% HumanEval, runs on 16 GB VRAM — the highest-quality GDPR-compliant coding model as of May 2026.
- GDPR Articles 25, 32, 44: Local deployment satisfies data protection by design (Art. 25), appropriate technical measures (Art. 32), and eliminates cross-border transfer obligations (Art. 44).
- EU AI Act 2026: General-purpose AI providers (cloud) face new conformity assessments. Local open-weight deployments under 10^25 FLOP training compute fall outside the highest-risk tier.
- The counter-argument: Cloud providers offer SCCs, DPAs, and EU data residency options. These are valid legal tools, not substitutes for data residency by design.
The Manifesto
These principles reflect the position of PromptQuorum on AI architecture and EU data governance. They are intended as a starting point for organisational AI policies, not legal advice.
- 1Data that does not leave your infrastructure cannot be breached by third-party systems
Why it matters: Supply chain attacks on AI providers are an emerging risk category. Local LLMs eliminate the API layer as an attack surface. - 2GDPR compliance by architecture is stronger than GDPR compliance by contract
Why it matters: [Standard Contractual Clauses (SCCs) under GDPR Article 46](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:31995L0046#d1e1789) legitimize the transfer and create legal accountability between controller and recipient. Post-Schrems II, SCCs must be supplemented by a [Transfer Impact Assessment](https://edpb.europa.eu/our-work-tools/our-documents/recommendations/recommendations-012020-measures-supplement-transfer-tools_en) assessing whether the recipient jurisdiction provides protection equivalent to GDPR. Local deployment avoids the entire framework by preventing the transfer from occurring in the first place. - 3Open weights enable auditability that closed APIs cannot provide
Why it matters: EU AI Act Article 53 requires general-purpose AI providers to publish technical documentation. Open-weight models allow organisations to inspect model architecture, training data cards, and behaviour patterns independently. - 4Performance parity has arrived — local models no longer mean quality sacrifice
Why it matters: Qwen 3.6 27B (92.1% HumanEval, 77.2% SWE-bench) and Mistral Devstral Small 24B demonstrate that local open-weight models match frontier cloud performance on coding tasks as of May 2026. The quality argument for cloud exclusivity is no longer valid. - 5Data sovereignty is a competitive advantage for EU organisations
Why it matters: EU data protection standards are becoming the global baseline. Organisations with mature local AI infrastructure will face fewer regulatory transitions as international AI governance converges toward EU-style requirements. - 6Licence transparency is a prerequisite for responsible AI deployment
Why it matters: Apache 2.0 (most Qwen 3 models) grants irrevocable rights to use, modify, and distribute for any purpose. This contrasts with proprietary API terms of service that can change with 30 days' notice, creating unpredictable compliance risk. - 7Multi-model dispatch, not single-model lock-in, is the mature AI architecture
Why it matters: No single model optimises cost, quality, latency, and compliance simultaneously. Routing tasks by type — local open-weight for GDPR-sensitive data, cloud for non-sensitive scale tasks — is a documented practice in EU AI governance frameworks and reduces overall compliance surface area.
•Important: This manifesto does not argue that cloud AI is unusable in the EU. It argues that local open-weight models should be the default for data-sensitive tasks, with cloud APIs as an opt-in for tasks where GDPR obligations have been explicitly assessed and satisfied.
The Closed-Model Problem
Closed cloud AI models present a structural GDPR problem that contractual remedies cannot fully resolve. When you send a prompt to OpenAI, Anthropic, or Google, you transfer data to their servers. The model processes it. Logging, abuse detection, training data pipelines, and security monitoring may touch that data. Standard Contractual Clauses (SCCs) under GDPR Article 46 legitimize the transfer and create legal accountability between controller and recipient — but they do not prevent the data transfer from occurring.
The Court of Justice of the European Union (CJEU) Schrems II ruling (Case C-311/18) established that SCCs alone are insufficient for transfers to jurisdictions without protection equivalent to the GDPR. The ruling applies particularly to the United States, where surveillance legislation like FISA 702 permits government access without adequate safeguards. Following Schrems II, the EDPB Recommendations 01/2020 require organisations to conduct a Transfer Impact Assessment (TIA) before relying on SCCs, evaluating whether the recipient jurisdiction provides "essentially equivalent" protection. This compliance obligation has become standard practice for any organisation sending personal data to cloud AI providers.
In 2023–2024, several EU Data Protection Authorities issued guidance or enforcement actions related to cloud AI: the Italian Garante temporarily restricted ChatGPT access, the Polish UODO opened an inquiry into ChatGPT's training data handling, and the Hamburg DPA issued guidance requiring SCCs for AI API use. These cases signal that cloud AI GDPR compliance is actively scrutinised, not assumed.
Beyond regulatory risk, there is an economic argument: every prompt to a cloud API is a disclosure of your organisation's knowledge work to a third-party system. Code, client communications, internal documents, and product plans all have commercial value. The question is not only "is this legal?" but "is this wise?"
📍 In One Sentence
Closed cloud AI models create structural GDPR transfer obligations. Standard Contractual Clauses legitimize transfers and create accountability under Article 46, but must be supplemented by Transfer Impact Assessment post-Schrems II. Local deployment prevents the transfer entirely.
💬 In Plain Terms
When you type a prompt into a cloud AI tool, that text is sent to the provider's server in another country. Legal contracts (SCCs) mean you can hold the provider accountable if something goes wrong and create a legal basis for the transfer — but your data still travels there. After the Schrems II ruling, these contracts must be backed by a Transfer Impact Assessment confirming the recipient country provides equivalent privacy protection. Local LLMs mean the data never travels at all.
Why Open Weights Matter
Open-weight models publish the trained model parameters — the numerical values that define the model's behaviour. This distinguishes them from open-source models (which also publish training code) and closed APIs (which publish neither). The Qwen 3 family, Llama 3.3, and Mistral models are open-weight: anyone can download the parameters, run inference, fine-tune, and inspect the architecture.
Auditability is the first benefit. A CISO can verify that Qwen 3.6 27B runs the exact weights published by Alibaba Cloud (Tongyi Lab), inspect the architecture, and run adversarial testing on the local deployment. None of this is possible with a cloud API.
Reproducibility is the second benefit. Open-weight models do not change between API calls. When a cloud provider updates their model (GPT-4o has had multiple silent updates, Claude Sonnet has gone through multiple versions), your fine-tuned prompts, test suites, and expected outputs may break without notice. A local open-weight deployment is frozen at the version you chose.
Commercial freedom is the third benefit. Apache 2.0 grants perpetual, irrevocable rights to use Qwen 3 for any purpose. Proprietary API terms can change. Anthropic, OpenAI, and Google have all modified their usage policies, pricing, and model availability within 12-month windows. Open-weight Apache 2.0 models cannot be unilaterally withdrawn.
💡Tip: DeepSeek's model lineup evolves frequently. Verify the current model name and pricing at platform.deepseek.com before deployment. Figures reflect publicly available data as of May 2026.
Qwen Licence Landscape
Always verify the license on the specific model's Hugging Face page before production deployment. Licenses can change between model releases. This table reflects QwenLM's stated policy as of May 2026.
Licence terms determine whether a model can be used commercially, distributed, and fine-tuned. Review the relevant licence before deploying in production. Verify all licence information against the official Hugging Face model card.
| Qwen Model Family | Licence | Commercial Use |
|---|---|---|
| All Qwen 3.6 open-weight models | Apache 2.0 | ✅ Unrestricted |
| All Qwen 3.5 open-weight models | Apache 2.0 | ✅ Unrestricted |
| Older Qwen variants (pre-3.5) | Varies — check model card | ⚠️ Verify |
GDPR Article-by-Article Fit
The GDPR articles most directly relevant to AI deployment are examined below, with an assessment of local open-weight versus cloud API compliance posture.
📍 In One Sentence
Local LLM deployment satisfies GDPR Article 25 (data protection by design) and eliminates Article 44 (cross-border transfer) obligations because data never leaves EU-controlled infrastructure.
| GDPR Article | Local LLM Posture | Cloud API Posture |
|---|---|---|
| Art. 5 — Data Minimisation | ✅ Data never leaves infrastructure | ⚠️ Data transferred to provider — minimisation requires careful prompt design |
| Art. 25 — Data Protection by Design | ✅ Architecture prevents transfer by design | ⚠️ Requires contractual and technical controls to approximate design-level protection |
| Art. 32 — Technical Measures | ✅ Encryption at rest and in transit under organisation's direct control | ⚠️ Provider implements measures; organisation must verify and document |
| Art. 44 — Cross-Border Transfers | ✅ No transfer — Article 44 does not apply | ❌ Transfer occurs — requires adequacy decision, SCC, or BCR |
| Art. 28 — Processor Obligations | ✅ No processor in scope — organisation is sole controller | ⚠️ Provider is processor — Data Processing Agreement (DPA) required |
EU AI Act 2026
The EU AI Act (Regulation 2024/1689) came into force in phases through 2025–2026. As of May 2026, obligations for general-purpose AI (GPAI) providers are active under Article 53. The 10^25 FLOPs training compute threshold specifically identifies "systemic risk" GPAI models under Article 55, which face additional oversight requirements. This distinction is critical: all GPAI providers must comply with Article 53, but only systemic risk models face the full Article 55 burden.
Article 53 applies to all GPAI providers, requiring: technical documentation, copyright compliance disclosure, training data summaries, and instruction tuning logs. Article 55 applies specifically to models above 10^25 FLOPs, adding adversarial testing, incident reporting to the EU AI Office, and cybersecurity assessments. Frontier cloud models (GPT-4o, Claude Sonnet, Gemini) approach or exceed the systemic risk threshold. Open-weight models in the 7B–72B range remain below it.
Local deployment of open-weight models below the systemic risk threshold does not trigger GPAI provider obligations. Organisations deploying Qwen 3.6 27B locally are users, not providers, for EU AI Act purposes. They remain subject to the Act's user provisions (prohibited use cases, transparency to end users) but not the full GPAI provider compliance burden.
Practically, this means: cloud API providers face growing EU compliance overhead in 2026–2027 due to Article 53 and 55 obligations. Local open-weight deployments below the systemic risk threshold offer a structurally simpler compliance path as long as prohibited-use provisions are observed.
📌Note: The distinction between GPAI (Article 53) and systemic risk GPAI (Article 55, 10^25 FLOPs) is critical for compliance planning. Monitor the EU AI Office guidance for threshold updates and model classifications. As of May 2026, Qwen 3 models up to 72B fall well below the 10^25 FLOP systemic risk threshold. Frontier cloud models' exact training compute is typically not disclosed; estimates suggest they approach or exceed the threshold.
The Counter-Argument
The strongest counter-argument to local open-weight LLMs for EU compliance is: "Cloud providers offer EU data residency, SCCs, and detailed DPAs — these are legally valid and operationally simpler than managing on-premises inference infrastructure."
This is correct. Microsoft Azure, AWS, and Google Cloud all offer EU region deployments. Anthropic and OpenAI offer enterprise DPAs with EU SCCs. For many organisations, especially those without dedicated ML infrastructure teams, cloud AI with proper contractual safeguards is a legitimate and compliant choice.
The manifesto position is not "cloud is non-compliant" — it is "local open-weight is structurally simpler from a compliance perspective, and the quality gap is now small enough that the trade-off is worth taking." An organisation with 5 engineers and no GPU budget should use cloud AI with proper SCCs. An organisation with an infrastructure team, GDPR-sensitive data, and a 1,000-developer team handling client code has a strong case for local Qwen 3.6 27B.
The key variable is data sensitivity. For general-purpose tasks without personal data, cloud AI is operationally superior. For healthcare, legal, financial services, and any prompt containing personal data at scale, local open-weight LLMs represent the lowest-risk architecture.
FAQ
Does GDPR ban cloud AI for EU organisations?
No. GDPR does not ban cloud AI. It requires that cross-border data transfers have a legal basis (Article 44). Standard Contractual Clauses (SCCs) are the most common legal basis for EU organisations using US-based cloud AI APIs. Cloud AI is legally usable with appropriate SCCs, Data Processing Agreements (DPAs), and data minimisation practices. Local LLMs offer a structurally simpler compliance posture by eliminating the transfer entirely.
Is DeepSeek R2 compliant with GDPR for EU personal data?
Using DeepSeek R2 for EU personal data is high-risk from a GDPR perspective. DeepSeek AI operates from China. The EU Commission has not issued a China adequacy decision. Without an adequacy decision, international transfers require SCCs or Binding Corporate Rules (BCRs). DeepSeek does not currently offer EU-standard SCCs. Consult your DPO before using DeepSeek R2 for any personal data.
Does the EU AI Act apply to local Qwen deployment?
As of May 2026, deploying Qwen 3.6 27B locally makes you a user, not a provider, under the EU AI Act. GPAI provider obligations (Article 53 documentation, adversarial testing for systemic risk models) apply to the model creator (Alibaba) and to organisations that build products on the model and make it available to others. Internal deployment for your own organisation's use is covered only by the user provisions (prohibited use cases, end-user transparency where applicable).
Is Qwen 3.6 27B truly Apache 2.0 licensed?
Yes. Qwen 3.6 27B is released under Apache 2.0, which permits commercial use, modification, and redistribution without royalties. Verify each model's current license on its Hugging Face model card before deploying in production.
What is the EU AI Act's GPAI threshold?
The EU AI Act defines general-purpose AI models trained on more than 10^25 FLOPs compute as "systemic risk" GPAI models requiring additional oversight. Frontier models (GPT-4o, Claude 3.5 Sonnet, Gemini 1.5 Pro) cross this threshold. Open-weight models in the 7B–72B range, including Qwen 3.6 27B, are well below the threshold as of May 2026. The threshold applies to the training compute of the model itself — not to inference compute at your organisation.