Résumé#
S. 5576, la Loi sur la gestion des risques et la sécurité de l'intelligence artificielle de 2026, créerait un conseil consultatif permanent au sein du ministère du Commerce et ajouterait des responsabilités pour certains développeurs d'IA et opérateurs d'infrastructures critiques. Son objectif déclaré est de traiter les risques liés aux modèles d'IA de pointe et aux agents d'IA. Elle a été introduite au Sénat et n'est pas encore une loi ; son adoption est incertaine.
- Le secrétaire au Commerce établirait le Conseil de sécurité de l'intelligence artificielle. Le NIST fournirait son personnel et son soutien.
- Le Conseil développerait des normes techniques, y compris des normes pour évaluer les risques liés à l'IA et sécuriser les environnements de test de l'IA. Le secrétaire adopterait les normes proposées ou modifiées par voie réglementaire, et les développeurs devraient suivre les normes qui leur sont applicables.
- Un développeur d'un modèle d'IA de pointe devrait donner au Conseil accès au modèle et aux matériaux nécessaires pour le faire fonctionner au moins 45 jours avant de l'introduire dans le commerce. Le projet de loi ne nécessite pas l'approbation du Conseil pour une publication.
- Les développeurs, tels que définis par le projet de loi, devraient publier, suivre et déposer un plan de sécurité pour chaque système ou modèle d'IA qu'ils créent, modifient substantiellement ou utilisent pour former ou évaluer d'autres modèles d'IA.
- Certains développeurs et opérateurs d'infrastructures critiques devraient signaler les incidents de sécurité ou de sûreté de l'IA confirmés : dans les 30 jours, ou dans les 72 heures si l'incident pose une menace imminente pour la sécurité nationale, les infrastructures critiques ou la sécurité publique.
- Le NIST créerait une base de données publique d'incidents sélectionnés et de défauts d'IA. Le projet de loi demande également au NIST de développer des orientations et un profil ainsi qu'un modèle de documentation pour les agents d'IA ; ceux-ci ne sont pas des exigences d'approbation.
Ce que cela signifie pour vous#
- Développeurs d'IA de pointe : Ils devraient fournir un accès avant publication aux modèles couverts, suivre les normes applicables et préparer et déposer des plans de sécurité. Le terme « développeur » est limité dans le projet de loi à un développeur d'un modèle d'IA de pointe, bien que les plans de sécurité couvrent chaque système ou modèle que ce développeur crée, modifie substantiellement ou utilise dans la formation ou l'évaluation.
- Opérateurs d'infrastructures critiques : Les opérateurs utilisant l'IA avec des systèmes de contrôle industriel ou d'autres technologies opérationnelles devraient signaler les incidents confirmés dans les délais indiqués.
- Autres organisations et chercheurs : Les organisations privées et publiques, les groupes de la société civile et les chercheurs académiques pourraient partager volontairement des informations sur des incidents et des défauts suspects ou confirmés.
- Utilisateurs et organisations d'agents d'IA : Le NIST développerait un profil de risque et un modèle de documentation commun. Le projet de loi ne nécessite pas que les organisations les utilisent.
- Le public : Le projet de loi créerait une base de données, mais le NIST déciderait quels rapports ou défauts y appartiennent. Les descriptions publiées doivent généralement protéger l'identité des parties affectées.
- Développeurs qui violent les normes applicables : Le secrétaire ferait respecter la conformité. Un développeur pourrait faire face à une pénalité civile allant jusqu'à 250 000 $ par violation ; chaque jour où une violation se poursuit compte séparément. Le procureur général pourrait engager une action civile à la demande du secrétaire.
Finances#
Le projet de loi nécessite du personnel et du soutien d'agence, mais le matériel disponible ne donne aucune estimation de coût.
- Le NIST doit fournir du personnel et d'autres soutiens pour le Conseil ; le projet de loi ne précise pas combien de personnel ou quel en serait le coût.
- Le secrétaire peut utiliser des environnements de calcul de recherche sécurisés sur une base remboursable et les rendre disponibles sur une base de récupération des coûts.
- Le projet de loi fixe des pénalités civiles mais n'estime pas les revenus des pénalités. Il ne précise pas d'affectation ou de dépenses fédérales totales.
Ce qui n'est pas clair#
- Le projet de loi ne fixe pas de test précis pour déterminer quels modèles comptent comme « de pointe » ou atteignent son seuil de risque sérieux ; le Conseil développerait des processus d'évaluation.
- Le secrétaire déciderait de la forme et de la manière de déposer les plans de sécurité. Le projet de loi ne précise pas combien de détails les plans doivent contenir ni comment les informations commerciales confidentielles en eux seraient protégées.
- Le projet de loi ne décrit pas comment le Conseil gérerait ou sécuriserait les matériaux du modèle qu'il reçoit, au-delà des exigences liées aux informations classifiées.
- Le projet de loi ne fixe pas de processus détaillé pour décider si le plan de sécurité d'un développeur ou sa conformité à une norme est adéquat, ni ne prévoit de processus d'appel.
- Il n'est pas clair comment « chaque violation » serait comptée pour les pénalités au-delà de la règle selon laquelle chaque jour continu est une violation distincte.
Arguments en faveur#
- Un argument possible en faveur du projet de loi est que des normes techniques communes pourraient aider les développeurs à évaluer les risques et à sécuriser les environnements de test de manière plus cohérente.
- Les rapports d'incidents requis de la part de développeurs et d'opérateurs d'infrastructure spécifiés pourraient fournir au NIST des informations sur des risques que des rapports volontaires pourraient manquer.
- Une base de données publique d'incidents sélectionnés et de défauts récurrents pourrait aider d'autres à apprendre des problèmes, tandis que le projet de loi exige l'anonymisation des parties affectées.
- L'accès du Conseil avant qu'un modèle de pointe n'entre dans le commerce pourrait soutenir les tests de sécurité et de sûreté avant la publication.
Arguments contre#
- Les développeurs seraient soumis à des normes obligatoires, des plans de sécurité, un accès aux modèles et des obligations de signalement, mais le projet de loi laisse des détails importants aux normes ultérieures et aux décisions des agences.
- Le Conseil aurait accès aux poids des modèles et à d'autres matériaux avant la publication. Le projet de loi ne précise pas de garanties détaillées pour ces matériaux au-delà de ses règles sur les informations classifiées.
- Le travail du Conseil pourrait impliquer des informations sensibles ou propriétaires, et le projet de loi permet des sessions fermées pour plusieurs raisons. Cela pourrait limiter la visibilité du public sur certaines parties de son travail.
- Le projet de loi exige du personnel fédéral et un nouveau travail d'agence sans donner d'estimation de coût ni préciser une affectation.