Le dossier de sécurité de l’IA devient une exigence de sécurité d’entreprise
La question la plus utile pour un programme IA d’entreprise n’est plus « Ce modèle est-il sûr ? » mais « Pouvons-nous démontrer pourquoi cette action spécifique activée par l’IA est suffisamment sûre, ici, pour cet utilisateur, avec ces données et ces permissions ? »
Cette distinction est importante. La semaine dernière, la conversation sur la sécurité autour de l’IA s’est affinée autour des capacités des modèles et des risques cyber. En parallèle, l’ISACA a souligné un échec d’entreprise plus familier : l’adoption va plus vite que la gouvernance, la sécurité et la valeur métier mesurable. Ces deux signaux pointent vers le même écart opérationnel. Les organisations tentent de gérer des systèmes IA dynamiques avec des processus d’approbation statiques.
Une politique peut indiquer que les données sensibles ne doivent pas entrer dans des outils IA publics. Un registre des risques peut noter qu’un assistant peut halluciner. Aucun ne prouve qu’un agent client a été empêché d’émettre un remboursement, d’utiliser un connecteur privilégié ou de récupérer un document hors de son périmètre prévu un mardi après-midi.
Ce dont les entreprises ont besoin, c’est d’un dossier de sécurité IA : un argument étayé par des preuves qu’un cas d’usage IA particulier a des limites définies, des contrôles appropriés et un propriétaire opérationnel crédible. Ce n’est pas de la paperasse pour la paperasse. C’est ainsi que la gouvernance devient testable par les équipes sécurité et que les équipes métier peuvent continuer à avancer.
Pourquoi l’assurance au niveau du modèle ne suffit pas
Les fournisseurs peuvent publier des résultats d’évaluation, des résumés d’équipes rouges et des déclarations sur la gestion des risques cyber. Ce sont des entrées utiles. Elles ne constituent pas la ligne d’arrivée pour un client entreprise.
Le risque que porte votre organisation est créé par le système autour du modèle : les prompts, les sources de récupération, les permissions des outils, le contexte d’identité, le comportement des employés, le workflow en aval et la surveillance. Un modèle généralement capable connecté à une base de connaissances en lecture seule est une proposition très différente du même modèle connecté à la paie, aux dossiers clients et à la capacité d’envoyer des messages à l’extérieur.
C’est pourquoi « modèle approuvé » devient une catégorie de gouvernance trompeuse. Un modèle peut être approuvé pour rédiger des contenus internes tandis que l’agent construit dessus n’est pas approuvé pour déclencher un workflow contractuel. La décision de contrôle appartient au niveau du cas d’usage et de l’action.
C’est aussi là que l’IA fantôme revient. Lorsque les outils sanctionnés sont lents à obtenir, mal expliqués ou trop restrictifs pour le travail courant, les équipes trouveront des alternatives. Un inventaire qui ne suit que les plateformes IA achetées ignore les outils basés sur navigateur, les comptes personnels, les copilotes intégrés et les petits workflows d’agents assemblés par les utilisateurs métier. Vous ne pouvez pas construire un dossier de sécurité crédible pour des systèmes que vous n’avez pas découverts.
Le dossier de sécurité IA minimum viable
Ne commencez pas par un modèle de 60 pages. Commencez par un document d’une page qui impose les bonnes décisions avant qu’un cas d’usage n’atteigne la production. Pour chaque système ou agent IA, capturez cinq éléments.
1. La tâche délimitée
Décrivez le résultat métier et la limite d’action en langage clair. « Répondre aux questions de politique RH en utilisant la base de connaissances RH approuvée » est délimité. « Aider les RH à automatiser le travail » ne l’est pas.
Un test utile est de savoir si un approbateur non technique peut identifier ce que le système ne doit jamais faire. Si la réponse est vague, l’équipe de mise en œuvre prendra cette décision par défaut.
2. Le chemin des données et des identités
Enregistrez quelles informations entrent dans le système, où elles sont stockées ou traitées, ce qu’il peut récupérer et sous quelle identité il opère. Traitez chaque connecteur comme une autorisation, pas un détail d’intégration.
Pour un agent, distinguez la personne demandant une action, le compte de service qui l'exécute et les sources de données interrogées. Les identifiants partagés et les comptes de service larges transforment une petite erreur d'IA en un incident de sécurité majeur.
3. Les modes de défaillance prévisibles
Listez les façons dont le système pourrait être erroné, manipulé ou sur-permissionné dans le flux de travail réel. Incluez l'injection de prompt via le contenu récupéré, les fuites de données, les recommandations incorrectes, le mauvais usage des outils, les communications externes non approuvées et les échecs de la revue humaine.
Indiquez ensuite le contrôle préventif et le signal de détection pour chaque scénario sérieux. « Les utilisateurs seront prudents » ne suffit pas.
4. Les contrôles décisionnels
Précisez ce que le système peut faire automatiquement, ce qui nécessite une confirmation et ce qui reste interdit. Les actions à fort impact ou irréversibles doivent avoir des voies d'escalade explicites. Un bon contrôle est observable et applicable : permissions API limitées, porte d'approbation, limite de transaction, liste de blocage, liste blanche de récupération ou point de contrôle humain obligatoire.
C’est là que beaucoup de programmes confondent accès et gouvernance. L’authentification unique est précieuse, mais elle ne définit pas quelles actions sont sûres. La journalisation est utile, mais elle n’empêche pas une action dangereuse avant qu’elle ne se produise.
5. Les preuves opérationnelles
Nommez un responsable, la cadence de revue, les tests requis avant la mise en production et la télémétrie qui révélera les dérives. Pour les agents, capturez les appels d’outils, les échecs, les dérogations, les actions refusées et les modifications importantes des prompts, modèles ou données connectées.
Si vous ne pouvez pas expliquer comment le cas sera réévalué après une mise à jour du fournisseur ou l’ajout d’un nouveau connecteur, ce n’est pas un cas de sécurité. C’est une checklist de lancement.
Faites du cas de sécurité une partie de la livraison, pas une file d’attente de comité
L’objection courante est la rapidité. Les équipes craignent que la gouvernance ralentisse l’adoption, alors elles construisent d’abord et demandent l’approbation après. En pratique, ce schéma produit le résultat le plus lent : retouches tardives, exceptions de sécurité, propriété floue et un patrimoine fantôme croissant.
La meilleure approche est une assurance par paliers. Les assistants internes à faible risque et en lecture seule peuvent suivre un chemin léger avec des contrôles standards. Les systèmes manipulant des données sensibles, prenant des décisions externes, exécutant des transactions ou utilisant un accès large aux outils doivent déclencher une revue approfondie et des preuves renforcées. Le principe est simple : la charge d’assurance doit augmenter avec la conséquence d’une erreur.
Cela permet aux équipes de sécurité de se concentrer sur la minorité de cas d’usage nécessitant vraiment un examen tout en offrant aux équipes métier une voie claire et rapide pour le travail ordinaire. Cela produit aussi des décisions compréhensibles. « Approuvé pour résumer des documents dans cet espace de travail, pas pour envoyer des emails ou accéder aux dossiers clients » est plus exploitable qu’une politique générique.
Commencez par la visibilité
Un cas de sécurité ne peut pas réparer une utilisation invisible de l’IA. Commencez par établir un inventaire actuel sur les plateformes sanctionnées, l’activité navigateur, les journaux d’identité, les intégrations SaaS et les automatisations métier. Puis associez chaque cas d’usage découvert à un responsable et un niveau de risque.
Aona aide les entreprises à découvrir l’IA fantôme, comprendre où l’IA est utilisée et appliquer une gouvernance pratique avant qu’un outil non suivi ne devienne un incident. L’objectif n’est pas de bloquer l’IA utile. C’est de faire de la voie sûre la voie facile.
Si votre programme IA compte plus d’agents, copilotes et connecteurs que vous ne pouvez décrire avec confiance, commencez par une évaluation de visibilité. Découvrez comment Aona aborde la gouvernance de l’IA et la découverte de l’IA fantôme, puis construisez des cas de sécurité autour des systèmes les plus importants.
