L’audition du conseil municipal de New York sur OpenAI place les laboratoires d’IA sous serment

OpenAI comparaîtra à une audition du conseil municipal de New York aux côtés de trois grands rivaux, sous serment, après que la plupart ont accepté de se présenter uniquement lorsque les élus ont menacé de les assigner à comparaître. La séance du 5 octobre réunira Anthropic, Google, Meta et OpenAI devant les 51 membres du conseil. L’ancien chercheur d’Anthropic Jacob Coxon devrait également témoigner après avoir averti publiquement qu’une IA avancée pourrait échapper au contrôle humain.

L’audition du conseil municipal de New York sur OpenAI n’est pas une simple table ronde supplémentaire sur les politiques publiques. Les membres du conseil examinent des propositions qui pourraient imposer une validation externe des modèles, récompenser les lanceurs d’alerte, établir une responsabilité pour les préjudices prévisibles et exiger un signalement rapide des incidents. Ces mesures transformeraient de vastes promesses de sécurité en obligations que les entreprises, les validateurs et les déployeurs pourraient devoir documenter.

Le conflit central oppose la responsabilité à la gouvernance volontaire. Les entreprises d’IA ont publié des cadres de sécurité et accepté des obligations de tests internes. Les élus new-yorkais veulent désormais des preuves indépendantes, des recours juridiques et des témoignages consignés au dossier. L’audition testera la capacité des principaux laboratoires à défendre leurs contrôles des risques lorsque les questions viendront d’élus plutôt que de leurs propres évaluateurs.

L’audition du conseil municipal de New York sur OpenAI vise plus large

L’audition fait passer la sécurité de l’IA des documents de politique interne des entreprises aux témoignages publics sous serment.

Le conseil municipal de New York a programmé son audition du Committee of the Whole à 11 heures le 5 octobre à City Hall. Un Committee of the Whole réunit l’ensemble du conseil au lieu de confier le sujet à une commission permanente.

Le conseil présente la séance comme un examen des risques posés par l’intelligence artificielle. Son ordre du jour de l’audition répertorie un point de contrôle et neuf propositions législatives. Ces propositions portent sur la validation des modèles, les lanceurs d’alerte, la confidentialité des chatbots, le signalement des incidents, la responsabilité, la planification d’urgence et les allégations publicitaires.

Meta s’est engagé à envoyer un représentant de haut niveau avant que le conseil ne menace d’engager une procédure contraignante. OpenAI et Google ont accepté de participer après l’avertissement d’assignation à comparaître. Anthropic a d’abord refusé, puis a confirmé sa présence peu avant l’échéance annoncée.

Le conseil affirme qu’il s’agira des premiers témoignages publics sous serment des quatre entreprises concernant les dangers de l’IA et les éventuelles réponses législatives. Cette description est importante. Elle émane du conseil, et l’audition n’a pas encore établi ce que chaque entreprise reconnaîtra, contestera ou consignera au dossier.

Les entreprises invitées ne devraient pas envoyer leurs directeurs généraux. Bloomberg a rapporté que des responsables des politiques publiques et de la sécurité représenteraient les laboratoires. Leur identité, leur autorité et leur volonté de répondre aux questions techniques détermineront la valeur de l’audition.

SpaceXAI est également devenu partie au différend après n’avoir pas répondu à l’invitation initiale du conseil. La présidente Julie Menin a émis une assignation à comparaître en vertu des pouvoirs d’enquête du conseil. Le conseil a déclaré qu’il pourrait demander l’exécution de cette mesure devant la Cour suprême de l’État de New York si l’entreprise ne s’y conformait pas.

Un article local publié ultérieurement a indiqué que SpaceXAI devrait participer. Cette éventuelle participation élargit la liste des entreprises, mais ne modifie pas la confrontation principale. Les élus veulent savoir si les développeurs d’IA de pointe peuvent démontrer que leurs garde-fous fonctionnent en dehors de démonstrations contrôlées.

