Mozilla-Report: Offene KI bleibt im Produktivbetrieb zurück

Der Mozilla-/SlashData-Report zeigt eine Lücke zwischen breiter Nutzung offener KI-Modelle und ihrem Produktivbetrieb. Entscheidend sind nicht nur Modelle, sondern Betrieb, Lizenz, Integration und Verantwortlichkeiten.

Von Wolfgang

20. Juli 20267 Min. Lesezeit

Offene KI-Modelle sind längst nicht mehr nur ein Thema für Forschungsabteilungen. Der neue Mozilla-/SlashData-Report zeigt jedoch: Zwischen Nutzung und belastbarem Produktivbetrieb liegt eine spürbare Lücke. In der zugrunde liegenden Erhebung nutzen 79 Prozent der Befragten offene Modelle. Produktiv im Einsatz sind sie bei 51 Prozent der Open-Model-Adoptierenden, bei geschlossenen Modellen bei 63 Prozent. Die Differenz von zwölf Prozentpunkten beschreibt keine allgemeine Ausfallquote. Sie verweist auf die Arbeit, die erst beginnt, wenn ein Modell in echte Prozesse eingebunden werden soll.

Das Wichtigste in 30 Sekunden

Der Mozilla-/SlashData-Report vom 14. Juli 2026 beobachtet eine niedrigere Produktivbetriebsrate bei offenen als bei geschlossenen Modellen – jeweils unter den Personen, die den Modelltyp bereits nutzen.
Die Werte sind ein Survey-Befund, kein Beweis dafür, dass ein einzelner Faktor die Differenz verursacht.
Für den Betrieb zählen neben Modellqualität auch Hosting, Datenpfade, Integration, Rechte, Monitoring, Updates und Support.
Offene Gewichte sind nicht automatisch vollständiges Open Source und auch keine automatische Zusage für Kosten-, Sicherheits- oder Compliance-Vorteile.

Drei Fachleute besprechen in einem unmarkierten Technikraum die Einführung eines KI-Systems neben einem geschlossenen Serverschrank. — Produktionsreife entsteht nicht am Modell allein, sondern im Zusammenspiel von Infrastruktur, Integration und klaren Zuständigkeiten.

Der Report lenkt den Blick auf den Betrieb

Mozilla hat am 14. Juli 2026 seinen ersten State of Open Source AI veröffentlicht. Der Report wertet eine globale Entwicklerbefragung von SlashData aus und stellt eine Frage in den Mittelpunkt, die in Modellvergleichen oft untergeht: Was fehlt zwischen einem verfügbaren Modell und einem Dienst, auf den sich ein Unternehmen im Alltag verlassen kann?

Für Teams mit Interesse an lokalen Installationen, Anbieterwechsel oder stärkerer Kontrolle über Daten wird dieser Befund praktisch relevant. Die Wahl eines Modells ist nur eine von mehreren Entscheidungen. Sobald ein System Kundendaten verarbeitet, Informationen aus internen Quellen abruft oder Werkzeuge ansteuert, werden Zuständigkeiten und Betriebsprozesse Teil der technischen Lösung.

Was die Erhebung gemessen hat

SlashData führte die Onlineerhebung im Auftrag von Mozilla vom 19. bis 29. Mai 2026 durch. Für die zentrale Funnel-Grafik nennt der Appendix 1.494 qualifizierte Befragte. Die Ergebnisse wurden regional gewichtet. Die Befragung lief auf Englisch, Chinesisch, brasilianischem Portugiesisch und Japanisch. Sie ist damit kein repräsentativer Zensus deutscher oder europäischer Unternehmen.

Der Report verwendet je nach Auswertung unterschiedliche Basen. Für Produktionsraten professioneller Entwicklerinnen und Entwickler nennt er n=954; für einzelne Analysen zu Hürden bei aktuellen oder abgesprungenen Open-Model-Nutzenden n=1.410. Diese Zahlen gehören nicht in einen gemeinsamen Nenner. Sie markieren unterschiedliche Ausschnitte derselben Untersuchung.

