La surveillance de l’IA a trois points aveugles — et la plupart des entreprises ne surveillent aucun d’entre eux

La plupart des conversations sur la sécurité de l’IA au sein des entreprises sont axées sur la mauvaise cible. Les équipes passent des semaines à discuter du modèle à utiliser, puis branchent ce modèle à leur messagerie, à leurs paiements, à leur base de données client et à leur code, sans s’arrêter pour poser une question beaucoup plus simple : quand cette chose fait quelque chose, qui la surveille, et peut-on l’arrêter ?

Les chiffres indiquent que cela va bientôt devenir coûteux. Gartner estime qu’au moins 15 % des décisions de travail routinières seront prises de manière autonome par l’IA en 2028, contre presque aucune en 2024. Dans la même étude, il avertit que plus de 40 % des projets d’IA agente seront annulés d’ici la fin de 2027, et l’une des raisons qu’il donne est le contrôle des risques faible. Relisez cela. Les projets ne meurent pas parce que les modèles sont mauvais. Ils meurent parce que personne n’a construit un moyen de les gouverner.

Je construis des systèmes de gouvernance pour l’IA pour gagner ma vie, donc je vois les mêmes lacunes à plusieurs reprises. Il y en a trois. La plupart des entreprises ne surveillent aucun d’entre eux correctement, et beaucoup ne surveillent aucun d’entre eux.

Les agents sont les plus bruyants

Tout le monde s’inquiète des agents autonomes, et ils ont raison de s’inquiéter. Mais la plupart des gens s’inquiètent de la mauvaise partie. La chose dérangeante à propos d’un agent est qu’il agit. Il ne propose pas le remboursement ; il le paie. Il ne rédige pas l’e-mail ; il l’envoie. Donnez à un modèle un ensemble d’outils et vous lui avez donné la capacité de toucher à des systèmes réels et de les modifier.

Si vous vous trompez, l’échec n’est pas une phrase maladroite. C’est de l’argent qui s’en va, ou une table qui disparaît discrètement d’une base de données. Et il y a un bord plus tranchant. L’injection de prompte se situe tout en haut de la liste des risques pour les applications LLM de l’OWASP, et pour bonne raison : alimentez un modèle avec le mauvais texte et il peut être convaincu de faire quelque chose que personne ne lui a demandé de faire. Lorsque le modèle ne peut que parler, c’est une nuisance. Lorsque le modèle peut appeler des outils, c’est un attaquant qui détient vos clés API.

La réponse standard est d’enregistrer tout ce que l’agent fait et de regarder les traces. Très bien. Mais une trace est une description de quelque chose qui s’est déjà produit. C’est la vidéo de surveillance après que la caisse a été vidée, utile pour l’enquête, inutile pour arrêter le vol.

Le silencieux que personne ne mentionne

Le deuxième point aveugle n’apparaît jamais sur une diapositive, car c’est ennuyeux. C’est l’appel d’API ordinaire. Pas un agent, pas un cadre, juste un morceau de code quelque part dans un service qui assemble une invite et la lance à un modèle.

La plupart de l’IA en production ressemble à cela, et c’est la partie la moins réglementée de l’ensemble de la pile, précisément parce que c’est si ordinaire. C’est une requête HTTP enfouie trois couches plus bas dans un service, écrite par un ingénieur qui n’a jamais entendu parler de votre politique d’IA et ne sait pas où la trouver. Cet appel unique peut expédier les données d’un client à un modèle tiers, ou déclencher une action en aval, et rien ne vérifie s’il le devrait, et rien d’indépendant n’écrit qu’il l’a fait.

Le désordonné, c’est les gens

Le troisième point aveugle, c’est les gens, c’est pourquoi c’est le pire. Votre personnel a découvert il y a des mois que coller une tâche dans ChatGPT ou Claude le fait plus rapidement, donc ils le font toute la journée, généralement à partir de comptes personnels que vous ne pouvez pas voir. Ce n’est pas hypothétique. L’examen de l’utilisation réelle sur le lieu de travail par Cyberhaven a constaté qu’une part réelle des employés ont collé des données confidentielles de l’entreprise dans ChatGPT, la plupart du temps via des comptes que l’entreprise n’a pas de fenêtre pour voir.