Coxon apporte un type de témoignage différent. Selon les informations publiées sur son départ, il a auparavant mené des recherches sur le préentraînement chez OpenAI et Anthropic. Le préentraînement est le processus à grande échelle par lequel un modèle apprend des schémas à partir de vastes jeux de données avant d’être ensuite affiné.

Il a quitté Anthropic en septembre et accusé les principaux laboratoires de prendre des risques inacceptables. Selon un article sur son témoignage, Coxon a déclaré que les personnes construisant des systèmes avancés pensaient que l’IA pourrait tuer l’humanité avant la fin de la décennie.

Il s’agit d’une affirmation extraordinaire, et non d’une prévision établie. Reuters a également indiqué ne pas avoir pu vérifier indépendamment le reportage de Bloomberg concernant la comparution prévue de Coxon. Le conseil a cité séparément sa démission en expliquant pourquoi il avait organisé cette audition plus large.

Coxon devrait comparaître aux côtés de l’ancien chercheur de Google DeepMind Alex Turner et de Daniel Kokotajlo, ancien chercheur d’OpenAI qui dirige l’AI Futures Project. Leur présence pourrait rendre la séance plus antagoniste qu’une audition composée uniquement de témoins d’entreprises.

Les représentants des entreprises décriront probablement les évaluations, les contrôles de déploiement et les procédures d’incident. D’anciens employés pourraient contester la capacité de ces garde-fous à répondre aux systèmes que les laboratoires s’empressent de construire. Les membres du conseil pourront alors comparer les deux versions selon les mêmes règles publiques.

Cette comparaison constitue le changement immédiat. Les débats sur la sécurité de l’IA séparent souvent les assurances des entreprises des avertissements de leurs détracteurs. New York City les réunit dans une même salle tout en examinant des lois qui attachent des conséquences à une validation incomplète ou à des préjudices évitables.

New York veut des preuves avant le déploiement

La proposition la plus importante ferait de la validation indépendante une condition préalable à l’offre ou au déploiement de modèles d’IA visés dans la ville.

La proposition du conseil, inscrite à l’ordre du jour sous la référence T2026-2602, interdirait de commercialiser, vendre ou déployer un modèle d’IA à New York City sans validation par un tiers. Elle exigerait également une capacité technique permettant à un opérateur humain d’arrêter le modèle.

La validation par un tiers signifie qu’un évaluateur externe examine un système au lieu de s’appuyer uniquement sur l’évaluation du développeur. La proposition identifie les performances des tâches, les effets disparates, la confidentialité et la sécurité comme domaines pertinents. Elle demande également aux validateurs d’examiner si la capacité d’arrêt humain fonctionne.

Les validateurs devraient divulguer les intérêts liés au modèle. Ils indiqueraient également si le système a été validé ou est prêt à être déployé. New York City Cyber Command définirait les règles de mise en œuvre et les qualifications des validateurs.

Les sanctions créeraient des enjeux pour les deux parties à la relation d’évaluation. L’ordre du jour indique que les sanctions civiles pourraient atteindre 25 000 dollars, y compris une pénalité fixe de 25 000 dollars par cas d’offre ou de déploiement d’un modèle sans validation requise. Les validations falsifiées pourraient entraîner le même montant.

Les règles d’IA proposées vont au-delà de la validation. Une mesure permettrait aux personnes de déposer des plaintes concernant des violations liées à l’IA visées auprès du Department of Consumer and Worker Protection. Cette agence mènerait généralement une enquête, sauf si une plainte était frivole, fausse ou redondante.

Un plaignant pourrait recevoir 25 % des sommes recouvrées si la ville engageait l’affaire sur la base des faits allégués. Cette part pourrait atteindre 50 % si les autorités désignaient le plaignant pour signifier un avis de violation ou engager une action civile.

