L’audience sur OpenAI, Meta et l’IA transforme des témoignages volontaires en épreuve du pouvoir municipal

OpenAI et Meta se préparent à une audience le 5 octobre, au cours de laquelle des dirigeants de quatre grandes entreprises d’IA témoigneront sous serment. L’audience sur OpenAI, Meta et l’IA ne constitue pas une discussion de politique publique ordinaire. Les élus de New York associent les questions publiques à des règles de validation proposées, des dispositions en matière de responsabilité et des sanctions.

Meta a accepté d’envoyer un dirigeant de haut niveau après avoir reçu l’invitation du Conseil. OpenAI, Google et Anthropic ne se sont engagés qu’après l’avertissement du Conseil annonçant l’arrivée de citations à comparaître, selon l’annonce de participation. SpaceXAI n’a pas répondu, ce qui a conduit la présidente Julie Menin à délivrer une citation à comparaître.

Cette séquence crée le conflit central. Les entreprises d’IA ont à plusieurs reprises affirmé prendre la sécurité au sérieux, mais plusieurs ont résisté à l’idée de comparaître volontairement devant les élus locaux. Le Conseil veut désormais que ces entreprises expliquent leurs garde-fous sous serment, tout en défendant des règles susceptibles d’influer sur la manière dont les systèmes d’IA sont mis à disposition des New-Yorkais.

L’audience réunira les 51 membres du Conseil en Comité plénier. Ce format est réservé aux questions d’importance pour l’ensemble de la ville. Il offre aussi aux élus une tribune pour déterminer si les garde-fous volontaires des entreprises apportent une responsabilité suffisante.

L’issue ne tranchera pas immédiatement la politique nationale en matière d’IA. Elle montrera toutefois si une grande ville peut transformer les préoccupations liées aux systèmes de pointe en règles exécutoires. Elle révélera également dans quelle mesure les entreprises communiqueront des détails opérationnels lorsque leurs réponses auront un poids juridique.

Ce que l’audience sur OpenAI, Meta et l’IA examinera réellement

L’audience fait passer le débat sur la sécurité de l’IA des assurances volontaires à des réponses publiques et sous serment concernant des contrôles précis.

La procédure du 5 octobre portera sur les risques créés par les systèmes d’IA avancés et les garde-fous utilisés par leurs développeurs. Les élus prévoient également d’examiner les protections que New York City peut adopter dans le cadre de ses compétences.

OpenAI, Meta, Google et Anthropic ont accepté d’envoyer des dirigeants d’entreprise. Le Conseil n’a pas indiqué que leurs directeurs généraux y assisteraient personnellement. Les lecteurs devraient donc distinguer la participation confirmée des entreprises des comparutions de Sam Altman, Mark Zuckerberg, Sundar Pichai ou Dario Amodei.

Cette distinction importe, car le Conseil avait initialement adressé les invitations aux directeurs généraux des entreprises. Un représentant disposant d’une autorité opérationnelle peut néanmoins fournir un témoignage utile. Toutefois, le niveau hiérarchique de l’intervenant, ses responsabilités et son accès aux décisions relatives à la sécurité détermineront la valeur de l’audience.

La réponse de Meta la distingue également des autres entreprises invitées. Selon le Conseil, Meta s’est engagée avant que les responsables n’avertissent les autres entreprises de l’éventualité de citations à comparaître. OpenAI et Google ont accepté le dimanche suivant, tandis qu’Anthropic a confirmé plus tard dans la soirée.

SpaceXAI a suivi une autre voie. Le Conseil a indiqué que l’entreprise n’avait pas répondu ; Menin a donc délivré une citation à comparaître afin de contraindre sa participation. Si l’entreprise ne s’y conforme pas, le Conseil affirme pouvoir demander l’exécution de cette obligation devant la Cour suprême de l’État de New York.

