Warum der Zugang zu KI und nicht die Leistungsfähigkeit das eigentliche Abhängigkeitsrisiko darstellt.

Was unterscheidet eigentlich das Mieten von KI-Intelligenz vom Besitzen derselben?

Etwa drei Jahre lang konzentrierte sich die Branche völlig auf den falschen Messwert.

Es gab heftige Debatten über Benchmarks, Denkfähigkeit, Halluzinationsraten sowie die Größe des Kontextfensters – alles Indikatoren dafür, wie intelligent diese Systeme waren.

Doch die wichtigere Frage heute lautet anders: Wer besitzt den Schalter, mit dem diese Intelligenz ausgeschaltet werden kann?

Am 12. Juni 2026 führte die US-Regierung Exportbeschränkungen für zwei der neuesten Modelle von Anthropic ein, nämlich Claude Fable 5 und Claude Mythos 5.

Durch diese Anordnung musste Anthropic den Zugang für Ausländer sperren, unabhängig davon, ob sie sich physisch innerhalb oder außerhalb der Vereinigten Staaten aufhielten.

Anthropic gab an, keinen zuverlässigen Weg zu haben, um die Nationalität in Echtzeit zu überprüfen.

Angesichts dieser Situation unternahm das Unternehmen einen drastischen Schritt: Es deaktivierte beide Modelle für alle Ausländer, einschließlich der Mitarbeiter im eigenen Unternehmen.

Achtzehn Tage vergingen, bevor die Regierung die Beschränkungen aufhob. Fable 5 wurde am 1. Juli weltweit wieder online gestellt, während Mythos 5 für eine bestimmte Gruppe von US-Organisationen nach der Genehmigung durch die Regierung am 26. Juni wieder aktiviert wurde.

OpenAI folgte anschließend fast dem gleichen Weg, startete jedoch von der entgegengesetzten Seite aus.

Am 26. Juni brachte OpenAI GPT-5.6 auf den Markt, beschränkte die Verfügbarkeit jedoch auf Wunsch der Regierung zunächst auf eine kleine, im Voraus geprüfte Gruppe von Partnern, deren Identitäten bereits den Behörden mitgeteilt worden waren. OpenAI machte öffentlich klar, dass es nicht wünsche, dass diese Art einer von der Regierung vermittelten Einführung künftig zur Standardpraxis wird.

Bis zum 9. Juli stand GPT-5.6 allen zur Verfügung.

Betrachten Sie, was diese Abfolge tatsächlich aufdeckt.

Nichts wurde durch fehlerhaften Code beschlagnahmt, gelöscht oder gestört.

Trotzdem waren für eine Weile einige der leistungsstärksten kommerziellen KI-Systeme, die es gibt, technisch funktionsfähig, aber fur die Nutzer unerreichbar, die sie benötigten.

Dieser ganze Vorfall fügt eine weitere Schicht zum anhaltenden Streit über das Tempo der KI-Entwicklung hinzu – es geht nicht mehr nur darum, wie schnell wir die Leistungsfähigkeit vorantreiben sollten, sondern auch darum, wie sorgfältig der Rollout und der Zugang sequenziert werden sollten.

Die eigentliche Lektion ist nicht, dass der Zugang verschwindet. Vielmehr verhält sich der Zugang wie eine unabhängige Variable, die von der Leistungsfähigkeit selbst getrennt ist, von ihrer eigenen Logik angetrieben wird, nach ihrem eigenen Zeitplan abläuft und in jede Richtung schneller umschlagen kann, als irgendeine Organisation reagieren kann.

Das ist eine weitaus beunruhigendere Realität als ein langsam schließendes Fenster, denn bei einem schrumpfenden Fenster kann man planen. Bei einem administrativ umgeschalteten Schalter, der in unvorhersehbaren Richtungen und im Zeitraum von Tagen umgeschaltet wird, ist Planung nicht möglich.

