SB1047 était une mauvaise idée. Mais le dernier SB53 du Sénateur Wiener est sur la bonne voie, et il est important de souligner les progrès. Voici mon raisonnement. Mon approche pour réguler des technologies nouvelles comme les modèles est la suivante : nous ne savons pas comment définir une atténuation et une assurance "bonnes", mais nous le saurons quand—et si—nous le verrons. Il y a deux implications. #1. Nous ne devrions pas prescrire des seuils de risque ou des normes de soins pour le développement de modèles. Nous ne pouvons pas nous mettre d'accord sur les risques qui comptent, comment les mesurer, ou combien est trop. La seule orientation pour les développeurs, les régulateurs et les tribunaux est un ensemble de pratiques naissantes déterminées principalement par des entreprises à code fermé s'appuyant sur des paywalls pour faire le gros du travail. Cela pourrait freiner l'innovation ouverte en exposant les développeurs à une responsabilité vague ou accrue pour une diffusion généralisée. C'était SB1047 en résumé, ainsi que ~5 équivalents qu'il a inspirés à travers les États-Unis cette session, comme le RAISE Act à New York. Nous devrions éviter cette approche. Ces propositions sont—dans des aspects étroits mais cruciaux—trop loin de la réalité. Et pourtant : #2. Nous devons mettre en lumière les pratiques de l'industrie pour mieux comprendre la diligence, ou son absence, appliquée par différentes entreprises. Si les développeurs doivent s'engager à une politique de sécurité et de sûreté, montrer leur travail, et laisser une trace écrite, nous pouvons mieux évaluer la force de leurs revendications, surveiller les risques émergents, et décider d'une intervention future. C'est l'Acte sur l'IA de l'UE et le Code de Pratique final en résumé, que OpenAI et Mistral ont tous deux soutenus, et c'est aussi la dernière version du SB53 de @Scott_Wiener. Si nous allons réguler le développement de modèles, c'est fondamentalement la meilleure approche : réguler la transparence—et non les capacités, les atténuations, ou le risque acceptable. Cela donnerait à au moins une juridiction américaine l'autorité de surveillance de Bruxelles, et cela éviterait des effets indésirables sur le développement ouvert. Pour être clair, il y a encore des icebergs devant : > Complexité. Que ce soit Big Tech ou non, ce sont des obligations de documentation et de reporting lourdes. Tactiquement parlant, plus c'est complexe, plus ce projet de loi deviendra vulnérable. > Incitations. Le reporting public obligatoire des évaluations de risque volontaires crée une incitation perverse pour les développeurs à sous-tester leurs modèles, et à fermer les yeux sur des risques difficiles. Permettre aux développeurs de divulguer leurs résultats à des auditeurs ou des agences plutôt que publiquement pourrait aider à promouvoir une plus grande franchise dans leurs évaluations internes. > Cheval de Troie. La culture hyperactive de Californie de modification et d'amendement peut rendre difficile l'examen de ces projets de loi. Si le SB53 se transforme en un projet de loi sur les normes de soins comme le SB1047 ou le RAISE, il devrait être rejeté pour les mêmes raisons qu'auparavant. Plus il y a de décorations ajoutées à cet arbre de Noël, plus le projet de loi devient contentieux. > Ampleur. Le projet de loi jette un large filet avec des définitions expansives de risque catastrophique et de capacité dangereuse. Pour un projet de loi "reporting obligatoire / pratiques volontaires", cela fonctionne. Si ce projet de loi était un projet de loi sur les normes de soins, il serait irréalisable. En résumé : chapeau bas au Sénateur Wiener pour avoir engagé et répondu de manière réfléchie aux retours au cours de l'année passée. C'est rafraîchissant de voir un projet de loi qui s'appuie réellement sur des critiques antérieures. Il y a encore de nombreux chemins que ce projet de loi pourrait emprunter—et il a évolué bien au-delà de la proposition originale de dénonciation—mais la trajectoire est prometteuse.