Comment les DSI peuvent encadrer l’autonomie des agents IA

Le risque immédiat lié aux agents vient de l’autorité

À mesure que les entreprises passent d’assistants IA à des agents capables d’agir avec moins d’intervention humaine, les DSI sont désormais confrontés à un choix déterminant : quel niveau d’accès et d’autorité accorder à ces systèmes. Le risque immédiat dépend des données, applications, outils et actions à la portée d’un agent, ainsi que des contrôles encadrant cet accès. Ces autorisations comptent déjà avec les systèmes actuels, quelle que soit l’ampleur des capacités supplémentaires que pourraient acquérir les futurs modèles.

Ce risque immédiat élargit le problème de sélection des modèles pour les DSI et en fait une question de conception du déploiement. Les DSI doivent toujours évaluer si un modèle est suffisamment capable pour une tâche, mais un déploiement autonome exige aussi de décider à quoi il peut accéder, quelles actions il peut exécuter de manière indépendante et à quel moment une personne doit approuver l’étape suivante. Ces choix déterminent les conséquences qu’un agent peut produire aujourd’hui dans l’entreprise, tandis que la recherche en IA de pointe influe sur le niveau de pression que les futurs systèmes pourraient exercer sur ces contrôles.

Les avertissements sur l’IA de pointe accentuent la pression sur le problème du contrôle

La nécessité de prendre au sérieux les capacités futures vient en partie des entreprises qui développent et commercialisent l’IA de pointe, et qui ont un intérêt commercial à orienter la manière dont les clients et les décideurs publics évaluent les capacités et la sécurité. Dario Amodei, PDG d’Anthropic, a appelé à ralentir le rythme du développement de l’IA de pointe, avertissant que des avancées rapides pourraient dépasser les efforts visant à comprendre et à contrôler des systèmes de plus en plus capables. Sa préoccupation porte sur la trajectoire de développement : des systèmes plus puissants pourraient arriver plus vite que les garde-fous destinés à les gérer.

Un concurrent direct a soutenu cette inquiétude. Sam Altman, PDG d’OpenAI, a appuyé l’appel d’Amodei à modérer le rythme du développement de pointe et a déclaré que le sujet avait fait l’objet de discussions majeures au sein d’OpenAI ces « dernières semaines ». Altman a également indiqué qu’OpenAI s’engagerait à donner aux évaluateurs indépendants un accès comparable à celui d’un employé, augmentant ainsi l’accès accordé aux tiers chargés d’évaluer ses systèmes. OpenAI développe et commercialise des services d’IA ; une confiance accrue dans l’évaluation et la sécurité favorise donc aussi l’adoption des systèmes qu’elle fournit.

Une autre initiative de fournisseur traite de la manière dont les personnes conservent l’autorité à mesure que les capacités des modèles progressent. Microsoft AI a publié le 14 septembre la première version de son Humanist AI Code of Conduct pour consultation publique. Ce projet vise à imposer que les futurs modèles de Microsoft AI restent soumis à la correction et à l’arrêt par des humains, afin de préserver une autorité humaine directe même lorsque leurs capacités augmentent. Microsoft a également un intérêt commercial dans l’adoption de l’IA en entreprise ; les règles proposées décrivent donc à la fois une position en matière de sécurité et une approche susceptible d’influer sur la confiance dans ses offres d’IA.

Le statut actuel de ce code limite ce que les DSI peuvent considérer comme une garantie opérationnelle. Microsoft indique que le code est encore en cours d’élaboration et n’est actuellement pas utilisé pour entraîner ses modèles. Il représente l’orientation de sécurité visée par l’entreprise plutôt qu’une contrainte d’entraînement déjà appliquée aux modèles déployés. Les DSI qui évaluent les systèmes Microsoft ont donc toujours besoin de contrôles applicables à leurs propres déploiements.

Ces initiatives des fournisseurs rendent la sécurité de l’IA de pointe pertinente pour la planification des entreprises, car des systèmes plus capables peuvent créer des problèmes de contrôle plus difficiles, tandis qu’une évaluation indépendante peut révéler des problèmes avant le déploiement. Le désaccord sur la vitesse à laquelle le développement de pointe devrait progresser peut perdurer parallèlement aux décisions de déploiement en entreprise. Les organisations doivent déjà décider du niveau d’autorité accordé aux agents actuels, ce qui fait passer le problème du développement des modèles à l’architecture des systèmes.

Un agent a besoin d’une autorisation pour causer un préjudice significatif

