De quel document s'agit-il
Un rapport de 106 pages publié par Anthropic dans le cadre de la mise en œuvre de la troisième version de sa Responsible Scaling Policy (RSP). Il s'agit du premier document de ce type — l'entreprise s'engage à le mettre à jour tous les 3 à 6 mois. Contrairement à la « system card », publiée avec chaque modèle et décrivant les caractéristiques d'un seul modèle, ce rapport évalue l'activité de l'ensemble de l'organisation : non seulement les capacités des modèles, mais aussi les mesures de sécurité, la surveillance, les protections de déploiement et le risque résiduel global.
Le document examine quatre catégories de risques catastrophiques : la production d'armes chimiques ou biologiques inédites, la création de nouvelles armes CB, les possibilités de sabotage à haut risque et l'accélération automatisée des MTEP. Pour chaque scénario, un modèle de menace est présenté, les modèles concernés (principalement Claude Opus 4.6), une évaluation des capacités actuelles, les mesures appliquées et le verdict final sur le risque.
Conclusions : trois des quatre catégories sont évaluées comme présentant un risque « très faible », la catégorie des nouvelles armes CB est classée comme « faible, mais avec une incertitude significative ». La partie la plus transparente du document se trouve à la fin : un chapitre sur la dynamique d'accélération, qui reconnaît que même en présence d'un risque direct faible, l'entreprise peut indirectement accélérer les concurrents qui ne mettent pas en place de telles protections. Un appendice entièrement censuré (7.7) est également présent.
Similarité structurelle avec la logique réglementaire de l'UE
Le plus intéressant est que ce document, qui n'est pas réglementaire, reprend presque tous les éléments structurels des réglementations européennes en matière de cybersécurité et du numérique.
Seuils progressifs. Les niveaux ASL-2 / ASL-3 d'Anthropic fonctionnent exactement comme le statut de « fournisseurs tiers critiques de services ICT » (CTPP) de DORA, le seuil des émetteurs « significatifs » (ART/EMT) de MiCA, les classes de produits « importants » et « critiques » de l'annexe I du CRA ou encore les modèles GPAI à risque systémique de l'article 51 de l'AI Act. Partout la même logique : si vous franchissez un seuil de capacité ou d'échelle, vous vous voyez imposer un ensemble d'obligations plus strictes.
Tests basés sur des scénarios. La méthodologie des « modèles de menace » d'Anthropic est proche du test d'intrusion basé sur les menaces (TLPT / TIBER-EU) prévu à l'article 26 de DORA et de l'analyse des risques requise par le CRA tout au long du cycle de vie du produit. La différence réside dans le fait que le TLPT est réalisé par des testeurs externes indépendants selon un périmètre approuvé par l'autorité de supervision.
Environnement de contrôle interne. Le rapport décrit des mesures telles que l'examen manuel obligatoire du code avant son intégration dans les dépôts partagés, la sélection automatique d'au moins 10 % des requêtes Claude Code pour une surveillance par classificateur, le sandboxing, la limitation du débit de sortie pour protéger les poids des modèles, et un programme de prime aux bugs. Il s'agit essentiellement d'un cycle de développement sécurisé (SSDLC) et de contrôles de gestion des menaces internes, que le CRA qualifie de « exigences de gestion des vulnérabilités » et que l'ISO 27001 désigne sous le groupe de contrôles A.8.
Risque relatif et risque absolu. Ici, Anthropic propose ce que la réglementation n'offre pas : une évaluation distincte de la part de risque ajoutée par les systèmes spécifiques de l'entreprise, et de la part de risque qui émergerait si l'ensemble du secteur se comportait de la même manière. Le droit de l'UE évalue le sujet individuellement ; l'évaluation des risques systémiques du secteur est laissée aux autorités de supervision. Cette double perspective est méthodologiquement précieuse et mérite l'attention des praticiens de la GRC.
Où s'arrête la similarité : trois lacunes
Première lacune — absence de validation indépendante. Le rapport est une auto-évaluation. Seule une revue externe expérimentale METR est mentionnée, après laquelle quelques formulations concernant une enquête interne auprès des employés ont été ajustées. À titre de comparaison : le CRA exige pour les produits critiques une évaluation de conformité par un organisme tiers notifié ; DORA impose une revue indépendante du système de gestion des risques ICT par un tiers (IRT) et un audit interne ; MiCA exige une licence de l'autorité nationale compétente avant le début des activités. L'article 55 de l'AI Act impose aux fournisseurs de GPAI à risque systémique des tests adversariaux et la fourniture de documentation à l'AI Office, mais pas d'audit indépendant obligatoire.
Deuxième lacune — asymétrie dans la notification des incidents. Aucune surveillance externe n'est prévue pour les incidents de sabotage visant les utilisateurs externes — on se base sur des signalements volontaires. Dans un environnement réglementé, cela est impossible : DORA établit une notification échelonnée des incidents ICT importants (initiale, intermédiaire, finale) ; NIS2 impose un avertissement précoce sous 24 heures et un rapport sous 72 heures ; à partir du 11 septembre 2026, le CRA obligera les fabricants à notifier à l'ENISA et au CSIRT, dans un délai de 24 heures, toute vulnérabilité activement exploitée ; l'article 73 de l'AI Act impose la notification des incidents graves.
Troisième lacune — appendice censuré. La frontière de la transparence, où s'affrontent le secret commercial et l'intérêt public. Le droit de l'UE résout cette tension non pas par le secret, mais par un accès confidentiel des autorités de supervision.
Royaume-Uni
Le Royaume-Uni ne dispose pas de loi horizontale sur l'IA. À la place, il s'appuie sur un système de régulation sectorielle basé sur des principes (FCA, PRA, ICO, Ofcom), le régime de résilience opérationnelle de la FCA/PRA avec des services commerciaux importants et des tolérances d'impact, le régime des « parties tierces critiques » selon le FSMA 2023, ainsi que le rôle de l'AI Security Institute. Dans un tel système, un rapport de risques publié volontairement par un fournisseur prend une importance accrue — il comble en pratique un vide réglementaire. Cependant, il reste la seule source de preuves, ce qui n'est pas une situation durable du point de vue de la gestion des risques du secteur financier.
Lituanie
Trois angles pratiques.
Secteur financier. La Lituanie compte un nombre disproportionnellement élevé d'EPI et de MFI, ce qui rend le DORA plus sensible ici que dans de nombreux autres États membres. Si une telle institution utilise Claude ou tout autre modèle de base, le fournisseur est inscrit au registre des IRT tiers, et les exigences contractuelles de 28 à 30 articles s'appliquent — stratégies de sortie, droits d'audit, chaîne de sous-traitance, localisation des données. Le rapport de risques d'Anthropic est une preuve utile dans la documentation du fournisseur, mais il ne remplace ni les garanties contractuelles ni votre propre évaluation des risques.
Fournisseurs de services d'actifs crypto. Les CASP licenciés par la Banque de Lituanie au titre du MiCA relèvent également du champ d'application du DORA. L'utilisation de l'IA pour la surveillance des abus de marché ou de la lutte contre le blanchiment d'argent implique une double couche d'obligations : le MiCA exige des systèmes robustes et adaptés, le DORA impose la gestion des risques ICT, et l'AI Act impose la transparence selon l'article 50.
Calendrier de l'AI Act. Le 24 juillet 2026, le Digital Omnibus on AI (Règlement (UE) 2026/1744) a été publié au Journal officiel, entrant en vigueur le 27 juillet. Les obligations pour les systèmes à haut risque selon l'annexe III sont reportées au 2 décembre 2027, et celles de l'annexe I au 2 août 2028. Cependant, les exigences de transparence de l'article 50 s'appliquent à partir du 2 août 2026, et les obligations relatives aux GPAI (articles 51 à 55) sont en vigueur depuis août 2025 et n'ont pas été modifiées. Le report n'est pas une pause — les travaux d'inventaire et de classification ne seront pas simplifiés.
Que faire de ces informations
Conclusion pratique pour la fonction GRC : il est conseillé de traiter de tels rapports de risques fournisseurs comme une source de preuves, et non comme une garantie. Plus précisément — relier les affirmations du rapport à votre bibliothèque de contrôles (quelles contrôles il confirme effectivement et lesquelles il se contente de déclarer), enregistrer les trois lacunes mentionnées ci-dessus comme un risque résiduel dans le profil du fournisseur, et les compenser par contrat — droit d'audit, délais de notification des incidents, transparence de la sous-traitance.
Et une dernière remarque. Le rapport montre à quoi ressemble une évaluation mature des risques là où la réglementation n'existe pas encore : des modèles de menaces clairs, des limites de contrôles identifiées, une incertitude reconnue. Beaucoup d'entreprises réglementées soumises aux exigences obligatoires de DORA ou NIS2 ne disposent pas elles-mêmes d'un tel document sur leur propre activité.
Analyse basée sur le « Risk Report: February 2026 » d'Anthropic (édition du 8 juillet 2026).
