Et si la vraie faiblesse de l’IA venait de sa mémoire

La mémoire de l’agent doit être traitée comme une base de données de premier ordre et régie.

L’IA fonctionne grâce aux données. En tant que leaders en quête d’efficacité et d’innovation, il y a une chose fondamentale à comprendre : la mémoire n’est pas seulement une caractéristique de vos systèmes d’IA, c’est le fondement de la façon dont ils apprennent, s’adaptent et agissent.

Nous sommes entrés dans un nouveau cycle où les agents d’intelligence artificielle ne se contentent pas de répondre à des requêtes prédéfinies. Ils sont autonomes. Ils se souviennent. Ils apprennent de ce qu’ils ont fait et l’appliquent dans de nouveaux contextes. Mais dans la plupart des outils d’IA actuels, la mémoire est traitée comme un bloc-notes jetable. Cela doit changer. La mémoire est désormais la base de données principale, vivante, persistante et opérationnelle. Elle a besoin d’une structure, d’un contrôle des versions, de politiques d’accès et d’un audit, tout comme n’importe quel système financier ou base de données clients auquel vous tenez.

Richmond Alake appelle ce changement « ingénierie de la mémoire ». Il établit une distinction entre la mémoire à court terme d’un LLM, qui se contente de stocker des poids et une fenêtre contextuelle temporaire, et la mémoire d’un agent d’intelligence artificielle, qui est censée persister au fil des sessions, prendre des nuances et évoluer au fil du temps. Ce type de mémoire est un flux de données en mouvement, qui se développe, change et influence les actions suivantes de votre IA.

Si vous ne régissez pas ce flux, votre IA développera des angles morts, répétera des erreurs, voire les fabriquera. Pire encore, elle le fera en toute confiance, sur la base des informations déformées qu’elle aura mémorisées. Pour les entreprises, cela crée un risque critique : un décideur artificiel qui agit sur la base de données corrompues, obsolètes ou non autorisées. Vous n’accepteriez pas cela dans votre système ERP. Vous ne pouvez pas vous le permettre ici non plus.

Partez du principe que la mémoire est une base de données d’entreprise comme les autres. Donnez-lui un schéma. Déterminez qui entre et accède à quoi. Auditez tout.

Une mémoire d’agent mal gérée présente trois risques majeurs pour la sécurité

La sécurité n’est jamais statique, en particulier avec les agents d’intelligence artificielle. Nous sommes arrivés à un point où ces systèmes peuvent accéder à des outils internes, à des bases de données et à des flux de travail basés sur les rôles, souvent en temps réel. C’est pourquoi la mémoire non gérée est plus qu’un problème de nettoyage. C’est une menace directe pour la sécurité.

Il existe trois risques majeurs, et aucun d’entre eux n’est théorique.

La première est l’empoisonnement de la mémoire. Il ne s’agit pas d’un piratage au sens traditionnel du terme, aucun pare-feu n’est brisé. Au contraire, un attaquant utilise des entrées régulières pour enseigner à votre IA quelque chose de faux. Une fois stockées dans la mémoire, ces informations erronées deviennent partie intégrante des croyances du système. Et à partir de là, chaque action en aval est influencée. L’OWASP a signalé cette catégorie de menaces. Des outils tels que Promptfoo existent aujourd’hui pour tester ces systèmes, en remettant en question la couche de mémoire de l’IA pour voir si elle peut être manipulée.

Vient ensuite l’utilisation abusive des outils. Lorsque les agents sont autorisés à appeler des API, à accéder à des bases de données ou à exécuter des commandes, ils peuvent être contraints, subtilement, à prendre de mauvaises décisions avec des informations d’identification valides. Par exemple, un attaquant peut inciter l’agent à interroger une base de données de production à l’aide d’un outil approuvé, mais dans un contexte non approuvé. Il ne s’agit pas d’une violation. Il s’agit d’une mauvaise utilisation autorisée. C’est plus difficile à prévenir et à détecter.

Enfin, il y a la dérive des privilèges. Au fil du temps, les agents accumulent des connaissances. Aujourd’hui, il assiste le directeur financier. Demain, il assistera un analyste junior. Le problème ? Il se souvient des deux sessions. Cela signifie qu’il peut commencer à transmettre des informations entre les rôles, exposant involontairement des données qu’il n’était pas censé partager. Ce point est déjà mentionné explicitement dans les taxonomies de sécurité de l’IA : les agents n’oublient pas, à moins que vous ne leur disiez comment le faire.

Pour les dirigeants, sachez que la mémoire dans ces systèmes n’est pas seulement une question de fonctionnalité. C’est une surface d’attaque. Chaque enregistrement non classé ou non structuré est un multiplicateur de risque. Plus l’accès au système est important, plus les enjeux sont élevés.

Vous devez définir comment vos agents stockent la mémoire, comment ils la rappellent et quand l’accès est révoqué. Et cela doit être géré avec la même discipline opérationnelle que celle que vous attendez de tout système d’entreprise de niveau 1. Il n’y a pas d’exception.

Les modèles existants de gouvernance des données d’entreprise peuvent et doivent être étendus pour régir efficacement la mémoire des agents