Si vous voulez l’histoire de mise en garde, c’est Samsung. En 2023, il a interdit l’IA générative à l’interne après que des ingénieurs aient collé du code source propriétaire dans ChatGPT, trois fois en moins d’un mois. Ce n’étaient pas des acteurs malveillants. Ce étaient de bons ingénieurs qui essayaient de déboguer plus rapidement. C’est tout le piège : la fuite ressemble à la productivité. Et vos anciens outils de perte de données ne la détecteront pas, car c’est une copie-coller dans un onglet de navigateur, et non un fichier qui quitte le bâtiment.

Qu’est-ce qui fonctionne vraiment

Alignez les trois et la solution cesse d’être spécifique aux agents et devient une idée unique : gouverner ce que fait l’IA avant qu’il ne le fasse, et non après. Quelques choses qui ont vraiment de l’importance, apprises principalement à la dure.

Asseyez-vous devant l’action, et non derrière. C’est tout le jeu, et c’est pourquoi j’insiste sur le fait que l’observabilité et la gouvernance ne sont pas le même mot. Un tableau de bord qui vous indique qu’un agent a déplacé 40 000 £ hier est un rapport de perte. Quelque chose qui peut retenir ce transfert pour que l’humain le regarde avant qu’il ne parte est un contrôle. Si votre configuration ne peut vous dire que ce qui s’est passé, vous n’avez pas de surveillance. Vous avez de l’hindsight.

Utilisez un point de contrôle, et non un par outil. Les agents, les appels d’API et le personnel qui colle dans un chatbot ressemblent à trois problèmes distincts, donc les entreprises achètent trois outils distincts et se retrouvent avec trois ensembles de lacunes entre eux. Les choses mauvaises vivent dans les lacunes. Tout ce que fait l’IA, où que cela vienne, devrait passer par la même porte.

Gardez un journal que l’IA ne peut pas réécrire. Si le système qui fait la chose est également la seule chose qui l’enregistre, vous n’avez pas d’enregistrement. Vous avez un journal qu’il est autorisé à éditer. C’est exactement où les règles sont en train d’aller. L’exigence de tenue de registre de l’Acte européen sur l’IA, l’article 12, existe afin que ce qu’a fait un système à haut risque puisse être reconstruit par quelqu’un d’autre que le système. Dans la pratique, cela signifie un journal conservé en dehors de la chose enregistrée, qui ne peut pas être modifié discrètement après coup.

Mettez un humain sur les appels importants et irréversibles. Pas tout, faites cela et vous noierez les gens dans les approbations jusqu’à ce qu’ils approuvent tout. Mais les appels que vous ne pouvez pas reprendre, déplacer de l’argent, exporter des données, supprimer des enregistrements, devraient s’arrêter et attendre. L’Acte européen sur l’IA rend déjà la surveillance humaine obligatoire pour les systèmes à haut risque, l’article 14. La prise de conscience qui vaut la peine de se souvenir est que la surveillance ne compte que si la personne a le temps et le contexte pour dire vraiment non. Une approbation que personne ne lit est juste du théâtre.

La vérification honnête

Aucun de ces trois n’est un cas de coin. Ce sont la façon ordinaire dont la plupart des entreprises exécutent l’IA en ce moment, discrètement, sans beaucoup de filet de sécurité. Les équipes qui traverseront les prochaines années sans incident laid ne seront pas celles qui ont les graphiques les plus beaux. Ce seront celles qui ont décidé tôt que tout ce que fait leur IA, l’agent, l’appel d’API, le paragraphe collé, passe par une porte avant qu’il ne se produise, et non après.

Si vous voulez un test rapide de votre propre configuration, répondez honnêtement à deux questions. De ces trois surfaces, combien pouvez-vous vraiment voir ? Et de ceux que vous pouvez voir, combien pouvez-vous arrêter ? Pour de nombreuses entreprises, la réponse honnête à la deuxième question est zéro. C’est le nombre à corriger en premier.