Un dirigeant qui envisage Claude Enterprise pour son organisation se retrouve vite face à une tension : les équipes juridique et sécurité veulent du zero data retention (ZDR) contractuel, et Anthropic doit malgré tout détecter les usages catastrophiques que sa Responsible Scaling Policy (RSP) impose de surveiller. Les Enterprise Frontier Safeguards (EFS), annoncés début septembre 2026 et déployés par phases à partir de l'automne, sont la réponse d'Anthropic à cette contradiction apparente. Ce texte détaille ce que le dispositif fait, ce qu'il ne fait pas, et les points à trancher avec votre DPO avant de signer.
Le problème que résolvent les Enterprise Frontier Safeguards
Un contrat Claude Enterprise avec ZDR promet qu'Anthropic ne conserve pas les prompts et les complétions au-delà du traitement. C'est ce que demande un secteur régulé (finance, santé, droit, industrie) pour signer. En parallèle, la Responsible Scaling Policy (RSP) d'Anthropic, son cadre général de gestion des risques frontier, engage l'éditeur à surveiller les usages catastrophiques les plus graves. Les Enterprise Frontier Safeguards ciblent une partie de ce périmètre : cyberattaques sophistiquées, vol d'identifiants à grande échelle et comportements autonomes déviants sur plusieurs sessions. Certains de ces schémas ne sont visibles qu'en corrélant des signaux dans la durée et entre comptes. Or corréler dans la durée suppose de stocker, et stocker casse le ZDR.
Les EFS sortent de cette impasse en déplaçant le lieu du stockage. Les données d'activité (les traces techniques nécessaires à la détection) ne vont plus dans les systèmes d'Anthropic. Elles vont dans l'infrastructure cloud du client : AWS S3, Azure Blob Storage ou Google Cloud Storage, sous des clés de chiffrement et des politiques d'accès gérées par le client, avec journalisation d'audit. Anthropic lit ce trafic dans une fenêtre glissante pour y détecter des schémas de mésusage sérieux, sans qu'un salarié d'Anthropic ait à parcourir les conversations par défaut. C'est le principe présenté dans l'annonce officielle et repris par CNBC le 1er septembre 2026.
Le dispositif a été co-construit avec plus de 100 organisations clientes, dont l'Analysis and Resilience Center for Systemic Risk (qui rassemble les RSSI de Goldman Sachs, Morgan Stanley, Citi, Bank of America, Wells Fargo) et des groupes comme Comcast, KPMG, Mastercard, Salesforce, Stripe, Visa et Snowflake. Ce n'est pas un produit greenfield, c'est un compromis négocié avec des clients qui ne pouvaient pas signer autrement.
Ce que sont concrètement les EFS chez Anthropic
Les EFS ne sont pas un classifieur de safety généraliste. Ils ciblent les catégories de mésusage documentées par Anthropic pour ce dispositif précis : cyberattaques, vol d'identifiants à grande échelle, comportements de modèle qui sortent du périmètre attendu (autonomie déviante sur plusieurs sessions). Anthropic n'a pas publié de liste exhaustive et définitive des catégories couvertes : ne pas présumer qu'un autre type de risque frontier (armes CBRN par exemple) entre ou n'entre pas dans le périmètre sans le faire confirmer par écrit dans le DPA. Le trafic métier ordinaire (rédaction commerciale, analyse de contrat, code propriétaire, stratégie interne, données RH) n'entre pas dans la surface de détection. C'est le point à faire remonter en premier au comité sécurité : la question n'est pas «Anthropic voit-il tout», mais «quelles catégories précises sont regardées et sous quel seuil».
Un mot sur la portée. Les EFS sont annoncés à terme sur Claude Code, Claude Enterprise, la Claude Platform (API), Amazon Bedrock, la Claude Platform sur AWS, la plateforme d'agents de Google et Microsoft Foundry. Cela signifie que le dispositif suit le client, y compris quand il consomme Claude via l'API Anthropic directement plutôt que par l'interface Claude.ai. La tarification est présentée comme gratuite : Anthropic ne facture pas le service, le client paie seulement son fournisseur cloud pour le stockage et les opérations.
Comment les EFS cohabitent avec le zero data retention
C'est le point qui décidera de la validation par votre DPO. Le ZDR contractuel reste. Ce que change EFS, c'est le circuit de détection. Les données transitent dans le bucket du client, sous ses clés. La détection est automatisée. Les cas positifs (hits) sont ceux qui peuvent remonter à une revue humaine chez Anthropic, avec un périmètre restreint aux éléments corrélés au signal. Le reste des sessions n'est pas parcouru par un humain d'Anthropic, ni conservé chez lui.
Pour un DPO, cela déplace la question RGPD. On ne discute plus «Anthropic conserve-t-il nos données ?» mais trois questions plus fines :
- Quelles catégories de données sont écrites dans le bucket client (métadonnées, contenus, en clair ou hashés) ?
- Sur quelle fenêtre glissante Anthropic lit-il ce bucket, et selon quels contrôles d'accès côté client ?
- Que se passe-t-il quand un hit est déclenché : qui accède, où, sous quelle base légale, pendant combien de temps la trace est conservée après revue ?
Anthropic communique le principe (stockage chez le client, détection automatisée, revue humaine ciblée sur les hits) mais laisse aux discussions contractuelles bilatérales le détail des durées, des périmètres et des juridictions. Ce n'est pas une critique, c'est une réalité d'un produit déployé par phases : la clause exacte fera partie du DPA.
Ce que ça change pour un déploiement Claude Enterprise en entreprise francophone
Trois angles concrets pour un dirigeant qui doit arbitrer.
Argumentaire pour le DPO et le comité sécurité. Le ZDR contractuel n'est pas dilué par EFS. La donnée métier ordinaire ne sort pas du périmètre client : elle est stockée dans votre propre cloud, sous vos clés. La détection ne cible que des schémas frontier. Les hits déclenchent une revue par Anthropic dans un cadre défini au contrat. Le dispositif a été co-construit avec les RSSI de plusieurs grandes banques américaines (Goldman Sachs, Morgan Stanley, Citi, Bank of America, Wells Fargo) via l'Analysis and Resilience Center for Systemic Risk : c'est un point de comparaison utile à faire valoir devant un comité risque européen, sans en faire une certification ou une garantie de conformité RGPD automatique.
Cas de l'API directe. Si vos équipes construisent des agents en tapant l'API Anthropic (par exemple pour connecter Claude à vos systèmes via un serveur MCP interne), EFS suit le client sur la Claude Platform. Le périmètre d'exposition n'est pas identique à Claude Enterprise en interface, notamment sur les traces techniques capturées. À faire préciser au commercial Anthropic avant signature.
Questions à poser à Anthropic avant signature. Quatre questions minimales : juridiction de la revue humaine et statut des transferts hors UE ; durée exacte de conservation d'un hit après clôture ; droit d'audit du client sur le processus de revue ; procédure d'escalade en cas de faux positif qui bloquerait un usage légitime (recherche pharma, red team cyber interne).
Pour les équipes qui construisent des agents autonomes sur Claude, ajoutez une cinquième question : comment EFS interagit-il avec des sessions Claude Code longues, multi-agents et pilotées via MCP ? La recherche récente sur les interactions multi-agents montre que les schémas de comportement émergent sur la durée, ce qui recoupe exactement le type de signal qu'EFS surveille.
Les limites à connaître avant de signer
Un dispositif utile n'est pas un dispositif parfait. Cinq points à intégrer dans l'analyse.
| Limite | Ce que ça implique | Décision à prendre |
|---|---|---|
| Faux positifs | Cas edge légitimes (biotech, red team, veille cyber) qui déclenchent une revue | Prévoir une clause d'escalade contractuelle |
| Seuils opaques | Le client ne règle pas la sensibilité de détection | Documenter le fait au registre des traitements |
| Juridiction | Revue humaine sous droit US | Analyse de transfert hors UE avec le DPO |
| Périmètre évolutif | La RSP évolue, ce qui est surveillé aussi | Clause de notification des changements |
| Déploiement par phases | Pas de disponibilité générale à l'annonce | Suivre le calendrier plateforme par plateforme |
La question qui reste ouverte est celle du point de bascule. À quel moment un cas d'usage devient-il trop sensible pour un déploiement Claude Enterprise standard, même avec EFS ? Les alternatives existent : consommation via Amazon Bedrock ou la Claude Platform sur AWS avec une isolation renforcée, ou usage restreint à des sous-populations d'utilisateurs internes. Ce n'est pas une décision à prendre sur une fiche produit, c'est un arbitrage entre le coût de friction interne et la sensibilité réelle des cas d'usage. Pour la partie configuration et gouvernance côté abonnements, la logique est la même à plus petite échelle.
Checklist opérationnelle avant activation
Une séquence de six étapes pour préparer la décision.
- Cartographier les cas d'usage sensibles. Lister les équipes qui manipuleront des données personnelles, des données patients, du code sous NDA, des dossiers M&A. Marquer celles qui pourraient tomber sur un faux positif frontier (recherche bio, sécurité offensive interne).
- Valider la clause EFS dans le DPA. Demander à Anthropic la version applicable à votre contrat, la faire relire par le juridique avec les quatre questions ci-dessus.
- Configurer le bucket de stockage. AWS S3, Azure Blob ou GCS selon votre cloud existant. Clés de chiffrement gérées par le client (CMK), politiques d'accès restrictives, journalisation d'audit activée. À traiter comme un actif de sécurité critique.
- Briefer les équipes. Expliquer ce qui déclenche une revue et ce qui ne la déclenche pas. Éviter les rumeurs internes du type «tout ce qu'on tape est lu par Anthropic» qui tueront l'adoption.
- Prévoir le canal d'escalade. Contact commercial Anthropic identifié, procédure interne pour signaler un blocage bloquant, délai de réponse attendu.
- Documenter dans le registre des traitements. Base légale, catégories de données, destinataire (Anthropic pour les hits), durée de conservation, transferts hors UE, mesures de sécurité.
EFS ne change pas radicalement l'analyse de risque d'un déploiement Claude Enterprise, mais il déplace le curseur : moins d'opacité sur la détection de mésusage, plus de responsabilité côté client pour la sécurité du bucket qui héberge les traces. C'est un compromis qui devrait rendre plus faciles les validations dans les secteurs régulés, à condition de traiter le sujet comme un dossier de gouvernance IA à part entière, pas comme un simple onglet dans le contrat. Si votre trajectoire va vers des agents autonomes en production qui appellent des systèmes internes via MCP, le sujet devient d'autant plus structurant : la détection de mésusage sur des chaînes d'agents multi-tours est précisément le cas d'usage pour lequel EFS a été pensé.