Les promesses de sécurité d’Amazon et Google se heurtent à une évaluation secrète de l’IA par la Maison-Blanche

Les engagements de sécurité d’Amazon et Google côtoient désormais un processus d’évaluation de la Maison-Blanche dont les règles les plus importantes restent soustraites à l’examen public. L’administration affirme que ce cadre volontaire renforcera la sécurité nationale. Ses détracteurs y voient une contradiction fondamentale : les autorités demandent aux entreprises de faire confiance aux tests du gouvernement, tout en donnant aux chercheurs et au public peu de raisons de faire confiance à ces tests.

Le cadre permettrait aux évaluateurs fédéraux d’examiner certains modèles de pointe pendant une période pouvant aller jusqu’à 30 jours avant leur lancement. Un modèle de pointe est un système généraliste avancé dont les capacités pourraient créer de graves risques pour la sécurité nationale. Pourtant, les règles rapportées couvrent les modèles fermés et excluent les systèmes à poids ouverts, dont les paramètres téléchargeables peuvent être modifiés et redistribués.

Cette distinction transforme un plan d’évaluation technique en conflit de politique publique. Google, OpenAI, Anthropic, Meta, Microsoft, Nvidia et de plus petits développeurs auraient participé à une réunion d’information de la Maison-Blanche le 4 août. Amazon n’était pas cité dans plusieurs récits de cette réunion, mais sa position dans le cloud et ses précédents engagements de sécurité le placent au cœur du débat plus large.

Le véritable affrontement n’oppose pas Amazon à Google. Il oppose une évaluation gouvernementale confidentielle à la responsabilité publique. Les deux entreprises ont publié leurs propres approches en matière de sécurité, mais aucune ne peut répondre seule à la question centrale de politique publique : qui vérifie les évaluateurs lorsque la norme elle-même reste secrète ?

Le cadre instaure un contrôle privé avant le lancement

La Maison-Blanche a établi un contrôle potentiellement influent sans publier le règlement qui le sous-tend.

Le président Donald Trump a signé le 2 juin un décret invitant les principaux développeurs d’IA à soumettre certains systèmes avancés à une évaluation fédérale. Le décret décrivait la participation comme volontaire et autorisait le gouvernement à examiner les modèles pendant une période pouvant atteindre 30 jours avant leur lancement public.

L’administration a présenté le processus comme une mesure ciblée de sécurité nationale. Elle a indiqué que les autorités se concentreraient sur les systèmes dotés de capacités cybernétiques avancées, plutôt que d’examiner chaque modèle commercial. Le décret sur l’évaluation des modèles confiait également un rôle majeur au directeur de la National Security Agency.

La Maison-Blanche a indiqué avoir finalisé le cadre de mise en œuvre avant une échéance fixée en août. Des responsables ont ensuite présenté le dispositif à des représentants de plusieurs grandes entreprises d’IA. Toutefois, l’administration n’a pas publié le document ni pleinement identifié les organisations censées l’appliquer.

Selon des personnes au fait des réunions, le cadre définit un modèle de pointe concerné comme un système fermé présentant des capacités à l’état de l’art et des implications pour la sécurité nationale. Les développeurs fourniraient aux évaluateurs un accès peu avant le lancement, lorsque le modèle approche de sa forme finale.

Ce calendrier est important. Un modèle de recherche précoce peut changer considérablement avant son lancement, ce qui rend les résultats d’évaluation moins utiles. Un modèle presque achevé offre une cible de test plus réaliste, mais une suspension de 30 jours peut entrer en conflit avec les calendriers produits, les contrôles de sécurité et le secret concurrentiel.

Les employés pourraient être soumis à des restrictions d’accès pendant la période d’évaluation. Ces contrôles peuvent réduire le risque de fuite de capacités dangereuses ou de méthodes de test. Ils peuvent aussi compliquer la remédiation si les ingénieurs ne peuvent pas librement examiner un problème détecté par les évaluateurs gouvernementaux.

