Gouvernance de l'IA : modèles, données, autorisations, risques et auditabilité

La gouvernance de l'IA est le système de droits de décision, de responsabilités, de contrôles et de preuves utilisé pour décider comment une organisation peut développer, acquérir, déployer, exploiter, modifier et retirer des systèmes d'IA. Elle est plus large qu'un document de politique et plus étroite que l'architecture d'entreprise dans son ensemble. Une gouvernance de l'IA efficace relie la propriété métier, les choix de modèles et de fournisseurs, l'autorité sur les données, les permissions, la classification des risques, l'évaluation, la surveillance, la gestion des incidents, l'auditabilité et les décisions de cycle de vie afin que quelqu'un puisse répondre non seulement à « l'IA fonctionne-t-elle ? » mais aussi à « qui l'a approuvée, dans quelles conditions, avec quelles preuves, et quand cette décision doit-elle être réexaminée ? »

Ce que signifie réellement la gouvernance de l'IA

La gouvernance de l'IA répond à des questions organisationnelles auxquelles un modèle, un SDK ou un schéma d'architecture ne peut pas répondre seul. Qui est propriétaire du résultat métier ? Qui peut approuver un nouveau fournisseur ? Quelles classes de données sont interdites de traitement externe ? Quelles preuves sont requises avant le déploiement ? Quelles permissions un agent peut-il recevoir ? Qui peut accepter le risque résiduel ? Que se passe-t-il lorsqu'un modèle change de comportement après une mise à niveau ?

L'objectif n'est pas d'empêcher le changement. Une bonne gouvernance rend le changement lisible : les décisions ont des propriétaires, des preuves, des conditions, des exceptions, des dates de révision et des voies de retour en arrière ou d'escalade.

C'est pourquoi le NIST place GOVERN sur l'ensemble du cycle de vie de la gestion des risques liés à l'IA plutôt que de traiter la gouvernance comme une étape d'approbation finale. La gouvernance établit la culture, les politiques, la responsabilité et les structures organisationnelles qui rendent possible la cartographie, la mesure et la gestion des risques liés à l'IA.

L'exemple le plus simple

Une équipe produit souhaite ajouter un fournisseur externe d'IA générative pour résumer des tickets de support client internes. Techniquement, l'intégration peut ne nécessiter qu'un appel API.

La gouvernance pose un ensemble différent de questions : Le contenu des tickets est-il autorisé à quitter l'environnement de l'organisation ? Quel fournisseur et quelle version de modèle sont approuvés ? La rétention est-elle désactivée ? Quels utilisateurs peuvent invoquer la fonctionnalité ? Comment la sortie est-elle évaluée ? Une revue humaine est-elle requise ? Qu'est-ce qui est journalisé ? Qui est responsable des incidents ? Que se passe-t-il si le fournisseur modifie ses conditions ou le comportement du modèle ?

Le résultat de la gouvernance peut toujours être « déployez-le ». La différence est que le déploiement est désormais une décision traçable avec des conditions explicites au lieu d'un choix d'ingénierie non enregistré.

Où l'exemple simple s'arrête

Les grandes organisations gouvernent rarement un seul système d'IA de manière isolée. Le même modèle peut soutenir des dizaines de produits ; un fournisseur peut traiter plusieurs classes de données ; une plateforme d'agents peut exposer des outils partagés à de nombreuses équipes.

La gouvernance a donc besoin de structures au niveau du portefeuille ainsi que de contrôles au niveau du système : inventaire de l'IA, fournisseurs approuvés, catalogues de modèles, référentiels d'évaluation partagés, modèles de sécurité, seuils de risque, registres d'exceptions et mappages de propriété.

La gouvernance ne peut pas non plus être identique pour chaque usage de l'IA. Un résumeur de contenu public, un assistant de codage interne, un système d'aide au recrutement et un agent capable d'initier des paiements ont des profils de conséquences et de contrôles matériellement différents.

