Blog
•
17 min de lecture
Un inventaire IA fondé sur la seule autodéclaration reste incomplet, car les systèmes les plus risqués sont précisément ceux que personne ne pense à déclarer : fonctionnalités d’IA intégrées à des logiciels déjà achetés, modèles intégrés aux services de prestataires et agents développés sur des plateformes internes. Un inventaire exploitable associe détection technique et déclaration structurée, consigne un ensemble minimal de champs par système et rapproche les deux en continu.
Pourquoi un questionnaire sur l’usage de l’IA sous-estime-t-il toujours la réalité ?
Le Work Trend Index 2024 de Microsoft et LinkedIn, une enquête menée auprès de 31 000 travailleurs du savoir dans 31 pays, a révélé que 78 % des utilisateurs d’IA apportaient leurs propres outils d’IA au travail et que 52 % des personnes utilisant l’IA au travail hésitaient à reconnaître qu’elles s’en servaient pour leurs tâches les plus importantes. Un questionnaire adressé à cette population ne peut, par construction, obtenir qu’une réponse partielle.
La réticence n’est qu’un mode de défaillance parmi d’autres. Chacun des cas suivants échappe à une enquête pour une raison différente.
Les fonctionnalités d’IA intégrées aux SaaS dont l’entreprise dispose déjà arrivent par une note de version, pas par un achat. Le CRM a ajouté le scoring des prospects, et personne ne présente son CRM comme un système d’IA lorsqu’on le lui demande.
Les abonnements individuels réglés par carte de frais sont comptabilisés comme logiciels, restent sous tous les seuils d’achat et ne sont déclarés que si le titulaire de la carte fait le lien entre un prélèvement mensuel de 20 dollars et la gouvernance.
Les modèles intégrés aux services de prestataires sont invisibles pour l’unité métier qui a acheté le service. Un prestataire chargé du tri des sinistres peut utiliser l’IA pour le compte de l’organisation, et selon l’article 3, point 4), de l’EU AI Act, l’organisme « utilisant sous sa propre autorité un système d’IA » est le déployeur, quel que soit celui qui l’a conçu.
Les agents développés sur des plateformes d’automatisation internes sont décrits par leurs créateurs comme des workflows. Un flux qui appelle un modèle puis écrit dans un système d’enregistrement est un agent, et aucune enquête sur les outils d’IA ne le détectera.
Les notebooks passés en production produisent des scores qu’un processus en aval exploite. Personne ne les a commandés, donc personne n’en est responsable, donc personne ne les déclare.
Le point commun : la personne qui pourrait déclarer un système ne le considère pas comme de l’IA, n’en est pas responsable ou a une raison de se taire. Tout le reste exige un signal qui ne dépend pas d’une personne. Le guide d’Enzai sur la détection et la gouvernance de l’IA fantôme explique en quoi l’IA fantôme diffère de l’informatique fantôme ; cet article porte sur la manière de la trouver.
Quelles méthodes de détection repèrent l’IA non autorisée, et quels sont leurs angles morts ?
Aucune méthode ne couvre à elle seule les modes de défaillance ci-dessus, et la question utile pour chacune n’est pas ce qu’elle trouve, mais ce qu’elle ne peut pas voir.
Méthode | Ce qu’elle trouve | Ce qu’elle ne voit pas |
|---|---|---|
Analyse du trafic réseau et API (journaux DNS, proxy, trafic sortant) | Appels directs depuis le réseau de l’entreprise vers des points de terminaison connus de fournisseurs de modèles et de SaaS d’IA ; volume et fréquence par source | Les appels côté serveur effectués par un prestataire pour votre compte peuvent lui échapper, de même que le trafic sur les appareils personnels, les réseaux domestiques et les données mobiles ; certains outils manquent aussi l’IA intégrée à un domaine SaaS approuvé que vous autorisez déjà |
Revue des autorisations SSO et OAuth (journaux du fournisseur d’identité) | Applications d’IA connectées aux comptes de l’entreprise, périmètres accordés (messagerie, fichiers, agenda) et auteurs de ces autorisations | Usage via des comptes personnels sans connexion d’entreprise ; développements internes qui ne passent jamais par le fournisseur d’identité ; le modèle derrière une application qui s’est authentifiée sous une autre identité |
Données de notes de frais et d’achats | Abonnements individuels payants, licences par département, renouvellements de contrats dont le prestataire a depuis ajouté de l’IA | Offres gratuites ; IA ajoutée à un produit après l’achat ; prestataires qui ne présentent pas leur service comme de l’IA sur la facture |
Analyse des environnements cloud (comptes, plateformes de ML, points de terminaison de modèles) | Points de terminaison de modèles déployés, tâches d’entraînement, bases vectorielles, comptes de service détenant des clés de fournisseurs de modèles, notebooks planifiés | Tout ce qui se trouve hors des comptes cloud que vous recensez ; l’IA hébergée en SaaS ; les serveurs départementaux sur site |
Analyse du code et des dépôts | Imports de SDK de fournisseurs de modèles, clés d’API intégrées au code, dépendances à des frameworks d’agents, fichiers de prompts versionnés dans les dépôts | Plateformes d’automatisation low-code et no-code ; tout ce qui n’est pas dans un dépôt analysé ; la configuration d’exécution qui détermine si le code est réellement actif |
CASB et outils de sécurité SaaS | Applications SaaS utilisées, y compris les applications d’IA non autorisées, avec l’activité par utilisateur et les volumes de données transférés | Les fonctionnalités d’IA des applications autorisées ; les agents internes ; le contexte de gouvernance (responsable, finalité, décisions concernées) qu’un outil de sécurité n’est pas conçu pour consigner |
Autodéclaration structurée | Finalité, responsable, données utilisées et décisions concernées : les champs qu’aucun signal technique ne peut fournir | Tout ce que le répondant ne reconnaît pas comme de l’IA, dont il n’est pas responsable ou qu’il préfère ne pas nommer |
Les angles morts diffèrent : un système repéré par deux signaux constitue donc une fiche confirmée, et un système repéré par un seul, une piste à vérifier. L’autodéclaration cesse d’être l’inventaire pour devenir l’étape d’enrichissement : les signaux techniques établissent qu’un système existe, et le responsable apporte ce que seule une personne sait. L’IA côté prestataire, lorsque le modèle s’exécute dans l’environnement du prestataire, est la seule catégorie qu’aucun signal technique n’atteint ; les questionnaires prestataires et la revue des contrats restent donc sur la liste.
Comment détecter spécifiquement les agents d’IA ?
Les agents laissent d’autres traces que les outils. Une personne qui utilise un assistant IA apparaît sous forme de domaine dans le journal du proxy ou d’application dans le fournisseur d’identité. Un agent apparaît sous forme d’identité non humaine : un compte de service détenant une clé d’API de fournisseur de modèles, un outil enregistré dans un framework d’agents, une tâche planifiée qui appelle un modèle, puis autre chose.
Les signaux sont la liste des identités non humaines du fournisseur d’identité et des ressources auxquelles elles ont accès, l’inventaire des secrets des comptes cloud limités aux fournisseurs de modèles, les journaux des connecteurs des plateformes d’automatisation et l’analyse des dépôts à la recherche de frameworks d’agents. L’indice révélateur : un appel de modèle suivi d’une action sur sa sortie, sans intervention humaine entre les deux.
Les agents délèguent aussi à d’autres agents. Dès qu’une organisation en compte plus d’une poignée, un maillage d’agents se forme, dans lequel les agents se découvrent et se transmettent du travail via une infrastructure partagée. Détecter ce maillage, c’est cartographier quelles identités non humaines appellent lesquelles, afin qu’une seule fiche montre les appelants en amont d’un agent et ses cibles en aval. Les contrôles qui en découlent sont présentés dans le guide d’Enzai sur la gouvernance de l’IA agentique.
Quelle est la fiche d’inventaire minimale exploitable ?
Le modèle complet, avec une quarantaine de champs, figure dans le guide de création d’un inventaire IA. La question ici est le plancher : la plus petite fiche qui permette encore une décision de gouvernance. Neuf champs passent ce test.
Champ | Pourquoi c’est le minimum | Exemple de valeur |
|---|---|---|
Responsable | Sans personne responsable, rien d’autre dans la fiche ne peut être vérifié ni mis à jour | Responsable des opérations sinistres |
Finalité | Détermine les catégories réglementaires applicables et si l’usage est conforme à la politique | Trier les déclarations de sinistre entrantes selon leur complexité probable |
Données concernées | Les données personnelles, les catégories particulières de données, les données confidentielles et les données clients déclenchent chacune des obligations différentes | Récits de sinistre, identifiants des assurés |
Modèle et version | Les preuves sur le comportement ne valent que pour la version testée ; les mises à jour du prestataire les invalident | Modèle de fondation hébergé par le prestataire, version figée en mars 2026 |
Niveau d’autonomie | Selon qu’une personne agit sur la sortie, la vérifie ou est entièrement contournée, l’ensemble des contrôles change | Recommande l’orientation ; le gestionnaire de sinistres confirme |
Décisions en aval concernées | Les décisions déterminantes concernant des personnes (crédit, assurance, emploi) emportent des obligations légales, quel que soit le modèle | Attribution des sinistres ; aucune décision de couverture |
Référentiels applicables | Les régimes et normes dont relève le système, et la justification de la classification | EU AI Act, annexe III, point 5 c), en cours d’examen ; ISO/IEC 42001 dans le périmètre |
Niveau de risque | La hiérarchisation propre à l’organisation, qui détermine la profondeur et la fréquence des revues | Niveau 2 |
Liens vers les preuves | L’emplacement de l’évaluation, de l’approbation, des résultats de tests et de la documentation du prestataire | Liens vers la fiche d’approbation et l’accord de traitement des données du prestataire |
Chaque fiche est une affirmation étayée. « Ce système présente un risque limité » est une assertion ; la même affirmation accompagnée d’un responsable, d’une finalité, d’un champ de données et d’un lien vers l’évaluation est une preuve. L’article 26 de l’EU AI Act montre pourquoi ces champs ne sont pas facultatifs : le paragraphe 2 impose un contrôle humain par des personnes compétentes (les champs responsable et niveau d’autonomie), et le paragraphe 6 exige la conservation des journaux pendant au moins six mois (les champs version du modèle et preuves). L’inventaire IA d’Enzai repose sur la même structure de fiche : responsable, finalité, références du prestataire et du modèle, niveau d’autonomie, niveau de risque, référentiels associés et preuves d’évaluation pour chaque entrée, la sensibilité des données étant gérée comme une étiquette.
Quelles réglementations et normes exigent un inventaire IA ?
Peu de régimes emploient le mot inventaire. La plupart imposent des obligations impossibles à respecter sans inventaire.
Régime | Disposition | Ce qu’elle présuppose |
|---|---|---|
EU AI Act, article 4 (maîtrise de l’IA) | Applicable depuis le 2 février 2025, en vertu de l’article 113, point a). Dans sa rédaction issue du règlement (UE) 2026/1744, les fournisseurs et les déployeurs « prennent des mesures pour favoriser le développement de la maîtrise de l’IA de leur personnel et des autres personnes s’occupant du fonctionnement et de l’utilisation des systèmes d’IA pour leur compte » | Savoir quels membres du personnel utilisent quels systèmes d’IA |
EU AI Act, article 26 (obligations des déployeurs de systèmes d’IA à haut risque) | Notice d’utilisation, contrôle humain attribué, surveillance, conservation des journaux pendant au moins six mois, information des travailleurs. Systèmes relevant de l’annexe III à partir du 2 décembre 2027 ; systèmes relevant de l’annexe I à partir du 2 août 2028 | Une fiche par système d’IA à haut risque, avec responsable, modalités de contrôle humain et emplacement des journaux |
Article 4.3 (domaine d’application du système de management de l’IA), 6.1.2 (appréciation des risques liés à l’IA) et 6.1.4 (évaluation de l’impact des systèmes d’IA) ; parmi les mesures de l’annexe A (référence normative) figure la documentation des ressources utilisées par chaque système d’IA | Un ensemble recensé de systèmes d’IA à l’intérieur du périmètre du système de management | |
NIST AI RMF 1.0, GOVERN 1.6 | « Des mécanismes sont en place pour inventorier les systèmes d’IA et sont dotés de ressources en fonction des priorités de risque de l’organisation. » La fonction MAP documente ensuite la finalité prévue et le contexte de chaque système (MAP 1.1) | Un inventaire comme intrant des fonctions MAP, MEASURE et MANAGE |
OMB M-25-21, 3 avril 2025 | Chaque agence fédérale, à l’exception du ministère de la Défense et de la communauté du renseignement, « doit inventorier ses cas d’usage de l’IA au moins une fois par an, soumettre l’inventaire à l’OMB et en publier une version publique sur le site web de l’agence » | Un inventaire des cas d’usage, les qualifications à fort impact étant suivies par le Chief AI Officer |
Colorado, SB 26-189, promulguée le 14 mai 2026 | Abroge et réédicte la SB 24-205. Les obligations s’appliquent à partir du 1er janvier 2027 : information au point d’interaction avec une technologie de prise de décision automatisée couverte, explication et examen humain après des décisions déterminantes défavorables, conservation des dossiers pendant au moins trois ans. Aucune obligation d’inventaire | Savoir quels systèmes prennent des décisions déterminantes concernant les consommateurs du Colorado |
Les numéros des mesures de l’annexe A de l’ISO/IEC 42001 ne sont pas publiés sur iso.org et ne sont pas cités ici. L’entrée du glossaire d’Enzai consacrée à OMB M-25-21 présente plus en détail ce mémorandum fédéral.
Comment un inventaire IA reste-t-il à jour après le premier recensement ?
Un inventaire se dégrade selon trois mécanismes, chacun appelant sa propre parade.
Le premier est une détection non rapprochée. Chaque signal produit des candidats, et si ces candidats restent dans un tableur à côté de l’inventaire, les deux divergent en un trimestre. Chaque candidat doit être rattaché à une fiche existante, fusionné comme doublon ou ouvert comme nouvelle fiche marquée sans responsable, avec une échéance pour en désigner un. Le nombre de fiches sans responsable depuis plus de trente jours est le premier indicateur de santé.
Le deuxième est l’érosion de la responsabilité. Les responsables changent de poste et partent. Si le champ responsable contient un nom en texte libre, l’inventaire est obsolète le jour où les RH traitent le départ. Rattacher le responsable à une identité de l’annuaire, pour qu’un départ déclenche une réattribution, donne tout son sens à ce champ.
Le troisième, ce sont les changements que l’inventaire ne voit pas. Un prestataire met à jour le modèle de base d’une fonctionnalité intégrée ; un agent obtient un nouvel outil ; une autorisation OAuth s’étend à un périmètre plus large. Le guide existant liste les déclencheurs métier ; les déclencheurs techniques sont les signaux du premier jour, exécutés en continu et comparés au dernier état connu. Le deuxième indicateur de santé est le délai entre la première apparition d’un signal et l’existence d’une fiche. Le troisième est le ratio entre les systèmes trouvés par la détection et ceux déclarés via le processus de demande : si la détection trouve sans cesse ce que le processus de demande n’a jamais vu, c’est ce processus qui est défaillant, et le guide du processus de demande est le point de départ. Une supervision continue de l’IA de ce type est le principe même de l’inventaire d’Enzai, qui se met à jour au fil des évolutions du parc et se synchronise avec AWS, Azure, GCP, Databricks, watsonx et Snowflake pour la découverte des actifs.
Que faire de l’IA que vous trouvez ?
La première fois qu’un outil non autorisé est trouvé, il est facile à trouver, car il a laissé une trace : une ligne de note de frais, une autorisation OAuth, un domaine dans le journal du proxy. Si la conséquence est le retrait ou une sanction, la deuxième vague se déplace vers les comptes personnels, les appareils personnels et les réseaux domestiques, qu’aucun des signaux ci-dessus ne peut voir. Commencer par sanctionner rend invisible une population jusque-là visible.
L’alternative est une amnistie limitée dans le temps, assortie d’un engagement de délai. Chaque outil déclaré reçoit une fiche d’inventaire et une décision dans un délai annoncé : approuver, approuver sous conditions, remplacer par un équivalent autorisé ou retirer. La personne qui l’a déclaré reçoit la décision, pas un numéro de dossier. Les sanctions sont réservées à la période qui suit l’amnistie et aux violations de la classification des données, qui sont des infractions que l’IA soit en cause ou non. Le guide sur l’IA fantôme traite du chemin balisé et de la conception des règles d’usage acceptable.
Si les outils déclarés attendent des mois une décision, les déclarations cessent. Le processus de demande de cas d’usage IA d’Enzai est conçu pour ce schéma : l’IA déjà utilisée qui n’est jamais passée par le processus de demande peut être intégrée à la gouvernance sans recherche de coupable, les cas à faible risque suivent une voie accélérée et les cas approuvés entrent dans l’inventaire avec leur justification consignée. C’est la forme opérationnelle de l’adoption de l’IA.
Que rechercher dans un outil de détection de l’IA non autorisée ?
Huit critères distinguent un outil de détection qui produit une liste d’un outil qui produit un inventaire.
Plus d’un signal de détection, clairement nommé. Demandez lesquelles des sept méthodes ci-dessus l’outil exécute lui-même et lesquelles il se contente d’ingérer. Un outil à signal unique hérite des angles morts de ce signal.
Corrélation en une seule fiche. Trois signaux concernant un même système doivent produire une fiche, pas trois alertes.
Couverture de l’IA intégrée et de l’IA des prestataires, pas seulement des domaines d’IA grand public, car ce sont précisément les modes de défaillance qu’une liste de blocage de domaines ne voit jamais.
Identités non humaines dans le périmètre. Un outil qui ne voit pas les comptes de service et les clés d’API ne peut pas trouver d’agents.
Un résultat sous forme de fiche de gouvernance : une entrée avec un responsable, un niveau de risque et une correspondance des référentiels, et non un événement de sécurité en attente de tri.
Des preuves rattachées à chaque système, pour que l’évaluation, l’approbation et la documentation du prestataire accompagnent la fiche jusqu’à l’audit.
Des transferts vers les outils où le travail se fait : outils de ticketing pour l’attribution des responsables, plateformes cloud et de ML pour la découverte des actifs.
Un processus de demande proportionné, pour que la découverte d’un système débouche sur une décision le concernant.
Les outils de sécurité réseau méritent qu’on leur rende justice. Les CASB et les solutions SSE (secure service edge) excellent à repérer l’usage des SaaS, à bloquer l’exfiltration et à appliquer les politiques en périphérie. Ce qu’ils produisent est un événement de sécurité portant sur un domaine ou une application ; la fiche de gouvernance est un autre livrable, et la question décisive pour la présélection est de savoir quel outil la produit. L’inventaire d’Enzai combine détection de l’IA, imports depuis les plateformes et demandes de cas d’usage, associe automatiquement chaque système à l’EU AI Act, à l’ISO 42001 et au NIST AI RMF, et transmet le travail à Jira, ServiceNow et Slack. La position d’une organisation sur un modèle de maturité de la gouvernance détermine combien des huit critères lui sont nécessaires dès le premier jour ; l’automatisation du workflow de gouvernance devient prioritaire dès que le parc dépasse ce qu’un tableur peut gérer, le moment où s’installe la prolifération de l’IA.
Ce que cela signifie sur le plan opérationnel
Pour une équipe de gouvernance qui part d’une liste autodéclarée, ou de rien :
Exécutez une fois, en parallèle, chaque signal de détection auquel vous avez accès, puis rapprochez les candidats en une seule liste. Notez quel signal a trouvé chaque système et si un autre l’a confirmé ; les découvertes issues d’un seul signal vous indiquent quels signaux maintenir en continu.
Ouvrez une fiche pour chaque candidat avec les neuf champs minimaux. Tolérez les champs vides partout sauf pour le responsable et la finalité, et fixez une échéance de trente jours pour désigner un responsable pour toute fiche qui n’en a pas.
Annoncez l’amnistie avec l’engagement de délai de décision, et faites passer chaque déclaration par le processus de demande pour qu’elle aboutisse à une fiche d’inventaire assortie d’une date de décision.
Présentez chaque mois les trois indicateurs d’actualité (fiches sans responsable depuis plus de trente jours, délai entre signal et fiche, ratio entre systèmes détectés et déclarés) au comité en charge des risques liés à l’IA.
Associez chaque fiche aux obligations qui s’y appliquent, en commençant par les articles 4 et 26 de l’EU AI Act, le périmètre ISO/IEC 42001 et NIST GOVERN 1.6, afin que l’inventaire constitue le socle de preuves pour chaque référentiel.
L’inventaire IA d’Enzai est conçu pour les étapes un, deux et cinq : une découverte multi-méthodes consolidée en une fiche par système, avec la correspondance des référentiels et la piste de preuves associées. Pour le voir appliqué à votre propre parc, échangez avec l’équipe Enzai.
Certifié ISO 27001 depuis 2023, audité chaque année par NQA
Traitement des données aligné sur le RGPD
Données clients hébergées sur AWS dans plusieurs régions
Utilisez votre propre modèle d’IA via une connexion privée
Identifiez l’IA utilisée par vos équipes, examinez-la avant sa mise en service, évaluez-la au regard des règles applicables et contrôlez ce que les agents peuvent faire. Conçu pour les organisations réglementées.