1. Définir la décision du conseil d’administration comme un pouvoir délégué
Un agent AI doit être considéré comme une capacité opérationnelle déléguée. La décision du conseil porte sur les objectifs que le système peut poursuivre, les informations qu’il peut utiliser, les outils qu’il peut appeler, les engagements qu’il peut créer et les actions qui restent soumises à approbation. Une licence d’utilisation d’un modèle ou une démonstration réussie ne répond pas à ces questions.
Le dossier économique peut être attractif. Les fonctions supports contiennent des recherches répétées, des rapprochements, du traitement documentaire, du tri d’exceptions, des relances et des mises à jour de statut. Un agent peut relier ces étapes entre les systèmes et dans le temps. Il peut préparer un dossier d’intégration fournisseur, retracer une facture contestée, constituer une prévision de trésorerie ou coordonner un dossier de service client. La valeur apparaît lorsque l’entreprise supprime les délais, les reprises et la propriété fragmentée tout en conservant des preuves fiables.
L’exposition liée au contrôle s’élargit également. L’agent peut sélectionner le mauvais enregistrement, suivre une instruction intégrée dans un document non fiable, utiliser un justificatif d’accès au-delà de l’objectif prévu, divulguer des données personnelles, créer un paiement en double, appliquer une politique obsolète ou continuer après que le contexte métier a changé. La conséquence peut traverser plusieurs systèmes avant qu’un humain ne la voie.
Le mandat du conseil doit donc définir quatre limites. La limite de résultat indique ce que l’agent peut accomplir. La limite de ressources indique quelles données, applications, identités, budgets et durées il peut utiliser. La limite d’action indique quels actes il peut exécuter et lesquels exigent une approbation. La limite de défaillance indique comment le système s’arrête, circonscrit le préjudice, préserve les preuves et renvoie le travail à une personne.
La première décision de politique doit identifier les actions interdites. Les exemples peuvent inclure la libération de liquidités, la modification de coordonnées bancaires, la rupture d’un contrat de travail, l’acceptation d’une responsabilité contractuelle, le dépôt de déclarations réglementaires, le contournement de la séparation des tâches ou la communication d’une décision défavorable définitive à une personne. La liste exacte dépend des obligations juridiques, du modèle opérationnel et de l’appétit pour le risque de l’entreprise.

L’objectif, l’identité, les outils et les sorties restent dans des limites explicites de politique, d’approbation et de preuve.
2. Fonder le programme sur des données probantes actuelles issues de plusieurs marchés
Les cadres officiels convergent vers une gouvernance du cycle de vie, une responsabilité, des tests et une capacité d’intervention. Le cadre de gestion des risques AI du NIST organise le travail autour de gouverner, cartographier, mesurer et gérer. Son profil génératif-AI identifie les risques qui peuvent être nouveaux ou amplifiés par les systèmes génératifs et fournit des actions sur l’ensemble du cycle de vie. En février 2026, le NIST a lancé l’initiative sur les normes relatives aux agents AI, avec des piliers spécifiques pour la sécurité, l’identité, l’autorisation, l’interopérabilité et l’évaluation des agents. L’initiative confirme que les contrôles des agents en entreprise restent un domaine actif de développement de normes.
Le DIFC a modifié son Règlement sur la protection des données en 2023 pour inclure le Règlement 10 relatif au traitement des données personnelles au moyen de systèmes autonomes et semi-autonomes. Le règlement et les orientations associées placent l’utilisation des données personnelles, la responsabilité et les personnes concernées dans un environnement de contrôle fondé sur les résultats. Une entreprise de taille intermédiaire opérant dans le DIFC ou par son intermédiaire devrait établir la correspondance entre le règlement et chaque agent qui traite des données personnelles et solliciter des conseils actuels sur le périmètre et les obligations.
Les orientations internationales du NCSC britannique sur la sécurité de AI couvrent la conception, le développement, le déploiement, l’exploitation et la maintenance sécurisés. Elles appellent à la modélisation des menaces, à la due diligence de la chaîne d’approvisionnement, à des infrastructures protégées, à la journalisation, à la surveillance, à la gestion des incidents et à une mise en production responsable. Ces contrôles importent lorsqu’un agent de back-office s’appuie sur des modèles, connecteurs, bibliothèques ou interfaces de programmation d’applications externes.
La Commission européenne indique que les obligations de transparence au titre de l’article 50 de la loi AI ont commencé à s’appliquer le 2 août 2026. Les documents de mise en œuvre 2026 de la Commission reflètent également des dates révisées pour les règles relatives aux systèmes à haut risque. Une entreprise devrait confirmer si elle agit en tant que fournisseur, déployeur, importateur ou autre opérateur et évaluer chaque cas d’usage au regard du texte officiel en vigueur et du droit sectoriel applicable.
Les données probantes du secteur financier offrent un signal de contrôle utile. L’enquête conjointe de la Banque d’Angleterre et de la Financial Conduct Authority de 2024 a rapporté que 75 % des entreprises répondantes utilisaient AI, que 33 % des cas d’usage impliquaient des tiers, que 55 % impliquaient une forme de prise de décision automatisée et que seulement 2 % étaient entièrement autonomes. Elle a également rapporté que la cybersécurité était le risque perçu comme le plus important et que la compréhension complète des AI déployés était limitée. Les données d’enquête ne déterminent pas la bonne conception pour une entreprise donnée ; elles montrent bien l’importance d’une propriété responsable, de la visibilité sur les tiers et d’une autonomie calibrée.
Tableau 1. Éléments probants officiels et implications pour le contrôle
| Autorité | Signal actuel | Incidence sur les contrôles | Périmètre de gestion |
|---|---|---|---|
| NIST AI RMF et initiative relative aux agents | gestion des risques sur le cycle de vie ; les travaux sur l’identité, l’autorisation et la sécurité se poursuivent | tenir un registre des agents, une enveloppe d’autorité et un dossier d’évaluation | les orientations volontaires doivent être rattachées au cas d’usage |
| Règlement 10 du DIFC | le traitement autonome et semi-autonome des données personnelles est expressément traité | analyse complète des données, des impacts individuels et de la responsabilité | le périmètre territorial et le périmètre de traitement nécessitent un examen juridique |
| NCSC du Royaume-Uni | conception sécurisée jusqu’à l’exploitation sécurisée ; contrôles liés à la chaîne d’approvisionnement et aux incidents | outils de modélisation des menaces, connecteurs, identifiants et chemins de défaillance | les orientations complètent le droit applicable et les obligations en matière de cybersécurité |
| Commission européenne | Les obligations de transparence de l'article 50 s'appliquent à compter du 2 août 2026 ; les calendriers varient selon la règle | classer le rôle, le système et l'interaction ; conserver la cartographie de conformité actuelle | le texte officiel et les amendements font foi |
| FCA et Banque d'Angleterre | l'utilisation par des tiers, la compréhension partielle et le risque cyber sont des thèmes importants | documenter les dépendances vis-à-vis des fournisseurs, les responsables désignés et la surveillance | les résultats de l'enquête décrivent les répondants, et non chaque entreprise |
| OCDE, Singapour et ISO | la supervision humaine, la traçabilité, la robustesse et l'amélioration continue reviennent régulièrement | intégrer AI à la gouvernance d'entreprise et au contrôle interne | les référentiels volontaires exigent une adoption proportionnée |
L'applicabilité, les définitions et les obligations nécessitent une confirmation actuelle propre à chaque entreprise.
3. Distinguer automatisation, assistance et autonomie d'action
Le mot automatisation masque trois modèles opérationnels différents. L'automatisation déterministe suit des règles codées : faire correspondre un bon de commande, valider un champ, acheminer un document ou calculer un seuil. L'assistance AI produit un brouillon, une classification, un résumé ou une recommandation pour une personne. L'autonomie d'action encadrée sélectionne et ordonne les actions dans le cadre d'un objectif défini et peut se poursuivre sur plusieurs étapes.
Ces modèles ne doivent pas partager un même standard d'approbation. L'automatisation déterministe peut souvent être testée par rapport à des entrées et sorties connues. L'assistance AI exige des contrôles sur l'ancrage, la revue et l'utilisation. La capacité d'action exige tous ces contrôles, plus l'autorité, l'identité, l'accès aux outils, la mémoire, la capacité d'arrêt, la gestion des exceptions et la preuve de chaque action intermédiaire.
L'autonomie doit être décomposée plutôt que décrite par une seule étiquette. Un agent peut avoir la liberté de planifier sans détenir de droits d'exécution. Il peut exécuter des mises à jour internes à faible conséquence tout en exigeant une approbation avant toute communication externe. Il peut intervenir uniquement sur un dossier nommé, dans une limite de valeur définie, pendant une courte fenêtre temporelle et avec un nombre plafonné d'appels d'outils.
L'entreprise doit choisir le niveau le plus bas de capacité d'action permettant d'obtenir le résultat économique souhaité. De nombreux processus s'améliorent sensiblement grâce à de meilleures données, à des contrôles déterministes et à une préparation assistée par AI. L'exécution entièrement sans supervision ne convient que lorsque le processus est bien compris, que l'action est réversible, que l'autorité peut être strictement délimitée, que les preuves sont complètes et que la défaillance peut être contenue.
Une échelle d'autonomie rend la progression observable. Un cas d'usage ne progresse qu'après avoir satisfait à des jalons de preuve définis à son niveau actuel. Les incidents de production, les changements importants de processus, les nouveaux outils, les changements de modèle ou une surveillance insuffisante doivent déclencher une réévaluation ou un retour à un niveau inférieur.