L’administration a une raison défendable de classer certains détails. Publier un référentiel cybernétique précis pourrait fournir aux attaquants une liste de contrôle leur permettant de découvrir quelles capacités suscitent l’inquiétude des autorités fédérales. Cela pourrait aussi aider les développeurs à optimiser les modèles pour un test sans réduire le danger sous-jacent.

Cet argument ne justifie pas de garder chaque règle privée. Les autorités pourraient divulguer les modalités de gouvernance, les critères de participation, les procédures de recours, les qualifications des évaluateurs et les seuils de risque généraux. Aucune de ces divulgations n’exige de révéler une instruction exploitable ou une cible classifiée.

Le cadre rapporté crée donc deux secrets distincts. Le premier concerne des méthodes de test sensibles, ce qui se justifie clairement au regard de la sécurité. Le second concerne la manière dont les décisions sont prises, ce qui soulève un problème de responsabilité plus difficile.

La Maison-Blanche affirme que ce processus fait progresser sa stratégie de cybersécurité et soutient le leadership américain dans l’IA. Cette affirmation reste difficile à évaluer, car les observateurs extérieurs ne peuvent pas comparer l’objectif déclaré à la norme réellement appliquée.

Il s’agit du changement central de cet événement. L’évaluation fédérale n’est plus seulement une proposition de politique publique. Elle dispose désormais, selon les informations rapportées, d’un processus, d’entreprises participantes, d’une période d’évaluation et d’une catégorie de modèles, même si le public ne peut pas examiner le cadre complet.

Pourquoi les politiques de sécurité d’Amazon et Google comptent ici

Les cadres de sécurité d’Amazon et Google montrent que les grandes entreprises acceptent déjà les tests de capacités, mais leurs politiques volontaires ne peuvent remplacer un processus public transparent.

Amazon et Google figuraient parmi les sept entreprises ayant pris des engagements volontaires en matière d’IA auprès de la Maison-Blanche en juillet 2023. Ces engagements comprenaient des tests de red teaming internes et externes, le partage d’informations, des investissements en cybersécurité et des méthodes permettant d’identifier les contenus générés par l’IA.

Le red teaming consiste à tester délibérément un système afin d’identifier des comportements nuisibles, des faiblesses de sécurité et des voies d’utilisation abusive. Cette démarche est utile, car les tests produits ordinaires passent souvent à côté des comportements adversariaux. Ses résultats dépendent néanmoins de l’accès des évaluateurs, de la qualité des tests et de la volonté du développeur de réagir.

Amazon a ensuite publié un cadre de sécurité pour les modèles de pointe décrivant la manière dont l’entreprise évaluerait les risques liés à des capacités graves. Son approche se concentre sur les capacités critiques susceptibles de permettre des dommages majeurs si elles étaient publiées sans garanties adaptées.

Google DeepMind a également développé un Frontier Safety Framework. L’entreprise utilise des seuils de capacités et des évaluations d’alerte précoce afin d’identifier les modèles nécessitant des contrôles de sécurité ou de déploiement renforcés. Le cadre de sécurité de Google a fait l’objet de plusieurs révisions publiques.

Ces politiques donnent aux deux entreprises une expérience opérationnelle pertinente pour l’initiative fédérale. Leurs chercheurs comprennent les tests avant déploiement, les contrôles d’accès, les seuils de capacités et la difficulté de transformer un résultat de benchmark préoccupant en décision de lancement.

Toutefois, les cadres des entreprises restent des outils d’autorégulation. Les développeurs choisissent nombre de leurs propres seuils, partenaires de test, pratiques de divulgation et réponses de mitigation. Les clients et les chercheurs indépendants ne peuvent pas supposer que ces choix sont comparables d’une entreprise à l’autre.

Une analyse universitaire des engagements antérieurs de la Maison-Blanche a relevé des éléments de preuve publics inégaux quant au respect de ces engagements. Les chercheurs ont signalé des résultats particulièrement faibles concernant la sécurité des poids des modèles, avec un score moyen de 17 % parmi les entreprises examinées. Ce constat ne prouve pas l’absence de garanties, car des mesures de sécurité non divulguées n’apparaîtraient pas dans une évaluation fondée sur la transparence.

