Où la gouvernance de l'IA doit-elle avoir lieu : au niveau de la passerelle, dans l'application, ou les deux ?

0
minutes de lecture
Où la gouvernance de l'IA doit-elle avoir lieu : au niveau de la passerelle, dans l'application, ou les deux ?

Où doit s'exercer la gouvernance de l'IA : au niveau de la passerelle, dans l'application, ou les deux ?

La gouvernance de l'IA relève des deux couches : la passerelle applique les politiques à l'échelle de l'organisation et l'application applique les décisions qui dépendent du contexte métier. Traiter la gouvernance de l'IA au niveau de la passerelle ou de l'application comme un choix binaire laisse une série de risques sans protection.

La passerelle convient aux règles qui s'appliquent à chaque requête, comme le masquage des données personnelles, la journalisation et les limites de dépenses. L'application convient aux règles que seule elle peut évaluer, comme la propriété des ressources et l'état des flux de travail.

Ce guide explique comment fonctionne chaque couche, où chacune échoue seule et comment des cadres tels que le règlement européen sur l'IA structurent cette répartition. Vous découvrirez également des tests pour évaluer votre architecture actuelle.

Ce que signifie le placement de la gouvernance de l'IA et pourquoi c'est important

Le placement de la gouvernance de l'IA désigne la décision de savoir où, dans votre pile technologique, vous appliquez les politiques de contrôle d'accès, de confidentialité des données, de conformité et de sécurité. Vous pouvez les appliquer de manière centralisée au niveau d'une passerelle, à l'intérieur de chaque application, ou dans les deux.

Une passerelle se situe entre vos applications et les modèles d'IA qu'elles appellent, et elle inspecte chaque requête avant que le trafic n'atteigne un fournisseur. La gouvernance au niveau de l'application réside à l'intérieur de chaque service, agent ou flux de travail sous forme de vérifications d'autorisations, de validation des prompts et de filtrage des sorties intégrées au code. Chaque couche perçoit quelque chose que l'autre ne peut pas voir : la passerelle voit tout le trafic, tandis que l'application sait ce qu'une requête signifie pour un enregistrement spécifique.

Le placement détermine si vos mesures de sécurité de l'IA tiennent à mesure que l'utilisation croît. Des contrôles placés dans la mauvaise couche entraînent des politiques fragmentées, une conformité de l'IA inégale, des outils de « shadow AI » non enregistrés et des lacunes d'audit qui apparaissent lors des examens réglementaires. Pour les équipes qui s'appuient sur une plateforme d'IA d'entreprise, le choix du placement détermine aussi la rapidité avec laquelle de nouveaux cas d'usage peuvent être déployés sans ajouter de risque.

Comment fonctionne la gouvernance au niveau de la passerelle

Une passerelle d'IA est le point d'entrée unique du trafic d'IA d'une organisation. Les requêtes provenant des assistants, des agents, des pipelines de génération augmentée par récupération (RAG) et des outils internes passent par la passerelle avant d'atteindre un fournisseur de modèles. Gartner a publié son premier Market Guide consacré aux passerelles d'IA en février 2026.

Pour chaque requête, la passerelle inspecte l'entrée, applique la politique d'identité, sélectionne un modèle, attache un budget, vérifie la réponse et journalise l'échange. Les contrôles courants incluent la détection des injections de prompts, la modération du contenu, le contrôle d'accès basé sur les rôles, les clés d'API à portée limitée et le routage par zone géographique ou par sensibilité des données. La passerelle peut aussi ajouter automatiquement des mentions « généré par l'IA », ce qui transforme des engagements éthiques de l'IA comme la transparence en comportements appliqués.

La limitation du débit illustre concrètement les avantages de la passerelle d'IA. Une équipe de plateforme peut plafonner chaque agent à 60 appels d'outils par minute, avec une erreur 429 au-delà de la limite et une erreur 403 pour les adresses IP bloquées. Chaque agent hérite de la règle dès le premier jour, sans aucune modification du code des agents ni des serveurs d'outils.

Comment fonctionne la gouvernance au niveau de l'application

La gouvernance au niveau de l'application place les contrôles à l'intérieur du service, de l'agent ou du flux de travail qui possède les données. Une passerelle sait qui appelle. La gouvernance au niveau de l'application couvre ce que la passerelle ne peut pas voir, comme la propriété des ressources, la classification des données, l'état des flux de travail et les limites par action.

Les appels d'outils des agents rendent la différence concrète. Une politique peut autoriser un outil issue_refund uniquement lorsque l'utilisateur détient le rôle refund_approver et que le montant est inférieur à une limite définie. Une autre peut autoriser edit_project_plan uniquement lorsque l'identifiant d'équipe de l'utilisateur correspond à l'identifiant de l'équipe propriétaire du projet.

La récupération suit le même schéma. Le contrôle d'accès au niveau des documents reste à l'intérieur de la base de données vectorielle ou du système source plutôt qu'au niveau de la passerelle. Seul ce système sait quels documents chaque utilisateur peut ouvrir.