Daher stellt sich die folgende Frage, mit der man sich auseinandersetzen sollte: Wenn das Modell, auf dem Sie angewiesen sind, über Nacht verschwinden würde, würde Ihre Arbeit dann weiterbestehen?

Eigentum ist kein Download

Wenn Menschen Abhängigkeit wahrnehmen, ist ihre erste Reaktion, etwas zu beschaffen.

Sie holen sich die offenen Gewichte, speichern sie auf einer Festplatte und glauben, nun beruhigt sein zu können. Doch das Besitzen einer Parametergruppe deckt nur einen winzigen Teil dessen ab, was wahre Unabhängigkeit erfordert, und die Verwechslung beider führt zu einer bestimmten Art von falschem Sicherheitsgefühl – dem künstlichen-Intelligenz-Äquivalent dazu, einen Notstromgenerator zu kaufen und niemals zu überprüfen, ob er funktioniert.

Ein funktionsfähiger Agent, der sinnvolle Arbeit leistet, besteht tatsächlich aus mindestens fünf Komponenten: den Modellgewichten selbst, dem Inferenzmotor, der sie ausführt, dem angesammelten Projektkontext, den Tools, die er aufrufen kann, sowie dem Bewertungssystem, das anzeigt, ob ein Ersatz tatsächlich seine Aufgabe erfüllt.

Die heruntergeladene Modelldatei ist nur ein Teil dieses Stackes.

Echte Unabhängigkeit erfordert das rechtliche Recht, das Modell zu betreiben, einen Inferenz-Runtime, den man allein aus der Dokumentation neu aufbauen kann, einen Projektzustand, den man frei exportieren kann, Tool-Rechte, die unter der Kontrolle der eigenen Anwendung und nicht eines Anbieters liegen, sowie Beweise dafür, dass ein Ersatzsystem die Arbeit tatsächlich abschließen kann.

Bereits die rechtliche Dimension ist komplizierter, als sie auf den ersten Blick erscheint.

"Open weights" und "open source" sind keine austauschbaren Begriffe – die Definition der Open Source Initiative verlangt weitaus mehr als nur die Möglichkeit, Parameter herunterzuladen, und eine liberale Lizenz für die Laufzeit deckt nicht automatisch jedes Modell ab, das damit ausgeführt wird.

Man muss die spezifische Lizenz, die jedes Artefakt regelt, tatsächlich lesen und eine Kopie davon zusammen mit diesem Artefakt archivieren.

Das Eigentum an Daten liegt auf einer völlig separaten Ebene. Nach den kommerziellen Bedingungen von Anthropic behalten Kunden die Rechte an allem, was sie einreichen, besitzen das Eigentum an den daraus resultierenden Ergebnissen zwischen den beiden Parteien, und es ist Anthropic untersagt, mit dem Kundeninhalt über diese Dienste zu trainieren. Allein das Versenden Ihres Inhalts an einen Anbieter überträgt nicht das Eigentum auf diesen. Ob dieser Inhalt danach aufbewahrt wird, ist eine weitere eigene Frage, und die Antwort hängt vom genauen Produkt, Vertrag und Konfiguration ab – nicht davon, was man zufällig einmal irgendwo gelesen hat.

All das ist kein Argument dagegen, gehostete Modelle zu verwenden.

Es handelt sich einfach um eine Erinnerung daran, dass der Satz „Wir besitzen unsere KI“ fünf oder sechs separate Bedingungen beinhaltet, die jeweils erfüllt sein müssen, und die meisten Teams machen sich nie die Mühe, irgendwelche davon zu überprüfen.

Die Arithmetik der Selbstversorgung

Die Berechnung, wie viel Speicher ein Modell benötigt, ist der einfache Teil der Gleichung: Man nimmt die Anzahl der Parameter, multipliziert sie mit der Anzahl der Bits pro Parameter und teilt durch acht.

Ein Modell mit acht Milliarden Parametern bei einer Präzision von sechzehn Bit benötigt etwa sechzehn Gigabyte; bei einer Präzision von vier Bit reduziert sich dieser Wert auf etwa vier Gigabyte. Ein Modell mit siebzig Milliarden Parametern verbraucht bei sechzehn Bit etwa hundertvierzig Gigabyte oder rund fünfunddreißig Gigabyte bei vier Bit.

