KI-Open-Source im Unternehmen: Wahl zwischen Open Source und proprietär

Open Source, Open Weights, proprietär: Wovon sprechen wir genau?

Ein Open-Weight-Modell, ein sogenanntes Open-Source-Modell und ein proprietäres Modell unterscheiden sich darin, was der Anbieter dem Unternehmen überlässt: das Modell selbst, seine Trainingsrezepte oder nur einen Zugang über eine API.

Familie	Was das Unternehmen erhält	Nutzungsart
Open Weight	Ein herunterladbares Modell [35]	Betrieb auf eigener oder Cloud-Infrastruktur [35]
Open Source	Die Gewichte und in der Regel die Trainingsrezepte [24]	Selbsthosting und weitreichende Anpassung [24]
Proprietär	Zugang ohne Einblick in den zugrunde liegenden Code [23]	API oder SaaS [24]

Open Weight: Das Modell wird heruntergeladen

Ein Open-Weight-Modell ist herunterladbar und auf eigener oder Cloud-Infrastruktur ausführbar [35]. Konkret kann das Unternehmen es auf eigenen Servern installieren und nutzen, ohne über die API eines externen Anbieters zu gehen [34].

Open Source: Die Gewichte und oft die Rezepte

Open-Source-Modelle stellen ihre Gewichte und in der Regel auch ihre Trainingsrezepte bereit [24]. Diese Offenheit ermöglicht Selbsthosting und weitreichende Anpassung [24]. Meta mit Llama sowie Mistral AI mit Mistral 7B und Mixtral beanspruchen diese Kategorie für sich [37].

Proprietär: Ein einziger Anbieter behält die Kontrolle

Ein proprietäres Modell wird von einem einzigen Unternehmen kontrolliert. Es ist in der Regel über eine API zugänglich, ohne dass die Nutzer den zugrunde liegenden Code einsehen oder verändern können [23]. Die juristische Literatur spricht auch von „geschlossenen“ oder proprietären Modellen [9].

Zwei Vorsichtsregeln beim Lesen

• Die Beispiele der Quelle [24] sind veraltet. Sie nennt Llama 3, Mistral 7B und Qwen2 auf der offenen Seite sowie GPT-4o und Claude 3.5 auf der proprietären Seite [24]. Sie veranschaulichen die Kategorien, nicht den aktuellen Stand des Angebots.
• Das Etikett „Open Source“ ist eine Behauptung des Anbieters [37], und die tatsächliche Offenheit variiert von Modell zu Modell. Der Abschnitt zu den Lizenzen geht auf diesen Punkt im Detail ein.

Worin unterscheiden sich die beiden Familien grundsätzlich?

Die beiden Familien unterscheiden sich darin, was das Unternehmen einsehen, verändern und hosten kann: Das proprietäre Modell wird als fertiger Dienst genutzt, das Open-Source-Modell wird bereitgestellt und angepasst. Ein Open-Source-Modell (zum Beispiel Mistral 7B, Llama 3, Qwen2) stellt seine Gewichte und in der Regel seine Trainingsrezepte frei zur Verfügung. Proprietäre Modelle (GPT-4o, Claude, Gemini) werden als API oder SaaS angeboten [24].

Kriterium	Proprietäres Modell	Open-Source- / Open-Weight-Modell
Transparenz	Black Box: Das Unternehmen sendet seine Daten per API, ohne Einblick in die interne Funktionsweise [21]. Der zugrunde liegende Code kann weder eingesehen noch verändert werden [23].	Gewichte und in der Regel Trainingsrezepte zugänglich [24].
Anpassung	Eingeschränkt und ohne Zusatzkosten [25].	Weitreichend [24].
Standardisierung	Sofort einsatzbereit, minimaler Konfigurationsaufwand [25].	In den herangezogenen Quellen nicht angegeben.
Hosting	API oder SaaS [24].	Selbsthosting möglich [24].
Support	Kommerzielle Angebote bieten Einfachheit und professionelle Unterstützung [11].	In den herangezogenen Quellen nicht angegeben.

Eine Lesart mit Einschränkungen

Mehrere Quellen dieser Tabelle sind Blogs von Agenturen oder Anbietern, keine institutionellen Texte und keine Forschungsarbeiten. Ihre Beschreibungen stimmen untereinander überein, beruhen aber auf keiner Messung. Zwei Felder bleiben mangels verlässlicher Information leer: die Standardisierung und der Support auf der Open-Source-Seite. Diese Punkte sollten beim gewählten Anbieter oder Hoster geprüft werden.

