L’avertissement de Bonfy sur le shady AI révèle le prochain problème de gouvernance pour la sécurité

Le PDG de Bonfy, Gidi Cohen, a identifié une lacune préoccupante en matière de gouvernance au sein des systèmes d’IA d’entreprise approuvés. Un accès légitime ne garantit plus un résultat approprié.

Cohen appelle ce problème le « shady AI ». Le terme décrit une IA approuvée qui utilise des données autorisées d’une manière contraire à l’intention de l’entreprise, aux politiques ou aux attentes des clients. Contrairement au shadow AI, le système lui-même n’est pas dissimulé aux équipes de sécurité.

L’avertissement a touché un public plus large grâce à la couverture médiatique spécialisée en sécurité et à Google News. Pourtant, l’essentiel ne réside pas dans une nouvelle étiquette accrocheuse de cybersécurité. Il s’agit de l’effondrement d’une hypothèse familière : une technologie approuvée, fonctionnant avec des autorisations valides, est une technologie gouvernée.

Cette hypothèse fonctionnait mieux lorsque les logiciels suivaient des instructions prévisibles. Un employé ouvrait un dossier, modifiait un champ ou exportait un document. Les équipes de sécurité pouvaient relier l’action à une personne, une autorisation, une application et un horodatage.

L’IA change cette relation. Un système peut récupérer des milliers d’enregistrements autorisés, en déduire des liens et produire un résultat que personne n’a directement demandé. Chaque accès individuel peut être autorisé, tandis que le résultat combiné franchit une limite.

Ce conflit place les équipes de sécurité d’entreprise face à deux choix insatisfaisants. Elles peuvent ralentir l’adoption de l’IA par des contrôles stricts, ou autoriser un déploiement rapide sans comprendre chaque usage ultérieur des données de l’entreprise.

Aucun de ces choix ne résout le problème central. Les organisations ont besoin de contrôles qui évaluent pourquoi les données sont utilisées, et pas seulement si une application peut y accéder.

Le shady AI déplace le risque au sein des systèmes approuvés

Le shady AI transforme un flux de travail approuvé en problème de gouvernance sans nécessiter d’employé malveillant, d’application inconnue ou d’identifiant volé.

Cohen a introduit ce terme en expliquant comment l’IA distingue la pertinence de l’appropriation. Son argument porte sur des systèmes qui opèrent au sein de plateformes approuvées et de flux de travail intentionnels.

L’utilisateur peut disposer du rôle adéquat. L’application peut avoir passé un examen de sécurité. Les enregistrements sous-jacents peuvent tous être accessibles grâce à des autorisations légitimes.

L’action obtenue peut néanmoins entrer en conflit avec les politiques. Un assistant IA pourrait combiner des communications clients, des détails contractuels et un historique de support afin de produire un profil de risque non autorisé. Chaque source semble pertinente, mais leur utilisation combinée change la finalité des données.

La distinction de Cohen compte, car les programmes de sécurité traitent généralement l’approbation comme une frontière de contrôle majeure. Une fois qu’un fournisseur, une application, une intégration et une identité ont passé l’examen, la surveillance se concentre souvent sur les accès non autorisés ou les comportements suspects.

La présentation du concept par Bonfy indique qu’un système d’IA peut récupérer des informations autorisées tout en produisant un résultat contraire aux attentes des clients. Dans son résumé du concept de shady AI, l’entreprise décrit une IA approuvée qui dépasse les limites prévues.

Cela reste un cadrage soutenu par un fournisseur, et non une catégorie réglementaire reconnue. Aucun organisme indépendant n’a établi le « shady AI » comme terme standard ou comme catégorie mesurable d’incidents.

Pour autant, le comportement sous-jacent est suffisamment réel pour être examiné. Les systèmes génératifs peuvent synthétiser des données provenant de plusieurs référentiels, déduire des attributs sensibles et déclencher des actions via des outils connectés. Ces capacités élargissent la signification de l’accès autorisé.

Prenons un assistant de travail connecté aux e-mails, aux documents, aux calendriers et aux dossiers clients. Un responsable lui demande d’identifier les comptes susceptibles de résilier au cours du trimestre.

L’assistant pourrait déduire un stress financier à partir de litiges de facturation. Il pourrait extraire une insatisfaction de conversations privées avec le support. Il pourrait également relier ces constats aux dates de renouvellement de contrat et aux commentaires des employés.