Ce mécanisme d’incitation cherche à résoudre un problème d’information. Les personnes extérieures savent rarement comment les évaluations internes ont été conçues, quels avertissements ont été remontés ou pourquoi un déploiement a eu lieu. Les employés et les sous-traitants ont souvent un meilleur accès, mais signaler des fautes peut menacer leur carrière.

Un autre projet de loi clarifierait les protections des lanceurs d’alerte pour les employés municipaux et les sous-traitants visés. Il protégerait les signalements concernant le développement ou l’utilisation de l’IA que les travailleurs estiment raisonnablement présenter un risque important et spécifique pour la sécurité publique.

L’ensemble traite également des incidents liés aux contrats municipaux. Les sous-traitants et les agences municipales devraient notifier Cyber Command dans les 24 heures suivant la découverte d’un incident de sécurité de l’IA à signaler. Cyber Command divulguerait ensuite publiquement l’événement signalé dans les 24 heures suivantes.

Cette exigence est plus limitée qu’une obligation générale de signalement pour chaque défaillance de modèle. Elle se concentre sur les contrats municipaux visés. Elle créerait néanmoins un registre visible que chercheurs, journalistes, fournisseurs et habitants pourraient comparer au fil du temps.

Un droit d’action privé viserait une autre lacune en matière d’application. En vertu de T2026-2600, une personne pourrait poursuivre une entreprise dont le modèle disponible commercialement a causé un préjudice par une utilisation malveillante ou inappropriée par un tiers. La demande exigerait un préjudice prévisible et des garde-fous insuffisants liés à cette mauvaise utilisation.

La prévisibilité sera contestée. Les développeurs ne peuvent empêcher chaque prompt malveillant ou chaque modification ultérieure. Pourtant, les entreprises ne peuvent pas non plus traiter un abus prévisible comme imprévisible simplement parce qu’une autre personne a fourni l’instruction finale.

La proposition place cette question devant les tribunaux au lieu de la laisser uniquement aux équipes de politiques internes des entreprises. Cela crée une pression pour conserver les résultats d’évaluation, les prévisions d’abus, les avertissements internes et les décisions de déploiement.

D’autres mesures réglementeraient les pratiques de données des chatbots et la publicité sur la sécurité. Les fournisseurs de chatbots devraient respecter des exigences de confidentialité, de sécurité, de transparence et d’accès des utilisateurs. Ils ne pourraient pas laisser entendre qu’un chatbot fournit des conseils équivalents à ceux d’un professionnel agréé.

La publicité pour un modèle d’IA devrait indiquer si un tiers l’a validé. Des affirmations de sécurité matériellement fausses ou trompeuses pourraient entraîner des sanctions allant jusqu’à 25 000 dollars.

Ces dispositions transforment le langage de la sécurité en quelque chose de plus proche d’une déclaration sur les caractéristiques du produit. Si un développeur présente un modèle comme sûr, la ville veut que cette affirmation soit liée à un processus d’évaluation identifiable.

L’ensemble demeure au stade de propositions législatives. L’audition du 5 octobre n’est pas un vote final, et les textes pourraient évoluer considérablement. L’action du conseil serait également suivie de questions de mise en œuvre, de contestations juridiques, de règles administratives ou de décisions du maire.

Cette incertitude ne doit pas masquer la direction prise. New York City passe d’une supervision restreinte des algorithmes à un examen plus large des modèles d’IA à usage général et des entreprises qui les fournissent.

La sécurité volontaire de l’IA face à des preuves contraignantes

Le différend central ne porte pas sur le fait que les entreprises testent leurs modèles, mais sur la question de savoir qui définit un test adéquat et qui peut vérifier le résultat.

OpenAI, Anthropic, Google et Meta réalisent tous des évaluations de modèles. Ils publient différentes combinaisons de fiches système, de rapports de sécurité, de politiques de mise à l’échelle responsable, d’articles de recherche et de restrictions de déploiement.

Ces documents fournissent des éléments utiles. Ils laissent également aux entreprises un contrôle étendu sur la conception des tests, le seuil de divulgation, le calendrier et la réponse à un résultat préoccupant.

