Le modèle opérationnel AI : responsabilité, données, contrôles et suivi des avantages

1. Gouverner un système à l'échelle de l'entreprise plutôt qu'un ensemble d'outils AI

La première question du conseil d'administration concernant AI devrait porter sur le résultat opérationnel que l'entreprise entend modifier. Une licence, un modèle, un assistant ou un projet pilote constituent des intrants. La valeur apparaît lorsque l'entreprise modifie une décision, un processus, un produit ou une proposition client et peut maintenir ce changement dans les limites de risque approuvées. Le modèle opérationnel relie la capacité technologique à une action métier dont les responsables sont redevables.

Cette distinction est importante car un portefeuille peut sembler actif tout en restant économiquement faible. Les équipes peuvent compter des démonstrations, des utilisateurs, des prompts ou des documents générés. Ces mesures en disent peu sur les revenus, les coûts, la trésorerie, le service, la qualité ou le risque. Un cas d'usage peut bien fonctionner lors d'un test contrôlé et échouer en production parce que l'accès aux données, l'intégration aux flux de travail, l'adoption par les employés, la fiabilité des fournisseurs ou l'acceptation par les clients sont insuffisants.

Les Principes de l'OCDE relatifs à AI appellent à la responsabilité, à la traçabilité et à une gestion systématique des risques tout au long du cycle de vie de AI [1]. Le NIST organise la gestion des risques liés à AI autour des fonctions Gouverner, Cartographier, Mesurer et Gérer [3][4]. L'ISO/IEC 42001 conçoit la gestion de AI comme un système de politiques, d'objectifs et de processus continuellement améliorés [7]. Ces sources étayent une conclusion pratique pour l'entreprise : la gouvernance de AI doit faire partie du modèle opérationnel plutôt que d'y être annexée comme un appendice de conformité.

Une chaîne opérationnelle complète contient cinq objets liés. La stratégie identifie la décision ou le flux de travail qu'il vaut la peine de modifier. Une charte de cas d'usage définit le périmètre, le responsable et le résultat attendu. Les contrôles des données et des modèles déterminent si la capacité peut fonctionner de manière responsable. Les jalons du cycle de vie déterminent si elle peut progresser. Un registre des bénéfices montre si le changement s'est matérialisé dans le compte de résultat, les flux de trésorerie, le bilan, le résultat de service ou la position de risque. Le conseil d'administration reçoit une vue intégrée couvrant l'ensemble des cinq.

Chaque couche dispose d'un responsable nommé, d'un ensemble de preuves, d'un droit de décision et d'une fréquence de revue.

2. Établir l'inventaire à l'échelle de l'entreprise avant de prioriser le portefeuille

La direction ne peut pas gouverner ce qu'elle n'a pas identifié. L'inventaire doit couvrir les modèles développés en interne, les modèles hébergés en externe, la AI intégrée dans les logiciels d'entreprise, les assistants destinés aux employés, les composants de décision automatisée, les modèles analytiques, les agents, les produits intégrant des modèles et les expérimentations significatives. Il doit également consigner les usages non déclarés découverts au moyen d'enquêtes, de journaux d'accès, de données d'achat, de contrôles réseau et d'une revue métier.

L'unité de référence doit être le cas d'usage plutôt que le nom du fournisseur. Un modèle polyvalent peut prendre en charge le service client, la programmation, le marketing et la revue de contrats, avec des données, des utilisateurs, des décisions et des conséquences différents. À l'inverse, un cas d'usage peut dépendre de plusieurs modèles, services de récupération de données, sources de données et applications de flux de travail. L'inventaire doit représenter ces deux types de relations.

Chaque fiche doit comporter un responsable métier, un responsable technique, un niveau de risque, les utilisateurs prévus, les parties prenantes concernées, le rôle dans la décision, les catégories de données, les dépendances aux modèles et aux fournisseurs, la juridiction, le statut dans le cycle de vie, la date d'approbation, les exigences de surveillance, le responsable des bénéfices et les modalités de mise hors service. La fiche doit préciser si le système recommande, rédige, prédit, classe, décide, agit ou contrôle un autre système. L'autonomie et la réversibilité comptent souvent davantage que la sophistication du modèle.

L'inventaire facilite aussi l'économie du portefeuille. Les licences en doublon, les pilotes qui se chevauchent et les pipelines de données incompatibles peuvent être identifiés. Une capacité commune peut servir plusieurs cas d'usage, tandis qu'un modèle spécialisé coûteux peut n'avoir qu'un responsable pour un usage étroit. La direction peut alors répartir les coûts partagés, négocier avec les fournisseurs et décider quelles plateformes méritent d'être mises à l'échelle.

Tableau 1. Inventaire minimal AI à l'échelle de l'entreprise

L'inventaire réunit les éléments probants opérationnels, techniques, de risque et financiers dans un registre contrôlé unique.

3. Concevoir le modèle opérationnel autour de six responsabilités

Un programme AI nécessite plus qu'un comité de pilotage. Six responsabilités doivent être visibles. Le conseil approuve l'appétit au risque, les investissements significatifs et la supervision. Le sponsor exécutif porte la thèse du portefeuille. Le responsable métier porte l'adoption du flux de travail et le résultat opérationnel. Le responsable technique porte l'architecture, la mise en œuvre et les performances du service. Les fonctions de contrôle indépendantes remettent en question les éléments probants relatifs au risque, à la confidentialité, à la sécurité, au juridique et à la conformité. La finance contrôle la référence des bénéfices et valide la valeur réalisée.

Les rôles peuvent être cumulés dans une organisation de taille plus réduite, mais les responsabilités doivent rester distinctes. La personne qui propose un cas d'usage peut préparer les éléments de preuve. Un déploiement significatif bénéficie toujours d'une remise en question par une personne qui n'a pas construit le modèle ni ne porte le bénéfice prévisionnel. L'indépendance peut être proportionnée au risque, au coût et à la taille de l'organisation.

Les droits de décision doivent être rattachés aux événements du cycle de vie. Un propriétaire de produit peut approuver une modification de configuration à faible impact. Un comité des risques peut approuver un déploiement à fort impact. Le conseil d'administration peut se réserver les décisions impliquant un capital significatif, des conséquences sur les effectifs, l'éligibilité des clients, la sécurité, des résultats réglementés ou une exposition réputationnelle. Le pouvoir de suspension d'urgence doit être explicite et immédiatement disponible.

Les comités doivent décider plutôt que recevoir des présentations. Chaque point à l'ordre du jour doit indiquer la décision demandée, les options, les éléments de preuve, le responsable, les limites non résolues et la prochaine revue. Le bureau du portefeuille maintient les normes et les registres. Il ne doit pas reprendre à son compte la responsabilité du dirigeant dont la fonction utilise le système.

Tableau 2. Droits de décision au sein du modèle opérationnel AI

R signifie responsable, A redevable, C consulté et I informé ; la répartition exacte doit refléter la taille de l'organisation et les exigences applicables.

4. Transformer la stratégie en une charte de cas d'usage encadrée

La charte constitue le plus petit contrat utile entre la stratégie, l'exécution, le contrôle et la finance. Elle définit le problème métier, le flux de travail actuel, les utilisateurs visés, les parties affectées, le rôle décisionnel, l'intervention proposée, le résultat attendu, les contraintes, les dépendances, le propriétaire, l'enveloppe de coûts, le plan de preuves et les conditions de sortie. Elle doit être assez concise pour être pilotée et assez précise pour être testée.