Vous avez déjà mis en place les systèmes nécessaires pour gérer la confiance dans les données. Il est maintenant temps de les utiliser.

Les entreprises savent comment gérer les informations sensibles, les dossiers des clients, les données financières et les données relatives aux ressources humaines. Ces systèmes disposent de schémas, de rôles d’accès, d’un suivi de l’historique, de calendriers de conservation, de pistes d’audit. Tout cela existe pour une raison. Vos agents d’IA n’ont pas besoin d’une nouvelle architecture de sécurité. Ils doivent hériter de celle à laquelle vous faites déjà confiance.

La tendance actuelle en matière d’IA passe d’un déploiement axé sur la rapidité à des plateformes structurées et vérifiables. La conversation au sein de la C-suite est en train de changer. Il ne s’agit plus de savoir à quelle vitesse nous pouvons lancer l’agent. Il s’agit plutôt de savoir à quelle vitesse nous pouvons nous assurer que ses données sont régies. Ce n’est pas une contrainte ennuyeuse. C’est ce qui empêche votre IA d’être un vecteur ouvert de risques juridiques, opérationnels et de réputation.

Les agents opèrent à grande vitesse. Ils traitent les données plus rapidement que les équipes humaines. Si vous leur fournissez des données périmées, mal étiquetées ou cloisonnées, ils amplifieront chaque défaut. Le risque n’est pas théorique. Ces agents ne s’arrêtent pas pour demander si les données sont correctes, ils agissent en fonction de ce qu’ils apprennent. Et une fois que cette mémoire est formée, ils la conservent d’une session à l’autre.

Si votre gouvernance s’arrête à l’entrepôt de données, vous avez déjà des angles morts. Les systèmes d’IA doivent suivre les mêmes politiques de classification, de conservation et d’accès que tout le reste. Pas de raccourcis. Pas de voies spéciales.

De nombreux développeurs créent involontairement des « bases de données fantômes » en stockant de la mémoire non gérée dans les agents d’intelligence artificielle.

La plupart des équipes ne construisent pas volontairement des systèmes d’IA non sécurisés. Mais c’est pourtant ce qui finit par se produire.

De nombreux frameworks d’IA par défaut sont livrés avec leurs propres couches de mémoire locale, bases de données vectorielles, fichiers JSON, caches en mémoire. Ils permettent une installation rapide, mais ils présentent des lacunes : pas d’application de schéma, pas de contrôle d’accès, pas de version, pas de visibilité. Ces bases de données fantômes se développent rapidement et silencieusement, fonctionnant en dehors de toute politique que vous avez déjà élaborée pour sécuriser l’infrastructure numérique.

Le problème s’étend rapidement. Copiez un prototype en production, et soudain vos agents gèrent des décisions en direct basées sur un stockage que personne ne contrôle ou ne surveille. Vous avez créé un autre silo de donnéesVous avez créé un autre silo de données, mais pire encore, il est dynamique, opaque et plein d’hypothèses non vérifiées. Cela signifie qu’il est impossible de lui faire confiance, de l’auditer ou de le sécuriser en toute confiance.

Pour les décideurs, il ne s’agit pas de ralentir les développeurs. Il s’agit d’éviter un décalage entre ce que le système sait et la manière dont cette connaissance est gérée. Vos équipes de sécurité ne peuvent pas gouverner ce qu’elles ne peuvent pas voir. La mémoire fantôme brise cette chaîne.

Si votre agent influence l’expérience des clients, prend des décisions, déclenche des actions et s’améliore au fil du temps, il s’agit d’un système de production. Sa mémoire doit se trouver dans la pile gouvernée.

L’objectif est simple : visibilité, responsabilité, confinement. Si vous n’appliquez pas de politiques de données de niveau entreprise à la mémoire des agents, vous êtes déjà en retard.

Les pratiques en matière de bases de données doivent être appliquées directement à la conception et à la gestion de la mémoire des agents.

La mémoire de l’IA est constituée de données exécutables. Elle façonne ce qu’un agent sait, se rappelle et agit. Cela signifie que les principes de base de données standard, la structure, le contrôle d’accès, la validation et la traçabilité ne sont pas facultatifs. Ce sont des exigences de base si vous voulez que vos agents soient fiables.

La couche mémoire doit être structurée. Vous ne pouvez pas jeter des journaux, des chiffres et des décisions dans un fichier plat et appeler cela un système. Traiter la mémoire comme un texte non structuré est un handicap. Chaque mémoire doit contenir des métadonnées : qui l’a créée, quand, dans quelle mesure le système est convaincu de son exactitude. Vous n’accepteriez pas des transactions financières non étiquetées. N’acceptez pas de processus de pensée non étiquetés.

Ensuite, votre pipeline de mémoire a besoin d’un pare-feu. Les entrées dans la mémoire à long terme doivent être soumises à une validation stricte : contrôles de schéma, règles de cohérence et analyse des menaces de sécurité telles que l’injection rapide ou l’empoisonnement de la mémoire. Ces règles doivent être appliquées au point d’entrée de la mémoire, et non pas après qu’une faille s’est produite.