La proposition new-yorkaise transférerait une partie de cette autorité à des validateurs indépendants et à des responsables municipaux. Ce changement explique pourquoi l’audition compte au-delà de New York. Il remet en question un modèle de gouvernance largement fondé sur des engagements volontaires et une transparence sélective.

Les tests menés par les entreprises peuvent avancer rapidement et utiliser un accès interne dont un évaluateur externe ne dispose pas. Les développeurs de modèles comprennent mieux que la plupart des régulateurs leurs systèmes, leur infrastructure et leurs plans de déploiement. Ils peuvent également effectuer des tests pendant le développement, avant qu’une publication publique ne crée une pression pour défendre le résultat.

L’examen externe offre un avantage différent. Il peut remettre en cause des hypothèses devenues normales au sein d’une entreprise. Il peut comparer les éléments de preuve entre fournisseurs et déterminer si une affirmation de sécurité repose sur des normes cohérentes.

Aucune des deux approches ne garantit une supervision fiable. Un validateur indépendant peut manquer d’accès au modèle, de compétences techniques ou de temps. Un test de conformité mal conçu peut récompenser la paperasse plutôt qu’une réduction réelle des risques.

L’exigence de prévention des conflits d’intérêts de la proposition reconnaît une faiblesse évidente. Un validateur rémunéré par un développeur peut subir des pressions pour approuver le système du client. La divulgation aide, mais elle ne supprime pas à elle seule la dépendance financière.

L’exigence d’un « kill switch » soulève une autre question difficile. Une capacité d’arrêt humain paraît simple, mais les produits d’IA sont déployés dans des services cloud, des applications, des agents et des infrastructures clientes.

Un fournisseur central peut désactiver l’accès à son modèle hébergé. Il ne peut pas nécessairement arrêter chaque sortie copiée, artefact exporté, intégration locale ou action en aval déjà déclenchée par un utilisateur.

La législation devra définir précisément le système qui est arrêté. Elle doit aussi distinguer un service désactivé d’un incident maîtrisé. Sans cela, les développeurs pourraient respecter un contrôle formel sans traiter les voies par lesquelles les préjudices surviennent.

Les performances sur les tâches dépendent également du contexte. Un modèle performant sur un benchmark peut échouer dans un hôpital, un processus de recrutement, un service juridique ou un agent logiciel autonome. La validation doit relier les capacités générales du modèle à son déploiement prévu.

New York a déjà rencontré ce problème dans la supervision du recrutement automatisé. La Local Law 144 interdit aux employeurs et agences de recrutement d’utiliser certains outils automatisés de décision en matière d’emploi sans audit récent des biais et sans avis obligatoires.

La ville a commencé à appliquer ce régime en juillet 2023. Ses règles d’audit du recrutement ont créé un précédent important, mais les propositions actuelles sont plus larges.

La Local Law 144 se concentre sur un usage précis dans l’emploi. T2026-2602, tel que résumé par le Conseil, s’applique aux modèles d’IA commercialisés, vendus ou déployés dans la ville. Cette formulation soulève des questions bien plus vastes sur le champ d’application, la compétence territoriale et la faisabilité technique.

Un outil limité a des utilisateurs, des décisions et des sorties identifiables. Un modèle à usage général peut prendre en charge le codage, l’analyse de documents, le service client, la recherche, le travail créatif et des actions autonomes. Le risque change avec chaque intégration.

L’audition devrait donc pousser les témoins à fournir des éléments précis. À quel accès au modèle un validateur aurait-il droit ? Quelles évaluations doivent avoir lieu avant le déploiement ? À quelle fréquence la validation doit-elle être renouvelée après une mise à jour du modèle ?

Les membres du Conseil devraient aussi demander qui assume la responsabilité lorsqu’un développeur fournit le modèle mais qu’une autre entreprise construit l’application. Une règle large pourrait viser les fournisseurs de modèles, les distributeurs, les déployeurs, ou les trois.