Ce qu'est la gouvernance de l'IA — et ce qu'elle n'est pas

La gouvernance est plus large que la conformité

La conformité est un intrant de la gouvernance, pas l'ensemble du système de gouvernance. Un cas d'usage de l'IA peut être légalement autorisé tout en violant l'appétit pour le risque de l'entreprise, la politique de sécurité, les obligations contractuelles ou les exigences de qualité produit.

L'inverse compte aussi : une approbation interne ne prime pas sur la loi. La gouvernance doit rendre les obligations légales applicables visibles au sein du même chemin de décision utilisé pour l'architecture, la sécurité et le risque métier.

L'ISO/IEC 42001 définit explicitement un système de management de l'IA comme un moyen structuré d'établir des politiques, des objectifs et des processus pour une IA responsable. L'ISO précise également que la norme ne remplace pas les lois ou réglementations ; elle fournit un cadre de management pouvant soutenir la conformité.

Le NIST AI RMF et l'ISO/IEC 42001 répondent à des besoins de gouvernance différents

Ces sources ne doivent pas être fusionnées en une seule liste de contrôle. Le NIST AI RMF est un guide de gestion des risques. L'ISO/IEC 42001 est une norme de système de management. L'EU AI Act est une loi. Une organisation peut les utiliser ensemble, mais leur autorité, leur portée et leur finalité de mise en œuvre sont différentes.

Le calendrier actuel de l'EU AI Act est important

Au 8 octobre 2026, la Commission européenne indique que l'AI Act est devenu généralement applicable le 2 août 2026. Les dispositions relatives aux pratiques interdites et à la littératie en IA s'appliquaient depuis le 2 février 2025, tandis que les règles de gouvernance et les obligations pour les modèles d'IA à usage général s'appliquaient depuis le 2 août 2025.

Les orientations actuelles de la Commission reflètent également des dates d'application ultérieures pour certaines exigences à haut risque. Les dates exactes et les règles de transition constituent un intrant de conformité évolutif et doivent être vérifiées par rapport aux documents actuels de la Commission avant une décision de déploiement.

La gouvernance de l'IA commence par un inventaire

Une organisation ne peut pas gouverner des systèmes d'IA qu'elle ne peut pas identifier. L'inventaire doit couvrir plus que les modèles entraînés sur mesure. Il peut inclure des API de modèles externes, des copilotes intégrés, des modèles locaux, des fonctionnalités SaaS dotées d'IA, des environnements d'exécution d'agents, des systèmes de récupération et des composants de décision automatisés.

Un inventaire utile relie la capacité d'IA à son propriétaire métier, son propriétaire technique, son cas d'usage, ses utilisateurs, ses classes de données, son modèle/fournisseur, son environnement de déploiement, ses permissions, sa classification des risques, son statut d'évaluation, ses obligations applicables et son état dans le cycle de vie.

L'inventaire n'est pas seulement un tableur pour les auditeurs. C'est l'index qui permet à l'organisation de savoir ce qui doit être réexaminé lorsqu'un fournisseur change, qu'une vulnérabilité apparaît, qu'une réglementation devient applicable ou qu'un modèle est retiré.

La gouvernance exige une propriété nommée

Les défaillances de l'IA franchissent souvent les frontières organisationnelles. Un problème de qualité de modèle peut devenir une défaillance produit, un problème de sécurité, un incident de confidentialité ou une violation contractuelle. La gouvernance a besoin de propriétaires nommés avant que l'incident ne survienne.

La propriété ne signifie pas qu'une seule personne est responsable de tout. Un modèle solide sépare les droits de décision : propriétaire métier, propriétaire produit, propriétaire technique, propriétaire des données, spécialistes sécurité/confidentialité, acteurs juridiques/conformité et support opérationnel.

La propriété critique est que chaque décision requise a un propriétaire et que chaque propriétaire sait quelles preuves il est censé examiner.

Les droits de décision doivent être explicites

La gouvernance des modèles est plus que le choix d'un modèle

