« Nous avons une politique IA. » Où est l'inventaire ?

Imaginez la prochaine réunion de gouvernance.

Quelqu'un demande quels systèmes d'IA l'organisation utilise. La politique arrive immédiatement. Elle porte un numéro de version, une date d'approbation et la signature du directeur.

L'inventaire, lui, prend plus de temps.

L'IT envoie une liste de produits approuvés. Le marketing ajoute l'assistant qu'il utilise via des comptes personnels. Les ventes mentionnent le bot qui rejoint les appels clients. Les RH indiquent que la plateforme de recrutement dispose de « quelques fonctionnalités IA », mais personne ne sait vraiment lesquelles sont activées.

Puis quelqu'un demande ce que les collaborateurs font avec les outils approuvés.

Un second silence.

Tout le monde pensait que quelqu'un d'autre assurait le suivi. Personne n'a nécessairement menti. Chacun a répondu à une question différente : ce qui avait été approuvé, ce qui avait été acheté, ce dont on se souvenait.

Aucune de ces réponses n'équivaut à ce qui est utilisé. Et savoir ce qui est utilisé ne permet pas encore d'établir si c'est utilisé correctement.

Votre inventaire IA doit décrire l'organisation que vous avez, non celle que votre politique suppose que vous avez.

Une liste de fournisseurs n'est pas un inventaire IA

Le nom d'un fournisseur vous indique où envoyer la facture. Il ne vous dit pas ce que font les collaborateurs, quelles informations entrent dans le système, ni les décisions que ses résultats influencent.

Considérez un assistant utilisé pour réécrire des contenus marketing publics. Imaginez maintenant le même produit utilisé pour évaluer des candidats à un poste. Le fournisseur n'a pas changé. La finalité, les informations et les personnes concernées, si.

Ma recommandation est de tenir un registre par système ou déploiement, puis d'y rattacher les cas d'usage matériellement différents. Créez une entrée distincte pour un cas d'usage lorsque la finalité, les données, les droits d'accès ou les conséquences changent suffisamment pour nécessiter une évaluation séparée.

Vous n'avez pas besoin d'une nouvelle ligne pour chaque prompt. Vous devez en revanche distinguer « rédige du contenu public » de « contribue aux décisions de recrutement ».

Une ligne par fournisseur masque les différences. Une ligne par prompt crée une charge administrative punitive.

L'inventaire n'est pas un accessoire de gouvernance improvisé. Le NIST AI Risk Management Framework Playbook traite explicitement des inventaires de systèmes IA dans GOVERN 1.6, notamment leur périmètre, les attributs à consigner et les responsabilités de maintenance. (NIST AI Resource Center)

La question pratique est de savoir si le vôtre peut répondre à une question de suivi.

L'IA que personne n'a achetée compte quand même

Commencez par la shadow AI : les outils ou déploiements utilisés à des fins professionnelles sans visibilité organisationnelle ni autorisation adéquate.

Élargissez le périmètre de découverte au-delà des produits achetés en standalone. Interrogez les collaborateurs sur les comptes personnels, les extensions de navigateur, les assistants de réunion, les fonctionnalités IA intégrées aux logiciels existants, les modèles développés en interne et les workflows qui appellent des API de modèles externes.

Interrogez également les fournisseurs. Un prestataire utilise-t-il l'IA pour traiter vos informations dans le cadre du travail que vous lui avez externalisé ?

Ne limitez pas l'exercice à l'IA générative. Incluez les systèmes de prévision, de classification, de reconnaissance d'images et de recommandation basés sur l'IA, là où ils sont utilisés. Une fenêtre de chat n'est pas une condition d'entrée.

Gardez les découvertes incertaines visibles. « Fonctionnalité IA à vérifier » est un statut temporaire acceptable. Exclure discrètement quelque chose parce que personne ne le comprend n'est pas une méthode de découverte.

De même, consignez les usages retirés ou bloqués comme tels. N'effacez pas leur existence au seul motif qu'ils ne correspondent plus à l'image approuvée.

Identifier ces systèmes est nécessaire. Ce n'est pas l'intégralité du travail.

L'outil est approuvé. L'usage ne l'est pas.

Retirez maintenant les comptes personnels de l'équation.

Imaginez que tout le monde utilise la plateforme d'entreprise approuvée. Les achats ont vérifié le contrat. La sécurité a examiné le déploiement. L'équipe privacy a évalué le traitement envisagé. Les accès sont gérés. Le système a un propriétaire.

Puis quelqu'un l'utilise à des fins qu'aucune de ces revues ne couvrait.

