Geschlossene Modelle, Open Weights und Open Source im Unternehmen

Wenn ich mit Unternehmen über KI-Modelle spreche, fallen häufig zuerst Produktnamen wie GPT oder Claude. Gleichzeitig werden Open Source und Open Weights regelmäßig gleichgesetzt. Das führt schnell zu falschen Annahmen über Hosting, Kontrolle und Datensicherheit.

Bevor ein Unternehmen über ein konkretes Modell entscheidet, muss es die eigenen Datenflüsse verstehen: Welche Daten verarbeitet das System? Wohin werden sie übertragen? Wer betreibt die Plattform und welchem Recht unterliegt das Unternehmen dahinter? Erst dann lässt sich sinnvoll entscheiden, ob ein geschlossenes Modell, Open Weights oder ein vollständig offenes System passt.

Ein Modell wird nicht nach seinem Namen ausgewählt. Es muss im konkreten Prozess zeigen, dass es die Anforderungen erfüllt.

Geschlossene Modelle: leistungsfähig und vollständig verwaltet

Bei einem geschlossenen Modell bleibt der wesentliche Teil beim Anbieter. Unternehmen greifen über eine Anwendung oder API darauf zu. Gewichte, Trainingscode und Trainingsdaten stehen nicht zum Download bereit.

Die GPT-Modelle von OpenAI und die Claude-Modelle von Anthropic können hervorragende Ergebnisse liefern. Der Anbieter übernimmt Infrastruktur, Skalierung, Sicherheitsupdates und neue Modellversionen. Das ermöglicht einen schnellen Einstieg. Im Gegenzug bestimmt er, welche Versionen, Funktionen, Limits und Preise gelten. Das Modell kann nicht auf die eigene Infrastruktur verschoben werden.

Anwendung und API bieten unterschiedliche Möglichkeiten. In ChatGPT oder Claude lassen sich eigene Anweisungen, Projekte oder konfigurierte Assistenten verwenden. Über die API kann ein Unternehmen zusätzlich eigene Systemanweisungen (Prompts) festlegen, Parameter konfigurieren und Ausgaben strukturiert weiterverarbeiten. Der interne Systemkontext des Anbieters, die Modellgewichte und das trainierte Alignment bleiben trotzdem außerhalb der eigenen Kontrolle.

Die API wird separat und verbrauchsabhängig abgerechnet. Bei intensiver Nutzung leistungsfähiger Modelle kann sie deutlich teurer werden als ein pauschaler Anwendungstarif. Für produktive Prozesse sollten Unternehmen deshalb mit ihren tatsächlichen Eingaben, Ausgaben und Kontextlängen rechnen. Warum sich Anwendungstarife und API-Kosten so stark unterscheiden können, untersuche ich im Artikel „KI-Abos, Tokenpreise und API-Kosten: Was bekommt man für sein Geld?“.

Für die Datensicherheit ist das konkrete Produkt wichtiger als der Markenname. OpenAI verwendet Daten aus seinen Business-Produkten und der API standardmäßig nicht zum Training. Anthropic macht für Claude for Work und seine API eine vergleichbare Zusage. Diese Zusagen sind relevant. Bei einem geschlossenen Dienst muss ein Kunde dennoch darauf vertrauen, dass die vertraglichen und technischen Regeln eingehalten werden. Direkte Kontrolle über Modellbetrieb und Datenverarbeitung besitzt er nicht.

Geschlossene Modelle sind sinnvoll, wenn ein schneller Einstieg, hohe Modellqualität und ein vollständig verwalteter Betrieb im Vordergrund stehen. Sobald sensible Unternehmens- oder Personendaten verarbeitet werden, müssen aber auch der konkrete Datenfluss, der Betreiber und dessen Rechtsraum Teil der Architekturentscheidung sein.

Open Weights: mehr Betriebsoptionen und mehr Verantwortung

Der entscheidende Vorteil von Open Weights liegt in den zusätzlichen Betriebsoptionen. Zusammen mit der Modellarchitektur und geeigneter Inferenzsoftware können Unternehmen das Modell unabhängig vom ursprünglichen Anbieter ausführen.

Mögliche Betriebsmodelle sind:

• im eigenen Rechenzentrum,
• in einer Private Cloud,
• bei einem europäischen Cloud-Anbieter,
• oder als verwalteter Dienst bei einem spezialisierten Betreiber.

Die Daten müssen dadurch nicht mehr an den ursprünglichen Modellentwickler übertragen werden. Das Unternehmen kann eine Modellversion behalten, Inferenzsoftware und Quantisierung auswählen und das Modell abhängig von der Lizenz anpassen.

