Anthropic vs. Pentagon: Kill‑Switch-Debatte wird zum Beschaffungsrisiko

Anthropic weist in Gerichtsdokumenten die Existenz eines „Kill‑Switches“ oder einer Backdoor für sein Modell Claude zurück, während das US‑Verteidigungsministerium die Firma als Supply‑Chain‑Risiko einstuft und die Nutzung in Bundesbehörden zurückfährt. Relevanz: Der Streit verschiebt die Spielregeln für KI‑Beschaffung – es geht nicht um einen Schalter, sondern um Kontrolle, Update‑Hoheit und verifizierbare Betriebssicherheit.

Hintergrund: Laut Gerichtsakten kann Anthropic laufende Militärsysteme nicht aus der Ferne deaktivieren oder deren Verhalten ändern; Updates wären nur mit Zustimmung des Regierungskunden und des Cloud‑Providers möglich. Zugleich argumentiert das Pentagon, es müsse kein Risiko tolerieren, dass kritische Systeme in Einsätzen kompromittiert werden. Über den Konflikt und seine Folgen berichtete zuerst WIRED; die Kernaussagen sind in eidesstattlichen Erklärungen und Schriftsätzen belegt.

Der Kernkonflikt: Kontrolle versus Kontingenz

Die Positionen sind klar abgegrenzt: In einer eidesstattlichen Erklärung betont Anthropics Public‑Sector‑Chef, das Unternehmen habe „keine Möglichkeit, Claude zum Stoppen zu bringen, die Funktionalität zu verändern, den Zugang abzuschalten oder sonstwie militärische Operationen zu gefährden“. Es gebe keinen Remote‑„Kill‑Switch“ und keinen Zugang zu Eingaben oder Betriebsdaten von Militärnutzern. Zudem seien Software‑Änderungen nur mit Freigabe des Regierungsauftraggebers und des Cloud‑Betreibers möglich – die Architektur sei entsprechend gestaltet.

Die Gegenseite hält dagegen, das Verteidigungsministerium müsse nicht das Risiko akzeptieren, dass kritische Systeme in entscheidenden Momenten ausfallen oder manipuliert werden könnten. Die Folge ist eine Einstufung als Lieferkettenrisiko, die das Pentagon dazu verpflichtet, Anthropic-Produkte innerhalb von 180 Tagen vollständig zu entfernen, was bereits zu massiven Vertragskündigungen führt. Behörden arbeiten parallel mit Cloud‑Providern daran, dass der Anbieter keine einseitigen Änderungen an laufenden Systemen vornehmen kann – auch das ist in Schriftsätzen dokumentiert.

Technik‑Realität: Was ein „Kill‑Switch“ wäre – und wie man seine Abwesenheit prüft

Ein „Kill‑Switch“ meint hier keinen physischen Schalter, sondern jede Fähigkeit des Anbieters, laufende Systeme aus der Ferne zu deaktivieren, ihr Verhalten heimlich zu verändern oder den Zugang im Einsatz zu sperren. Proprietäre Foundation‑Modelle erschweren die Verifikation, weil Codebasis, Gewichte und Infrastruktur nicht offenliegen. Dennoch lässt sich das Risiko strukturieren und mitigieren:

• Architektur‑Evidenz: Kundenseitig verwaltete Identitäten, Schlüssel und Netzsegmente; kein Anbieterzugriff auf Produktions‑Tenants; durchgesetzte Update‑Gates mit expliziter Freigabe durch Auftraggeber und Cloud‑Provider.
• Änderungskontrolle: Signierte Releases, Unveränderlichkeits‑Policies, getrennte Staging‑/Prod‑Pfade, nachvollziehbare Rollbacks; kryptografische Attestierungen der Build‑ und Lieferkette.
• Protokollierbarkeit: Unveränderliche Audit‑Logs für Admin‑Aktionen, Modell‑ und Policy‑Updates; externe Überwachung durch den Auftraggeber.
• Drittparteien‑Kontrollen: Cloud‑seitige Guardrails, die Anbieter‑Privilegien in Kunden‑Tenants technisch verhindern; unabhängige Audits und Pen‑Tests mit Einblick in Schnittstellen, nicht in Gewichte.
• Betriebsisolation: Option für dedizierte Deployments (z. B. Government‑Clouds) mit vertraglichem Update‑Freeze während Operationen und definierten „Change Windows“.

