Conformité à la loi californienne SB 53 : Un guide pratique sur la loi Transparency in Frontier AI Act

Le 29 septembre 2025, le gouverneur de Californie, Gavin Newsom, a signé le projet de loi du Sénat 53, la loi sur la transparence de l'intelligence artificielle de pointe (Transparency in Frontier Artificial Intelligence Act - TFAIA), faisant de la Californie la première juridiction américaine à imposer des obligations contraignantes en matière de sécurité, de transparence et de signalement d'incidents aux développeurs des systèmes d'IA les plus intensifs en calcul. La loi est entrée en vigueur le 1er janvier 2026 et, au cours des six derniers mois, elle a discrètement remodelé la manière dont les plus grands laboratoires d'IA et une liste croissante de développeurs de modèles de taille intermédiaire documentent les risques, publient des cadres de gouvernance et informent les régulateurs sur les scénarios de risques catastrophiques.

Si votre organisation entraîne, ajuste (fine-tuning) ou modifie substantiellement des modèles de fondation — ou exploite de grands clusters de calcul sur lesquels d'autres développeurs s'appuient — la loi SB 53 est désormais la loi sur l'IA la plus conséquente que vous devez comprendre aux États-Unis. Ce guide détaille qui est concerné, ce que vous devez publier, comment fonctionne le délai de 15 jours pour le signalement des incidents critiques, quelles sont les obligations relatives aux lanceurs d'alerte et comment traduire la loi en un programme de conformité opérationnel.

Ce que le projet de loi SB 53 réglemente réellement

Contrairement aux lois sur l'IA dans l'emploi qui se propagent d'État en État (comme la loi locale 144 de New York ou la loi sur l'IA du Colorado), la loi SB 53 ne réglemente pas les outils d'embauche algorithmiques, les modèles de souscription de crédit ou les systèmes de sélection de locataires. Elle cible une catégorie beaucoup plus étroite : les modèles de fondation de pointe entraînés à des échelles de calcul extraordinaires, et les scénarios de risques catastrophiques qui peuvent en découler.

La loi se situe à l'intersection de deux traditions réglementaires. Du droit de la sécurité des produits, elle emprunte l'idée que les entreprises doivent publier des évaluations de risques et informer les autorités lorsque des incidents surviennent. Du droit de la régulation financière, elle emprunte l'idée que les acteurs les plus importants supportent des charges de divulgation plus lourdes que les plus petits. Le résultat est un régime à plusieurs niveaux construit autour de deux seuils.

Le seuil de calcul de 10^26 FLOPs

Un « modèle de pointe » selon la SB 53 est défini comme un modèle de fondation entraîné en utilisant plus de 10^26 opérations sur entiers ou à virgule flottante, y compris le calcul cumulatif provenant de l'ajustement fin et des modifications ultérieures. Ce seuil est délibérément aligné sur le déclencheur de signalement de l'ancien décret fédéral 14110 et sur le niveau de l'IA à usage général de la loi sur l'IA de l'UE (EU AI Act), de sorte que la plupart des grands laboratoires américains savent déjà s'ils le franchissent.

Ce qui est parfois omis, c'est que la loi comptabilise le calcul cumulatif provenant des modifications en aval. Si vous prenez un modèle de base qui a été entraîné près du seuil et que vous poursuivez le pré-entraînement, effectuez un ajustement fin par apprentissage par renforcement ou fusionnez les poids avec un autre modèle, vous pouvez faire passer un dérivé au statut de modèle de pointe même si aucun entraînement unique n'a dépassé 10^26 FLOPs. Cataloguer chaque modèle de base, chaque ajustement fin, chaque distillation et chaque fusion de poids — et suivre les FLOPs consommés à chaque étape — est désormais une discipline de tenue de registres essentielle.

Le seuil de revenus de 500 millions de dollars pour les grands développeurs de pointe