C'est ce que j'appelle la shady AI : un outil approuvé utilisé de manière non gouvernée ou inappropriée.

J'utilise cette distinction pour séparer deux problèmes qui méritent chacun une investigation : les outils que vous n'avez pas correctement recensés, et les usages qui échappent à la gouvernance au sein de votre environnement approuvé. Ce sont des étiquettes de travail, non un jugement sur les intentions des collaborateurs.

Considérez trois exemples fictifs.

Un assistant est autorisé pour la rédaction de communications internes générales. Un manager y télécharge des notes d'évaluation identifiables de collaborateurs et lui demande de recommander qui devrait être promu. Le produit est approuvé. Cette finalité et ces données ne faisaient pas partie de l'approbation.

Un assistant de réunion est autorisé pour les réunions de projet ordinaires. Quelqu'un le fait participer à une discussion confidentielle portant sur un grief d'un collaborateur, malgré une exclusion explicite. Même fournisseur, même compte, frontière différente.

Ou encore : un assistant de support client est approuvé pour rédiger des réponses, à condition qu'un agent les vérifie avant envoi. L'équipe continue de l'utiliser pour le support client. Personne n'ajoute de connecteur ni ne modifie le modèle. Elle se contente d'envoyer les brouillons sans effectuer les vérifications requises.

La shady AI n'est pas seulement un nouveau cas d'usage que personne n'a évalué. C'est aussi un cas d'usage approuvé dont les garde-fous ont été discrètement supprimés.

Le Playbook de NIST traite explicitement du détournement des systèmes et de la nécessité de définir le périmètre d'application et les responsabilités humaines. Vérifier un nom de produit sur une liste approuvée ne répond pas à ces questions. (NIST AI Resource Center)

Une approbation doit avoir un périmètre

« Approuvé » a besoin d'une deuxième phrase.

Approuvé pour quelles tâches ? Avec quelles informations ? Pour quels utilisateurs et destinataires ? Avec quelle autorité d'action ? Sous quels contrôles ?

Sans ces limites, à quoi exactement demande-t-on aux collaborateurs de se conformer ?

Vérifiez si les conditions ont été communiquées, si le workflow les rend praticables et si quelqu'un contrôle qu'elles sont respectées. Ne supposez pas que tout écart est malveillant. Ne supposez pas non plus qu'une absence d'intention malveillante rend l'écart inoffensif.

La liste des outils approuvés vous indique ce que les collaborateurs peuvent ouvrir. Elle ne dit pas ce qu'ils peuvent faire une fois que c'est ouvert.

Commencez par le travail. Puis vérifiez les journaux.

« Utilisez-vous l'IA ? » n'est pas la question par laquelle je commencerais.

Je poserais plutôt :

« Montrez-moi comment vous rédigez, résumez, traduisez, codez, classifiez ou formulez des recommandations aujourd'hui. Qu'est-ce qui vous aide à réaliser ce travail ? »

Puis demandez ce qui est téléchargé, collé, connecté ou généré en cours de route.

Menez ces entretiens avec les personnes qui font le travail, pas seulement avec les responsables de département. Interrogez-les sur les expérimentations et les comptes gratuits autant que sur les déploiements officiels. Utilisez des démonstrations anonymisées ; la découverte ne nécessite pas de copier des données clients dans vos notes.

Pour les outils approuvés, ajoutez une autre question :

« Qu'advient-il du résultat, et quels contrôles interviennent avant qu'une personne agisse dessus ? »

C'est là que commence l'investigation sur la shady AI. Un produit peut figurer dans tous les registres d'achat et être utilisé en dehors de ses limites autorisées.

Ensuite, confrontez les réponses aux preuves.

Examinez les achats, les notes de frais, les contrats et les questionnaires fournisseurs. Dans les limites de votre visibilité autorisée, consultez les inventaires d'applications, les intégrations d'identité, les paramètres d'administration SaaS, les extensions, les endpoints de modèles et les enregistrements de développement interne.

Investiguez les écarts. Un outil déclaré sans achat correspondant n'est pas automatiquement une réponse incorrecte. Une intégration que personne n'a mentionnée doit avoir un propriétaire. Une fonctionnalité activée appelle une discussion sur son utilisation réelle.

Une connexion à un service n'explique pas par elle-même la finalité métier ni ce qui a été soumis comme information. Consignez ce que vous avez vérifié, quand, ce que cela a révélé et ce qui reste incertain.

Expliquez l'exercice aux collaborateurs. Encouragez la déclaration sans promettre une immunité générale pour les usages abusifs. Convenez d'une approche de surveillance proportionnée avec les équipes privacy et juridique compétentes, y compris la consultation des représentants du personnel si nécessaire.