C’est là que responsabilité et innovation deviennent un véritable arbitrage. Des normes faibles laisseraient passer des affirmations peu fiables. Des normes vagues ou excessivement larges pourraient décourager des déploiements utiles sans améliorer la sécurité.

Les principaux laboratoires ont intérêt à défendre des règles techniquement éclairées et cohérentes à l’échelle nationale. Les élus municipaux ont intérêt à agir lorsque les normes fédérales semblent insuffisantes. L’audition inscrit ces priorités concurrentes dans le même dossier public.

Les alertes des lanceurs d’alerte exigent plus que des gros titres

L’avertissement de Coxon accroît l’enjeu politique, mais les élus ont encore besoin de preuves vérifiables concernant des systèmes, des décisions et des défaillances précis.

Les affirmations liées aux risques existentiels retiennent l’attention parce que le préjudice allégué est immense. Elles peuvent aussi éclipser des questions plus immédiates de confidentialité, de discrimination, de fraude, de cybersécurité et d’automatisation dangereuse.

Le paquet du Conseil tente d’aborder ces deux niveaux. La planification d’urgence et les exigences d’arrêt des modèles répondent aux défaillances graves. La confidentialité des chatbots, les obligations de divulgation publicitaire, les règles contractuelles et les recours privés traitent des préjudices que les habitants pourraient rencontrer plus rapidement.

Le témoignage de Coxon sera particulièrement utile s’il passe des affirmations de probabilité aux détails opérationnels. Les élus doivent comprendre quelles capacités le préoccupent, quels éléments ont fait évoluer son jugement et quelles protections il estime absentes des laboratoires actuels.

Ils devraient aussi distinguer les estimations personnelles du risque des constats documentés d’une entreprise. L’avertissement d’un ancien employé peut révéler un désaccord sérieux. Il n’établit pas indépendamment qu’une issue catastrophique se produira.

La même norme s’applique au témoignage des entreprises. Les déclarations sur une culture de sécurité ne prouvent pas qu’un modèle a réussi des tests adversariaux significatifs. Un cadre de mise à l’échelle responsable ne montre pas que les employés peuvent suspendre une sortie lorsque la pression commerciale augmente.

Le Conseil devrait demander à chaque entreprise comment une alerte interne grave remonte dans l’organisation. Qui peut retarder le déploiement ? Quel dirigeant peut annuler cette décision ? Quels documents subsistent après le désaccord ?

Les protections des lanceurs d’alerte comptent parce que les canaux de signalement formels peuvent échouer. Les employés peuvent craindre des représailles, la perte de futures opportunités de travail ou un conflit juridique autour d’informations confidentielles. Pourtant, les programmes d’incitation peuvent aussi attirer des plaintes faibles, redondantes ou stratégiques.

Le système de plainte proposé tente de filtrer les signalements frivoles, falsifiés et répétés. Son succès dépendra de l’expertise des agences et de leur capacité d’enquête. Les responsables doivent distinguer un jugement technique impopulaire d’une violation de la loi.

La récompense financière mérite une conception attentive. Un pourcentage des sanctions recouvrées peut encourager les initiés à signaler des informations que les régulateurs ne verraient pas autrement. Il peut aussi créer des litiges sur la personne ayant fourni en premier les faits décisifs.

Le Conseil doit définir les informations admissibles, les divulgations protégées, les règles de confidentialité et les procédures de traitement des éléments sensibles pour la sécurité. La divulgation publique ne peut pas devenir une voie de fuite de données personnelles, de poids de modèles ou de vulnérabilités exploitables.

Les entreprises ont également le droit de contester des allégations inexactes. Les garanties procédurales comptent lorsqu’une plainte peut déclencher des enquêtes, des sanctions, des litiges ou un préjudice de réputation publique.