Beispiele sind DeepSeek-V3, Modelle der GLM-Familie und OpenAIs gpt-oss. Sie stellen Gewichte und zusätzliche technische Artefakte bereit. Das macht sie aber nicht automatisch zu vollständig offenen Modellen.

Open Weights bedeutet nicht automatisch, dass ein Modell unzensiert oder frei von politischen Verzerrungen ist. Beim Self-Hosting kontrolliert das Unternehmen den Systemprompt, die Chat-Vorlage, die Inferenzparameter und zusätzliche Filter der eigenen Laufzeit. Das während des Trainings erlernte Alignment bleibt jedoch Bestandteil der Gewichte.

Eine aktuelle EACL-Studie mit 36.000 Testprompts zeigt, dass sowohl die Herkunft eines Modells als auch die Sprache der Anfrage politische Antworten beeinflussen können. Untersuchungen zu DeepSeek-R1 dokumentieren zusätzlich Auslassungen und Ablehnungen bei politisch sensiblen Themen mit China-Bezug. Das betrifft nicht nur chinesische Modelle. Unternehmen sollten Bias und Ablehnungsverhalten deshalb mit eigenen Testfällen in den tatsächlich verwendeten Sprachen und Fachgebieten prüfen.

Vor einem Unternehmenseinsatz muss auch die Lizenz geprüft werden. Gewichte und Code können unterschiedlichen Bedingungen unterliegen. Herunterladbar bedeutet nicht automatisch, dass jede kommerzielle Nutzung, Veränderung oder Weitergabe erlaubt ist.

Open Weights erhöht damit auch die eigene Verantwortung. Wer selbst hostet, übernimmt Updates, Zugriffsschutz, Monitoring, Skalierung, Evaluation und den sicheren Betrieb. Diese Modelle sind sinnvoll, wenn ein Unternehmen die Daten und den Betrieb stärker kontrollieren muss und die dafür notwendige technische Verantwortung übernehmen kann.

Open Source: Transparenz und praktische Prüfbarkeit

Der Begriff Open Source wird bei KI-Modellen häufig zu großzügig verwendet. Ein öffentliches GitHub-Repository reicht nicht aus. Das Verhalten eines Modells entsteht aus Architektur, Trainingsdaten, deren Aufbereitung, dem Trainingsverfahren und den daraus hervorgegangenen Gewichten.

Die Open Source AI Definition 1.0 der Open Source Initiative verlangt deshalb mehr als einen Download der Gewichte. Ein offenes KI-System soll genutzt, untersucht, verändert und weitergegeben werden können. Dafür müssen unter anderem der relevante Code, die Modellparameter und umfangreiche Informationen über die Trainingsdaten und deren Verarbeitung verfügbar sein.

Vollständige Trainingsdaten können aus rechtlichen oder datenschutzrechtlichen Gründen fehlen. Die Dokumentation soll dennoch so weit reichen, dass Fachleute die Entstehung und Funktionsweise untersuchen können.

Die praktische Grenze bleibt: Nur sehr wenige Organisationen könnten ein großes Modell vollständig neu trainieren und überprüfen, ob die veröffentlichten Gewichte tatsächlich aus dem beschriebenen Prozess entstanden sind. Transparenz ermöglicht eine Prüfung. Sie macht sie noch nicht wirtschaftlich oder technisch machbar.

Open Source ist besonders relevant, wenn ein Unternehmen ein System nachvollziehen, verändern oder langfristig unabhängig weiterentwickeln möchte. Der zusätzliche Einblick ist wertvoll. Er ersetzt aber weder eine eigene Evaluation noch die technische Fähigkeit, die veröffentlichten Informationen tatsächlich zu prüfen.

Die Modellart verändert Hosting, Kontrolle und Verantwortung. Sie garantiert allein weder Datensicherheit noch Compliance. Mit KI-Unterstützung erstellt.

Datensicherheit entscheidet sich am Datenfluss

Die Offenheit eines Modells und die Sicherheit seiner Verarbeitung sind zwei unterschiedliche Fragen. Entscheidend ist, welche Daten ein System verarbeitet, wie sie durch die Architektur fließen, wo sie gespeichert oder protokolliert werden und wer auf sie zugreifen kann.

Ein Serverstandort in Frankfurt klingt zunächst beruhigend. Aber wie viel europäische Datensouveränität bleibt, wenn der Betreiber US-Recht unterliegt? Unter bestimmten Voraussetzungen muss er Daten herausgeben – möglicherweise ohne das betroffene Unternehmen darüber informieren zu dürfen.