Limitez la collecte, contrôlez les accès et définissez les durées de conservation. Le principe de minimisation des données du GDPR s'applique également aux données personnelles collectées lors de la découverte. (EUR-Lex)

Ne résolvez pas la shadow AI en créant une surveillance fantôme.

Construisez un registre qui résiste à une question de suivi

Voici la structure de travail que j'utiliserais. Considérez-la comme un point de départ opérationnel, non comme la prétention que chaque référentiel prescrit exactement ces colonnes.

Gardez l'usage prévu, l'usage autorisé et la pratique observée distinguables. Sinon, l'entrée deviendra discrètement une copie supplémentaire de la politique.

N'ajoutez pas une vague colonne « Shady AI : oui/non » en considérant que le problème est traité. Consignez le périmètre, l'observation et l'écart.

Un exemple, trois réponses différentes

Prenons un déploiement fictif : AI-017, un assistant de rédaction pour le support client.

Maya, responsable du support, est propriétaire du cas d'usage. L'assistant utilise les tickets clients et une base de connaissances contrôlée pour produire des réponses en brouillon. Son intégration peut enregistrer des brouillons, mais ne peut pas les envoyer.

Le workflow autorisé exige qu'un agent de support vérifie l'exactitude et la pertinence de la réponse avant envoi.

Lors d'un audit fictif du workflow, l'agent génère une réponse et l'envoie sans en vérifier le contenu. La revue requise est devenue un simple clic.

La plateforme est approuvée. Le cas d'usage est autorisé. La condition d'utilisation n'est pas respectée.

Ce sont trois réponses différentes. Une cellule verte « Approuvé » ne peut pas les représenter toutes.

Consignez l'observation, investiguez la cause et assignez une action corrective. Puis vérifiez que l'étape de revue fonctionne en pratique, plutôt que de simplement envoyer un nouveau rappel.

Rendez les informations manquantes tout aussi explicites. « Conservation inconnue ; assignée au responsable fournisseur ; réponse attendue vendredi » est exploitable.

« Conservation : conforme » n'est pas une réponse, à moins que quelqu'un puisse expliquer ce que cela signifie et comment cela a été établi.

Inspirez-vous du célèbre SBOM. Construisez un AI-BoM.

Le software bill of materials, ou SBOM, part d'une idée utile : le nom du produit ne vous dit pas ce que le produit contient. Il répertorie les composants logiciels et leurs relations dans la chaîne d'approvisionnement. (NIST)

Un AI bill of materials, ou AI-BoM, étend ce travail de composition aux éléments spécifiques à l'IA. CycloneDX prend en charge les informations sur les modèles, les jeux de données, les configurations et les dépendances. La documentation IA de SPDX décrit également les relations impliquant des modèles, des données, des prompts et des agents. (CycloneDX)

Ce n'est pas votre tableur d'outils approuvés avec un nom de fichier plus impressionnant.

Distinguez bien trois livrables :

L'inventaire recense ce que l'organisation utilise, à quelle fin et sous la responsabilité de qui.

L'AI-BoM recense de quoi un système particulier est constitué et dont il dépend.

Le registre des risques recense ce qui pourrait mal tourner et ce que l'organisation fait pour y remédier.

Reliez-les. Ne les transformez pas en trois versions concurrentes de la réalité.

Commencez par un périmètre défini

Pour cet exercice, commencez par un système déployé précis. Donnez à son enregistrement de composition un identifiant, une révision, un environnement, une date et un mainteneur. Liez les SBOM logiciels existants et la documentation au niveau du modèle lorsqu'ils sont disponibles.

Précisez explicitement si l'enregistrement décrit l'ensemble du déploiement, un modèle ou le service d'un fournisseur.

Le document de modèle d'un fournisseur ne décrit pas l'intégration des tickets, le service de récupération et les droits d'accès que vos ingénieurs ont ajoutés autour de lui.

Pour une première version pratique, je capturerais ou référencerais les groupes suivants :

Ces groupes reflètent les relations de composition décrites par CycloneDX et SPDX. Mappez-les au format que vous utilisez ; conservez les détails complémentaires dans des enregistrements liés lorsque le format retenu ne les capture pas directement. (CycloneDX)

Consignez les relations, pas seulement les ingrédients

Pour AI-017, reliez l'intégration des tickets, le service de récupération depuis la base de connaissances, le modèle de génération hébergé, le template de prompt contrôlé et l'intégration de rédaction des brouillons.

Quel composant lit le ticket ? Quelle source est interrogée ? Quel modèle reçoit les informations assemblées ? Quel composant rédige le brouillon ?

