Beancount.io LogoBeancount.io

Einhaltung von Kalifornien SB 53: Ein praktischer Leitfaden zum Transparency in Frontier AI Act

13 Minuten LesezeitMike ThriftMike Thrift
Einhaltung von Kalifornien SB 53: Ein praktischer Leitfaden zum Transparency in Frontier AI Act

Am 29. September 2025 unterzeichnete der kalifornische Gouverneur Gavin Newsom den Senate Bill 53, den Transparency in Frontier Artificial Intelligence Act (TFAIA). Damit wurde Kalifornien zur ersten US-Rechtsordnung, die den Entwicklern der rechenintensivsten KI-Systeme verbindliche Verpflichtungen zur Sicherheit, Transparenz und Meldung von Vorfällen auferlegt. Das Gesetz trat am 1. Januar 2026 in Kraft und hat in den letzten sechs Monaten im Stillen die Art und Weise verändert, wie die größten KI-Labore und eine wachsende Liste mittelgroßer Modellentwickler Risiken dokumentieren, Governance-Strukturen veröffentlichen und Regulierungsbehörden über Szenarien katastrophaler Risiken informieren.

Wenn Ihr Unternehmen Basismodelle (Foundation Models) trainiert, feinabstimmt oder wesentlich modifiziert – oder große Rechencluster betreibt, auf die andere Entwickler angewiesen sind – ist SB 53 nun das bedeutendste KI-Gesetz in den Vereinigten Staaten, das Sie verstehen müssen. Dieser Leitfaden erläutert, wer unter das Gesetz fällt, was Sie veröffentlichen müssen, wie die 15-Tage-Frist für die Meldung kritischer Vorfälle funktioniert, welche Verpflichtungen für Whistleblower gelten und wie Sie das Gesetz in ein operatives Compliance-Programm übersetzen.

Was SB 53 tatsächlich reguliert

Im Gegensatz zu den KI-Gesetzen im Beschäftigungsbereich, die sich von Bundesstaat zu Bundesstaat verbreiten (wie das NYC Local Law 144 oder der Colorado AI Act), reguliert SB 53 keine algorithmischen Einstellungswerkzeuge, Kreditprüfungshilfen oder Mieter-Screening-Systeme. Es zielt auf eine viel engere Kategorie ab: Frontier-Basismodelle, die mit außergewöhnlichen Rechenkapazitäten trainiert wurden, und die Szenarien katastrophaler Risiken, die daraus entstehen können.

Das Gesetz steht an der Schnittstelle zweier Regulierungstraditionen. Aus dem Produktsicherheitsrecht übernimmt es die Idee, dass Unternehmen Risikobewertungen veröffentlichen und Behörden benachrichtigen sollten, wenn Vorfälle eintreten. Aus dem Finanzregulierungsrecht übernimmt es die Idee, dass die größten Akteure schwerere Offenlegungspflichten tragen als kleinere. Das Ergebnis ist ein gestuftes System, das um zwei Schwellenwerte herum aufgebaut ist.

Der Rechenschwellenwert von 10^26 FLOPs

Ein „Frontier-Modell“ wird unter SB 53 als ein Basismodell definiert, das mit mehr als 10^26 Ganzzahl- oder Gleitkommaoperationen trainiert wurde, einschließlich der kumulativen Rechenleistung aus Feinabstimmungen (Fine-Tuning) und nachfolgenden Modifikationen. Dieser Schwellenwert ist bewusst auf den mittlerweile aufgehobenen Berichterstattungsauslöser der föderalen Executive Order 14110 und die Stufe für Allzweck-KI des EU AI Act abgestimmt, sodass die meisten großen US-Labore bereits wissen, ob sie ihn überschreiten.

Was manchmal übersehen wird, ist, dass das Gesetz die kumulative Rechenleistung aus nachgelagerten Modifikationen mitzählt. Wenn Sie ein Basismodell nehmen, das nahe am Schwellenwert trainiert wurde, und das Vortraining fortsetzen, ein Reinforcement Learning Fine-Tuning durchführen oder Gewichte mit einem anderen Modell zusammenführen (Weight Merge), können Sie ein Derivat in den Frontier-Status katapultieren, selbst wenn kein einzelner Trainingslauf 10^26 FLOPs überschritten hat. Die Katalogisierung jedes Basismodells, jedes Fine-Tunings, jeder Destillation und jeder Gewichtszusammenführung – sowie die Verfolgung der jeweils verbrauchten FLOPs – ist nun eine wesentliche Buchhaltungsdisziplin.

