KI-Abhängigkeit als Compliance-Risiko: Was der Anthropic-Fall jeden CTO lehrt

1. Der Weckruf: Was am 12. Juni 2026 passierte

Es war kein Serverausfall, kein Bug, kein Angriff. Es war ein Brief.

Um 17:21 Uhr Ortszeit erhielt Anthropic eine Anweisung des US-Handelsministeriums, unterzeichnet von Minister Howard Lutnick: Die Modelle Fable 5 und Mythos 5 seien sofort für alle ausländischen Staatsangehörigen zu sperren, unabhängig davon, ob sie sich in den USA oder anderswo befanden. Wenige Stunden später sahen Entwickler weltweit dasselbe Bild: ihre API-Aufrufe wurden mit einem schlichten Fehler 404 beantwortet.

Keine Übergangsfrist. Keine Migration. Keine Ausnahme.

Für Teams, die ihre Produktionsprozesse auf diese Modelle aufgebaut hatten, bedeutete das: Systeme stehen still, Kunden bemerken es, Erklärungen müssen her, und ein Plan B existiert nicht.

Was auf den ersten Blick wie ein politisches Ereignis wirkt, ist aus operativer Sicht ein Infrastrukturausfall besonderer Art. Anders als ein Rechenzentrum, das abbrennt, oder ein Dienst, der überlastet ist, kam dieser Ausfall nicht aus dem System heraus, sondern von außen, per Dekret, ohne technische Vorwarnung. Und er traf nicht nur ein Unternehmen: Er traf jeden, der dieses Modell in irgendeiner Form genutzt hat.

2. Warum das kein Einzelfall ist, sondern ein Systemrisiko

Es wäre bequem, diesen Vorfall als Ausreißer abzutun. Ein besonders leistungsfähiges Modell, eine besonders aufgeheizte politische Lage, ein unglückliches Timing. Das Problem: Alle drei Faktoren werden in den nächsten Jahren zunehmen, nicht abnehmen.

Der Anthropic-Fall ist der erste dokumentierte Einsatz von US-Exportkontrollrecht gegen ein kommerziell verbreitetes Sprachmodell. Aber die rechtliche Infrastruktur für weitere Eingriffe dieser Art steht längst. Das Bureau of Industry and Security kann Exportlizenzen für KI-Technologien verlangen. Die EU treibt mit dem EU AI Act einen eigenen regulatorischen Rahmen voran, der Hochrisiko-Anwendungen mit Auflagen belegt. Und geopolitische Spannungen rund um Halbleiter, Trainingsdaten und Modellarchitekturen nehmen zu.

Das bedeutet: Wer KI in seine Infrastruktur integriert, ist mindestens vier verschiedenen Abhängigkeitsrisiken ausgesetzt:

Regulatorisches Risiko. Ein Modell, das heute zugelassen ist, kann morgen unter Exportkontrolle fallen, als Hochrisiko-System eingestuft werden oder schlicht nicht mehr den Anforderungen einer neuen Richtlinie entsprechen.

Geopolitisches Risiko. KI-Modelle sind zunehmend Gegenstand außenpolitischer Auseinandersetzungen. Der Zugriff auf bestimmte Technologien kann von staatlichen Akteuren gezielt eingeschränkt werden, als Druckmittel, als Schutzmaßnahme oder, wie im Anthropic-Fall, auf Basis einer singulären Sicherheitsbewertung.

Technisches Risiko. Modelle werden deprecated, APIs ändern sich, Anbieter stellen Dienste ein oder verändern ihr Angebot. Was heute funktioniert, ist morgen nicht mehr garantiert.

Vertragliches Risiko. Die meisten Nutzungsbedingungen großer KI-Anbieter enthalten weitreichende Klauseln, die eine Einschränkung oder Einstellung des Dienstes ohne Haftung erlauben. Das ist kein böser Wille, sondern die Realität einer Technologie, die noch keine stabilen rechtlichen Rahmenbedingungen kennt.

Keines dieser Risiken ist neu. Jedes einzelne davon ist bekannt und gut beschreibbar. Was fehlt, ist die konsequente Einordnung von KI-Abhängigkeiten in das bestehende Risikomanagement-Framework eines Unternehmens.

3. Die versteckte Abhängigkeit in eurer Tech-Architektur

Die meisten Unternehmen wissen nicht genau, wie tief KI in ihre Prozesse eingebettet ist.

Das klingt provokant, trifft aber eine strukturelle Realität: KI-Integration passiert oft inkrementell. Ein Team bindet ein Modell für die Zusammenfassung von Dokumenten ein. Ein anderes nutzt es für die automatisierte Kategorisierung von Support-Anfragen. Die Produktentwicklung integriert es in ein Feature, das Kunden schätzen. Jede dieser Entscheidungen ist für sich genommen sinnvoll, aber in der Summe entsteht eine Abhängigkeit, die niemand vollständig überblickt.

