Kiteworks avertit que 80 % des organisations ont subi des incidents de sécurité ou liés à l’IA alors que la gouvernance accusait un retard

Kiteworks a fait son entrée dans Google News avec une affirmation frappante : 80 % des organisations ont connu un incident de sécurité ou lié à l’IA, tandis que leur niveau de préparation en matière de gouvernance restait extrêmement faible. Ce chiffre attire l’attention, mais le conflit plus profond se situe entre les politiques écrites et les contrôles qui fonctionnent lors d’une utilisation réelle de l’IA.

Le titre, publié par Cybersecurity Insiders, intervient au moment où les entreprises accordent aux systèmes d’IA l’accès à des documents privés, des applications métier et des flux de travail internes. Ces connexions amplifient les conséquences de permissions insuffisantes, de journaux incomplets et de mouvements de données inconnus.

Kiteworks a un intérêt commercial dans ce débat, puisqu’il commercialise des technologies de sécurité et de gouvernance des données privées. Ses conclusions méritent donc d’être examinées, et non acceptées automatiquement. Plusieurs chiffres complémentaires révèlent toutefois un problème de gouvernance qui dépasse le cadrage d’un seul fournisseur.

Ce que le rapport Kiteworks change réellement

Le rapport transforme la gouvernance de l’IA, d’un débat sur les politiques, en un problème de réponse aux incidents.

L’article Google News présente le chiffre de 80 % comme sa principale conclusion. Toutefois, le titre seul ne précise pas si ce pourcentage regroupe des violations confirmées, des événements suspects, des violations de politiques ou des défaillances propres à l’IA.

Cette distinction est importante. Une violation de données classique, un employé téléversant un texte confidentiel dans un chatbot non approuvé et un agent autonome effectuant une action involontaire sont des événements différents. Ils exigent des contrôles différents et entraînent des niveaux de préjudice différents.

Les lecteurs devraient donc considérer ce pourcentage comme le résultat d’une enquête rapporté par un fournisseur. Il ne mesure pas les violations vérifiées de manière indépendante dans l’ensemble de l’économie. Les documents Kiteworks accessibles au public étayent la préoccupation plus large concernant la gouvernance, mais ils ne rendent pas toutes les catégories d’incidents interchangeables.

Une précédente étude mondiale de Kiteworks a interrogé 461 organisations en Amérique du Nord, en Europe, en Asie-Pacifique et au Moyen-Orient. Les rapports sur cette étude indiquaient que seulement 17 % avaient entièrement mis en œuvre des cadres techniques de gouvernance de l’IA.

C’est le point de référence le plus utile. La gouvernance technique de l’IA désigne des contrôles applicables couvrant l’accès aux données, l’utilisation des modèles, la surveillance, la conservation et la gestion des incidents. Un document de politique dépourvu de ces contrôles ne peut empêcher un employé, une application ou un agent d’exposer des informations protégées.

La même étude associait une visibilité limitée à des résultats plus faibles. Selon un rapport indépendant, 46 % des organisations qui ignoraient le nombre de leurs tiers ne pouvaient pas non plus identifier leur fréquence de violation.

Parmi les organisations incertaines quant aux violations, 42 % l’étaient également quant aux délais de détection. Selon cette couverture, 48 % supplémentaires ne pouvaient pas chiffrer les coûts liés aux litiges.

Ces relations n’établissent pas qu’une mauvaise visibilité a causé chaque violation. Elles montrent toutefois que les organisations incapables de recenser leurs systèmes et partenaires peinent aussi à mesurer les conséquences.

L’analyse 2026 de Kiteworks sur le secteur technologique offre une autre perspective. Elle a interrogé 225 dirigeants de la sécurité, de l’informatique, de la conformité et des risques, dans 10 secteurs et huit régions. Trente-deux répondants représentaient des organisations technologiques, tandis que 97 % de l’ensemble des participants travaillaient dans des organisations comptant au moins 1 000 employés.

Cet échantillon est pertinent pour évaluer le risque dans les grandes entreprises, mais il ne représente pas toutes les entreprises. Le sous-ensemble technologique est particulièrement réduit. Les écarts en pourcentage parmi ces 32 réponses doivent être interprétés comme des tendances, non comme des estimations précises du secteur.

Même avec ces limites, le rapport identifie un problème cohérent. Les organisations ont investi dans des pratiques de gouvernance visibles, mais les contrôles fondamentaux restent incomplets.

