Quels garde-fous choisir pour l’intelligence artificielle générale en entreprise ?

Les garde-fous pour l’intelligence artificielle générale concernent une technologie encore hypothétique, mais les décisions prises aujourd’hui structurent déjà l’exposition des entreprises. Les agents autonomes, grands modèles de langage et assistants connectés aux outils internes rapprochent certains usages des capacités attendues d’une AGI. La différence entre AGI et IA générative reste donc essentielle pour calibrer les contrôles. Une IA générative produit ou transforme du contenu dans un périmètre défini. Une AGI désignerait un système capable de transférer ses compétences entre des tâches variées, de planifier et d’agir avec une autonomie beaucoup plus large.

AGI et IA générative : distinguer les capacités utiles aux équipes IT

L’IA générative actuelle prédit la suite la plus probable d’un texte, d’une image ou de code à partir de données d’entrée. Elle peut appeler des outils externes lorsqu’un agent lui en donne le droit. Cette combinaison augmente son utilité, mais aussi sa surface d’attaque.

Une intelligence artificielle générale n’existe pas comme produit démontré et disponible en entreprise. Le terme décrit une capacité cognitive générale qui resterait performante sur des tâches nouvelles sans entraînement spécialisé pour chacune d’elles. Les équipes IT doivent éviter de présenter un agent relié à un progiciel de gestion, à une messagerie et à une base documentaire comme une AGI.

Les limites de l’intelligence artificielle générale restent aussi théoriques que ses capacités. Pourtant, les contrôles conçus pour les agents actuels forment une base solide. Ils empêchent surtout qu’un modèle obtienne, par défaut, des droits plus larges que ceux de son opérateur.

Les risques de l’AGI en entreprise exigent des frontières opérationnelles

Les risques de l’AGI en entreprise seraient d’abord liés à l’autonomie. Un système capable de décomposer un objectif commercial ou technique en sous-tâches pourrait consulter des fichiers, envoyer des messages ou modifier une configuration. Chaque action isolée peut paraître légitime. Leur enchaînement peut créer une fraude, une interruption de service ou une divulgation massive.

Les attaques contre les modèles actuels donnent une indication concrète. L’injection de prompt consiste à cacher une instruction hostile dans un document, une page web ou un courriel consulté par l’agent. Le jailbreaking cherche, lui, à contourner les règles fixées au modèle par des formulations ambiguës ou insistantes.

La fuite de données constitue un risque central lorsque les connecteurs donnent accès aux dossiers RH, aux contrats ou aux dépôts de code. Un modèle n’interprète pas spontanément la confidentialité comme un juriste ou un responsable métier. La protection des données sensibles doit donc être appliquée avant l’envoi vers le modèle, par classification, masquage et règles de rétention.

Les garde-fous techniques contrôlent les accès, les prompts et les actions

Le principe du moindre privilège impose d’accorder à un agent les seuls droits nécessaires à une tâche précise. Un assistant chargé de résumer des tickets support n’a pas besoin de créer des comptes, de consulter la paie ou de déployer du code. Des identités de service distinctes permettent de limiter les dégâts en cas de compromission.

Le filtrage des entrées et des sorties vérifie les documents transmis au modèle et les réponses qu’il produit. Il peut bloquer des secrets détectés, des données personnelles, des commandes dangereuses ou des instructions cachées. Aucun filtre n’est parfait. Les contrôles doivent donc être doublés par une validation avant toute action irréversible.

Le contrôle humain obligatoire s’applique aux paiements, suppressions, modifications de droits et communications externes. La validation doit afficher les données utilisées, l’action proposée et son périmètre. Un simple bouton de confirmation sans contexte ne réduit pas réellement le risque.

Enfin, les équipes doivent tester l’arrêt d’urgence et réversibilité. Couper l’accès d’un agent suppose de révoquer ses jetons, suspendre ses connecteurs et bloquer ses files de tâches. Les actions réalisées doivent rester identifiables et annulables lorsque c’est techniquement possible.

Une gouvernance de l’IA organise les responsabilités et les escalades

Une gouvernance de l’IA adaptée aux équipes IT attribue un propriétaire métier, un responsable technique et une autorité de contrôle pour chaque cas d’usage. Les rôles et responsabilités clairement définis évitent qu’un incident reste sans pilote entre sécurité, conformité et direction métier. Ils déterminent aussi qui peut modifier les instructions système ou élargir les droits d’un agent.