Wichtig: Die Abwesenheit eines Kill‑Switches lässt sich nicht absolut beweisen. Was beschaffungsseitig erreichbar ist, sind überprüfbare Zusicherungen über Architektur, Rollenrechte, Update‑Prozesse und Überwachung – flankiert durch staatliche oder unabhängige Zertifizierungen. Genau hier verdichtet sich der Konflikt: Das Pentagon verlangt Null‑Toleranz gegenüber Restunsicherheit, der Anbieter verweist auf fehlende technische Zugriffspfade und vertragliche Schranken.

Marktdynamik: Präzedenzfall für KI‑Lieferanten

Die Supply‑Chain‑Einstufung sendet ein deutliches Signal an den Markt. Erstens: In sicherheitskritischen Anwendungsfällen zählt nicht nur Modellleistung, sondern vor allem Änderungs‑ und Zugriffskontrolle. Zweitens: Cloud‑Topologie und Rollenrechte werden zum differenzierenden Produktmerkmal – Government‑Tenants, Kundenschlüssel, Update‑Gates und Notfall‑Freeze‑Optionen sind nicht Kür, sondern Voraussetzung. Drittens: Der Nachweisweg verschiebt sich von „Trust me“ zu „Show me“ – mit belastbaren Audits, Logs und rechtlich durchsetzbaren SLAs.

Für Anbieter mit Regierungsambitionen entsteht ein Dilemma: Je offener und restriktiver die Betriebsarchitektur, desto höher die Compliance‑Fähigkeit – aber desto geringer die zentrale Steuerbarkeit des Produkts. Für Beschaffer wächst die Bedeutung von Multi‑Modell‑Resilienz: Redundanz über mehrere Anbieter reduziert das Risiko politischer oder operativer Störungen einzelner Lieferanten.

Was bedeutet das für den EU AI Act?

Der EU AI Act nimmt Verteidigungsvorhaben grundsätzlich vom Anwendungsbereich aus. Dennoch greifen zwei Ebenen: Erstens unterliegen Basismodelle, die in der EU vermarktet werden, seit August 2025 spezifischen Transparenz‑ und Governance‑Pflichten (GPAI). Zweitens setzen öffentliche Auftraggeber in der EU zusätzliche Beschaffungsauflagen durch – etwa zu Änderungskontrolle, Auditierbarkeit und Einsatzgrenzen.

Zahlenrahmen, der Beschaffer und Anbieter im DACH‑Raum kalibriert: Verstöße gegen Verbote können mit bis zu 35 Mio. Euro oder 7% des weltweiten Jahresumsatzes geahndet werden; für Verstöße im Hochrisikobereich liegen die Höchststrafen bei bis zu 15 Mio. Euro oder 3% (geltende Gesetzeslage, gestaffelt nach Verstoßkategorien). Ab dem 2. August 2026 treten die Kernpflichten für Hochrisiko‑Systeme in Kraft; ab August 2027 laufen weitere Übergangsfristen für bestehende Modelle aus. Auch wenn Verteidigung ausgenommen ist, werden diese Benchmarks in zivilen Regierungsprojekten faktisch zum Mindeststandard.

So What? Management‑Relevanz jenseits der USA

Für C‑Level zählt jetzt Verhandlungssubstanz statt Marketingversprechen. Auf Anbieterseite braucht es „Assurance Packs“, die Architektur‑Diagramme, Rollen‑ und Rechtemodelle, Change‑Control‑Prozesse, Notfall‑Freeze‑Mechanismen und Cloud‑seitige Kontrollen dokumentieren – plus vertragliche Zusagen zu Update‑Gates, Audit‑Rechten und Betriebsisolation. Auf Käuferseite gehören dreifache Sicherungen in jeden Vertrag: technische Gating‑Kontrollen, rechtlich belastbare Change‑Prozesse und operative Redundanz über mehrere Modelle und Clouds. Ohne diese Trias ist das Residualrisiko politischer Eingriffe oder Anbieter‑Änderungen nicht tragfähig managbar.

Fazit: Prüfbarkeit schlägt Behauptung

Der Streit zeigt: „Kein Kill‑Switch“ ist als Aussage erst dann belastbar, wenn Architektur, Prozesse und Logs das belegen – und der Käufer diese Belege unabhängig prüfen kann. Für Entscheider heißt das: Beschaffung nach Zero‑Trust‑Prinzipien, Update‑Freeze‑Klauseln mit klaren Ausnahmewegen, kundenseitige Schlüsselverwaltung, externe Audit‑Rechte und Multi‑Anbieter‑Resilienz. Wer heute diese Leitplanken setzt, reduziert morgen die Wahrscheinlichkeit, im Einsatz von Lieferketten‑ oder Politikrisiken überrascht zu werden.