Die Umsatzschwelle von 500 Millionen US-Dollar für große Frontier-Entwickler

Ein „großer Frontier-Entwickler“ ist ein Frontier-Entwickler, dessen Unternehmen und verbundene Unternehmen im vorangegangenen Kalenderjahr mehr als 500 Millionen US-Dollar Bruttojahresumsatz erzielt haben. Die Umsatzprüfung erfolgt konsolidiert: Muttergesellschaften, Tochtergesellschaften und gemeinsam kontrollierte verbundene Unternehmen werden addiert. Ein kleines KI-Startup, das eine Finanzierungsrunde in Milliardenhöhe abgeschlossen, aber nur 40 Millionen US-Dollar an tatsächlichem Umsatz erzielt hat, ist kein großer Frontier-Entwickler; ein börsennotiertes Technologiekonglomerat mit einer kleinen KI-Abteilung, die den FLOPs-Schwellenwert überschreitet, ist es fast sicher.

Die Einstufung ist wichtig, da große Frontier-Entwickler die umfassendsten Verpflichtungen haben: Veröffentlichung eines Frontier-KI-Frameworks, Durchführung von Bewertungen katastrophaler Risiken, Einreichung vierteljährlicher Zusammenfassungen interner Risiken beim California Office of Emergency Services (Cal OES) und Unterhalt eines anonymen internen Whistleblower-Kanals. Kleinere Frontier-Entwickler – jene über dem FLOPs-Schwellenwert, aber unter der Umsatzschwelle – müssen weiterhin Transparenzberichte veröffentlichen und kritische Sicherheitsvorfälle melden, sind jedoch nicht zur Umsetzung des vollständigen Framework-Regimes verpflichtet.

Was Sie veröffentlichen müssen: Das Frontier-KI-Framework

Jeder große Frontier-Entwickler muss ein Frontier-KI-Framework auf seiner Website veröffentlichen und aktuell halten. Eine jährliche Überprüfung ist obligatorisch, und jede wesentliche Änderung muss innerhalb von 30 Tagen nach der Änderung eine Aktualisierung auslösen.

Ein vertretbares Framework befasst sich mindestens mit:

  • Schwellenwerten für katastrophale Risiken und Bewertungsmethoden. Welche Fähigkeiten – Unterstützung bei chemischen, biologischen, radiologischen oder nuklearen Waffen; großflächige Angriffe auf kritische Infrastrukturen; Szenarien von autonomem Kontrollverlust der Agenten – würde der Entwickler als Überschreitung einer Katastrophenschwelle betrachten? Wie wird der Entwickler diese Fähigkeiten vor der Bereitstellung testen?
  • Strategien zur Risikominderung. Konkrete Maßnahmen vor der Bereitstellung: Ablehnungstraining (Refusal Training), Fähigkeitsdämpfung, Bereitstellungsbeschränkungen, überwachter Zugang, gestufte Rollouts und Überwachung nach der Bereitstellung.
  • Bewertungen durch Dritte. Welche externen Red-Teams, Evaluatoren und Auditoren werden das Modell bewerten und wie werden deren Ergebnisse berücksichtigt?
  • Cybersicherheitsprotokolle für unveröffentlichte Modellgewichte. Kontrollen gegen Insider-Drohungen, Hardware-Sicherheitsmodule, Netzwerksegmentierung und Zugriffsprotokollierung zum Schutz der Gewichte vor der Bereitstellung gegen Diebstahl.
  • Verfahren zur Reaktion auf kritische Sicherheitsvorfälle. Wer entscheidet, ob ein Vorfall meldepflichtig ist, wie die 15-Tage-Frist in Gang gesetzt wird und wie das Unternehmen mit Cal OES koordiniert.
  • Interne Governance-Mechanismen. Aufsicht durch den Vorstand, die Rolle des KI-Sicherheitsbeauftragten, Eskalationspfade und der Rhythmus der Sicherheitsüberprüfungen.
  • Einhaltung von Standards. Explizite Abbildung auf das NIST AI Risk Management Framework (AI RMF 1.0) und ISO/IEC 42001, die das Gesetz als grundlegende Baselines betrachtet.