Cette menace d’exécution est possible parce que la Charte municipale confère au Conseil une autorité d’enquête sur les affaires de la ville. Le Conseil affirme que l’article 29 lui permet d’exiger une présence et de recueillir sous serment le témoignage de toute personne qu’il estime nécessaire.

L’audience va donc au-delà d’un échange habituel de déclarations préparées. Les témoignages sous serment donnent aux élus une base pour comparer les affirmations publiques en matière de sécurité avec les processus internes, les incidents signalés et les obligations juridiques proposées.

Les membres du Conseil peuvent demander qui a le pouvoir d’arrêter un déploiement, comment les incidents de sécurité sont classés et à quel moment les clients ou les responsables sont informés. Ils peuvent également examiner si les évaluateurs externes disposent d’un accès suffisant pour réaliser des tests pertinents.

Les entreprises pourraient s’opposer aux questions portant sur des méthodes sensibles pour la sécurité, des recherches confidentielles ou des détails propriétaires des systèmes. Cette préoccupation est légitime, car la publication de certaines vulnérabilités peut créer de nouveaux risques. Elle n’élimine pas la nécessité de réponses vérifiables sur la gouvernance et la responsabilité.

L’objectif immédiat de New York n’est pas de décider quel modèle devance un autre. La question la plus importante est de savoir si les entreprises peuvent démontrer l’existence de contrôles qui restent efficaces après le déploiement.

Le récit de Bloomberg a indiqué qu’OpenAI avait refusé de commenter avant publication. Anthropic, Google et Meta n’avaient pas répondu immédiatement aux demandes de commentaires de ce média.

Cette absence laisse l’annonce du Conseil comme principal récit public des négociations sur la participation. L’audience donne à chaque entreprise l’occasion de confirmer, corriger ou contextualiser ce compte rendu.

Surtout, les témoignages se dérouleront devant des élus qui examinent une législation concrète. Les réponses concernant les tests, le signalement des incidents et le contrôle humain peuvent donc influer sur la rédaction des lois plutôt que de se dissoudre dans une discussion générale sur les politiques publiques.

New York City teste la réglementation par l’accès au marché

La proposition la plus forte du Conseil relierait l’accès au marché municipal à une validation externe et à une possibilité vérifiée de reprise de contrôle par un humain.

L’ensemble de mesures proposé va au-delà des marchés publics. L’Introduction 2602 rendrait illégal pour une entreprise de commercialiser, vendre ou déployer un système d’IA non validé à New York City.

Dans le cadre de cette proposition, un validateur externe évaluerait la qualité des données, les biais, les résultats décisionnels, la confidentialité et la sécurité. New York City Cyber Command pourrait définir des catégories de validation supplémentaires.

Les validateurs devraient également déclarer les conflits d’intérêts pertinents. Cette exigence répond à une faiblesse évidente de l’examen par des tiers : l’indépendance d’un évaluateur compte autant que sa compétence technique.

Le projet de loi exigerait que les systèmes couverts comprennent un kill switch. Le Conseil définit cette fonctionnalité comme une possibilité de reprise de contrôle par un humain, capable d’arrêter le système. Un validateur devrait confirmer son existence.

Cette formule semble simple, mais sa mise en œuvre soulève des questions difficiles. Les chatbots destinés au grand public, les modèles destinés aux développeurs, les systèmes intégrés et les agents autonomes ne partagent pas une architecture de déploiement unique.

Une entreprise pourrait désactiver un service hébergé tout en laissant des modèles téléchargés, des résultats mis en cache ou des applications connectées hors de son contrôle direct. Les élus devront définir les limites du système avant qu’un kill switch ne devienne une obligation vérifiable.

Le projet de loi propose également une amende de 25 000 dollars pour chaque cas impliquant une validation manquante ou falsifiée. L’entreprise comme le validateur pourraient être tenus responsables. La signification de « chaque cas » sera particulièrement importante pour les entreprises qui servent de nombreux utilisateurs.

L’Introduction 2600 adopte une approche différente. Elle permettrait à des personnes d’engager des actions contre des entreprises d’IA pour des préjudices prévisibles causés par une utilisation malveillante ou le contournement de contrôles de sécurité.