Die entscheidende Frage ist nicht: "Nutzen wir KI?" Sondern: "Was passiert, wenn das Modell morgen nicht mehr verfügbar ist?"

Konkret bedeutet das:

• Welche eurer Kernprozesse laufen nicht mehr, wenn die KI-API einen 404 zurückgibt?
• Welche Versprechen habt ihr euren Kunden gegenüber gemacht, explizit in SLAs oder implizit im Produkt, die ihr ohne das Modell nicht halten könnt?
• Wie lange würde es dauern, auf einen alternativen Anbieter zu migrieren? Stunden, Tage, Wochen?
• Habt ihr das jemals konkret getestet?

Für viele Teams sind das unangenehme Fragen, nicht weil die Antworten katastrophal wären, sondern weil sie schlicht unbekannt sind. Und unbekannte Abhängigkeiten sind gefährlicher als bekannte Risiken, egal wie groß.

4. Wie Risikomanagement hier konkret aussieht

Gutes Risikomanagement im KI-Kontext ist keine akademische Übung. Es ist eine Reihe konkreter Architektur- und Prozessentscheidungen, die man treffen kann, bevor der Ernstfall eintritt.

Abstraction Layer einbauen. Der wirksamste Schutz gegen Anbieterabhängigkeit ist ein sauberer Abstraction Layer zwischen eurer Anwendung und dem KI-Modell. Wer seine Prompts, seine Datenaufbereitung und seine Output-Verarbeitung modell-agnostisch gestaltet, kann einen Anbieter austauschen, ohne die gesamte Architektur anfassen zu müssen. Das ist kein großes Projekt, es ist eine Designentscheidung, die am Anfang getroffen werden sollte.

Alternativen vorab testen, nicht erst im Notfall. Ein Fallback-Anbieter, den man nie getestet hat, ist kein Fallback, er ist eine Hoffnung. Wer ernsthaft auf Resilienz setzt, hat einen oder zwei alternative Anbieter identifiziert, deren Outputs auf den eigenen Anwendungsfall geprüft und die Integration zumindest einmal durchgespielt. Das kostet Zeit. Es kostet deutlich weniger als ein ungeplanter Ausfall unter Produktionsbedingungen.

SLAs und Verträge auf KI-Ausfallszenarien prüfen. Die meisten KI-Nutzungsverträge schließen Haftung für Dienstunterbrechungen weitgehend aus. Das ist faktisch akzeptiert, aber es bedeutet, dass ihr das Risiko vollständig selbst tragt. Wenn ihr euren Kunden gegenüber SLAs habt, die von KI-Verfügbarkeit abhängen, müsst ihr diese Lücke explizit adressieren: entweder durch vertragliche Anpassungen, durch technische Redundanz oder durch klare Ausnahmeregeln in euren eigenen Bedingungen.

Kritikalitätsbewertung einführen. Nicht jeder KI-Einsatz ist gleich kritisch. Eine KI, die Entwürfe für interne Dokumente erstellt, hat ein anderes Risikoprofil als eine KI, die automatisiert Compliance-Berichte generiert, auf die Kunden sich verlassen. Eine ehrliche Kategorisierung, welche Prozesse dürfen KI-abhängig sein, welche brauchen einen menschlichen Fallback, welche müssen KI-frei bleiben, ist die Grundlage für alles weitere.

Monitoring und Frühwarnsignale definieren. Regulatorische Entwicklungen im KI-Bereich sind selten vollständige Überraschungen. Der Anthropic-Fall hatte Vorläufer: Das US-Verteidigungsministerium hatte das Unternehmen Monate zuvor als "supply chain risk" eingestuft. Wer die relevanten regulatorischen und geopolitischen Entwicklungen beobachtet, EU AI Act, US-Exportkontrolle, nationale KI-Strategien, hat zumindest einen Informationsvorsprung, wenn sich Risiken konkretisieren.

5. Wie wir das bei Kopexa handhaben

Wir predigen das nicht nur, wir leben es. Kopexa setzt selbst Agentic AI in der Plattform ein, also sind wir genau der Fall, über den dieser Artikel spricht: ein Unternehmen, dessen Produkt von KI-Modellen abhängt. Deshalb behandeln wir unsere eigenen KI-Abhängigkeiten nach denselben Regeln, die wir Kunden empfehlen, und mit denselben Werkzeugen, die die Plattform bereitstellt.

