Un AI Act prend forme sur les terres des Big Tech
![AI Act Californie](https://www.silicon.fr/wp-content/uploads/2024/08/Designer-684x513.jpeg)
La Californie a adopté son propre AI Act, encore soumis à la ratification du gouverneur. En voici les grandes lignes.
Bientôt un « AI Act à l’américaine » ? Possiblement en Californie.
Sur place, la législature avait enregistré, en début d’année, une proposition de loi émanant du sénateur démocrate Scott Wiener. Cette semaine, les chambres basse puis haute l’ont adoptée, chacune à une nette majorité. Dernière étape : la ratification – ou le veto – du gouverneur démocrate Gavin Newsom avant fin septembre.
L’intéressé n’a pas encore publiquement communiqué de position sur ce texte qui a divisé la classe politique autant que l’écosystème tech. Nancy Pelosi s’y est notamment opposée, comme la maire de San Francisco London Breed et plusieurs candidats à sa succession. Elon Musk juge quant à lui que ce Safe and Secure Innovation for Frontier Artificial Intelligence Models Act est « nécessaire ». Aaron Levie, le patron de Box, fait partie de ceux qui ne sont pas du même avis.
The unintended consequences of this bill in many years from now would likely be quite bad. The amount of risk that model providers take on would almost necessarily slow down the rate of AI progress and reduce competition overall. And as we know with regulation, it’s often a one…
— Aaron Levie 🇺🇸 (@levie) August 26, 2024
Un« bouton rouge », mais pas de sanctions pénales
En six mois et quelques, le texte aura été édulcoré sur certains aspects. Les sanctions pénales en ont par exemple disparu, à la faveur exclusive de peines civiles. Le montant maximal de ces dernières n’est par ailleurs plus fonction du coût des modèles : il est désormais plafonné. En outre, les conditions dans lesquelles le procureur général peut lancer des enquêtes sont devenues plus strictes.
Un autre allègement allant dans le sens des développeurs de modèles d’IA (et des fournisseurs de ressources de calcul, que l’« AI Act californien » englobe également) touche au « mécanisme d’arrêt d’urgence ». Il est censé permettre de stopper en totalité l’entraînement et l’inférence des modèles qui se révéleraient problématiques. Ainsi que de leurs dérivés*, aussi longtemps qu’ils sont sous le contrôle desdits développeurs. Par « dérivé », il faut entendre, « copie », « copie modifiée sans fine-tuning », « copie combinée à d’autres logiciels » ou « copie modifiée avec fine-tuning en utilisant moins de 3 x 1025 opérations par seconde (entier ou virgule flottante) et moins de 10 M$ ». Des seuils qui valent jusqu’à fin 2026.
Le texte initial imposait un arrêt sur tous les ordinateurs et systèmes de stockage se trouvant sous le contrôle, sous la responsabilité ou en possession des acteurs concernés. Une mention qui n’est plus d’actualité.
Des flops et des dollars
Le Safe and Secure Innovation for Frontier Artificial Intelligence Models Act a aussi évolué vers une plus grande précision calendaire. Avec deux grandes échéances : le 1er janvier 2026, puis le 1er janvier 2027.
À la première de ces dates, la Government Operations Agency devra avoir produit un document de cadrage en vue de la mise en place de CalCompute, un cluster de cloud public pour le développement et le déploiement d’IA. À la seconde, une deuxième mission lui échoira. Elle révisera annuellement la définition des modèles qui tomberont sous le coup de cette loi. Pour le moment, il s’agit, d’une part, de ceux dont l’entraînement nécessite plus de 1026 (fl)ops et coûte plus de 100 M$ (calculé sur la base du prix moyen du compute sur le marché au début de l’entraînement). D’autre part, de ceux ajustés (fine-tuned) avec au moins 3 x 1025 (fl)ops et 10 M$. Au 1er janvier 2026, les montants feront l’objet d’une indexation sur l’inflation.
Un « palier cyberattaque » à 500 M$
On entend par « développeur » quiconque crée, possède ou a la responsabilité d’un modèle. À ces acteurs, il appartiendra, à l’image de ce qu’établit l’AI Act, d’implémenter les mesures adéquates d’atténuation du risque. Il faudra y ajoindre un protocole de sûreté et de sécurité. Lequel consignera, en particulier, des procédures de test et d’implémentation de garde-fous. En ligne de mire, les risques dits « déraisonnables ». Et ceux pouvant aboutir à des « dommages critiques ». En l’occurrence :
– Création d’armes chimiques, biologiques, radiologiques ou nucléaires entraînant des « pertes massives » (mass casualties)
– Pertes massives d’au moins 500 M$ liées à des cyberattaques sur des infrastructures critiques, que le modèle conduise ces attaques ou y contribue
– Pertes massives d’au moins 500 M$ résultant d’une conduite ayant entraîné des actes que l’humain a supervisés de manière limitée et qui seraient passibles d’une sanction pénale pour avoir engendré la mort ou bien une atteinte importante à la santé physique ou à la propriété
– Autres atteintes graves à la sûreté et à la sécurité publiques comparables en sévérité aux premier et troisième éléments
Il n’y a pas de « dommage critique » si les outputs problématiques sont « raisonnablement accessibles » au public par ailleurs. Même exception pour les modèles associés à d’autres logiciels s’ils n’ont pas sensiblement contribué aux dommages.
Des obligations pour les fournisseurs d’infra
Le Safe and Secure Innovation for Frontier Artificial Intelligence Models Act fixe un délai de 72 heures pour signaler les incidents survenus avec les modèles. Ce délai prend cours à partir du moment où le développeur a connaissance de l’incident… ou de faits suffisants pour pouvoir « raisonnablement » l’estimer. Le terme « incident » recoupe :
– Comportement « autre que la requête » (sic)
– Vol, détournement, usage malveillant, publication inadvertente ou accès non autorisé aux poids
– Panne critique des contrôles techniques ou administratifs
– Usage non autorisé aboutissant ou facilitant substantiellement un dommage critique
Les fournisseurs d’infra deront quant à eux faire en sorte de déterminer – y compris par anticipation – les clients formant ou utilisant des modèles concernés. Il leur appartiendra d’horodater les accès de ces clients et de conserver les adresses IP. Cela ne vaut que pour les clusters d’au moins 1020 (fl)ops avec interconnexion à plus de 100 Gb/s.
Illustration générée par IA