C’est ce qui a changé. Les incidents de sécurité liés à l’IA ne sont plus des cas limites hypothétiques associés à de futurs systèmes autonomes. Les entreprises signalent des incidents alors que les capacités essentielles d’inventaire, de traçabilité et d’application des règles restent inachevées.

Pourquoi Google News met maintenant en avant le déficit de gouvernance

L’adoption de l’IA est passée de sessions de chat isolées à des systèmes capables de récupérer des données, d’appeler des outils et d’agir dans les processus métier.

Un chatbot qui répond à une question générale dispose d’un accès limité. Un agent d’IA relié aux e-mails, au stockage cloud, aux dossiers clients, au code source ou aux systèmes financiers opère sur une surface d’attaque bien plus vaste.

L’IA agentique désigne un logiciel capable de planifier et d’exécuter plusieurs actions pour atteindre un objectif. Son risque dépend moins de sa fluidité conversationnelle que de son identité, de ses autorisations, des outils disponibles et des données auxquelles il peut accéder.

Cela crée plusieurs voies menant à un incident. Un agent peut recevoir des privilèges excessifs, suivre des instructions malveillantes intégrées à un document, divulguer des informations récupérées ou déclencher une action en dehors de sa finalité prévue.

Les employés créent également une exposition par le biais de l’IA fantôme, c’est-à-dire des outils d’IA utilisés sans approbation ni surveillance formelles. Le risque augmente lorsque ces outils conservent les prompts, entraînent leurs modèles sur le contenu soumis ou se connectent à des comptes organisationnels.

Les programmes de sécurité traditionnels gèrent déjà les identités, les terminaux, les applications et le trafic réseau. L’IA ajoute une couche de raisonnement capable de combiner des informations et d’initier des actions à la vitesse des machines.

Cela ne rend pas chaque système d’IA imprévisible. Cela signifie toutefois qu’une approbation statique lors du déploiement ne peut remplacer une observation continue après le déploiement.

Le calendrier reflète également la pression réglementaire. L’AI Act de l’Union européenne est entré en vigueur en 2024, et ses obligations suivent un calendrier échelonné. Les exigences de gouvernance applicables aux modèles d’IA à usage général ont commencé à s’appliquer en août 2025.

Le calendrier de mise en œuvre de la Commission européenne montre que différentes dispositions et échéances transitoires s’appliquent à des moments différents. Les organisations doivent identifier quels systèmes, rôles de fournisseur et cas d’utilisation relèvent de chaque obligation.

Ce calendrier évolutif complique la planification de la conformité, mais il ne supprime pas le besoin d’un inventaire. Une entreprise ne peut pas classer un système d’IA, documenter ses risques ou appliquer les contrôles appropriés si personne ne sait qu’il existe.

La réglementation n’est qu’une source de pression parmi d’autres. Les clients demandent de plus en plus aux fournisseurs comment l’IA traite les informations confidentielles. Les assureurs, auditeurs, conseils d’administration et équipes achats souhaitent également disposer de preuves que les contrôles fonctionnent comme prévu.

L’exigence de preuve modifie la signification de la préparation. Une entreprise n’est pas prête parce que ses dirigeants ont approuvé une politique sur l’IA. Elle l’est lorsque ses équipes peuvent démontrer qui a accédé aux données, quel modèle les a reçues, ce que le système a fait et comment l’organisation a réagi.

C’est pourquoi les conclusions de Kiteworks sur la gouvernance de l’IA trouvent un écho au-delà de la clientèle du fournisseur. Elles décrivent une lacune opérationnelle déjà visible dans les examens de sécurité et les achats des entreprises.

Google News amplifie cette statistique sur les incidents à un moment où les dirigeants reconnaissent le problème, mais manquent de preuves cohérentes. Le titre attire l’attention parce que l’adoption a dépassé les systèmes nécessaires pour l’observer.

Les promesses de gouvernance dépassent les contrôles techniques

Le principal conflit n’oppose pas l’adoption de l’IA à la prudence ; il oppose la gouvernance promise sur le papier à la gouvernance appliquée en production.

La note de Kiteworks consacrée au secteur technologique illustre cette division. Les organisations technologiques ont dominé l’échantillon mondial dans plusieurs capacités formelles de gouvernance.