Il met en évidence la limite de responsabilité des engagements volontaires. Une promesse peut sembler précise tout en empêchant les observateurs extérieurs de déterminer si le contrôle promis a fonctionné. L’évaluation des engagements soutient que les rapports publics restent incohérents d’un développeur à l’autre.

Le nouveau cadre de la Maison-Blanche pourrait améliorer cette situation en créant un canal d’évaluation commun. Les évaluateurs gouvernementaux peuvent comparer les systèmes dans des conditions plus cohérentes et examiner des capacités que les entreprises ne peuvent pas démontrer publiquement sans risque.

Le secret peut également reproduire le problème existant à un niveau supérieur. Au lieu de faire confiance au processus privé de chaque entreprise, le public est invité à faire confiance à un processus privé partagé par le gouvernement et certaines entreprises sélectionnées.

Le rôle d’Amazon est particulièrement important, car AWS fournit des infrastructures et un accès aux modèles sur l’ensemble du marché de l’IA. Amazon développe ses propres modèles tout en hébergeant, via ses services cloud, des systèmes d’autres fournisseurs. Une norme fédérale d’évaluation peut donc affecter ses produits, ses partenaires et ses clients professionnels.

Google occupe une position tout aussi stratifiée. L’entreprise développe les modèles Gemini, exploite Google Cloud, mène des recherches de pointe via DeepMind et fournit des systèmes d’IA aux entreprises comme aux institutions publiques. Une décision de classification d’un modèle peut influencer bien plus que le lancement d’un seul chatbot grand public.

C’est pourquoi le mot-clé amazon google renvoie à davantage que deux noms d’entreprises. Ces sociétés relient la recherche de pointe, la distribution cloud, les achats des entreprises et les technologies gouvernementales. Tout processus national d’évaluation finira par toucher ces relations, même lorsqu’une réunion précise rassemble une liste différente de participants.

Leurs cadres publiés offrent également un point de comparaison pratique. Les deux entreprises divulguent au moins certaines catégories de risques et certains concepts de gouvernance. Le gouvernement fédéral demande une confiance comparable tout en révélant moins de choses sur sa propre structure décisionnelle.

Ce déséquilibre deviendra plus difficile à défendre si une évaluation retarde un modèle, en approuve un autre ou impose des conditions d’accès différentes selon les développeurs. À ce stade, la transparence procédurale deviendra un enjeu de concurrence autant que de sécurité.

Le débat Amazon Google révèle le compromis entre transparence et sécurité

Une évaluation sûre exige des détails de test confidentiels, mais une évaluation crédible exige des règles, une autorité et une responsabilité visibles.

L’argument le plus solide de l’administration est simple. Les tests de cybersécurité perdent de leur valeur lorsque chaque instruction, environnement d’exploitation et seuil d’échec devient public. Des modèles avancés pourraient aider les utilisateurs à découvrir des vulnérabilités, écrire du code d’exploitation ou automatiser certaines étapes d’une intrusion.

Les évaluateurs ont besoin d’un accès contrôlé à des systèmes réalistes et à des cibles sensibles. Ils peuvent également avoir besoin de renseignements classifiés sur les menaces, qui ne peuvent pas être partagés avec les développeurs, les chercheurs externes ou le grand public.

Le gouvernement a donc des raisons légitimes de protéger le contenu des référentiels. Le problème commence lorsque le secret opérationnel s’étend au secret institutionnel.

Le public doit tout de même savoir qui est qualifié pour agir comme évaluateur, comment les conflits sont gérés et ce qui se passe après l’apparition d’une capacité grave. Les développeurs doivent comprendre si un résultat défavorable retarde le lancement, déclenche une remédiation ou produit simplement un avertissement.

Les petits laboratoires ont besoin d’une autre réponse. Ils doivent savoir si la participation offre un véritable avantage en matière de sécurité ou crée une barrière informelle favorisant les entreprises déjà établies dans les cercles de Washington.