Pour les entreprises, le mécanisme commence par la portée. Un agent devient plus déterminant à mesure qu’il obtient l’accès aux données, applications et outils de l’entreprise et reçoit l’autorisation d’agir avec moins d’intervention humaine. Une erreur ou une action inattendue peut alors se propager dans des systèmes où sont gérés les informations clients, l’argent et les opérations métier. Une portée plus large transforme le comportement du modèle en exposition opérationnelle.

Cette exposition modifie les décisions du DSI, car la conception du déploiement détermine ce que le modèle peut affecter. Un DSI doit préciser quelles ressources un agent peut lire, quels outils il peut invoquer, quelles transactions il peut initier et quelles étapes exigent une approbation humaine. Les capacités du modèle déterminent ce que l’agent peut être en mesure de comprendre, tandis que ces décisions de déploiement déterminent quels résultats il peut concrétiser dans les systèmes de l’entreprise.

Randall Hunt, CTO du fournisseur de services cloud Caylent, estime que les responsabilités des entreprises à court terme restent les mêmes malgré les avertissements appelant à ralentir le développement de l’IA de pointe, car les entreprises contrôlent les autorisations accordées aux agents actuels. « Un modèle n’a pas besoin d’une intelligence surhumaine pour exposer des dossiers clients ou effectuer un paiement non autorisé ; il lui faut simplement de l’autorité et de l’accès », a déclaré Hunt. Caylent vend des services cloud aux entreprises ; l’entreprise a donc un intérêt commercial dans l’architecture et les contrôles que les sociétés utilisent autour des systèmes basés sur le cloud. Même avec cet intérêt, les exemples de Hunt identifient les autorisations concrètes nécessaires pour l’exposition de dossiers clients et les paiements non autorisés.

Ces exemples distinguent deux variables que les DSI peuvent gouverner différemment. L’intelligence influe sur ce qu’un agent peut être capable de découvrir ou de planifier, tandis que l’autorité et l’accès déterminent les ressources et opérations de l’entreprise qui lui sont ouvertes. Une organisation peut créer une exposition importante avec les systèmes actuels en accordant de larges autorisations, même pendant que les développeurs de l’IA de pointe se concentrent sur des modèles futurs plus puissants.

Une intelligence supérieure peut exercer davantage de pression sur ces limites d’autorisation. Hunt affirme que des modèles et agents plus capables pourraient découvrir des moyens de contourner des contrôles faibles, un problème qu’il s’attend à voir persister à mesure que les systèmes s’améliorent. Le mécanisme d’application compte donc, car un contrôle doit continuer à fonctionner lorsqu’un agent se comporte de manière inattendue ou devient plus performant dans la poursuite de la tâche qui lui a été assignée.

Encadrer l’autonomie avec des contrôles applicables

La nécessité de résister à un comportement inattendu fait passer le problème de la politique à l’application. Hunt soutient que les entreprises ont besoin de garde-fous autour des actions que les agents peuvent effectuer sans humain dans la boucle, c’est-à-dire sans qu’une personne examine ou approuve chaque action concernée. Des instructions peuvent indiquer à un modèle comment il doit se comporter, mais des restrictions dans le système environnant peuvent déterminer si une action demandée est autorisée à s’exécuter.

Cette application commence par la séparation entre accès et action. Le modèle de contrôle de Hunt définit précisément ce à quoi chaque agent peut accéder et quelles actions il est autorisé à entreprendre, car l’autorisation de lire une information ne justifie pas automatiquement la modification d’un enregistrement, le déclenchement d’un processus ou une dépense d’argent. Des limites explicites réduisent les ressources et opérations disponibles lorsqu’un agent commet une erreur ou suit une trajectoire inattendue.

Une fois ces limites en place, l’identité permet de les appliquer à chaque agent. Hunt indique que les agents devraient recevoir leur propre identité afin que les systèmes d’entreprise puissent attribuer des autorisations directement à l’agent au lieu de s’appuyer sur des identifiants plus larges. Ces identités devraient bénéficier d’un accès au moindre privilège, c’est-à-dire uniquement des autorisations nécessaires au travail assigné. Limiter ainsi chaque identité réduit ce qu’un agent peut atteindre si son comportement dépasse la tâche attendue.

Les autorisations d’action ont également besoin de limites en matière d’échelle et de durée. Hunt appelle à des plafonds de dépenses, des limites de transaction et des limites sur la durée pendant laquelle un agent peut fonctionner de manière autonome. Les plafonds de dépenses et les limites de transaction permettent au système environnant de rejeter les actions qui dépassent les seuils établis, tandis qu’une limite de temps met fin à l’autorité autonome à l’issue de la période prévue. Ces contrôles réduisent à la fois l’ampleur et la durée des conséquences possibles.

