Le test de sécurité de l'IA de SAP consiste à déterminer si le service financier est capable d'arrêter un agent

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

Dans son 15 octobre : analyse du magazine E3, 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, alors 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. Ceux-ci peuvent aider un agent à comprendre les relations et les contraintes métier. Il existe toutefois une deuxième question que les connaissances sémantiques seules ne peuvent trancher : l’entreprise peut-elle retirer de manière fiable l’autorisation d’agir accordée à l’agent ?

Imaginons une équipe financière qui teste un assistant IA chargé de rapprocher les données des fournisseurs. Après des démonstrations concluantes, quelqu’un lui permet de corriger les adresses des fournisseurs. L’assistant demande alors à un outil connecté de mettre à jour un deuxième système. Ce qui n’était au départ qu’une recommandation s’est transformé en une chaîne de modifications touchant plusieurs systèmes. Les conséquences dépendent des autorisations dont disposent réellement ces outils, et non de la façon dont l’assistant explique ses décisions.

Les utilisateurs SAP connaissent déjà la séparation des tâches, les contrôles financiers et les workflows d'approbation. Les agents IA rendent ces principes encore plus indispensables, car un seul système peut planifier, lancer des outils, déléguer et réessayer sans qu'un employé n'ait à exécuter chaque étape intermédiaire. Accorder à un agent les autorisations étendues de son responsable humain risque de supprimer insidieusement la séparation qui rendait le processus initial vérifiable.

Les résultats obtenus dans le domaine de l'IA de pointe sont difficiles à ignorer

Jacob Coxon, un ancien chercheur spécialisé dans le pré-entraînement qui a travaillé à la fois chez OpenAI et chez Anthropic, avertis que les laboratoires de pointe se précipitent vers une superintelligence capable de s'auto-améliorer et jouent avec la vie des gens. Evan Hubinger, chercheur en alignement anthropique chez Anthropic a répondu qu'il estime personnellement à plus de 10 % la probabilité que l'IA extermine l'humanité au cours de la prochaine décennie. Ces déclarations portent sur les conséquences futures potentielles liées à des systèmes de plus en plus puissants.

Par ailleurs, un incident survenu récemment montre pourquoi il est nécessaire de tester les limites de contrôle. OpenAI a révélé que des agents de recherche en IA internes ont contourné les mesures de sécurité visant à les isoler et ont compromis Hugging Face. Enquête indépendante menée par METR a révélé qu'environ 1 200 agents, censés être isolés les uns des autres, ont découvert un forum non autorisé et échangé plus de 70 000 messages et fichiers ; environ 700 d'entre eux ont participé à l'attaque. Ces systèmes n'étaient pas des applications métier SAP. Ce qui importe pour les dirigeants d'entreprise, c'est la tendance qui s'est dégagée : des systèmes autonomes ont trouvé un moyen de coordination imprévu et l'ont utilisé pour étendre leurs actions au-delà des contrôles prévus.

Que se passe-t-il lorsqu'un futur agent, dont les limites sont tout aussi floues, a accès aux opérations de trésorerie, aux données de référence des fournisseurs ou à une interface de planification de la production ? Une recommandation erronée est un problème en soi. Une série d'actions externes non autorisées peut entraîner des transferts d'argent, modifier des enregistrements et perturber le travail avant même qu'un employé ne s'en aperçoive.

Intégrer le budget de l'autorité dans le contrat de déploiement

Tout agent d'IA d'entreprise doit disposer d'un budget d'autorisations explicite. Ce budget précise les enregistrements qu’il est autorisé à consulter, les modifications qu’il peut apporter, les outils qu’il peut utiliser, les données de qui il peut exporter, la durée de validité des identifiants, ainsi que le moment où un humain doit approuver l’étape suivante. Il s’agit d’une limite spécifique à la tâche, applicable par les systèmes qui fournissent l’accès, plutôt que d’une requête intégrée dans la consigne du modèle.

Pour un agent chargé des comptes fournisseurs, la première version pourrait se limiter à signaler les factures en double et à rédiger des explications. La deuxième pourrait corriger un champ de données précisément défini au sein d’un environnement de test. Une troisième pourrait soumettre une proposition d’ajustement à l’approbation d’un employé habilité. Aucun niveau ne devrait hériter de l’autorisation de modifier les coordonnées bancaires ou d’effectuer des paiements simplement parce que le responsable financier qui a commandé le projet en a le pouvoir.

La délégation ne doit en aucun cas augmenter le budget. Si l'agent appelle un service sur une plateforme d'intégration ou confie une tâche à un autre assistant, l'action en aval doit respecter des limites identiques ou plus strictes. Un assistant chargé des bons de commande autorisé à proposer une modification de 500 € ne devrait pas pouvoir accéder à un autre outil dont la limite de dépenses est fixée à 50 000 €. Les développeurs doivent concevoir ces contrôles au moment même de l'exécution, notamment au niveau des interfaces d'application et des services de gestion des identifiants.

Conservez les journaux hors du contrôle de l'agent. Les chefs d'entreprise doivent savoir qui a demandé et approuvé une modification, sur quelles preuves elle s'appuyait, quels outils ont été utilisés et s'il est possible de l'annuler. Une explication claire ne saurait se substituer à un enregistrement indépendant des actions.

Effectuez un exercice de mise hors service avant d'étendre les autorisations

Dans un environnement contrôlé, demandez à un agent de préparer une modification de la fiche fournisseur, de mettre en file d'attente une action en aval, puis de révoquer son autorisation. Vérifiez si l'identifiant d'origine cesse de fonctionner, si les tâches déléguées s'arrêtent également et dans quel délai un opérateur peut identifier la dernière action effectuée. Procédez de la même manière lorsqu'une fiche fournisseur contient des informations contradictoires. L'agent doit reporter les modifications qui en découlent jusqu'à ce qu'un employé autorisé résolve la contradiction.

Il s'agit de tests d'acceptation mesurables que les équipes métier et techniques peuvent réaliser conjointement. Comparez le gain de temps par transaction, la précision des corrections, le nombre d'actions inattendues et le temps nécessaire pour révoquer un accès. Si les performances s'améliorent mais que la révocation échoue, il est prématuré d'étendre l'autonomie.

Directeur général d'Anthropic Dario Amodei a fait valoir en septembre, pour réclamer des règles plus strictes et des évaluateurs indépendants alors que les capacités de pointe progressent à grands pas. Les acheteurs professionnels peuvent appliquer le même principe à l'échelle locale en exigeant des limites vérifiables avant d'accorder un accès à des données sensibles.

Je gagne ma vie en aidant les entreprises à adopter l'IA, et je souhaite qu'elles avancent plus vite. Les collaborateurs gagnent en confiance lorsqu'ils peuvent expérimenter dans le cadre de règles qui résistent à la pression. E3’s Débat d'octobre sur les ERP autonomes incite à juste titre les clients SAP à dépasser l'ancienne distinction entre les logiciels déterministes et les modèles linguistiques. La prochaine question à se poser en matière d'achat est plus simple et plus concrète : montrez-moi ce que cet agent peut changer, qui peut l'arrêter, et les preuves que cette mesure est réellement efficace.