Un processus peut être officiellement volontaire tout en devenant difficile à refuser sur le plan commercial. Les agences fédérales achètent des services cloud et des outils d’IA. Les régulateurs influencent les décisions de risque des entreprises. L’approbation gouvernementale peut aussi devenir un signal puissant pour les assureurs et les équipes chargées des achats en entreprise.

Un développeur qui refuse l’évaluation pourrait faire face aux questions de ses clients après la participation d’un concurrent. À l’inverse, une entreprise qui soumet un modèle pourrait obtenir une approbation implicite en matière de sécurité, même si le gouvernement n’a jamais eu l’intention d’en accorder une.

Tel est le danger d’un contrôle privé. Son autorité peut croître au gré des attentes du marché sans que le Congrès en définisse les limites juridiques. Une évaluation confidentielle peut commencer comme une collaboration et évoluer vers une approbation de facto.

Chris Lehane d’OpenAI a soutenu l’élaboration de cadres de sécurité efficaces reposant sur des institutions démocratiques, une expertise technique et une large participation des parties prenantes. Cette formulation met en évidence ce qui manque au processus secret : une institution publique peut protéger des éléments de preuve sensibles tout en expliquant sa gouvernance.

Les précédents programmes de cybersécurité offrent des exemples utiles. La divulgation coordonnée des vulnérabilités protège les détails des exploits tout en établissant des canaux de signalement, des délais de réponse et des attentes pour les fournisseurs concernés. Les programmes de menaces classifiées fonctionnent également sous contrôle statutaire sans publier chaque source de renseignement.

Diana Kelley, dirigeante du secteur de la sécurité interrogée après l’abandon d’une précédente version de l’initiative, a soutenu que la pérennité exige des tests indépendants, des seuils clairs et des conséquences significatives. Ses préoccupations restent pertinentes, car le cadre final rapporté n’a pas répondu publiquement à ces questions de gouvernance.

La comparaison entre Amazon et Google souligne le problème. Google peut divulguer des niveaux de capacité sans publier chaque prompt adversarial. Amazon peut expliquer ses protocoles d’escalade sans rendre publics des poids de modèles sensibles. Le gouvernement fédéral peut suivre la même séparation entre gouvernance publique et matériel de test protégé.

La transparence influe aussi sur la qualité technique. Des chercheurs externes identifient souvent des benchmarks défaillants, des jeux de tests contaminés et des hypothèses que les équipes internes n’ont pas repérées. Un processus d’évaluation entièrement fermé limite cette pression corrective.

Les responsables n’ont pas besoin de publier des exercices cyber en conditions réelles. Ils peuvent publier les principes de conception des benchmarks, les procédures de validation, les règles d’indépendance des évaluateurs et des conclusions anonymisées une fois les risques traités.

Ils pourraient également publier des rapports agrégés. Ces rapports pourraient indiquer combien de modèles ont été soumis à examen, combien ont nécessité des mesures d’atténuation et quelles catégories de risques sont apparues le plus souvent. L’agrégation préserverait la confidentialité des entreprises tout en montrant si le programme accomplit réellement son rôle.

Sans ces signaux, les observateurs ne peuvent pas distinguer un examen de sécurité exigeant d’une consultation privée. La différence importe, car une consultation informe les développeurs, tandis qu’un examen implique un jugement.

Le secret de la Maison-Blanche pourrait aussi affaiblir la participation des entreprises. Les développeurs protègent habituellement les systèmes non publiés, les méthodes de recherche et les calendriers produits. Ils doivent avoir l’assurance que l’accès du gouvernement n’exposera pas leur propriété intellectuelle ni ne divulguera des informations concurrentielles.

Des règles de traitement claires aideraient. Il en irait de même de limites publiées précisant qui peut accéder aux modèles soumis, combien de temps les artefacts sont conservés et si les conclusions peuvent influer sur des décisions distinctes de marchés publics ou d’application de la loi.

Le secret peut protéger un test. Un secret excessif peut compromettre la coopération qui rend ce test possible. C’est le compromis que l’administration n’a pas résolu publiquement.