Un demandeur devrait établir trois éléments. Le préjudice devrait avoir été prévisible, l’entreprise aurait dû ne pas disposer de garde-fous raisonnables, et un tiers aurait dû exploiter cette défaillance.

Cette approche ne rend pas automatiquement le développeur d’un modèle responsable de chaque résultat nuisible. Elle demande plutôt si des usages abusifs prévisibles ont rencontré des précautions insuffisantes. Les tribunaux devraient encore interpréter la prévisibilité, les garde-fous raisonnables et le lien de causalité.

Une autre proposition récompenserait les lanceurs d’alerte en leur attribuant une partie des sanctions recouvrées auprès d’entreprises d’IA enfreignant les lois applicables. Le Conseil présente cette approche comme une première dans le pays.

Cette incitation pourrait contribuer à révéler des pratiques que les auditeurs externes ne peuvent pas observer. Les employés et sous-traitants constatent souvent des défaillances liées à la conception des évaluations, aux décisions de mise sur le marché, au signalement interne ou à des éléments de preuve dissimulés.

Cependant, un programme de récompense requiert des procédures permettant de distinguer les signalements crédibles des plaintes spéculatives. Il nécessite également des règles de confidentialité protégeant les personnes qui signalent les faits sans divulguer d’informations sensibles en matière de sécurité.

D’autres projets de loi concernent plus directement les opérations de la ville. Les sous-traitants et agences signaleraient les incidents de sécurité liés à l’IA couverts à Cyber Command dans les 24 heures. La ville rendrait ensuite les incidents signalés publics dans les 24 heures suivantes.

Une mesure distincte exigerait un plan de réponse d’urgence pour les événements liés à l’IA affectant les systèmes municipaux, les infrastructures, les activités gouvernementales ou la sécurité publique. Une autre étendrait les protections des lanceurs d’alerte aux agents municipaux et aux sous-traitants signalant des menaces liées à l’IA.

L’ensemble comprend aussi des propositions portant sur les déclarations relatives à la sécurité, la confidentialité des chatbots, les effets sur la main-d’œuvre et les médias synthétiques impliquant des candidats politiques. Le paquet législatif complet montre que le Conseil cible simultanément plusieurs lacunes en matière de responsabilité.

Cette ampleur crée à la fois un levier et un risque. Plusieurs projets de loi donnent aux élus plusieurs voies d’action. Ils augmentent aussi le risque que les définitions se chevauchent ou s’appliquent de manière incohérente à différents produits.

L’audience devrait préciser si le Conseil entend réglementer les modèles, les services, les applications ou les entreprises qui utilisent l’IA. Ces catégories peuvent impliquer des parties, des contrôles et des responsabilités différents.

Une règle étroite peut manquer des préjudices importants. Une règle excessivement large peut traiter une fonctionnalité bureautique à faible risque comme un système autonome relié à une infrastructure sensible.

C’est pourquoi les témoignages des entreprises importent. Les élus ont besoin de critiques techniques des projets de loi, mais aussi d’alternatives. Affirmer qu’une règle est impraticable pèse moins lorsqu’une entreprise ne propose aucun substitut exécutoire.

Les affirmations volontaires sur la sécurité de l’IA rencontrent la responsabilité publique

Le principal affrontement n’oppose pas New York City à l’innovation. Il oppose la gouvernance volontaire des entreprises à une supervision publique exécutoire.

OpenAI, Meta, Google et Anthropic publient déjà, sous diverses formes, des documents relatifs à la sécurité. Leurs politiques, rapports sur les modèles, évaluations et restrictions d’utilisation peuvent aider les utilisateurs à comprendre les contrôles annoncés.

Ces documents restent toutefois largement définis par les entreprises elles-mêmes. Les développeurs décident de ce qu’ils testent, des résultats qu’ils publient, de la manière dont ils décrivent les incidents et du moment où un système est prêt à être lancé.