Un « grand développeur de pointe » est un développeur de pointe dont l'entité et les sociétés affiliées ont réalisé plus de 500 millions de dollars de revenus bruts annuels au cours de l'année civile précédente. Le test de revenus est consolidé : les sociétés mères, les filiales et les sociétés affiliées sous contrôle commun sont additionnées. Une petite startup d'IA qui a levé un milliard de dollars mais a réalisé 40 millions de dollars de revenus réels n'est pas un grand développeur de pointe ; un conglomérat technologique coté en bourse avec une petite division d'IA qui franchit le seuil de FLOPs l'est presque certainement.

Cette hiérarchisation est importante car les grands développeurs de pointe portent les obligations les plus lourdes : publication d'un cadre pour l'IA de pointe, réalisation d'évaluations de risques catastrophiques, soumission de résumés trimestriels des risques liés à l'utilisation interne à l'Office des services d'urgence de Californie (Cal OES), et maintien d'un canal interne anonyme pour les lanceurs d'alerte. Les plus petits développeurs de pointe — ceux qui sont au-dessus du seuil de FLOPs mais en dessous du seuil de revenus — doivent tout de même publier des rapports de transparence et signaler les incidents de sécurité critiques, mais ils ne sont pas tenus de respecter l'intégralité du régime cadre.

Ce que vous devez publier : le cadre pour l'IA de pointe

Chaque grand développeur de pointe doit publier un cadre pour l'IA de pointe sur son site web et le maintenir à jour. Un examen annuel est obligatoire, et toute modification matérielle doit déclencher une mise à jour dans les 30 jours suivant le changement.

Un cadre défendable traite, au minimum :

Les seuils de risques catastrophiques et les méthodes d'évaluation. Quelles capacités — assistance aux armes chimiques, biologiques, radiologiques, nucléaires ; attaque à grande échelle contre des infrastructures critiques ; scénarios de perte de contrôle d'agents autonomes — le développeur considérerait-il comme franchissant un seuil catastrophique ? Comment le développeur testera-t-il ces capacités avant le déploiement ?
Les stratégies d'atténuation des risques. Mesures concrètes d'atténuation avant déploiement : entraînement au refus, atténuation des capacités, restrictions de déploiement, accès surveillé, déploiements progressifs et surveillance post-déploiement.
Les évaluations par des tiers. Quelles équipes rouges (red teams), évaluateurs et auditeurs externes évalueront le modèle, et comment leurs conclusions seront-elles intégrées ?
Les protocoles de cybersécurité pour les poids de modèles non publiés. Contrôles des menaces internes, modules de sécurité matérielle, segmentation du réseau et journalisation des accès pour protéger les poids avant déploiement contre le vol.
Les procédures de réponse aux incidents de sécurité critiques. Qui décide si un incident doit être signalé, comment le compte à rebours de 15 jours est lancé et comment l'entreprise se coordonne avec le Cal OES.
Les mécanismes de gouvernance interne. Supervision au niveau du conseil d'administration, rôle du responsable de la sécurité de l'IA, voies d'escalade et cadence des examens de sécurité.
L'alignement sur les normes. Correspondance explicite avec le cadre de gestion des risques de l'IA du NIST (AI RMF 1.0) et la norme ISO/IEC 42001, que la loi considère comme des bases fondamentales.

Le cadre n'est pas un document marketing. C'est un artefact destiné aux régulateurs que le procureur général peut utiliser pour évaluer si les engagements publics de l'entreprise correspondent à ses pratiques internes. Le rédiger avec la même rigueur qu'une divulgation de facteurs de risque pour la SEC ou une description de système SOC 2 est la posture appropriée.

Rapports de transparence avant chaque déploiement

Chaque développeur de modèles de pointe — et pas seulement les plus importants — doit publier un rapport de transparence avant de déployer un modèle de pointe nouveau ou substantiellement modifié. Le rapport de transparence est un document spécifique au modèle, distinct du cadre de référence, qui doit inclure :

Le nom de l'entreprise, son site web et un mécanisme de contact pour les préoccupations liées à la sécurité
La date de sortie du modèle et une liste des langues prises en charge et des modalités de sortie
Les utilisations prévues et les restrictions d'utilisation applicables
Pour les grands développeurs, un résumé des évaluations des risques catastrophiques et les résultats, y compris si et comment des évaluateurs tiers ont été impliqués