L’exclusion des modèles ouverts laisse le risque le plus difficile hors du cadre

L’exemption rapportée pour les modèles à poids ouverts restreint le programme précisément là où le contrôle après publication est le plus faible.

Un modèle à poids ouverts rend ses paramètres entraînés disponibles au téléchargement. Ces poids peuvent être modifiés, affinés et exécutés sur des infrastructures échappant au contrôle du développeur d’origine. Cela diffère d’un projet open source dont les données d’entraînement, le code et le processus de développement peuvent également être publics.

Le cadre de la Maison-Blanche limiterait les modèles de pointe couverts aux systèmes fermés. Les modèles à poids ouverts éviteraient donc les mêmes tests fédéraux volontaires, même lorsqu’ils atteignent des capacités comparables.

Cette distinction soutient le programme d’innovation de l’administration. Les modèles ouverts aident les chercheurs à inspecter les systèmes, permettent aux entreprises de déployer l’IA sur leur propre infrastructure et réduisent la dépendance à un petit groupe de fournisseurs d’API.

Ils créent aussi des conditions de sécurité différentes. Un fournisseur fermé peut surveiller l’utilisation, mettre à jour les garde-fous, restreindre des comptes et corriger un modèle après sa publication. Ces contrôles sont imparfaits, mais restent disponibles.

Une publication à poids ouverts est difficile à inverser. Une fois que les utilisateurs ont copié les poids, le développeur d’origine ne peut pas retirer de manière fiable chaque version ni imposer une nouvelle protection. Le rapport international sur la sécurité identifie cette irréversibilité comme un défi central de gouvernance.

Les partisans de l’exemption affirment que les modèles ouverts ne devraient pas hériter de règles conçues pour des systèmes commerciaux hébergés de manière centralisée. Un accès obligatoire avant publication pourrait décourager la recherche, consolider les grands acteurs en place et déplacer le développement hors des États-Unis.

Les critiques répondent que le mode de distribution n’efface pas le risque lié aux capacités. Un modèle qui facilite des opérations cyber avancées reste pertinent, que les utilisateurs y accèdent via une API ou téléchargent ses poids.

Les deux arguments ont du mérite, mais une exemption catégorielle absolue est une réponse brutale. Un examen fondé sur les capacités pourrait traiter différemment les modèles ouverts et fermés sans considérer une catégorie comme inoffensive.

Par exemple, les évaluateurs pourraient examiner un modèle ouvert avant sa publication tout en appliquant des contrôles adaptés à une distribution irréversible. L’atténuation pourrait mettre l’accent sur la sécurité des poids, une publication progressive, des exigences matérielles ou la suppression d’une capacité dangereuse.

Les systèmes fermés pourraient faire face à des mesures différentes. Les fournisseurs pourraient ajouter de la surveillance, des limites de débit, des contrôles de comptes ou des filtres côté serveur. Un même résultat de test n’exige pas la même atténuation selon le type de publication.

Le cadre rapporté semble au contraire faire de l’architecture et de la distribution des critères décisifs dès l’étape d’éligibilité. Cela risque d’inciter à décrire une publication comme ouverte tout en laissant sans réponse les questions difficiles concernant les seuils de capacité.

Cela complique également la concurrence. Meta a fortement promu les modèles ouverts, tandis qu’Anthropic a plaidé pour des contrôles plus stricts autour des systèmes les plus capables. Google soutient des publications ouvertes dans certaines familles de produits tout en gardant ses systèmes les plus avancés sous contrôle. Amazon distribue à la fois des modèles propriétaires et des modèles librement disponibles via AWS.

Ces stratégies mixtes rendent trompeuse une simple opposition entreprise contre entreprise. La division importante traverse les entreprises elles-mêmes et leurs gammes de produits.

Les activités cloud d’Amazon et Google illustrent le problème pratique. Les clients d’entreprise ne consomment pas les modèles selon une structure de publication uniforme. Ils comparent des API gérées, des poids téléchargeables, des systèmes affinés et des modèles tiers disponibles sur des places de marché cloud.