La gouvernance des modèles suit quel modèle est utilisé, dans quel but, sous quelle configuration et avec quelles preuves. Cela s'applique aux API externes, aux modèles hébergés localement, aux modèles affinés et aux modèles intégrés dans des logiciels tiers.

Une décision de modèle doit prendre en compte la capacité, les résultats d'évaluation, le coût, la latence, le traitement des données, les conditions du fournisseur, le support du cycle de vie, les contraintes géographiques/d'hébergement, la sécurité, le comportement de repli et les conséquences d'un changement de version.

Les alias de modèle tels que « latest » peuvent être pratiques sur le plan opérationnel mais affaiblissent la reproductibilité si le comportement change sans processus de publication gouverné. Les systèmes à conséquences bénéficient d'un suivi explicite des versions et d'une évaluation de régression.

La gouvernance des fournisseurs est une couche de dépendance distincte

Deux systèmes utilisant la même famille de modèles peuvent avoir des risques de gouvernance différents si l'un s'exécute localement et l'autre envoie des données à un fournisseur externe. La gouvernance des fournisseurs couvre les conditions contractuelles, le lieu de traitement, la rétention, la journalisation, les sous-traitants, la disponibilité, la dépréciation et la stratégie de sortie.

L'abstraction des fournisseurs peut réduire la dépendance technique, mais elle ne supprime pas le travail de gouvernance. Changer de fournisseur peut modifier les flux de données, le comportement du modèle, les hypothèses de sécurité, les coûts et les obligations de conformité.

Une liste de fournisseurs approuvés ne doit donc pas être interprétée comme « chaque modèle et chaque classe de données de ce fournisseur est automatiquement approuvé ». L'approbation nécessite une portée.

La gouvernance des données reste la couche de source de vérité

La gouvernance de l'IA ne fait pas du modèle l'autorité pour les faits organisationnels. La gouvernance des données détermine toujours la propriété, la classification, la rétention, la qualité et l'utilisation autorisée des données sources.

Pour le RAG et les agents, la gouvernance doit identifier quelles sources font autorité, lesquelles sont consultatives, comment la provenance est préservée, quelles données peuvent entrer dans le contexte du modèle et quelles frontières de locataire/utilisateur doivent être appliquées.

Les sorties générées créent également de nouvelles questions de gouvernance des données : si les invites et les réponses sont conservées, qui peut accéder aux traces, si les résumés générés deviennent des enregistrements et comment les embeddings ou index dérivés sont supprimés lorsque les données sources sont supprimées.

Les permissions sont des décisions de gouvernance avec application à l'exécution

L'IA agentique fait des permissions un objet de gouvernance de premier ordre. L'organisation doit décider quels outils, fichiers, API, bases de données et effets de bord chaque agent ou utilisateur peut accéder.

La gouvernance définit la politique et la logique d'approbation ; l'environnement d'exécution de confiance les applique. Les instructions en langage naturel telles que « ne pas supprimer de fichiers » ne remplacent pas l'autorisation au niveau du système de fichiers, de l'API ou du service.

Le même principe s'applique à l'isolation des locataires : un rôle peut autoriser une opération tandis que la portée du locataire limite les ressources de quel client cette opération peut atteindre.

La classification des risques doit modifier l'ensemble des contrôles

Tous les systèmes d'IA n'ont pas besoin de la même profondeur d'examen. La gouvernance devient évolutive lorsque la classification des risques modifie les exigences en matière de preuves, d'approbation et de surveillance.

La méthode de classification peut être simple ou sophistiquée, mais elle doit correspondre à des conséquences concrètes : plus de tests, des permissions plus restreintes, une supervision humaine obligatoire, un examen de sécurité, une acceptation des risques par la direction ou une interdiction de déploiement.

La gouvernance doit préserver le contexte du cas d'usage