Distinguez les données d'entraînement des informations récupérées ou fournies lors de l'utilisation. « Données » n'est pas une relation suffisamment précise.

Imaginez maintenant un changement de modèle ou une bibliothèque vulnérable dans le service de récupération. Les enregistrements liés devraient permettre d'identifier le déploiement concerné et son propriétaire sans relancer une découverte de zéro.

Collectez les preuves à partir des configurations de déploiement, des manifestes de dépendances, des registres de modèles et de la documentation fournisseur. Distinguez les faits vérifiés en interne des déclarations fournisseurs.

Lorsqu'un fournisseur ne divulgue pas la version exacte d'un modèle ou les jeux de données sous-jacents, consignez cette limitation. Capturez l'identifiant de service disponible, la date de documentation et les modalités de notification des changements. Ne fabriquez pas une précision qui n'existe pas.

Commencez par un tableau structuré si nécessaire, puis évoluez vers un format lisible par machine pris en charge par vos outils. Ne supposez pas qu'un tableur devient interopérable au seul motif que son nom de fichier contient « BOM ».

Ne laissez pas les identifiants d'accès, les informations clients brutes et les contenus confidentiels de jeux de données y figurer. Référencez plutôt des enregistrements contrôlés.

Les ingrédients peuvent rester inchangés tandis que l'usage dérape

Revenons à AI-017.

Le modèle, l'application et les intégrations restent inchangés. L'équipe cesse simplement de vérifier les brouillons.

L'AI-BoM n'a pas nécessairement changé. La pratique opérationnelle, si.

Liez l'enregistrement de composition aux cas d'usage autorisés, à leurs conditions et aux preuves du fonctionnement réel. Mettez à jour l'AI-BoM lorsque les composants ou configurations consignés changent. Réévaluez l'usage lorsque sa finalité, ses informations, ses destinataires ou ses garde-fous changent, même si le logiciel ne change pas.

Un AI-BoM complet ne peut pas vous dire si quelqu'un a effectivement lu la réponse avant de l'envoyer.

« Est-ce que ça s'entraîne sur nos données ? » n'est pas toute l'évaluation privacy

Posez la question de l'entraînement. Puis continuez.

Un engagement de non-entraînement ne répond pas à la question de savoir si les informations sont conservées pour la fourniture du service, stockées dans l'historique des conversations, accessibles au personnel de support ou transmises à un autre service. Traitez ces points comme des questions distinctes nécessitant des preuves.

Pour chaque cas d'usage, investiguez les prompts, les pièces jointes et les sources connectées. Suivez les sorties et les journaux. Établissez qui reçoit les informations et quelles sont les modalités de suppression vérifiées.

Pour les assistants capables d'agir, investiguez les droits d'action autant que les informations. Le système peut-il lire une boîte mail entière, mettre à jour un enregistrement client ou envoyer des données en dehors de l'organisation ?

L'analyse de la CNIL sur l'IA agentique souligne les complications créées par les sources de données connectées, la mémoire persistante, la circulation entre services et les actions déléguées. Apportez à la fonction privacy une description de ces opérations, pas seulement la page sécurité de l'éditeur. (CNIL)

C'est également là que la shady AI entre en jeu. Une évaluation portant sur la rédaction de communications internes générales ne décrit pas l'utilisation d'enregistrements d'évaluation de collaborateurs pour recommander des promotions.

Identifiez la finalité de traitement réelle, les parties prenantes concernées, la base légale applicable, les modalités de transparence et les éventuels transferts internationaux. Reliez l'inventaire aux enregistrements de traitement et aux évaluations privacy appropriés. (EUR-Lex)

L'inventaire et l'AI-BoM ne satisfont pas automatiquement ces exigences. L'article 30 du GDPR porte sur les registres des activités de traitement ; l'article 35 exige une DPIA lorsque le traitement est susceptible d'engendrer des risques élevés pour les droits et libertés des personnes. La mention de « IA » dans le nom du produit n'est pas, en elle-même, l'évaluation. (EUR-Lex)

Protégez également l'inventaire lui-même. Un registre décrivant des sources sensibles et des intégrations puissantes ne devrait pas devenir un répertoire accessible à l'ensemble de l'entreprise recensant des choses intéressantes à consulter.

« Découvert » ne signifie pas « approuvé »

Gardez le statut de découverte séparé de l'autorisation.

« Signalé par un département » et « vérifié dans la console d'administration » décrivent des preuves. « En cours d'examen », « autorisé avec restrictions », « suspendu » et « retiré » décrivent des décisions ou des états opérationnels.