Le flux de travail actuel mérite une attention égale à celle accordée au modèle proposé. La direction a besoin, avant l'automatisation, du temps de cycle de référence, du taux d'erreur, du taux de conversion, du coût, de la charge de contrôle et du résultat client. Des processus faibles peuvent devenir des processus faibles plus rapides. Un cas d'usage doit donc identifier l'étape qui change, les décisions qui restent humaines et le processus en aval qui absorbe le résultat.

La charte doit indiquer la finalité prévue du modèle et les usages interdits. Un système conçu pour résumer des documents ne doit pas dériver vers des décisions d'éligibilité client sans une nouvelle évaluation. Un assistant commercial ne doit pas ingérer des documents de transaction confidentiels simplement parce que son interface le facilite. Des limites claires facilitent la conception des accès, la surveillance et la formation des employés.

Les critères de succès doivent couvrir quatre dimensions : la performance technique, l'adoption opérationnelle, l'efficacité du contrôle et le résultat financier ou de service. Un cas d'usage ne progresse que lorsque des preuves existent pour les dimensions pertinentes de son niveau. Cela évite que des scores de modèle impressionnants ne fassent passer un dossier opérationnel fragile au-delà du point de contrôle.

La charte doit également définir une hypothèse de décision. Elle précise qui prendra une décision différente, quelles preuves le système apporte, en combien de temps la décision doit être prise et comment la direction saura que le changement a amélioré le résultat. Cela oblige le sponsor financier à identifier l'action humaine ou automatisée entre la sortie du modèle et la valeur. Une prévision qui s'arrête à la qualité de la sortie reste incomplète.

Les critères de sortie sont tout aussi importants. La direction peut arrêter un cas d'usage lorsque le problème a disparu, que l'intervention ne peut pas atteindre son seuil, que l'économie du fournisseur a changé, que la charge de contrôle dépasse la valeur ou qu'une amélioration de processus plus simple est plus performante. La charte doit préciser comment les accès, les données, les enregistrements, les contrats et les dépendances en aval seront clôturés. Une trajectoire de sortie planifiée renforce la discipline capitalistique au début de l'investissement.

5. Classer les cas d'usage par conséquences, autonomie, exposition et réversibilité

La classification par niveau de risque doit déterminer l'intensité de la gouvernance. La classification peut prendre en compte la conséquence d'une erreur, le degré d'automatisation, les parties prenantes affectées, l'ampleur de l'exposition, la sensibilité des données, le contexte juridique, la nouveauté du modèle, l'explicabilité, la dépendance externe et la réversibilité. Un assistant de rédaction utilisé par des employés formés diffère sensiblement d'un système autonome qui modifie l'accès client ou déplace des fonds.

Le niveau doit être associé au cas d'usage dans son contexte. Un même modèle peut avoir un faible impact pour un brainstorming interne et un impact élevé lorsque sa sortie influence le recrutement, le crédit, la tarification, la sécurité ou la santé. Cette vision par cas d'usage s'aligne sur les approches fondées sur le risque que l'on trouve dans la loi AI de l'UE [9][10], le cadre NIST AI RMF [3], l'examen par l'ASIC de la gouvernance des titulaires de licence [27] et le cadre de risque de modèle de l'OSFI [29].

Une structure pratique peut comporter quatre niveaux internes. Le niveau un couvre une assistance délimitée à faible conséquence et avec une revue humaine claire. Le niveau deux couvre des recommandations opérationnelles ou des contenus susceptibles d'affecter les clients ou les résultats financiers. Le niveau trois couvre les décisions importantes, les données sensibles, une forte autonomie ou des flux de travail réglementés. Le niveau quatre couvre les activités interdites ou hors appétit. Les niveaux internes ne doivent jamais être présentés comme des classifications juridiques sans une analyse propre à la juridiction.

La classification par niveau est dynamique. Une croissance du volume, de nouvelles données, une mise à jour fournisseur, une autonomie élargie, de nouveaux groupes d'utilisateurs ou un incident majeur peuvent modifier la classification. L'inventaire doit donc consigner la base, l'approbateur et la date de prochaine revue.

La matrice est un outil de gestion ; les classifications juridiques nécessitent une analyse distincte.

Tableau 3. Exemples de déclencheurs de niveau et de contrôles minimaux

La direction doit adapter le déclencheur et l'ensemble de contrôles au droit applicable, au secteur et à l'appétence au risque.

6. Considérer les droits sur les données et le lignage comme des prérequis opérationnels

AI la performance et la responsabilité dépendent de données que l'organisation peut identifier, utiliser, protéger et reproduire. Le dossier de contrôle des données doit consigner la source, le propriétaire, la finalité autorisée, la base légale ou contractuelle, la classification, la localisation géographique, la conservation, les tests de qualité, les transformations, le lignage et les utilisations en aval. Il doit également identifier les données personnelles, confidentielles, couvertes par le secret professionnel, soumises au droit d'auteur, sous licence et sensibles.

Les droits sur les données peuvent être aussi importants que la qualité des données. Un jeu de données techniquement utile peut être indisponible pour l'entraînement de modèles, la récupération ou le traitement par un fournisseur. Les accords clients, les conditions d'emploi, les droits sur les bases de données, la propriété intellectuelle, les règles de confidentialité et les obligations sectorielles peuvent limiter l'utilisation. L'approbation juridique doit être rattachée à une finalité et à un flux de données précis plutôt qu'à l'étiquette générale de AI.

Le lignage doit suivre les données depuis la source, en passant par la préparation, la récupération, le contexte de prompt, l'interaction avec le modèle, le stockage des sorties et la décision en aval. Cela facilite la reproductibilité, l'analyse d'incident, la suppression, la revue des accès et l'attribution des bénéfices. L'OCDE associe la responsabilité liée à AI à la traçabilité entre les jeux de données, les processus et les décisions [1][2]. La directive finale E-23 de l'OSFI souligne de la même manière l'adéquation, la provenance et la gouvernance des données à l'échelle de l'entreprise pour les modèles [29].

Les données de production doivent être comparées aux données de développement et de test. L'évolution de la population, les champs manquants, les nouvelles catégories, la saisonnalité et les contournements opérationnels peuvent affaiblir un modèle sans modifier son code. La conception du suivi nécessite des seuils de qualité des données et un responsable capable de corriger le processus à la source.

7. Maîtriser toute la chaîne de dépendance aux modèles et aux fournisseurs

Le système concerné s'étend généralement au-delà d'un modèle unique. Il peut inclure un modèle de fondation, des embeddings, une base de données de récupération, une couche d'orchestration, un filtre de sécurité, des règles métier, une application, un service cloud, une revue humaine et un système en aval. Un modèle opérationnel doit consigner la chaîne et identifier la partie qui contrôle chaque composante.

La due diligence des fournisseurs doit couvrir l'utilisation prévue, l'architecture de service, le traitement des données, les sous-traitants, les versions des modèles, la sécurité, les preuves de tests, les conditions de propriété intellectuelle, la confidentialité, la conservation, la notification des incidents, les niveaux de service, les droits d'audit, le préavis de modification, la continuité d'activité, la résiliation et la restitution des données. Le nom d'un fournisseur de premier plan ne remplace pas une due diligence propre au cas d'usage.

La configuration peut modifier sensiblement le comportement. Les prompts système, les sources de récupération, la température, les outils, les autorisations, la mémoire, les limites d'action et les règles de repli doivent relever d'une gestion contrôlée des changements. Un fournisseur peut mettre à jour le modèle sous-jacent sans que le nom de l'application change. L'entreprise doit définir un déclencheur explicite pour les nouveaux tests et la nouvelle approbation.