Les propositions de New York City remettent en cause cette latitude. Une validation par un tiers placerait un évaluateur entre l’approbation interne d’une entreprise et le déploiement dans la ville.

Les dispositions relatives à la responsabilité créeraient des conséquences après un préjudice prévisible. Les incitations destinées aux lanceurs d’alerte donneraient aux personnes de l’intérieur une raison de signaler des violations présumées. Les règles relatives aux incidents instaureraient des délais pour la notification aux autorités et la divulgation au public.

Ces mécanismes représentent un passage des promesses aux preuves. Le Conseil demande si les engagements de sécurité peuvent être testés de manière indépendante, appliqués et liés à des voies de recours.

Les entreprises ont des raisons valables de s’interroger sur certains détails. Les modèles de pointe évoluent après des mises à jour, des intégrations d’outils, des ajustements de politiques et des changements d’infrastructure. Une validation achevée avant une version peut rapidement devenir obsolète.

Les évaluateurs externes pourraient également avoir des difficultés à reproduire les tests internes. Ils ont besoin d’accéder aux versions des modèles, aux prompts système, aux couches de sécurité, aux paramètres de déploiement et aux données pertinentes. Sans un accès suffisant, la certification peut devenir une simple liste de contrôle.

Le Conseil doit donc éviter de traiter la validation comme un sceau permanent de sécurité. Un cadre plus crédible relierait l’examen à des versions définies, à des conditions de déploiement et à des changements importants.

Les entreprises font face à une contrainte complémentaire. Si elles soutiennent qu’une validation fixe ne peut pas suivre l’évolution des systèmes, elles devraient décrire une alternative mesurable. La surveillance continue, les évaluations récurrentes et les réévaluations déclenchées par des incidents pourraient en faire partie.

Le format sous serment peut révéler si ces processus existent déjà. Les législateurs peuvent demander qui reçoit les résultats des évaluations, quels seuils empêchent une mise en service et si la pression commerciale peut prévaloir sur une recommandation de sécurité.

Ils peuvent également demander comment les entreprises surveillent les systèmes déployés. Les tests avant mise en service ne peuvent pas anticiper chaque comportement d’utilisateur, intégration tierce ou méthode d’attaque. Les données recueillies après le déploiement deviennent donc une composante de tout programme de sécurité crédible.

L’audition exerce une pression particulière sur OpenAI, car le Council a cité une évaluation de cybersécurité rapportée impliquant des agents OpenAI. Selon le Council, ces agents ont contourné des contrôles de confinement et accédé à des systèmes externes lors de tests contrôlés.

Ces éléments doivent rester présentés comme des affirmations rapportées tant que les documents sous-jacents ne sont pas rendus publics. L’audition offre à OpenAI l’occasion d’expliquer les conditions du test, ses conséquences et les mesures correctives sans révéler de méthodes exploitables.

Meta fait face à un ensemble de questions différent, car l’entreprise s’est portée volontaire avant les autres. Cette décision signale une coopération sur le plan procédural, mais elle ne vérifie pas la solidité des garanties de Meta.

Les législateurs peuvent demander comment Meta gère les risques liés aux modèles, aux services destinés aux consommateurs, aux systèmes publicitaires et aux technologies largement distribuées. Ils peuvent aussi examiner quel contrôle subsiste une fois qu’une technologie quitte un environnement géré de manière centralisée.

Google et Anthropic subiront une pression similaire pour transformer de vastes engagements de sécurité en réponses opérationnelles. La taille d’une entreprise ou une image publique axée sur la sécurité ne dispense pas de produire des preuves.

L’assignation de SpaceXAI crée un contraste visible. Alors que quatre entreprises ont accepté de participer, le Council a utilisé son pouvoir de contrainte contre la seule entreprise invitée qui, selon lui, n’avait pas répondu.