La fonction MAP du NIST met l'accent sur l'objectif visé, les utilisateurs, le contexte de déploiement, les hypothèses, les impacts et les lois ou normes applicables. Cela importe car le même modèle peut présenter un faible risque dans un cas d'usage et avoir des conséquences élevées dans un autre.

Les dossiers de gouvernance doivent donc classer l'application, et non seulement le modèle. « Nous utilisons le modèle X » ne suffit pas pour déterminer le risque.

L'objet de gouvernance pertinent est le système ou le cas d'usage : modèle + données + contexte + outils + utilisateurs + environnement de déploiement + processus métier.

L'évaluation est une preuve de gouvernance

Un processus de gouvernance de l'IA ne doit pas approuver un déploiement sur la seule base des benchmarks d'un fournisseur ou d'une démonstration réussie. Le système a besoin de preuves liées à son usage réel prévu.

Les preuves utiles peuvent inclure l'évaluation de la réussite des tâches, la qualité de la recherche d'informations, l'ancrage factuel, les tests de sécurité, les tests de permissions, les scénarios adversariaux, les études de révision humaine, la latence et le coût, la robustesse et les comparaisons de régression.

La fonction MEASURE du NIST rend cela explicite : les organisations doivent identifier et appliquer des méthodes et des métriques appropriées pour les risques identifiés lors de la cartographie, tout en documentant les risques qui ne peuvent pas ou ne seront pas mesurés.

Les points de contrôle de gouvernance doivent exister tout au long du cycle de vie

La gestion du changement est au cœur de la gouvernance de l'IA

Les systèmes d'IA changent même lorsque le code de l'application ne change pas. Les fournisseurs mettent à jour les modèles, les filtres de sécurité, les limites de contexte, les tarifs, les politiques et l'infrastructure. Les corpus de récupération changent. Les outils des agents acquièrent des permissions. Les réglementations et les contrats évoluent.

La gouvernance doit donc définir des déclencheurs de changement matériel. Un ajustement mineur de la formulation d'un prompt peut nécessiter des tests de régression ordinaires ; le remplacement du modèle, l'activation d'outils d'écriture ou l'introduction de données sensibles peuvent nécessiter un nouveau jalon d'approbation.

Le registre de gouvernance doit conserver quelle version a été approuvée et quelles conditions ont rendu l'approbation valide.

Les exceptions nécessitent des propriétaires, une expiration et des contrôles compensatoires

Les organisations réelles ont besoin d'exceptions. Une équipe peut avoir besoin d'un modèle non approuvé pour une expérience limitée dans le temps, ou un système hérité peut ne pas encore satisfaire à une nouvelle exigence de journalisation.

Le schéma dangereux est une exception permanente non documentée. Les exceptions gouvernables précisent le propriétaire, la justification, la portée, le risque résiduel, le contrôle compensatoire, la date d'expiration et la condition de réexamen.

Le traitement des exceptions doit faire partie du système de gouvernance normal plutôt que d'un canal parallèle informel.

L'auditabilité est la capacité de reconstituer la décision et l'exécution

L'auditabilité de l'IA ne consiste pas simplement à stocker les prompts du modèle. Il s'agit de pouvoir reconstituer quelle version du système a été utilisée, quelles données et permissions s'appliquaient, qui a approuvé la configuration, quelles évaluations ont soutenu le déploiement et ce qui s'est passé lors de l'exécution concernée.

Pour un agent, cela peut nécessiter l'identité du principal, les appels d'outils, les approbations, les ressources cibles, les changements d'état et les résultats. Pour le RAG, cela peut nécessiter la version du corpus/index, la requête de récupération, les preuves sélectionnées et la provenance. Pour un changement de modèle, cela peut nécessiter les résultats d'évaluation précédents et nouveaux.

Les preuves d'audit doivent être proportionnées. Journaliser chaque token possible peut créer un risque de confidentialité et de sécurité en soi. La gouvernance doit définir quelles preuves sont nécessaires, combien de temps elles sont conservées et qui peut y accéder.

La surveillance ferme la boucle de gouvernance