La question de savoir si les conditions d'utilisation sont effectivement respectées appelle une autre réponse.

Un système peut être confirmé comme présent et rester inacceptable pour son usage actuel. L'ajouter au registre ne le légitime pas.

Orientez les découvertes vers une évaluation, avec des responsables et des dates nommés. Je prioriserais l'investigation lorsque l'usage implique des informations sensibles, des décisions à impact sur des personnes, des droits d'accès étendus ou des dépendances en production.

Pour la shady AI, décidez si la réponse requiert de clarifier les instructions, de rétablir un garde-fou, de restreindre les accès, d'évaluer un nouvel usage ou d'arrêter l'activité.

Lorsque des informations sont manquantes, décidez de ce qui peut se poursuivre pendant que la lacune est comblée. « En cours d'examen » ne doit pas signifier « continuer indéfiniment ».

Lorsque la découverte laisse supposer une exposition ou un incident, utilisez le processus de réponse existant. Compléter l'entrée de l'inventaire n'est pas une mesure de confinement. Les recommandations de gouvernance de NIST relient explicitement la surveillance de l'IA à la réponse aux incidents et à la responsabilité de traiter les problèmes. (NIST AI Resource Center)

Une fois les faits établis, reliez-les aux travaux de gestion des risques existants. Les articles sur la construction d'un registre des risques IA et l'intégration du risque IA dans le SMSI couvrent cette étape suivante. (Cyber Academy)

Une cellule verte est une décision que quelqu'un doit être en mesure d'expliquer.

Maintenez-le à jour, ou appelez-le un document historique

Désignez un gardien pour l'inventaire et des propriétaires métier pour ses entrées. Les propriétaires techniques doivent maintenir les preuves de composition et de configuration pertinentes. Le Playbook de NIST traite la propriété définie et la revue continue comme des activités de gouvernance, non comme un entretien optionnel après la collecte initiale. (NIST AI Resource Center)

Connectez les mises à jour aux changements qui nécessitent déjà une attention : nouveaux cas d'usage, fonctionnalités activées, changements de modèle, nouvelles sources de données, intégrations supplémentaires, permissions modifiées et retraits.

Incluez également les changements opérationnels. Supprimer une étape de revue ou modifier les destinataires d'un résultat peut justifier une réévaluation, même lorsque personne ne déploie de nouveau code.

Pour AI-017, passer de « enregistre des brouillons » à « envoie les réponses automatiquement » requiert une nouvelle décision. Découvrir que les agents envoient déjà des brouillons sans les vérifier exige une action immédiate, pas à la prochaine mise à jour logicielle.

Mettez à jour les enregistrements liés ensemble et conservez les versions précédentes pertinentes. Vous devez pouvoir établir ce qui était en place au moment d'un événement, pas seulement ce qui est configuré aujourd'hui.

Utilisez les revues périodiques pour détecter les changements passés inaperçus, non comme une permission d'ignorer tout ce qui survient entre deux revues.

Pour le reporting à la direction, présentez la propriété vérifiée, les évaluations en retard, les lacunes d'information non résolues et les écarts par rapport aux conditions approuvées. Décrivez le périmètre de vos travaux de découverte.

Soyez prudent avec « 100 % de l'IA inventoriée ». Compter tout ce qui figure déjà sur votre liste n'établit pas qu'il ne manque rien.

Commencez par l'inventaire. Puis connectez le reste.

Choisissez un département et parcourez son travail réel.

Consignez les systèmes et les usages. Vérifiez les propriétaires. Retracez les informations. Comparez les conditions approuvées avec la pratique observée. Construisez l'AI-BoM pour un déploiement significatif et reliez-le à l'inventaire.

Transformez les questions sans réponse en actions assignées.

Vous obtenez ainsi un point de départ que vous pouvez améliorer, et non une affirmation d'exhaustivité sans fondement.

La prochaine fois que quelqu'un demandera quels systèmes IA l'organisation utilise, vous devrez être en mesure de montrer ce que vous avez trouvé, de quoi cela dépend, qui en est responsable et ce qui reste à résoudre.

Vous pouvez également joindre la politique. Elle ne devrait simplement pas être votre seule réponse.

Pour les travaux de gouvernance plus larges, explorez mon AI Risk Governance Toolkit. Utilisez-le en complément de cette approche, avec les faits, les responsables et les décisions dont votre organisation a réellement besoin.

Explorer l'AI Risk Governance Toolkit →

Trouvez l'IA que personne n'a déclarée. Examinez l'IA que tout le monde a approuvée. Documentez ce dont les deux dépendent, et vérifiez comment les deux sont utilisées.