Le secteur a déclaré utiliser des techniques de préservation de la confidentialité à hauteur de 56 %, contre 33 % au niveau mondial. Les taxonomies et procédures de réponse aux incidents liés à l’IA ont atteint 50 %, contre 27 % à l’échelle mondiale.

Les répondants du secteur technologique ont également déclaré réaliser des évaluations d’impact de l’IA à 53 %, des audits de biais à 47 % et une documentation sur l’explicabilité des modèles à 41 %. Chaque résultat dépassait le chiffre mondial correspondant.

Il s’agit d’investissements significatifs. Les évaluations d’impact peuvent identifier les groupes concernés et les préjudices prévisibles. Les procédures de réponse aux incidents attribuent aux équipes des responsabilités prédéfinies lorsqu’un modèle se comporte de façon inattendue.

Cependant, la même note sur le secteur technologique a relevé des résultats plus faibles dans les infrastructures moins visibles.

Seuls 22 % des répondants du secteur technologique ont signalé des environnements d’entraînement isolés, contre 26 % à l’échelle mondiale. L’isolation sépare les ressources de développement, d’entraînement et de production afin que les données ne puissent pas circuler entre elles sans contrôle.

Seuls 19 % ont déclaré disposer de capacités de provenance et de traçabilité, contre 23 % au niveau mondial. La provenance des données enregistre l’origine des informations, leurs modifications et les modèles ou processus qui les ont utilisées.

Cela crée une contradiction pratique. Une entreprise peut détecter un comportement inhabituel et disposer d’un document de réponse, tout en restant incapable de retracer une sortie affectée jusqu’à ses données sources.

Elle peut également maintenir des contrôles d’accès en production tout en laissant les environnements de développement des modèles connectés de manière trop large. Cette lacune accroît le risque d’accès non autorisé, de données d’entraînement contaminées ou de mouvements de données involontaires.

Les répondants du secteur technologique ont obtenu de meilleurs résultats concernant les pistes d’audit immuables, la surveillance de la dérive et les procédures de réponse aux incidents. Ces contrôles aident les équipes à constater qu’un changement s’est produit.

Une traçabilité insuffisante rend plus difficile l’explication des raisons de ce changement. Elle peut retarder l’analyse des causes profondes et compliquer la prévention des récidives.

Le rapport a également constaté que 53 % des répondants du secteur technologique déclaraient que les conseils d’administration accordaient la priorité à la gouvernance de l’IA. Pourtant, seuls 47 % ont signalé l’attention du conseil à l’égard de la posture globale de cyberrisque, soit sept points de pourcentage sous le chiffre mondial.

Ce résultat ne prouve pas que les conseils d’administration ont abandonné la cybersécurité. Il suggère que l’attention des dirigeants peut se déplacer vers des initiatives d’IA visibles, tandis que la sécurité fondamentale se dispute le même temps et le même budget.

La gouvernance de l’IA ne peut pas être isolée de la cybersécurité comme un projet de conformité distinct. Elle dépend de la gestion des identités, du chiffrement, de la classification des données, de la sécurité logicielle, de la supervision des tiers et de la réponse aux incidents.

Le National Institute of Standards and Technology américain reflète cette approche fondée sur le cycle de vie. Son cadre volontaire de gestion des risques liés à l’IA organise le travail autour de quatre fonctions : Govern, Map, Measure et Manage.

La gouvernance établit les responsabilités et les politiques. La cartographie identifie le contexte et les parties concernées. La mesure évalue le risque, tandis que la gestion le hiérarchise et le traite.

Une entreprise qui s’arrête à la gouvernance n’a achevé qu’une partie de ce cycle. Les politiques doivent être reliées aux observations techniques, aux résultats des tests et aux décisions de réponse.

C’est le renversement central derrière ce titre. Les organisations peuvent sembler préparées parce qu’elles disposent de comités, de normes et d’outils approuvés. Les incidents de sécurité liés à l’IA révèlent si ces préparatifs atteignent les systèmes qui traitent de véritables données.

Les incidents de sécurité liés à l’IA révèlent le problème de l’inventaire

Les organisations ne peuvent pas contrôler les flux de données de l’IA qu’elles ne peuvent ni identifier, ni classer, ni reconstituer.

L’inventaire paraît élémentaire, mais l’IA le rend difficile. Un seul processus métier peut impliquer un employé, une application logicielle, un fournisseur de modèles externe, une infrastructure de récupération et plusieurs référentiels de données.