L'approbation est un instantané. La surveillance en production indique à la gouvernance si les hypothèses qui sous-tendent l'approbation tiennent toujours.

Les signaux utiles dépendent du cas d'usage : régression de qualité, sorties dangereuses, défaillances d'outils, refus de politique, coût inhabituel, latence, plaintes des utilisateurs, dérive, fraîcheur de la récupération, incidents du fournisseur, alertes de sécurité ou nouvelles classifications réglementaires.

La gouvernance doit définir des seuils qui déclenchent une action : enquêter, restreindre, exiger un examen humain, annuler, changer de fournisseur, suspendre ou retirer.

Les incidents liés à l'IA nécessitent un parcours opérationnel défini

Les incidents spécifiques à l'IA peuvent impliquer du contenu préjudiciable, une fuite de données, des actions non autorisées, une défaillance factuelle persistante, une panne de modèle ou de fournisseur, une injection de prompt, une récupération inter-locataires ou un comportement inattendu après une mise à jour de modèle.

Le processus de gestion des incidents doit relier la réponse technique à la responsabilité de gouvernance. Quelqu'un doit être autorisé à désactiver un modèle, retirer un outil, révoquer des identifiants, restreindre des utilisateurs, notifier les fonctions concernées et décider si le système peut être remis en service.

Les enseignements tirés des incidents doivent mettre à jour les politiques, les tests, la classification des risques et les contrôles de plateforme réutilisables plutôt que de rester isolés au sein d'une seule équipe.

L'approvisionnement fait partie de la gouvernance de l'IA

Les organisations peuvent acquérir des capacités d'IA substantielles par le biais d'un approvisionnement SaaS ordinaire. La gouvernance doit donc couvrir les fonctionnalités d'IA achetées ainsi que les systèmes développés en interne.

L'évaluation des fournisseurs peut inclure l'utilisation des données, la conservation, la politique d'entraînement des modèles, les sous-traitants, la sécurité, la notification des incidents, l'exportation et la suppression, le traitement géographique, les changements de version, la continuité de service et la sortie contractuelle.

Une revue de l'architecture technique et une revue de l'approvisionnement doivent partager le même inventaire des systèmes afin que l'approbation commerciale ne s'écarte pas du flux de données réellement déployé.

La supervision humaine doit être conçue, pas simplement déclarée

« Humain dans la boucle » n'a de sens que si l'humain dispose de l'autorité, du temps, de l'information et d'un mécanisme d'intervention utilisable.

Un évaluateur qui ne voit que la recommandation de l'IA mais pas ses preuves, son incertitude ou l'état de sa source peut simplement approuver la sortie sans véritable examen. La gouvernance doit préciser ce que l'évaluateur peut inspecter et quelles actions sont disponibles : approuver, rejeter, modifier, escalader ou arrêter.

La supervision humaine doit également être fondée sur le risque. Les systèmes à faibles conséquences peuvent recourir à l'échantillonnage ou à un examen a posteriori, tandis que les effets secondaires à fortes conséquences peuvent nécessiter une approbation avant exécution.

La gouvernance de la plateforme et la gouvernance des cas d'usage sont différentes

L'approbation de la plateforme doit donc réduire le travail répété, et non éliminer la responsabilité des cas d'usage. « Le modèle est approuvé » est différent de « cette application du modèle est approuvée ».

Gouvernance de l'IA et architecture d'IA d'entreprise

L'architecture d'IA d'entreprise décrit comment les systèmes d'IA, les plateformes, les données, les identités, les fournisseurs, les opérations et les systèmes organisationnels s'articulent ensemble. La gouvernance de l'IA décrit le système de décision et de contrôle qui détermine comment ces architectures peuvent être créées et modifiées.

Les deux sont étroitement couplés. La gouvernance sans architecture peut devenir une politique abstraite. L'architecture sans gouvernance peut produire des systèmes techniquement élégants avec une propriété floue, une adoption non contrôlée des fournisseurs ou des risques non évalués.

