Wer wissen will, wer für einen KI-Agenten haftet, muss zuerst wissen, worauf er rechnet. Die Modellbasis ist keine technische Fußnote. Sie entscheidet, wo die Daten liegen, wer im Verarbeitungspfad sitzt, welche Rechnung monatlich anfällt und wer im Schadensfall greifbar ist. Dieses Referenzstück behandelt das selbst betriebene Gegenstück zu den gemieteten Frontier-Modellen: lokale und Open-Weight-Modelle.

Die Erzählung ist in jedem zweiten Vorstandsdeck dieselbe. Frontier-Modelle sind stark, aber sie liegen bei amerikanischen Anbietern; wer Kundendaten, Mandantengeheimnisse oder Gesundheitsakten verarbeitet, holt sich stattdessen Gewichte ins eigene Rechenzentrum, hostet selbst und ist damit souverän. Die Erzählung ist attraktiv, weil sie ein Regulierungsproblem in eine Beschaffungsentscheidung übersetzt. Genau das ist ihr Fehler.

Befund 01Zwei Kurven, die in verschiedene Richtungen zeigen

Die meistzitierte Zahlenreihe zum tatsächlichen Unternehmenseinsatz stammt aus dem LLM-Marktreport von Menlo Ventures. Sie zeigt für Open-Source- beziehungsweise Open-Weight-Modelle keinen Aufstieg, sondern einen Rückgang: von 19 Prozent der Unternehmens-Workloads auf 13 Prozent innerhalb von sechs Monaten.

Zur Einordnung gehört, woher diese Zahlen kommen. Es handelt sich um eine Erhebung eines Wagniskapitalgebers auf Basis von Befragungen technischer Entscheider und ausgewerteter Nutzungsdaten – kein amtlicher Marktbericht, keine repräsentative Vollerhebung, mit einem Schwerpunkt auf amerikanischen Technologieunternehmen. Der Anbieter ist zudem selbst in dem Markt investiert, den er vermisst. Die Reihe ist trotzdem die brauchbarste öffentlich verfügbare, weil sie produktive Nutzung statt Absichtserklärungen erfasst und über mehrere Wellen methodisch konsistent bleibt. Sie ist als Trendindikator zu lesen, nicht als Statistik.

Der Report nennt drei Gründe für den Rückgang, und keiner davon ist ideologisch. Erstens ein Fähigkeitsabstand von neun bis zwölf Monaten gegenüber den Spitzenmodellen. Zweitens die technische Komplexität des Eigenbetriebs. Drittens eine ausdrückliche Zurückhaltung gegenüber APIs chinesischer Anbieter – die zugleich einen Großteil der leistungsfähigsten offenen Modelle stellen.

Parallel dazu läuft die zweite Kurve. In der europäischen Aufsichts- und Beratungsliteratur ist das selbst betriebene Open-Weight-Modell 2026 nicht mehr die exotische Option, sondern die Standardantwort auf DORA-Fragen zu IKT-Drittparteirisiken, auf Datenschutzanforderungen bei besonderen Kategorien personenbezogener Daten und auf Konzentrationsrisiken im IT-Outsourcing. In der Zuspitzung dieser Literatur gilt es für abgeschottete Umgebungen, Private Banking, Verteidigung und Behörden als die einzige vollständig prüfbare Bauform.

Diese Zuspitzung ist eine Verkaufsposition, keine technische Notwendigkeit. Prüfbarkeit entsteht durch dokumentierte Verarbeitungswege, Protokollierung und vertragliche Zusicherungen – Eigenschaften, die auch eine extern bezogene Verarbeitung haben kann, wenn sie entsprechend ausgestaltet ist. Was der Eigenbetrieb tatsächlich beseitigt, ist ein bestimmtes Risiko: die Weitergabe von Inhalten an einen Dritten, dessen Verarbeitung man nicht einsehen kann. Das ist erheblich. Es ist nicht dasselbe wie Prüfbarkeit insgesamt.