Das Framework ist kein Marketingdokument. Es ist ein auf die Regulierungsbehörden ausgerichtetes Artefakt, mit dem der Generalstaatsanwalt beurteilen kann, ob die öffentlichen Zusagen des Unternehmens mit seiner internen Praxis übereinstimmen. Die Erstellung mit derselben Sorgfalt wie eine SEC-Risikofaktorerklärung oder eine SOC 2-Systembeschreibung ist die richtige Herangehensweise.

Transparenzberichte vor jeder Bereitstellung

Jeder Frontier-Entwickler – nicht nur die großen – muss vor der Bereitstellung eines neuen oder erheblich modifizierten Frontier-Modells einen Transparenzbericht veröffentlichen. Der Transparenzbericht ist ein modellspezifisches Dokument, das getrennt vom Framework erstellt wird und Folgendes enthalten muss:

  • Firmenname, Website und Kontaktmöglichkeiten für Sicherheitsbedenken
  • Das Veröffentlichungsdatum des Modells sowie eine Liste der unterstützten Sprachen und Ausgabemodalitäten
  • Beabsichtigte Verwendungszwecke und geltende Nutzungsbeschränkungen
  • Für große Entwickler: Eine Zusammenfassung der Bewertungen katastrophaler Risiken und deren Ergebnisse, einschließlich der Angabe, ob und wie externe Prüfer einbezogen wurden

Eine „erhebliche Modifikation“ umfasst umfassende Upgrades der Fähigkeiten, die Hinzufügung neuer Modalitäten und signifikante Änderungen im Mix der Trainingsdaten. Patch-Releases und routinemäßige Sicherheits-Feinabstimmungen erfordern im Allgemeinen keinen neuen Transparenzbericht, aber Grenzfälle sollten mit einer schriftlichen Begründung dokumentiert werden, falls der Generalstaatsanwalt später fragt, warum kein Bericht veröffentlicht wurde.

Die 15-Tage-Frist für die Meldung kritischer Vorfälle

Die Compliance-Last, die Unternehmensjuristen am meisten überrascht hat, ist der Zeitplan für die Meldung von Vorfällen. Frontier-Entwickler müssen das California Office of Emergency Services (Cal OES) innerhalb von 15 Tagen nach Entdeckung über einen kritischen Sicherheitsvorfall informieren, wobei eine engere 24-Stunden-Frist gilt, wenn der Vorfall eine unmittelbare Bedrohung für die öffentliche Sicherheit darstellt.

Das Gesetz definiert einen kritischen Sicherheitsvorfall weit gefasst:

  • Unbefugter Zugriff auf oder Diebstahl von unveröffentlichten Modellgewichten
  • Realisierung eines katastrophalen Risikos
  • Verlust der Kontrolle des Entwicklers über ein bereitgestelltes Modell
  • Täuschendes oder ausweichendes Modellverhalten, das Schutzmaßnahmen umgeht

Der Aufbau eines vertretbaren internen Prozesses bedeutet, drei Fragen zu beantworten, bevor ein Vorfall überhaupt eintritt:

  1. Wer entscheidet? Ein einzelner benannter Verantwortlicher (häufig der Chief AI Safety Officer oder ein designierter Stellvertreter) sollte die Befugnis haben, die Meldefrist in Gang zu setzen, wobei Eskalationskriterien dokumentiert sein müssen.
  2. Was setzt die Frist in Gang? Auslöser ist die „Entdeckung“. Die interne Dokumentation sollte genau festhalten, wann ein Vorfall von wem und durch welches Überwachungssystem entdeckt wurde, da das 15-Tage-Fenster ab diesem Moment berechnet wird.
  3. Wie wird der Bericht übermittelt? Das Cal OES unterhält ein vertrauliches Aufnahmeverfahren für Einreichungen von Entwicklern. Das Meldeteam sollte den Workflow für die Einreichung – einschließlich der verschlüsselten Übertragung sensibler technischer Details – lange vor einem tatsächlichen Vorfall proben.

