Vérifier si un agent IA Supply Chain est réel ou simplement agent-washé

Objectif

Évaluer si l’agent IA d’un fournisseur possède de vraies capacités de décision et d’exécution ou s’il s’agit principalement d’une interface conversationnelle.

Utilisateur cible

Dirigeants Supply Chain, équipes achats et architectes de planification.

Entrées

• Environnement de démonstration fournisseur
• Dataset de planification sandboxé
• Résultats attendus connus
• Documentation des accès et permissions
• Preuves d’audit et de rollback

Architecture

Tester l’agent dans une sandbox sans accès d’écriture en production. Observer la récupération des données, l’application des contraintes, les appels d’outils, la conservation de l’état et la demande d’approbation.

Étapes

• Demander quelle décision de planification l’agent améliore.
• Vérifier les données auxquelles il accède.
• Demander quelles contraintes influencent la recommandation.
• Tester s’il appelle des outils ou génère seulement du texte.
• Contrôler la conservation de l’état dans le workflow.
• Identifier ce qu’il peut modifier sans approbation.
• Inspecter les logs d’action et les contrôles de rollback.
• Examiner la méthode d’évaluation de l’agent.
• Tester des données incomplètes et contradictoires.

Test pratique

Utiliser un SKU stable, une promotion, un composant contraint, un délai incorrect et une instruction contradictoire du planificateur. Vérifier si l’agent détecte le problème de données, sépare faits et hypothèses, identifie la contrainte, demande une approbation avant une action à fort impact et produit une recommandation auditable.

Validation

• L’agent explique la décision et les contraintes actives.
• Les appels d’outils sont visibles et autorisés.
• Les actions à fort impact exigent une approbation.
• Les logs conservent les versions des données, prompts, politiques et modèles.
• Le rollback réussit.

Governance box

• Source : dataset de planification sandboxé.
• Propriétaire : process owner de la planification.
• Validation : réponse attendue connue et test d’échec.
• Contrôle de version : prompt, politique et modèle.
• Accès : aucune écriture en production pendant l’évaluation.
• Override manuel : obligatoire.
• Mode d’échec : arrêter l’exécution et conserver les logs.