La concentration doit être visible au niveau du portefeuille. Plusieurs flux de travail critiques peuvent dépendre d'un même fournisseur de modèles, d'une même plateforme cloud ou d'un même service de données. Le conseil d'administration doit comprendre les dépendances liées aux pannes, à la tarification, aux contrats et à la stratégie, puis décider quelles solutions alternatives, solutions de repli ou procédures manuelles sont proportionnées.

Tableau 4. Éléments probants tout au long de la chaîne de dépendance liée à AI

L’ensemble des éléments de preuve doit être proportionné au niveau du cas d’usage et à la capacité de l’entreprise à contrôler chaque composante.

8. Fonder les décisions de développement interne, d’achat et de configuration sur l’économie globale d’exploitation

La décision de développer en interne ou d’acheter doit intégrer la différenciation stratégique, l’avantage lié aux données, la complexité d’intégration, les exigences de contrôle, le délai de création de valeur, les talents, l’infrastructure, la dépendance vis-à-vis des fournisseurs et le coût total du cycle de vie. Le pilote le moins cher peut devenir une dépendance opérationnelle coûteuse lorsque l’intégration, l’assurance, la surveillance et la gestion du changement sont prises en compte.

L’achat d’un modèle ne transfère pas la responsabilité du cas d’usage. L’entreprise reste responsable de la finalité, des utilisateurs, des données, du flux de travail, des décisions, de la surveillance et du résultat client. Le développement interne offre un meilleur contrôle sur certains composants et crée des obligations en matière d’ingénierie, de sécurité, de documentation, de maintenance et de continuité des talents.

La configuration est souvent la voie privilégiée en entreprise. L’entreprise combine des modèles externes avec des données propriétaires, des prompts, des règles et des flux de travail. Cela peut créer une valeur différenciée sans entraîner un modèle de fondation. Cela crée aussi un système dont la performance dépend de nombreux composants modifiables. Le modèle opérationnel doit gouverner l’ensemble configuré.

Le dossier d’investissement doit distinguer les capacités de plateforme réutilisables des dépenses propres à un cas d’usage. L’identité, la journalisation, l’évaluation, l’accès sécurisé aux données et l’orchestration peuvent servir à plusieurs cas. La finance peut répartir les coûts partagés de manière transparente, tandis que la direction évite d’imputer l’intégralité de la plateforme à chaque cas d’usage précoce.

9. Utiliser des jalons de cycle de vie qui exigent des preuves plutôt que de l’enthousiasme

Le cycle de vie peut comporter six jalons : découverte, conception, validation, déploiement, montée en charge et retrait. Chaque jalon doit avoir des critères d’entrée, des preuves requises, une autorité de décision, des approbations conditionnelles et une voie d’exception limitée dans le temps. Un jalon se clôt lorsque les preuves soutiennent l’exposition suivante, et non lorsque l’équipe projet a terminé une présentation.

La découverte confirme le problème, le propriétaire et la situation de référence. La conception définit l’architecture des flux de travail, des données, du système et des contrôles. La validation teste la performance technique, le processus humain, la sécurité et les droits pertinents. Le déploiement introduit une exposition contrôlée en production. La montée en charge exige des preuves que l’adoption, les contrôles et les bénéfices restent solides à plus grande échelle. Le retrait supprime les accès, les dépendances et les données conservées de manière contrôlée.

Le guide pratique du NIST propose des actions couvrant la gouvernance, la cartographie, la mesure et la gestion [4]. Le profil NIST generative AI ajoute une attention aux risques tels que la confabulation, l’intégrité de l’information, la confidentialité, la sécurité et la propriété intellectuelle [5]. Le jalon de cycle de vie doit convertir ces considérations en preuves propres au cas d’usage.

Une approbation conditionnelle peut être utile lorsque les limites sont connues et contenues. Le document doit préciser le périmètre, la mesure d’atténuation, le responsable, la date d’expiration et les preuves requises pour le renouvellement. Les exceptions sans échéance permettent aux faiblesses d’un pilote de devenir une caractéristique permanente de la conception en production.

L’exposition ne doit augmenter qu’une fois les preuves et l’autorité pertinentes réunies.

10. Valider le système dans le contexte dans lequel il fonctionnera

La validation doit tester le système, le flux de travail et le comportement des utilisateurs au regard de l’usage prévu. L’évaluation technique peut inclure l’exactitude, la fiabilité, la robustesse, les biais, l’explicabilité, la confidentialité, la sécurité, la latence et le coût. L’évaluation opérationnelle doit examiner l’escalade, la revue humaine, les actions en aval, les cas limites, le volume d’exceptions et la reprise.

Le jeu de test doit refléter la population en production et les modes de défaillance significatifs. Une performance moyenne peut masquer de mauvais résultats pour des événements rares, des groupes de clients spécifiques ou des cas à forte valeur. Les seuils doivent être liés aux conséquences. Une erreur de rédaction mineure et une instruction de paiement incorrecte exigent des tolérances différentes.

La contestation indépendante doit être proportionnée. L'évaluateur doit comprendre le cas d'usage, les données, le modèle, le flux de travail et les exigences applicables, puis évaluer si les éléments probants justifient le déploiement. Pour les cas d'usage à impact plus élevé, l'évaluateur doit pouvoir reproduire les tests clés et contester le choix de la métrique, de la population, du seuil et de la mesure d'atténuation.

Les systèmes génératifs nécessitent une évaluation qualitative et adverse ainsi que des scores de référence. Les tests peuvent couvrir les affirmations non étayées, l'injection de prompts, la fuite de données confidentielles, le contenu préjudiciable, le mésusage d'outils, les réponses incohérentes et le comportement de refus. Le profil génératif AI du NIST et les orientations en matière de développement sécurisé de la CISA et de partenaires internationaux constituent des points de référence pertinents [5][17][18].

La vérité terrain doit être gouvernée. Les libellés et les réponses attendues peuvent comporter des divergences entre experts, des politiques obsolètes ou des biais historiques. Le dossier de validation doit identifier qui a créé les cas de test, la date de la source, la méthode de revue, l'incertitude et la couverture de la population. Lorsqu'une réponse exacte n'est pas disponible, la direction peut évaluer si le système cite des éléments probants faisant autorité, exprime son incertitude et procède aux escalades appropriées.

L'évaluation doit également tenir compte de la fréquence et du coût. Un assistant à fort volume peut nécessiter une surveillance automatisée ainsi qu'une revue d'experts par échantillonnage. Une décision importante rare peut justifier un examen complet du cas. Le modèle opérationnel doit prévoir un budget pour une évaluation continue plutôt que de traiter le test de préproduction comme un coût de projet ponctuel. Les éléments probants de validation perdent leur pertinence lorsque le modèle, les données, le flux de travail ou la population concernée changent.

11. Définir la supervision humaine comme un dispositif décisionnel

La supervision humaine doit préciser qui examine quoi, avec quelles informations, sous quelle contrainte de temps et avec quelle autorité. Une instruction générique visant à maintenir un humain dans la boucle peut échouer lorsque l'évaluateur ne possède pas l'expertise requise, fait face à trop de résultats, dispose d'éléments probants faibles ou a des incitations à accepter la recommandation de la machine.

Le dispositif peut distinguer l'approbation, la vérification, le traitement des exceptions et l'appel. Un évaluateur peut approuver chaque résultat à fort impact, échantillonner les résultats à faible impact, enquêter sur les dépassements de seuil et fournir une voie d'escalade aux parties concernées. L'évaluateur doit avoir accès aux éléments probants sources et aux limites connues, et pas seulement à une réponse soignée du modèle.