Der CLOUD Act setzt die DSGVO nicht außer Kraft. Er kann aber einen Rechtskonflikt erzeugen, den die Angabe „DSGVO-konform“ allein nicht auflöst. Für sensible Unternehmensdaten müssen deshalb auch Betreiber, Konzernstruktur, geltender Rechtsraum und tatsächliche Zugriffsmöglichkeiten geprüft werden. Der Standort des Rechenzentrums ist nur ein Teil der Antwort.

Ein Open-Weights-Modell kann vollständig bei einem europäischen Anbieter oder auf eigener Infrastruktur laufen. Der ursprüngliche Entwickler erhält dann nicht automatisch Zugriff auf Eingaben und Ausgaben. Maßgeblich ist der Betreiber der konkreten Infrastruktur: Wer kontrolliert administrative Zugriffe, Protokolle, Backups und die Löschung der Daten?

Für sensible Daten müssen Standort, Rechtsraum, Zugriffe und Verträge gemeinsam geprüft werden. Mit KI-Unterstützung erstellt.

Self-Hosting leistungsfähiger Modelle benötigt erhebliche Rechenkapazität. Wie schnell dabei eine völlig andere Größenordnung erreicht wird, zeigt Kimi K3: Für eine mögliche Konfiguration werden 32 NVIDIA-H100-Grafikkarten genannt. Bei aktuell öffentlich gelisteten Preisen entspricht das rund 1,7 Millionen Euro allein für die Grafikkarten. Server, Netzwerk, Kühlung und Strom sind darin noch nicht enthalten. Die Preisangabe ist eine Momentaufnahme mit Stand Juli 2026.

Kleinere Modelle und unterschiedliche Quantisierungsstufen können diesen Aufwand deutlich reduzieren. Dabei stellt sich aber auch die Frage, wie sich die Reduzierung auf Qualität und Ergebnisse auswirkt. Diesen Zusammenhang zwischen Modellgröße, Quantisierung, Hardware, Stromverbrauch und tatsächlichen Kosten behandle ich in einem eigenen Artikel.

Die rechtlichen und technischen Details werden im Artikel „DSGVO und CLOUD Act im KI-Zeitalter: Datensicherheit im Unternehmen“ behandelt. Darin geht es genauer um europäische Datenresidenz, US-Recht, geopolitische Risiken und mögliche technische Alternativen.

Kriterien für die Modellwahl im Unternehmen

Keine der drei Kategorien ist pauschal die beste. Ein geschlossenes Modell kann sinnvoll sein, wenn Leistungsfähigkeit, schneller Einstieg und ein vollständig verwalteter Betrieb im Vordergrund stehen. Open Weights bietet mehr Freiheit bei Hosting und Anpassung. Ein Open-Source-System geht bei Transparenz und Veränderbarkeit noch weiter.

Vor der Auswahl sollten Unternehmen deshalb konkrete Fragen beantworten:

• Welche konkreten Daten verarbeitet das System?
• Wohin werden Eingaben, Kontext, Ausgaben und Protokolle übertragen?
• Wer betreibt die Plattform und welchem Rechtsraum unterliegt dieses Unternehmen?
• Muss das Modell auf eigener oder europäisch kontrollierter Infrastruktur laufen?
• Wie viel Kontrolle wird über Modellversion, Systemanweisungen und zusätzliche Filter benötigt?
• Was erlauben Lizenz und verfügbare technische Artefakte im kommerziellen Betrieb?
• Erfüllt oder übertrifft das Modell die fachlichen Anforderungen in realistischen Tests mit den eigenen Anwendungsfällen?
• Wer übernimmt Sicherheit, Updates, Evaluation, Kostenkontrolle und einen späteren Anbieterwechsel?

Meine Empfehlung ist, die Modellwahl nicht mit einem Produktnamen zu beginnen. Zuerst muss klar sein, um welche Daten es geht, wie sie durch das System fließen, wohin sie übertragen werden und wer die Plattform dahinter betreibt. Danach muss das Modell mit realistischen Aufgaben aus dem späteren Einsatz getestet werden. Es muss die benötigte Qualität zuverlässig erreichen oder übertreffen. Das teuerste oder leistungsfähigste Modell ist dafür nicht automatisch erforderlich.

Auch der Ressourcenverbrauch gehört zu dieser Entscheidung. Große Modelle benötigen erhebliche Rechenleistung und Energie – im eigenen Rechenzentrum ebenso wie bei einem Cloud-Anbieter. KI darf umfangreich eingesetzt werden, wenn sie Qualität, Geschwindigkeit oder Wirtschaftlichkeit tatsächlich verbessert. Sie sollte aber nicht in einen Prozess eingebaut werden, nur weil es technisch möglich ist.

Mehr Rechenleistung ist nur dann sinnvoll, wenn sie auch ein besseres Ergebnis liefert.