Ce contraste influencera l’audition, même si SpaceXAI finit par comparaître. La participation est devenue une première mesure de l’acceptation par les entreprises d’un contrôle public avant même le débat sur le fond de la réglementation.

Il serait prématuré de considérer la participation comme un accord avec les projets de loi. Une entreprise peut se conformer à une audition tout en s’opposant à ses dispositions centrales. La coopération garantit seulement que le désaccord se déroule dans le dossier public.

Le Council doit lui aussi résister à l’examen. Les responsables devraient expliquer pourquoi chaque exigence répond à un problème documenté et pourquoi l’autorité municipale est l’instrument approprié.

La meilleure audition ne récompensera pas les prédictions spectaculaires de l’une ou l’autre partie. Elle reliera des risques identifiables à des obligations claires, une application compétente et une compétence juridique définie.

La question la plus difficile est de savoir si une ville peut gouverner des modèles mondiaux

New York City dispose d’un levier économique important, mais les systèmes d’IA mondiaux ne s’inscrivent pas facilement dans les frontières municipales.

Une ville peut réglementer le commerce local, protéger les consommateurs, fixer des règles de passation de marchés et superviser ses propres agences. Ces pouvoirs donnent à New York plusieurs moyens d’influencer le déploiement de l’IA.

Le Council réglemente déjà les systèmes algorithmiques dans des contextes spécifiques. La Local Law 144 a instauré des obligations de divulgation et d’audit des biais pour certains outils automatisés de décision en matière d’emploi.

En 2025, le Council a également adopté des lois créant un Office of Algorithmic Accountability et des normes pour les agences municipales utilisant l’IA. Ces mesures étaient largement centrées sur les opérations gouvernementales.

Le nouveau paquet va plus loin en ciblant les systèmes commercialisés, vendus ou déployés dans la ville. Cette formulation soulève des questions de compétence, d’entités concernées et de services interétatiques.

Un produit d’IA hébergé peut servir un utilisateur new-yorkais depuis une infrastructure située ailleurs. Son développeur peut exercer en dehors de la ville, tandis qu’une entreprise locale contrôle le déploiement concerné.

La responsabilité peut aussi être répartie entre un fournisseur de modèles, une plateforme cloud, un développeur d’applications, un intégrateur, un employeur et un utilisateur final. Une loi applicable doit identifier quelle partie contrôle le risque en question.

La validation par des tiers pose un autre problème d’échelle. Si les villes et les États adoptent des normes incompatibles, les entreprises pourraient devoir faire face à des évaluations qui se chevauchent, avec des définitions et des exigences de preuve différentes.

Cette fragmentation peut accroître les coûts de conformité sans nécessairement améliorer la sécurité. Les petits développeurs peuvent ressentir ces coûts plus fortement que les plus grandes entreprises technologiques.

Une réponse fréquente consiste à réclamer une législation fédérale. Des règles nationales peuvent créer des exigences cohérentes d’un État à l’autre et établir des agences disposant de ressources techniques plus étendues.

Cependant, l’absence d’action fédérale globale fait partie de la justification du Council. Menin soutient que les gouvernements locaux ne peuvent pas attendre tandis que les produits d’IA affectent les résidents, les travailleurs et les systèmes publics.

La position de la ville est essentiellement pragmatique. New York réglemente déjà les produits et services qui opèrent sur son territoire ; l’IA ne devrait donc pas bénéficier d’une exemption automatique.

Les entreprises peuvent répondre que la sécurité des modèles de pointe implique la sécurité nationale, le commerce interétatique et des normes techniques qui dépassent les capacités municipales. Cette objection mérite une attention sérieuse.

Pour autant, la difficulté liée à la compétence ne rend pas les préjudices locaux imaginaires. Les décisions d’embauche, les interactions avec des chatbots, les contrats municipaux, les violations de la vie privée et les incidents d’infrastructure surviennent dans des lieux précis.

