Les agents d'IA sont souvent présentés comme des outils de productivité plus rapides, plus autonomes et plus persistants que les formes d'automatisation précédentes.
Une fois qu'un agent fonctionne en continu et agit sans supervision, il passe dans une catégorie différente. Il lit les informations non fiables, détient les informations d'identification et prend des décisions qui ne peuvent être visibles qu'une fois qu'elles ont pris effet. D'un point de vue opérationnel, cela le place plus près d'un service d'arrière-plan que d'un outil que quelqu'un utilise activement.
Ce changement de cadre est plus important que le choix du modèle, du framework ou de l'environnement d'hébergement.
Les systèmes opérationnels sont conçus en tenant compte des défaillances. Ils supposent des saisies compliquées, une visibilité incomplète et un oubli humain, non pas parce que les équipes s'attendent à ce que les choses tournent mal tous les jours, mais parce qu'elles comprennent que la stabilité est un facteur dont les systèmes s'éloignent au fil du temps.
La plupart des défaillances des agents reflètent cette dérive. L'accès temporaire devient permanent. Les autorisations sont étendues pour éliminer les frictions et ne plus jamais se contracter. Les journaux augmentent parce que le stockage est peu coûteux et que l'examen est reporté. L'agent continue de fonctionner suffisamment bien pour qu'il soit risqué de le toucher. Rien de tout cela ne semble imprudent pour le moment. On dirait que c'est pratique.
Le fait de considérer les agents comme des logiciels interactifs qui s'exécutent simplement plus longtemps encourage ces modèles. Les informations d'identification générales semblent acceptables car l'agent est utile. L'accès partagé semble raisonnable car le système est interne. Au fil du temps, ces choix produisent des systèmes difficiles à raisonner et encore plus difficiles à modifier.
Les équipes chargées de l'infrastructure reconnaissent immédiatement ce schéma. Les systèmes bien gérés sont construits en fonction de limites plutôt que d'intentions. Ils partent du principe que les entrées seront trompeuses, que les autorisations seront modifiées et que les systèmes seront utilisés d'une manière que personne n'avait initialement prévue. Les agents héritent de ces conditions dès qu'ils sont laissés en activité.
Lorsqu'un agent peut lire largement, écrire librement et appeler de nombreux services externes, il devient difficile de prévoir son comportement sous pression. L'injection rapide cesse d'être un sujet de recherche abstrait une fois que les autorisations sont trop étendues. À ce stade, les résultats sont moins influencés par le jugement du modèle que par l'étendue de l'accès.
C'est là que la gouvernance apparaît, même dans les petites équipes. Pas la gouvernance en tant que paperasse, mais la gouvernance en tant que propriété. Quelqu'un doit savoir à qui appartient l'agent, qui peut l'arrêter, qui change ses informations d'identification et qui décide de ce qu'il est autorisé à toucher lorsque son rôle change.
Lorsque ces réponses ne sont pas claires, le système fonctionne déjà sans supervision efficace.
On a tendance à remettre ces questions à plus tard, en particulier lorsque les déploiements sont conçus comme des expériences. Les systèmes toujours actifs ont l'habitude de rester actifs. Une fois qu'un agent devient utile, il crée une dépendance, et la dépendance réduit l'appétit pour le changement.
Les limites ajoutées tardivement sont plus difficiles à appliquer et il est plus facile de résister.
Il existe une base de référence axée sur la sécurité pour rendre les pannes ennuyeuses. L'agent s'arrête. L'accès est révoqué. Les informations d'identification font l'objet d'une rotation. L'impact reste limité. Le système redevient compréhensible.
Si vous pouvez décrire, en langage clair, ce à quoi votre agent peut accéder, ce à quoi il ne peut pas accéder et comment vous feriez pour le fermer en cas de mauvais jour, la configuration est probablement dans un état raisonnable. Lorsque ces réponses sont vagues, le problème vient rarement de l'agent lui-même. C'est l'absence de discipline opérationnelle à cet égard.
Les agents d'IA continueront de gagner en capacité et le déploiement continuera de se faciliter. Ces tendances renforcent la nécessité de faire preuve de modération au lieu de la réduire.
Traitez les agents comme des systèmes opérationnels dès le départ. Une fois ce cadre en place, il devient plus facile de raisonner sur le reste.
