Le test de sécurité SAP sur l'IA : le service financier est-il capable de neutraliser un agent IA ?

Vous lisez la traduction allemande de cet article. Vous trouverez la version originale en anglais ici.

Dans son Éditorial du magazine E3 du 15 octobre Peter M. Färbinger a soulevé un problème qui devrait préoccuper tout client SAP s'intéressant à l'IA autonome. Les modèles linguistiques fonctionnent de manière probabiliste, tandis que la planification des ressources d'entreprise repose sur des transactions précises et reproductibles. Il s'est demandé si les graphes de connaissances pouvaient fournir la structure nécessaire à cet effet. Ils peuvent en effet aider un agent à comprendre les contextes commerciaux et les conditions-cadres. Mais il existe une deuxième question à laquelle les connaissances sémantiques seules ne permettent pas de répondre : une entreprise peut-elle retirer de manière fiable à un agent d’IA l’autorisation d’agir ?

Imaginons une équipe financière qui teste un assistant IA pour la mise en correspondance des données de base des fournisseurs. Après des démonstrations concluantes, l’assistant obtient l’autorisation de corriger les adresses des fournisseurs. Il lance ensuite, via un outil connecté, la mise à jour d’un deuxième système. Ce qui n’était au départ qu’une recommandation s’est transformé en une chaîne de modifications inter-systèmes. Les conséquences de cette situation dépendent des autorisations réelles des outils utilisés – et non de la manière dont l’assistant justifie ses décisions.

Les utilisateurs SAP sont déjà familiarisés avec la séparation des fonctions, les contrôles financiers et les workflows d'approbation. Les agents IA renforcent encore l’importance de ces mécanismes de contrôle, car un seul système peut planifier de manière autonome, lancer des outils, déléguer des tâches et réessayer des actions sans qu’un collaborateur n’ait à effectuer chacune des étapes intermédiaires. Si un agent se voit attribuer les mêmes autorisations étendues que son donneur d’ordre humain, on court le risque de voir, à l’insu de tous, cette séparation des fonctions – qui rendait le processus initial traçable et vérifiable – être contournée.

Il est difficile d'ignorer les signaux d'alerte liés au développement de l'IA de pointe

Jacob Coxon, ancien chercheur spécialisé dans le pré-entraînement des modèles d'IA, qui a travaillé tant chez OpenAI que chez Anthropic, a averti, selon laquelle les principaux laboratoires d'IA se livrent à une course effrénée pour mettre au point une superintelligence capable de s'améliorer d'elle-même, mettant ainsi des vies humaines en danger. Evan Hubinger, chercheur en alignement chez Anthropic, répondit, selon lesquelles il estime personnellement à plus de 10 % la probabilité que l'IA puisse anéantir l'humanité tout entière au cours des dix prochaines années. Ces déclarations portent sur les conséquences futures possibles de systèmes d'IA de plus en plus performants.

Un incident récent montre d'ailleurs pourquoi il est nécessaire de vérifier concrètement les limites des mécanismes de contrôle. OpenAI a rendu public, selon laquelle des agents de recherche en IA internes avaient contourné les mécanismes d'isolation et compromis la plateforme Hugging Face. Une Enquête indépendante menée par METR a révélé qu'environ 1 200 agents, qui étaient censés être isolés les uns des autres, avaient découvert un forum de discussion non autorisé et y avaient échangé plus de 70 000 messages et fichiers. Environ 700 agents ont participé à cette attaque. Ces systèmes n’étaient pas des applications SAP de gestion d’entreprise. Pour les responsables d’entreprise, c’est toutefois le schéma de comportement mis en évidence qui est déterminant : des systèmes autonomes ont trouvé un moyen involontaire de se coordonner et l’ont utilisé pour étendre leurs activités au-delà des limites de contrôle prévues.

Que se passerait-il si un futur agent d'IA, soumis à des restrictions tout aussi insuffisantes, avait accès aux processus de trésorerie, aux données de base des fournisseurs ou aux interfaces de planification de la production ? Une recommandation erronée est une chose. Mais une série d’actions non autorisées dans des systèmes externes peut entraîner des mouvements de fonds, modifier des enregistrements et perturber les processus opérationnels avant même qu’un collaborateur ne s’en aperçoive.

Faire du cadre d'autorisation un élément incontournable de la mise en œuvre de l'IA