Diese Unterschiede strukturieren die folgenden Abschnitte: Kosten, Datenschutz und Anbieterabhängigkeit ergeben sich daraus, wo das Modell läuft und was man daran verändern kann. Oupi ermöglicht die Nutzung beider Familien im selben Tool, sodass man sich nicht a priori für eine davon entscheiden muss (Produkt ansehen).

Holen Open-Weight-Modelle die proprietären Modelle bei der Leistung ein?

Ja, der Abstand verringert sich, doch die Unterlagen erlauben keinen Schluss auf eine allgemeine Gleichwertigkeit von Open-Weight- und proprietären Modellen. Drei Feststellungen sind belegt.

• Das erreichte Niveau: Open-Source-Modelle wie Llama-3 von Meta erreichen den Stand der Technik, der von proprietären Modellen vorgegeben wurde [1].
• Das Gewicht im Markt: Der Aufstieg der Open-Source-Modelle ist ein wichtiger Faktor im Markt für generative KI [9].
• Das Angebot: Chinesische Akteure machen ihre Modelle zugänglicher, teils bis hin zur Open Source [3].

Modelle, die man selbst hosten kann

Llama (Meta) und Mistral gehören zu den meistgenutzten Modellen der Kategorie, die man auf eigenen Servern installieren kann, ohne über die API eines externen Anbieters zu gehen [34]. Meta mit Llama sowie Mistral AI mit Mistral 7B und Mixtral bezeichnen sich als Anbieter von Open-Source-Modellen [37]. Der Begriff ist umstritten: Abschnitt 1 unterscheidet Open Source und Open Weights, Abschnitt 6 behandelt die Lizenzen.

Was die Unterlagen nicht sagen

Die Aussage zu Llama-3 [1] ist eine qualitative Feststellung. Die Unterlagen enthalten keinen einzigen quantifizierten Vergleichs-Benchmark. Daher lässt sich nicht sagen, welches Modell bei welcher Aufgabe (Redaktion, Extraktion, Code, Französisch) vorne liegt und mit welchem Abstand. „Den Stand der Technik erreichen“ bedeutet nicht, überall gleichwertig zu sein, und ein bestimmtes Modell kann bei einem bestimmten Anwendungsfall zurückliegen.

Die praktische Konsequenz: Mit den eigenen Fällen testen

Die einzig vertretbare Vorgehensweise besteht darin, die Kandidaten beider Familien anhand der eigenen Daten zu bewerten. Ein minimales Protokoll umfasst einige Punkte:

1. eine Sammlung realer, repräsentativer Anfragen in der Arbeitssprache zusammenstellen;
2. dieselben Anfragen an ein proprietäres Modell und an ein Open-Weight-Modell richten;
3. die Antworten von den betroffenen Fachbereichen bewerten lassen;
4. die beobachtete Latenz und die Kosten erfassen, denn die Leistung allein entscheidet nicht.

Oupi ermöglicht die Nutzung beider Modellfamilien im selben Tool, was solche Vergleiche mit identischen Anfragen erleichtert (Produkt ansehen).

Was kostet ein KI-Modell wirklich: API oder Selbsthosting?

Die Kosten eines KI-Modells hängen vom verarbeiteten Volumen und von den intern verfügbaren Kompetenzen ab: Die Quellen sind sich nicht einig, welche Option die günstigste ist.

Zwei gegensätzliche Lesarten

Laut Tizy wäre ein selbst gehostetes Open-Source-Modell bei vergleichbarem Volumen 5- bis 10-mal günstiger als ein proprietäres Modell über API [10]. Diese Zahl wird nach „Tech Insider“ zitiert, einer Sekundärquelle. Die Unterlagen enthalten keinerlei Angaben zur Berechnung, und Tizy ist ein kommerzieller Akteur, weshalb die Angabe mit Vorsicht zu behandeln ist. Ein anderer Beitrag relativiert die Tragweite: Open Source bringt nennenswerte Einsparungen vor allem für Unternehmen mit interner technischer Expertise [13].