Für große Frontier-Entwickler geht die Verpflichtung über die reaktive Meldung von Vorfällen hinaus. Alle drei Monate (oder gemäß einem anderen angemessenen Zeitplan) müssen große Entwickler dem Cal OES eine Zusammenfassung aller Bewertungen katastrophaler Risiken übermitteln, die sich aus der internen Nutzung ihrer Frontier-Modelle ergeben. Dieser vierteljährliche Rhythmus ist einzigartig für SB 53 und stellt das erste Mal dar, dass ein US-Gesetz KI-Labore verpflichtet hat, laufende Erkenntnisse über interne Nutzungsrisiken an eine Behörde der Exekutive zu melden.

Whistleblower-Schutz und der anonyme interne Kanal

SB 53 ergänzt die allgemeine Whistleblower-Regelung Kaliforniens um eine Reihe KI-spezifischer Schutzmaßnahmen, die für „betroffene Mitarbeiter“ gelten – also für diejenigen, zu deren Aufgaben die Bewertung, Verwaltung oder Bewältigung des Risikos katastrophaler Schäden durch Frontier-Modelle gehört.

Frontier-Entwickler dürfen einen betroffenen Mitarbeiter nicht daran hindern, Informationen offenzulegen, oder Vergeltungsmaßnahmen gegen ihn ergreifen, wenn er Informationen weitergibt an:

  • Den Generalstaatsanwalt von Kalifornien
  • Eine Bundesaufsichtsbehörde
  • Einen direkten Vorgesetzten oder einen anderen Vorgesetzten mit Ermittlungsbefugnis
  • Einen anderen betroffenen Mitarbeiter, zu dessen Aufgaben die Risikobewertung gehört

Die geschützten Offenlegungen decken sowohl (a) den begründeten Glauben ab, dass die Aktivitäten des Entwicklers eine spezifische und erhebliche Gefahr für die öffentliche Gesundheit oder Sicherheit durch ein katastrophales Risiko darstellen, als auch (b) den begründeten Glauben, dass der Entwickler gegen SB 53 selbst verstoßen hat.

Große Frontier-Entwickler müssen zudem einen anonymen internen Meldekanal unterhalten. Das Gesetz schreibt vor:

  • Einen Workflow, der es betroffenen Mitarbeitern ermöglicht, anonyme Offenlegungen über Bedenken hinsichtlich katastrophaler Risiken einzureichen
  • Monatliche Status-Updates für den meldenden Mitarbeiter über den Fortgang der Untersuchung
  • Vierteljährliche Briefings für Führungskräfte und Vorstände, die Offenlegungen und Ergebnisse zusammenfassen, wobei namentlich genannte Personen, die eines Fehlverhaltens beschuldigt werden, vom Teilnehmerkreis des Briefings ausgeschlossen sind

Gerichte können erfolgreichen Klägern in Verfahren wegen Vergeltungsmaßnahmen Anwaltskosten zusprechen. Entscheidend ist, dass das Gesetz die Beweislast umkehrt: Wenn ein betroffener Mitarbeiter nachweist, dass die geschützte Tätigkeit ein beitragender Faktor für eine nachteilige Maßnahme war, trägt der Entwickler die Beweislast dafür, dass die Maßnahme aus unabhängigen legitimen Gründen erfolgt wäre.

Die Definition des katastrophalen Risikos

Der Schwerpunkt von SB 53 liegt auf der Definition des „katastrophalen Risikos“. Das Gesetz definiert es als ein vorhersehbares und wesentliches Risiko, dass ein Frontier-Modell erheblich zum Tod oder zur schweren Verletzung von mehr als 50 Personen oder zu Sachschäden oder Vermögensverlusten von mehr als 1 Milliarde US-Dollar durch einen von drei Kausalmechanismen beiträgt:

  1. Unterstützung bei Waffenentwicklung. Wesentlicher Beitrag zur Erstellung, Bereitstellung oder Verwendung einer chemischen, biologischen, radiologischen oder nuklearen Waffe oder zu einer Cyberwaffe, die vergleichbaren Schaden anrichtet.
  2. Unkontrolliertes schädliches Verhalten. Verhalten des Modells mit begrenzter menschlicher Aufsicht, das, wenn es von einem Menschen begangen würde, eine schwere Straftat darstellen würde, die Vorsatz erfordert.
  3. Kontrollverlust. Verlust der Kontrolle des Entwicklers über das Modell, sodass dieses ein erheblich schädliches Verhalten an den Tag legt.

