Gouvernance de l’IA en finance : le modèle prépare, une personne valide
La gouvernance de l’IA en finance se ramène à une question que posera l’auditeur : qui a modifié ce chiffre, et qui l’a validé ? Si la réponse est « l’IA », vous n’avez pas de réponse. Les contrôles qui règlent le problème sont simples : le modèle se contente de lire par défaut et vous le prouvez, il n’écrit que dans une zone d’attente, une personne valide par une action délibérée, chaque action s’exécute sous un utilisateur nommé, et la piste d’audit enregistre le tout.
Nous appliquons ces contrôles à l’agent IA que nous faisons tourner sur notre propre Business Central, pour des contrôles internes comme les feuilles de temps. Chacun d’eux existe parce que nous en avons eu besoin.
Que demandera un auditeur sur l’IA en finance ?
Les mêmes questions que pour toute modification de données financières, plus une. Qui a fait la modification ? Avec quels droits ? Quand ? Qui l’a validée ? Et la nouvelle : qu’a proposé le modèle, et qu’a accepté la personne ?
C’est à cette dernière question que la plupart des dispositifs IA ne savent pas répondre. Si le modèle écrit directement dans la comptabilité, la proposition et la décision sont un seul et même événement, et personne ne peut montrer qu’un humain l’a regardée. Chaque contrôle qui suit sert à garder ces deux événements séparés.
Aucun nouveau référentiel n’est nécessaire. C’est la séparation entre préparer et valider que la finance applique déjà aux personnes, appliquée à un outil qui prépare très vite.
Pourquoi un agent IA ne doit-il jamais avoir son propre compte ?
Parce que la piste d’audit dirait alors « le compte », et un compte n’est pas une personne.
Sur Business Central, le serveur MCP natif, la connexion standard entre les clients IA et l’ERP, exécute chaque opération sous l’identité et avec les droits de l’utilisateur connecté. La documentation Microsoft précise que la piste d’audit montre alors qui a fait chaque action. Un agent ne peut pas faire plus que la personne sous laquelle il tourne, et tout ce qu’il fait porte le nom de cette personne.
Un utilisateur « IA » partagé jette tout cela. Il a aussi tendance à accumuler des droits avec le temps, parce que chaque nouvel usage demande un droit de plus et que personne ne se sent assez propriétaire du compte pour refuser. Un utilisateur par personne, l’agent héritant des droits de cette personne : la question « qui » garde une réponse.
Que veut dire « lecture seule par défaut » en pratique ?
Une lecture seule que vous avez prouvée, pas une lecture seule qu’on vous a annoncée.
Deux faits tirés de notre propre installation. D’abord, la permission que reçoit le client IA dans Entra ID est une permission en lecture-écriture : le guide de Microsoft utilise la permission déléguée Financials.ReadWrite.All, et nous n’avons trouvé aucune permission en lecture seule pour Business Central. Le garde-fou ne peut donc pas vivre dans la couche d’identité. Il vit dans l’ERP : dans la configuration MCP et dans les droits de l’utilisateur.
Ensuite, nous ne faisons pas confiance à l’interrupteur de configuration. Nous cherchons parmi les actions disponibles pour l’agent tout ce qui crée, modifie ou supprime, et une configuration en lecture seule répond qu’il n’y en a aucune. Cette réponse est la preuve. Le détail est dans notre article sur les agents IA dans Business Central.
La configuration elle-même est tracée. Microsoft documente une télémétrie, à partir de la version 28.0, pour la création, la modification et la suppression des configurations MCP, y compris le fait que les outils d’écriture soient autorisés ou non. Ouvrir l’écriture à un agent est en soi un événement journalisé. C’est le premier enregistrement qu’un contrôleur devrait regarder.
Comment une IA doit-elle écrire dans les données financières ?
Par une porte construite pour elle, jamais directement dans les données.
Notre schéma : le modèle remplit une zone d’attente, une page de préparation dans notre propre extension. Une action distincte et explicite, lancée volontairement, fait passer le contenu dans les vrais enregistrements. Le modèle prépare. Une personne valide.
C’est la partie qui rend l’IA sûre, et ce n’est pas une fonctionnalité d’IA. C’est du travail ERP ordinaire : une zone tampon, une action, un droit sur cette action. Les étapes d’approbation de l’ERP restent aussi là où elles sont, entre les mains des personnes. Un dispositif IA qui a besoin de contourner une approbation pour fonctionner est un dispositif qui ne devrait pas exister.
Avant toute écriture, l’agent vérifie aussi à quelle société il est connecté, et les tests se font dans une société de test, jamais en production.
Que doit contenir la piste d’audit ?
De quoi reconstituer la décision, pas seulement la modification.
Sur Business Central, Microsoft documente une télémétrie des appels d’outils du serveur MCP à partir de la version 28.0. Chaque événement porte l’identifiant de télémétrie de l’utilisateur, l’outil appelé, la configuration MCP utilisée, le client à l’origine de l’appel et le résultat. Croisé avec les enregistrements de modification de l’ERP, cela montre qui a demandé quoi à l’agent, par quelle configuration.
Nous ajoutons un élément de notre côté : les preuves de ce que l’agent a lu. Une proposition construite sur une mauvaise lecture reste une mauvaise lecture une fois approuvée. Le filtre utilisé, le nombre de lignes et la plage de dates lues accompagnent donc la proposition, comme le décrit notre méthode pour vérifier ce qu’un agent IA lit dans les données ERP. Une approbation ne vaut que ce que l’on a montré à celui qui approuve.
Quelles décisions restent à une personne ?
Toute écriture qui modifie un enregistrement financier, et toute correction qui obligerait à deviner.
Le modèle est bon pour préparer : lire un mois de saisies, les regrouper, signaler les lignes qui ne tombent pas juste, rédiger les corrections. Il ne doit pas décider qu’une ligne est juste quand la ligne elle-même ne le dit pas. Dans ce cas il la signale et nomme ce qui manque, et la personne qui connaît le contexte tranche.
Il en va de même pour les droits. Ouvrir un nouveau chemin d’écriture à un agent est une décision qui a un propriétaire, une date et une raison, pas un changement de configuration fait un vendredi après-midi.
L’approche Asio Services
Nous commençons chaque projet IA en finance en lecture seule, et nous le prouvons. Les écritures s’ouvrent une porte à la fois : une zone d’attente, une action délibérée, une vérification de la société cible, un utilisateur nommé, et des preuves jointes à chaque proposition. C’est ainsi que nous construisons l’IA pour les groupes multi-entités : les contrôles sont conçus avant la première écriture, pas ajoutés après le premier incident.
Si votre direction financière bloque l’IA parce que personne ne sait répondre à « qui a modifié ce chiffre », commencez par une session de clarté.
FAQ
Un agent IA peut-il passer des écritures dans l’ERP tout seul ?
Il le peut si vous le laissez faire, et il ne devrait pas. Gardez l’agent en lecture seule par défaut, ne le laissez écrire que dans une zone d’attente, et faites valider par une personne via une action délibérée. La piste d’audit montre alors la décision d’une personne, pas l’effet de bord d’un outil.
Un agent IA a-t-il besoin de son propre compte utilisateur ?
Non, et il ne doit pas en avoir. Sur Business Central, le serveur MCP exécute chaque action sous l’identité et avec les droits de l’utilisateur connecté, donc la piste nomme une personne. Un compte « IA » partagé remplace ce nom par « le compte ».
Que voudront voir les auditeurs sur l’usage de l’IA en finance ?
Qui a fait chaque modification, avec quels droits, et qui l’a validée. Mais aussi ce que le modèle a proposé face à ce qu’une personne a accepté, et les preuves qu’on lui a montrées. La télémétrie et les enregistrements de modification de l’ERP couvrent la première partie ; une zone d’attente et une validation délibérée couvrent le reste.
L’accès en lecture seule aux données financières suffit-il ?
C’est le bon point de départ, pas l’arrivée. La lecture seule doit être prouvée, pas supposée, et un agent peut toujours mal lire et conduire une personne à une mauvaise décision. Vérifier ce qui a été lu fait partie de la gouvernance.