Un cadre qui examine un canal de distribution mais en ignore un autre peut produire des garanties incohérentes. Une équipe d’approvisionnement pourrait considérer la participation gouvernementale comme la preuve qu’un modèle fermé a reçu un examen plus approfondi, sans que cela signifie nécessairement qu’il présente moins de risques.

L’exemption influe également sur la concurrence internationale. Les modèles ouverts développés hors des États-Unis peuvent se diffuser rapidement et soutenir la recherche nationale dans des pays confrontés à un accès restreint aux puces ou services américains.

La Maison-Blanche semble considérer la large disponibilité des modèles ouverts comme un élément de la compétition stratégique avec la Chine. Les critiques y voient le risque inverse : un système avancé téléchargeable peut transférer des capacités au-delà de la portée des fournisseurs américains.

Il n’existe pas de solution politique simple. L’administration doit décider quel degré de diffusion irréversible elle acceptera en échange d’une plus grande innovation et d’une portée géopolitique accrue.

Le cadre actuel choisirait la portée en excluant les modèles ouverts. Comme les critères opérationnels restent secrets, le public ne peut pas déterminer si les responsables ont établi un plafond de capacité ou ont simplement laissé la catégorie hors du dispositif.

Cette incertitude est plus lourde de conséquences que n’importe quel benchmark individuel. Les systèmes les plus difficiles à contrôler après leur publication pourraient recevoir l’examen fédéral le moins visible avant leur publication.

Un examen volontaire peut tout de même remodeler le marché de l’IA

L’influence commerciale du cadre dépendra moins de son application formelle que des achats, de la réputation et de l’accès à l’expertise gouvernementale.

Un programme volontaire n’impose pas une exigence classique de licence. Les entreprises peuvent théoriquement lancer un modèle sans le soumettre, à condition qu’aucune autre loi n’empêche sa publication.

Les marchés préservent rarement cette distinction nette. Les acheteurs d’entreprise transforment les signaux techniques en exigences d’approvisionnement. Les assureurs demandent si les fournisseurs ont suivi des pratiques reconnues. Les conseils d’administration veulent des preuves qu’un prestataire a anticipé les risques de sécurité nationale et de cybersécurité.

La participation peut donc devenir un signe distinctif concurrentiel. Une entreprise pourrait dire à ses clients qu’elle a collaboré avec des évaluateurs fédéraux avant la publication, même si le gouvernement n’a jamais délivré d’approbation formelle.

Cette formulation exigerait une surveillance attentive. « Examiné » ne signifie pas « sûr », et une brève évaluation avant publication ne peut pas identifier toutes les voies d’usage abusif. L’administration devrait empêcher les développeurs de transformer leur participation en une approbation gouvernementale trompeuse.

La non-participation peut créer le problème inverse. Une startup peut ne pas disposer de l’équipe juridique, de l’environnement sécurisé ou des relations gouvernementales nécessaires pour naviguer dans le processus. Les clients pourraient interpréter son absence comme un échec en matière de sécurité plutôt que comme une contrainte de ressources.

Les grandes entreprises bénéficient d’avantages évidents dans ces conditions. Amazon, Google, Microsoft, Meta, OpenAI et Anthropic disposent déjà d’équipes de sécurité et de relations avec les agences fédérales. Elles peuvent fournir un accès contrôlé à des modèles non publiés plus facilement qu’un laboratoire plus petit.

Le processus d’examen pourrait néanmoins aider les startups si le gouvernement fournit une expertise de test gratuite et protège les informations propriétaires. Des ressources d’évaluation partagées réduiraient la nécessité pour chaque développeur de bâtir un programme interne coûteux.

Les règles non publiées rendent cet avantage incertain. Les petites entreprises doivent connaître les conditions d’éligibilité, les procédures de candidature, les prérequis techniques et les protections de traitement des données avant de pouvoir planifier leur participation.