L'autorité ne s'étend qu'après que les preuves, la réversibilité et le confinement ont été démontrés au niveau précédent.
4. Établir un inventaire des processus et des décisions
L'adoption des agents doit commencer par le processus, la décision et la piste des preuves. Un catalogue de démonstrations séduisantes peut manquer les causes opérationnelles des coûts et des retards. L'entreprise doit inventorier le back-office par chaîne de valeur : de la commande à l'encaissement, de l'achat au paiement, de la comptabilisation au reporting, du recrutement au départ, du dossier à la résolution, le reporting réglementaire et les informations de gestion.
Chaque processus doit être décomposé en déclencheurs, entrées, décisions, actions, systèmes, responsables, transferts, contrôles, exceptions et sorties. La direction doit mesurer le volume, le temps de cycle, les erreurs, les reprises, le backlog, le coût, l'exposition financière, la sensibilité des données et la conséquence sur le service. L'inventaire doit identifier où un jugement est réellement requis et où des données manquantes ou une politique incohérente créent l'apparence d'un jugement.
L'inventaire des décisions est particulièrement important. Une décision peut approuver un paiement, libérer une commande client, classer une réclamation, modifier une fiche fournisseur, comptabiliser une écriture, sélectionner un candidat ou communiquer une conclusion. L'enregistrement doit identifier qui est concerné, les preuves requises, la politique applicable, la marge d'appréciation autorisée, la voie de recours ou de correction et la conséquence juridique ou de contrôle.
La priorisation doit combiner valeur économique et faisabilité du contrôle. Les travaux à fort volume, à faible conséquence et riches en preuves peuvent constituer un point de départ attractif. Les travaux à forte conséquence, ambigus ou mal étayés par des preuves doivent d'abord faire l'objet d'une correction du processus et de contrôles de données renforcés. Une entreprise doit éviter d'automatiser un processus d'exception défaillant dont la cause racine n'est pas résolue.
L'inventaire devient la source de référence pour l'approbation des cas d'usage. Il relie la valeur revendiquée à une base de référence mesurable et empêche une équipe technologique d'accorder une autorité sans que le responsable du processus, le propriétaire du risque, le propriétaire des données et le propriétaire du contrôle ne s'accordent sur la conception.
Tableau 2. Inventaire des processus et des décisions
| Champ d'inventaire | Question centrale | Justificatif | Usage décisionnel |
|---|---|---|---|
| déclencheur et objectif | qu'est-ce qui déclenche le travail et quel résultat le clôt ? | événement source, standard de service et enregistrement d'achèvement | définir le périmètre et la règle d'arrêt |
| données d'entrée et décision | quels faits et quelle politique déterminent l'étape suivante ? | documents, données de référence, politique et enregistrement d'approbation | justification des tests et marge d'appréciation autorisée |
| action et conséquence | qu'est-ce qui peut changer dans l'entreprise ou affecter une personne ? | transaction système, communication et exposition de valeur | définir l'autorité et le niveau d'approbation |
| exception et défaillance | où le traitement normal s'interrompt-il ? | codes d'erreur, arriéré, litiges et incidents | Concevoir l’escalade et la défaillance sécurisée |
| Contrôle et responsable | Qui reste responsable et quel contrôle doit s’exercer ? | Matrice de contrôle, ségrégation et description des rôles | Désigner le responsable de la gouvernance et des preuves |
| Situation de référence et valeur | Quels coûts, délais, erreurs ou expositions de trésorerie peuvent être améliorés ? | Indicateurs de volume, de temps, de qualité, de trésorerie et de service | Élaborer le business case et le tableau de bord |
Les indicateurs sont sélectionnés selon le contexte opérationnel et doivent s’appuyer sur des éléments probants rapprochés.
5. Définir l’enveloppe d’autorisation
L’enveloppe d’autorisation traduit la politique en limites applicables par la machine. Elle doit préciser l’objectif, les données autorisées, les outils autorisés, les actions, les valeurs, les contreparties, les juridictions, les heures d’activité, la durée, le nombre d’appels, les points d’approbation et les conditions d’arrêt. Une instruction en langage naturel ne suffit pas, car elle peut être interprétée différemment selon l’évolution du contexte.
Les autorisations doivent être restreintes par défaut. Un agent de facturation pourrait lire les factures et bons de commande approuvés, demander les éléments internes manquants, préparer une proposition de paiement et mettre à jour le dossier. Il ne devrait disposer d’aucun droit permanent de modifier les coordonnées bancaires d’un fournisseur ni de libérer un paiement. Un agent de recouvrement pourrait rédiger une relance à partir de faits et conditions approuvés, tandis qu’un humain approuve toute communication externe dépassant un niveau de sensibilité ou une catégorie de client définis.
L’enveloppe doit être rattachée à un responsable métier nommé et à un niveau de risque. Les autorisations temporaires doivent expirer. Les limites de valeur et de volume doivent être cumulatives autant que transactionnelles, afin que de nombreuses petites actions ne puissent pas contourner un plafond journalier ou par dossier. Les limites géographiques, d’entité et de devise doivent correspondre au périmètre juridique et opérationnel.
L’application des politiques doit avoir lieu en dehors du modèle de raisonnement. Un service déterministe doit valider chaque appel d’outil proposé au regard de l’identité, de la finalité, des autorisations, de la valeur, du statut du dossier et de l’approbation. Le modèle peut expliquer pourquoi il propose une action ; le moteur de politiques décide si l’action peut être exécutée.
Chaque refus doit générer des preuves structurées. Des refus répétés peuvent révéler un prompt médiocre, une conception de processus faible, un usage abusif émergent ou une enveloppe d'autorité à revoir. Les modifications de l'enveloppe doivent suivre un contrôle de version, des tests et une approbation, la version précédente étant conservée.

