Provenance par construction : des analyses IA que vos auditeurs peuvent rejouer

Dans chaque pilote d'IA d'une institution financière arrive le moment où quelqu'un pose la question qui décide du sort du projet : « Et quand le superviseur demandera d'où vient ce chiffre ? » La plupart des pilotes s'arrêtent là - non parce que les réponses étaient fausses, mais parce que personne ne pouvait prouver qu'elles étaient justes. « Le modèle l'a dit » n'est pas une réponse qu'un responsable conformité peut signer, et tout le monde dans la pièce le sait.

La réaction habituelle consiste à visser une fonction d'explication sur le côté : demander au modèle de décrire son raisonnement, stocker la description, appeler cela une piste d'audit. Nous pensons que cette approche échoue d'une manière qu'aucun polissage ne répare, et cet article décrit l'alternative que nous avons construite à la place - la provenance comme contrainte de construction. Dans DataQube, l'agent ne peut pas produire une affirmation sans que la chaîne de preuve existe, parce qu'assembler la chaîne est la manière dont les affirmations se produisent. La piste d'audit ne documente pas l'analyse. Elle est l'analyse.

Ce qu'une piste d'audit IA doit réellement contenir

Partez de ce dont un relecteur a besoin, car c'est cela qui définit la structure de données. Quand une équipe de supervision, l'audit interne ou la fonction risque de modèle examine un chiffre produit par l'IA, elle pose cinq questions dans un ordre prévisible : à quoi l'agent avait-il droit, quel savoir préalable a-t-il appliqué, qu'a-t-il réellement exécuté, comment le chiffre a-t-il été calculé à partir de ce qui est revenu, et qu'a-t-on vérifié avant que quiconque le répète.

Chacune correspond à une étape de ce que nous appelons la chaîne de preuve, et chaque réponse de l'agent porte les cinq :

• Périmètre - l'espace de travail, les droits en vigueur et le contrôle de gouvernance passé par la session avant le premier appel.
• Savoir rappelé - quelles définitions et conventions validées ont été appliquées, et quand chacune a été confirmée pour la dernière fois.
• Appels audités - chaque requête, lecture de fichier et exécution, chacune avec sa référence d'événement d'audit.
• Traçabilité du calcul - comment les lignes récupérées sont devenues le chiffre à l'écran.
• Contrôles - ce qui a été rapproché d'une source indépendante avant publication de la réponse.

Rien de tout cela n'est de la prose. Chaque étape est une donnée structurée, émise au moment où le travail se fait, avec des identifiants qui se résolvent dans le journal d'audit. Cette distinction - des événements structurés au moment de l'exécution, pas un récit après coup - rend possible le reste de cet article.

Anatomie d'une réponse auditable

Voici un exemple de la forme, tiré de notre scénario de démonstration standard : l'équipe Risque Groupe d'une banque interroge la concentration en immobilier commercial avant une réponse au superviseur. Un constat - « Le CRE Bureaux est à 92 % de sa sous-limite interne » - assemblé depuis quatre systèmes différents, chaque appel portant sa référence d'audit :

Rejouer l'exécution

D'après de réelles conversations clients — toutes les données sont fictives.

Remontez la chaîne derrière ce constat et vous ne trouverez aucun récit, seulement des enregistrements. Le côté exposition vient d'une requête en lecture seule sur l'entrepôt - 18 204 lignes, 213 millisecondes, événement d'audit evt-4c19d2. La limite agrégée de 12,5 % n'a été ni mémorisée ni supposée : elle a été lue au §3.2 du document de politique approuvé par le conseil, et la citation pointe vers la section et le passage cité, pas seulement vers un nom de fichier. Les chiffres mensuels n'ont pas été redérivés : l'agent a invoqué le workflow standard cre-monthly-exposure, exécution n° 38, paramètres figés - c'est pourquoi le nombre de cette conversation ponctuelle est identique à celui du pack mensuel distribué. Et avant d'énoncer le constat, les expositions par segment ont été rapprochées du grand livre à ±0,1 %.

Quatre systèmes, quatre références d'audit, un identifiant de corrélation qui relie toute l'exécution. Un relecteur n'a pas à croire la phrase ; il peut ouvrir chacun de ses liens.

Les affirmations portent des reçus, pas des notes de bas de page

La décision de conception porteuse se trouve un niveau sous l'interface : une affirmation, dans DataQube, est une structure de données dont les champs sont sa preuve. Voici le même constat Bureaux, déplié - c'est le panneau qui s'ouvre quand quelqu'un clique sur « Comment cela a-t-il été dérivé ? » sur le constat ci-dessus, exactement tel qu'il apparaît dans le produit :

D'après de réelles conversations clients — toutes les données sont fictives.