Chaque source pourrait relever des autorisations techniques du responsable. Toutefois, l’organisation n’a peut-être jamais approuvé cette finalité de profilage combiné. Elle peut également ne disposer d’aucune trace des facteurs ayant façonné la recommandation.

Cela diffère du shadow AI ordinaire. Le shadow AI désigne généralement des employés utilisant des modèles non approuvés, des comptes personnels de chatbot, des extensions de navigateur ou des agents non autorisés.

Dans ces cas, le problème de sécurité commence par la visibilité. Les équipes doivent découvrir quels outils sont actifs, déterminer quelles données y ont été introduites et décider s’il faut bloquer ou gouverner leur utilisation.

The Hacker News a décrit une autre version de ce risque au sein de logiciels approuvés. Des fonctionnalités d’IA peuvent apparaître dans des outils de support, des systèmes documentaires et des plateformes clients existants après l’examen initial du fournisseur.

Son aperçu des risques du shadow AI soutient que le fait d’avoir auparavant évalué un logiciel ne gouverne pas chaque fonctionnalité d’IA activée ultérieurement. Cette observation réduit l’écart entre le shadow AI et le cadrage plus récent de Cohen.

Les deux concepts décrivent néanmoins des défaillances de contrôle différentes.

Le shadow AI demande si l’organisation sait qu’un outil ou une fonctionnalité existe. Le shady AI demande si le comportement d’un système approuvé reste approprié pour un utilisateur, une finalité et une relation donnés.

Google News peut placer les deux histoires sous le vaste thème de la sécurité de l’IA. Les défenseurs des entreprises ne peuvent pas se permettre de les traiter comme le même problème opérationnel.

Les outils de découverte peuvent révéler un chatbot inconnu. Ils ne peuvent pas décider automatiquement si un assistant approuvé doit utiliser une conversation sensible avec un client pour influencer une décision commerciale.

Cette décision exige du contexte. Elle exige également des politiques que les logiciels peuvent évaluer avant la récupération, la génération ou l’action.

Pourquoi les contrôles d’identité et d’accès ne suffisent plus

Les contrôles d’identité répondent à la question de savoir qui peut accéder aux données, mais le shady AI oblige les organisations à décider quelles relations et quelles finalités rendent cet accès approprié.

Le contrôle d’accès traditionnel accorde des autorisations par le biais de rôles, de groupes, de propriété des ressources et de règles de politique. Un responsable du support client peut lire tous les dossiers attribués à une région. Un analyste financier peut examiner chaque facture d’une unité opérationnelle.

Ces contrôles restent essentiels. Ils empêchent de nombreux utilisateurs et applications non autorisés d’atteindre des systèmes sensibles. Ils créent également des traces que les enquêteurs peuvent examiner après un incident.

Cependant, des autorisations larges existent souvent parce que les personnes ont besoin de flexibilité. Un employé senior peut accéder à des milliers de documents tout en n’en utilisant qu’un petit sous-ensemble pour chaque tâche.

Le jugement humain fournit une seconde couche informelle. Les employés comprennent généralement que l’accès à un dossier client n’autorise pas tous les usages possibles de son contenu.

On ne peut pas présumer que l’IA partage cette compréhension. Un modèle optimise sa réponse à partir du contexte disponible, des instructions et des schémas appris. Il ne connaît pas intrinsèquement les limites non écrites d’une organisation.

Cela crée un problème de finalité. Les données collectées pour le support client peuvent être techniquement accessibles à un assistant commercial. Cette disponibilité n’autorise pas nécessairement l’utilisation du langage émotionnel issu d’appels au support pour ajuster un traitement commercial.

Cela crée également un problème de relation. Un clinicien, un avocat, un responsable des ressources humaines et un administrateur système peuvent accéder au même dossier dans le cadre de devoirs professionnels différents.

Une autorisation conventionnelle peut représenter la ressource et l’utilisateur. Elle capture rarement l’ensemble de la relation entourant chaque déduction qu’une IA pourrait effectuer.

Les agents augmentent encore les enjeux. Un agent IA est un logiciel qui choisit et exécute des actions au moyen d’outils connectés, plutôt que de se limiter à produire du texte.

Un agent approuvé peut lire des e-mails, interroger une base de données, mettre à jour un dossier client et envoyer un message. Ses autorisations peuvent être valides à chaque étape.

La séquence combinée peut néanmoins rester dangereuse. Une instruction non fiable dissimulée dans un e-mail pourrait rediriger le comportement de l’agent. Un objectif trop général pourrait également encourager une récupération excessive ou une action inutile.