Chaque action proposée doit passer les limites cumulatives, la politique et l'approbation avant exécution.
6. Donner à chaque agent une identité distincte
Un agent ne doit pas fonctionner via un compte employé partagé ou un identifiant de service sans restriction. Il a besoin d'une identité machine unique reliée à un propriétaire nommé, à un objectif défini, à un niveau de risque, à une version et à une date d'expiration. Cela favorise le moindre privilège, l'attribution, la rotation des identifiants, la révocation et un audit fiable.
Les autorisations doivent être spécifiques à la tâche. L'accès en lecture, les droits de proposition et les droits d'exécution sont distincts. L'agent doit recevoir des identifiants à courte durée de vie au moment du besoin, après que le service de politique a validé le dossier et l'état d'approbation. Les secrets doivent rester dans un coffre-fort géré et ne jamais être placés dans des prompts, la mémoire, les journaux ou des documents.
L'architecture des identités doit préserver la séparation des tâches. Un agent qui crée un fournisseur ne doit pas approuver ce fournisseur ni libérer un paiement. Un agent qui prépare une écriture comptable ne doit pas comptabiliser et approuver la même écriture. Une approbation humaine ne corrige pas un conflit lorsque l'approbateur manque d'indépendance, de preuves ou de temps suffisant.
Les appels d'agent à agent exigent la même discipline. L'agent récepteur doit authentifier l'appelant, valider le périmètre délégué et refuser toute autorité qui ne peut pas être rattachée au principal d'origine. Les chaînes de délégation doivent avoir une profondeur maximale et préserver le propriétaire, le dossier et les limites cumulatives d'origine.
La révocation d'urgence doit être opérationnelle. L'entreprise doit pouvoir désactiver l'identité, révoquer les jetons actifs, arrêter les actions en file d'attente et isoler le dossier sans attendre le fournisseur du modèle. La recertification des accès doit avoir lieu après des changements importants de processus ou de rôle et selon un calendrier périodique proportionné au risque.
7. Contrôler les données, les prompts, les outils et la mémoire
L'environnement opérationnel effectif de l'agent comprend plus que le modèle. Il inclut les instructions système, les instructions utilisateur, les documents récupérés, la mémoire, les descriptions d'outils, les réponses applicatives et le contenu tiers. Chacun de ces éléments peut être inexact, malveillant, obsolète ou hors de la finalité autorisée.
L'accès aux données doit respecter la classification, la finalité et le principe de nécessité minimale. L'entreprise doit cartographier les données personnelles, les informations commerciales confidentielles, les données de paiement, les données relatives à l'emploi et les documents protégés par le secret professionnel. La récupération doit appliquer les limites d'entité, de dossier et d'utilisateur. Les champs sensibles peuvent être masqués jusqu'à ce que la tâche et l'approbation les exigent.
Le contenu non fiable doit être traité comme des données plutôt que comme des instructions. Un message dans une pièce jointe de facture qui demande à l'agent d'ignorer la politique ou d'envoyer des informations ailleurs ne doit avoir aucune autorité. L'architecture doit séparer les instructions de contrôle fiables du contenu récupéré, assainir les sorties d'outils lorsque c'est approprié et tester les scénarios d'injection de prompt.
Les outils exigent des listes d'autorisation et des contrôles de paramètres. Une requête de base de données générique, un shell de commande ou un navigateur sans restriction peuvent donner à l'agent une surface opérationnelle plus large que ne l'exige la finalité métier. Des outils conçus spécialement, avec des entrées typées, des actions ciblées, une validation déterministe et l'idempotence, offrent une frontière plus solide.
La mémoire doit avoir un objectif défini, une durée de conservation et une procédure de suppression. L'entreprise doit distinguer l'état temporaire d'un dossier, les connaissances de référence approuvées et les préférences apprises. La mémoire persistante peut transporter des faits obsolètes, des données personnelles non autorisées ou les instructions d'un dossier vers un autre. Les écritures en mémoire doivent être explicites, attribuables et auditables.
Tableau 3. Registre des contrôles de la surface opérationnelle de l'agent
| Surface | Risque principal | Contrôle préventif | Contrôle de détection ou de reprise |
|---|---|---|---|
| Instructions système et utilisateur | Autorité ambiguë ou contradictoire | Prompt de contrôle signé et versionné, et règles de priorité | Trace des instructions et revue des actions refusées |
| Documents récupérés | Injection de prompt, faits obsolètes ou entité erronée | Classes de sources fiables, filtres par dossier et isolation du contenu | Journal de provenance et tests de contenu adversarial |
| Outils et connecteurs | capacités excessives ou paramètres non sécurisés | outils typés à périmètre restreint, liste d'autorisation, validation des politiques et idempotence | télémétrie des appels d'outils, rapprochement et révocation |
| identifiants et secrets | divulgation, réutilisation ou élévation de privilèges | coffre-fort, jeton à durée de vie courte et moindre privilège | analyse des secrets, rotation et alertes d'accès |
| mémoire de travail | fuite entre cas ou contexte obsolète | isolation des cas, règle de conservation et autorisation d'écriture explicite | audit de la mémoire, expiration et preuve de suppression |
| modèles et services externes | exposition liée au transfert, à la modification ou à la concentration des données | contrat, configuration, minimisation des données et solution de repli | surveillance des fournisseurs, tests de version et plan de sortie |
La mise en œuvre technique doit être validée par les responsables de la sécurité, de la confidentialité et du contrôle de l'entreprise.
8. Encadrer les travaux probabilistes par des contrôles déterministes
Un agent peut aider à interpréter des informations désordonnées, tandis que des contrôles déterministes doivent régir les données qui doivent être exactes. Les formats de comptes bancaires, les identifiants fiscaux, les calculs de factures, la devise, la détection des doublons, les limites d'approbation, les périodes comptables, le statut au regard des sanctions et les règles de ségrégation doivent être validés au moyen de données et de code contrôlés.
Le workflow peut utiliser le modèle pour localiser un numéro de facture probable, expliquer un écart ou proposer une catégorie. Un service déterministe doit ensuite vérifier l'identifiant auprès du système source, calculer le montant, tester la règle et renvoyer un résultat conforme, non conforme ou une exception. L'agent ne doit pas transformer une interprétation à faible niveau de confiance en transaction exécutée.
Le rapprochement est essentiel. L'entreprise doit comparer les actions demandées, approuvées, exécutées et enregistrées. Chaque transaction doit disposer d'une clé d'idempotence afin qu'une nouvelle tentative ne puisse pas créer de doublon. Les totaux de lots, les comptes de contrôle et les files d'exceptions doivent être rapprochés avec les systèmes source et de destination. Une réponse réussie d'un outil prouve qu'un appel a eu lieu, et non que le résultat comptable ou opérationnel visé a été obtenu.
Le niveau de confiance ne doit pas tenir lieu d'autorité. Un modèle très confiant peut néanmoins se tromper, et une sortie à faible niveau de confiance peut être utile lorsqu'elle est clairement orientée vers une personne. Les règles de décision doivent tenir compte des conséquences, de l'exhaustivité des preuves, des politiques et de la réversibilité, en complément de tout score de modèle.
La conception doit permettre une dégradation progressive. Si le modèle, le connecteur ou la source de données est indisponible, le processus doit se mettre en pause, revenir à une règle plus simple ou confier le travail à une personne selon un plan de service documenté. L'entreprise doit savoir quels engagements opérationnels dépendent de l'agent et pendant combien de temps elle peut tolérer une interruption.
9. Concevoir l'approbation humaine en fonction des conséquences et de la réversibilité
L'intervention humaine ne crée un contrôle que lorsque le réviseur reçoit les bonnes preuves, comprend la décision, détient l'autorité et dispose du temps nécessaire pour la contester. Une file de centaines d'approbations de routine peut devenir purement formelle. La conception doit concentrer le jugement humain sur les actions importantes, inhabituelles ou irréversibles.
Les niveaux d'approbation doivent refléter les conséquences. Une classification interne de faible valeur peut être contrôlée par échantillonnage. Une communication client peut nécessiter une approbation lorsqu'elle modifie la position contractuelle ou concerne une personne vulnérable. Un paiement, une modification de coordonnées bancaires, une écriture comptable, une mesure RH ou un dépôt réglementaire peut nécessiter un double contrôle ou un examen spécialisé.
Le dossier d'approbation doit présenter l'action proposée, l'objectif, les preuves sources, la règle de politique, les hypothèses significatives, les exceptions, la valeur, la partie concernée, les alternatives et les conséquences en aval. Le réviseur doit pouvoir approuver, modifier, rejeter ou renvoyer le dossier. Un motif de rejet doit alimenter l'amélioration des processus sans entraîner automatiquement l'apprentissage du système.
La réversibilité influe sur le point de contrôle. La mise à jour du statut d'une tâche interne est plus facile à annuler que l'envoi de fonds, la divulgation de données ou l'émission d'une décision finale. La sensibilité au temps compte également. Le système doit déclencher une escalade avant une échéance plutôt que de pousser un réviseur à prendre une décision peu fiable au dernier moment.
La performance humaine doit être surveillée. Des approbations rapides répétées, des taux de dérogation élevés, de fréquentes corrections après approbation ou une forte variabilité entre réviseurs peuvent indiquer des preuves insuffisantes, une formation inadéquate ou un biais d'automatisation. La responsabilité reste celle du propriétaire désigné, même lorsqu'un agent a préparé le travail.