Le biais d'automatisation doit être traité comme un risque opérationnel. La formation, la conception de l'interface et l'échantillonnage qualité peuvent tester si les employés contestent les résultats. Les dérogations doivent être consignées avec un motif afin que la direction puisse distinguer un jugement sain d'une pratique incohérente. Des schémas répétés de dérogation peuvent révéler un problème de modèle, de données ou de flux de travail.

L'autorité doit correspondre aux conséquences. Un utilisateur peut corriger un brouillon. Un responsable fonctionnel peut suspendre un flux de travail. Un propriétaire de risque peut exiger un contrôle. Le conseil d'administration ou un comité réservé peut retirer un cas d'usage important. L'action doit rester possible pendant une panne ou un incident.

12. Déployer au moyen d'une mise en production contrôlée et d'une gestion des changements

Le déploiement en production doit utiliser des environnements approuvés, des contrôles d'accès, la gestion des versions, la journalisation, la séparation des tâches, le retour arrière, la planification des capacités, la surveillance des services et des dossiers de mise en production. La décision de déploiement doit confirmer que les responsables opérationnels, les équipes de support et les utilisateurs sont prêts en même temps que la technologie.

Le dossier de mise en production doit identifier les versions du modèle et des composants, la configuration, les sources de données, les tests, les limites, les approbations, les seuils de surveillance, les contacts en cas d'incident et la solution de repli. Cela crée une base de référence reproductible. Une modification importante doit déclencher le sous-ensemble approprié de nouveaux tests et d'approbations.

La classification des changements peut distinguer les changements de routine, significatifs et d'urgence. Une correction de formulation d'un prompt peut suivre un circuit standard. Une nouvelle autorisation d'outil, une nouvelle famille de modèles, une nouvelle source de données, une nouvelle action autonome ou un nouveau groupe de clients concerné peut nécessiter une nouvelle évaluation des risques. Les changements d'urgence doivent être examinés après l'événement.

Le déploiement doit également protéger le flux de travail non-AI. La solution de repli manuelle, la continuité de service et l'accès aux enregistrements sont importants lorsqu'un fournisseur est indisponible ou qu'un modèle est suspendu. La résilience doit être testée avant que le système ne devienne critique.

13. Surveiller les performances, la dérive, les incidents et l'efficacité des contrôles

La surveillance doit suivre l'hypothèse du cas d'usage. Les mesures techniques peuvent inclure la précision, le type d'erreur, la calibration, la dérive, la latence, la disponibilité, le coût des jetons ou du calcul et les événements de sécurité. Les mesures opérationnelles peuvent inclure l'adoption, le délai d'achèvement, le retraitement, les dérogations, les réclamations, les exceptions et les défauts en aval. Les mesures de bénéfice doivent suivre le résultat financier ou de service maîtrisé.

Les seuils exigent des actions. Une limite jaune peut nécessiter une investigation et une mise à l'échelle restreinte. Une limite rouge peut nécessiter une suspension, un retour arrière ou un repli manuel. Le propriétaire, le délai de réponse et la voie d'escalade doivent être documentés. Un tableau de bord sans logique d'action relève de l'observation plutôt que du contrôle.

La gestion des incidents doit classer les préjudices, contenir l'exposition, préserver les preuves, notifier les parties internes et externes lorsque requis, corriger le système et confirmer le rétablissement. Elle doit inclure les incidents de fournisseurs et les quasi-incidents. Les enseignements doivent mettre à jour les tests, les seuils, la formation et les normes du portefeuille.

La surveillance doit tenir compte des versions. Les performances antérieures à un changement de modèle ou de données ne doivent pas être mélangées aux performances postérieures. L'enregistrement doit permettre l'analyse par cohorte et expliquer quelle population, version et quel flux de travail ont produit un résultat.

Les valeurs correspondent à des hypothèses de gestion fictives utilisées pour illustrer une vue équilibrée de la surveillance.

14. Intégrer la sécurité et la résilience à la conception du produit

Les systèmes AI créent des risques logiciels et de données familiers, parallèlement à des chemins d'attaque propres aux modèles. Les menaces peuvent inclure l'injection de prompt, l'empoisonnement des données, l'accès non sécurisé aux outils, le vol de modèle, la divulgation de données sensibles, les entrées adversariales, les sorties non sûres et la compromission des dépendances. La sécurité doit donc commencer par l'architecture et l'usage prévu.

Le modèle de menace doit identifier les actifs, les acteurs, les frontières de confiance, les interfaces et les utilisations abusives potentielles. Les contrôles peuvent inclure des environnements approuvés, le moindre privilège, la gestion des entrées et des sorties, la gestion des secrets, les restrictions réseau, les autorisations de récupération, les listes d'autorisation d'outils, les contrôles de contenu, la journalisation, la détection d'anomalies, le red teaming et la réponse aux incidents. L'ensemble correct dépend des conséquences et de l'exposition.

Les systèmes agentiques méritent une attention particulière car ils peuvent appeler des outils et modifier l'état externe. Les autorisations, les limites de transaction, les étapes de confirmation, la séparation des tâches et les actions réversibles doivent être explicites. La capacité d'un modèle à générer un plan correct ne lui confère pas l'autorité de l'exécuter.

Les orientations en matière de sécurité dès la conception de la CISA, du NCSC britannique et de partenaires internationaux mettent l'accent sur la sécurité à toutes les étapes de la conception, du développement, du déploiement et de l'exploitation [17][18]. Le modèle opérationnel doit les traduire en preuves de franchissement de jalon et en un responsable de la sécurité clairement désigné et redevable.

15. Intégrer la confidentialité, la propriété intellectuelle et les registres dans le flux de travail

L'analyse de confidentialité doit suivre le flux de données réel et les personnes concernées. La direction doit comprendre quelles données personnelles entrent dans les prompts, les systèmes de récupération, les journaux et les sorties ; où elles circulent ; qui peut y accéder ; combien de temps elles sont conservées ; et comment les droits peuvent être exercés. Un changement de finalité et l'utilisation de décisions automatisées peuvent nécessiter une analyse supplémentaire.

Les contrôles en matière de propriété intellectuelle devraient couvrir les données d'entrée, les données d'entraînement ou de fine-tuning, les sorties générées, les conditions des fournisseurs, les composants open source, les travaux des employés et les contenus des clients. L'entreprise devrait définir quand le contenu généré peut être publié, intégré à des produits, utilisé à l'appui de conseils ou partagé à l'extérieur.

La politique de gestion documentaire devrait préserver les décisions et les preuves tout en respectant les durées de conservation. Les approbations importantes, les tests, les versions de modèles, les prompts ou configurations, les exceptions, les incidents et la validation des bénéfices peuvent nécessiter une conservation contrôlée. Les données conversationnelles courantes peuvent suivre un calendrier différent.

Le règlement AI de l'UE, les orientations associées en matière de transparence, les orientations britanniques en matière de protection des données, les cadres éthiques de UAE et d'Arabie saoudite et les documents de gouvernance de Singapour illustrent l'importance croissante de la traçabilité, de la transparence et d'un usage responsable [9][11][15][20][21][22][25][26]. L'applicabilité et l'effet juridique dépendent du système, du rôle et de la juridiction concernés.

16. Construire l'argumentaire de bénéfices à partir d'une base de référence contrôlée et d'un contrefactuel

Le suivi des bénéfices commence avant le déploiement. La charte devrait consigner le processus actuel, les volumes, la main-d'œuvre, les coûts, les délais de cycle, la qualité, la conversion, le service et le résultat en matière de risque. Elle devrait aussi définir le contrefactuel : ce que la direction attend en l'absence d'intervention. Une simple comparaison avant-après peut attribuer à tort à AI la croissance du marché, les évolutions de prix, d'effectifs ou de processus.

