Illinois-KI-Audits ab 2028: erste Analyse eines US-Bundesstaats

Der Kalendereintrag ist kein Konferenzpanel mehr. Er ist eine Release-Abhängigkeit. Illinois hat die Einhaltung von KI-Sicherheitsvorgaben aus dem vertrauten Bereich interner Dokumentation in die weniger nachsichtige Welt unabhängiger Audits verlagert. Das ist wichtig, weil Auditierbarkeit nichts ist, was ein Team nach dem Launch einfach über ein Modell streut. Logs, Evaluationsaufzeichnungen, Incident-Workflows, Governance-Freigaben und Nachweise von Anbietern müssen alle vorhanden sein, bevor eine dritte Partei sie überprüfen kann. Die praktische Frage ist nicht, ob Regulierungsbehörden Sicherheitsframeworks mögen. Sie lautet, ob dein Produktprozess beweisen kann, dass eines funktioniert hat, als es darauf ankam.

Was Illinois tatsächlich beschlossen hat Laut Skadden unterzeichnete der

Gouverneur von Illinois, JB Pritzker, am 6. Juli 2026 den Artificial Intelligence Safety Measures Act. Damit ist Illinois nach Kalifornien und New York der dritte Bundesstaat, der großen KI-Entwicklern Transparenz-, Sicherheits- und Berichtspflichten auferlegt. Skadden sagt, Illinois gehe noch weiter, indem Entwickler verpflichtet werden, jährlich eine unabhängige dritte Partei mit der Prüfung der Compliance zu beauftragen. DLA Piper beschreibt Illinois ähnlich als den ersten Bundesstaat, der Drittparteien-Audits von KI-Modellen verlangt, während Governing zuvor berichtete, der Gesetzentwurf würde große KI-Entwickler verpflichten, Risiken offenzulegen, Sicherheitsvorfälle zu melden und sich jährlichen unabhängigen Audits zu unterziehen.

Die Kurzfassung lautet: Illinois ist bei externer Verifizierung zuerst. Die juristische Version ist enger und nützlicher: Erfasste Entwickler großer Frontier-Modelle müssen sich jährlichen unabhängigen Compliance-Audits stellen, plus einer öffentlichen Framework-Pflicht, die am 1. Januar 2028 beginnt. Wenn dein Compliance-Memo nur sagt, dass die Model Card fertig ist, verfehlt es den Punkt.

Wer in der Compliance-Spur ist Skadden sagt, das Gesetz konzentriere sich auf

ein Frontier-KI-Framework und gelte für einen großen Frontier-Entwickler. Ab dem 1. Januar 2028 muss dieser Entwickler ein Framework schreiben, umsetzen, einhalten und deutlich sichtbar auf seiner Website veröffentlichen, das seinen Ansatz für das Management katastrophaler Risiken beschreibt. Skadden sagt außerdem, das Framework müsse mindestens jährlich überprüft werden, und jede wesentliche Änderung müsse innerhalb von 30 Tagen mit Begründung veröffentlicht werden. Crowell & Moring beschreibt dasselbe Gesetz als Transparenz- und Sicherheitspflichten für Frontier-KI-Systeme und sagt, Illinois habe sich Kalifornien und New York angeschlossen, indem es Standards für die leistungsstärksten KI-Systeme eingeführt habe. Das ist eine hilfreiche Grenzmarkierung für Entwickler, die keine Frontier-Modelle trainieren, sich aber auf sie stützen. Du bist vielleicht nicht das direkte gesetzliche Ziel, aber Beschaffung hat ein langes Gedächtnis und einen kurzen Fragebogen.

Was sich für Entwickler ändert Cooley beschreibt

AISMA als einen Schritt von Transparenz zu Verifizierung. Die Analyse stellt frühere Frameworks gegenüber, darunter Kaliforniens TFAIA, New Yorks geänderten RAISE Act und Teile des EU AI Act, die Entwickler im Allgemeinen verpflichten, zu bewerten und offenzulegen, wie sie KI-Risiken identifizieren, evaluieren und managen. Illinois fügt den unbequemen Teil hinzu: Eine unabhängige dritte Partei muss prüfen, ob der Prozess tatsächlich so funktioniert, wie beschrieben.

In Produktarbeit übersetzt bedeutet das: Compliance-Nachweise müssen in das System hineindesignt werden. Die Release-Checkliste braucht klare Zuständigkeiten für Risikobewertungen, Modell- oder Systemkarten, Meldewege für Vorfälle, Aktualisierungen öffentlicher Frameworks und Zusammenarbeit bei Audits. Ein Anbietervertrag, der ein Frontier-Modell berührt, sollte Dokumentationslieferung, Incident-Benachrichtigung und Audit-Unterstützung verlangen – nicht, weil jeder Kunde direkt reguliert ist, sondern weil regulierte Pflichten durch Beschaffungsprozesse weiterwandern.

DLA Piper merkt an, dass AISMA Kalifornien und New York bei den Transparenzpflichten ähnelt, mit der auffälligen Ausnahme der Audit-Bestimmungen. Genau bei dieser Ausnahme sollten Produktteams Zeit investieren. Ein öffentliches Framework ist ein Dokument. Ein Audit ist ein Dokument plus Beweise, Zeitstempel, Personen, Kontrollen und das gelegentliche unangenehme Meeting.

Wo die Rechtsräume jetzt auseinanderlaufen Cooleys Vergleich zeigt das Problem,

das Entwickler wiedererkennen werden: Kalifornien, New York und Teile des EU AI Act betonen Bewertung, Offenlegung, Governance-Frameworks, Transparenzberichte, Model Cards, Risikobewertungen und Incident Reporting. Illinois behält einen Großteil dieser Architektur bei und fügt dann unabhängige Verifizierung hinzu.

Crowell & Moring sagt, dass Kalifornien, New York und Illinois auch ohne bundesstaatliches Handeln im Grunde ein nationales Framework für KI-Sicherheit und Transparenz geschaffen haben. Das bedeutet nicht, dass die Regeln identisch sind. Es bedeutet, dass ein großer Entwickler, der US-Kunden bedient, möglicherweise die strengste operative Erwartung erfüllen muss, selbst wenn ein anderer Bundesstaat mit selbst gemeldeten Kontrollen zufrieden ist.

Der Schwerpunkt der Compliance verlagert sich von dem, was ein Entwickler sagt, dass er tut, zu dem, was ein Auditor nachweisen kann, dass er getan hat. Für Leserinnen und Leser, die mit Frontier-Systemen bauen, ist der nächste sinnvolle Schritt langweilig und unmittelbar: Kartiere, welche Nachweise dein aktueller Entwicklungslebenszyklus bereits erzeugt, welche Nachweise in Chat-Threads verschwinden und welche Nachweise eine dritte Partei tatsächlich prüfen könnte. Bis 2028 werden die interessanten Unternehmen nicht diejenigen sein, die sagen, dass sie die Regeln begrüßen. Es werden diejenigen sein, deren Launch-Prozess bereits eine Audit-Spur hinterlässt.