Meistens hören die Leute hier auf, über die Hardwareanforderungen nachzudenken – und es ist auch genau diese Berechnung, die am häufigsten richtig gelingt.

Die wahren Fehler treten später in der Verarbeitungskette auf.

Der KV-Cache – die Struktur, die den Aufmerksamkeitszustand über ein Gespräch hinweg speichert – wächst mit längeren Kontextfenstern und skaliert außerdem bei jeder gleichzeitigen Anfrage, die bearbeitet wird.

Mischarchitekturen aus Experten bringen ihre eigenen Herausforderungen mit sich: Da jedes Token nur einen Teil des Netzwerks aktiviert, bleibt die tatsächliche Rechenleistung pro Token gering, doch jeder Experte, egal ob aktiv oder nicht, muss dennoch irgendwo im Speicher untergebracht werden.

Die Anzahl der aktivierten Parameter gibt Aufschluss über die Verarbeitungskosten pro Token – sie sagt jedoch nichts darüber aus, wie viel Speicherplatz das Modell einnimmt.

Das Auslagern von Teilen des Modells an einen anderen Ort beseitigt das Speicherproblem nicht, es verschiebt es lediglich – und nun entstehen zusätzliche Kosten für den Datentransfer, die zuvor nicht vorhanden waren.

Ein Modell, das erfolgreich in den Speicher geladen wird, hat noch nicht bewiesen, dass es tatsächlich Anfragen bearbeiten kann.

Die Verarbeitungsgeschwindigkeit eines Prompts, die Generierungsgeschwindigkeit sowie die Gesamtzeit bis zur Erledigung einer Aufgabe sind drei separate Kennzahlen, und eine schnelle Einverarbeitung eines Prompts sagt nichts darüber aus, wie schnell eine lange Antwort generiert wird.

Die wirklich wichtige Arbeitslast ist die anspruchsvolle – große Dokumente, mehrere gleichzeitige Benutzer sowie Toolaufrufe, die sich immer wieder hin und her schalten.

Tests mit einem einzigen kurzen Prompt verbergen genau die Art von Warteschlangenverzögerungen und Speicherkonflikten, die eine lokale Inferenz unangenehm machen, sobald mehrere Personen sie nutzen.

Was all diese Fehler miteinander verbindet, ist ein Muster: Jeder von ihnen nimmt eine Zahl, die leicht zitiert werden kann, und hält sie fälschlicherweise für den eigentlichen Engpassfaktor.

Führen Sie Ihre eigenen Benchmarks auf der Hardware durch, die Sie bereits besitzen, oder mieten Sie Rechenzeit mit genau der Konfiguration, die Sie bewerten möchten, bevor Sie sich entscheiden.

Die Kaufkraft zu erhöhen, bevor man erkannt hat, wo sich das eigentliche Engpassproblem befindet, ist eine gute Möglichkeit, dafür zu sorgen, dass dieses Problem weiterhin bestehen bleibt.

Ein Prompt ist keine Genehmigung

Der wichtigste Missverständnis bei der Konzeption von Agenten hat fast nichts mit dem Modell zu tun, das man verwendet.

Wenn ein Modell einen Tool-Aufruf generiert, handelt es sich dabei um eine Anfrage – nichts weiter.

Ein separates Mechanismus muss entscheiden, ob diese Anfrage tatsächlich ausgeführt wird.

Es ist überraschend einfach, ein System zu entwickeln, in dem dieser separate Mechanismus funktional lediglich darin besteht, dass das Modell sich selbst vertraut – wobei eine höfliche Anweisung im Prompt es dazu auffordert, sich an Grenzen zu halten.

Das ist eine Präferenz, keine echte Grenze, und genau solche Präferenzen werden von Prompt-Injection-Angriffen ausgenutzt.