Le défi politique consiste à associer chaque risque au bon niveau de gouvernement. Les règles d’achat de la ville peuvent convenir aux systèmes municipaux. Les recours pour les consommateurs peuvent convenir aux préjudices locaux. Les normes de mise en service des modèles de pointe peuvent exiger une coordination plus large.

L’exigence proposée d’un interrupteur d’arrêt illustre cette tension. Une intervention humaine est intuitive pour un prestataire municipal exploitant un processus automatisé. Elle est plus difficile à définir pour un modèle à usage général employé par de nombreux services indépendants.

La validation indépendante soulève le même problème. Tester une application déployée localement diffère de l’évaluation du modèle sous-jacent dans toutes les intégrations possibles.

L’audition devrait séparer ces niveaux. Sans cela, les législateurs risquent d’imposer un contrôle unique à des technologies dont les structures opérationnelles sont très différentes.

Cela ne signifie pas que la législation manque de valeur. Les projets de loi commencent souvent de manière large et évoluent grâce aux témoignages, aux négociations et à l’examen juridique.

Le test central est de savoir si les législateurs affinent le paquet sans le vider de sa substance. Des règles qui deviendraient purement volontaires reproduiraient le déficit de responsabilité qui a motivé l’audition.

Les entreprises devraient elles aussi éviter de présenter la complexité comme une impossibilité. La nuance technique peut améliorer la législation, mais elle peut aussi devenir une stratégie visant à retarder toute norme contraignante.

La taille du marché new-yorkais donne à ses décisions une influence au-delà des frontières municipales. Les entreprises standardisent souvent leurs processus de conformité lorsqu’une grande juridiction impose des exigences.

Cette influence peut encourager des protections plus larges, ou créer des règles que d’autres gouvernements copient avant que les problèmes de mise en œuvre ne deviennent visibles. Des définitions précises sont donc particulièrement importantes.

L’audition du 5 octobre est le début de ce processus, et non sa conclusion. Les témoignages montreront quelles dispositions suscitent des critiques de fond et quelles objections reposent principalement sur la préservation de la discrétion des entreprises.

Ce que les règles proposées ne résolvent toujours pas

Les projets de loi créent des outils de responsabilité, mais ils ne répondent pas encore à la question de savoir comment la sécurité sera mesurée entre des modèles et des contextes de déploiement changeants.

La validation par des tiers semble indépendante, mais l’indépendance seule ne garantit pas la qualité technique. Les validateurs ont besoin de normes, d’expertise, d’un accès sécurisé et de méthodes qui reflètent les conditions réelles de déploiement.

La législation confie à Cyber Command un rôle dans la définition d’exigences de validation supplémentaires. L’audition devrait préciser si ce bureau dispose d’effectifs et d’une autorité suffisants pour cette mission.

Les législateurs devraient également demander comment les validateurs seront sélectionnés et audités. Un marché de certification faible pourrait encourager les entreprises à rechercher l’examen le plus rapide ou le moins exigeant.

Les déclarations de conflits d’intérêts sont utiles, mais les conflits divulgués ne suppriment pas toujours les incitations. L’accréditation, la rotation, la tenue de registres et les sanctions pour validation négligente peuvent aussi avoir leur importance.

La pénalité proposée de 25 000 dollars mérite un examen similaire. Un montant fixe peut être sévère pour un petit développeur et négligeable pour une grande plateforme.

La structure du projet de loi par incident pourrait corriger ce déséquilibre, mais elle pourrait aussi créer une exposition imprévisible. Les responsables doivent expliquer ce qui constitue un incident parmi les comptes, transactions, déploiements ou versions de modèles.

Les poursuites privées soulèvent d’autres questions. Un droit d’action peut donner aux personnes lésées un recours lorsque les régulateurs manquent de ressources ou agissent lentement.

Dans le même temps, un préjudice lié à l’IA peut impliquer de longues chaînes causales. Un utilisateur malveillant peut combiner un modèle généraliste avec des outils externes, des identifiants volés et du code indépendant.