Cela ne justifie pas le secret. Cela signifie que la ville a besoin d’un processus qui protège à la fois les lanceurs d’alerte crédibles et l’intégrité des preuves.

La question sceptique est de savoir si un gouvernement municipal peut administrer ce processus dans l’ensemble du secteur de l’IA de pointe. New York City dispose d’une expérience réglementaire, d’agences techniques, d’un pouvoir d’achat public et d’un vaste marché. Elle ne contrôle pas la politique nationale de recherche, les exportations de puces ni chaque déploiement hors de ses frontières.

Une réglementation large des modèles pourrait aussi susciter des différends de compétence. Un modèle cloud pourrait être entraîné ailleurs, hébergé dans un autre État, accessible par un intermédiaire et utilisé par un résident de New York. Chaque lien crée une théorie différente de l’autorité locale.

Ces difficultés ne rendent pas l’audition symbolique. Les villes achètent des technologies, réglementent les entreprises, protègent les consommateurs et fixent des conditions à l’activité locale. La taille de New York permet à ses règles d’influencer les pratiques des fournisseurs au-delà des limites de la ville.

Cependant, l’influence ne se confond pas avec la force exécutoire. Le Conseil doit montrer comment les agences détecteraient un modèle non validé, identifieraient l’entité responsable et distingueraient une mise à jour du modèle d’un nouveau déploiement.

Les entreprises devraient expliquer quelles preuves elles peuvent fournir sans exposer de détails de sécurité ni de secrets commerciaux. Les élus devraient expliquer comment les validateurs externes recevront un accès suffisant pour tester les affirmations importantes.

Si les deux parties restent au niveau de la catastrophe contre l’innovation, l’audition produira des extraits mémorables et peu de clarté opérationnelle. Si elles discutent de l’accès aux audits, des définitions d’incidents, de l’autorité et des preuves, la séance peut améliorer les projets de loi.

Cette distinction compte aussi pour les acheteurs d’entreprise. Les équipes d’approvisionnement font de plus en plus face à des affirmations sur la sécurité, la fiabilité et la conformité des modèles. Un cadre de validation crédible pourrait réduire les asymétries d’information.

Un cadre faible ajouterait un certificat supplémentaire sans aider les acheteurs à évaluer le risque. Les détails de l’accès, de la couverture des tests, de l’indépendance et des évaluations répétées déterminent le résultat que New York obtiendra.

La pression s’étend au-delà de quatre entreprises d’IA

Les règles proposées affecteraient non seulement les développeurs de modèles, mais aussi les validateurs, les prestataires, les déployeurs, les annonceurs et les organisations qui achètent des services d’IA.

OpenAI, Anthropic, Google et Meta reçoivent l’attention parce qu’ils développent des modèles importants. La législation décrite à l’ordre du jour atteint une chaîne d’organisations plus large.

Une entreprise proposant un modèle d’IA à New York pourrait avoir besoin d’une preuve de validation. Une entreprise qui déploie le modèle pourrait être soumise à des obligations distinctes. Un validateur pourrait devenir responsable d’une fausse certification.

Les prestataires de la ville devraient disposer de procédures de détection des incidents et de signalement rapide. Les agences devraient mettre en place des processus pour transmettre les incidents à Cyber Command. La ville devrait alors publier les informations assez rapidement pour respecter le calendrier proposé.

Les fournisseurs de chatbots destinés aux consommateurs devraient examiner leurs pratiques d’accès aux données, de confidentialité, de sécurité et de transparence. Les équipes marketing auraient besoin d’éléments étayant les affirmations de sécurité. Les équipes juridiques devraient évaluer les usages abusifs prévisibles.

Cette répartition des responsabilités compte parce que le risque lié à l’IA repose rarement sur une seule organisation. Un développeur de modèles crée la capacité sous-jacente. Une entreprise d’applications définit les flux de travail. Un client fournit les données et accorde l’accès aux systèmes.