Alles, was der Agent von externen Quellen abruft, gilt als unzuverlässige Eingabe.

Eine README-Datei kann Anweisungen enthalten, die an Ihren Agenten gerichtet sind. Ebenso können es Kommentare im Quellcode, der Inhalt eines Issue-Trackers oder eine gewöhnliche Webseite sein.

Die Lösung liegt nicht in klügeren Anweisungen, sondern in einem strengeren Berechtigungsmodell: Der Zugriff soll auf eine genehmigte Liste von Pfaden beschränkt werden statt auf den gesamten Dateisystem, die Dateigrößen begrenzt, kontrolliert werden, was geschrieben werden darf, Tests in einer temporären Umgebung ausgeführt werden, die Bereitstellungsanmeldeinformationen außerhalb der Reichweite des Worker-Prozesses gehalten werden und ein Mensch muss jeden Patch vor dem Versand in die Produktion überprüfen.

Das Ausführen eigener lokaler Inferenzverarbeitung und das Einschränken der Berechtigungen von Tools sind zwei verschiedene Probleme – es ist verlockend anzunehmen, dass die Lösung eines auch das andere behebt.

Durch das Eigenhosting der Gewichte bestimmt man, wo die Daten physisch gespeichert sind und ob das System von der Online-Verfügbarkeit eines anderen Unternehmens abhängt. Dies hat keinerlei Einfluss darauf, welche Aktionen der Agent tatsächlich ausführen darf.

Teams, die diese beiden Aspekte miteinander verwechseln, erhalten letztendlich ein vollständig selbst gehostetes Modell, das dennoch unbegrenzten Schaden an ihrer eigenen Codebasis anrichten kann.

In der Größenordnung eines ganzen Teams führt dieselbe Logik dazu, ein authentifiziertes Gateway vor den Inferenz-Endpunkt zu platzieren, Nutzungsbudgets pro Benutzer festzulegen und für jeden Workflow eine klare Richtlinie zu definieren – lokal ausführen, ein erlaubtes gehostetes Modell nutzen oder die Aufgabe an einen Menschen zur Überprüfung weiterleiten.

Speichern Sie Checkpoints, bevor Sie fehlgeschlagene Schritte erneut ausführen, und gestalten Sie alle Tools mit Nebenwirkungen so, dass sie idempotent sind, damit ein Wiederherstellungsversuch keine bereits ausgeführte Aktion heimlich wiederholt.

Warum die Zuverlässigkeit gegen Sie arbeitet

Stellen Sie sich vor, jeder Schritt in einem agierenden Workflow hat eine unabhängige Erfolgschance von 95 Prozent. Wenn man zehn solcher Schritte nacheinander verknüpft, liegt die Gesamterfolgsrate bei etwa sechzig Prozent – 0,95 hoch zehn ergibt ungefähr 0,599.

Erhöht man die Anzahl der Schritte auf zwanzig, sinkt die Rate auf etwa dreißig-six Prozent.

Reale Schritte sind nicht wirklich unabhängig, daher sollte dies eher als Veranschaulichung denn als präziser Vergleichswert angesehen werden. Dennoch zeigt es etwas, was keine Qualität des Modells rückgängig machen kann: Die Zuverlässigkeit pro Schritt addiert sich nicht, sondern multipliziert sich – und zwar exponentiell mit der Länge der Kette.

Steigt die Zuverlässigkeit pro Schritt von 95 Prozent auf 98 Prozent, steigt die Erfolgsrate bei einer zehnschrittigen Abfolge von 60 Prozent auf 82 Prozent. Fügen Sie jedoch zehn weitere Schritte zu einem Prozess hinzu, der bereits eine Zuverlässigkeit von 95 Prozent hat, wird dieser gesamte Gewinn wieder aufgehoben.

Das verändert das, was man eigentlich von einem kleinen lokalen Modell erwarten sollte. Seine eigentliche Aufgabe besteht nicht darin, brillant zu sein – sondern darin, in einem Workflow, der kurz ist, eng gefasst, leicht überprüfbar und bei Fehlern einfach wiederherstellbar, zuverlässig zu funktionieren.