Befund 02„Open Weight“ ist nicht „Open Source“ – und der AI Act weiß das

Der sprachliche Kurzschluss beginnt beim Wort. Ein Modell, dessen Gewichte heruntergeladen werden können, ist damit nicht quelloffen im Sinne der klassischen Definition. Die Trainingsdaten bleiben in aller Regel unveröffentlicht, der Trainingscode ebenso; was offen ist, sind die Parameter des fertigen Modells. Das ist ein erheblicher Unterschied – praktisch und rechtlich.

Praktisch: Ohne Trainingsdaten lässt sich nicht prüfen, worauf ein Modell konditioniert wurde. Wer ein Modell in eine Kontrollfunktion stellt, übernimmt dessen Prägung als unbekannte Größe. Das Argument „wir hosten selbst, also kontrollieren wir“ deckt den Verarbeitungsweg ab, nicht die Prägung.

Rechtlich: Der EU AI Act knüpft seine Ausnahme für Modelle mit allgemeinem Verwendungszweck an eine freie und quelloffene Lizenz, an öffentlich verfügbare Parameter und Architektur sowie daran, dass das Modell nicht monetarisiert wird. Lizenzen mit Nutzungsbeschränkungen erfüllen das nicht. Damit fällt ausgerechnet die in Unternehmen verbreitetste Familie – Llama unter ihrer Community-Lizenz – nach überwiegender Lesart nicht unter die Ausnahme.

Die Ausnahme ist also keine Freistellung, sondern eine Verkürzung der Dokumentationspflichten – und wo sie greift, verschiebt sie Nachweislast in Richtung des Betreibers. Für ein reguliertes Haus ist das die entscheidende Pointe: Das offene Modell nimmt Abhängigkeit vom Anbieter, gibt aber Dokumentationsarbeit zurück ins eigene Haus.

Befund 03Die Betriebsrechnung, die selten aufgemacht wird

Der Kostenvergleich zwischen API und Eigenbetrieb wird meist als Token-Preis gegen Hardware-Preis geführt. Das ist die falsche Rechnung, weil sie die teuerste Position auslässt: den Betrieb.

Der zweite Punkt der rechten Spalte ist der, an dem Projekte scheitern. Ein selbst gehostetes Modell ohne eigene Evaluations- und Regressionsprüfung ist kein souveräner Betrieb, sondern ein unbeaufsichtigter. Die Kontrolle, die man dem Anbieter entzogen hat, muss jemand im Haus ausüben – sonst ist sie schlicht verschwunden.

Befund 04Das Souveränitätsparadox

Hier wird die Lage unbequem. Die leistungsfähigsten offen verfügbaren Modelle kommen in erheblichem Umfang aus China – DeepSeek, Qwen, GLM, Kimi, MiniMax. Europäische Alternativen existieren, liegen in der reinen Leistung aber zurück. Wer Souveränität an der Herkunft des Modells festmacht, landet damit in einem Zielkonflikt zwischen Fähigkeit und geopolitischer Unbedenklichkeit, der sich am Modell selbst nicht auflösen lässt.

Das Gegenargument wird meist in einem Satz zusammengefasst: Modellgewichte telefonieren nicht nach Hause. Das stimmt für die Gewichte – eine Parameterdatei enthält keinen Rückkanal. Es stimmt aber nicht automatisch für den Betrieb, in dem diese Gewichte laufen. Der Rückkanal, wenn es einen gibt, sitzt an anderer Stelle: in der Inferenz-Laufzeit und ihren Abhängigkeiten, in mitgelieferter Telemetrie, in Modell- und Container-Bezugsquellen, in Update-Pfaden, in Werkzeugen, die das Modell aufruft.

Die Aussage gilt also unter Bedingungen, und diese Bedingungen sind Betriebsarbeit: kontrollierte Laufzeitumgebung, geprüfte Abhängigkeiten, abgeschaltete Telemetrie, definierter Netzwerkausgang, nachvollziehbare Bezugsquelle der Gewichte. Wer das leistet, hat das Datenabflussrisiko gegenüber dem Modellhersteller tatsächlich beseitigt.

