Surveiller le comportement de l’IA n’équivaut pas à le gouverner
Anthropic a fait une annonce majeure cette semaine. Claude Enterprise s’intègre désormais à 28 partenaires de sécurité et de conformité via la nouvelle Claude Compliance API, offrant aux équipes en charge de cybersécurité un accès programmatique au contenu des conversations, aux fichiers téléchargés et aux événements d’activité de l’IA — pour les intégrer dans les outils DLP, CASB, SIEM et eDiscovery déjà présents dans l’environnement de l’entreprise.
Le signal envoyé au marché est, en réalité, plus important que le produit lui-même. Si Anthropic développe une API de conformité, c’est parce que ses clients entreprises l’exigent. Selon l’étude KPMG 2025 AI Governance Survey, 62 % des entreprises considèrent le manque de fonctions de gouvernance comme le principal obstacle à l’extension de l’IA aux processus métiers sensibles. Les entreprises ne veulent plus déployer l’IA sur des workflows sensibles sans infrastructure de gouvernance. C’est une réaction saine. Mais la vraie question est de savoir si une infrastructure de gouvernance qui enregistre le comportement de l’IA a posteriori équivaut à une infrastructure qui contrôle l’accès à l’IA en amont.
Ce n’est pas le cas — et cette distinction est cruciale pour les secteurs réglementés.
5 points clés à retenir
1. L’API de conformité de Claude marque une avancée pour l’IA d’entreprise.
L’API Claude Compliance d’Anthropic s’intègre à 28 partenaires de sécurité — Cloudflare, CrowdStrike, Microsoft Purview, Varonis, Wiz, Relativity, Datadog, et 21 autres — offrant aux entreprises réglementées un accès programmatique aux journaux de conversations, fichiers téléchargés et événements d’activité de l’IA pour les intégrer à leurs outils DLP, CASB, SIEM et eDiscovery existants. Cette fonction n’existait pas auparavant sous une forme structurée et accessible via API. Le signal envoyé au marché est aussi important que le produit : les entreprises exigent une infrastructure de gouvernance de l’IA avant d’étendre son usage à des workflows sensibles.
2. Toutes les intégrations fonctionnent après la conversation.
Les 28 intégrations de l’API de conformité interviennent a posteriori, faisant de l’outil un système de surveillance et non de gouvernance. Il documente ce qui s’est passé — il ne peut empêcher ce qui n’aurait pas dû arriver. Les données ont été traitées. Le contenu a été envoyé au modèle. La conversation a eu lieu. L’API crée un enregistrement ; elle ne modifie pas le résultat. Pour les contenus réglementés, cette distinction n’est pas un détail. C’est la différence entre un contrôle de détection et un contrôle de prévention.
3. Les données sensibles atteignent le modèle avant tout signalement.
Un collaborateur utilisant Claude Enterprise avec l’API de conformité pleinement activée peut toujours coller des CUI, joindre des informations médicales protégées ou interroger des données soumises à l’ITAR dans une conversation. L’API enregistre l’activité mais ne la bloque pas. Une couche de gouvernance pré-modèle bloque le contenu avant qu’il n’entre dans la session. La plupart des cadres réglementaires exigent des contrôles d’accès comme mesure principale — enregistrer que des données réglementées ont été consultées sans autorisation ne remplace pas la prévention de l’accès non autorisé.
4. Les lacunes de gouvernance concernent toute l’entreprise, pas seulement les fournisseurs.
63 % des organisations ne peuvent pas limiter l’utilisation de l’IA à des finalités précises, 60 % ne peuvent pas désactiver un système d’IA défaillant, et seulement 18 % disposent de politiques de gouvernance de l’IA pleinement intégrées selon les Prévisions 2026 de Kiteworks. L’annonce d’Anthropic confirme l’existence d’un réel manque sur le marché. Elle ne le comble pas. Il s’agit de lacunes de contrôle — et non de surveillance — qui ne sont pas corrigées par un journal d’audit plus sophistiqué.
5. Les contrôles pré-modèle définissent la nouvelle norme de gouvernance réglementaire.
Le CMMC Niveau 2 exige que les organisations « contrôlent l’accès aux CUI » — le contrôle d’accès est la notion clé, pas l’enregistrement des accès. Les garanties techniques de la HIPAA précisent que seules les personnes ou logiciels autorisés doivent pouvoir accéder aux données. La norme de conformité pour l’IA d’entreprise réglementée imposera des contrôles de contenu pré-modèle, et non une simple surveillance a posteriori. La question pour les RSSI est de savoir s’il faut anticiper cette norme dès maintenant ou la mettre en place dans l’urgence après une action réglementaire.
Vous pensez que votre organisation est sécurisée. Mais pouvez-vous le prouver ?
Pour en savoir plus :
La limite structurelle de la surveillance a posteriori
Voici la limite structurelle que l’API de conformité ne peut pas lever, par conception : chacune de ces 28 intégrations intervient après la conversation. Les données ont été traitées. Le contenu a été envoyé au modèle. La conversation a eu lieu. L’API de conformité crée un enregistrement de ce qui s’est passé — elle ne modifie pas ce qui s’est passé.
Prenons l’exemple de la gouvernance des données dans des architectures de sécurité d’entreprise matures. Un système DLP ne se contente pas d’enregistrer qu’un collaborateur a envoyé un document sensible sur une adresse personnelle — il empêche l’envoi. Un pare-feu de contenu ne fait pas que consigner les fichiers transférés — il applique la politique d’accès au moment du transfert. L’architecture qui a fait ses preuves pour la messagerie, le transfert de fichiers et les plateformes collaboratives repose sur un modèle « prévention d’abord, journalisation ensuite ». L’API de conformité applique à l’IA un modèle « journalisation d’abord, alerte ensuite ».
Cela reste utile. Mais c’est fondamentalement différent de la prévention. Pour les contenus réglementés — CUI, informations médicales protégées, données soumises à l’ITAR, informations couvertes par le secret professionnel — les cadres réglementaires n’autorisent pas un modèle basé uniquement sur la journalisation et l’alerte comme contrôle principal. Ils imposent des contrôles d’accès. Enregistrer que des données réglementées ont été consultées sans autorisation ne remplace pas la prévention de l’accès non autorisé.
Ce qui peut se produire avant que l’API de conformité ne le détecte
Un collaborateur utilisant Claude Enterprise avec l’API de conformité pleinement activée et configurée peut : coller le texte d’un document non classifié contrôlé dans une invite de conversation ; joindre un fichier contenant des informations médicales protégées comme contexte pour une tâche Claude ; saisir des spécifications techniques soumises à l’ITAR dans un message de chat ; interroger Claude sur le contenu d’un jeu de données financières sensible auquel il a accès dans un autre système.
Dans tous ces cas, l’API de conformité enregistrera l’activité. Si les bonnes règles DLP sont configurées en aval, une alerte sera générée. Ce qui ne se produira pas : le contenu ne sera pas bloqué avant d’atteindre Claude. La conversation ne sera pas empêchée. Les données ne seront pas stoppées à une frontière de contrôle d’accès avant d’entrer dans le modèle. L’API de conformité documente l’exposition ; elle ne la prévient pas.
Pour les équipes de sécurité des secteurs réglementés, cela compte car la plupart des cadres réglementaires exigent des contrôles préventifs, et non uniquement des contrôles de détection. Le CMMC Niveau 2 exige que les organisations « contrôlent l’accès aux CUI ». Les exigences techniques de la HIPAA précisent que seules les personnes ou logiciels autorisés doivent pouvoir accéder aux données. La norme attendue est le contrôle d’accès, pas la documentation des accès.
La couche de gouvernance pré-modèle : une architecture différente
Une couche de gouvernance pré-modèle fonctionne selon un principe fondamentalement différent : elle détermine quels contenus sont autorisés comme entrée d’une session IA avant même qu’elle ne commence, et non après coup. La logique de contrôle repose sur l’identité et le rôle de l’utilisateur, la classification du contenu demandé, le cas d’usage de l’IA et le cadre de conformité applicable. Lorsqu’un utilisateur initie une session IA, la couche de gouvernance évalue ces facteurs selon des règles explicites — et autorise, restreint ou bloque certains contenus avant leur entrée dans la session.
Le Kiteworks Secure MCP Server s’intercale entre les systèmes de données de l’entreprise et les modèles d’IA — y compris Claude — et applique la politique de gouvernance du contenu à l’interface. Le contenu sensible n’est accessible aux sessions IA que si le rôle de l’utilisateur, l’objectif de la session et la classification du contenu respectent toutes les exigences de la politique. Les journaux d’audit enregistrent non seulement les contenus consultés, mais aussi ceux demandés et bloqués. L’AI Data Gateway applique la même gouvernance aux pipelines RAG et aux workflows automatisés. Chaque requête est authentifiée, autorisée selon des contrôles d’accès basés sur les attributs, et consignée dans un journal d’audit infalsifiable — avec un chiffrement validé FIPS 140-3 pour sécuriser chaque flux de données.
Cette architecture permet aux entreprises réglementées d’ouvrir l’accès de l’IA à des workflows sensibles — achats de défense, opérations de santé, conseil financier — sans créer le risque de non-conformité que la surveillance a posteriori documente sans pouvoir le prévenir. Le Réseau de données privé Kiteworks étend cette gouvernance à la messagerie électronique, au partage de fichiers, au MFT, au SFTP, aux formulaires web et aux API, le tout sous un moteur de politique unique et un journal d’audit consolidé.
Ce que cela implique pour les déploiements d’IA d’entreprise réglementés
Pour les responsables sécurité et conformité qui évaluent des plateformes IA d’entreprise, la question à poser à chaque fournisseur est : « Que se passe-t-il si un collaborateur envoie un contenu restreint au modèle avant que votre couche de conformité ne le détecte ? »
Si la réponse est « nous l’enregistrons et générons une alerte », vous disposez d’un système de surveillance. C’est utile pour la recherche d’incidents, la réponse aux incidents et la documentation d’audit. Mais cela ne répond pas aux exigences de contrôle d’accès de la plupart des cadres réglementaires pour les données sensibles. Si la réponse est « nous l’empêchons », vous disposez d’un système de gouvernance. Cette distinction détermine si votre déploiement IA est conforme à vos obligations réglementaires ou simplement documenté comme non conforme après coup.
Les cadres de conformité évoluent toujours vers l’interprétation la plus protectrice. On l’a vu avec le stockage cloud, la gestion des terminaux mobiles et la messagerie sécurisée — à chaque fois, la norme de gouvernance a évolué vers la prévention et le contrôle d’accès, plutôt que la détection et la journalisation. L’IA suit la même trajectoire. Les organisations qui anticipent cette norme dès maintenant — en mettant en place une couche de gouvernance pré-modèle qui contrôle les contenus sensibles accessibles aux modèles IA — auront le moins de coûts d’adaptation lorsque la réglementation rattrapera la technologie.
Pour en savoir plus sur la gouvernance des workflows IA, réservez votre démo personnalisée dès aujourd’hui.
Foire aux questions
La surveillance de conformité IA crée un enregistrement de ce que les modèles IA ont fait. La gouvernance IA contrôle ce que les modèles IA sont autorisés à faire — quels contenus ils peuvent consulter, pour quels utilisateurs, dans quelles conditions et pour quels usages. L’API Claude Compliance est un outil de surveillance. Le Kiteworks Secure MCP Server et l’AI Data Gateway assurent la gouvernance : ils appliquent la politique d’accès avant que le contenu n’atteigne le modèle, empêchant l’accès non autorisé plutôt que de le documenter après coup.
Pour la plupart des types de données réglementées — CUI, informations médicales protégées, données techniques soumises à l’ITAR — non, pas seule. Le CMMC, la HIPAA et l’ITAR imposent un contrôle d’accès aux données sensibles. Une API de conformité qui enregistre que des informations médicales protégées ont été soumises à un modèle IA documente l’échec à répondre à cette exigence — elle ne la satisfait pas. La gouvernance pré-modèle apporte les contrôles d’accès préventifs nécessaires à la conformité.
Une couche de gouvernance pré-modèle s’intercale entre les systèmes de données de l’entreprise et les modèles IA, appliquant la politique d’accès au contenu avant le début d’une session IA. Elle évalue le rôle utilisateur, la classification du contenu demandé et l’objectif de la session selon des règles explicites — et autorise, restreint ou bloque le contenu avant qu’il n’entre dans la session. Le Kiteworks Secure MCP Server met en œuvre cette gouvernance pré-modèle via des contrôles d’accès basés sur les attributs et une journalisation d’audit infalsifiable à chaque opération.
Les sous-traitants de la défense gérant des CUI sous le CMMC, les organismes de santé traitant des informations médicales protégées sous HIPAA, les sociétés de services financiers soumises aux exigences de gouvernance des données de la SEC et de la FINRA, ainsi que les entreprises aérospatiales et de défense gérant des données techniques soumises à l’ITAR sont les plus exposés. Selon les Prévisions 2026 de Kiteworks, 90 % des organismes publics et 77 % des organismes de santé n’ont pas de passerelle centralisée pour les données IA — le point de contrôle qui comble cette faille.
Le Secure MCP Server s’intercale entre Claude et les systèmes de données de l’entreprise, appliquant la politique de gouvernance à l’interface. Lorsque Claude demande l’accès à un contenu sensible, le serveur évalue cette demande selon des règles explicites, autorise ou bloque en fonction de cette évaluation, et consigne le résultat dans un journal d’audit infalsifiable. Cette gouvernance pré-modèle complète la surveillance a posteriori de l’API de conformité — en offrant la couche de contrôle préventive qui transforme la documentation de conformité en application de la conformité.
Ressources complémentaires
- Article de blog
Stratégies Zero‑Trust pour une protection abordable de la vie privée en IA - Article de blog
Comment 77 % des organisations échouent à sécuriser les données IA - eBook
Fossé de gouvernance IA : pourquoi 91 % des petites entreprises jouent à la roulette russe avec la sécurité des données en 2025 - Article de blog
Il n’existe pas de « –dangerously-skip-permissions » pour vos données - Article de blog
Les régulateurs ne se contentent plus de demander si vous avez une politique IA. Ils veulent des preuves de son efficacité.