L’entreprise peut ne posséder qu’une partie de cette chaîne. Une plateforme de support client peut ajouter des fonctionnalités génératives via un modèle tiers. Un développeur peut connecter un assistant de programmation à des référentiels privés.

Une autre équipe peut créer un agent interne qui récupère des documents depuis un espace de stockage partagé. Chaque déploiement peut entraîner des conditions différentes de conservation, d’autorisations et de journalisation.

Un inventaire utile doit donc enregistrer davantage que des noms de produits. Il doit identifier les propriétaires des systèmes, les usages prévus, les fournisseurs de modèles, les données connectées, les outils disponibles, les groupes d’utilisateurs et les lieux géographiques de traitement.

Il doit également préciser si le système peut effectuer des actions. Un assistant qui rédige un e-mail crée un niveau de risque. Un agent autorisé à envoyer cet e-mail ou à modifier un compte en crée un autre.

Les conclusions de Kiteworks sur la visibilité des tiers correspondent à ce problème. Des fournisseurs et intégrations inconnus peuvent masquer les chemins par lesquels circulent des données privées.

L’organisation peut avoir approuvé l’application visible sans comprendre tous les sous-traitants qui se trouvent en dessous. Cela devient important lorsqu’un fournisseur de modèles, un plug-in ou un service de données évolue.

Le même problème se retrouve dans la souveraineté des données. Les recherches de Kiteworks pour 2026 ont révélé qu’environ quatre répondants sur cinq se disaient bien informés des exigences de souveraineté. Pourtant, environ un tiers a signalé un incident lié à la souveraineté au cours de l’année précédente.

La souveraineté des données concerne le contrôle juridique et opérationnel du lieu où résident les informations et de la juridiction qui les régit. L’IA complique cette question lorsque les prompts, les embeddings, les journaux et les résultats des modèles traversent des frontières régionales.

Le rapport sur la souveraineté présente cet écart comme une différence entre la sensibilisation et un contrôle démontrable. Les organisations peuvent comprendre les règles tout en ne disposant pas de mécanismes automatisés d’application ni de preuves prêtes pour un audit.

Ce contraste est plus défendable que de traiter chaque événement signalé comme le même type d’incident lié à l’IA. Il conduit également à un test concret.

Après un événement lié à l’IA, l’organisation peut-elle identifier les données affectées, le modèle impliqué, l’identité à l’origine de l’action, les actions exécutées et les destinataires en aval ? Sinon, la gouvernance reste incomplète, quelle que soit la qualité des politiques.

Les travailleurs du savoir ont un rôle à jouer dans ce système. Ils décident quels fichiers entrent dans les prompts, quelles réponses générées sont jugées fiables et quels outils d’IA s’intègrent au travail quotidien.

Les organisations peuvent réduire les expositions accidentelles en donnant aux employés des moyens approuvés de rechercher et de synthétiser leurs propres informations. Une base de connaissances IA privée peut limiter les copies inutiles entre des services sans lien, lorsque ses limites sont clairement définies.

Cette approche nécessite toujours une gouvernance. Le stockage local ou privé ne résout pas automatiquement les accès excessifs, les résultats inexacts, l’authentification faible ou les obligations de conservation.

L’objectif n’est pas d’interdire les flux de travail utiles. Il consiste à offrir aux utilisateurs un parcours approuvé dont les mouvements de données peuvent être compris et examinés.

L’inventaire doit également inclure la gestion des changements. Une application qui a commencé comme assistant de rédaction peut acquérir des fonctions de récupération, d’automatisation ou d’agent grâce à une mise à jour.

Les équipes de sécurité devraient examiner les nouvelles capacités en fonction des accès et des actions modifiés, et pas seulement du nom familier du produit. Un outil auparavant à faible risque peut devenir sensiblement différent après avoir reçu de nouvelles autorisations.

C’est là que les incidents de sécurité liés à l’IA deviennent des signaux précieux. Chaque événement devrait mettre à jour l’inventaire, le modèle de menace, la conception des contrôles et les consignes destinées aux employés.

Un simple nombre d’incidents ne peut pas montrer si les organisations ont tiré des leçons de ces événements. La qualité du processus correctif compte davantage que le chiffre mis en avant.