Andere Quellen erinnern daran, dass Modelle kostenlos heruntergeladen werden können, Rechenleistung und Speicher aber vom Unternehmen getragen werden müssen [11]. Für eine Standardnutzung wären eine proprietäre API oder ein Open-Source-Modell bei einem Inferenz-Anbieter oft wirtschaftlicher und zuverlässiger [22].

Diese Positionen widersprechen sich nicht frontal: Sie beschreiben unterschiedliche Situationen (große Volumina und ein technisches Team auf der einen Seite, alltägliche Nutzung auf der anderen).

Die einzurechnenden Kostenposten

Beim Selbsthosting ist Folgendes zu berücksichtigen [12]:

• eine geeignete Recheninfrastruktur;
• die Verwaltung der Aktualisierungen;
• die Überwachung der Leistung;
• die Absicherung der KI-Pipeline.

Die letzten drei Posten binden Teamzeit, die in einem Preis pro Token nicht auftaucht.

In Vollkosten denken

Den Token-Preis einer API mit den Kosten eines Servers zu vergleichen reicht nicht aus: Man muss in Vollkosten denken [40]. Bei einer API bedeutet das, den tatsächlichen Verbrauch hochzurechnen. Beim Selbsthosting addiert man Hardware oder die Miete von GPUs, den Betrieb und die Kompetenzen.

Was man festhalten sollte

Die Quellen des Dossiers erlauben es nicht, eine universelle Wirtschaftlichkeitsschwelle festzulegen. Alles hängt von Volumen und Kompetenzen ab: Selbsthosting wird relevant, wenn die Volumina hoch sind und das Team es betreiben kann, während die API für eine Standardnutzung die einfachste Wahl bleibt. Um zu entscheiden, sollte man diese beiden Szenarien mit den eigenen Volumina und Anwendungsfällen durchrechnen.

Open Source oder proprietär: Welche Lösung schützt Daten und Souveränität am besten?

Ein auf eigenen Servern installiertes Modell bietet die unmittelbarste Kontrolle über die Daten. Open Source garantiert die digitale Souveränität jedoch nicht von selbst, und ein proprietäres Modell ist grundsätzlich nicht ausgeschlossen.

Was das Selbsthosting ändert. Ein Unternehmen kann ein Open-Source-Modell auf eigenen Servern installieren und nutzen, ohne über die API eines externen Anbieters zu gehen [34]. Diese Konfiguration erlaubt es, die Kontrolle über die Daten zu behalten [18]. Bei einem proprietären Modell sendet das Unternehmen seine Daten über eine API und hat keinerlei Einblick in die interne Funktionsweise des Modells [21].

Warum Souveränität bei der Entscheidung ins Gewicht fällt. Digitale Souveränität und Compliance, verschärft durch den europäischen AI Act, veranlassen Unternehmen dazu, Lösungen zu suchen, bei denen sie ihre Infrastruktur kontrollieren und die Abhängigkeit von US-amerikanischen oder chinesischen Großkonzernen vermeiden [31]. Diese Quelle ist ein Agenturblog: Sie beschreibt einen Markttrend, keine juristische Analyse.

Ein europäisches Modell reicht nicht aus. Die Wahl eines europäischen Modells löst nur einen Teil der Frage, denn Souveränität hängt auch von anderen Faktoren ab, etwa dem Hosting [22]. Ein offenes Modell, das bei einem Inferenz-Anbieter betrieben wird, bietet daher nicht dasselbe Maß an Kontrolle wie ein Modell auf der eigenen Infrastruktur. Man muss prüfen, wo das Modell tatsächlich läuft.

Was der AI Act je nach Modellfamilie ändert. Die Verordnung (EU) 2024/1689, in Kraft seit dem 1. August 2024, unterscheidet zwischen Open Source und proprietär [26]. Bei einer rein internen Nutzung ohne Bereitstellung für externe Nutzer beschränkt sich die genannte Pflicht darauf, die Mitarbeitenden darüber zu informieren, dass sie mit einer KI interagieren [26]. Dieses Beispiel gilt für Tools wie ChatGPT, Claude oder Mistral [26].

Zu prüfen: Diese Aussage stammt aus einem Blog, der auf service-public.fr verweist [26]. Vor jeder Compliance-Entscheidung sollte sie mit dem amtlichen Wortlaut der Verordnung abgeglichen werden.