La politique de contrôle doit lier chaque déploiement à un registre. Ce registre documente la finalité, les données utilisées, les modèles, les outils connectés, les sous-traitants et les décisions humaines requises. Un niveau de criticité permet ensuite de choisir la fréquence des revues et la profondeur des tests.

Le développement d’une application web sécurisée illustre cette logique. Les clés d’interface de programmation ne doivent pas être exposées côté navigateur, et les appels au modèle passent par un serveur contrôlé. Les mêmes principes valent pour les agents capables d’interroger des services internes.

Choisir les contrôles selon la criticité du cas d’usage

Une gouvernance fondée sur le niveau de risque distingue les assistants de rédaction des systèmes qui agissent sur les actifs de l’entreprise. Un outil qui reformule un compte rendu interne demande un cadre de confidentialité. Un agent qui met à jour un dossier client ou ordonne un remboursement exige des autorisations plus étroites et une approbation humaine.

Le règlement européen classe certains usages comme inacceptables, à haut risque, à risque de transparence ou à risque minimal. Cette grille ne remplace pas l’analyse interne. Elle aide toutefois à documenter le niveau de contrôle attendu, surtout lorsqu’un système traite des données personnelles ou influence une décision affectant une personne.

Les seuils doivent être concrets. Une action financière peut être bloquée au-delà d’un montant fixé par la direction. Une modification de production peut exiger deux validations. Une hausse soudaine du volume d’appels doit déclencher une alerte, car elle peut signaler un pic, voire un volcan de requêtes anormales.

Vérifier les garde-fous par des tests et un audit continu

Les contrôles ne prouvent leur efficacité qu’en situation d’échec simulée. Les tests adversariaux et le red teaming opposent au système des scénarios d’injection de prompt, d’exfiltration, d’abus d’outils et de contournement des validations. Les résultats doivent conduire à des correctifs suivis, pas seulement à un rapport de conformité.

Un audit continu de la robustesse mesure la part de requêtes bloquées à bon escient, le taux de faux positifs, le délai de révocation d’un accès et le nombre d’actions annulées. Ces indicateurs révèlent les dégradations après une mise à jour de modèle, de connecteur ou de politique interne. Ils permettent aussi de comparer les niveaux de sûreté entre fournisseurs.

La journalisation doit conserver l’identité de l’utilisateur, les sources consultées, les outils appelés et la décision finale. Les journaux ne doivent pas stocker inutilement les données brutes ou les secrets. Leur durée de conservation doit être cohérente avec les exigences de sécurité, d’enquête et de protection des données.

Questions fréquentes sur les garde-fous pour l’intelligence artificielle générale

Une IA générative actuelle doit-elle déjà être soumise à des garde-fous ?

Oui. Un modèle génératif devient un risque opérationnel dès qu’il accède à des données internes ou appelle des outils. Les mêmes règles de droits minimaux, de traçabilité et de validation humaine s’appliquent avant toute automatisation à impact réel.

Quel contrôle faut-il imposer avant qu’un agent IA agisse ?

Une approbation humaine est requise pour les actions financières, juridiques, RH ou techniques irréversibles. L’écran de validation doit préciser l’action, les données source, la cible et les conséquences attendues. Cette étape doit être journalisée.

Comment réduire le risque d’injection de prompt ?

Il faut traiter les contenus externes comme des données non fiables et les séparer des instructions système. Les agents ne doivent pas interpréter un document consulté comme une règle prioritaire. La restriction des outils accessibles limite aussi l’impact d’une instruction hostile.

L’AI Act s’applique-t-il aux outils internes d’entreprise ?

Oui, selon le rôle de l’entreprise, le type de système et son usage. Les obligations varient entre fournisseur, déployeur, importateur et distributeur. Un outil interne peut relever d’exigences renforcées s’il entre dans une catégorie à haut risque ou s’il exploite un modèle d’IA à usage général.

L’anticipation d’une AGI passe donc par une discipline déjà nécessaire pour les agents actuels. Des droits limités, des validations explicites et des preuves d’audit créent une architecture de contrôle capable d’évoluer avec les capacités des modèles.