Sicherheit
Pflicht-Audits für KI kommen. Die Prüfebene ist schon kaputt
Am 6. Juli 2026 wurde Illinois der erste US-Bundesstaat, der unabhängige Drittprüfungen von Frontier-KI-Modellen gesetzlich vorschreibt. Vier Monate zuvor stand das bestfinanzierte Startup im Geschäft mit automatisierten Compliance-Audits im Verdacht, 493 nahezu identische SOC-2-Berichte produziert zu haben, und flog bei Y Combinator raus. Diese beiden Fakten gehören in denselben Satz, und fast niemand stellt sie dorthin.
Die Pflicht ist real und die Richtung stimmt. Das Problem ist Arithmetik. Eine gesetzliche Prüfpflicht erzeugt Nachfrage nach Prüfkapazität, die es nicht gibt, Nachfrage wird durch Automatisierung bedient, und wir haben gerade öffentlich gesehen, wie automatisierte Compliance-Nachweise aussehen, wenn niemand die Nachweise prüft. Wer Audit-Trails produziert statt sie zu konsumieren, sollte dieses Jahr sicherstellen, dass der eigene das Gelesenwerden übersteht.
Was Illinois tatsächlich beschlossen hat
SB 0315, der Artificial Intelligence Safety Measures Act, wurde am 6. Juli 2026 von Gouverneur JB Pritzker unterzeichnet. Er tritt am 1. Januar 2027 in Kraft, die Prüfpflichten folgen ein Jahr später am 1. Januar 2028. Erfasst sind Entwickler mit mehr als 500 Millionen US-Dollar Umsatz im Vorjahr, eine Schwelle, die den Kreis der Betroffenen kurz und bekannt hält.
Zwei Pflichten zählen. Erfasste Entwickler müssen ein Frontier-KI-Rahmenwerk implementieren, einhalten und veröffentlichen, also dokumentierte Protokolle zum Umgang mit katastrophalen Risiken. Und sie müssen einen unabhängigen Dritten mit einem jährlichen Compliance-Audit dagegen beauftragen. Die Durchsetzung liegt ausschließlich beim Attorney General von Illinois, mit Bußgeldern bis zu 1 Million US-Dollar beim ersten und bis zu 3 Millionen bei weiteren Verstößen, so Skadden und DLA Piper.
Die Prüfpflicht ist das, was Illinois von seinen Nachbarn in derselben Regulierungswelle trennt. Kaliforniens Transparency in Frontier Artificial Intelligence Act und der RAISE Act in New York zielen auf dieselbe Entwicklerklasse und hören bei der Offenlegung auf. Illinois sagt als Erster, dass die Veröffentlichung eines Rahmenwerks nicht genügt und jemand Unabhängiges nachsehen muss.
Drei US-Gesetze, ein entscheidender Unterschied
| Gesetz | Kernpflicht | Unabhängiges Audit | Durchsetzung |
|---|---|---|---|
| Illinois AISMA (SB 0315) | Frontier-KI-Rahmenwerk veröffentlichen und einhalten | Ja, jährlich, ab 1.1.2028 | Illinois AG, bis 1 Mio. / 3 Mio. USD |
| California TFAIA | Transparenz und Vorfallmeldung | Nein | Staatliche Durchsetzung, offenlegungsbasiert |
| New York RAISE Act | Veröffentlichung des Sicherheitsprotokolls | Nein | Staatliche Durchsetzung, offenlegungsbasiert |
Lesen Sie die rechte Spalte als Prognose, nicht als Rangliste. Offenlegungsregime bekommen erfahrungsgemäß eine Verifikation, sobald sich die erste peinliche Offenlegung als falsch herausstellt. Illinois ist dort nur zuerst angekommen, und die Compliance-Branche hat jetzt achtzehn Monate, um die nötige Kapazität aufzubauen.
Der Teil, den niemand verknüpfen will: die Prüfebene ist bereits ausgefallen
Am 22. März 2026 veröffentlichte ein anonymes Konto detaillierte Vorwürfe gegen Delve, ein Y-Combinator-Unternehmen, das 32 Millionen US-Dollar bei einer Bewertung von 300 Millionen eingesammelt hatte und automatisierte SOC-2-Compliance verkaufte. Der Kernvorwurf: Die automatisierten Audits wurden selbst nicht geprüft. Von 494 untersuchten SOC-2-Berichten sollen 493 nahezu identisch gewesen sein, mit denselben Absätzen, denselben Grammatikfehlern und denselben unsinnigen Kontrollbeschreibungen, verändert nur bei Firmenname und Logo.
Die weiteren Vorwürfe wiegen schwerer: fabrizierte Kontrollnachweise, Prüferschlussfolgerungen, die erzeugt wurden, bevor ein Prüfer die Kundendaten gesehen hatte, und nicht akkreditierte Zertifizierungsmühlen, die das Ergebnis abstempelten. Um den 3. April 2026 entfernte Y Combinator Delve aus dem Verzeichnis und bat die Gründer, das Programm zu verlassen. Delve selbst hält dagegen, gar keine Compliance-Berichte auszustellen, sondern eine Automatisierungsplattform zu sein, die unabhängigen akkreditierten Prüfern Zugang zu Informationen verschafft, wobei Kunden ihre Prüfer frei wählen können.
Nimmt man diese Verteidigung vollständig für bare Münze, bleibt der strukturelle Punkt trotzdem stehen. Eine Plattform, die den Nachweis erzeugt, den Bericht formatiert und die Arbeit an selbst angeworbene Prüfer weiterleitet, sitzt auf jeder Seite einer Transaktion, deren gesamter Wert aus Unabhängigkeit besteht. Das ist keine Aussage über die Ehrlichkeit irgendeines Beteiligten. Es ist die Beschreibung eines Anreizes, und Anreize sind genau das, was Kontrollen einhegen sollen.
Warum das zuerst bei Firewall- und Netzwerkteams landet
Frontier-KI-Entwickler sind nicht das Publikum dieser Seite, und die Illinois-Schwelle schließt fast alle Leser aus. Relevant ist das Muster, und dieses Muster kennt das Firewall-Änderungsmanagement seit einem Jahrzehnt, lange bevor KI es modern machte.
Ein Prüfbericht ist eine Behauptung. Der Audit-Trail ist die Sache selbst. Wenn beide auseinanderlaufen, wird der Bericht abgeheftet und der Trail beschlagnahmt. Jede Organisation, die je in der Woche vor einer Bewertung ein ISO-27001- oder PCI-Nachweispaket zusammengetragen hat, kennt den Unterschied zwischen einer Kontrolle, die wirkt, und einer Kontrolle, deren Wirken belegbar ist, und weiß, welche von beiden einen ernsthaften Prüfer übersteht.
Der Ausfallmodus ist vertraut. Eine Tabelle mit Firewall-Regeln ist ein Bericht über die Landschaft, keine Aufzeichnung von ihr, weshalb tabellenbasierte Firewall-Nachverfolgung bei Audits durchfällt, sobald jemand fragt, wer eine bestimmte Änderung an einem bestimmten Datum freigegeben hat. Die entsprechende Frage an einen KI-Compliance-Bericht lautet, wer diese Kontrolle auf welcher Grundlage wann verifiziert hat, und 493 identische Dokumente können sie für 493 verschiedene Unternehmen nicht beantworten.
Was ein ernst gemeintes Audit tatsächlich übersteht
Der Unterschied, den man verinnerlichen sollte, liegt zwischen erzeugtem und erfasstem Nachweis. Erzeugter Nachweis entsteht zum Berichtszeitpunkt in einem System, das beschreibt, was es für wahr hält. Erfasster Nachweis wird im Moment des Geschehens von dem System aufgezeichnet, das es getan hat, samt Identität desjenigen, der es autorisiert hat.
- Herkunft schlägt Darstellung. Ein Datensatz mit Änderung, Antragsteller, Freigeber und Zeitstempel ist mehr wert als beliebig viele gut formatierte Kontrollbeschreibungen.
- Abweichung erkennen, nicht ihr Fehlen behaupten. Eine laufende Landschaft driftet von ihrem dokumentierten Zustand weg, weshalb Policy-Drift-Erkennung ein Nachweis ist und eine unterschriebene Compliance-Erklärung nicht.
- Rezertifizierung braucht ein Datum. Wenn niemand sagen kann, wann eine Regel zuletzt als weiterhin nötig bestätigt wurde, existiert der Rezertifizierungszyklus nur auf dem Papier.
- Einzigartigkeit ist ein Signal. Zwei Organisationen mit wirklich unterschiedlichen Landschaften sollten keine Nachweispakete produzieren, die sich nur im Logo unterscheiden. Wenn Ihres gegen das eines Wettbewerbers austauschbar wäre, beschreibt es eine Vorlage und nicht Ihr Netz.
Nichts davon ist neu. Es ist dieselbe Disziplin, die hinter einem ISO-27001-Firewall-Audit und hinter den NIS2-Nachweiserwartungen für 2026 steht. Neu ist das Volumen an Compliance-Arbeit, das gleich per Gesetz entsteht, und die Gewissheit, dass der Großteil davon von Werkzeugen statt von Menschen bewerkstelligt wird.
Die Prognose, gegen die man planen sollte
Zwischen der Illinois-Pflicht, dem europäischen Zeitplan und den bereits geltenden Offenlegungsgesetzen in zwei weiteren Bundesstaaten wird die Nachfrage nach prüffähiger KI-Dokumentation in den nächsten vierundzwanzig Monaten das Angebot an qualifizierten Menschen, die dafür unterschreiben, deutlich übersteigen. Software füllt diese Lücke. Ein Teil dieser Software wird ausgezeichnet sein, ein Teil eine Vorlagenmaschine mit Compliance-Logo, und von außen wird der Käufer das nur schwer unterscheiden können.
Die praktische Antwort ist unspektakulär. Fragen Sie jeden Compliance-Anbieter, ob er den Nachweis erzeugt, ihn prüft oder beides, und behandeln Sie beides als Feststellung statt als Funktion. Lassen Sie sich zwei Berichte zeigen, die er für verschiedene Kunden erstellt hat. Halten Sie Ihre eigenen erfassten Aufzeichnungen unabhängig von der Plattform, die sie zusammensetzt, denn der Zusammenbruch eines Anbieters darf nicht Ihre Audit-Historie mitnehmen. Dieselbe Überlegung gilt für die Abbildung von KI-VO-Pflichten auf echte Sicherheitskontrollen, wo die Abbildung nur so glaubwürdig ist wie der Nachweis, auf den sie zeigt.
Die unbequeme Zusammenfassung
Illinois hat das Richtige getan und es zuerst getan. Eine unabhängige Prüfung von Systemen zu verlangen, die ihre eigenen Erbauer in Begriffen katastrophaler Risiken beschreiben, ist keine Überregulierung. Aber eine Pflicht ist ein Nachfragesignal, und der Markt, der sie bedienen wird, hat gerade in großem Maßstab und öffentlich gezeigt, dass er Compliance produzieren kann, die nichts bedeutet.
Wer in den nächsten zwei Jahren zu irgendetwas geprüft wird, sollte die Delve-Vorwürfe als Vorschau lesen und nicht als Klatsch. Die Frage, die ein Prüfer stellen sollte und die Sie sich zuerst stellen sollten, hat sich lange vor der Ankunft von KI nicht geändert: nicht, ob Sie einen Bericht haben, sondern ob Sie die Aufzeichnung vorlegen können, auf der dieser Bericht beruhen sollte. Liegt diese Aufzeichnung in einer Tabelle oder in der Datenbank eines Anbieters, aus der Sie nicht exportieren können, haben Sie sie noch nicht.
Strukturierte Änderungssteuerung ist die langweilige Fassung der Antwort, und genau deshalb überlebt Firewall-Änderungsmanagement die Compliance-Rahmenwerke, die darüber kommen und gehen. Eine Änderung, die beantragt, geprüft, freigegeben, umgesetzt und aufgezeichnet wurde, ist vor jeder Aufsichtsbehörde in jedem Jahr unter jedem Kürzel verteidigbar.
Wenn Sie eine Außensicht darauf wollen, ob Ihre Nachweise halten, geht der kostenlose NIS2-Readiness-Check durch, was ein Prüfer tatsächlich verlangt.
Über FwChange
FwChange ist eine Methodik für Firewall-Änderungsmanagement