Des conséquences plus élevées et une réversibilité plus faible exigent des preuves plus solides et une approbation indépendante.
10. Encadrer les dépendances multi-agents et envers des tiers
Un agent fonctionne rarement seul. Il peut dépendre d'un fournisseur de modèle, d'une plateforme cloud, d'une couche d'orchestration, d'une base de données vectorielle, d'un connecteur, d'un service d'identité et d'une application métier. Une conception multi-agents ajoute des tâches déléguées et des communications entre systèmes ayant des propriétaires et des capacités différents.
Le registre des dépendances doit identifier le fournisseur, le service, la localisation des données, le modèle ou la version, la criticité, les droits contractuels, les sous-traitants, la conservation, la notification d'incident, le niveau de service, les preuves d'audit, le processus de changement et la trajectoire de sortie. La concentration doit être visible lorsque plusieurs flux de travail critiques reposent sur un même fournisseur ou un même plan de gestion des identifiants.
L'entreprise doit tester les changements de fournisseur. Le comportement des modèles, les schémas d'outils, les limites de débit, les paramètres de sécurité et les conditions relatives aux données peuvent évoluer. Une mise en production doit passer par un environnement contrôlé avec des tests de régression avant la production. Les changements d'urgence chez un fournisseur doivent déclencher un parcours défini de confinement et de repli.
Les messages d'agent à agent doivent utiliser des protocoles authentifiés, typés et bornés. Le système destinataire doit considérer le contenu libre comme non fiable jusqu'à validation. Chaque tâche doit porter l'objectif, le principal à l'origine, le périmètre délégué, l'expiration et les exigences de preuve. Un agent enfant ne doit pas obtenir plus d'autorité que son parent.
Les contrats doivent traiter l'utilisation des données, la confidentialité, la sécurité, la propriété intellectuelle, l'audit, les incidents, les changements, la continuité de service, la portabilité et la résiliation. Un avis juridique est requis pour la juridiction et le modèle opérationnel concernés. Des garanties techniques restent nécessaires, car un recours contractuel intervient après un incident et peut ne pas restaurer les données ni la confiance des clients.
11. Préserver le contrôle financier et des achats
La finance et les achats offrent des cas d'usage d'agents précieux, car ils impliquent une constitution répétée de preuves et la résolution d'exceptions. Ils comportent aussi des risques directs liés à la trésorerie, au reporting, à la fraude et aux fournisseurs. L'architecture des agents doit étendre l'environnement de contrôle interne existant plutôt que créer une voie parallèle de contournement.
Dans le processus d'achat au paiement, les agents peuvent vérifier la complétude de l'intégration fournisseur, comparer les preuves de facture et de bon de commande, identifier les doublons, préparer des descriptions d'exceptions et acheminer les approbations. La création ou la modification de coordonnées bancaires doit rester soumise à une vérification indépendante en dehors du canal de communication utilisé pour la demande. Les propositions de paiement doivent être rapprochées des factures approuvées et libérées selon l'autorité de trésorerie établie.
Dans le processus de comptabilisation au reporting, les agents peuvent assembler des rapprochements, tracer les écarts, préparer les justificatifs d'écritures et rédiger des commentaires. Le statut de la période, la propriété des comptes, les preuves et l'approbation doivent être validés par la machine. Les écritures significatives ou inhabituelles doivent faire l'objet d'un examen indépendant. Le système doit conserver la trace exacte de la source, de la transformation et de la décision utilisée pour chaque écriture proposée.
Dans le processus de la commande à l'encaissement, les agents peuvent identifier les lacunes documentaires, classer les litiges, préparer les actions de recouvrement et coordonner les responsables internes. La communication externe doit s'appuyer sur des faits et des pouvoirs approuvés. Les modifications de limite de crédit, les concessions, les abandons de créance et les escalades juridiquement sensibles doivent suivre les approbations existantes.
La conception doit éviter la dilution du contrôle par le volume. Un agent peut produire plus de propositions que les réviseurs ne peuvent en évaluer. Les limites de capacité, l'acheminement fondé sur le risque et le vieillissement des files d'attente doivent faire partie de la décision de mise en production. Le bénéfice financier doit être mesuré au regard du temps de cycle, des retraitements, des erreurs, du calendrier de trésorerie et de la capacité libérée, accompagnés d'indicateurs de service et de contrôle.
Tableau 4. Matrice de contrôle financier et des achats
| Cas d'usage | Contribution de l'agent | Point de contrôle déterministe | Contrôle humain ou indépendant |
|---|---|---|---|
| Intégration des fournisseurs | Rassembler les preuves et identifier les lacunes | Contrôles des champs obligatoires, des doublons, des taxes et des comptes | Approbation du responsable ; vérification indépendante des coordonnées bancaires |
| Exception de facture | Comparer les documents et expliquer les écarts | Règles arithmétiques, de devise, de doublons et de tolérance | Le responsable de l'exception approuve la résolution |
| Proposition de paiement | Regrouper les éléments échus approuvés et prévoir la trésorerie | Statut d'approbation, montant, date d'échéance et idempotence | Décaissement par la trésorerie dans le cadre du mandat existant |
| Rapprochement | rapprocher les enregistrements et préparer l'analyse des écarts | contrôle du total, de la période et de la validation de la source | le responsable du compte certifie les éléments non résolus |
| préparation des écritures | assembler les justificatifs et l'écriture proposée | règles de période, de compte, de solde et de ségrégation | le réviseur autorisé approuve et comptabilise |
| dossier de recouvrement | localiser les éléments de preuve et préparer l'action suivante | client, montant, échéance et règle de communication | le responsable approuve les actions sensibles ou engageantes |
La matrice complète les politiques existantes de l'entreprise en matière de délégations de pouvoirs, de comptabilité et de trésorerie.
12. Protéger les clients, les employés et les personnes concernées
Les agents de back-office peuvent avoir un impact sur les personnes même lorsque le cas d'usage semble administratif. Un client peut faire l'objet d'une escalade de recouvrement. Un fournisseur peut être bloqué. Un employé peut être classé, faire l'objet d'une enquête ou se voir refuser un avantage. Une réclamation peut être classée d'une manière qui modifie son traitement. L'entreprise doit évaluer les conséquences individuelles et relationnelles de chaque décision.
L'évaluation doit identifier le groupe concerné, les données utilisées, la finalité, la base juridique, le préjudice potentiel, les préoccupations d'équité, l'obligation de transparence, la revue humaine et la voie de contestation. Les données personnelles doivent être limitées à la finalité autorisée. Les données de catégories particulières ou sensibles exigent une analyse et des garanties renforcées en vertu du droit applicable.
Les communications doivent décrire avec précision le rôle de l'automatisation lorsque cela est nécessaire et offrir un moyen concret de joindre une personne. Les personnes concernées ne doivent pas être piégées dans une boucle où un agent examine la décision d'un autre agent sans intervention indépendante significative. Les réclamations et recours doivent conserver les preuves d'origine, le parcours décisionnel et les versions utilisées.
Les cas d'usage en matière d'emploi exigent une vigilance particulière. La présélection des candidats, l'analyse des performances, la gestion des absences, les mesures disciplinaires et la rupture du contrat de travail peuvent avoir des conséquences juridiques et humaines importantes. L'entreprise doit obtenir des conseils actuels en droit du travail et en protection des données, associer des responsables RH qualifiés et appliquer un examen indépendant.
L'équité doit être testée en contexte. La précision agrégée peut masquer des erreurs ou une charge inégales entre groupes, zones géographiques, langues ou segments de clientèle. L'entreprise doit définir des mesures de résultats pertinentes, examiner les schémas d'erreur et surveiller les changements après déploiement. Un examen de l'équité doit aussi déterminer si le processus lui-même se prête à l'utilisation d'un agent.
13. Concevoir pour la cybersécurité et la défaillance sûre
Le modèle de menace doit couvrir l'ensemble du système d'agents. Les attaquants peuvent manipuler les invites, les documents, les sorties d'outils, la mémoire, les connecteurs, les identifiants et les dépendances. Ils peuvent chercher à obtenir des données, de l'argent, de la persistance, à provoquer des perturbations ou à influencer les décisions commerciales. Une erreur de configuration ordinaire peut produire des conséquences similaires sans intention malveillante.
La conception sécurisée commence par des outils à périmètre restreint, des environnements isolés, le moindre privilège, des contrôles des entrées et des sorties, des secrets protégés et des frontières de confiance explicites. Le développement doit utiliser des dépôts contrôlés, des dépendances revues, des builds reproductibles et des tests. Le déploiement doit protéger l'infrastructure, la configuration et l'accès aux modèles. L'exploitation doit surveiller les comportements, les vulnérabilités, les changements de fournisseur et les incidents.
La conception de la défaillance sûre doit préciser ce qui se passe lorsque des preuves sont contradictoires, qu'un outil renvoie une structure inattendue, qu'une limite est atteinte, qu'un identifiant échoue, qu'un modèle change, qu'une dépendance est indisponible ou que l'agent se comporte en dehors de sa distribution testée. La réponse privilégiée consiste généralement à mettre en pause, préserver l'état, contenir les actions en attente et orienter le cas vers une personne.
La capacité d'arrêt doit être indépendante de l'agent. Les opérateurs doivent pouvoir désactiver une identité, un connecteur, un cas d'usage, un modèle ou toute une couche d'orchestration. Les travaux en file d'attente et les transactions partielles nécessitent une procédure de reprise. La continuité d'activité doit couvrir le processus manuel ou simplifié nécessaire pendant l'interruption.
La réponse aux incidents doit conserver les invites, les preuves récupérées, les appels d'outils, les approbations, les versions de modèle et de configuration, les horodatages et les transactions exécutées. L'équipe doit déterminer la portée, contenir l'autorité active, informer les propriétaires et conseillers concernés, rapprocher les résultats, corriger les enregistrements concernés et décider si une notification réglementaire ou contractuelle est requise.

