- Le SB-1047 vise à promouvoir un développement de l’IA sûr, mais ses dispositions actuelles pourraient imposer une charge excessive aux développeurs open source et aux petites entreprises
- Si les restrictions sur le développement se renforcent, la transparence et la collaboration pourraient reculer, affaiblissant aussi la capacité d’une communauté d’experts plus large à repérer et corriger les problèmes de sécurité
- La définition de “covered model” est large, et les exigences de suspension obligatoire, de signalement et de respect des directives étant lourdes, même le développement de modèles open source de bonne foi pourrait être découragé
- Les audits, le conseil juridique, les frais et le risque de sanctions civiles peuvent constituer des barrières à l’entrée et encourager l’autocensure pour les startups et les chercheurs
- Une meilleure approche consisterait à réglementer les usages à haut risque plutôt que le développement des modèles lui-même, tout en soutenant l’open source, la coopération entre industrie, universités et pouvoirs publics, ainsi que l’investissement public dans l’expertise IA
Position de principe sur le SB-1047
- Ce texte est une contribution personnelle de Jeremy adressée au rédacteur du projet de loi SB-1047, et ne reflète pas la position officielle d’Answer.AI
- L’objectif poursuivi par le SB-1047, à savoir un développement de l’IA sûr et sécurisé, peut en lui-même être considéré positivement
- Le problème est que certaines dispositions du texte actuel pourraient avoir des effets négatifs sur les développeurs open source, les petites entreprises et l’innovation dans l’ensemble de l’écosystème IA
- Si le développement open source est restreint, la sécurité de l’IA pourrait elle aussi s’en trouver affaiblie
- Si la transparence et la collaboration reculent, il devient plus difficile pour un plus grand nombre d’experts d’identifier et de résoudre les problèmes de sécurité potentiels
- Si le contrôle se concentre entre quelques grands acteurs, la diversité et la résilience diminuent, ce qui accroît le risque de point unique de défaillance et de risques systémiques
Inquiétudes sur un frein au développement open source
- L’open source est un élément central du succès de l’industrie logicielle américaine et a permis à de nombreuses personnes d’accéder à des outils logiciels essentiels
- Une grande partie des briques fondamentales de l’IA moderne provient aussi de l’open source, et la recherche universitaire comme la recherche sur la sûreté et la sécurité repose elle aussi presque entièrement sur l’open source
- Si l’open source s’affaiblit, les développeurs, les consommateurs, le monde académique et les nouvelles startups en subiront tous les effets
-
Définition excessivement large de “covered model”
- La définition de “covered model” dans le texte est très large, au point de pouvoir inclure divers modèles open source à faible risque
- En conséquence, les activités de développeurs de bonne foi menant des projets d’IA utiles pourraient elles aussi être involontairement criminalisées
-
La question de la responsabilité pour les outils à usage général
- Les modèles d’IA ressemblent davantage à des logiciels généralistes exécutés sur ordinateur, comme les traitements de texte, les calculatrices ou les navigateurs web
- De même qu’un développeur de navigateur web ou de calculatrice ne peut empêcher tous les usages malveillants, il est difficile pour un créateur de modèle de garantir qu’il ne sera jamais utilisé à des fins nuisibles
- Si l’on impose cette responsabilité aux créateurs d’outils généralistes, il pourrait devenir en pratique impossible de créer de tels outils autrement que dans de grandes entreprises dotées d’équipes juridiques conséquentes
-
Le poids des exigences imposées aux développeurs
- Le texte impose aux développeurs des contraintes telles que la suspension obligatoire, un reporting étendu et le respect de “covered guidance”, potentiellement ambigu
- Pour les développeurs open source qui ne disposent pas des ressources nécessaires pour absorber des procédures réglementaires complexes, ces exigences sont encore plus lourdes
- La crainte des conséquences juridiques et des démarches bureaucratiques peut réduire la participation au développement open source et affaiblir la culture de collaboration qui a porté les avancées de l’IA
- Si la transparence recule, il devient également plus difficile de repérer et résoudre les problèmes potentiels de sécurité
Effets sur les petites entreprises et l’écosystème de recherche
- La réglementation proposée pourrait créer d’importantes barrières à l’entrée pour les petites entreprises et les startups qui cherchent à innover dans l’IA
- Les coûts de conformité et les risques juridiques peuvent décourager les fondateurs et limiter la concurrence
- Il pourrait en résulter un ralentissement de l’innovation et une concentration accrue du pouvoir entre les mains des grandes entreprises déjà en place
-
Coûts et risques juridiques
- Les coûts de conformité réglementaire, notamment les frais, les audits et le conseil juridique, représentent une lourde charge pour les petites entreprises et les startups
- Une telle structure de coûts peut limiter la concurrence, concentrer le pouvoir chez les grands groupes existants et freiner l’innovation
-
Frein à la recherche et fuite des talents
- La peur de déclencher involontairement certaines dispositions du texte peut conduire les chercheurs et développeurs à l’autocensure
- Si certaines pistes de recherche en IA prometteuses sont évitées, le progrès scientifique et le potentiel de l’IA pour résoudre des problèmes de société s’en trouvent limités
- Un environnement trop restrictif peut pousser des chercheurs et développeurs IA talentueux à quitter la Californie
- Cela pourrait nuire à l’économie californienne et affaiblir son leadership en matière d’innovation IA
Répercussions sur l’innovation IA en Californie et aux États-Unis
- La Californie joue un rôle essentiel dans l’innovation américaine, en particulier dans le secteur technologique
- Si le SB-1047 impose une charge excessive au développement de l’IA, le leadership de la Californie dans ce domaine clé pourrait s’affaiblir
- Ses effets pourraient se diffuser à l’ensemble des États-Unis et ralentir les progrès globaux de la recherche et du développement en IA
Alternatives proposées
- Plutôt que de réglementer le développement même des modèles d’IA, il faut une approche centrée sur les applications de l’IA et les risques réels
-
Soutenir le développement open source
- Encourager le développement open source des modèles d’IA peut renforcer la collaboration et la transparence, et contribuer à un écosystème IA plus diversifié et plus résilient
-
Se concentrer sur la régulation des usages plutôt que du développement
- La régulation devrait porter non pas sur le développement des modèles d’IA, mais sur la manière dont l’IA est utilisée
- Il faut en particulier cibler les applications qui présentent des risques élevés pour la sécurité publique et la sûreté
- En réglementant l’usage de l’IA dans des domaines à fort potentiel de préjudice, comme la santé, la justice pénale ou les infrastructures critiques, on peut maintenir la responsabilité sur les usages nocifs tout en permettant la poursuite des avancées technologiques en IA
-
Investir dans la transparence, la collaboration et l’expertise
- La coopération entre l’industrie, le monde académique et les pouvoirs publics peut encourager l’élaboration et l’adoption de bonnes pratiques pour un développement responsable de l’IA
- Il faut à la fois des standards industriels, la promotion du développement open source et des investissements dans la recherche sur la sécurité de l’IA
- Doter les administrations des ressources nécessaires pour développer une expertise en IA leur permettrait de surveiller et de traiter plus efficacement les risques potentiels
- Une telle approche permettrait une régulation de l’IA plus fine, mieux équilibrée entre sécurité et innovation
Dispositions précises qui suscitent des inquiétudes
- Section 22602 (f) : la définition de “covered model” est excessivement large et pourrait inclure divers modèles open source
- Section 22603 (b) : les exigences imposées aux développeurs sont excessives et pourraient freiner le développement open source
- Section 22606 (a) : le risque de sanctions civiles pourrait produire un effet dissuasif sur la recherche et l’innovation
- Section 11547.6 (c)(11) : le pouvoir d’imposer des frais pourrait créer des barrières à l’entrée pour les petites entreprises
1 commentaires
Avis de Hacker News
Les créateurs de modèles ne peuvent pas garantir que leurs modèles ne seront jamais utilisés à des fins nuisibles, pas plus que les développeurs de navigateurs web, de calculatrices ou de traitements de texte
Si l’on fait porter la responsabilité aux créateurs de ces outils à usage général, dans les faits, seuls les grands groupes disposant d’équipes juridiques suffisantes pourront en créer. Il est presque impossible de garantir qu’une technologie ne sera pas utilisée à des « fins nuisibles », et ce type de disposition semble constituer un obstacle supplémentaire empêchant les acteurs autres que les grandes entreprises de participer au développement des LLM
Il ne s’agit même pas d’être responsable des incidents de sécurité eux-mêmes, seulement de les signaler ; cela peut être quelque peu contraignant, mais dans l’ensemble cela paraît assez raisonnable
Le fait qu’un modèle très performant soit utilisé à de mauvaises fins, voire cause des dommages catastrophiques, n’entraîne pas non plus automatiquement une responsabilité ; la question centrale est de savoir si des mesures préventives raisonnables ont été prises. Il aurait été possible d’opter pour un régime de responsabilité stricte rendant les développeurs responsables des dommages catastrophiques indépendamment de toute faute de leur part, mais ce projet de loi ne le fait pas
Dans l’ensemble, l’idée est assez raisonnable : si un modèle peut provoquer des dommages catastrophiques — même si ce n’est pas le cas des modèles actuels, cela pourrait l’être pour des modèles futurs — il ne faut pas le déployer d’une manière dont on peut prévoir qu’elle causera de tels dommages
Si vous voulez connaître le détail du texte, je recommande le long article de Zvi. Personnellement, j’y vois une proposition assez étroite, centrée sur les risques les plus graves, et par exemple beaucoup plus limitée que l’EU AI Act : https://thezvi.substack.com/p/on-the-proposed-california-sb-...
Sinon, il faudrait aussi critiquer les mesures visant à empêcher la recherche open source sur les agents biologiques, les ogives nucléaires open source ou les protocoles open source de clonage humain. Ce sont également toutes des technologies à double usage et, objectivement, moralement neutres
C’est comme ne pas autoriser la vente de grenades au coin de la rue. Cette volonté d’échapper à la responsabilité est l’un des aspects que j’apprécie le moins chez les grandes entreprises technologiques
Cela pourrait inclure l’IA pour la découverte de médicaments et la science des matériaux, l’IA pour la gestion du réseau électrique et du trafic haut débit, ainsi que l’IA pour les services financiers et de santé. Du côté du complexe militaro-industriel, si seuls des contrats fédéraux sont concernés, cette loi pourrait ne pas pouvoir y toucher du tout. Le développement d’IA militaires classifiées paraît imprudent ; on se demande s’ils n’ont pas vu War Games
https://technologymagazine.com/top10/top-10-military-technol...
Au moins, avec l’open source, les capacités apparaissent plus immédiatement
Le monde politique semble viser très fortement l’IA open source, au point que la situation paraît délirante
Soros disait que la combinaison de projets d’IA d’entreprise et de projets d’IA gouvernementaux créait une menace plus puissante que les dictateurs de la guerre froide, qui se tenaient à distance de l’innovation des entreprises. L’idée était que « l’alliance entre régimes répressifs et monopoles IT donne à ces régimes un avantage intégré sur les sociétés ouvertes. Ils représentent une menace mortelle pour les sociétés ouvertes »
https://www.wired.com/story/mortal-danger-chinas-push-into-a...
Littéralement tous ceux qui recherchent une influence mondiale salivent devant l’IA. J’en viens à me demander sérieusement si je devrais acheter un Mac Studio 512 Go quand il sortira, pour faire tourner un gros modèle llama3 qui pourrait bientôt être interdit
Les investisseurs ou bénéficiaires d’entreprises comme OpenAI pourraient entretenir des liens étroits avec des responsables politiques. Il y a de fortes chances qu’il n’existe pas de lien direct, et ils sont probablement déjà très doués pour dissimuler ce genre de connexions et permettre des dénégations plausibles
Nous en sommes encore vraiment au tout début. À moins que le monde universitaire échoue lourdement, dans environ cinq ans, des clusters de recherche de professeurs pourront entraîner des modèles au niveau de l’état de l’art actuel, et ce ne sera sans doute pas limité aux seules universités R1
À long terme, j’ai l’impression que toute personne ayant accès à l’équivalent textuel d’une bibliothèque pourra créer un modèle utilisable. Il n’y a rien de magique dans notre cerveau ; un jour, nous pourrons enseigner la lecture et l’écriture à des ordinateurs avec à peu près le nombre de livres nécessaire pour instruire un être humain. Même s’ils sont dix fois plus stupides que nous, alors que l’Américain moyen lit des centaines de livres au cours de sa vie, va-t-on exiger un permis pour posséder plus de quelques milliers d’ebooks ?
Même dans une version plus faible, sans aucune autonomie et où tout ne serait que le résultat de prompts, si elle tient réellement ses promesses en matière de performance, elle sera profondément déstabilisatrice. Nous ne sommes absolument pas prêts pour un monde où presque tout peut être falsifié à un coût proche de zéro
En revanche, il est aussi très probable que cela prenne la forme de règles très étranges, comme l’ITAR existant, qui n’ont presque aucun rapport avec la sécurité réelle
C’est beaucoup moins cher qu’un Mac Studio. J’ai acheté un R820 pour quelques centaines de dollars ; il contient 256 Go de RAM et il reste de la marge pour l’étendre davantage
Comme cela n’apparaît pas dans le billet, j’ajoute que le 7 février 2024, le sénateur Scott Wiener a présenté le SB-1047 devant le parlement de Californie.
Son nom officiel est le Safe and Secure Innovation for Frontier Artificial Intelligence Systems Act, et c’est un projet de loi visant à encadrer le développement et l’utilisation des modèles d’IA avancés. Il impose aux développeurs de procéder à certaines évaluations de sécurité avant l’entraînement d’un modèle d’IA, de respecter plusieurs exigences de sécurité et de signaler les incidents de sécurité liés à l’IA. Il crée aussi, au sein du Department of Technology, une Frontier Model Division chargée de la supervision, et introduit des amendes civiles en cas d’infraction.
https://www.dlapiper.com/en/insights/publications/2024/02/ca...
https://www.opensecrets.org/orgs/openai/summary?id=D00008425...
https://www.sfgate.com/politics/article/fentanyl-dealers-in-...
Je crains que ce type de réglementation ne crée un effet de verrouillage favorable aux entreprises d’IA déjà en tête, rendant impossible l’arrivée de nouveaux entrants.
À moins d’être une équipe complètement folle capable de lever environ 1 milliard de dollars dès le départ, il n’y a aucune chance de rivaliser.
Difficile à croire. J’aime bien les positions de Scott Wiener sur le logement, mais ce projet de loi est truffé d’interventionnisme excessif de l’État.
Ironiquement, il produira le même effet que le système NIMBY contre lequel il se bat depuis longtemps.
Il demande par exemple, avant de commencer l’entraînement d’un modèle couvert non dérivé, d’implémenter une capacité permettant de l’arrêter rapidement et complètement tant qu’il ne bénéficie pas d’une exemption d’obligations limitées. Au bout du compte, cela ressemble à l’idée qu’on ne peut entraîner que ce qui a été autorisé.
Évidemment, un nouveau service doté du pouvoir de prélever des frais l’accompagne aussi. Il crée la Frontier Model Division, chargée d’examiner les rapports annuels de certification des développeurs, d’en publier les conclusions synthétiques et de prélever les frais correspondants pour les verser dans un fonds séparé.
Et bien sûr, il faudra aussi payer des consultants. Le Department of Technology confierait à des consultants la création d’un cluster public de cloud computing appelé CalCompute, avec pour objectifs principaux d’étudier le déploiement sûr et sécurisé de grands modèles d’IA et de favoriser une innovation équitable.
Cela devrait être facile, me semble-t-il, et garantir qu’on puisse quand même l’éteindre paraît être une bonne chose.
Je me demande quel sera, à long terme, le meilleur État pour les startups d’IA.
J’aurais naturellement pensé à la Californie, mais il semble désormais plus important de choisir un État peu susceptible de surréglementer. Washington ne montre pas encore de mouvement de ce type, n’a pas d’impôt sur le revenu au niveau de l’État, et compte beaucoup d’ingénieurs et de chercheurs en IA à Seattle/Redmond, donc c’est une option. Le Texas a aussi de bonnes chances de ne pas ajouter de réglementation, et être à Austin offrirait des avantages similaires. Si la Californie repousse cette industrie par la réglementation, quel autre endroit émergera ?
C’est pourquoi les villes du Texas et de Floride sont en croissance. Seattle a un mauvais climat, Washington est froid, et les grandes villes y sont mal gérées, ce qui les rend peu attractives pour les familles aisées.
En Californie, l’électricité est particulièrement chère, et la construction de nouvelles installations industrielles y est aussi rendue difficile. C’est encore plus vrai près des étendues d’eau, qui pourraient aider à répondre aux besoins de refroidissement. Une entreprise peut garder une partie de ses employés en Californie, mais le matériel tournera probablement ailleurs.
Cet article est très mauvais et sent le contenu généré par LLM.
Si vous voulez vraiment comprendre ce projet de loi, mieux vaut lire l’analyse de Zvi : https://thezvi.substack.com/p/on-the-proposed-california-sb-...
Par exemple, avant de commencer l’usage commercial, public ou à grande échelle d’un modèle couvert, en l’absence de décision positive de sécurité ou d’exemption d’obligations limitées, le développeur doit, selon le texte, mettre en place des protections et des exigences raisonnables pour « empêcher qu’un individu utilise ce modèle afin de créer un modèle dérivé susceptible de causer un préjudice grave ».
C’est tout simplement impossible. Si l’on me donne les poids du modèle, je peux clairement le fine-tuner pour qu’il provoque un préjudice couvert. Je peux par exemple lui faire fournir des instructions de fabrication d’armes chimiques ou biologiques. Cette exigence est impossible à satisfaire, et si elle ne l’est pas, le modèle couvert ne peut pas être déployé.
Il est très probable que l’entreprise ou l’auteur ait directement essayé ses propres produits internes.
Un « modèle concerné » est un modèle d’IA qui satisfait à l’un des deux critères suivants.
Premièrement, un modèle entraîné avec plus de 10^26 opérations sur des entiers ou en virgule flottante. Deuxièmement, un modèle entraîné avec un volume de calcul suffisamment important pour qu’on puisse raisonnablement s’attendre à ce qu’il atteigne des performances similaires ou supérieures à celles d’un modèle d’IA entraîné, selon les critères de 2024, avec plus de 10^26 opérations ; cette évaluation se fait au moyen de benchmarks couramment utilisés pour quantifier les performances générales des modèles de fondation de pointe.
Il suffit d’avoir suivi un cours de base sur l’architecture CPU pour savoir que les opérations sur entiers et les opérations en virgule flottante ont des coûts de calcul très différents. Une partie pourrait utiliser cette formulation devant un tribunal pour abaisser fortement, a posteriori, le seuil d’application. Par exemple, elle pourrait soutenir qu’une opération en virgule flottante équivaut à 10 opérations sur entiers, et que la limite est donc de 10^26 opérations sur entiers ou 10^25 opérations en virgule flottante.
À force de vouloir anticiper de meilleurs algorithmes à partir des benchmarks d’aujourd’hui, on en arrive à un point où l’effort fourni n’a plus vraiment d’importance. Cela revient à tracer une ligne de référence sur les benchmarks actuels, qu’ils reflètent ou non les capacités réelles. Un petit modèle pourrait être entraîné pour obtenir volontairement de faibles scores sur ces benchmarks, tout en étant excellent sur les tâches qui les inquiètent, comme la fabrication d’armes nucléaires.
Il indique qu’avant de commencer l’entraînement d’un modèle concerné, le développeur peut déterminer si ce modèle obtiendra de moins bonnes performances sur tous les benchmarks ; on peut se demander comment il est censé connaître ses performances avant l’entraînement.
Dès qu’une limite supérieure exploitable existe, l’ingéniosité humaine tendra à se concentrer sur des solutions qui tiennent dans cette limite. Bien sûr, cela ne concerne que les États-Unis. La Chine, la Russie, la Corée du Nord, l’Iran, etc., pourront toujours poursuivre librement cette technologie.
Tout cet article donne l’impression d’avoir été écrit avec ChatGPT.
Par exemple, il n’évoque même pas le texte original du projet de loi et se contente d’aligner des affirmations vagues sur la valeur de l’open source.
Je ne vois pas ce que cela apporte au débat, ni même s’il y a là un argument qui fonctionne comme une réfutation.
J’aime l’idée de réglementer les domaines d’application, en particulier ceux qui présentent des risques élevés pour la sûreté et la sécurité publiques, plutôt que de réglementer le développement des modèles d’IA lui-même.
En encadrant l’usage de l’IA dans les secteurs à haut risque où le potentiel de préjudice est le plus important, comme la santé, la justice pénale ou les infrastructures critiques, on pourrait continuer à permettre les progrès de la technologie IA tout en garantissant une responsabilité pour les usages nuisibles. Je me demande s’il existe de bons arguments contre cette approche.