Les fournisseurs cloud subiront une pression indirecte. AWS, Google Cloud et Microsoft Azure hébergent des modèles de plusieurs développeurs. Les clients pourraient leur demander d’indiquer si un modèle a fait l’objet d’un examen fédéral, quelle version a été testée et si un affinage ultérieur a modifié son profil de risque.

Le versionnage est particulièrement important. Un résultat de sécurité s’applique à une configuration de modèle, un ensemble d’outils et un environnement de déploiement précis. Connecter le même modèle à l’exécution de code ou à des bases de données sensibles peut modifier sa capacité effective.

Les entreprises devraient donc éviter de considérer le cadre comme un substitut à leurs propres contrôles. Elles ont toujours besoin de gestion des accès, de journalisation, de tests, de réponse aux incidents et de restrictions sur les données qu’un système d’IA peut récupérer.

Les travailleurs du savoir font face à un problème connexe. Un modèle peut réussir des tests cyber de pointe tout en restant inadapté aux documents confidentiels, aux dossiers réglementés ou aux décisions métier automatisées. L’examen de sécurité nationale et l’assurance d’entreprise répondent à des questions différentes.

Les équipes qui comparent des systèmes peuvent utiliser une base de connaissances IA structurée pour conserver les fiches de modèle, les résultats d’évaluation, les politiques et les dossiers d’incidents. Cette documentation devient plus précieuse lorsque les informations publiques sur l’examen fédéral restent limitées.

Les clients d’Amazon et Google devraient aussi surveiller les changements contractuels. Les accords cloud pourraient commencer à distinguer les modèles examinés des modèles non examinés, ou les systèmes gérés des poids téléchargeables. Les fournisseurs pourraient ajouter de nouvelles déclarations concernant la participation aux évaluations sans garantir un résultat.

Les autorités de concurrence devraient surveiller si un accès privilégié crée des avantages injustes. Un processus dominé par des laboratoires établis pourrait les aider à façonner des seuils correspondant à leur propre architecture, à leurs effectifs et à leurs pratiques de publication.

Les évaluateurs indépendants offrent un contrepoids partiel. Leur inclusion peut élargir l’expertise et réduire l’impression que le gouvernement et les principales entreprises s’évaluent mutuellement à huis clos.

L’indépendance exige davantage que le nom d’une nouvelle organisation. Les évaluateurs ont besoin d’un financement stable, d’un accès protégé, de règles claires sur les conflits d’intérêts et de la liberté de signaler des désaccords sérieux. Sinon, ils restent des prestataires dont l’accès dépend des entités qu’ils évaluent.

Le cadre peut devenir utile sans devenir obligatoire. Il peut établir un langage commun, soutenir des tests sensibles et identifier des menaces qu’aucune entreprise ne perçoit seule.

Il peut aussi se transformer en norme privée favorisant les acteurs établis. La publication des règles de gouvernance aiderait à déterminer la voie empruntée par le programme.

Trois signaux montreront si le cadre mérite la confiance

Le prochain test n’est pas une nouvelle déclaration de la Maison-Blanche. Il s’agit de savoir si le processus produit une participation cohérente, un examen crédible et une politique défendable pour les modèles ouverts.

Le premier signal serait un document public de gouvernance. L’administration devrait préciser qui dirige les examens, comment les modèles sont admissibles, comment les conflits sont traités et ce que les développeurs doivent faire après une constatation grave.

Cette divulgation n’a pas besoin de révéler des benchmarks classifiés. Si elle intervient, elle renforcerait l’argument selon lequel le secret se limite aux véritables détails de sécurité. Le silence persistant renforcerait les critiques selon lesquelles l’ensemble du processus décisionnel échappe à l’examen public.

Le deuxième signal serait constitué d’éléments issus des premiers examens achevés. Les responsables devraient communiquer des résultats agrégés, notamment le nombre de systèmes entrés dans le processus et la fréquence à laquelle les évaluateurs ont demandé des mesures d’atténuation.

Un rapport spécifique à un modèle pourrait être impossible avant son lancement. Un résumé anonymisé pourrait néanmoins démontrer que le cadre modifie les décisions de mise sur le marché plutôt que de fournir des briefings privés aux grandes entreprises.