Die Definition sieht wichtige Ausschlüsse vor. Risiken, die auf bereits öffentlich zugänglichen Informationen basieren, Schäden, die aus rechtmäßigen Aktivitäten des Bundes entstehen, und Schäden, bei denen der Beitrag des Modells nicht wesentlich ist, fallen nicht in den Anwendungsbereich. Dieser Ausschluss sorgt dafür, dass alltägliche Anwendungsrisiken – wie Voreingenommenheit bei der Prüfung von Lebensläufen, halluzinierte medizinische Ratschläge oder Urheberrechtsverletzungen – nicht das Regime für katastrophale Risiken auslösen. Diese Schäden sind real, werden aber durch andere Gesetze adressiert, nicht durch SB 53.

Zivilrechtliche Sanktionen und Durchsetzung

Der kalifornische Generalstaatsanwalt (Attorney General) verfügt über die exklusive Durchsetzungsbefugnis. Zivilrechtliche Sanktionen können bis zu 1 Million US-Dollar pro Verstoß erreichen, skaliert nach der Schwere des Verhaltens. Es gibt kein privates Klagerecht unter SB 53 selbst, obwohl die Bestimmungen zum Schutz von Whistleblowern vor Vergeltungsmaßnahmen unabhängig durch zivilrechtliche Klagen geschädigter Mitarbeiter durchsetzbar sind.

In der Praxis konzentriert sich das Durchsetzungsrisiko auf drei Bereiche:

  • Umgehung von Schwellenwerten. Unternehmen, die Trainingsläufe so strukturieren, dass sie knapp unter 10^26 FLOPs bleiben, während sie eindeutige Frontier-Class-Fähigkeiten ausliefern, werden unter Beobachtung stehen. Die im Gesetz verankerte Formulierung zur kumulativen Rechenleistung macht diese Strategie anfällig.
  • Lücken im Framework. Ein Framework, das Richtlinien ohne Nachweise für deren Umsetzung auflistet, wird leichter anfechtbar sein als eines, das jede Verpflichtung mit operativen Artefakten, benannten Verantwortlichen und Audit-Logs verknüpft.
  • Verzögerungen bei der Meldung von Vorfällen. Das Versäumen der 15-Tage-Frist oder der 24-Stunden-Frist bei unmittelbar drohenden Gefahren ist die Art von eindeutigem, dokumentierbarem Verstoß, den Regulierungsbehörden historisch gesehen sehr aggressiv verfolgen.

Erstellung eines 90-Tage-Implementierungsplans

Für eine Organisation, die noch kein SB-53-Programm eingerichtet hat, empfiehlt sich die folgende Abfolge:

Tage 1 bis 30: Scope- und Gap-Analyse.

  • Katalogisieren Sie jedes Basismodell (Foundation Model), das trainiert, feinabgestimmt, zusammengeführt oder wesentlich modifiziert wurde, mit der geschätzten kumulativen Rechenleistung für jedes Modell.
  • Stellen Sie fest, ob der konsolidierte Umsatz (einschließlich aller verbundenen Unternehmen) im vorangegangenen Kalenderjahr 500 Millionen US-Dollar überschritten hat.
  • Bilden Sie eine funktionsübergreifende Arbeitsgruppe für KI-Sicherheit und Compliance mit Mitgliedern aus den Bereichen Technik, Sicherheit, Recht, Kommunikation und Personalwesen.
  • Gleichen Sie die aktuellen Praktiken mit dem NIST AI RMF 1.0 und ISO/IEC 42001 ab, um Lücken zu identifizieren.