Pour que ces limites tiennent, Hunt recommande de faire appliquer les restrictions dans le code. Un prompt peut indiquer à un agent de rester sous un seuil de dépense ou d’éviter une opération particulière, mais des agents plus puissants peuvent contourner des contrôles faibles. Une application au niveau du code place la décision finale d’autorisation dans des systèmes capables de refuser l’action, indépendamment de ce que l’agent génère ou décide.

Lian Jye Su, analyste en chef chez Omdia, une division d’Informa TechTarget, recommande plusieurs contrôles qui recoupent l’architecture de Hunt, même si Su évalue différemment les avertissements plus larges sur l’IA de pointe. Su recommande de limiter l’autonomie des agents, d’attribuer des identités claires, d’appliquer des contrôles d’accès fondés sur les rôles, ou RBAC, qui accordent des autorisations selon des rôles définis, et de maintenir une supervision humaine. Omdia vend des études et analyses technologiques ; les recommandations sur la gouvernance de l’IA en entreprise font donc partie d’un marché dans lequel l’entreprise a un intérêt commercial.

En s’appuyant sur ces contrôles d’accès, Su s’attend à ce que les organisations intensifient le red-teaming, c’est-à-dire les tests délibérés des systèmes pour détecter les défaillances et comportements dangereux, et maintiennent des pistes d’audit couvrant les prompts, les appels d’outils et les résultats. Ces enregistrements relient ce qu’il a été demandé à un agent de faire aux fonctions externes qu’il a invoquées et au résultat qu’il a produit. Un DSI peut utiliser cette chaîne pour déterminer si une défaillance provient de l’instruction, de la limite d’autorisation, de l’invocation de l’outil ou de l’action qui en a résulté.

Le recoupement entre Hunt et Su est précis : tous deux placent l’autonomie encadrée, l’identité et les contrôles d’accès au centre de la gouvernance du déploiement. Su ajoute la supervision humaine comme limite d’approbation et prévoit davantage de red-teaming et d’auditabilité, qui testent ces limites et révèlent comment les systèmes se comportent autour d’elles. Ensemble, ces recommandations placent la gouvernance à l’intérieur des systèmes qui autorisent, observent et contraignent l’exécution.

Les contrôles intégrés à cette architecture n’exigent pas des DSI qu’ils prédisent l’intelligence de la prochaine génération de modèles. Un agent peut se comporter de manière inattendue à son niveau de capacité actuel ; le système environnant peut donc limiter ce que ce comportement est autorisé à accomplir. À mesure que les capacités augmentent, l’application externe devient plus importante, car Hunt s’attend à ce que des agents plus puissants exercent une pression plus forte sur des garde-fous faibles.

La sécurité des fournisseurs alimente la gouvernance d’entreprise

L’application externe marque aussi la frontière entre le travail de sécurité des fournisseurs et la responsabilité de l’entreprise. Les fournisseurs de modèles peuvent investir dans l’évaluation et les garde-fous autour du comportement des modèles, tandis qu’un DSI relie le modèle résultant aux identités, données, outils, processus d’approbation et systèmes d’exploitation de l’entreprise. Les pratiques des fournisseurs peuvent influer sur la première couche, mais c’est l’organisation qui déploie qui configure la seconde.

Gary Olliffe, distinguished vice president analyst chez Gartner, explicite cette frontière : « L’évaluation intégrée ne sera pas une “garantie de sécurité”, donc les DSI doivent toujours prévoir leurs propres investissements en garde-fous IA et en gouvernance. » Gartner vend des services de recherche et de conseil technologiques aux décideurs d’entreprise, ce qui lui donne un intérêt commercial dans les questions de gouvernance sur lesquelles Olliffe conseille. Son point s’applique directement à l’architecture de déploiement, car une évaluation par le fournisseur ne peut certifier chaque combinaison d’autorisations et de workflows dans laquelle un modèle peut être placé.

Cette frontière donne aux DSI deux ensembles liés de décisions de sécurité. Les entreprises d’IA peuvent évaluer le comportement des modèles et améliorer les garde-fous avant et pendant la mise à disposition, tandis que les entreprises gouvernent les identités, autorisations, actions et validations humaines disponibles dans leurs environnements. Les pratiques des fournisseurs peuvent réduire les risques provenant du comportement des modèles, et les contrôles de l’entreprise limitent les conséquences créées par la configuration propre à chaque organisation.