Les lecteurs devraient surveiller le langage employé par les développeurs. « A participé à l’examen » est une affirmation factuelle sur le processus. « Approuvé par le gouvernement » impliquerait une conclusion que le programme n’est peut-être pas conçu pour fournir.

Le troisième signal concerne le traitement des systèmes à poids ouverts par l’administration. Les responsables doivent expliquer si l’exemption est permanente, limitée par les capacités ou soumise à une filière d’évaluation distincte.

Une filière distincte renforcerait la logique fondée sur les risques du cadre. Elle reconnaîtrait que les systèmes ouverts et fermés nécessitent des mesures d’atténuation différentes, tout en rejetant l’hypothèse selon laquelle un mode de distribution ne requiert aucun examen.

Une exemption générale et permanente affaiblirait l’argument de sécurité nationale de l’administration. Elle laisserait des publications irréversibles en dehors du programme alors même que les responsables présentent les capacités cybernétiques avancées comme la raison de l’implication fédérale.

Amazon et Google contribueront à façonner ces trois signaux, par leur participation directe, leurs commentaires publics, leurs politiques cloud ou leurs propres divulgations en matière de sécurité. Leurs cadres existants donnent aux responsables des exemples de publication de principes de gouvernance tout en protégeant les tests sensibles.

Les autres entreprises comptent tout autant. Le soutien d’Anthropic à des garanties renforcées pour les modèles de pointe, la défense des modèles ouverts par Meta et l’appel d’OpenAI à une large participation des parties prenantes définissent les limites du débat politique autour du processus de la Maison-Blanche.

L’administration devrait éviter de présenter les désaccords comme la preuve qu’une partie s’oppose à la sécurité. Les développeurs divergent sur l’origine des risques, les contrôles efficaces et les effets de la réglementation sur la concurrence. Ce sont des différends de fond auxquels un cadre crédible doit faire face.

Les entreprises devraient suivre le processus sans attendre un label gouvernemental définitif. Elles peuvent demander aux fournisseurs quelle version du modèle a été évaluée, à quels accès les évaluateurs ont bénéficié et si le déploiement comprend des capacités absentes de la configuration testée.

Les équipes de sécurité devraient également demander une documentation sur les changements postérieurs à la publication. Un modèle connecté à des outils externes, à des fichiers locaux ou à des systèmes privilégiés nécessite de nouveaux tests, même si sa version de base a fait l’objet d’un examen fédéral.

Les travailleurs du savoir peuvent appliquer la même discipline à plus petite échelle. Consignez quel modèle a traité une tâche, quelles informations il a consultées et quelles affirmations nécessitent une vérification humaine. Une base de connaissances consultable aide à conserver ces décisions associées aux éléments qui les étayent.

L’histoire Amazon Google ne porte donc pas sur la question de savoir si deux entreprises technologiques soutiennent la sécurité. Toutes deux ont déjà pris des engagements publics et développé des cadres internes. La question non résolue est de savoir si Washington peut transformer une coopération privée en un processus que des observateurs externes peuvent évaluer.

Les tests confidentiels et la responsabilité démocratique ne sont pas incompatibles. Le gouvernement peut protéger les exploits, les renseignements classifiés et les détails de modèles non publiés tout en rendant publics son autorité, ses procédures et ses résultats agrégés.

Tant que cette séparation n’apparaîtra pas, le cadre secret de la Maison-Blanche conservera deux identités concurrentes. Il constitue un canal potentiellement utile pour tester des capacités dangereuses, et une porte opaque exerçant une influence croissante sur les mises à disposition de modèles.

Les un à trois prochains mois devraient révéler quelle identité l’emporte. Surveillez la publication de règles de gouvernance, des résultats d’examen mesurables et une politique cohérente pour les modèles ouverts. Ces signaux montreront si les pratiques de sécurité d’Amazon et Google alimentent une norme nationale crédible ou entourent simplement un nouvel accord privé.