L'ordre des opérations est tout le sujet. L'agent n'écrit pas l'affirmation pour y attacher ensuite des pièces - il ne le peut pas. L'objet-affirmation est assemblé à partir des reçus : le résultat de requête fournit l'exposition, la lecture du document fournit la limite, l'exécution du workflow fournit la parité avec le pack standard, le contrôle fournit le rapprochement. Retirez un reçu, et il n'y a plus d'affirmation à énoncer. Nous appelons cela la provenance par construction, par contraste délibéré avec la provenance par décoration - le même contenu généré après coup en demandant à un modèle sur quoi il s'est probablement appuyé.

La conséquence pratique se voit dans les cas d'échec. Quand une source est indisponible - le document de politique a été déplacé, l'entrepôt a expiré -, un système décoratif produit une réponse assurée avec une explication plus mince. Un système constructif ne produit aucun chiffre, et dit pourquoi. Pour une équipe régulée, ce second comportement est précisément le but.

Le refus fait partie du registre

Une piste d'audit qui n'enregistre que les succès est un document marketing. Les vraies revues passent l'essentiel de leur temps sur l'espace négatif : qui a tenté d'accéder à quoi et a été refusé, quelles limites se sont déclenchées, ce que le système a refusé de faire.

Chaque décision d'autorisation dans DataQube atterrit dans le même journal immuable que l'accès aux données qu'elle gouverne - y compris, surtout, les refus. Si la session d'une analyste tente d'atteindre une source hors de ses droits, le refus est enregistré avec la règle qui s'est déclenchée. Si une action sensible a requis l'approbation d'une personne, le registre montre qui a été sollicité, ce qui a été approuvé exactement, et quand. La demande de permission et la réponse humaine sont des événements du même rang qu'une requête.

C'est aussi pourquoi « le refus explicite gagne toujours » est un énoncé d'architecture et non une préférence de politique : un refus qu'un agent peut contourner par l'argumentation n'est pas une preuve de contrôle, et les preuves de contrôle sont ce qu'un auditeur vient réellement collecter.

Ce qu'un relecteur peut rejouer sans accès au système

La chaîne serait d'un intérêt limité si son examen exigeait un compte DataQube et un administrateur bienveillant. Elle s'exporte.

La trace exportée d'un fil contient les cinq étapes de chaque affirmation, la liste complète des événements d'audit avec horodatages et nombres de lignes, les citations documentaires avec leurs passages, et les références de workflows avec leurs paramètres figés. Un relecteur travaillant avec la seule exportation peut faire trois choses qui comptent : vérifier que chaque chiffre a une chaîne complète, sans trou ; réexécuter les requêtes citées sur les systèmes source via son propre accès et comparer nombres de lignes et résultats ; et confirmer que les chiffres de politique remontent aux documents qui font foi, pas à la mémoire du modèle. Les lignes de journal ne contiennent jamais d'identifiants, de données personnelles ni de résultats bruts - la piste est une preuve, pas une seconde copie de vos données -, si bien que l'exportation peut suivre un processus de revue comme n'importe quel autre artefact d'audit.

Autrement dit : la personne qui signe la revue n'a pas besoin de faire confiance à notre logiciel. Elle doit faire confiance à son propre entrepôt, à son propre référentiel documentaire et à l'arithmétique.

Pourquoi l'explicabilité après coup échoue à l'audit

Il vaut la peine d'être précis sur l'alternative rejetée, car c'est le standard du secteur. « L'IA explicable » signifie, dans la plupart des produits actuels, demander au modèle, après sa réponse, de produire un compte rendu de son raisonnement. Le compte rendu est fluide, plausible et structurellement invérifiable - c'est une seconde sortie du modèle à propos de la première, avec le même statut épistémique et sans vérification indépendante. Quand l'explication et le calcul réel divergent, rien ne détecte la divergence. Un auditeur ne peut pas distinguer une explication fidèle d'une explication confabulée - ce qui signifie, aux fins de l'audit, que l'explication ne porte aucune information.

L'approche constructive renonce à quelque chose de réel en échange : l'agent répond plus lentement qu'un système qui s'épargne la comptabilité, et il refuse dans des situations où un produit de chat improviserait. Nous considérons ces deux coûts comme le produit fonctionnant comme prévu. Une réponse produite sans sa chaîne n'est pas une réponse au rabais - dans un environnement régulé, c'est un passif avec une bonne grammaire.

La question à poser à tout fournisseur

Si vous évaluez des outils d'analyse IA pour un environnement régulé, il existe un test à une seule question qui sépare les deux architectures : choisissez n'importe quel nombre du résultat et demandez à voir la requête qui l'a produit, le document derrière chaque chiffre de politique, et le registre de ce que le système a refusé de faire en chemin. Un système à provenance par construction répond par des liens. Un système décoratif répond par de la prose.

Notre réponse à ce test se trouve sur la page sécurité, avec la chaîne de preuve rendue en entier - et si vous voulez faire passer le test à vos propres données, réservez une démo et apportez votre chiffre le plus difficile.