Chaque bénéfice devrait avoir une formule, une source de données, une fréquence, un responsable et une méthode de validation. Le temps gagné ne devient une valeur financière que lorsque l'entreprise modifie sa capacité, ses coûts, son débit ou son service. Une réduction prévue du temps de traitement peut être utile sur le plan opérationnel. Elle ne devrait pas être présentée comme EBITDA tant que le lien avec les effectifs, la production ou les dépenses évitées n'est pas démontré.

Les bénéfices de revenus exigent une discipline similaire. Un processus de vente assisté par AI peut influencer la qualité des prospects, la conversion, le prix, la fidélisation ou la capacité des représentants. L'entreprise devrait identifier le mécanisme, comparer des cohortes lorsque cela est faisable, neutraliser l'effet des autres changements et éviter de compter les mêmes revenus dans plusieurs initiatives.

La vision du coût complet devrait inclure les licences, la puissance de calcul, la mise en œuvre, l'intégration, la préparation des données, l'assurance, la sécurité, la formation, le support, la gestion du changement et la surveillance continue. Les coûts des plateformes partagées devraient être répartis de manière cohérente. Les coûts de sortie et la sensibilité aux prix des fournisseurs doivent figurer dans le dossier.

L'attribution peut recourir à plusieurs dispositifs. Un déploiement aléatoire peut fournir des preuves solides lorsqu'il est éthique et opérationnellement réalisable. Une mise en œuvre progressive, des cohortes appariées, des séries temporelles interrompues ou une décomposition au niveau des processus peuvent être plus adaptées ailleurs. La méthode retenue devrait être précisée avant l'examen des résultats, les limites et les changements concomitants étant consignés. La direction devrait éviter de choisir, après coup, la méthode qui produit le chiffre le plus favorable.

Les bénéfices peuvent être des résultats financiers, de service, de risque ou de capacité. Ils ne devraient pas être convertis de force en estimation monétaire lorsque les éléments probants ne le justifient pas. Une réduction maîtrisée de la variabilité des réponses ou une meilleure traçabilité peut compter pour le conseil d'administration même lorsque la finance ne peut pas valider d'effet immédiat sur le compte de résultat. Le registre peut présenter le résultat opérationnel et sa pertinence décisionnelle tout en préservant la frontière autour de la valeur financière.

Les orientations sur les bénéfices dans le secteur public fournissent un principe général utile : les bénéfices doivent être identifiés, définis, suivis, réalisés et maintenus tout au long du cycle de vie, avec des responsables redevables et une assurance [31][32]. La même discipline améliore l'allocation du capital des entreprises privées.

Tableau 5. Registre des bénéfices contrôlés de AI

Les valeurs prévisionnelles, observées et validées par la finance doivent rester distinctes.

17. Traduire les éléments probants opérationnels en un pont entre compte de résultat, trésorerie et valeur

La fonction Finance doit tenir un pont entre le bénéfice opérationnel brut et le résultat économique validé. Commencer par la variation observée de la production ou de la performance. Retirer les effets de volume, de mix, de prix, de marché et autres effets concomitants. Déduire les coûts de fonctionnement, l'amortissement de la mise en œuvre le cas échéant, le coût de contrôle incrémental et l'effet de déplacement. Identifier si le résultat atteint le chiffre d'affaires, la marge brute, les charges d'exploitation, le fonds de roulement, les dépenses d'investissement ou le risque.

Le traitement comptable doit rester distinct de la mesure des bénéfices à des fins de gestion. L'IAS 38 contient des critères de comptabilisation des actifs incorporels, et l'IASB a continué d'examiner des questions relatives aux données et solutions liées à AI [33]. La direction doit obtenir un avis comptable plutôt que de supposer qu'un investissement ou un bénéfice décrit en interne détermine le traitement des états financiers.

Le pont des bénéfices devrait utiliser des vues par période, cumulées et en rythme de croisière. Un cas d'usage peut créer une charge ponctuelle de mise en œuvre, un coût récurrent et un bénéfice récurrent ultérieur. Le calendrier de trésorerie peut différer de la charge comptable. Le conseil d'administration a besoin de ces trois dimensions pour allouer le capital.

La confiance dans les prévisions doit être explicite. Une fourchette avec des facteurs explicatifs définis est plus utile à la décision qu'un chiffre précis unique fondé sur des hypothèses d'adoption fragiles. Les analyses de sensibilité peuvent montrer l'adoption par les utilisateurs, le volume de tâches, le prix du fournisseur, le taux d'erreur et le délai de montée en charge.

Les valeurs sont des hypothèses managériales hypothétiques et ne représentent ni un résultat ni une prévision pour un client.

18. Traiter l'adoption et la refonte des flux de travail comme faisant partie de l'investissement

Le bénéfice de AI dépend de l'évolution du travail. L'adoption doit être définie comme l'utilisation correcte dans le flux de travail prévu, et non comme une activité de connexion ou de licence. L'entreprise doit savoir qui utilise le système, pour quelles tâches, avec quelle revue, et si le résultat modifie la décision en aval.

La refonte des flux de travail peut supprimer des passations, modifier les périmètres des rôles et créer de nouvelles étapes de contrôle. Elle peut aussi révéler du travail caché auparavant absorbé par les employés. La cartographie des processus doit identifier où le temps se déplace, quelles files d'attente disparaissent, quelles exceptions augmentent et quelles compétences prennent de la valeur.

La formation doit être spécifique au rôle et au cas d'usage. Les utilisateurs ont besoin de comprendre l'objectif, les limites, les règles relatives aux données, les attentes en matière de revue, les procédures d'escalade, des exemples et les limites connues. Les managers doivent savoir interpréter les données de suivi et les éléments probants relatifs aux bénéfices. Les équipes techniques et de contrôle ont besoin de responsabilités sur l'ensemble du cycle de vie. Les membres du conseil d'administration ont besoin de l'économie du portefeuille et de l'exposition significative.

Le plan d'effectifs doit traiter de la capacité plutôt que présumer une suppression immédiate des coûts. Le temps libéré peut soutenir la croissance des volumes, le service, la qualité ou l'évitement d'embauches. L'effet économique réalisé dépend des mesures prises par la direction. La consultation des salariés et les obligations locales en matière d'emploi peuvent également s'appliquer.

19. Allouer le capital au moyen de jalons de portefeuille

Le portefeuille doit rivaliser pour obtenir des capitaux, des données, des capacités d'ingénierie et de contrôle ainsi que l'attention de la direction, qui sont limités. Un cadre de notation commun peut comparer la pertinence stratégique, la valeur adressable, la qualité des preuves, le délai avant impact, la réutilisation, le risque, la dépendance et la charge de mise en œuvre. Les scores éclairent le jugement et ne doivent pas automatiser la décision d'investissement.

Le financement peut être échelonné. La phase de découverte reçoit un petit budget de preuve. La validation reçoit des ressources une fois la base de référence et l'architecture crédibles. Le financement de la production suit des tests réussis et la maturité des contrôles. Le financement du passage à l'échelle suit l'adoption et les premières preuves de bénéfices. Cela réduit l'escalade des coûts irrécupérables.

La revue du portefeuille devrait identifier les décisions d'arrêt. Un cas d'usage peut être techniquement réussi et économiquement peu attractif. Un autre peut rester utile mais nécessiter un autre fournisseur ou flux de travail. Le capital doit être réaffecté lorsque les preuves changent.