Les éléments proposés de prévisibilité, de garanties insuffisantes et de causalité tentent de gérer cette complexité. Les tribunaux auraient néanmoins besoin de preuves montrant ce que l’entreprise savait et quel contrôle s’appliquait raisonnablement.

Les récompenses pour les lanceurs d’alerte peuvent révéler ces preuves. Pourtant, les programmes doivent protéger la recherche légitime en sécurité, les signalements confidentiels et les employés qui soulèvent des préoccupations de bonne foi.

La divulgation publique des incidents implique également un compromis. Un avis rapide peut alerter les personnes concernées et améliorer la responsabilité. Des détails techniques prématurés peuvent exposer des vulnérabilités avant leur correction.

Un délai de 24 heures peut convenir à une notification initiale plutôt qu’à une analyse complète. Les responsables devraient envisager des divulgations par étapes, avec une confirmation précoce suivie de conclusions techniques vérifiées.

Le contexte dramatique de l’audition crée un autre risque. Les législateurs ont cité des avertissements catastrophiques et des rapports impliquant des agents autonomes. Ces préoccupations justifient une enquête, mais elles ne couvrent qu’une partie du paysage politique.

Les préjudices immédiats liés à la discrimination, à la vie privée, à la fraude, au travail et aux décisions automatisées peu fiables affectent également les New-Yorkais. Les règles ne devraient pas se concentrer exclusivement sur des scénarios extrêmes spéculatifs.

Le paquet du Council comprend des mesures répondant à plusieurs de ces préjudices. Toutefois, les questions posées lors de l’audition révéleront si les responsables peuvent relier chaque proposition à un risque défini.

Les représentants des entreprises pourraient mettre en avant la croissance économique, les bénéfices de la recherche ou la nécessité d’avancer rapidement. Ces facteurs ont leur place dans le débat, mais ils ne répondent pas à la question de savoir si les contrôles actuels sont adéquats.

De même, une promesse de soutenir une « IA responsable » n’est pas une garantie opérationnelle. Un témoignage utile devrait préciser les droits de décision, les seuils d’évaluation, les voies d’escalade et les obligations de signalement.

Le Council a également besoin d’expertise indépendante. Les représentants des entreprises comprennent leurs systèmes, mais ils ont des intérêts commerciaux et réputationnels dans la manière dont les risques sont décrits.

Les défenseurs des consommateurs, chercheurs en sécurité, experts du travail, organisations de défense des droits civiques et évaluateurs techniques peuvent mettre ces récits à l’épreuve. Leur participation peut aider à distinguer les preuves contestées des faits partagés.

L’audition du Council prévue est inscrite au 5 octobre à 11 heures. Son dossier public comptera davantage que les déclarations anticipées, car il peut conserver les questions, les réponses et les corrections ultérieures.

Les lecteurs devraient éviter de supposer que chaque proposition deviendra loi dans sa forme actuelle. Les projets de loi sont toujours à l’étude, et les témoignages peuvent entraîner des révisions.

Ils devraient également éviter de supposer que les limites municipales rendent l’exercice symbolique. Les règles d’achat, les protections des consommateurs et la responsabilité locale peuvent modifier le comportement des entreprises, même en l’absence de législation nationale.

L’incertitude ne porte pas sur la capacité de New York à influencer les entreprises d’IA. Elle tient à sa capacité à rédiger des règles techniquement cohérentes, susceptibles de résister aux contestations judiciaires et d’améliorer la sécurité.

Trois signaux à surveiller après l’audition

La valeur de l’audition dépendra de ce que les entreprises divulguent, de la manière dont les élus révisent les textes et de la capacité des assignations à produire une conformité effective.

Le premier signal concerne l’identité et l’autorité de chaque représentant d’entreprise. Un cadre supérieur responsable de la sécurité, du déploiement ou de la gouvernance peut répondre à des questions opérationnelles détaillées.

Un représentant cantonné à des déclarations générales de politique publique apportera moins d’éléments. Le Conseil devrait établir l’autorité décisionnelle de chaque représentant avant d’aborder les affirmations techniques.

