Agent IA
Nous concevons l’IA dans les autorisations existantes, des limites de données propres à la tâche et des processus applicatifs maîtrisés.
Un agent d’IA ne doit pas être un raccourci vers la base de données ou les droits d’administration. Il agit dans les limites définies par l’application et le processus. Avant qu’une tâche IA reçoive des informations, des composants de confiance vérifient l’utilisateur, ses droits et le but de la demande.
| Question | Responsabilité de l’application | |---|---| | Qui est l’utilisateur ? | authentification | | Que peut-il lire ou faire ? | autorisation et rôles | | Quelles données peut-il voir ? | périmètre organisation, client, tenant ou document | | Quelle action peut-il réaliser ? | validation de l’action et droit d’approbation |
Lire un dossier ne donne pas automatiquement le droit de le modifier, de rembourser un paiement ou de changer les droits d’une autre personne. Une validation humaine peut être requise, mais ne remplace pas les contrôles techniques.
Pour un ticket de support hypothétique, l’IA peut recevoir le message, le produit et le statut courant afin de préparer une synthèse. Elle n’a besoin ni d’un mot de passe, ni d’un jeton de session, ni de factures sans rapport, ni de données d’autres clients. La minimisation limite l’entrée, mais ne remplace pas l’application des droits avant cette sélection.
Utilisateur → [application : identité, droit, périmètre des données]
│
▼
données sélectionnées pour la tâche
│
▼
fournisseur IA
│
▼
résultat non fiable → validation applicative → action autoriséePour un assistant de connaissance, l’application limite d’abord la recherche aux documents accessibles à la personne courante. Pour une facture, l’IA peut suggérer des valeurs ; l’application vérifie format et règles, puis une personne autorisée les contrôle avant l’approbation existante. Ce sont des exemples illustratifs, non des projets clients GiSoft.
L’injection de prompt consiste à placer dans un message ou un document des instructions visant à faire ignorer les règles prévues. Ce contenu est une donnée non fiable, pas une instruction de l’application. Limiter le contexte, séparer instructions et contenu, valider le résultat et restreindre les outils sont utiles ; aucune mesure isolée n’élimine tout risque.
Un JSON structuré ou un score de confiance élevé ne garantit pas une catégorie, une synthèse, une valeur de facture ou une action correcte. Les secrets ne doivent pas apparaître dans les prompts, le contexte ou les réponses ; une couche d’intégration séparée ne garantit pas à elle seule la confidentialité.
Les traces utiles peuvent contenir identifiant du dossier, utilisateur, sources, version du processus, résultat de validation et action approuvée, sans conserver tous les prompts ou documents. Les droits pertinents sont revérifiés avant l’affichage d’un résultat différé ou l’exécution d’une action.
Timeout, sortie invalide, accès retiré, source indisponible ou annulation doivent produire un état visible et un comportement défini pour le processus. Un repli manuel n’est utile que s’il a été conçu et vérifié. Les données, décisions et actions qui font foi restent sous le contrôle de l’application et des personnes autorisées.