Jeder KI-Anbieter ist ein Asset und ein Vendor. Die Modelle, von denen unsere Features abhängen, stehen in unserem Asset-Register und im Lieferantenmanagement, nicht in einer Notiz, die niemand findet. Erst dadurch wird die Abhängigkeit überhaupt sichtbar und steuerbar.

Die Abhängigkeit ist ein bewertetes Risiko. Im Risikomanagement ist der Ausfall oder die Sperrung eines KI-Anbieters als eigenes Risiko erfasst, mit Kritikalität, Auswirkung und Eintrittswahrscheinlichkeit, einem Verantwortlichen und einer hinterlegten Maßnahme. Das ist gelebtes Third-Party Risk Management, kein Bauchgefühl.

Das Risiko ist mit den Frameworks verknüpft. Über den OSCAL-nativen Katalog hängt diese eine Abhängigkeit gleichzeitig an den passenden Controls aus ISO 27001, NIS2 und DORA. Einmal bewerten, überall nachweisen.

Abstraction Layer, Fallbacks und Klauseln sind dokumentierte Nachweise. Unser modell-agnostischer Abstraction Layer, die getesteten Alternativ-Anbieter und die relevanten Vertragsklauseln liegen als Evidence am Risiko, nicht im Kopf einer einzelnen Person. Ändert sich der Schutzbedarf, werden die Verantwortlichen automatisch benachrichtigt.

Der eigentliche Punkt: KI-Risikomanagement braucht kein neues Tool und kein neues Silo. Es braucht einen Ort, an dem die Abhängigkeit als Asset steht, als Risiko bewertet und an die bestehenden Compliance-Anforderungen geknüpft ist.

6. Was das mit Compliance zu tun hat, und warum es auf euren Tisch gehört

Spätestens hier sollte klar sein: KI-Abhängigkeit ist kein reines Tech-Thema. Es ist ein Risiko, das systematisch in bestehende Compliance-Frameworks gehört, und das in den meisten Unternehmen dort noch nicht angekommen ist.

Nehmt NIS2 als Beispiel. Die Richtlinie verpflichtet betroffene Unternehmen unter anderem zur Absicherung ihrer Lieferkette und zur Implementierung von Business-Continuity-Maßnahmen. Ein KI-Anbieter, auf den kritische Prozesse angewiesen sind, ist ein Lieferant, und ein Ausfall dieses Anbieters ist ein Continuity-Ereignis. Wer NIS2-konform sein will, muss diese Abhängigkeit analysiert, bewertet und mit Maßnahmen hinterlegt haben.

Dasselbe gilt für ISO 27001: Das ISMS verlangt eine systematische Risikoidentifikation und -bewertung. KI-Anbieter, die in Produktionsprozesse integriert sind, gehören in das Asset-Register und in die Risikobetrachtung, inklusive der Frage, was bei einem Ausfall passiert und wie die Wiederherstellungszeit aussieht.

Und für Unternehmen, die DORA im Scope haben, ist der Gedanke noch unmittelbarer: IKT-Drittparteienrisiken sind explizit Teil der regulatorischen Anforderungen. Ein KI-Modell, das in operative Prozesse eingebettet ist, ist ein IKT-Drittanbieter, mit allen Konsequenzen für Vertragsgestaltung, Monitoring und Ausstiegsszenarien.

Das ist keine Erbsenzählerei. Es ist die Erkenntnis, dass KI-Risikomanagement kein neues Silo braucht, sondern in die Strukturen integriert werden sollte, die Unternehmen für genau diese Zwecke bereits aufgebaut haben oder gerade aufbauen.

7. Fazit: Flexibilität ist keine Option, sondern Architekturprinzip

Der Anthropic-Fall wird in Erinnerung bleiben, nicht weil er so dramatisch war, sondern weil er so unerwartet kam. Und weil er gezeigt hat, dass die Einschränkung von KI-Zugang kein theoretisches Szenario mehr ist, sondern operative Realität.

Die gute Nachricht: Das Risiko ist beherrschbar. Wer KI-Abhängigkeiten kennt, sie bewertet und mit konkreten Maßnahmen hinterlegt, ist nicht schutzlos. Ein Abstraction Layer, vorab getestete Alternativen, eine klare Kritikalitätsbewertung und die Integration in bestehende Compliance-Frameworks, das sind keine großen Projekte. Es sind Entscheidungen, die man heute treffen kann.

Was sich verändert hat: KI in die Infrastruktur einzubauen, ist keine rein technische Entscheidung mehr. Es ist eine Entscheidung mit regulatorischer, geopolitischer und operativer Dimension. Wer das mitdenkt, baut robuster, und erklärt sich nicht gegenüber Kunden, wenn der nächste Brief aus Washington kommt.