“Open source is cheaper and more privacy-compliant” — I hear this sentence in nearly every initial consultation about adopting AI. It is seductive, often well-meant, and in this blanket form simply wrong. Bringing a language model into your company is neither a matter of faith nor an automatic cost-saver; it is a trade-off between control, true total cost, and compliance effort. The right answer depends on your data classification, your token volume, and your existing operational expertise — not on the “open source” label.
This guide gives you the decision framework, an honest cost calculation, and the legal assessment that most comparison articles leave out. Written from the dual perspective of a business lawyer and a developer — because the open-vs.-proprietary question is simultaneously an architecture question and a liability question. (As of April 2026. The model and licensing landscape changes monthly — treat figures as ranges and check licenses against the original text before deployment. This is general information, not legal advice.)
What is the difference between open-source and proprietary LLMs?
An open-source LLM (more precisely: an open-weight model) makes its trained weights publicly available — you can download it, run it yourself, adapt it, and usually use it commercially (e.g., Llama, Mistral, Qwen, Gemma, DeepSeek, gpt-oss). A proprietary LLM is “closed-weight”: you access it exclusively through an API (e.g., OpenAI GPT, Anthropic Claude, Google Gemini), and the weights never leave the provider. In short: open source means self-hostable, proprietary means usable only as a service.
Two honest clarifications up front that nearly every listicle skips:
- “Open source” ≠ free. You don’t pay per token, but you do pay for hardware, electricity, operations, and staff — often more than an API subscription would have cost.
- “Open source” ≠ automatically GDPR-compliant. Compliance arises from operations, contracts, and configuration, not from the label.
”Open-weight” is not the same as “open source”
This is where it gets legally subtle — and exactly where the most expensive misunderstandings lie. The fact that a model has open weights says nothing about its license. Meta’s Llama, for instance, is marketed by Meta as “open source,” yet runs under its own community license that the Open Source Initiative does not recognize as an open-source license — it contains usage and competition restrictions that no genuine open-source license has (more on that below). “Open,” then, describes access to the weights, not freedom of use.
The three decision axes — control, cost, compliance
Reduce the debate to three axes and it becomes decidable. The following matrix compares the three realistic operating models.
| Property | Open source (self-hosted / on-prem) | Open source (EU cloud, managed) | Proprietary API |
|---|---|---|---|
| Data control / hosting | Maximal — data never leaves the building | High — data stays with the EU host | Ends at the API boundary |
| Adaptability (fine-tuning) | Full, no provider permission needed | Full, depending on platform | Limited, provider-dependent |
| Model strength / maturity | Very good, often just below the top | Very good | Usually leading |
| Integration / support | Your own effort | Partly managed | Turnkey, broad SDKs |
| Vendor lock-in | Low | Medium | High |
| License / legal clarity | Check per model (can be tricky) | Check per model | Contractually clear, but third-country risk |
| Operational effort | High (DevOps, GPU, updates) | Medium | Minimal |
How to read it: there is no universally “better” column. If you process sensitive data and run consistently high load, you win on the left. If you want to start fast and have fluctuating or low load, you win on the right. Most companies end up in a hybrid architecture (see the decision guide below).
No single axis decides — you weigh control, cost, and compliance along your data classification, load, and operational expertise.
Control & data sovereignty — what open source really delivers
The strongest card of self-hosting is real: your data never leaves the building. That considerably simplifies the data-protection assessment, because there is no third-country transfer (Chapter V GDPR) and no US provider involved. But “simpler” does not mean “done.” Obligations remain even when you run it yourself:
- If you don’t operate physically on-prem but with a hosting provider, you need a data processing agreement (German: Auftragsverarbeitungsvertrag, Art. 28 GDPR).
- Data-flow, access, and logging documentation remain mandatory.
- Privacy by Design (Art. 25 GDPR) and a deletion concept apply regardless of the model.
With the proprietary API, your control ends at the interface. That is manageable — via a data processing agreement, zero-data-retention commitments, and an EU region — but it carries a residual risk, for example access by US authorities under the CLOUD Act with US providers. How far you need to go here depends on your data classification; the hosting and sovereignty question is explored in depth in our article on EU-hosted vs. US LLMs and data sovereignty.
What does a self-hosted LLM cost? The TCO and break-even reality check
This is where the “open source saves money” myth falls apart. With the API, you pay per token — variable, no fixed costs, ideal for fluctuating or low load. With self-hosting, you pay up front and on an ongoing basis: GPU hardware, electricity, and — the underestimated item — DevOps, maintenance, and updates.
The honest rule of thumb: GPU acquisition is often only about half of the total cost. Operations, staff, and downtime push the real cost (total cost of ownership) to a multiple of the pure hardware price.
The table below consolidates current break-even estimates from several 2026 TCO analyses — deliberately as ranges, because they depend heavily on model size, GPU utilization, and hourly labor cost.
| Scenario | Model / hardware (example) | Break-even vs. API (range) |
|---|---|---|
| Small model, single GPU | ~7B on an A10G-class card | roughly from ~0.5M tokens/day |
| Large model, single GPU | ~70B on A100 80 GB | roughly from ~2M tokens/day |
| Near-frontier, reserved cloud GPU | large open model | roughly ~2–5M tokens/day |
(Sources: SitePoint TCO analysis 2026, PromptCost 2026. Figures for orientation, not a fixed price — run the numbers against your real load before any investment.)
The decisive lever is utilization. If your GPU runs at only 10% load, the effective price per 1,000 tokens can rise by a factor of ten. Put differently: low or sporadic load → the API is usually cheaper. High, constant load plus sensitive data → self-hosting can pay off, and not only financially.
A worked example makes this tangible. A reserved A100 80 GB instance costs, depending on the provider, roughly €1.5–2.5 per hour — about €1,100–1,800 per month, fixed, whether you utilize it or not. Running 24/7 at a realistic throughput for a ~70B model, you land at a few million tokens per day. The same token volume via a mid-priced API can sit in a comparable or higher order of magnitude depending on the model and the input/output mix — but only if the GPU truly runs flat out. At 20% utilization the math flips immediately in favor of the API, because the fixed cost keeps running. That is precisely why the honest question is not “API or self-hosting?” but “Do I have the constant load to amortize the fixed cost?” (Prices April 2026, heavily provider- and region-dependent — recalculate with your real load and your specific model.)
GDPR Compliance of Open-Source LLMs — Obligations When Self-Hosting
In short: they can be operated in a GDPR-compliant way — but compliance arises from operations, contracts, and configuration, not from the “open source” label. A locally hosted model has structural advantages (no third-country transfer, full data sovereignty), but it does not release you from your obligations.
Checklist of obligations for self-hosting:
- Data processing agreement with the host (Art. 28), if not purely on-prem.
- Data protection impact assessment (German: Datenschutz-Folgenabschätzung, Art. 35) where there is high risk to data subjects.
- Privacy by Design & Default (Art. 25) — e.g., pseudonymization, data minimization in the prompt.
- Deletion concept and access control, including the handling of prompt and log data.
This is exactly where many comparisons go wrong: they sell “local = compliant” as a foregone conclusion. Legally sound implementation is detail work — we walk through it step by step in the guide GDPR-compliant AI in SMBs.
The licensing trap — may I use Llama, Mistral & co. commercially?
The most important and most frequently overlooked question. “Open” says nothing about your commercial rights. Check the license per model and per version. A dated overview (as of April 2026):
| Model | License (as of 04/2026) | Commercial use? | Watch out for |
|---|---|---|---|
| Llama (Meta) | Llama Community License | Yes, with terms | Not an OSI open-source license: special license required above >700M monthly users, mandatory “Built with Llama” attribution, competition/AUP clauses |
| Mistral (e.g., Small, Large) | mostly Apache 2.0 | Yes, very free | A few older/special models had their own licenses — check |
| Qwen (Alibaba) | Apache 2.0 (common versions) | Yes, very free | Check version-dependent |
| DeepSeek | MIT (common versions) | Yes, very free | Code and weights very permissive |
| Gemma (Google) | from Gemma 4: Apache 2.0 (OSI) | Yes | Earlier Gemma versions ran under Google’s own terms, not OSI |
| gpt-oss (OpenAI) | Apache 2.0 | Yes, very free | Also observe the OpenAI usage policy |
| Teuken-7B (OpenGPT-X) | Apache 2.0 (commercial version) | Yes | There are also research/CC-BY-NC variants — choose the right one |
The bottom line: the Llama license is precisely not a free open-source license — it contains a user cap and competition clauses that do not exist in Apache 2.0 or MIT. Anyone deploying Llama in production should know this; for most SMBs the 700M-user threshold is irrelevant, but the “Built with Llama” attribution requirement and the acceptable-use policy are not. Before deployment, always read the current license text of the specific model version. (License information researched April 2026, OSI assessment — licenses change, and this does not replace a case-by-case legal review.)
Vendor lock-in — does the proprietary API tie me down?
Yes, but in a nuanced way. Lock-in has several dimensions: prompt/tooling binding (your prompts and function calls are optimized for one model), data residency (where do embeddings and logs sit?), and price/model deprecation (the provider changes prices or shuts down a model). Open source is the exit option here: you can move the model to your own hardware at any time.
In practice, you mitigate lock-in by programming against an abstraction gateway rather than directly against a provider SDK — then a switch becomes a configuration question rather than a code question. We explore this strategy in depth in the article Avoiding vendor lock-in with AI.
Which open-source LLMs are enterprise-ready?
A dated overview (April 2026) — deliberately without a ranking, because rankings shift monthly:
- Llama (Meta): strong, broad ecosystem — but a license with terms (see above).
- Mistral: European provider, many models under Apache 2.0, good efficiency.
- Qwen (Alibaba): very capable, Apache 2.0, broad range of sizes.
- DeepSeek: strong reasoning models, MIT license.
- Gemma (Google): from Gemma 4 under Apache 2.0, well integrated into the Google ecosystem.
- gpt-oss (OpenAI): open weights from OpenAI under Apache 2.0.
- European options: Teuken-7B (OpenGPT-X/Fraunhofer, all 24 EU languages, Apache 2.0) and Aleph Alpha (Pharia line) — relevant when German-language quality and EU provenance are mandatory criteria.
For German-language use cases, three criteria matter more than the top benchmark spot: license clarity, German-language quality, and hardware requirements (a 7B model runs on a mid-range GPU, a 70B model needs considerably more).
The decision guide — which model for which case
Instead of a pros/cons list: five factors that together yield the recommendation.
- Data classification: public/non-critical, personally identifiable information (PII), or trade secret?
- Use case: standard task or core business with competitive relevance?
- Volume/token load: sporadic, medium, or high and constant?
- In-house operational expertise: is there a team that can take responsibility for GPUs and MLOps?
- Budget: willingness to spend CapEx vs. predictable OpEx?
From these emerge four typical recommendations:
- Proprietary API: low/fluctuating load, non-critical data, fast start, no MLOps team.
- Open source in EU cloud (managed): medium load, heightened data sensitivity, EU hosting desired, but no in-house GPU team.
- Open source on-prem: high constant load, trade secrets/strict sovereignty, existing operational expertise.
- Hybrid (the most common real-world case): non-critical requests via the API, business-critical ones via your own open-source model — orchestrated through a gateway acting as a data airlock.
If you take one thing away from this article: hybrid is usually the right answer. You combine the speed of the API with the control of self-hosting — and assign each use case to the appropriate side.
Compliance is more than GDPR — the AI Act angle
The choice of model also touches the EU AI Act. Two points are relevant to the open-vs.-proprietary question. First, the AI Act requires data governance and transparency — both of which you must document regardless of the model. Second, and this is rarely discussed: anyone who substantially modifies or further distributes an open model can themselves slip into a provider role with its own obligations. Exactly these obligations for providers of general-purpose AI models (GPAI) under Art. 53 of the AI Act have applied since 2 August 2025 — anyone who distributes a significantly altered open model can therefore potentially fall under them. Pure fine-tuning for internal use is usually uncritical; distributing a significantly altered model may not be. (As of April 2026; general assessment, not legal advice.)
FAQ
Is an open-source LLM free?
No. The license is often free of charge, but operating it is not. Hardware/GPU, electricity, and above all DevOps and maintenance make up the bulk of the total cost — GPU acquisition is frequently only about half. At low load, a proprietary API is usually cheaper.
Are open-source LLMs GDPR-compliant?
They can be. Compliance arises from operations, contracts (DPA), and configuration, not from the label. Self-hosting simplifies the assessment (no third-country transfer) but does not replace a data protection impact assessment, Privacy by Design, and a deletion concept.
Are open-source LLMs secure?
Security depends on operations, not on the license type. Self-hosting keeps data in-house but shifts full responsibility for patching, access control, and model risks (e.g., prompt injection) onto you. Proprietary providers take on part of that, but in exchange you give up control.
When is a self-hosted LLM worthwhile?
Rule of thumb: with high, constant load and/or hard data-residency requirements. 2026 TCO analyses cite break-even ranges from roughly 0.5M tokens/day (small model) up to 2–5M tokens/day (large/near-frontier models) — heavily dependent on utilization. Run the numbers against your real load before investing.
Can I switch from a proprietary to an open model later?
Yes — and that is exactly open source as an exit option. You make the switch easier if you work through an abstraction gateway from the start rather than directly against a provider SDK. Then the switch becomes a configuration question rather than a redevelopment one.
Conclusion & next step
Open vs. proprietary is not a matter of faith. Those with sensitive data and high constant load win with open source on-prem — those who want to start fast and have fluctuating load win with the API. Most companies are best served by going hybrid. What matters is making the choice along data classification, volume, and operational expertise — and clarifying both license and GDPR before deployment, not after.
This is exactly the architecture and compliance decision I make together with you — technically grounded and legally sound. More on that under Introducing LLMs into your company in a legally compliant way. For on-prem and sovereignty questions, it’s worth looking at data-sovereign AI.
Author: Leon Lotz, business lawyer & developer (about me). As of April 2026. This article is general information and not legal advice.
Sources — as of 04.04.2026
- Llama 4 Community License Agreement — https://www.llama.com/llama4/license/
- Open Source Guy: “Why Is the Llama License Not Open Source?” — https://shujisado.org/2025/01/27/why-is-the-llama-license-not-open-source/
- Open Source Guy: “Significant Risks in Using AI Models Governed by the Llama License” — https://shujisado.org/2025/01/27/significant-risks-in-using-ai-models-governed-by-the-llama-license/
- Google Open Source Blog: “Gemma 4 — Apache 2.0” — https://opensource.googleblog.com/2026/03/gemma-4-expanding-the-gemmaverse-with-apache-20.html
- OpenAI gpt-oss (Apache 2.0, open weights) — https://github.com/openai/gpt-oss
- Fraunhofer IAIS / OpenGPT-X: Teuken-7B (Apache 2.0, EU languages) — https://www.iais.fraunhofer.de/en/industries_and_cross-sector_solutions/cross-sector_solutions/generative-ai/opengpt-x.html
- SitePoint: “Local LLMs vs Cloud APIs — 2026 TCO Analysis” — https://www.sitepoint.com/local-llms-vs-cloud-api-cost-analysis-2026/
- PromptCost.org: “Local LLM Total Cost of Ownership 2026” — https://promptcost.org/en/blog/local-llms-total-cost-ownership-2026/
- all-about-security / it-daily: “LLM use in companies: 76% choose open source” (secondary source; the 76% figure traces back to the Databricks report “State of Data & AI” — verify against the primary survey before relying on it) — https://www.all-about-security.de/llm-nutzung-in-unternehmen-76-prozent-entscheiden-sich-fuer-open-source/
- EU AI Act, Art. 53 — obligations for providers of GPAI models (applicable since 02.08.2025) — https://artificialintelligenceact.eu/article/53/
Leon Lotz
Leon Lotz is a business lawyer and founder of MusketierSoftware. He combines legal depth with real software craft.