La conception la plus solide est bidirectionnelle : les exigences de gouvernance deviennent des contrôles d'architecture, tandis que l'architecture expose les décisions réelles que la gouvernance doit assumer.

Preuves du projet d'origine

Enterprise Aaasaasa 0.1 : la gouvernance comme structure de livraison

Enterprise Aaasaasa 0.1 utilise des jalons définis pour les exigences, l'architecture, le prototype, la validation et la clôture du projet. Cette structure illustre un principe de gouvernance fondamental : les transitions du cycle de vie doivent avoir des livrables et des points de décision explicites plutôt qu'un processus informel de type « construire d'abord, examiner ensuite ».

Le projet suit également les risques tels que la dérive du périmètre, le retard d'architecture et les préoccupations liées à l'IA/RGPD, et identifie les groupes de parties prenantes, notamment le parrainage, le comité de pilotage, l'architecture, la sécurité, le marketing, les API externes et l'hébergement.

Cela ne constitue pas un système de management ISO/IEC 42001. Il s'agit d'une preuve de projet plus restreinte montrant comment la responsabilité, le risque, les jalons et la validation peuvent être intégrés à la livraison technique.

SenseFlow : traçabilité des exigences et des décisions

SenseFlow utilise un parcours structuré allant de l'objectif produit et du besoin utilisateur aux épopées, récits utilisateur, critères d'acceptation, architecture, implémentation et validation. Les enregistrements de décision conservent la décision, la justification, les alternatives, les compromis, le statut et la date/version.

Ce modèle de traçabilité est directement pertinent pour la gouvernance, car un contrôle d'IA doit être relié à l'exigence ou au risque qui l'a justifié. Un système de gouvernance se renforce lorsque la chaîne allant du besoin métier à la décision d'architecture jusqu'à la preuve de validation peut être reconstruite.

Aaasaasa AI Client : permissions et exécution comme configuration gouvernée

Aaasaasa AI Client sépare le fournisseur, le modèle, l'emplacement d'exécution et les permissions plutôt que de les traiter comme un seul « paramètre IA ». Des profils de permissions d'espace de travail centraux régissent l'accès aux outils, Direct Chat n'a pas d'outils de système de fichiers/shell, et les environnements d'exécution compatibles avec les agents fonctionnent sous des profils de permissions explicites.

Cette séparation démontre un modèle de gouvernance important : le choix du modèle et l'autorité d'action doivent être des objets de configuration indépendants. Un modèle plus performant ne reçoit pas automatiquement des permissions plus larges sur le système de fichiers, le shell ou les activités métier.

La preuve d'implémentation est architecturale et ne prétend pas que l'application constitue un système certifié de gouvernance organisationnelle de l'IA.

Modes de défaillance courants de la gouvernance de l'IA

Une gouvernance centrale ne signifie pas centraliser chaque décision

Une organisation mature peut centraliser la politique, les modèles de contrôle et l'escalade tout en déléguant les décisions à faible risque aux équipes produit ou plateforme.

Ce modèle fédéré passe mieux à l'échelle que d'exiger qu'un comité central approuve chaque modification de prompt. La fonction centrale définit les niveaux de risque, les contrôles obligatoires, la politique fournisseur, l'autorité d'exception et les exigences d'audit ; les équipes opèrent de manière autonome à l'intérieur de ces limites.

L'objectif de conception est une responsabilité cohérente, pas une centralisation maximale.

Gouverner le système de gouvernance lui-même

La gouvernance a besoin de retour d'information. Sinon, les contrôles peuvent devenir des rituels coûteux qui ne réduisent pas le risque.

Les métriques de gouvernance ne doivent pas récompenser le volume de paperasse. La mesure utile est de savoir si la qualité des décisions, la traçabilité, la détection des risques et la livraison sécurisée s'améliorent.

Une séquence pratique de mise en œuvre de la gouvernance de l'IA