La défaillance sûre préserve les preuves, confine l'autorité et renvoie les travaux non résolus à un responsable redevable.
14. Permettre de reconstituer chaque action significative
L'auditabilité exige plus qu'une transcription. Le dossier de preuves doit permettre de reconstituer qui ou ce qui a initié le cas, quelle autorité s'appliquait, quelles versions de données et de documents ont été récupérées, quel modèle et quelle configuration ont été utilisés, quelles décisions intermédiaires ont eu lieu, quels outils ont été appelés, quels contrôles de politique ont été effectués, qui a approuvé l'action et ce que le système de destination a enregistré.
Les journaux doivent être structurés, synchronisés dans le temps, soumis à un contrôle d'accès et protégés contre toute modification non autorisée. Ils doivent éviter les secrets et les données personnelles inutiles. La conservation doit être alignée sur les exigences légales, réglementaires, contractuelles et opérationnelles. L'entreprise doit pouvoir relier les journaux d'identité, d'agent, d'application et de transaction au moyen d'un identifiant commun de cas et d'action.
La provenance doit distinguer les faits issus des sources de l’interprétation générée par le modèle. Une personne chargée de la revue doit pouvoir ouvrir la facture justificative, le contrat, la politique ou l’enregistrement système concerné. Si l’agent a combiné plusieurs sources, les éléments de preuve doivent indiquer quelle déclaration provient de quelle source et si la source était à jour au moment de la décision.
La surveillance doit porter sur les résultats ainsi que sur l’activité technique. L’entreprise doit rapprocher les transactions exécutées, les communications clients, les écritures du grand livre, les modifications d’accès et les suites données aux exceptions. L’échantillonnage doit couvrir les cas courants, tandis que les actions importantes peuvent faire l’objet d’un examen complet.
L’accès aux éléments de preuve eux-mêmes est sensible. Les journaux d’audit peuvent contenir des processus métier, des détails de sécurité et des données personnelles. Des accès fondés sur les rôles, des limites de finalité et une surveillance indépendante sont nécessaires. L’entreprise doit tester si elle peut reconstituer un dossier avant de se fier à la conception des preuves en production.
15. Tester le système avant l’autorisation de production
Les tests doivent commencer par la conception des processus et des contrôles. L’équipe doit confirmer que l’objectif est clair, que les données sources sont fiables, que la politique peut être encodée, que l’autorité est limitée et que le chemin de défaillance est praticable. Un benchmark de modèle ne peut compenser un processus ambigu ni des éléments de preuve manquants.
L’ensemble de tests doit inclure des cas normaux, des cas rares mais importants, des dossiers incomplets, des éléments de preuve contradictoires, des documents obsolètes, des demandes en double, des instructions adverses, des appels d’outils non autorisés, des dépassements de limites de valeur, des dépendances indisponibles, des approbations retardées et des tentatives de franchir les limites d’entité ou de dossier. L’équipe doit tester l’accumulation multi-étapes, car une séquence d’actions individuellement plausibles peut créer une exposition importante.
L’évaluation doit mesurer le résultat de la tâche, l’ancrage factuel, la conformité aux politiques, l’utilisation correcte des outils, la prévention des doublons, la qualité de l’escalade, l’exhaustivité des éléments de preuve, la latence et le coût. Les tests de sécurité doivent couvrir l’injection de prompt, la fuite de données, l’élévation de privilèges, la compromission de dépendances et le déni de service. Les tests de confidentialité et d’équité doivent refléter la population concernée et le contexte juridique.
Le déploiement doit progresser via l’évaluation hors ligne, le bac à sable, le mode fantôme, la production approuvée par un humain et le fonctionnement autonome encadré. Chaque étape doit avoir des critères d’entrée et de sortie. Le mode fantôme compare les recommandations aux résultats réels des processus sans accorder de droits d’exécution. La production limitée doit plafonner les contreparties, les montants, les utilisateurs, le volume et la durée.
Des tests de régression sont requis après des modifications du modèle, du prompt, de la source de données, de l’outil, de la politique, du connecteur ou d’un processus métier important. Un registre de déploiement doit indiquer la version approuvée et les éléments de preuve. L’entreprise doit conserver la capacité de revenir en arrière ou de retirer l’autorité lorsque les résultats se dégradent.
Tableau 5. Points de contrôle des tests et du déploiement
| Point de contrôle | Éléments de preuve requis | Autorisation de production | Réponse en cas d’échec |
|---|---|---|---|
| Revue de conception | Cartographies des processus, décisions, données, menaces et autorités | Construire dans un environnement isolé | Corriger le processus ou restreindre le cas d’usage |
| évaluation hors ligne | résultats de tests représentatifs et adversariaux | aucune autorité sur les opérations réelles | conception correcte du modèle, des données, de l’outil ou de la politique |
| environnement isolé | preuves de bout en bout relatives aux outils et aux contrôles | actions synthétiques ou hors production | contenir et retester |
| mode miroir | comparaison avec des cas réels et les décisions des responsables | contexte de production en lecture seule | combler les lacunes en matière de résultats et de preuves |
| mise en production approuvée par un humain | indicateurs stables, qualité des approbations et rapprochement | propositions encadrées et actions approuvées | réduire le périmètre ou revenir à un mode d’observation |
| fonctionnement sans supervision dans des limites définies | preuves continues de maîtrise, de surveillance et de défaillance sûre | actions réversibles dans des limites strictes | révoquer l’autorisation et activer la reprise |
Les seuils et tailles d’échantillon doivent refléter le risque du cas d’usage, le volume et les exigences d’assurance applicables.
16. Instaurer un modèle opérationnel responsable
Le modèle opérationnel doit attribuer la responsabilité métier avant la mise en œuvre technique. Le propriétaire du processus métier est responsable du résultat et de la politique d’exploitation. Le propriétaire du risque approuve le traitement du risque. Le propriétaire des données pilote la qualité des sources et les usages autorisés. La sécurité est responsable du modèle de menace et de l’architecture des accès. La technologie est responsable de la fiabilité de la plateforme. L’audit interne ou une fonction d’assurance indépendante évalue la conception et le fonctionnement conformément à son mandat.
Un forum de gouvernance AI peut approuver les cas d’usage, les niveaux de risque, les enveloppes d’autorisation, les mises en production et les changements importants. Le forum doit inclure les fonctions métier, technologie, sécurité, confidentialité, juridique, conformité, finance, RH ou d’autres fonctions selon le cas d’usage. Le conseil d’administration ou le comité compétent doit approuver l’appétit pour le risque et recevoir une vue synthétique du portefeuille.
Le registre des agents doit contenir le propriétaire, la finalité, le processus, les parties concernées, les données, le modèle, les outils, l’identité, l’autorité, le niveau de risque, les approbations, les preuves de test, la mise en production, la surveillance, les incidents, les dépendances et le statut de retrait. Le registre doit distinguer les expérimentations des systèmes de production tout en appliquant des contrôles adaptés aux expérimentations qui utilisent des données sensibles ou des outils opérationnels.
La gestion du changement doit prendre en compte le personnel. Les employés doivent être formés aux capacités des agents, à leurs limites, à l’escalade, à l’examen des preuves et aux usages interdits. La conception des rôles doit déterminer les tâches supprimées, le jugement qui subsiste et les nouvelles responsabilités de contrôle qui en découlent. Les capacités libérées doivent être redéployées de façon délibérée plutôt que présumées.
L’examen critique indépendant doit se concentrer sur les preuves. Les responsables doivent démontrer le contrôle et le résultat plutôt que s’appuyer sur des déclarations de principe. Lorsque les compétences sont limitées, l’entreprise peut recourir à des spécialistes externes pour l’architecture, la cybersécurité, la confidentialité, le juridique, l’audit ou la conception des processus, tout en conservant la responsabilité interne.
17. Déployer selon une séquence de 120 jours
Les 30 premiers jours établissent les faits et les limites. La direction sélectionne une chaîne de valeur étroite, cartographie le processus et les décisions, rapproche la base de référence, classe les données, identifie les parties concernées, désigne les responsables, finalise le modèle de menace et rédige l’enveloppe d’autorisation. Un prototype manuel ou assisté par AI peut vérifier si la valeur proposée existe avant l’octroi d’un quelconque droit d’exécution en production.
Les jours 31 à 60 construisent le parcours contrôlé. L’équipe crée l’identité unique de l’agent, des outils restreints, un point de contrôle des politiques, un modèle de preuves par cas, un dossier d’approbation, la journalisation, une procédure d’arrêt sécurisé et un jeu de tests. L’évaluation hors ligne et adversariale doit corriger les défauts de traitement des instructions, d’ancrage dans les sources, de paramètres des outils et de routage des exceptions.
Les jours 61 à 90 passent par le bac à sable et le mode ombre. L’équipe compare les propositions des agents aux résultats réels des processus, mesure les performances de référence et de contrôle, teste la continuité et les procédures d’incident, réalise la due diligence des tiers et forme les réviseurs. Le périmètre de production reste en lecture seule ou soumis à approbation humaine jusqu’à ce que les critères de sortie soient remplis.
Les jours 91 à 120 recourent à une production encadrée. L’entreprise limite la valeur, le volume, les entités, les contreparties, les actions et la durée. Elle rapproche chaque action exécutée, surveille les exceptions et le comportement des réviseurs, et vérifie le bénéfice opérationnel revendiqué. Le forum de gouvernance décide s’il faut conserver, élargir, restreindre ou retirer l’autorité.
L’extension devrait réutiliser le plan de contrôle tout en répétant l’analyse des cas d’usage. Une architecture commune d’identité, de politique, de preuve et de surveillance peut réduire le coût marginal de mise en œuvre. Chaque nouveau processus nécessite néanmoins sa propre évaluation des décisions, des données, des conséquences et des aspects juridiques.