OWASP décrit l’injection de prompt comme des instructions qui manipulent un modèle via une entrée directe ou du contenu que le modèle traite ultérieurement. L’impact dépend fortement des outils et de l’autorité dont dispose le système, selon ses recommandations sur l’injection de prompt.

Cette menace relie les exploits de sécurité aux défaillances de gouvernance. Une instruction malveillante peut provoquer une action inappropriée, mais une politique ambiguë peut produire un résultat similaire sans attaquant.

OWASP met séparément en garde contre l’autonomie excessive, lorsqu’un système d’IA dispose de plus de fonctionnalités, d’autorisations ou d’autonomie que nécessaire. Son exemple comprend un e-mail malveillant ordonnant à un agent de rechercher dans une boîte de réception et de transférer des informations sensibles.

Le principe du moindre privilège reste une partie de la réponse. Un assistant ne peut pas mal utiliser des données ou des fonctions auxquelles il n’a pas accès.

Pourtant, la réduction des autorisations à elle seule a ses limites. Les organisations déploient souvent l’IA précisément parce qu’elle peut relier des informations entre plusieurs systèmes. Supprimer toute capacité intersystèmes peut éliminer la valeur commerciale qui justifiait le déploiement.

La tâche la plus difficile consiste à rendre l’autorisation plus spécifique. Une décision doit prendre en compte l’identité à l’origine de la demande, la finalité métier, la relation aux données, l’action, la destination et le contexte actuel.

Par exemple, un assistant de service client peut résumer une réclamation pour le dossier qui lui est attribué. Le même assistant ne devrait pas ajouter des informations de santé issues de cette réclamation à un profil marketing.

Les deux actions impliquent la même identité et les mêmes données sous-jacentes. La différence réside dans la finalité, l’audience et l’usage attendu.

C’est pourquoi le shady AI constitue fondamentalement un défi de gouvernance. Les équipes de sécurité peuvent définir des limites techniques, mais les responsables juridiques, de la protection de la vie privée, de la conformité, du produit et des métiers doivent définir le comportement approprié.

Cette responsabilité partagée est inconfortable. Les organisations de sécurité préfèrent des règles applicables, tandis que les équipes de politique rédigent souvent des principes qui dépendent de l’interprétation humaine.

Les systèmes d’IA exposent l’écart entre ces deux approches. Une politique affirmant que les données clients doivent être utilisées « de manière appropriée » offre peu de protection si l’organisation ne transforme pas cette expression en contrôles testables.

Google News met en lumière le passage de l’accès à l’intention

La discussion plus large sur la sécurité évolue de la découverte des outils d’IA vers la gouvernance de ce que les modèles et agents approuvés font avec un accès légitime.

L’apparition du shady AI dans Google News reflète une évolution plus large de la couverture de la sécurité d’entreprise. La première vague de préoccupations portait sur les employés collant des données sensibles dans des chatbots publics.

Ce risque n’a pas disparu. Les comptes personnels, les applications non approuvées et les fonctionnalités d’IA intégrées continuent de créer des problèmes de visibilité et de fuite de données.

Cependant, les déploiements d’entreprise approuvés posent désormais une question plus complexe. Les organisations connectent des assistants et des agents à des systèmes de grande valeur, car des interfaces de chat isolées offrent une valeur opérationnelle limitée.

Les connexions créent du contexte. Elles créent aussi de l’autorité.

Un modèle connecté à une base de connaissances d’entreprise peut localiser des informations internes. Un agent connecté à un logiciel opérationnel peut agir sur ces informations. La gouvernance doit donc couvrir à la fois l’interprétation et l’exécution.

Les recherches d’IBM sur les violations de données en 2025 ont révélé une lacune substantielle de supervision autour de l’IA d’entreprise. Son communiqué officiel indiquait que 13 % des organisations étudiées avaient signalé des violations impliquant des modèles ou des applications d’IA.

Parmi ces organisations, 97 % ne disposaient pas de contrôles d’accès à l’IA adéquats. IBM a également indiqué que 63 % des organisations interrogées n’avaient pas de politiques de gouvernance de l’IA ou étaient encore en train de les élaborer.

Ces chiffres proviennent d’une étude financée par un fournisseur et ne doivent pas définir le niveau de risque de chaque organisation. Ils montrent néanmoins pourquoi la sécurité de l’IA a dépassé le stade des attaques hypothétiques contre les modèles.