Ce que le chiffre de 80 % ne prouve pas

Le titre indique une exposition étendue, mais il n’établit pas un taux universel de compromission et ne prouve pas que l’IA a causé chaque incident signalé.

Les enquêtes de fournisseurs peuvent révéler des tendances utiles, en particulier lorsqu’elles publient la taille de l’échantillon et leur méthodologie. Elles comportent aussi des limites inévitables.

Les répondants peuvent interpréter différemment le terme « incident ». Les responsables de la sécurité peuvent regrouper sous une même appellation les attaques tentées, les compromissions confirmées, les violations de politiques, les événements de confidentialité et les défaillances opérationnelles.

Les résultats auto-déclarés dépendent aussi de la visibilité. Une organisation mature disposant d’une surveillance étendue peut signaler davantage d’incidents parce qu’elle détecte davantage d’événements.

Une organisation moins préparée peut paraître plus sûre simplement parce qu’elle ne voit pas ses défaillances. Les propres recherches de Kiteworks mettent en garde contre cet effet de visibilité.

Les populations interrogées comptent également. La note technologique de Kiteworks représente très largement de grandes organisations : 97 % des répondants travaillent dans des entreprises comptant au moins 1 000 employés.

Les grandes entreprises disposent de davantage de systèmes, d’utilisateurs, de fournisseurs et d’obligations réglementaires. Leur expérience ne doit pas être projetée directement sur les petites entreprises.

L’analyse technologique ne comprenait que 32 répondants issus des secteurs concernés. Une différence de plusieurs réponses peut modifier sensiblement un pourcentage au sein de ce sous-groupe.

L’affirmation de 80 % nécessite donc des précisions complémentaires avant que les lecteurs puissent la comparer à une autre étude sur les incidents. Les détails nécessaires incluent la formulation de la question, les options de réponse, la période d’observation et le traitement des événements suspectés.

Il serait également utile de séparer les incidents cyber traditionnels des événements provoqués par l’IA. Un attaquant utilisant l’IA pour améliorer l’hameçonnage diffère d’un modèle d’entreprise qui divulgue des données récupérées.

Une troisième catégorie concerne les attaques conventionnelles contre l’infrastructure d’IA, telles que le vol d’identifiants ou des logiciels vulnérables. Qualifier les trois de « incidents liés à l’IA » masque qui contrôlait le système défaillant.

Kiteworks vend aussi des produits conçus pour répondre à la gouvernance des données privées. Cette position commerciale n’invalide pas ses données, mais elle crée une incitation à souligner les risques auxquels sa plateforme répond.

Une reproduction indépendante renforcerait l’affirmation mise en avant. La publication de ventilations anonymisées par type d’incident, taille d’organisation, région et maturité de gouvernance le ferait également.

L’enseignement le plus crédible du rapport ne nécessite pas d’accepter un taux universel de 80 %. Plusieurs études de Kiteworks montrent que la préparation formelle et l’application opérationnelle divergent fréquemment.

La note technologique identifie des lacunes concernant l’isolation de l’entraînement et la provenance. L’enquête antérieure a constaté une mise en œuvre limitée de la gouvernance technique. La recherche sur la souveraineté révèle une forte sensibilisation malgré la persistance des incidents.

Ensemble, ces constats étayent une conclusion plus restreinte. De nombreuses grandes organisations ont entamé une gouvernance de l’IA, mais relativement peu peuvent démontrer un contrôle technique complet sur l’ensemble du cycle de vie des données.

C’est sérieux sans être sensationnaliste. Cela offre aussi aux acheteurs un meilleur cadre pour évaluer les produits de gouvernance.

Un fournisseur devrait expliquer quels flux de données il observe, quelles politiques il applique et quelles actions il peut bloquer. Il devrait également divulguer les limites et les dépendances d’intégration.

Les acheteurs devraient se montrer prudents lorsqu’un produit traite la gouvernance comme un simple tableau de bord. La visibilité est nécessaire, mais l’application, les tests, la réponse et la reprise complètent le cycle opérationnel.

Ils devraient également éviter de supposer qu’une seule passerelle contrôle tous les chemins. Les employés, les fonctionnalités d’IA intégrées, les interfaces de programmation d’applications directes et les agents autonomes peuvent créer des routes distinctes.