Un agent autonome ajoute une couche supplémentaire. Un agent est un logiciel qui utilise un modèle pour planifier et agir, souvent au moyen d’outils externes. Son comportement dépend du modèle, des autorisations disponibles, des instructions et de l’application environnante.

Un modèle peut sembler maîtrisé dans une interface de chat, mais devenir dangereux lorsqu’il est connecté à des e-mails, des bases de données, des systèmes de paiement ou des dépôts logiciels. La validation doit donc examiner l’environnement de déploiement, et pas seulement le modèle de base.

La proposition du Conseil sur le signalement des incidents reconnaît cette réalité opérationnelle pour les contrats municipaux. Un événement à signaler peut commencer par une sortie de modèle, mais devenir dommageable en raison d’autorisations système ou d’une surveillance insuffisante.

Les organisations utilisant l’IA ne devraient pas attendre la législation définitive pour examiner ces voies. Elles peuvent identifier les modèles qui accèdent à des données sensibles, les outils susceptibles d’effectuer des actions externes et les personnes capables de révoquer les autorisations.

La documentation est au cœur de ce travail. Les équipes ont besoin de registres des versions de modèles, des résultats d’évaluation, des décisions relatives aux incidents et des modifications des protections. Sans ces registres, la responsabilité devient un débat fondé sur les souvenirs.

Les travailleurs du savoir ont également un intérêt direct. Les assistants d’IA touchent de plus en plus aux documents internes, aux notes de réunion, au code, à la recherche et aux informations clients. Les utilisateurs doivent savoir quelles données entrent dans un système et quels contrôles régissent leur récupération ou leur conservation.

Une base de connaissances IA bien entretenue peut aider les équipes à préserver le contexte et à retracer les décisions. Elle ne remplace pas la validation des modèles, les contrôles d’accès ni la réponse aux incidents.

Pour les développeurs, l’audition indique que les affirmations de sécurité exigeront de plus en plus des preuves matérielles. Déclarer qu’une application comporte des garde-fous ne satisfera pas un régulateur sceptique. Les équipes pourraient avoir besoin de cas de test, de journaux d’évaluation, de registres d’accès et de procédures de réponse.

Les acheteurs d’entreprise devraient surveiller si les entreprises acceptent une base commune pour les tests indépendants. Une base partagée pourrait simplifier les achats. Des normes divergentes pourraient laisser les acheteurs comparer des rapports incompatibles.

Les entreprises subissent également des pressions stratégiques différentes. OpenAI et Anthropic mettent l’accent sur le développement de modèles de pointe et la recherche sur la sécurité. Google intègre l’IA dans la recherche, le cloud, la productivité et les services destinés aux consommateurs.

Meta développe des modèles tout en exploitant de vastes plateformes sociales et des systèmes publicitaires. Ces différences de modèle économique influencent l’échelle du déploiement, les modalités d’accès et les éléments de preuve que chaque entreprise peut fournir.

L’audition ne devrait pas gommer ces différences pour les réduire à une seule réponse sectorielle. Elle devrait déterminer quelles obligations s’appliquent à tous les modèles économiques et lesquelles exigent des règles adaptées au contexte.

La précédente loi new-yorkaise sur le recrutement offre à la fois un précédent et un avertissement. Une obligation locale d’audit peut créer un marché pour l’examen externe. Elle peut aussi susciter des débats sur les définitions, la couverture et la question de savoir si les audits mesurent les préjudices qui préoccupent les personnes concernées.

Les nouvelles propositions seront confrontées à ces questions à une échelle plus vaste. Les modèles à usage général évoluent fréquemment et prennent en charge des usages que les développeurs ne peuvent pas pleinement anticiper. La validation doit rester pertinente après les mises à jour sans rendre chaque modification mineure juridiquement ingérable.

Le Conseil a présenté cet ensemble de mesures comme favorable à la fois à l’innovation et à la sécurité. Cet équilibre dépendra des définitions et de la mise en œuvre, et non du slogan.