Und was entscheidend ist: Die Anzahl der Schritte in diesem Workflow wird nicht durch die Gewichte des Modells bestimmt. Es handelt sich dabei um eine Gestaltungsauswahl, die man bei der Entwicklung der Anwendung trifft.

Durch Kürzung der Prozesskette, Überprüfung der Zwischenergebnisse sowie Einbau von Kontrollpunkten, sodass bei einem Fehler der Prozess fortgesetzt statt von vorne begonnen werden kann, erhält man in der Regel mehr Zuverlässigkeit als durch den Einsatz eines größeren Modells.

Deshalb kann die Bewertung auch nicht vage oder auf Anekdoten beruhen.

Nehmen Sie fünfzig Aufgaben aus Ihrem tatsächlichen Backlog – jede mit einem erwarteten Ergebnis, das an einem Ort aufgezeichnet ist, den der Agent weder schreiben noch verändern kann.

Überwachen Sie die Richtigkeit – ob die Tool-Aufrufe gültig waren, die Latenzzeit, wie viele Wiederholungsversuche nötig waren sowie wie viel Zeit ein Mensch später zum Beheben der Probleme aufwandte – all das wird bei realistischen Datenvolumina und Konkurrenzniveaus gemessen und anhand von von Ihnen vorher festgelegten Schwellenwerten bewertet, um herauszufinden, welches Modell vorteilhaft ist.

Eine Unterscheidung verdient in Ihrer Telemetrie eine eigene Spalte: Ein unerreichbares Modell und ein Modell, das eine schlechte Antwort liefert, stellen grundlegend unterschiedliche Fehler dar.

Der erste ist ein Routing- und Wiederherstellungsproblem. Der zweite ist ein Qualitätsproblem.

Falls man sie zu einer einzigen Erfolgsquote zusammenfasst, geht genau die Information verloren, die verrät, ob die eigentliche Lösung mehr Kapazität, ein besseres Modell oder eine kleinere, eingeschränktere Aufgabe erfordert.

Was Sie tatsächlich kaufen

Der einzige vergleichbare Wert ist der Kosten pro akzeptierter Aufgabe.

Der Vergleich der Token-Preise vergleicht Dinge, die nicht gleich sind; der Vergleich der akzeptierten Arbeiten hingegen vergleicht Dinge, die es sind. Auf der lokalen Seite bestehen Ihre Kosten aus Abschreibungen des Hardwares, Stromkosten, Wartungskosten, Inaktivitätszeiten sowie Aufwand für die Überprüfung. Bei der Hosted-Lösung sind es Tokenkosten, Wiederholungsversuche und Aufwand für die Überprüfung.

Führen Sie auf beiden Seiten dieselbe Mischung an Aufgaben unter derselben Akzeptanzschwelle durch – alles Andere macht den Vergleich zu einer Farce.

Die Mathematik ergibt das Ergebnis, das man erwarten würde.

Nehmen wir an, die lokale Infrastruktur verursacht monatlich feste Kosten von sechshundert Dollar, wobei jede lokal akzeptierte Aufgabe zwei Cent kostet, während eine über eine Hosted-API akzeptierte Aufgabe zwanzig Cent kostet. Der Break-Even-Punkt liegt bei etwa 3.333 akzeptierten Aufgaben pro Monat.

Diese Zahlen dienen nur zur Veranschaulichung und sind nicht gemessen, doch das zugrundeliegende Muster bleibt unverändert: Die lokale Ausführung von Inferenz ist ein Investitionsvorhaben mit festen Kosten, das erst dann rentabel wird, wenn eine bestimmte Menge an Aufgaben erreicht ist – darunter führt es zu Verlusten.

Die meisten Teams bleiben unter dieser Schwelle.

Genau hier weicht die ehrliche Einschätzung bezüglich lokaler KI stark von den Marketingversprechen ab.