Les conclusions d’IBM sur les violations décrivent une adoption qui progresse plus vite que la gouvernance. Shady AI identifie une conséquence possible de ce déséquilibre au sein de systèmes approuvés.

Les cadres existants offrent des bases utiles. Le cadre de l’IA du NIST structure la gestion des risques liés à l’IA autour de la gouvernance, de la cartographie, de la mesure et de la gestion des risques.

Le NIST a également publié un profil pour l’IA générative qui adapte ce cadre aux risques propres aux modèles. Il met l’accent sur des responsabilités documentées, des tests, des processus de gestion des incidents et une mesure continue.

Ces pratiques aident les organisations à dépasser l’approbation ponctuelle. Elles encouragent les équipes à traiter l’IA déployée comme un système évolutif nécessitant une supervision continue.

Cependant, un cadre ne peut pas fournir les règles métier propres à chaque entreprise. Une banque, un hôpital, un fournisseur de logiciels et une université définiront différemment les usages appropriés des données.

La réglementation ajoute une couche supplémentaire. Les règles de l’Union européenne imposent des obligations aux fournisseurs et aux déployeurs selon le rôle et la classification des risques d’un système d’IA.

La Commission européenne indique que les obligations relatives aux modèles à usage général ont commencé à s’appliquer le 2 août 2025. Elles comprennent des exigences en matière de documentation et de transparence, ainsi que des obligations supplémentaires pour les modèles classés comme présentant un risque systémique.

Ces règles ciblent largement les fournisseurs et les cas d’usage désignés. Elles ne tranchent pas automatiquement chaque décision contextuelle prise par un assistant d’entreprise utilisant des données internes autorisées.

Une organisation peut satisfaire aux exigences de documentation des fournisseurs tout en déployant un assistant dont les finalités internes sont mal définies. La conformité juridique et la pertinence opérationnelle se recoupent, mais ne sont pas identiques.

La même distinction apparaît dans le droit de la protection de la vie privée. Le consentement ou une autre base juridique peut autoriser le traitement des données à un niveau général. Une nouvelle inférence ou un ensemble de données combiné peut néanmoins entraîner des conséquences inattendues.

C’est là que l’expression « la pertinence n’est pas une autorisation » devient utile. Une information peut améliorer la réponse d’un modèle sans être appropriée pour cette décision.

Les moteurs de recherche et Google News tendent à privilégier des catégories simples, telles que le shadow AI, les agents IA et les fuites de données. Shady AI ne s’inscrit pas clairement dans l’une d’elles.

Il se situe à l’intersection de la gestion des accès, de la confidentialité, du comportement des modèles, de la gouvernance des données et de la conception des processus métier. Ce chevauchement rend l’attribution des responsabilités plus difficile et les problèmes plus faciles à négliger.

L’organisation sous pression n’est donc pas uniquement le centre des opérations de sécurité. Les responsables de la sécurité des systèmes d’information, les responsables de la confidentialité, les équipes juridiques, les propriétaires de données et les responsables applicatifs héritent tous d’une partie du problème.

Ils ont besoin d’une vision unique et applicable des comportements autorisés. Sans elle, chaque équipe peut croire qu’un autre groupe est responsable du risque.

La partie la plus difficile consiste à transformer les politiques en décisions d’exécution

Une réponse crédible doit appliquer le contexte lors de la récupération d’informations et de l’action, et non simplement publier une nouvelle politique d’usage acceptable.

De nombreuses organisations ont commencé la gouvernance de l’IA par des listes. L’une répertorie les outils approuvés. Une autre identifie les données interdites. Une troisième attribue les propriétaires des applications et les dates de révision.

Ces inventaires sont nécessaires, en particulier pour détecter le shadow AI. Ils ne répondent toutefois pas pleinement au cas d’un système approuvé qui produit un résultat inapproprié à partir de ressources autorisées.

Shady AI exige des contrôles plus proches de l’exécution. L’exécution désigne le moment où une IA reçoit une demande, récupère des informations, génère une sortie ou appelle un outil connecté.

À ce moment-là, le système dispose de davantage de contexte qu’un processus d’approbation statique. Il connaît l’utilisateur, la demande, les données sélectionnées, la destination prévue et l’action proposée.

Une couche de gouvernance peut évaluer ces facteurs avant d’autoriser la poursuite du flux de travail. Elle peut refuser l’accès, supprimer un contexte sensible, exiger une approbation ou limiter l’action disponible.