Liste de contrôle de la gouvernance de l'IA

Idées fausses courantes

Cas limites et limitations

Les très petites organisations peuvent ne pas avoir besoin d'une fonction dédiée de gouvernance de l'IA. Les mêmes principes peuvent être mis en œuvre via des décisions d'architecture légères, des registres de risques, des mappages de propriétaires et des portes de release.

Les organisations hautement réglementées peuvent avoir besoin de beaucoup plus de gouvernance formelle, d'assurance indépendante, de processus de conformité documentés et d'interprétation juridique que ce que décrit cet article au niveau architectural.

Les modèles open source et auto-hébergés réduisent certaines dépendances fournisseur mais en créent d'autres : correctifs, provenance du modèle, évaluation, sécurité de l'infrastructure, licences et propriété opérationnelle.

Les modèles d'IA à usage général peuvent être utilisés dans de nombreux contextes. La gouvernance doit éviter de supposer que les contrôles au niveau du fournisseur déterminent entièrement le risque de l'application en aval.

Aucun cadre de gouvernance ne garantit qu'un système d'IA est sûr ou correct. La gouvernance améliore la responsabilité et la qualité des décisions ; la validation technique, la surveillance et le jugement humain restent nécessaires.

Qu'est-ce qui changerait cette réponse ?

L'ensemble exact des contrôles change selon la loi, le secteur, la taille de l'organisation, la sensibilité des données, l'autonomie, le modèle de déploiement et les conséquences métier.

Le NIST révise actuellement l'AI RMF 1.0, de sorte que la terminologie ou les pratiques recommandées du NIST pourraient changer à l'avenir. Les normes ISO peuvent également être révisées, et les orientations et détails de transition de l'EU AI Act continuent d'évoluer.

Le principe architectural stable est que les décisions d'IA nécessitent des responsables explicites, des preuves, des autorisations, un traitement des risques et une revue du cycle de vie plutôt que d'être cachées dans la configuration du modèle ou de l'application.

Connaissances canoniques associées

La gouvernance de l'IA dépend de concepts déjà séparés ailleurs dans ce graphe de connaissances : la Source de Vérité détermine l'autorité, le RBAC et l'isolation des locataires limitent l'accès, l'ingénierie du contexte contrôle les informations visibles par le modèle, et l'architecture agentique définit comment les outils et les actions entrent dans une boucle d'exécution.

L'Architecture d'IA d'Entreprise est le concept parent d'architecture organisationnelle. La gouvernance est la couche de contrôle opérationnel qui détermine comment ces composants d'IA d'entreprise peuvent être introduits, modifiés et retirés.

Les systèmes agentiques augmentent les exigences de gouvernance car les décisions du modèle peuvent devenir des effets secondaires réels. Les contrôles de permission, d'approbation et d'audit doivent donc exister en dehors du modèle lui-même.

Questions fréquentes

Glossaire

Conclusion

La gouvernance de l'IA est le plan de contrôle organisationnel autour de l'IA. Elle donne des noms et des preuves aux décisions qui autrement restent cachées dans le code, les paramètres du fournisseur, les invites ou le jugement informel de l'équipe.

Une gouvernance solide relie l'ensemble du système : l'objectif métier, les modèles, les fournisseurs, l'autorité sur les données, l'identité, les permissions, l'évaluation, le risque, la conformité, la surveillance, les incidents, les changements et le retrait.

L'objectif pratique n'est pas un processus maximal. C'est la structure de gouvernance minimale qui permet de rendre les décisions importantes en matière d'IA attribuées, fondées sur des preuves, exécutoires, vérifiables et auditables tout au long du cycle de vie.

Sources primaires et références actuelles

Les sources ci-dessous fournissent un ancrage externe actuel pour la gestion, le risque et la réglementation de l'IA. Les sections du projet sont des preuves originales de mise en œuvre/projet et sont explicitement distinguées des normes formelles ou des systèmes de gouvernance certifiés.