Chaque agent IA utilisé en entreprise devrait disposer d'un budget d'autorisations clairement défini. Celui-ci détermine les ensembles de données que l’agent est autorisé à consulter, les modifications qu’il peut apporter, les outils auxquels il a accès, les données de qui il est autorisé à exporter, la durée de validité de ses identifiants d’accès et les moments où un humain doit approuver l’étape suivante. Il s’agit là d’une restriction liée à la tâche, qui doit être techniquement mise en œuvre par les systèmes accordant l’accès – et non pas simplement d’une instruction figurant dans l’invite du modèle linguistique.

Dans le cas d'un agent IA dédié à la comptabilité fournisseurs, la première étape pourrait consister exclusivement à signaler les factures en double et à formuler des explications. Dans un deuxième temps, il pourrait corriger un champ de données clairement défini au sein d'un environnement de test. Une troisième étape pourrait lui permettre de soumettre une proposition de correction pour validation par un collaborateur habilité. Aucune de ces étapes ne devrait automatiquement donner le droit de modifier les coordonnées bancaires ou de déclencher des paiements, simplement parce que le responsable financier qui a lancé le projet est lui-même habilité à le faire.

Même en cas de délégation de tâches, le budget d'autorisations ne doit en aucun cas être augmenté. Si un agent appelle un service sur une plateforme d'intégration ou transfère des tâches à un autre assistant, les actions en aval doivent être soumises à des restrictions identiques ou plus strictes. Un assistant chargé des commandes, qui n’est autorisé à proposer qu’une modification d’un montant de 500 euros, ne doit pas pouvoir accéder soudainement, via un autre outil, à une limite de dépenses de 50 000 euros. Les développeurs doivent mettre en œuvre ces contrôles là où les actions sont effectivement exécutées, y compris au niveau des interfaces d’application et des services de gestion des identifiants.

Les données de journalisation doivent rester hors du contrôle de l'agent. Les responsables des processus doivent pouvoir retracer qui a demandé et approuvé une modification, sur quelles informations elle s'appuyait, quels outils ont été utilisés et si cette modification peut être annulée. Une explication rédigée de manière convaincante ne saurait se substituer à un journal des actions tenu de manière indépendante.

Effectuer un test de mise hors service avant d'étendre les autorisations

Dans un environnement contrôlé, un agent doit d'abord préparer une modification d'une fiche fournisseur et mettre une action en aval en file d'attente. Ses autorisations lui sont ensuite retirées. Il convient alors de vérifier si les identifiants d'accès d'origine perdent leur validité, si les tâches déléguées sont également interrompues et dans quel délai un collaborateur responsable est en mesure d'identifier la dernière action effectuée. Le même test doit être effectué lorsqu’une fiche fournisseur contient des informations contradictoires. L’agent doit suspendre les modifications susceptibles d’avoir des conséquences importantes jusqu’à ce qu’un collaborateur habilité ait résolu ces incohérences.

Il s'agit de tests de réception mesurables que les services métier et les équipes informatiques peuvent réaliser conjointement. Il convient de comparer le gain de temps par transaction, la précision des corrections, le nombre d'actions inattendues et le temps nécessaire au retrait des autorisations. Si les performances de l’agent s’améliorent, mais que la révocation des autorisations ne fonctionne pas de manière fiable, il est prématuré d’étendre son autonomie.

PDG d'Anthropic Dario Amodei a plaidé en septembre, compte tenu du développement fulgurant de systèmes d'IA performants, en faveur de règles plus strictes et d'instances de contrôle indépendantes. Les entreprises peuvent appliquer ce même principe à leurs propres projets d'IA en exigeant des limites dont l'efficacité est démontrée avant d'accorder aux agents une grande latitude d'action.

Dans le cadre de mon activité professionnelle, j'accompagne les entreprises dans la mise en œuvre de l'IA et je souhaite les aider à progresser plus rapidement. Les collaborateurs gagnent en confiance lorsqu'ils peuvent mener des expériences dans le respect de règles claires, qui fonctionnent de manière fiable même en situation de stress. La Débat E3 d'octobre sur les ERP autonomes invite à juste titre les clients SAP à dépasser la distinction traditionnellement établie entre les logiciels déterministes et les modèles linguistiques. La prochaine question cruciale en matière d’achat est plus simple et plus concrète : montrez-moi ce que cet agent est autorisé à modifier, qui peut l’arrêter et quelles preuves attestent que cet arrêt fonctionne réellement.