La politique doit être suffisamment précise pour être appliquée. « Protéger la confiance des clients » est un principe important, mais les logiciels ont besoin d’une règle plus précise.

Une règle pourrait interdire à un assistant d’utiliser des conversations du support pour déterminer des remises. Une autre pourrait empêcher la synthèse d’informations médicales des employés en dehors d’un flux de travail autorisé lié aux avantages sociaux.

Les organisations ont également besoin de traçabilité, qui consigne l’origine des informations utilisées dans une réponse d’IA. La traçabilité aide les examinateurs à comprendre quelles sources ont influencé une réponse ou une action.

Enregistrer uniquement le prompt final et la réponse ne suffit pas pour de nombreux flux de travail agentiques. Les enquêteurs peuvent avoir besoin des documents récupérés, des appels d’outils, des évaluations de politiques, de la version du modèle et de l’historique des approbations.

Cet enregistrement soutient les audits et la réponse aux incidents. Il peut également révéler des règles de politique qui bloquent un travail inoffensif ou autorisent des combinaisons risquées.

Les tests doivent refléter les relations métier réelles. Des benchmarks génériques de modèles ne peuvent pas déterminer si un message spécifique d’un client doit figurer dans une recommandation de renouvellement.

Les équipes doivent élaborer des scénarios autour de leurs propres données, rôles, flux de travail et résultats interdits. Les tests doivent inclure à la fois des prompts malveillants et des demandes ordinaires aux finalités ambiguës.

L’approbation humaine peut réduire le risque pour les actions à fort impact. Elle est particulièrement utile lorsque l’examinateur reçoit le contexte pertinent et une raison compréhensible pour l’alerte.

Un bouton intitulé « approuver » est peu utile si l’examinateur ne peut pas voir quelles sources sensibles ont façonné l’action. La fatigue liée aux approbations peut aussi transformer un contrôle formel en clic automatique.

Les organisations devraient donc réserver l’examen humain aux limites importantes. Les flux de travail moins risqués peuvent s’appuyer sur des restrictions automatisées, l’échantillonnage et une surveillance rétrospective.

La minimisation des données constitue un autre contrôle pratique. Un assistant ne devrait recevoir que les informations nécessaires à sa tâche actuelle, même si son compte de service peut accéder à davantage de données.

Les systèmes de récupération peuvent appliquer cette restriction avant que le contenu n’entre dans le contexte du modèle. Les passerelles d’outils peuvent de la même manière limiter les opérations qu’un agent peut effectuer.

Pour les travailleurs du savoir, le contexte local peut réduire les transferts inutiles vers de vastes services externes. Une base de connaissances personnelle bien conçue peut préserver des frontières plus claires entre les informations personnelles et les informations organisationnelles partagées.

Toutefois, l’architecture seule ne garantit pas un usage approprié. Le traitement local peut réduire l’exposition tout en produisant une inférence injuste, intrusive ou non autorisée.

Il s’agit d’un point de scepticisme important. Les fournisseurs de sécurité peuvent présenter l’application contextuelle comme une réponse complète, mais l’interprétation des politiques demeure difficile.

Le langage naturel est ambigu. Les relations métier évoluent. Une règle qui fonctionne pour un service peut entraver une autre équipe ou passer à côté d’un usage abusif subtil.

Les faux positifs peuvent pousser les employés à contourner les règles. Les faux négatifs peuvent créer une confiance injustifiée dans une couche automatisée de gouvernance.

Le comportement des modèles change également après les mises à jour. Un prompt, une stratégie de récupération ou un test de politique qui fonctionnait avec une version peut se comporter différemment avec une autre.

Les organisations devraient traiter les contrôles contextuels comme une partie d’un programme à plusieurs couches. L’identité, le moindre privilège, la classification des données, le filtrage de récupération, les restrictions sur les outils, l’évaluation et la supervision humaine restent nécessaires.

Aucun contrôle unique ne garantit que chaque résultat soit approprié. L’objectif est de rendre les violations de politiques visibles, testables et plus difficiles à exécuter à la vitesse des machines.

Trois signaux montreront si Shady AI devient une véritable catégorie de sécurité

Shady AI ne comptera que si les organisations peuvent le mesurer, appliquer des contrôles significatifs et relier les défaillances à des responsables identifiables.