La sélection des fournisseurs doit donner la priorité à la sécurité

Avec une responsabilité répartie entre ces couches, les achats doivent tenir compte des deux. Su indique que les DSI étaient déjà prudents à l’égard de l’IA agentique, car la gouvernance, la sécurité, la qualité des données et un ROI peu clair freinaient les déploiements à grande échelle. Il s’attend à ce que les récents avertissements des dirigeants de l’IA renforcent cette prudence et repoussent potentiellement davantage les décisions de déploiement dans le futur. Cette attente relie directement les préoccupations liées à l’IA de pointe aux calendriers d’achat et de déploiement des entreprises.

La prudence accrue anticipée par Su s’étend des contrôles internes à la sélection des partenaires. « Les DSI vont commencer à examiner de plus près leurs plans en matière d’IA agentique, choisir des partenaires ayant une solide compréhension de la sécurité de l’IA et de la cybersécurité, et consacrer davantage de ressources aux pratiques internes de sécurité de l’IA et de cybersécurité avec supervision humaine », a-t-il déclaré. Dans ce modèle, les pratiques de sécurité des fournisseurs complètent les contrôles qu’une entreprise maintient autour de son propre déploiement.

Cette relation peut modifier la manière dont les DSI classent des modèles qui répondent déjà aux exigences fonctionnelles d’un cas d’usage. « La meilleure pratique consistera à adopter les modèles d’IA agentique les plus sûrs plutôt que les plus intelligents ou les plus capables », a déclaré Su. Pour un cas d’usage où plusieurs systèmes peuvent effectuer le travail requis, des pratiques plus solides de sécurité et de sûreté chez le fournisseur peuvent avoir une valeur pratique importante, en complément des contrôles de l’entreprise sur les identités, les autorisations, la supervision et l’intervention humaine.

L’augmentation des capacités accentue la pression sur les contrôles

Donner la priorité au contrôle laisse néanmoins les capacités comme variable de risque importante. Des dirigeants de l’IA demandent un ralentissement du développement de l’IA de pointe, et Hunt s’attend à ce que des agents plus puissants puissent trouver des moyens de contourner des contrôles faibles. L’évaluation indépendante reste pertinente pour la même raison : un agent plus capable peut révéler des faiblesses qu’un système moins capable n’atteindrait jamais. L’attente de Su d’une prudence accrue des DSI découle de cette pression.

La pression liée aux capacités devient opérationnelle à travers l’autorité attachée à l’agent. Les agents actuels peuvent atteindre des dossiers sensibles ou initier des transactions lourdes de conséquences lorsque les organisations leur accordent les autorisations nécessaires, tandis que l’avertissement d’Olliffe signifie qu’une évaluation intégrée du fournisseur ne peut pas constituer une « garantie de sécurité » pour un déploiement donné en entreprise. À mesure que les modèles deviennent plus capables, les DSI ont de plus en plus de raisons de tester et de renforcer les systèmes qui déterminent quelles données, quels outils et quelles actions ces modèles peuvent atteindre.

Recap

Les DSI n’ont pas besoin de trancher le débat sur le développement de l’IA de pointe avant de prendre des décisions sur l’IA agentique. Ils doivent en revanche décider du niveau d’autorité à accorder aux systèmes actuels. À mesure que les agents accèdent à des données sensibles, à des applications métier et à des transactions, ces choix de déploiement déterminent les conséquences des erreurs des modèles et des comportements inattendus.

Pour les dirigeants d’entreprise, cela fait de l’autonomie une décision de gouvernance plutôt qu’une simple caractéristique de capacité. L’identité de l’agent, l’accès au moindre privilège, les limites de transaction, l’approbation humaine et l’application au niveau du code doivent être définis en parallèle du business case du déploiement. Les évaluations des fournisseurs et leurs engagements en matière de sécurité peuvent éclairer la sélection des fournisseurs, mais ils ne peuvent pas remplacer des contrôles conçus pour les systèmes et workflows propres à une organisation.

La norme pratique n’est donc pas de savoir si un agent est suffisamment capable pour fonctionner de manière autonome, mais si l’entreprise peut encadrer cette autonomie en toute sécurité. À mesure que les capacités des modèles augmentent, les entreprises disposant de limites applicables sur l’accès et l’action seront mieux placées pour adopter ces capacités sans accorder une autorité inutile.