Was auch dann bleibt, sind Fragen der Prägung – Bias, Trainingsdatenauswahl, blinde Flecken bei bestimmten Themen. Diese Fragen sind durch Eigenbetrieb nicht gelöst, sondern in die eigene Verantwortung übernommen.

Die Unterscheidung ist für die Aufsichtsdiskussion zentral. Ein Datenabflussrisiko wird durch Eigenbetrieb tatsächlich beseitigt. Ein Prägungsrisiko wird durch Eigenbetrieb nicht beseitigt, sondern nur in die eigene Verantwortung überführt. Wer beides in einen Topf wirft, verkauft Hosting als Governance.

Befund 05Souveränität ist eine Architekturfrage, keine Modellwahl

DORA verlangt beherrschbare IKT-Drittparteirisiken, dokumentierte Ausstiegsstrategien und die Fähigkeit, kritische Dienstleister zu ersetzen. Die BaFin hat Konzentrationsrisiken im IT-Outsourcing – ausdrücklich auch mit Blick auf große US-Cloud-Anbieter – auf die Aufsichtsagenda gehoben. Keine dieser Anforderungen ist mit der Auswahl eines bestimmten Modells erfüllt. Alle sind mit Austauschbarkeit erfüllt.

Damit verschiebt sich die entscheidende Bauentscheidung eine Ebene nach unten: nicht welches Modell, sondern wie fest die Anwendung an ein Modell gebunden ist. Ein Haus, das seinen Agentenbetrieb innerhalb von Tagen von einem Frontier-Anbieter auf ein selbst gehostetes Modell umstellen kann, ist souverän – unabhängig davon, worauf es heute tatsächlich rechnet. Ein Haus, dessen Prompts, Evals und Tool-Definitionen auf ein einziges Modell zugeschnitten sind, ist es nicht, auch wenn dieses Modell im eigenen Keller steht.

Watchdog-WinkelWas das für FinCrime-Agenten bedeutet

In der Geldwäsche- und Betrugsbekämpfung treffen beide Fronten aufeinander. Die Datenklasse ist maximal sensibel: Kundenstammdaten, Transaktionshistorien, Verdachtsmomente, in Teilen Strafverfolgungsrelevanz. Gleichzeitig ist die Aufgabe anspruchsvoll genug, dass der Fähigkeitsabstand von neun bis zwölf Monaten spürbar wird – bei der Bewertung mehrdeutiger Alerts kann Reasoning-Tiefe die Fehlalarmquote beeinflussen.

Der Ausweg, den Architekturberatung und Anbieterunterlagen übereinstimmend empfehlen, heißt hybrid: ein Router entscheidet pro Anfrage nach Datenklasse, Kostenprofil und Policy, welches Modell rechnet. Öffentliche Rechercheaufgaben und Regulierungstexte gehen an das Frontier-Modell, personenbezogene Kunden- und Transaktionsdaten an das lokale.

Wie verbreitet diese Bauform im Produktivbetrieb tatsächlich ist, lässt sich derzeit nicht belegen – Erhebungen zur Verbreitung von Routing-Architekturen in regulierten Häusern liegen nicht vor. Dieses Dossier führt „hybrid“ deshalb als Befund pro Branche und nicht als Grundannahme. Sicher ist nur die Konsequenz für den Fall, dass geroutet wird: Sie verlagert die Kontrollfrage ein weiteres Mal.

Damit steht dieses Referenzstück wieder bei der Leitfrage des Dossiers. Ein Agent, der handelt, braucht eine Zuordnung: welches Modell, unter welcher Lizenz, in wessen Rechenzentrum, mit welcher Protokollierung, unter wessen Verantwortung. Die Modellbasis ist der erste Eintrag in diesem Datensatz. Ohne sie ist jede Aussage über Haftung und Kontrolle eine Vermutung.