Le premier signal sera de savoir si les principaux cadres de sécurité distinguent l’usage autorisé inapproprié de l’IA non autorisée ordinaire. Le NIST, OWASP et les groupes sectoriels traitent déjà certains aspects connexes.

L’injection de prompts couvre les comportements de modèles manipulés. L’autonomie excessive couvre une autonomie dangereuse. Le shadow AI couvre les systèmes inconnus ou non approuvés.

Aucune de ces étiquettes ne décrit parfaitement un système approuvé prenant une décision contextuellement inacceptable sans attaquant. Une taxonomie plus claire aiderait les équipes à signaler les incidents de façon cohérente.

Surveillez les nouvelles orientations des cadres qui abordent la finalité, la relation et l’inférence. De telles orientations renforceraient l’argument de Cohen selon lequel les contrôles d’accès conventionnels laissent subsister une lacune importante.

Ce jugement s’affaiblirait si les catégories existantes couvraient déjà ces incidents sans confusion opérationnelle. Une nouvelle terminologie a peu de valeur lorsqu’elle se contente de renommer des défaillances établies.

Le deuxième signal sera l’arrivée de contrôles d’exécution mesurables. Les fournisseurs promettront une gouvernance contextuelle, mais les acheteurs devraient rechercher des éléments probants allant au-delà des tableaux de bord de politiques.

Parmi les éléments utiles figurent des restrictions de finalité applicables, des journaux de décision, des contrôles au niveau de la récupération, des approbations d’appels d’outils et des tests reproductibles. Les produits devraient également expliquer pourquoi une politique a autorisé ou refusé une action.

Des évaluations indépendantes seraient particulièrement précieuses. Un fournisseur ne devrait pas être le seul à définir le risque, mesurer son produit et déclarer le contrôle réussi.

Les acheteurs devraient tester des scénarios réalistes avant un déploiement à grande échelle. Ils devraient se demander si le système bloque les combinaisons de données inappropriées, et pas seulement les prompts malveillants connus.

Ils devraient également examiner les modes de défaillance. Un contrôle qui bloque trop souvent des flux de travail légitimes perdra son soutien, même si sa logique de sécurité semble solide.

Le troisième signal sera la responsabilité organisationnelle. Shady AI recoupe les responsabilités liées à la sécurité, à la confidentialité, au droit, aux données et aux produits.

Un comité de gouvernance peut coordonner ces équipes, mais les comités produisent souvent des orientations sans responsabilité opérationnelle. Chaque système déployé a néanmoins besoin d’un décideur responsable.

Ce responsable devrait approuver les finalités prévues, les relations de données acceptables, les résultats interdits et les règles d’escalade. Les équipes de sécurité peuvent ensuite traduire ces décisions en contrôles techniques et en tests.

Le signalement des incidents révélera si ce modèle fonctionne. Les organisations devraient pouvoir distinguer un outil inconnu, un agent compromis, une défaillance d’autorisation et une action autorisée mais inappropriée.

Ces catégories mènent à des remèdes différents. Bloquer un domaine peut résoudre le problème d’un chatbot non approuvé, mais ne peut pas gouverner un modèle approuvé déjà intégré dans une application métier.

L’exposition dans Google News attirera davantage l’attention sur shady AI, mais l’attention seule n’établira pas le terme. Les preuves issues de systèmes déployés doivent montrer une défaillance récurrente que les contrôles existants ne détectent pas systématiquement.

Les responsables de la sécurité devraient commencer par un inventaire restreint des flux de travail d’IA approuvés qui touchent des données sensibles ou des décisions importantes. Pour chaque flux de travail, ils devraient poser quatre questions.

Quelles informations le système peut-il récupérer ? Quelles finalités justifient cette récupération ? Quelles actions peut-il entreprendre ? Qui peut expliquer et arrêter un résultat inapproprié ?

Si ces questions produisent des réponses vagues, la lacune de gouvernance existe déjà. Les équipes n’ont pas besoin d’attendre une violation, une réglementation ou une nouvelle catégorie de produits pour l’examiner.

La prochaine étape pratique consiste à sélectionner un flux de travail à fort impact et à le suivre de la demande au résultat. Consignez les identités, les données récupérées, les politiques, les décisions du modèle, les appels d’outils et les approbations humaines.

Testez ensuite des demandes techniquement autorisées mais contextuellement inappropriées. Cet exercice montrera si « approuvé » signifie réellement gouverné, ou simplement connecté et digne de confiance.