Le titre de Google News mérite l’attention, car le risque sous-jacent est réel. Son pourcentage exact devrait rester attribué au rapport jusqu’à ce que la méthodologie complète précise ce que ce chiffre inclut.

Trois signaux qui mettront à l’épreuve l’avertissement de Kiteworks

Les prochaines données devraient montrer si les entreprises construisent une gouvernance applicable ou ajoutent simplement une couche supplémentaire de documentation.

Le premier signal est une meilleure divulgation des incidents. Les recherches futures devraient séparer les compromissions confirmées, les événements suspectés, les violations de politiques et les actions non intentionnelles de l’IA.

Elles devraient également distinguer les incidents causés par l’IA des attaques visant les systèmes d’IA. Cette taxonomie rendrait les comparaisons d’une année à l’autre plus significatives.

Une divulgation détaillée pourrait renforcer l’avertissement de Kiteworks si des taux élevés persistent dans des catégories clairement définies. Elle pourrait affaiblir le titre si le chiffre de 80 % combine de nombreux événements de faible gravité ou vaguement liés.

Le deuxième signal est un progrès mesurable des contrôles techniques. La note technologique de 2026 fournit des références pour les environnements d’entraînement isolés, la provenance, les guides de réponse aux incidents et la supervision par le conseil d’administration.

Une enquête de suivi devrait utiliser les mêmes questions et la même méthode d’échantillonnage. Une adoption croissante de la traçabilité et de l’isolation des environnements montrerait que les organisations comblent l’écart d’application.

Des résultats stables ou en baisse soutiendraient la préoccupation centrale du rapport. Ils indiqueraient que les dépenses restent concentrées sur les évaluations et les politiques plutôt que sur les contrôles fondamentaux.

Le troisième signal est la preuve réglementaire. Les mesures d’application européennes, les audits et les orientations de mise en œuvre devraient révéler quelles défaillances de gouvernance créent la plus forte exposition pratique.

Surveillez les cas impliquant une documentation manquante, une surveillance inadéquate, une interaction avec l’IA non divulguée ou des mouvements de données mal contrôlés. Ces exemples aideront les organisations à hiérarchiser leurs investissements.

L’action réglementaire pourrait renforcer la thèse du rapport si les autorités constatent à plusieurs reprises des écarts entre les politiques déclarées et le comportement des systèmes. Une conformité claire accompagnée de peu de défaillances opérationnelles en réduirait l’urgence.

Les acheteurs d’entreprise n’ont pas besoin d’attendre ces signaux pour agir. Ils peuvent tester leur préparation à l’aide d’un exercice simple centré sur un flux de travail d’IA en production.

Commencez par un système qui accède à des informations sensibles. Demandez au responsable d’identifier chaque source de données, fournisseur de modèles, outil connecté, autorisation, règle de conservation et décideur responsable.

Simulez ensuite un compte compromis, un document malveillant ou une action non intentionnelle. Déterminez si l’organisation peut arrêter le système, retracer son activité, identifier les informations exposées et préserver les éléments de preuve.

L’exercice devrait inclure les équipes juridique, sécurité, confidentialité, informatique et l’équipe métier qui utilise le système. La gouvernance de l’IA échoue lorsque la responsabilité disparaît entre ces groupes.

Les équipes devraient conserver les décisions et les enseignements tirés des incidents dans un système consultable, plutôt que de les disperser entre réunions et documents. Un flux de travail de connaissances structuré peut aider les responsables à maintenir les preuves à mesure que les systèmes évoluent.

La documentation ne peut toujours pas se substituer à l’application. Sa valeur réside dans le lien qu’elle établit entre les responsables nommés, le comportement observé, les exceptions approuvées et les actions correctives.

Le chiffre de 80 % d’incidents signalé par Kiteworks se lit au mieux comme un avertissement qui mérite vérification. Les recherches plus larges de l’entreprise montrent déjà suffisamment d’éléments indiquant une faible visibilité, une gouvernance technique limitée et une provenance incomplète.

La vraie question n’est plus de savoir si une organisation possède une politique d’IA. Elle est de savoir si cette organisation peut reconstituer les actions d’un système d’IA après qu’un problème survient.

Google News peut amplifier un pourcentage spectaculaire, mais les responsables de la sécurité ont besoin des contrôles qui le sous-tendent. Ils devraient inventorier un flux de travail d’IA actif, tester son parcours de défaillance et documenter ce qui reste invisible.