L’autorité progresse au fil de jalons de preuve, de la réalité du processus à une production encadrée.
18. Mesurer le contrôle, la valeur opérationnelle et la valeur d’entreprise
Le tableau de bord doit distinguer l’activité technique du résultat métier. Les appels d’outils, les tokens et la latence des modèles peuvent éclairer la planification des capacités. Ils ne prouvent pas que le processus s’est amélioré. Le conseil d’administration a besoin de preuves concernant le temps de cycle, le backlog, les erreurs, les reprises, le calendrier de trésorerie, la qualité de service, les exceptions de contrôle, les incidents et les capacités libérées.
Les mesures de contrôle doivent inclure les refus d’actions non autorisées, le taux d’escalade, l’exhaustivité des preuves, la prévention des doublons, les écarts de rapprochement, les dérogations à l’approbation, les corrections après action, les événements de sécurité, les événements de confidentialité, les changements de fournisseurs et le temps de rétablissement. Un faible taux de refus n’est utile que si l’autorité et la surveillance sont efficaces.
La valeur doit être mesurée par rapport à une référence rapprochée. La capacité de main-d’œuvre peut être estimée à partir du volume observé et du temps de traitement, puis validée par des changements réels de rôles et de charge de travail. Les effets de trésorerie doivent être rapprochés des transactions et des preuves bancaires ou comptables. Les pertes évitées doivent être présentées avec prudence et étayées par des incidents observés ou un modèle de risque documenté.
La valeur d’entreprise peut s’améliorer grâce à une capacité de coûts durable, une conversion de trésorerie plus rapide, un meilleur service client ou fournisseur, des contrôles renforcés, des opérations plus évolutives et un risque opérationnel moindre. Les preuves transactionnelles doivent montrer que le bénéfice persiste, dépend d’une infrastructure contrôlée et peut survivre aux changements de personnes clés ou de fournisseurs. Les acheteurs et les prêteurs peuvent décoter un bénéfice qui repose sur un système opaque ou des preuves fragiles.
La prestation commerciale doit relier le diagnostic à l’exécution. Des conseillers externes peuvent accompagner la cartographie des processus, la conception du business case, l’architecture de contrôle, la gouvernance de la mise en œuvre, la sélection de fournisseurs, la modélisation financière et le reporting au conseil. Les travaux spécialisés en droit, protection des données, cybersécurité, audit, emploi, comptabilité et réglementation doivent être réalisés par des conseillers qualifiés. Le succès doit être attesté par des livrables acceptés, des mandats signés, des honoraires encaissés et des résultats clients durables.
Tableau 6. Tableau de bord du conseil d’administration pour l’adoption contrôlée d’agents
| Dimension | Preuve principale | Indicateur du conseil d’administration | Déclencheur d'escalade |
|---|---|---|---|
| Résultat opérationnel | registre des processus et des transactions | temps de cycle, arriéré, erreurs, retraitements et service | le résultat se dégrade au-delà du seuil de tolérance |
| autorité et politiques | journaux d'identité, de politiques et d'appels d'outils | actions refusées, approuvées et exécutées par niveau de risque | une action se produit hors du périmètre autorisé |
| preuves et approbation | dossier d'instruction et décision du réviseur | exhaustivité, dérogation, correction et ancienneté | une action significative ne dispose pas de preuves reconstituables |
| sécurité et confidentialité | alertes, incidents et registre des accès | événements, exposition, confinement et temps de rétablissement | suspicion de compromission de données, d'identifiants ou d'intégrité |
| valeur financière | éléments probants de référence, de grand livre, de trésorerie et de capacité | bénéfice récurrent, échéancier de trésorerie et coût d'exploitation | le bénéfice revendiqué ne peut être rapproché |
| résilience et dépendance | enregistrements relatifs aux fournisseurs, à la continuité et aux changements | concentration, défaillances de changement et préparation au repli | le service critique ne dispose pas d'un confinement ou d'un repli viable |
Les cibles sont des choix de gestion illustratifs et doivent être approuvées pour chaque processus et chaque niveau de risque.
Conclusion de la mise en œuvre
Les agents AI peuvent améliorer le back-office du marché intermédiaire lorsque l'autorité est conçue avec le même soin que le flux de travail. La séquence pratique commence par un inventaire rapproché des processus et des décisions, sélectionne le niveau d'autonomie utile le plus faible, définit une enveloppe d'autorité explicite et attribue à chaque agent une identité distincte. Une politique déterministe, la validation et le rapprochement encadrent l'interprétation probabiliste.
L'approbation humaine est concentrée sur les conséquences et la réversibilité. Les données, les outils, les prompts, la mémoire et les fournisseurs restent à l'intérieur de limites de confiance définies. Les tests progressent depuis des éléments probants hors ligne, en passant par le bac à sable, le mode fantôme et une production encadrée. La journalisation rend les actions significatives reconstructibles, tandis que des mécanismes indépendants d'arrêt et de récupération endiguent les défaillances.
Un programme de 120 jours peut établir le plan de contrôle et démontrer la valeur opérationnelle dans un processus restreint. L'extension suit les mêmes points de contrôle pour chaque cas d'usage supplémentaire. Cela fournit au conseil d'administration des éléments probants sur la productivité et le risque, et crée une base plus crédible pour une valeur d'entreprise évolutive et prête à une transaction.
Références
- National Institute of Standards and Technology. AI Cadre de gestion des risques, y compris AI RMF 1.0, Playbook et Profil pour l'intelligence artificielle générative. https://www.nist.gov/itl/ai-risk-management-framework
- National Institute of Standards and Technology. Cadre de gestion des risques liés à l'intelligence artificielle : Profil pour l'intelligence artificielle générative, NIST AI 600-1, juillet 2024. https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf
- National Institute of Standards and Technology. AI Initiative sur les normes des agents, créée le 17 février 2026 et mise à jour le 20 avril 2026. https://www.nist.gov/artificial-intelligence/ai-agent-standards-initiative
- Centre financier international de Dubaï. Règlement 10 relatif au traitement des données personnelles au moyen de systèmes autonomes et semi-autonomes. https://www.difc.com/business/registrars-and-commissioners/commissioner-of-data-protection/regulation-10
- Centre financier international de Dubaï. Orientations en matière de protection des données à l'intention de la conformité, y compris le traitement des données personnelles au moyen de systèmes autonomes et semi-autonomes. https://www.difc.com/business/registrars-and-commissioners/commissioner-of-data-protection/guidance
- Centre national de cybersécurité du Royaume-Uni. Lignes directrices pour le développement sécurisé des systèmes AI, 27 novembre 2023. https://www.ncsc.gov.uk/collection/guidelines-secure-ai-system-development
- Commission européenne. Cadre réglementaire de la loi AI et calendrier d'application, mis à jour en juillet 2026. https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
- Commission européenne. Obligations de transparence pour les fournisseurs et déployeurs de certains systèmes AI, 20 juillet 2026. https://digital-strategy.ec.europa.eu/en/news/commission-publishes-guidelines-transparency-obligations-providers-and-deployers-certain-ai-systems
- Autorité de conduite financière et Banque d'Angleterre. L'intelligence artificielle dans les services financiers britanniques : résultats de l'enquête 2024. https://www.fca.org.uk/publications/research-notes/ai-uk-financial-services
- OCDE. Principes de l'OCDE relatifs à AI, adoptés en 2019 et actualisés en 2024. https://www.oecd.org/en/topics/ai-principles.html
- Commission de protection des données personnelles de Singapour. Approche de Singapour en matière de gouvernance de AI et cadre de gouvernance type de AI. https://www.pdpc.gov.sg/help-and-resources/2020/01/model-ai-governance-framework
- Organisation internationale de normalisation. ISO/IEC 42001:2023, systèmes de management de l'intelligence artificielle. https://www.iso.org/standard/42001
- Agence de cybersécurité et de sécurité des infrastructures. La CISA et le NCSC du Royaume-Uni dévoilent des lignes directrices conjointes pour le développement sécurisé des systèmes AI, 26 novembre 2023. https://www.cisa.gov/news-events/alerts/2023/11/26/cisa-and-uk-ncsc-unveil-joint-guidelines-secure-ai-system-development
À propos de l'auteur
Chennakeshav Adya est chercheur indépendant et associé gérant chez Matchpoint Partners. Ses travaux portent sur la finance d'entreprise, la stratégie de capital, l'exécution des transactions et les systèmes opérationnels qui relient les éléments probants financiers, les décisions du conseil et la performance mesurable de l'entreprise.