Pourquoi une gouvernance uniquement au niveau de l'application échoue à grande échelle

Une gouvernance uniquement au niveau de l'application demande à chaque équipe produit de construire sa propre journalisation, ses propres filtres de prompts, son propre masquage des données personnelles et ses propres messages de divulgation. Chaque équipe interprète la même politique un peu différemment, et ces versions s'éloignent davantage les unes des autres à chaque mise à jour.

La lacune d'audit apparaît tôt. Une question comme « Quels modèles ont traité des données clients ce mois-ci ? » n'a pas de réponse unique lorsque chaque service journalise dans son propre format. Les équipes qui envoient des prompts directement depuis le code frontend ou backend sautent souvent complètement l'étape de journalisation.

La pression des délais aggrave ces défis de gouvernance de l'IA à mesure que les équipes intègrent des modèles non enregistrés et des intégrations externes, ce qui alimente le shadow AI, un facteur qui, selon IBM, ajoute 670 000 USD au coût moyen d'une violation. Les données d'entraînement, les séries d'évaluation et les artefacts de déploiement perdent leurs liens entre eux. La préparation d'audit se transforme en exercice de documentation au lieu de preuves extraites de la télémétrie du système.

Pourquoi une gouvernance uniquement au niveau de la passerelle présente des angles morts

Une gouvernance uniquement au niveau de la passerelle repose sur des outils grossiers comme les listes d'autorisation, les routes regex et les règles en ligne. Ces outils peuvent bloquer un modèle de requête. Ils ne peuvent pas exprimer des règles tenant compte des relations, comme permettre aux responsables de consulter les évaluations de performance uniquement de leurs subordonnés directs.

Les flux de travail multi-agents exposent un risque plus profond, car une vérification au premier saut ne dit rien de ce qu'un sous-agent fait ensuite. Le sous-agent peut finir par agir avec plus d'autorité que n'en avait l'utilisateur d'origine. Prévenir cette défaillance du « député confus », ainsi que l'agentivité excessive et l'escalade de privilèges qu'elle permet, implique de vérifier chaque saut et de restreindre les autorisations à chaque délégation.

Une passerelle ne régit également que l'usage à l'exécution. La passerelle ne peut pas montrer comment les données d'entraînement ont été obtenues, quels ensembles de données ont entraîné un modèle, comment le modèle a été évalué ou qui a approuvé sa mise en production. Ces tâches de gestion des risques liés à l'IA nécessitent des contrôles au sein des pipelines d'entraînement et des systèmes de déploiement.

Comment superposer la gouvernance entre la passerelle et l'application

Une conception en couches attribue chaque contrôle à la couche qui dispose des informations nécessaires pour l'appliquer. En pratique, la répartition ressemble à ceci :

  • La passerelle gère le masquage des données personnelles, la détection des injections de prompts, la modération, la journalisation unifiée, les budgets par équipe, les limites de débit, le routage des fournisseurs et la gestion des clés.
  • L'application gère l'accès aux documents, les vérifications de propriété, l'autorisation selon l'état du flux de travail, la validation des sorties, les règles métier des appels d'outils et la vérification de la chaîne de délégation.

L'identité doit circuler entre les deux couches. La passerelle vérifie l'appelant et transmet cette identité en aval, et l'application décide de ce que l'appelant peut faire avec un enregistrement spécifique. Glean, par exemple, applique les autorisations avant que le contenu n'atteigne le modèle, de sorte que les réponses ne s'appuient que sur ce que chaque utilisateur est déjà autorisé à voir.

Les contrôles à l'exécution doivent aussi se connecter aux contrôles du cycle de vie comme les registres de modèles, les flux de travail d'évaluation et les points de contrôle de déploiement. Lorsque les deux couches écrivent dans un seul système de référence, la gouvernance de l'IA produit des preuves de conformité pendant les opérations normales. Un enregistrement partagé est une bonne pratique essentielle de la gouvernance de l'IA, car les preuves existent déjà lorsqu'un auditeur les demande.

Cadres et normes de gouvernance de l'IA qui influencent les décisions de placement

Le règlement européen sur l'IA adopte une approche fondée sur le risque. Ses obligations incluent la gouvernance des données d'entraînement, la traçabilité des modèles, l'évaluation avant la mise en production, la supervision humaine, les contrôles de sécurité à l'exécution, la transparence, la surveillance continue et la gestion des incidents. La sécurité à l'exécution et la transparence trouvent leur place au niveau de la passerelle, tandis que la traçabilité et la supervision dépendent des systèmes applicatifs et de cycle de vie.