Eine Entscheidung je nach Anwendungsfall. Die Vertraulichkeitsanforderungen variieren je nach Anwendungsfall. In Oupi lassen sich beide Modellfamilien im selben Tool nutzen (Produkt ansehen), sodass dem gesamten Unternehmen keine einzige Wahl aufgezwungen werden muss.

Bedeutet „Open Source“ immer lizenzfrei nutzbar? Was die Lizenzen sagen

Nein: „Open Source“ sagt für sich allein nicht, was ein Unternehmen mit einem Modell tun darf. Das legt die Lizenz fest, und sie unterscheidet sich von Modell zu Modell. Laut einem Überblick von Lebigdata setzt sich keine Lizenz durch [33]:

Lizenz	Genannte Modelle
Apache 2.0	Gemma 4, Qwen3.8‑27B, Muse Glimmer von Meta [33]
MIT	DeepSeek, GLM‑5.2 [33]
Individuelle Lizenz	Qwen3.8‑2.4T‑A95B (Lizenz Qwen3.8‑Max) [33]
Proprietäre Stufenlizenz	Kimi K3 [33]

Die Bedingungen können sich auch von einer Version zur nächsten ändern. Meta hat für Muse Glimmer Apache 2.0 gewählt und damit seine bisherige Community-Lizenz aufgegeben [33].

Das Etikett „Open Source“ entscheidet nicht immer. Eine Forschungsarbeit wirft die Frage auf, wann man überhaupt von einer Open-Source-Lizenz sprechen kann, auch im Fall von Mistral 7B [2]. Für einen CIO ersetzt die kommerzielle Bezeichnung eines Anbieters also nicht die Lektüre des Lizenztexts.

Ein offenes Projekt kann auch die Richtung wechseln. Eine Forschungsarbeit weist darauf hin, dass es in eine proprietäre Richtung abdriften kann [4]. Es ist daher umsichtig, die Lizenz der tatsächlich eingesetzten Version zu prüfen, denn die Bedingungen einer späteren Version können abweichen.

Nach OSAID konforme Modelle gelten als rechtlich sicherer. Laut ZDNET bieten sie Organisationen Transparenz, Rechtssicherheit und umfassende Anpassungsmöglichkeiten [20]. Dieses Kriterium ist ein Ausgangsfilter, keine Garantie: Es entbindet nicht davon, die Lizenz des gewählten Modells zu prüfen.

Umgekehrt gewähren proprietäre oder geschlossene Modelle keinen Zugang zu ihrem Quellcode [9]. Ihre Nutzungsbedingungen richten sich dann nach dem Vertrag des Anbieters.

Vor jeder kommerziellen Nutzung sollte man die Lizenz des Modells lesen, Version für Version, und ihre Bedingungen von der Rechtsabteilung prüfen lassen. Oupi ermöglicht die Nutzung beider Modellfamilien im selben Tool, was den Vergleich anhand Ihrer Anwendungsfälle erleichtert (Produkt ansehen). Die Prüfung der Lizenzen liegt jedoch in Ihrer Verantwortung.

Welches Risiko der Anbieterbindung (Lock-in) besteht je nach Modellwahl?

Das Risiko einer Anbieterbindung besteht bei beiden Modellfamilien, nimmt aber unterschiedliche Formen an. Lock-in bezeichnet die Situation, in der ein Anbieterwechsel zu teuer wird, gemessen an Zeit, Entwicklungsaufwand oder organisatorischem Aufwand.

Das Risiko bei proprietären Modellen

Sobald ein proprietäres Modell tief in Arbeitsabläufe und APIs eingebettet ist, wird es schwer zu ersetzen [7]. Je weiter die Integration fortschreitet, desto teurer wird der Ausstieg. Am wichtigsten ist dieser Punkt in der Konzeptionsphase.

Das Risiko ist für KMU besonders deutlich: Wer ein Angebot auf einem proprietären KI-Modell aufbaut, setzt sich diesem Risiko aus [3]. Unternehmen, deren Tätigkeit auf proprietären APIs beruht, sollten es daher bewerten [5].

Auch der kommerzielle Kontext spielt eine Rolle. Laut einer Analyse der französischen Wettbewerbsbehörde können Anbieter junge KI-Unternehmen dazu bewegen, ihre Dienste zu wählen [6]. Ein attraktives Einstiegsangebot sagt jedoch nichts über die Kosten eines späteren Wechsels aus.