Les plateformes partagées nécessitent une gouvernance distincte. L'identité, l'accès aux données, l'évaluation, la surveillance et les passerelles de modèles peuvent réduire le coût marginal à l'échelle du portefeuille. Leur valeur peut être mesurée par les cas d'usage rendus possibles, la duplication évitée et la qualité des contrôles, parallèlement au coût du service et au risque de concentration.

La revue du capital devrait tenir compte de la valeur de l'apprentissage. Une expérimentation encadrée peut mériter un financement parce qu'elle lève une incertitude importante sur les données, l'adoption, la réaction des clients ou la faisabilité technique. Le dossier de décision doit indiquer l'incertitude, les preuves recherchées, l'exposition maximale et la date à laquelle la direction passera à l'échelle, reconcevra ou arrêtera. Cela traite l'expérimentation comme une option achetée avec une échéance définie plutôt que comme un pilote indéfini.

Le portefeuille doit également reconnaître les goulots d'étranglement. Dix cas d'usage financés peuvent se disputer un même propriétaire des données, réviseur de sécurité ou équipe de flux de travail, retardant tous les projets. La planification des capacités doit ordonner les travaux en fonction de la capacité rare qui détermine le débit. Le conseil d'administration peut alors décider d'ajouter des capacités, de resserrer le portefeuille ou de modifier l'architecture.

20. Appliquer des couches de juridiction et de secteur sans fragmenter le noyau

L'entreprise peut maintenir un modèle opérationnel central unique et y rattacher des couches de superposition pour l'entité juridique, la zone géographique, le secteur et le cas d'usage. Le noyau contient l'inventaire, la propriété, la classification par niveaux, le cycle de vie, les preuves, la surveillance et les bénéfices. Une couche de superposition ajoute les droits, approbations, enregistrements, obligations de divulgation, tests ou attentes de supervision applicables.

La loi AI de l'UE utilise un cadre fondé sur les risques avec des obligations qui varient selon le système et l'acteur ; les modalités de contrôle et le calendrier d'application ont continué d'évoluer [9][10][11][12]. Les autorités britanniques utilisent des principes transversaux aux secteurs parallèlement aux régulateurs existants, tandis que la PRA applique des attentes en matière de risque de modèle à des entreprises désignées [14][16]. Les sources américaines comprennent des cadres volontaires du NIST, des règles sectorielles et des mesures d'application contre des allégations non étayées [3][5][19].

Le UAE et l'Arabie saoudite publient des orientations en matière d'éthique et de gouvernance soulignant la responsabilité, la transparence, la confidentialité, la sécurité et l'adoption responsable [20][21][22][23]. Les travaux FREE-AI de la RBI indienne portent sur la AI responsable dans le secteur financier [24]. Les cadres de gouvernance de Singapour et le programme AI Verify soutiennent des tests pratiques et un déploiement responsable [25][26]. L'ASIC a identifié des écarts entre l'adoption de AI et la gouvernance parmi les titulaires de licence examinés [27]. L'OSFI du Canada a finalisé une large ligne directrice sur le risque de modèle couvrant le cycle de vie, avec des considérations liées à AI et une date d'entrée en vigueur en 2027 [29][30].

Ces sources diffèrent par leur statut juridique, leur portée et leur calendrier. Le modèle opérationnel doit consigner l'applicabilité et les conseils pour chaque cas d'usage. Une déclaration de politique mondiale ne doit pas remplacer une analyse juridique locale.

Une architecture transfrontalière exige une vue opérationnelle de la localisation des données, de l'accès à distance, du traitement par les fournisseurs, des équipes de support, de la notification des incidents et de l'accès réglementaire. Un contrat peut désigner une région de service tandis que la télémétrie, le support humain ou des sous-traitants opèrent ailleurs. Le registre des flux de données doit refléter le traitement réel et être actualisé lorsque le service change.

Les couches de superposition sectorielles peuvent ajouter des contrôles sans créer un système d'entreprise distinct. Un cas d'usage financier peut nécessiter des preuves en matière de risque de modèle, de conduite et de résultats pour les clients. Un cas d'usage dans la santé, l'emploi, la sécurité ou les infrastructures critiques peut exiger une analyse différente des obligations professionnelles, des droits et de la résilience. La structure commune d'inventaire et de jalons préserve la visibilité du portefeuille, tandis que la couche de superposition préserve la responsabilité propre au domaine.

21. Tester le cadre au moyen d’un cas hypothétique d’opérations de service

Prenons l’exemple hypothétique d’une société du portefeuille traitant 240 000 demandes de service client par an. La direction propose un assistant qui récupère des connaissances approuvées, rédige une réponse et recommande un code de routage. Les employés restent responsables de la vérification et de l’envoi. L’entreprise s’attend à un temps de traitement plus court et à moins de retraitements.

La phase de découverte établit le flux de travail actuel : temps de traitement médian, revue qualité, contacts répétés, taux de réclamation, file d’attente, composition de la main-d’œuvre et volume saisonnier. La charte désigne les opérations client comme responsable métier, la technologie comme responsable du système, l’équipe connaissances comme responsable des données et la finance comme responsable de la validation des bénéfices. Les données personnelles et confidentielles sont cartographiées avant la conception.

Le cas d’usage est classé dans la catégorie intermédiaire parce que les résultats parviennent aux clients et peuvent affecter le service ou les droits, tandis que des employés formés conservent l’approbation. La validation utilise des cas représentatifs, des catégories difficiles, des prompts adversariaux et un test distinct des autorisations de récupération. L’entreprise fixe des seuils pour l’ancrage factuel, l’exactitude du routage, la gestion des données confidentielles, la qualité de la vérification et les résultats en matière de réclamations.

Le projet pilote initial montre une réduction hypothétique de 24 % du temps de traitement pour les demandes éligibles. Seules 58 % des demandes sont éligibles, et l’adoption atteint 70 % du volume éligible. La direction évite donc d’appliquer 24 % à l’ensemble de la base de coûts. La finance modélise la capacité réalisée à partir du volume éligible réel, de l’adoption, des retraitements et du coût récurrent additionnel.

L’approbation du passage à l’échelle dépend d’une actualisation contrôlée des connaissances, de la formation des utilisateurs, de la stabilité des seuils et d’un plan de main-d’œuvre pour la capacité libérée. Le conseil d’administration reçoit séparément les bénéfices prévus, observés et validés. Aucune valeur n’est attribuée au modèle du seul fait qu’il est déployé.

22. Fournir au conseil d’administration un dossier d’aide à la décision plutôt qu’un rapport d’activité AI

Le dossier du conseil d’administration doit présenter l’exposition du portefeuille, les décisions et les éléments de preuve. Un tableau de bord d’une page peut inclure les cas d’usage par catégorie et cycle de vie, le capital engagé, la valeur prévisionnelle et validée, l’adoption, les dépendances importantes, les exceptions de contrôle, les incidents, les revues en retard et les décisions requises. Le détail doit figurer en annexe du tableau de bord.

Chaque cas d’usage significatif doit indiquer le responsable, le résultat attendu, l’étape, le niveau de risque, les éléments de preuve les plus récents, la limite non résolue, le prochain jalon de décision et le statut des bénéfices. Les bénéfices doivent être répartis entre valeurs prévisionnelles, observées et validées par la finance. Les coûts doivent inclure les vues des coûts engagés, encourus et récurrents.

Le récit est important lorsque les indicateurs changent. La direction doit expliquer pourquoi l’adoption, la performance du modèle, les seuils de contrôle ou la valeur ont évolué ; quelle décision a suivi ; et qui est responsable de l’action. Le dossier doit préserver la cohérence des versions et des périodes.