La norme ISO/IEC 42001 définit une norme de système de management pour l'IA, et le NIST AI Risk Management Framework (AI RMF) structure la gestion des risques liés à l'IA. Les deux normes couvrent la collecte des données, le déploiement et la surveillance post-déploiement, ce qui donne aux auditeurs une raison de regarder au-delà des journaux d'inférence. Les services financiers, la santé et d'autres secteurs réglementés ajoutent des exigences de résidence des données et d'isolation régionale que les deux couches doivent appliquer.

Un test simple de conformité de l'IA utilise une seule sortie en production. Montrez à un auditeur le prompt, la réponse, l'horodatage, l'utilisateur, le modèle et si cet utilisateur était autorisé à voir les données sources. La passerelle fournit les cinq premiers éléments, et seule l'application peut prouver le sixième.

Comment évaluer votre architecture de gouvernance dès aujourd'hui

Décider de la gouvernance de l'IA au niveau de la passerelle ou de l'application commence par un inventaire de chaque service d'IA, agent et intégration de modèle. Une équipe incapable de répondre à « Quelle IA faisons-nous fonctionner ? » a un problème de découverte à résoudre avant toute décision de placement. L'empreinte compte aussi, car une passerelle peut être excessive pour un seul fournisseur de modèles, une ou deux applications d'IA et des besoins de conformité légers.

Ensuite, menez un exercice de changement de politique. Choisissez une nouvelle règle, comme « aucune donnée personnelle client dans les prompts envoyés à des modèles externes », et chronométrez le temps nécessaire pour l'appliquer à chaque service. Des semaines de déploiements de code réparties sur plusieurs équipes signifient que votre gouvernance est trop distribuée.

Puis, séquencez le travail par risque : d'abord les contrôles de passerelle pour les budgets, le masquage et la journalisation d'audit, puis les contrôles d'application pour les autorisations et les vérifications des flux de travail. Lorsque vous comparez des outils de gouvernance de l'IA, le nôtre inclus, demandez à chaque fournisseur de réaliser cet exercice de changement de politique en direct. Vous pouvez en savoir plus sur notre équipe et sur la façon dont nous concevons une IA gouvernée.

Foire aux questions

Quels sont les principaux avantages d'une passerelle d'IA ?

Une passerelle offre aux équipes de sécurité et de plateforme un seul endroit pour définir et modifier la politique d'IA. Un nouveau filtre ou budget s'applique à toutes les applications connectées en même temps, sans redéploiement. Les fournisseurs partagent un format de journal unique, ce qui raccourcit la préparation d'audit, et les outils non enregistrés perdent leur accès aux modèles.

En quoi la gouvernance de l'IA au niveau de la passerelle diffère-t-elle de celle au niveau de l'application ?

La passerelle juge la requête, et l'application juge l'action. Les contrôles de passerelle couvrent qui appelle, quels modèles ils peuvent atteindre et quel contenu est autorisé à passer. Les contrôles d'application décident si cet utilisateur peut accéder à cet enregistrement spécifique ou déclencher cette étape de flux de travail, en fonction de données que seule l'application détient.

Que se passe-t-il lorsqu'une entreprise n'a aucune gouvernance de l'IA ?

Les dépenses en IA augmentent sans contrôle, et les données personnelles des clients peuvent se glisser dans les prompts envoyés à des fournisseurs externes. La posture de sécurité varie selon les équipes, les régulateurs réclament des preuves que personne ne peut produire, et le shadow AI comble les lacunes. Les équipes perdent aussi la capacité de remonter d'un résultat d'IA jusqu'à ses données ou son modèle.

Comment équilibrer la gouvernance entre le gateway et les applications ?

Posez une question par contrôle : son application nécessite-t-elle de connaître l'enregistrement ou le workflow spécifique concerné ? Si non, c'est le gateway qui s'en charge. Si oui, c'est l'application, et les deux couches alimentent le même enregistrement d'audit afin que les relecteurs ne voient qu'une seule trace.

Quels cadres de gouvernance de l'IA déterminent où doivent résider les contrôles ?

Le règlement européen sur l'IA (EU AI Act) définit des obligations fondées sur le risque pour les systèmes d'IA, notamment la traçabilité, la supervision humaine et la surveillance. La norme ISO/IEC 42001 fixe les exigences d'un système de management de l'IA, et le NIST AI RMF guide les équipes pour identifier et réduire les risques liés à l'IA. Chacun de ces cadres va au-delà de l'exécution pour englober l'approvisionnement en données et l'approbation des modèles ; aucune couche ne peut donc les satisfaire à elle seule.

Vous pouvez répartir correctement les responsabilités sans reconstruire toutes vos applications d'un coup. Déplacez d'abord les contrôles que votre gateway peut assumer, puis fournissez aux équipes applicatives le contexte d'appel dont elles ont besoin pour les décisions au niveau des enregistrements. Demandez une démo pour découvrir comment Glean et l'IA peuvent transformer votre environnement de travail, et nous vous présenterons la gouvernance tenant compte des autorisations sur les deux couches.

Articles récents

L’IA au travail qui fonctionne.

Demander une démo
CTA BG