Unter dem Break-Even-Punkt ist die lokale Inferenz nicht die günstigere Option, und wer das behauptet, macht die Entscheidung unzureichend begründbar, sobald jemand tatsächlich die Zahlen prüft.

Was man eigentlich kauft, ist vielmehr die Option – die Garantie, weiterhin arbeiten zu können, selbst wenn sich die Zugangsbedingungen ändern, unter Bedingungen, die man selbst kontrolliert.

Optionen werden nach ihrer Volatilität, nicht nach erwarteten Durchschnittsergebnissen, bewertet.

Falls die jüngsten Störungen etwas gezeigt haben, dann, dass diese Volatilität echt ist, dass sie aus administrativen Entscheidungen und nicht aus technischen resultiert sowie ohne Vorwarnung auftritt.

Das ist ein berechtigter Grund, Geld auszugeben.

Aber es handelt sich um einen anderen Grund als den, der üblicherweise angegeben wird, und er verdient es, aufgrund seiner eigenen Merkmale verteidigt zu werden, anstatt als Kostensenkungsmaßnahme getarnt zu werden.

Der Test, der tatsächlich etwas aussagt

Davon hängt nichts davon ab, dass man glaubt, Skalengesetze würden weiterhin gelten, dass ein bestimmtes Zugriffsfenster tatsächlich schließt oder dass AGI letztendlich in eine bestimmte Menge an VRAM passt oder nicht.

Das sind Vorhersagen, und das Risiko der Abhängigkeit erfordert nicht, dass sie wahr sind.

Alles, was dazu erforderlich ist, ist das Bewusstsein dafür, dass ein System, auf das man sich verlässt, aus Gründen ausfallen kann, die nichts mit seiner Leistung oder dem eigenen Verhalten zu tun haben. Das galt bereits für Stromnetze, Unterwasserkabel und Zahlungsnetzwerke – und gilt nun eindeutig auch für fortschrittliche KI-Modelle.

Die praktische Lösung ist nicht besonders aufregend. Im Wesentlichen bedeutet sie, Fähigkeiten zu erlernen, die man derzeit als selbstverständlich hinnimmt oder annimmt, dass jemand anderes sie bereits erledigt hat.

Probieren Sie Folgendes aus: Bauen Sie Ihren Stack vollständig neu auf, basierend auf allen Notizen und Backups, die Sie gespeichert haben, und übergeben Sie anschließend genau diese Notizen einem anderen Ingenieur. Beobachten Sie, wie dieser versucht, den Stack unabhängig wieder aufzubauen. Diese eine Übung lehrt Sie mehr darüber, wie selbstständig Sie tatsächlich sind, als jede Anzahl von reibungslosen Gesprächen mit einem heute verfügbaren Modell. Die Tatsache, dass ein Modell gerade jetzt verfügbar ist, sagt nichts über morgen aus – der einzige echte Beweis für Widerstandsfähigkeit ist, ob Ihre Einrichtung auch ohne es funktioniert.

Verwandte Artikel

• ReAct erklärt: Wie KI-Agenten Denken mit Handlungen in der realen Welt verbinden – Erfahren Sie, wie das ReAct-Framework Denken und Werkzeugnutzung miteinander verbindet, um KI-Agenten zu unterstützen, und wie es sich von Chain-of-Thought-, RL- sowie Denkmodellen unterscheidet.

Agentic AI Explained: Von Sprachmodellen zu autonomen Agenten — Eine strukturierte Erklärung, wie LLMs durch Werkzeuge, Speicherfunktionen, Planungsmöglichkeiten, mehragentige Architekturen sowie MCP-Integration zu agierenden Systemen werden.

Wenn KI Ihre React-App schreibt, aber die Prinzipien des sauberen Codes ignoriert — Lernen Sie sieben Gewohnheiten des sauberen Codes – DRY-Prinzip, Einzelverantwortungsprinzip, Schutzklauseln und mehr – die in von KI generiertem React-Code oft missachtet werden, sowie wie man sie behebt.