Messgröße	Bezugsgruppe	Wert	Was daraus nicht folgt
Nutzung offener Modelle	Befragte der zentralen Funnel-Grafik	79 Prozent	Keine Aussage über alle KI-Projekte oder Unternehmen
Produktivbetrieb mit offenen Modellen	Open-Model-Adoptierende	51 Prozent	Keine allgemeine Scheiterquote
Produktivbetrieb mit geschlossenen Modellen	Adoptierende geschlossener Modelle	63 Prozent	Kein Beweis für eine einzelne Ursache

Hände ordnen drei leere farbige Karten auf einer Holzfläche; im Hintergrund liegen ein geschlossenes Archiv und ein Kabelkanal ohne Beschriftung. — Die beobachtete Differenz im Produktivbetrieb verweist auf Übergaben und Prüfungen, beweist aber keine einzelne Ursache.

Wie die zwölf Prozentpunkte zu lesen sind

Die 51 und 63 Prozent sind Raten innerhalb unterschiedlicher Gruppen von Modelltyp-Adoptierenden. Daraus ergibt sich eine deskriptive Differenz von zwölf Prozentpunkten. Der Report beobachtet also einen Abstand im Produktivbetrieb. Er beantwortet nicht, ob Infrastruktur, Lizenzbedingungen, Support, Personal, Integration oder ein anderer Faktor dafür ausschlaggebend war.

Die nützlichere Frage lautet deshalb, an welcher Stelle ein konkreter Anwendungsfall hängen bleibt: bei der Datenanbindung, bei Lastspitzen, bei Freigaben, bei Updates oder an einer fehlenden Verantwortung für Störungen. Die Antworten können je nach Workload sehr unterschiedlich ausfallen.

Produktivbetrieb entsteht im Zusammenspiel von Modell und Betriebsumfeld

Mozilla nennt Compute- und Infrastrukturkosten, Sicherheit, Datenschutz, Compliance, Wartung, Integration, Standardisierung und Enterprise-Support als wiederkehrende Hürden. Diese Liste ist kein Bauplan und kein Kausalbeweis. Sie beschreibt aber eine vertraute Realität aus dem Betrieb: Ein Modell kann in einem Test überzeugend reagieren und trotzdem ungeeignet sein, wenn es nicht zuverlässig in vorhandene Systeme, Berechtigungen und Supportwege passt.

Für ein produktives KI-System müssen Datenpfade, Hosting, Schnittstellen, Logs, Monitoring und Eskalationen zusammenpassen. Ebenso wichtig sind Rollen: Wer darf welche Quelle anbinden? Wer genehmigt Toolzugriffe? Wer prüft, ob sich ein Modell- oder Prompt-Update auf Antworten und Folgeprozesse auswirkt? Ohne solche Entscheidungen bleibt die technische Freiheit eines offenen Modells schwer nutzbar.

Betriebsarchitektur bleibt über alle Organisationsgrößen hinweg entscheidend

Die interaktive Reportfassung zeigt bei geschlossenen Modellen Produktionsraten von 54, 66 und 73 Prozent für kleine, mittlere und große Organisationen. Bei offenen Modellen liegen die Werte bei 53, 55 und 57 Prozent. Das Muster ist auffällig, aber es bleibt eine beschreibende Umfrageauswertung. Es beweist weder, dass große Organisationen offene Modelle nicht betreiben können, noch dass Größe selbst den Unterschied erzeugt.

Zusätzliche Ressourcen ersetzen keine Betriebsarchitektur. Auch ein großes Team braucht klare Verantwortungen für Daten, Identitäten, Kosten, Updates und Störungen. Kleine Teams wiederum müssen nicht jede Schicht selbst bauen, sondern sollten die Grenzen ihres Betriebsmodells früh benennen.

Open Weights, Open Source und Ownership

Offene Gewichte sind für viele Teams attraktiv, weil sie mehr Auswahl bei Hosting und Integration ermöglichen können. Damit ist aber nicht automatisch geklärt, was an einem System offen ist. Gewichte, Trainingsdaten, Trainingscode, Lizenz, Hosting, Updatepfad und Supportmodell sind getrennte Fragen.