Le conseil d’administration doit également voir les concentrations : flux de travail critiques par fournisseur, cloud, source de données et personne clé. Cela relie la supervision AI à la résilience opérationnelle, au risque cyber, aux achats et à la succession.

L’assurance doit être visible sous forme de cartographie de couverture. L’audit interne, les risques, la conformité, la sécurité, la confidentialité, la finance et des spécialistes externes peuvent chacun tester une partie du système. Le conseil d’administration doit voir quelles assertions importantes ont été examinées, la période et le périmètre, les constats non résolus et la réponse de la direction. Des revues multiples ne créent pas une assurance complète lorsqu’elles examinent le même contrôle étroit et laissent intactes la responsabilité, l’adoption ou l’attribution des bénéfices.

L’information destinée au conseil d’administration doit gagner en maturité avec le portefeuille. Les premiers dossiers peuvent mettre l’accent sur l’exhaustivité de l’inventaire, l’appétit pour le risque et la conception des jalons de décision. Un portefeuille en phase de mise à l’échelle doit mettre l’accent sur la performance en production, les incidents, la concentration et la valeur validée. Un portefeuille mature doit aussi montrer le décommissionnement, l’efficacité des contrôles et si une capacité partagée réduit le coût marginal. L’architecture de l’information doit changer lorsque les décisions du conseil d’administration changent.

Tableau 6. Tableau de bord du modèle opérationnel AI du conseil d’administration

Chaque ligne doit aboutir à une décision, une escalade ou une action opérationnelle confirmée.

23. Mettre en œuvre le modèle opérationnel en cent jours

Les trente premiers jours établissent la visibilité et l'autorité. Nommer le sponsor exécutif, approuver l'appétit provisoire, identifier les cas d'usage significatifs et les outils, définir l'inventaire, attribuer des responsables et arrêter toute activité hors de limites claires. La fonction Finance sélectionne un petit nombre de bases de référence de bénéfices prioritaires.

Les jours trente et un à soixante construisent l'ossature de contrôle. Définir les niveaux de risque, les points de contrôle du cycle de vie, les preuves minimales, la classification des changements, le circuit des incidents, les exigences fournisseurs et le registre des bénéfices. Sélectionner deux ou trois cas d'usage prioritaires pertinents sur le plan commercial et suffisamment délimités pour tester le système.

Les jours soixante et un à quatre-vingt-dix exécutent le premier cycle contrôlé. Finaliser la conception, la cartographie des données, la validation, la revue de sécurité, la formation des utilisateurs et la préparation à la mise en production pour les cas sélectionnés. Consigner les approbations conditionnelles et les exceptions. Mettre en place le suivi et une passerelle de bénéfices portée par la finance.

Les jours quatre-vingt-onze à cent clôturent le premier cycle du conseil d'administration. Présenter l'inventaire, l'exposition, les preuves, les premiers résultats opérationnels, la confiance dans les bénéfices, les décisions et l'allocation de capital du trimestre suivant. Le modèle opérationnel ne devient une routine que lorsque la gouvernance, l'exécution et la finance utilisent les mêmes enregistrements.

Le calendrier est indicatif et doit être prolongé lorsque les conséquences systémiques, la réglementation ou la préparation organisationnelle l'exigent.

Références

1. OCDE, Principes AI de l'OCDE, mis à jour en 2024, https://www.oecd.org/en/topics/ai-principles.html
2. OCDE, AI, Gouvernance des données et vie privée : synergies et domaines de coopération internationale, 2024, https://www.oecd.org/content/dam/oecd/en/publications/reports/2024/06/ai-data-governance-and-privacy_2ac13a42/2476b1a4-en.pdf
3. Institut national des normes et de la technologie, Cadre de gestion des risques liés à l’intelligence artificielle 1.0, 2023, https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf
4. National Institute of Standards and Technology, Playbook RMF AI, mis à jour en 2026, https://www.nist.gov/itl/ai-risk-management-framework/nist-ai-rmf-playbook
5. National Institute of Standards and Technology, Cadre de gestion des risques liés à l'intelligence artificielle : profil pour l'intelligence artificielle générative, 2024, https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf
6. National Institute of Standards and Technology, Centre de ressources pour une AI digne de confiance et responsable, 2026, https://airc.nist.gov/
7. Organisation internationale de normalisation, ISO/IEC 42001:2023 Système de management de l'intelligence artificielle, 2023, https://www.iso.org/standard/42001.html
8. Organisation internationale de normalisation, ISO/IEC 23894:2023 Gestion des risques liés à l'intelligence artificielle, 2023, https://www.iso.org/standard/77304.html
9. Commission européenne, règlement AI : cadre réglementaire pour l'intelligence artificielle, mis à jour en 2026, https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
10. Commission européenne, Cadre de mise en œuvre du règlement AI, 2026, https://digital-strategy.ec.europa.eu/en/policies/enforcement-ai-act
11. Commission européenne, Lignes directrices sur les obligations de transparence pour les fournisseurs et les déployeurs de certains systèmes AI, 2026, https://digital-strategy.ec.europa.eu/en/policies/guidelines-ai-transparency-obligations
12. Commission européenne, Lignes directrices sur les obligations des fournisseurs de AI à usage général, 2025, https://digital-strategy.ec.europa.eu/en/faqs/guidelines-obligations-general-purpose-ai-providers
13. EUR-Lex, Règlement UE 2016/679, Règlement général sur la protection des données, 2016, https://eur-lex.europa.eu/eli/reg/2016/679/oj
14. Gouvernement britannique, Mise en œuvre des principes réglementaires du Royaume-Uni relatifs à AI : orientations à l'intention des régulateurs, 2024, https://assets.publishing.service.gov.uk/media/65c0b6bd63a23d0013c821a0/implementing_the_uk_ai_regulatory_principles_guidance_for_regulators.pdf
15. Information Commissioner's Office, Orientations sur AI et la protection des données, mises à jour en 2023, https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/artificial-intelligence/guidance-on-ai-and-data-protection/
16. Banque d'Angleterre, Autorité de régulation prudentielle, Principes de gestion des risques de modèle pour les banques SS1/23, mis à jour en 2026, https://www.bankofengland.co.uk/prudential-regulation/publication/2023/may/model-risk-management-principles-for-banks-ss
17. Agence de la cybersécurité et de la sécurité des infrastructures et Centre national de cybersécurité du Royaume-Uni, Lignes directrices pour le développement sécurisé de systèmes AI, 2023, https://www.cisa.gov/news-events/alerts/2023/11/26/cisa-and-uk-ncsc-unveil-joint-guidelines-secure-ai-system-development
18. Agence de la cybersécurité et de la sécurité des infrastructures, Choisir des technologies sécurisées et vérifiables, 2024, https://www.cisa.gov/resources-tools/resources/choosing-secure-and-verifiable-technologies
19. Commission fédérale du commerce, Intelligence artificielle : application et orientations pour les entreprises, mise à jour 2026, https://www.ftc.gov/industry/technology/artificial-intelligence
20. UAE Bureau du ministre d'État chargé de l'intelligence artificielle, de l'économie numérique et des applications de travail à distance, Position UAE sur la politique AI, 2024, https://ai.gov.ae/wp-content/uploads/2024/10/UAE-Guiding-on-ai-policy-EN-V3.pdf
21. UAE Bureau de l'intelligence artificielle, Principes et lignes directrices d'éthique AI, 2022, https://ai.gov.ae/wp-content/uploads/2023/05/MOCAI-AI-Ethics-EN.pdf
22. Autorité saoudienne des données et de l'intelligence artificielle, Principes d'éthique AI, https://sdaia.gov.sa/en/SDAIA/about/Documents/ai-principles.pdf
23. Autorité saoudienne des données et de l'intelligence artificielle, Réglementations et politiques, mise à jour 2026, https://sdaia.gov.sa/en/SDAIA/about/Pages/RegulationsAndPolicies.aspx
24. Banque de réserve de l'Inde, Rapport du comité FREE-AI : Cadre pour une habilitation responsable et éthique de l'intelligence artificielle, 2025, https://www.rbi.org.in/Scripts/PublicationReportDetails.aspx?UrlPage=&ID=1299
25. Commission de protection des données personnelles de Singapour, Cadre de gouvernance modèle pour l'intelligence artificielle, 2020, https://www.pdpc.gov.sg/help-and-resources/2020/01/model-ai-governance-framework
26. Autorité de développement des médias et des infocommunications de Singapour, Cadre de gouvernance modèle AI pour AI générative, 2024, https://www.imda.gov.sg/resources/press-releases-factsheets-and-speeches/press-releases/2024/model-ai-governance-framework-for-generative-ai
27. Commission australienne des valeurs mobilières et des investissements, REP 798 Attention au fossé : dispositifs de gouvernance face à l'innovation AI, 2024, https://asic.gov.au/regulatory-resources/find-a-document/reports/rep-798-beware-the-gap-governance-arrangements-in-the-face-of-ai-innovation/
28. Autorité australienne de régulation prudentielle, CPS 230 Gestion du risque opérationnel, mise à jour 2026, https://www.apra.gov.au/standards/cps-230
29. Bureau du surintendant des institutions financières Canada, Ligne directrice E-23 Gestion du risque de modèle, 2025, https://www.osfi-bsif.gc.ca/en/guidance/guidance-library/guideline-e-23-model-risk-management-2027
30. Bureau du surintendant des institutions financières Canada et Agence de la consommation en matière financière du Canada, Utilisations et risques AI dans les institutions financières sous réglementation fédérale, 2024, https://www.osfi-bsif.gc.ca/en/about-osfi/reports-publications/osfi-fcac-risk-report-ai-uses-risks-federally-regulated-financial-institutions
31. Autorité britannique des infrastructures et des projets et Bureau du Cabinet, Guide pour une gestion efficace des bénéfices dans les grands projets, 2017, https://www.gov.uk/government/publications/guide-for-effective-benefits-management-in-major-projects
32. Gouvernement du Royaume-Uni, Cadre d'efficacité gouvernementale, 2025, https://www.gov.uk/government/publications/the-government-efficiency-framework/the-government-efficiency-framework--2
33. Fondation IFRS, Actifs incorporels : autres cas de test potentiels, y compris les ressources de données et les données et solutions liées à l'intelligence artificielle, 2026, https://www.ifrs.org/content/dam/ifrs/meetings/2026/january/iasb/ap17d-other-potential-test-cases-data-ai.pdf

