„Open Source ist günstiger und datenschutzkonformer” — diesen Satz höre ich in fast jedem Erstgespräch zur KI-Einführung. Er ist verführerisch, oft gut gemeint und in dieser Pauschalität schlicht falsch. Wer ein Sprachmodell ins Unternehmen holt, trifft keine Glaubensfrage und keinen Spar-Automatismus, sondern eine Abwägung aus Kontrolle, echten Gesamtkosten und Compliance-Aufwand. Die richtige Antwort hängt von Ihrer Datenklasse, Ihrem Token-Volumen und Ihrer vorhandenen Betriebskompetenz ab — nicht vom Label „Open Source”.
Dieser Leitfaden gibt Ihnen das Entscheidungs-Framework, eine ehrliche Kosten-Rechnung und die juristische Einordnung, die in den meisten Vergleichsartikeln fehlt. Geschrieben aus der Doppelperspektive Wirtschaftsjurist und Entwickler — weil die Open-vs.-proprietär-Frage gleichzeitig eine Architektur- und eine Haftungsfrage ist. (Stand: April 2026. Die Modell- und Lizenzlandschaft ändert sich monatlich — Zahlen als Bandbreiten, Lizenzen vor Einsatz gegen den Originaltext prüfen. Dies ist allgemeine Information, keine Rechtsberatung im Einzelfall.)
Was ist der Unterschied zwischen Open-Source- und proprietären LLMs?
Ein Open-Source-LLM (präziser: Open-Weight-Modell) stellt seine trainierten Gewichte öffentlich bereit — Sie können es herunterladen, selbst betreiben, anpassen und in der Regel kommerziell nutzen (z. B. Llama, Mistral, Qwen, Gemma, DeepSeek, gpt-oss). Ein proprietäres LLM ist „closed-weight”: Sie greifen ausschließlich über eine API darauf zu (z. B. OpenAI GPT, Anthropic Claude, Google Gemini), die Gewichte verlassen den Anbieter nie. Kurz: Open Source heißt self-hostbar, proprietär heißt nur als Dienst nutzbar.
Zwei ehrliche Klarstellungen vorweg, die fast jeder Listicle überspringt:
- „Open Source” ≠ kostenlos. Sie zahlen nicht pro Token, aber für Hardware, Strom, Betrieb und Personal — oft mehr, als ein API-Abo gekostet hätte.
- „Open Source” ≠ automatisch DSGVO-konform. Konformität entsteht aus Betrieb, Vertrag und Konfiguration, nicht aus dem Label.
„Open-Weight” ist nicht dasselbe wie „Open Source”
Hier wird es juristisch fein — und genau hier liegen die teuersten Missverständnisse. Dass ein Modell offene Gewichte hat, sagt nichts über die Lizenz. Metas Llama etwa wird von Meta als „open source” beworben, läuft aber unter einer eigenen Community-Lizenz, die die Open Source Initiative nicht als Open-Source-Lizenz anerkennt — sie enthält Nutzungs- und Wettbewerbsbeschränkungen, die es in keiner echten Open-Source-Lizenz gibt (dazu unten mehr). „Offen” beschreibt also den Zugang zu den Gewichten, nicht die Freiheit der Nutzung.
Die drei Entscheidungsachsen — Kontrolle, Kosten, Compliance
Reduzieren Sie die Debatte auf drei Achsen, dann wird sie entscheidbar. Die folgende Matrix vergleicht die drei realistischen Betriebsmodelle.
| Eigenschaft | Open Source (self-hosted / on-prem) | Open Source (EU-Cloud, managed) | Proprietäre API |
|---|---|---|---|
| Datenkontrolle / Hosting | Maximal — Daten verlassen das Haus nicht | Hoch — Daten bleiben beim EU-Hoster | Endet an der API-Grenze |
| Anpassbarkeit (Fine-Tuning) | Voll, ohne Anbieter-Erlaubnis | Voll, je nach Plattform | Eingeschränkt, anbieterabhängig |
| Modellstärke / Reife | Sehr gut, oft knapp unter Spitze | Sehr gut | In der Regel führend |
| Integration / Support | Eigenleistung | Teilweise Managed | Schlüsselfertig, breite SDKs |
| Vendor-Lock-in | Gering | Mittel | Hoch |
| Lizenz-/Rechtsklarheit | Pro Modell prüfen (kann tückisch sein) | Pro Modell prüfen | Vertraglich klar, aber Drittland-Risiko |
| Betriebsaufwand | Hoch (DevOps, GPU, Updates) | Mittel | Minimal |
Lesart: Es gibt keine universell „bessere” Spalte. Wer sensible Daten verarbeitet und Last konstant hoch fährt, gewinnt links. Wer schnell starten will und schwankende oder geringe Last hat, gewinnt rechts. Die meisten Unternehmen landen am Ende in einer Hybrid-Architektur (siehe Entscheidungs-Leitfaden unten).
Keine Achse für sich entscheidet — Kontrolle, Kosten und Compliance gewichten Sie entlang Ihrer Datenklasse, Last und Betriebskompetenz.
Kontrolle & Datenhoheit — was Open Source wirklich bringt
Der stärkste Trumpf von Self-Hosting ist real: Ihre Daten verlassen das Haus nicht. Das vereinfacht die datenschutzrechtliche Beurteilung erheblich, weil kein Drittlandtransfer (Kapitel V DSGVO) und kein US-Anbieter im Spiel ist. Aber „einfacher” heißt nicht „erledigt”. Auch beim Selbstbetrieb bleiben Pflichten:
- Betreiben Sie nicht physisch on-prem, sondern bei einem Hoster, brauchen Sie einen Auftragsverarbeitungsvertrag (Art. 28 DSGVO).
- Datenfluss-, Zugriffs- und Logging-Dokumentation bleiben Pflicht.
- Privacy by Design (Art. 25 DSGVO) und ein Löschkonzept gelten unabhängig vom Modell.
Bei der proprietären API endet Ihre Kontrolle an der Schnittstelle. Das ist absicherbar — über AVV, Zero-Data-Retention-Zusagen und EU-Region — bleibt aber mit einem Restrisiko behaftet, etwa dem Zugriff durch US-Behörden nach dem CLOUD Act bei US-Anbietern. Wie tief Sie hier gehen müssen, hängt von Ihrer Datenklasse ab; die Hosting- und Souveränitätsfrage vertieft unser Beitrag zu EU-gehosteter vs. US-LLM und Datensouveränität.
Was kostet ein selbst gehostetes LLM? Der TCO- und Break-even-Realitätscheck
Hier zerbricht der „Open Source spart”-Mythos. Bei der API zahlen Sie pro Token — variabel, ohne Fixkosten, ideal bei schwankender oder geringer Last. Beim Self-Hosting zahlen Sie vorab und laufend: GPU-Hardware, Strom, und — der unterschätzte Posten — DevOps, Wartung und Updates.
Die ehrliche Faustregel: Die GPU-Anschaffung ist oft nur etwa die Hälfte der Gesamtkosten. Betrieb, Personal und Ausfallzeiten treiben die echten Kosten (Total Cost of Ownership) auf ein Vielfaches des reinen Hardware-Preises.
Die folgende Tabelle bündelt aktuelle Break-even-Schätzungen aus mehreren TCO-Analysen 2026 — bewusst als Spannen, weil sie stark von Modellgröße, GPU-Auslastung und Stundenlohn abhängen.
| Szenario | Modell / Hardware (Beispiel) | Break-even ggü. API (Bandbreite) |
|---|---|---|
| Kleines Modell, eine GPU | ~7B auf einer A10G-Klasse | grob ab ~0,5 Mio. Token/Tag |
| Großes Modell, eine GPU | ~70B auf A100 80 GB | grob ab ~2 Mio. Token/Tag |
| Frontier-nah, reservierte Cloud-GPU | großes Open-Modell | grob ~2–5 Mio. Token/Tag |
(Quellen: SitePoint TCO-Analyse 2026, PromptCost 2026. Zahlen als Orientierung, kein Festpreis — vor einer Investition mit Ihrer realen Last durchrechnen.)
Der entscheidende Hebel ist die Auslastung. Läuft Ihre GPU nur bei 10 % Last, kann der effektive Preis pro 1.000 Token um den Faktor zehn steigen. Anders gesagt: Niedrige oder sporadische Last → die API ist meist günstiger. Hohe, konstante Last plus sensible Daten → Self-Hosting kann sich rechnen, und zwar nicht nur finanziell.
Ein Rechenbeispiel macht das greifbar. Eine reservierte A100-80-GB-Instanz kostet je nach Anbieter grob 1,5–2,5 €/Stunde, also rund 1.100–1.800 €/Monat — fix, egal ob Sie sie auslasten. Bei 24/7-Betrieb und realistischem Durchsatz eines ~70B-Modells landen Sie bei einigen Millionen Token pro Tag. Dieselbe Tokenmenge über eine mittelpreisige API kann je nach Modell und In-/Output-Mix in einer vergleichbaren oder höheren Größenordnung liegen — aber nur, wenn die GPU wirklich durchläuft. Bei 20 % Auslastung kippt die Rechnung sofort zugunsten der API, weil die Fixkosten weiterlaufen. Genau deshalb ist die ehrliche Frage nicht „API oder Self-Hosting?”, sondern „Habe ich die konstante Last, um die Fixkosten zu amortisieren?”. (Preise April 2026, stark anbieter- und regionsabhängig — mit Ihrer realen Last und Ihrem konkreten Modell nachrechnen.)
DSGVO-Konformität von Open-Source-LLMs — Pflichten beim Self-Hosting
Kurz: Sie können DSGVO-konform betrieben werden — aber Konformität entsteht aus Betrieb, Vertrag und Konfiguration, nicht aus dem Label „Open Source”. Ein lokal gehostetes Modell hat strukturelle Vorteile (kein Drittlandtransfer, volle Datenhoheit), entbindet Sie aber nicht von den Pflichten.
Pflichtenkatalog beim Self-Hosting:
- AVV mit dem Hoster (Art. 28), falls nicht rein on-prem.
- Datenschutz-Folgenabschätzung (Art. 35) bei hohem Risiko für Betroffene.
- Privacy by Design & Default (Art. 25) — z. B. Pseudonymisierung, Datensparsamkeit im Prompt.
- Löschkonzept und Zugriffskontrolle, inklusive Umgang mit Prompt-/Log-Daten.
Genau hier liegt der Denkfehler vieler Vergleiche: Sie verkaufen „lokal = konform” als Selbstläufer. Die rechtssichere Umsetzung ist Detailarbeit — wir gehen sie im Leitfaden DSGVO-konforme KI im Mittelstand Schritt für Schritt durch.
Lizenzfalle — darf ich Llama, Mistral & Co. kommerziell nutzen?
Die wichtigste und am häufigsten übersehene Frage. „Open” sagt nichts über Ihre kommerziellen Rechte. Prüfen Sie die Lizenz pro Modell und pro Version. Ein datierter Überblick (Stand April 2026):
| Modell | Lizenz (Stand 04/2026) | Kommerziell nutzbar? | Achtung |
|---|---|---|---|
| Llama (Meta) | Llama Community License | Ja, mit Auflagen | Keine OSI-Open-Source-Lizenz: Sonderlizenz nötig ab >700 Mio. monatl. Nutzer, „Built with Llama”-Pflicht, Wettbewerbs-/AUP-Klauseln |
| Mistral (z. B. Small, Large) | überwiegend Apache 2.0 | Ja, sehr frei | Einzelne ältere/spezielle Modelle hatten eigene Lizenzen — prüfen |
| Qwen (Alibaba) | Apache 2.0 (gängige Versionen) | Ja, sehr frei | Versionsabhängig prüfen |
| DeepSeek | MIT (gängige Versionen) | Ja, sehr frei | Code und Gewichte sehr permissiv |
| Gemma (Google) | ab Gemma 4: Apache 2.0 (OSI) | Ja | Frühere Gemma-Versionen liefen unter eigenen Google-Terms, nicht OSI |
| gpt-oss (OpenAI) | Apache 2.0 | Ja, sehr frei | Zusätzlich OpenAI-Usage-Policy beachten |
| Teuken-7B (OpenGPT-X) | Apache 2.0 (kommerzielle Version) | Ja | Daneben Forschungs-/CC-BY-NC-Varianten — richtige Variante wählen |
Die Quintessenz: Die Llama-Lizenz ist gerade keine freie Open-Source-Lizenz — sie enthält eine Nutzer-Obergrenze und Wettbewerbsklauseln, die in Apache 2.0 oder MIT nicht existieren. Wer Llama produktiv einsetzt, sollte das wissen; für die meisten Mittelständler ist die 700-Mio.-Nutzer-Grenze irrelevant, die „Built with Llama”-Kennzeichnungspflicht und die Acceptable-Use-Policy aber nicht. Vor dem Einsatz immer den aktuellen Lizenztext der konkreten Modellversion lesen. (Lizenzangaben recherchiert April 2026, OSI-Einordnung — Lizenzen ändern sich, dies ersetzt keine Rechtsprüfung im Einzelfall.)
Vendor Lock-in — bindet mich die proprietäre API?
Ja, aber differenziert. Lock-in hat mehrere Dimensionen: Prompt-/Tooling-Bindung (Ihre Prompts und Funktionsaufrufe sind auf ein Modell optimiert), Datenresidenz (wo liegen Embeddings und Logs?) und Preis-/Modell-Abkündigung (der Anbieter ändert Preise oder schaltet ein Modell ab). Open Source ist hier die Exit-Option: Sie können das Modell jederzeit auf eigene Hardware ziehen.
Praktisch mildern Sie Lock-in, indem Sie über ein Abstraktions-Gateway statt direkt gegen eine Anbieter-SDK programmieren — dann ist ein Wechsel eine Konfigurations- statt einer Code-Frage. Diese Strategie vertiefen wir im Beitrag Vendor Lock-in bei KI vermeiden.
Welche Open-Source-LLMs sind enterprise-tauglich?
Ein datierter Überblick (April 2026) — bewusst ohne Ranking, weil sich Rangfolgen monatlich verschieben:
- Llama (Meta): stark, breites Ökosystem — aber Lizenz mit Auflagen (siehe oben).
- Mistral: europäischer Anbieter, viele Modelle unter Apache 2.0, gute Effizienz.
- Qwen (Alibaba): sehr leistungsfähig, Apache 2.0, breites Größenspektrum.
- DeepSeek: starke Reasoning-Modelle, MIT-Lizenz.
- Gemma (Google): ab Gemma 4 unter Apache 2.0, gut integriert ins Google-Ökosystem.
- gpt-oss (OpenAI): offene Gewichte von OpenAI unter Apache 2.0.
- Europäische Optionen: Teuken-7B (OpenGPT-X/Fraunhofer, alle 24 EU-Sprachen, Apache 2.0) und Aleph Alpha (Pharia-Reihe) — relevant, wenn deutsche Sprachgüte und EU-Herkunft Pflichtkriterien sind.
Für deutschsprachige Anwendungsfälle zählen drei Kriterien mehr als der Benchmark-Spitzenplatz: Lizenzklarheit, deutsche Sprachgüte und Hardwarebedarf (ein 7B-Modell läuft auf einer Mittelklasse-GPU, ein 70B-Modell braucht deutlich mehr).
Der Entscheidungs-Leitfaden — welches Modell für welchen Fall
Statt Pro/Contra-Liste: fünf Faktoren, die zusammen die Empfehlung ergeben.
- Datenklasse: Öffentlich/unkritisch, personenbezogen (PII) oder Geschäftsgeheimnis?
- Use-Case: Standard-Aufgabe oder Kerngeschäft mit Wettbewerbsrelevanz?
- Volumen/Token-Last: sporadisch, mittel oder hoch und konstant?
- Inhouse-Betriebskompetenz: Gibt es ein Team, das GPUs und MLOps verantworten kann?
- Budget: CapEx-Bereitschaft vs. planbare OpEx?
Daraus ergeben sich vier typische Empfehlungen:
- Proprietäre API: geringe/schwankende Last, unkritische Daten, schneller Start, kein MLOps-Team.
- Open Source in EU-Cloud (managed): mittlere Last, erhöhte Datensensibilität, EU-Hosting gewünscht, aber kein eigenes GPU-Team.
- Open Source on-prem: hohe konstante Last, Geschäftsgeheimnisse/strenge Souveränität, vorhandene Betriebskompetenz.
- Hybrid (häufigster Realfall): unkritische Anfragen über die API, kernkritische über das eigene Open-Source-Modell — gesteuert über ein Gateway als Datenschleuse.
Wenn Sie aus diesem Artikel eine Sache mitnehmen: Hybrid ist meist die richtige Antwort. Sie kombinieren die Geschwindigkeit der API mit der Kontrolle des Self-Hostings — und ordnen jeden Use-Case der passenden Seite zu.
Compliance ist mehr als DSGVO — der AI-Act-Winkel
Die Modellwahl berührt auch die EU-KI-Verordnung (AI Act). Zwei Punkte sind für die Open-vs.-proprietär-Frage relevant: Erstens verlangt der AI Act Daten-Governance und Transparenz — beides müssen Sie unabhängig vom Modell dokumentieren. Zweitens, und das wird kaum diskutiert: Wer ein offenes Modell wesentlich anpasst oder weiterverbreitet, kann selbst in eine Anbieter-/„Provider”-Rolle mit eigenen Pflichten rutschen. Genau diese Pflichten für Anbieter von Allzweck-KI-Modellen (GPAI) nach Art. 53 AI Act gelten seit dem 2. August 2025 — wer ein offenes Modell deutlich verändert weitergibt, fällt damit potenziell selbst darunter. Reines Fine-Tuning für den Eigengebrauch ist meist unkritisch; die Weitergabe eines deutlich veränderten Modells ist es ggf. nicht. (Stand: April 2026; Einordnung allgemein, keine Rechtsberatung im Einzelfall.)
FAQ
Ist ein Open-Source-LLM kostenlos?
Nein. Die Lizenz ist oft kostenfrei, der Betrieb nicht. Hardware/GPU, Strom und vor allem DevOps und Wartung machen den Großteil der Gesamtkosten aus — die GPU-Anschaffung ist häufig nur etwa die Hälfte. Bei geringer Last ist eine proprietäre API meist günstiger.
Sind Open-Source-LLMs DSGVO-konform?
Sie können es sein. Konformität entsteht aus Betrieb, Vertrag (AVV) und Konfiguration, nicht aus dem Label. Self-Hosting vereinfacht die Beurteilung (kein Drittlandtransfer), ersetzt aber nicht DSFA, Privacy by Design und Löschkonzept.
Sind Open-Source-LLMs sicher?
Sicherheit hängt vom Betrieb ab, nicht vom Lizenztyp. Self-Hosting hält Daten im Haus, verlagert aber die Verantwortung für Patching, Zugriffskontrolle und Modell-Risiken (z. B. Prompt Injection) vollständig auf Sie. Proprietäre Anbieter übernehmen Teile davon, dafür geben Sie Kontrolle ab.
Ab wann lohnt sich ein selbst gehostetes LLM?
Faustregel: bei hoher, konstanter Last und/oder harten Datenresidenz-Anforderungen. TCO-Analysen 2026 nennen Break-even-Bandbreiten ab grob 0,5 Mio. Token/Tag (kleines Modell) bis 2–5 Mio. Token/Tag (große/Frontier-nahe Modelle) — stark abhängig von Auslastung. Vor der Investition mit Ihrer realen Last durchrechnen.
Kann ich später vom proprietären zum offenen Modell wechseln?
Ja — und genau das ist Open Source als Exit-Option. Den Wechsel erleichtern Sie, wenn Sie von Anfang an über ein Abstraktions-Gateway statt direkt gegen eine Anbieter-SDK arbeiten. Dann wird der Wechsel zur Konfigurations- statt zur Neuentwicklungsfrage.
Fazit & nächster Schritt
Open vs. proprietär ist keine Glaubensfrage. Wer sensible Daten und hohe konstante Last hat, gewinnt mit Open Source on-prem — wer schnell starten will und schwankende Last hat, mit der API. Die meisten Unternehmen fahren am besten hybrid. Entscheidend ist, die Wahl entlang von Datenklasse, Volumen und Betriebskompetenz zu treffen — und Lizenz wie DSGVO vor der Einführung zu klären, nicht danach.
Genau diese Architektur- und Compliance-Entscheidung treffe ich mit Ihnen gemeinsam — technisch fundiert und rechtssicher. Mehr dazu unter LLM rechtssicher im Unternehmen einführen. Bei On-Prem- und Souveränitäts-Fragen lohnt der Blick auf datensouveräne KI.
Autor: Leon Lotz, Wirtschaftsjurist & Entwickler (über mich). Stand: April 2026. Dieser Beitrag ist allgemeine Information und keine Rechtsberatung im Einzelfall.
Quellen — Stand 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-Sprachen) — 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-Nutzung in Unternehmen: 76 % entscheiden sich für Open Source” (Sekundärquelle; die 76-%-Zahl geht auf den Databricks-Report „State of Data & AI” zurück — vor Übernahme an der Primärerhebung verifizieren) — https://www.all-about-security.de/llm-nutzung-in-unternehmen-76-prozent-entscheiden-sich-fuer-open-source/
- EU AI Act, Art. 53 — Pflichten für Anbieter von GPAI-Modellen (anwendbar seit 02.08.2025) — https://artificialintelligenceact.eu/article/53/
Leon Lotz
Leon Lotz ist Wirtschaftsjurist und Gründer von MusketierSoftware. Er verbindet juristische Tiefe mit echtem Software-Handwerk.