Tage 31 bis 60: Entwurf und Governance.

  • Entwerfen Sie das Frontier-KI-Framework als versioniertes, öffentlich publizierbares Dokument.
  • Erstellen Sie die Methodik zur Bewertung katastrophaler Risiken, einschließlich Fähigkeitsbewertungen, Bedrohungsmodellierung und den Kriterien für die Einstufung eines Modells als "frontier-fähig" in einem gefährlichen Bereich.
  • Richten Sie Cybersicherheitskontrollen für nicht veröffentlichte Modellgewichte ein, mit dokumentierten Zugriffsprotokollen und Überwachung von Insider-Bedrohungen.
  • Richten Sie den anonymen internen Meldekanal sowie den Workflow für monatliche Status-Updates und vierteljährliche Briefings für den Vorstand ein.

Tage 61 bis 90: Operative Bereitschaft.

  • Führen Sie eine Tabletop-Übung zur Reaktion auf Vorfälle durch, die die Entdeckung eines Diebstahls von Modellgewichten und den Eintritt eines katastrophalen Risikos simuliert; üben Sie dabei die 15-Tage- und 24-Stunden-Melde-Workflows.
  • Schulung der betroffenen Mitarbeiter über Whistleblower-Rechte und den anonymen Kanal.
  • Veröffentlichen Sie den Transparenzbericht für jedes Modell in der Deployment-Pipeline mit einem Querverweis auf das Frontier-KI-Framework.
  • Terminieren Sie die vierteljährlichen Einreichungen der Zusammenfassungen katastrophaler Risiken an das Cal OES sowie die jährliche Überprüfung des Frameworks.

Koordinierung mit anderen KI- und Datenschutzregimen

SB 53 steht nicht allein. Compliance-Teams sollten es abgleichen mit:

  • Dem NIST AI Risk Management Framework, auf das das Gesetz explizit Bezug nimmt und das einen Großteil des substanziellen Governance-Gerüsts liefert.
  • Der Stufe für KI-Systeme mit allgemeinem Verwendungszweck (General-Purpose AI) des EU AI Act, wo die Dokumentationsüberschneidungen erheblich sind und ein einziges, harmonisiertes internes Framework beide erfüllen kann.
  • Dem Colorado AI Act und dem Texas Responsible AI Governance Act, die Pflichten für Bereitsteller von KI für risikoreiche Entscheidungsfindungen regeln und für Ihre nachgelagerten Kunden gelten könnten.
  • Dem California Consumer Privacy Act (CCPA) und den kommenden Regeln der California Privacy Protection Agency zu automatisierten Entscheidungstechnologien, die sich mit dem Model-Deployment überschneiden, aber unabhängig von SB 53 fungieren.
  • Den freiwilligen Verpflichtungen des US AI Safety Institute und einer etwaigen künftigen Bundesgesetzgebung, die die Compliance-Basis verschieben könnten.

Genaue Compliance-Aufzeichnungen und klare Audit-Trails sind über alle diese Regime hinweg unerlässlich – und dieselbe Dokumentationsdisziplin, die das Finanzberichterstattung unterstützt, stützt auch die KI-Governance-Berichterstattung. Frontier-KI-Frameworks, Bewertungen katastrophaler Risiken, Vorfallsprotokolle und Whistleblower-Untersuchungsberichte sollten mindestens fünf Jahre lang aufbewahrt und so gespeichert werden, dass sie Führungswechsel und Unternehmensumstrukturierungen überdauern.

Halten Sie Ihre Compliance- und Finanzunterlagen revisionssicher

Unabhängig davon, ob Sie ein Frontier-KI-Framework veröffentlichen, vierteljährliche Cal-OES-Einreichungen terminieren oder sich auf eine Untersuchung durch den Generalstaatsanwalt vorbereiten, die zugrunde liegende Disziplin ist dieselbe: klare, versionskontrollierte und prüfbare Aufzeichnungen. Derselbe Plain-Text- und versionskontrollierte Ansatz, den KI-native Teams für ihre Codebasen verwenden, funktioniert hervorragend für ihre Bücher. Beancount.io bietet Plain-Text-Buchhaltung, die Ihnen vollständige Transparenz und Kontrolle über Ihre Finanzdaten gibt – keine Blackboxen, keine Anbieterbindung und ein sauberer Audit-Trail, der natürlich mit der Governance-Disziplin harmoniert, die Regulierungsbehörden heute erwarten. Starten Sie kostenlos und erfahren Sie, warum Entwickler und Finanzexperten auf Plain-Text-Buchhaltung umsteigen.