Un périmètre clair pourrait récompenser les développeurs qui documentent déjà leurs contrôles. Un périmètre ambigu pourrait favoriser les grandes entreprises capables d’absorber les coûts de conformité, tandis que les plus petits fournisseurs se retireraient.

Cette possibilité mérite une attention particulière lors de l’audition. La responsabilité ne devrait pas devenir une barrière que seules les plus grandes entreprises peuvent se permettre de franchir. Les préoccupations liées à la concentration du marché ne devraient pas non plus servir d’excuse à des tests insuffisants.

Trois signaux montreront si l’audition compte

L’importance de l’audition se mesurera aux éléments de preuve qu’elle produira, aux modifications apportées aux projets de loi et aux normes que New York pourra réellement faire appliquer.

Le premier signal sera le témoignage lui-même. Observez si les représentants des entreprises répondent par des méthodes d’évaluation concrètes, des procédures d’escalade et des seuils de déploiement.

Les déclarations générales sur une IA responsable révéleront peu de choses. Des descriptions précises de l’accès indépendant, des conclusions des red teams, de la gestion des incidents et de l’autorité de mise en production constitueraient un dossier que des observateurs extérieurs pourraient évaluer.

Coxon et les autres anciens chercheurs sont soumis au même critère. Leur témoignage gagnera en force s’ils identifient des mécanismes, des défaillances de gouvernance ou des décisions que les législateurs peuvent examiner. Les seules prévisions catastrophistes n’indiqueront pas à la ville comment réglementer.

Le deuxième signal est le processus de révision législative. Le plan de témoignage des entreprises indique que le Conseil souhaite recueillir l’avis du secteur sur les solutions proposées. Des amendements substantiels montreraient que l’audition a modifié la compréhension des législateurs.

Surveillez la définition d’un modèle d’IA, le champ de la validation par des tiers et le sens donné au déploiement. Ces termes déterminent si les règles couvrent un groupe restreint de systèmes ou presque tous les services intégrant de l’IA.

Surveillez également la capacité d’arrêt proposée. Une disposition applicable devrait préciser qui la contrôle, ce qu’elle désactive, comment elle est testée et quels déploiements l’exigent.

L’incitation destinée aux lanceurs d’alerte nécessitera des règles détaillées concernant l’éligibilité et la confidentialité. Le droit d’action privé exigera un critère défendable de prévisibilité et de garanties raisonnables.

Le troisième signal est la voie de mise en œuvre. Cyber Command et le Department of Consumer and Worker Protection assumeraient des responsabilités majeures au titre des propositions.

Leurs effectifs, leur accès technique, leur pouvoir réglementaire et leurs procédures d’application compteront autant que le texte législatif. Une obligation sans capacité d’enquête laisserait la ville dépendante des déclarations des entreprises.

L’ordre du jour du Conseil inscrit toujours les nouvelles propositions comme des points préexaminés. Les procès-verbaux et les actions législatives n’étaient pas disponibles avant l’audition prévue. Les lecteurs devraient donc considérer cet ensemble comme un point de départ, et non comme une loi adoptée.

L’audition OpenAI du Conseil municipal de New York ne réussira que si elle réduit l’écart entre les promesses de sécurité et les contrôles vérifiables. Cela suppose de demander quels éléments de preuve existent, qui peut les examiner et ce qui se passe lorsqu’un avertissement est ignoré.

Les développeurs, les acheteurs en entreprise et les utilisateurs d’IA devraient suivre les témoignages en gardant ces questions à l’esprit. Les témoins dévoilent-ils des garanties vérifiables ? Les législateurs transforment-ils un langage général en obligations applicables ? Les agences reçoivent-elles l’autorité et l’expertise nécessaires pour les faire respecter ?

Les réponses montreront si New York construit un modèle crédible de responsabilité ou une nouvelle couche de formalités administratives de conformité. Suivez le compte rendu de l’audition, puis comparez chaque assurance publique aux éléments de preuve fournis sous serment.