Une « modification substantielle » inclut des mises à niveau majeures des capacités, l'ajout de nouvelles modalités et des changements significatifs dans le mélange des données d'entraînement. Les versions correctives et les ajustements fins de sécurité de routine ne nécessitent généralement pas de nouveau rapport de transparence, mais les cas limites doivent être documentés avec une justification écrite au cas où le procureur général demanderait ultérieurement pourquoi aucun rapport n'a été publié.

Le délai de 15 jours pour le signalement des incidents critiques

La contrainte de conformité qui a le plus surpris les conseillers juridiques internes est le calendrier de signalement des incidents. Les développeurs de modèles de pointe doivent informer le Bureau des services d'urgence de Californie (Cal OES) d'un incident de sécurité critique dans les 15 jours suivant sa découverte, avec un délai plus strict de 24 heures si l'incident représente une menace imminente pour la sécurité publique.

La loi définit largement un incident de sécurité critique :

Accès non autorisé ou vol de poids de modèles non publiés
Matérialisation d'un risque catastrophique
Perte de contrôle du développeur sur un modèle déployé
Comportement de modèle trompeur ou évasif qui déjoue les garde-fous

Mettre en place un processus interne défendable signifie répondre à trois questions avant même qu'un incident ne survienne :

Qui décide ? Un seul responsable désigné (souvent le responsable en chef de la sécurité de l'IA ou un adjoint désigné) doit avoir l'autorité nécessaire pour déclencher le délai de signalement, avec des critères d'escalade documentés.
Qu'est-ce qui déclenche le délai ? La « découverte » est l'élément déclencheur. La documentation interne doit consigner exactement quand un incident a été découvert, par qui et via quel système de surveillance, car la fenêtre de 15 jours est calculée à partir de ce moment.
Comment le rapport est-il transmis ? Le Cal OES maintient un processus de réception confidentiel pour les soumissions des développeurs. L'équipe de signalement doit répéter le flux de travail de soumission — y compris la transmission cryptée de détails techniques sensibles — bien avant tout incident réel.

Pour les grands développeurs de pointe, l'obligation va au-delà du signalement réactif des incidents. Tous les trois mois (ou selon un autre calendrier raisonnable), les grands développeurs doivent transmettre au Cal OES un résumé de toute évaluation de risque catastrophique découlant de l'utilisation interne de leurs modèles de pointe. Cette cadence trimestrielle est unique à la loi SB 53 et constitue la première fois qu'un statut américain oblige les laboratoires d'IA à signaler les conclusions de risques liés à l'utilisation interne continue à une agence de la branche exécutive.

Protections des lanceurs d'alerte et canal interne anonyme

La loi SB 53 ajoute au régime général des lanceurs d'alerte de Californie un ensemble de protections spécifiques à l'IA qui s'appliquent aux « employés concernés » — ceux dont les fonctions incluent l'évaluation, la gestion ou le traitement du risque de dommage catastrophique lié aux modèles de pointe.

Les développeurs de modèles de pointe ne peuvent pas empêcher un employé concerné de divulguer des informations, ni exercer de représailles contre lui pour avoir divulgué des informations à :

Le procureur général de Californie
Une autorité de régulation fédérale
Un superviseur direct ou un autre superviseur ayant l'autorité d'enquêter
Un autre employé concerné dont les fonctions incluent l'évaluation des risques

Les divulgations protégées couvrent à la fois (a) la croyance raisonnable que les activités du développeur présentent un danger spécifique et substantiel pour la santé ou la sécurité publique lié à un risque catastrophique, et (b) la croyance raisonnable que le développeur a violé la loi SB 53 elle-même.

Les grands développeurs de modèles de pointe doivent également maintenir un canal de signalement interne anonyme. La loi exige :

Un flux de travail permettant aux employés concernés de soumettre des divulgations anonymes concernant des préoccupations de risques catastrophiques
Des mises à jour mensuelles sur l'état de l'enquête pour l'employé à l'origine du signalement
Des séances d'information trimestrielles aux dirigeants et administrateurs résumant les divulgations et les résultats, les personnes nommées accusées d'actes répréhensibles étant exclues de l'audience de la séance

Les tribunaux peuvent accorder des frais d'avocat aux plaignants qui obtiennent gain de cause dans des actions pour représailles. Critiquement, la loi déplace la charge de la preuve : lorsqu'un employé concerné démontre qu'une activité protégée a été un facteur contributif à une mesure défavorable, il incombe au développeur de prouver que la mesure aurait été prise pour des raisons légitimes indépendantes.

La définition du risque catastrophique

Le centre de gravité de la loi SB 53 est sa définition du « risque catastrophique ». La loi le définit comme un risque prévisible et matériel qu'un modèle de pointe contribue matériellement à la mort ou à des blessures graves de plus de 50 personnes, ou à plus d'un milliard de dollars de dommages ou de pertes de biens, par l'un des trois mécanismes causaux suivants :

Assistance aux armements. Contribution matérielle à la création, au déploiement ou à l'utilisation d'une arme chimique, biologique, radiologique ou nucléaire, ou d'une cyberarme causant des dommages comparables.
Conduite nuisible incontrôlée. Conduite par le modèle avec une surveillance humaine limitée qui, si elle était commise par un humain, constituerait un crime grave nécessitant une intention.
Perte de contrôle. Perte de contrôle du développeur sur le modèle de telle sorte qu'il s'engage dans une conduite matériellement nuisible.

La définition prévoit des exclusions importantes. Les risques basés sur des informations déjà accessibles au public, les dommages découlant d'une activité fédérale licite et les dommages où la contribution du modèle n'est pas matérielle sortent tous du champ d'application. Cette exclusion est ce qui empêche les risques d'application quotidienne — biais dans le tri des CV, conseils médicaux hallucinés, violation du droit d'auteur — de déclencher le régime des risques catastrophiques. Ces dommages sont réels, mais ils sont traités par d'autres lois, pas par la SB 53.

Sanctions civiles et mise en œuvre

Le Procureur général de Californie détient l'autorité d'exécution exclusive. Les sanctions civiles peuvent atteindre 1 million de dollars par infraction, modulées selon la gravité de la conduite. Il n'existe pas de droit d'action privé en vertu de la loi SB 53 elle-même, bien que les dispositions relatives aux représailles contre les lanceurs d'alerte soient applicables indépendamment par des actions civiles intentées par les employés lésés.

En pratique, le risque d'exécution est concentré dans trois domaines :

Le contournement des seuils. Les entreprises qui structurent leurs cycles d'entraînement pour rester juste en dessous de 10^26 FLOPs tout en offrant des capacités manifestement de pointe feront l'objet d'un examen minutieux. Le libellé de la loi relatif au calcul cumulatif rend cette stratégie fragile.
Les lacunes du cadre de gouvernance. Un cadre qui énumère des politiques sans preuve de mise en œuvre sera plus facile à attaquer qu'un cadre qui lie chaque engagement à des artefacts opérationnels, des responsables désignés et des journaux d'audit.
Les retards de signalement des incidents. Manquer l'échéance de 15 jours, ou celle de 24 heures en cas de menace imminente, est le type de violation simple et documentable que les régulateurs poursuivent historiquement avec agressivité.

Élaborer un plan de mise en œuvre de 90 jours

Pour une organisation qui n'a pas encore mis en place de programme relatif à la loi SB 53, la séquence suivante est recommandée :

Jours 1 à 30 : Analyse de la portée et des lacunes.

Inventorier chaque modèle de fondation entraîné, affiné, fusionné ou substantiellement modifié, avec une estimation de la puissance de calcul cumulative pour chacun.
Déterminer si le chiffre d'affaires consolidé (incluant toutes les filiales) a dépassé 500 millions de dollars au cours de l'année civile précédente.
Former un groupe de travail transversal sur la sécurité de l'IA et la conformité comprenant des membres de l'ingénierie, de la sécurité, du juridique, de la communication et des RH.
Comparer les pratiques actuelles avec le NIST AI RMF 1.0 et l'ISO/IEC 42001 pour identifier les lacunes.

Jours 31 à 60 : Rédaction et gouvernance.

Rédiger le cadre pour l'IA de pointe sous la forme d'un document versionné et publiable.
Élaborer la méthodologie d'évaluation des risques catastrophiques, incluant les évaluations de capacités, la modélisation des menaces et les critères permettant de déclarer un modèle comme ayant des capacités de pointe dans un domaine dangereux.
Mettre en place les contrôles de cybersécurité pour les poids non publiés, avec des journaux d'accès documentés et une surveillance des menaces internes.
Établir le canal de signalement interne anonyme et le flux de travail pour les mises à jour mensuelles du statut et les briefings trimestriels du conseil d'administration.

Jours 61 à 90 : Préparation opérationnelle.

Réaliser un exercice de simulation de réponse aux incidents reproduisant la découverte d'un vol de poids et la matérialisation d'un risque catastrophique, puis s'entraîner aux flux de signalement de 15 jours et de 24 heures.
Former les employés concernés sur les droits des lanceurs d'alerte et le canal anonyme.
Publier le rapport de transparence pour tout modèle dans le pipeline de déploiement, avec une référence croisée au cadre pour l'IA de pointe.
Planifier les soumissions trimestrielles du résumé des risques catastrophiques au Cal OES ainsi que la révision annuelle du cadre.

Coordination avec les autres régimes d'IA et de confidentialité

La loi SB 53 n'est pas isolée. Les équipes de conformité doivent la mettre en relation avec :

Le cadre de gestion des risques de l'IA du NIST (AI RMF), auquel la loi fait explicitement référence et qui fournit une grande partie de la structure de gouvernance de fond.
La catégorie de l'IA à usage général du Règlement européen sur l'IA (AI Act), où le chevauchement de la documentation est substantiel et où un cadre interne unique et harmonisé peut satisfaire aux deux réglementations.
La loi sur l'IA du Colorado et la loi sur la gouvernance responsable de l'IA du Texas, qui régulent les obligations des déployeurs pour l'IA de prise de décision à haut risque et peuvent s'appliquer à vos clients en aval.
La loi californienne sur la protection de la vie privée des consommateurs (CCPA) et les règles à venir de l'Agence californienne de protection de la vie privée sur la technologie de prise de décision automatisée, qui croisent le déploiement de modèles mais fonctionnent indépendamment de la SB 53.
Les engagements volontaires de l'AI Safety Institute fédéral et toute législation fédérale de préemption à venir, qui pourraient modifier le seuil de conformité de base.

Des registres de conformité précis et des pistes d'audit claires sont essentiels à travers tous ces régimes — et la même discipline documentaire qui soutient les rapports financiers soutient les rapports de gouvernance de l'IA. Les cadres d'IA de pointe, les évaluations de risques catastrophiques, les journaux d'incidents et les dossiers d'enquête sur les lanceurs d'alerte doivent être conservés pendant au moins cinq ans et stockés de manière à survivre aux changements de direction et aux restructurations d'entreprise.

Gardez vos dossiers de conformité et financiers prêts pour l'audit

Que vous publiiez un cadre pour l'IA de pointe, que vous planifiiez des soumissions trimestrielles au Cal OES ou que vous vous prépariez à une enquête du Procureur général, la discipline sous-jacente est la même : des dossiers clairs, versionnés et auditables. La même approche en texte brut et versionnée que les équipes natives de l'IA utilisent pour leurs bases de code fonctionne parfaitement pour leur comptabilité. Beancount.io propose une comptabilité en texte brut qui vous offre une transparence et un contrôle complets sur vos données financières — sans boîtes noires, sans dépendance vis-à-vis d'un fournisseur, et avec une piste d'audit propre qui s'associe naturellement à la discipline de gouvernance que les régulateurs exigent désormais. Commencez gratuitement et découvrez pourquoi les développeurs et les professionnels de la finance passent à la comptabilité en texte brut.