Das Risiko bei Open Source und gemischten Angeboten

Die Wahl eines offenen Modells beseitigt nicht jede Abhängigkeit. Manche Anbieter kombinieren proprietäre KI-Bausteine mit Open-Source-Plattformen. Dieser Ansatz erleichtert die Einführung und bietet eine solide technische Begleitung, schafft aber eine Abhängigkeit vom Anbieter, sowohl bei den Kosten als auch beim tatsächlichen Verständnis der Modelle [27]. Diese Quelle ist ein Fachmedium, keine Studie, doch der beschriebene Mechanismus ist klar: Das Etikett „Open Source“ der Plattform verhindert nicht das Lock-in durch die sie umgebenden Bausteine.

Fragen, die man vor einer Festlegung stellen sollte

• Lässt sich das Modell ersetzen, ohne Arbeitsabläufe und API-Integrationen neu zu schreiben?
• Welche Bausteine des Angebots bleiben proprietär, auch auf einer offenen Plattform?
• Was würde der Ausstieg kosten, sowohl in der Entwicklung als auch bei den internen Kompetenzen?

Lock-in zu begrenzen heißt vor allem, die Möglichkeit zu behalten, das Modell zu wechseln. Oupi ermöglicht die Nutzung beider Modellfamilien, Open Source und proprietär, im selben Tool (Produkt ansehen). Die Nutzung ist daher nicht an eine einzige Familie gebunden.

Wie entscheidet man konkret: proprietär, Open Weights oder hybrid?

Die Wahl zwischen proprietär und Open Weights ist weder binär noch endgültig: Sie hängt vom technologischen Reifegrad des Unternehmens und seinen Bedürfnissen ab [15][29]. Eine heute getroffene Entscheidung kann daher revidiert werden, wenn sich Volumina, Kompetenzen oder Rahmenbedingungen ändern.

Entscheidungsraster

Situation	Empfohlene Richtung	Warum
Standardanwendungsfälle, schnelle Umsetzung	Proprietäres Modell	Sofort verfügbare und leistungsstarke Lösung [29], vereinfachter Einsatz [14]
Interne technische Expertise, große Volumina	Selbst gehostetes Open-Weight-Modell	Mögliche nennenswerte Einsparungen, wenn die Expertise intern vorhanden ist [13]
Gemischte Anforderungen (Sicherheit, Kosten, Souveränität, Compliance)	Hybrider Ansatz	Die Wahl richtet sich nach diesen Kriterien, und der Hybrid ist eine davon [12]

Der Hybrid besteht darin, die Nutzungen zwischen beiden Familien aufzuteilen, Aufgabe für Aufgabe. Auf der Angebotsseite ist dies realistisch: Manche Akteure bieten bereits sowohl proprietäre als auch Open-Source-Modelle an [6].

Eine einfache Architektur für den Einstieg

Ein kommerzieller Anbieter, gensai.ai, argumentiert, dass ein gut gewähltes Open-Weight-Modell, ein RAG auf den eigenen Dokumenten und ein Anwendungsspeicher den überwiegenden Teil der Bedürfnisse abdecken, zu einem Bruchteil der Kosten einer proprietären Entwicklung [30]. Diese Behauptung stammt von einem Akteur, der genau diese Art von Lösung verkauft: Sie liefert einen Ausgangspunkt, keinen Beweis.

Auf den eigenen Anwendungsfällen vergleichen

Oupi ermöglicht die Nutzung beider Modellfamilien im selben Tool. Ein Team kann so denselben Anwendungsfall einem proprietären Modell und einem Open-Weight-Modell vorlegen, ohne die Oberfläche zu wechseln, und die Ergebnisse vergleichen (Produkt ansehen).

Mit den realen Volumina testen

Generische Zahlen ersetzen keine Messung. Vor der Entscheidung empfiehlt es sich, folgende Schritte zu gehen:

1. zwei oder drei repräsentative Anwendungsfälle auswählen;
2. sie in beiden Familien mit Volumina nahe dem Produktivbetrieb laufen lassen;
3. die Antwortqualität, die Vollkosten (einschließlich Infrastruktur und Betriebszeit) und die Dauer der Umsetzung vergleichen;
4. die Entscheidung in regelmäßigen Abständen überprüfen, da die Wahl nicht endgültig ist [15].