Für die Beschaffung heißt das: Nicht nur auf ein Label schauen. Entscheidend sind die Lizenz für den vorgesehenen Einsatz, die Verantwortung für Sicherheitsupdates, die Herkunft und Verarbeitung der Daten sowie die Möglichkeit, einen Anbieter oder eine Betriebsform später zu wechseln. Datenhoheit kann ein sinnvoller Grund für ein offenes Modell sein; sie entsteht nicht allein dadurch, dass Gewichte verfügbar sind.

Was der Agentic Harness leisten soll

Der Report verwendet den Begriff Agentic Harness für die Ebene um das Modell herum: Orchestrierung, Tools, Speicher, Ausführung, Identität, Rechte, Evaluation, Observability und Governance. Gemeint ist damit nicht ein weiteres Modell, sondern die Umgebung, die festlegt, was ein KI-System lesen, speichern und auslösen darf.

Wenn ein System Werkzeuge nutzt, liegt die Verantwortung nicht im Modell allein. Freigaben, Rollen, Budgets, Audit-Trails und Rückrufmöglichkeiten entscheiden darüber, ob ein Fehler begrenzt bleibt oder sich über verbundene Systeme ausweitet. Der Report belegt nicht, dass ein Harness die Produktivlücke schließt. Er macht sichtbar, welche Steuerungsschicht bei agentischen Anwendungen oft fehlt.

Drei Kolleginnen und Kollegen besprechen vor einer Pinnwand mit leeren Karten die Rollen und Betriebsabläufe eines technischen Systems. — Datenzugriff, Rechte, Beobachtbarkeit und Reaktion auf Störungen gehören zur Architektur eines produktiven KI-Systems.

Ein Entscheidungsrahmen für Teams in Deutschland und Europa

Workload bestimmen: Welche Aufgabe soll das System lösen, welche Qualität und welche Antwortzeit werden tatsächlich benötigt?
Daten und Hosting klären: Welche Daten dürfen verarbeitet werden, wo laufen die Komponenten und wer betreibt sie?
Lizenz und Ownership prüfen: Welche Nutzungsrechte, Abhängigkeiten, Update- und Supportzusagen gelten konkret?
Integration und Beobachtbarkeit planen: Wie werden Quellen, Logs, Monitoring, Evaluierung und Fehlerbehandlung eingebunden?
Rechte und Betrieb festlegen: Wer vergibt Berechtigungen, genehmigt Toolzugriffe, verwaltet Budgets und handelt bei Incidents?

Der Report liefert keine Deutschlandstatistik und keinen kausalen EU-Vergleich. Für Teams in Deutschland und Europa bleibt der Befund trotzdem relevant: Wer in Deutschland oder Europa Datenhoheit, Nachweisbarkeit, lokale Betriebsmodelle oder eine spätere Anbieterwahl prüft, muss diese Fragen vor dem Rollout beantworten. Die passende Architektur hängt vom Workload und vom Risiko ab, nicht von einer Lagerzugehörigkeit zu offenen oder geschlossenen Modellen.

Meine Einschätzung

Aus Sicht eines Ingenieurs beginnt Produktionsreife dort, wo das Modell nicht mehr für sich steht. Ein System muss nachvollziehbar mit Daten, Rechten, Schnittstellen und Menschen zusammenarbeiten. Offene Modelle können dabei mehr Gestaltungsspielraum geben. Sie verlagern aber auch Verantwortung in Bereiche, die ein API-Aufruf zunächst unsichtbar macht.

Die Mozilla-Zahlen sind daher weniger ein Urteil über eine Modellklasse als ein Hinweis auf die Reihenfolge der Arbeit. Zuerst sollte ein Team klären, welche Aufgabe, welche Daten und welche Betriebsgrenzen gelten. Danach lässt sich entscheiden, ob ein offenes oder geschlossenes Modell besser passt – und welche zusätzlichen Schichten für einen verlässlichen Dienst nötig sind.