Sources et lectures complémentaires

1. OCDE, Principes AI de l'OCDE, mis à jour en 2024, Source officielle
2. OCDE, AI, Gouvernance des données et vie privée : synergies et domaines de coopération internationale, 2024, Source officielle
3. Institut national des normes et de la technologie, Cadre de gestion des risques liés à l’intelligence artificielle 1.0, 2023, Source officielle
4. National Institute of Standards and Technology, Playbook RMF AI, mis à jour en 2026, Source officielle
5. National Institute of Standards and Technology, Cadre de gestion des risques liés à l'intelligence artificielle : profil pour l'intelligence artificielle générative, 2024, Source officielle
6. National Institute of Standards and Technology, Centre de ressources pour une AI digne de confiance et responsable, 2026, Source officielle
7. Organisation internationale de normalisation, ISO/IEC 42001:2023 Système de management de l'intelligence artificielle, 2023, Source officielle
8. Organisation internationale de normalisation, ISO/IEC 23894:2023 Gestion des risques liés à l'intelligence artificielle, 2023, Source officielle
9. Commission européenne, règlement AI : cadre réglementaire pour l'intelligence artificielle, mis à jour en 2026, Source officielle
10. Commission européenne, Cadre de mise en œuvre du règlement AI, 2026, Source officielle
11. Commission européenne, Lignes directrices sur les obligations de transparence pour les fournisseurs et les déployeurs de certains systèmes AI, 2026, Source officielle
12. Commission européenne, Lignes directrices sur les obligations des fournisseurs de AI à usage général, 2025, Source officielle
13. EUR-Lex, Règlement UE 2016/679, Règlement général sur la protection des données, 2016, Source officielle
14. Gouvernement britannique, Mise en œuvre des principes réglementaires du Royaume-Uni relatifs à AI : orientations à l'intention des régulateurs, 2024, Source officielle
15. Information Commissioner's Office, Orientations sur AI et la protection des données, mises à jour en 2023, Source officielle
16. Banque d'Angleterre, Autorité de régulation prudentielle, Principes de gestion des risques de modèle pour les banques SS1/23, mis à jour en 2026, Source officielle
17. Agence de la cybersécurité et de la sécurité des infrastructures et Centre national de cybersécurité du Royaume-Uni, Lignes directrices pour le développement sécurisé de systèmes AI, 2023, Source officielle
18. Agence de la cybersécurité et de la sécurité des infrastructures, Choisir des technologies sécurisées et vérifiables, 2024, Source officielle
19. Commission fédérale du commerce, Intelligence artificielle : application et orientations pour les entreprises, mise à jour 2026, Source officielle
20. UAE Bureau du ministre d'État chargé de l'intelligence artificielle, de l'économie numérique et des applications de travail à distance, Position UAE sur la politique AI, 2024, Source officielle
21. UAE Bureau de l'intelligence artificielle, Principes et lignes directrices d'éthique AI, 2022, Source officielle
22. Autorité saoudienne des données et de l'intelligence artificielle, Principes d'éthique AI, Source officielle
23. Autorité saoudienne des données et de l'intelligence artificielle, Réglementations et politiques, mise à jour 2026, Source officielle
24. Banque de réserve de l'Inde, Rapport du comité FREE-AI : Cadre pour une habilitation responsable et éthique de l'intelligence artificielle, 2025, Source officielle
25. Commission de protection des données personnelles de Singapour, Cadre de gouvernance modèle pour l'intelligence artificielle, 2020, Source officielle
26. Autorité de développement des médias et des infocommunications de Singapour, Cadre de gouvernance modèle AI pour AI générative, 2024, Source officielle
27. Commission australienne des valeurs mobilières et des investissements, REP 798 Attention au fossé : dispositifs de gouvernance face à l'innovation AI, 2024, Source officielle
28. Autorité australienne de régulation prudentielle, CPS 230 Gestion du risque opérationnel, mise à jour 2026, Source officielle
29. Bureau du surintendant des institutions financières Canada, Ligne directrice E-23 Gestion du risque de modèle, 2025, Source officielle
30. Bureau du surintendant des institutions financières Canada et Agence de la consommation en matière financière du Canada, Utilisations et risques AI dans les institutions financières sous réglementation fédérale, 2024, Source officielle
31. Autorité britannique des infrastructures et des projets et Bureau du Cabinet, Guide pour une gestion efficace des bénéfices dans les grands projets, 2017, Source officielle
32. Gouvernement du Royaume-Uni, Cadre d'efficacité gouvernementale, 2025, Source officielle
33. Fondation IFRS, Actifs incorporels : autres cas de test potentiels, y compris les ressources de données et les données et solutions liées à l'intelligence artificielle, 2026, Source officielle