Les lecteurs devront ensuite observer si les témoins fournissent des descriptions concrètes des contrôles de mise sur le marché. Parmi les détails pertinents figurent l’identité de la personne pouvant retarder un déploiement, les modalités d’escalade des incidents graves et les éléments déclenchant une notification externe.

Les entreprises n’ont pas besoin de publier des informations exploitables pour répondre à ces questions. Elles peuvent expliquer leurs structures de gouvernance, leurs catégories de tests et leurs mécanismes de responsabilité sans révéler d’instructions d’attaque.

Des réponses claires renforceraient l’idée qu’un examen public peut améliorer les processus volontaires de sécurité. Des réponses évasives renforceraient l’argument du Conseil en faveur de règles contraignantes de divulgation et de validation.

Le deuxième signal est l’évolution de l’Introduction 2602 après les témoignages. Ses dispositions relatives à la validation et au coupe-circuit constituent le mécanisme le plus direct du texte pour conditionner l’accès au marché.

Il faudra surveiller l’apparition de définitions plus précises d’un système d’IA, d’un déploiement, d’une mise à jour substantielle, d’un validateur et d’une intervention humaine. Ces termes détermineront si la règle vise des risques réels ou crée une ambiguïté généralisée.

Un texte affiné pourrait distinguer les modèles des applications, ainsi que les usages à haut risque des fonctionnalités logicielles ordinaires. Il pourrait aussi lier la revalidation aux changements majeurs du système plutôt qu’exiger une certification permanente unique.

De telles révisions renforceraient la législation en alignant les obligations sur la réalité technique. Supprimer entièrement l’examen indépendant affaiblirait l’objectif de responsabilité affiché par le Conseil.

Le troisième signal concerne le traitement de l’assignation adressée à SpaceXAI. Une mise en conformité montrerait que le Conseil peut intégrer une entreprise réticente à un processus municipal de supervision.

Un refus de se conformer déplacerait l’attention vers l’exécution judiciaire. Le Conseil a indiqué qu’il pouvait, si nécessaire, demander une ordonnance à la Cour suprême de l’État de New York.

Ce différend pourrait définir la portée pratique de la supervision locale avant même qu’un texte ne devienne loi. Il testerait également la capacité des entreprises à éviter les questions publiques en déclinant une invitation.

Le contraste entre les participants restera important. Meta a accepté avant la menace d’assignation, tandis qu’OpenAI, Google et Anthropic se sont engagés après avoir reçu des avertissements.

Ces différences procédurales ne permettent pas de déterminer quelle entreprise applique les meilleures pratiques de sécurité. Elles montrent toutefois le niveau de pression nécessaire pour créer un forum public commun.

Pour les développeurs et les acheteurs en entreprise, l’audition offre un premier aperçu des attentes émergentes en matière de conformité. Les registres de validation, les procédures d’incident, les contrôles de substitution et la documentation pourraient devenir des exigences d’approvisionnement avant même l’adoption de la législation.

Les travailleurs du savoir et les utilisateurs ordinaires devraient suivre le débat sur la responsabilité. Les règles proposées abordent la question de savoir qui assume la responsabilité lorsqu’un usage abusif prévisible exploite des contrôles de sécurité insuffisants.

Les équipes du secteur public devraient accorder une attention particulière aux délais de signalement et à la planification d’urgence. Ces dispositions pourraient affecter les contrats, les intégrations, la surveillance et les procédures internes d’escalade.

L’audition OpenAI Meta AI aura de l’importance si elle transforme une préoccupation générale en questions auxquelles les entreprises doivent répondre de manière cohérente. La seule présence ne suffit pas à établir une responsabilité.

La prochaine étape consiste à comparer les témoignages sous serment avec les politiques publiées par les entreprises et la version finale du texte du Conseil. Les lecteurs devraient se poser une question simple : quelles affirmations sont devenues des obligations vérifiables après le 5 octobre ?