Il y a ensuite le contrôle d’accès. Ne comptez pas sur une logique rapide pour contrôler qui voit quoi. Ce n’est pas fiable et ce n’est pas évolutif. Les politiques d’accès doivent se situer au niveau des données. Mettez en place une sécurité au niveau des lignes afin que les agents ne récupèrent que la mémoire correspondant à l’habilitation de l’utilisateur actuel. Si un agent a travaillé avec le directeur financier la semaine dernière, cela ne lui donne pas des droits à long terme sur ces informations lorsqu’il assiste un stagiaire aujourd’hui. Ces limites doivent être appliquées par la couche de données.

Enfin, vérifiez tout. Vous devez disposer d’une traçabilité complète, savoir quelle mémoire a été consultée, quand et pourquoi. Les chefs d’entreprise ont besoin de cette visibilité non seulement pour assurer la conformité, mais aussi pour déboguer les décisions. Si un agent effectue une action inattendue, vous devez être en mesure de savoir exactement quelle mémoire l’a déclenchée.

Brij Pandey le dit clairement : depuis des années, les bases de données constituent l’épine dorsale des applications sécurisées et évolutives. Cela ne change pas avec l’IA. En fait, elles sont encore plus importantes aujourd’hui. Vous ne vous contentez pas de stocker des données. Vous stockez le contexte opérationnel qui alimente la prise de décision autonome.

Les entreprises déjà équipées pour la gouvernance des données ont un avantage concurrentiel

La confiance dans l’IA est souvent évoquée en termes abstraits : alignement, équité, transparence. Tous ces éléments sont importants. Mais pour l’adoption par les entreprises, la confiance se résume à quelque chose de plus opérationnel : le contrôle.

Les entreprises qui régissent déjà la manière dont elles stockent, récupèrent et utilisent les informations sont les mieux placées pour faire évoluer les systèmes intelligents. Pourquoi ? En effet, il n’est pas nécessaire de mettre en place une nouvelle infrastructure, il suffit d’appliquer les contrôles existants à un nouveau type de charge de travail. Ce n’est pas un saut énorme. C’est un avantage.

Si vous gérez déjà des données sensibles avec des règles de conservation, un accès basé sur les rôles, un historique des versions et des journaux d’audit, vous avez déjà parcouru 70 % du chemin. En étendant cette discipline à la mémoire d’IA, vos agents peuvent accéder à des informations sans engager leur responsabilité. Cela signifie également que tout problème, qu’il s’agisse de bogues du système ou de failles dans les données, peut être diagnostiqué, retracé et résolu.

Pour les dirigeants de la suite, c’est un élément clé. La gouvernance est votre multiplicateur. Elle vous permet d’adopter des outils puissants, des agents capables de prendre des décisions et d’interagir avec les systèmes opérationnels, en toute confiance. Sans hésitation. Sans compromis.

La différence entre l’innovation et le chaos réside dans le contrôle. Les entreprises qui parviennent à une bonne gouvernance construisent plus rapidement, évoluent de manière plus sûre et prennent de l’avance.

Principaux enseignements pour les dirigeants

• Traitez la mémoire de l’IA comme une infrastructure de base : La mémoire des agents n’est pas temporaire, elle façonne les résultats. Les dirigeants doivent la gérer comme une base de données critique de l’entreprise avec un schéma, un contrôle d’accès et une auditabilité pour garantir un comportement sûr et fiable de l’IA.
• Anticiper et atténuer les risques de sécurité liés à la mémoire : L’empoisonnement de la mémoire, l’utilisation abusive des outils et l’augmentation des privilèges sont des menaces actives. Les dirigeants doivent mettre en œuvre une validation stricte, faire respecter les limites d’accès et auditer régulièrement la mémoire des agents afin de réduire les risques.
• Étendre la gouvernance des données existante aux systèmes d’IA : Les organisations qui gèrent déjà des données clients et financières disposent de l’infrastructure nécessaire. Les dirigeants devraient appliquer ces mêmes modèles de gouvernance à la mémoire de l’IA afin de réduire les risques sans réinventer les opérations.
• Éliminez les systèmes de mémoire fantôme : De nombreuses structures d’agents utilisent par défaut un stockage non géré, ce qui crée des zones d’ombre. Les dirigeants doivent imposer l’intégration de la mémoire des agents dans l’infrastructure de données de l’entreprise afin de maintenir la visibilité et le contrôle.
• Appliquer les principes éprouvés de l’architecture des bases de données à la mémoire institutionnelle : La mémoire de l’IA nécessite une structure, une validation et une traçabilité. Les décideurs doivent appliquer le schéma, la logique du pare-feu, l’accès au niveau des lignes et les audits de traçabilité de la mémoire pour que les systèmes restent fiables et sûrs.
• Utilisez la maturité de la gouvernance des données comme un avantage stratégique : Les entreprises dotées de solides fondations en matière de gouvernance peuvent faire évoluer les agents d’IA plus rapidement et de manière plus sûre. Les dirigeants devraient considérer la préparation à l’IA comme une extension des capacités de gouvernance existantes, et non comme une initiative distincte.