Espérer que le modèle interprète correctement le statut n''est pas une stratégie

Il y a quelques trimestres, un collègue a demandé à un produit de conformité IA bien connu si une clause spécifique d'un projet d'accord satisfaisait une obligation spécifique en vertu d'une loi particulière d'un État. Le produit a répondu avec assurance. La réponse était fausse. Le statut cité avait été modifié six mois plus tôt, et l'obligation ne se lisait plus comme le modélisation le suggérait.

Ce n'est pas l'histoire de ce seul produit. C'est l'histoire de toute la génération actuelle d'outils de conformité IA, et de la décision stratégique que les entreprises réglementées doivent maintenant prendre. Le schéma est le même chez tous les fournisseurs. Extraire le texte du statut. Le fournir à un grand modèle linguistique. Faire confiance à l'interprétation. Livrer la réponse.

Ce n'est pas ça, la conformité. C'est juste... de l'espoir.

Ce à quoi ressemble le schéma en pratique

L'architecture de la plupart des outils de conformité IA actuels est un mince enveloppe autour d'un modèle linguistique généraliste avec une couche de récupération sur le texte statutaire. Le argument de vente est que le modèle peut lire la loi. L'hypothèse tacite est que lire équivaut à être en conformité.

Lire n'est pas être en conformité. Un statut n'est pas une recette. C'est le texte de surface d'un régime réglementaire qui comprend les orientations interprétatives, l'historique des contrôles, la réglementation des agences, les décisions de justice, les dossiers de règlement, les livrables des groupes de travail et le contexte opérationnel spécifique de l'entreprise réglementée. Le modèle voit le texte. Il déduit le reste. Cette déduction est parfois juste et parfois fausse avec assurance, et l'entreprise réglementée ne peut pas savoir laquelle.

Le discours commercial aggrave le problème. Les démonstrations sont effectuées sur des lois fédérales stables et bien citées où l'inférence du modèle coïncide avec l'obligation réelle. L'achat du contrat est signé sur la base de la démonstration. Le produit est ensuite déployé face à une loi étatique fragmentée, des dispositions récemment modifiées, des actes partiellement suspendus et des orientations de l'agence qui n'ont pas été intégrées aux données d'entraînement. Le modèle continue de répondre avec assurance. Les réponses continuent d'être fausses, mais moins visibles.

Pourquoi c'est un problème stratégique, pas technique

Une entreprise réglementée ne peut déléguer l'interprétation de ses obligations à un tiers qui ignore ce que sont réellement ces obligations. C'est à l'entreprise qu'incombe le devoir. Ce devoir ne se transfère pas avec l'achat.

Lorsqu'un régulateur demande à l'entreprise quel était son état de conformité au jour de l'incident, "le modèle a dit que c'était bon" n'est pas une réponse. Le régulateur veut savoir quelles étaient les obligations que l'entreprise comprenait avoir, quelles preuves l'entreprise avait pour remplir ces obligations et quel processus l'entreprise avait pour maintenir cette compréhension à jour. Aucun de ces éléments ne peut être expliqué par un modèle qui interprétait le texte statutaire à la demande et qui ne conservait pas un enregistrement structuré de cette interprétation.

C'est un problème stratégique parce que l'entreprise a construit un flux de travail qui produit un résultat qu'elle ne peut pas défendre. Le résultat ressemble à de la conformité. La piste d'audit ne survit pas au contact du processus d'application réel. L'entreprise a acheté un outil qui l'aide à paraître conforme sans l'aider à l'être.

La même distinction qu'est PAICE concernant les personnes

PAICE présente une thèse centrale sur la manière dont les professionnels collaborent avec l'IA : les tests battent la conversation. Une personne qui semble éloquente mais manque les erreurs injectées obtient un score inférieur à une personne concise qui capte tout. La conversation est le médium. Ce n'est pas la mesure.

La même distinction s'applique aux outils de conformité. Un outil qui semble correct sur une obligation n'est pas le même qu'un outil qui prouve obtenir l'obligation correctement lors d'un audit. Le médium est le discours généré. La mesure est de savoir si la représentation structurée du devoir survit au contact de l'enregistrement d'application réel.

Ce n'est pas une métaphore. C'est le même mode de défaillance architectural à deux échelles. Une personne qui raconte son flux de travail IA avec éloquence mais qui ne peut pas dire quand le modèle se trompe est un problème de fluidité. Un outil de conformité qui raconte une obligation avec éloquence mais qui ne peut pas montrer son travail par rapport à un enregistrement structuré faisant autorité est le même problème de fluidité. Les deux échouent sous la contrainte de la même manière. Les deux semblent productifs jusqu'à ce que la contrainte arrive.

Ce qu'exige une véritable conformité

Une représentation de conformité qui tient la route possède trois propriétés.

Elle existe en dehors du modèle. La représentation structurée de l'obligation ne dépend pas de la version du modèle utilisée ce trimestre. Le modèle peut changer. La représentation de l'obligation reste fixe. Lorsque le modèle se trompe, la représentation est la correction.

Elle possède une provenance. Chaque affirmation concernant ce qu'exige un devoir pointe vers un artefact d'autorité qu'un régulateur reconnaîtrait : le statut, l'orientation de l'agence, l'interprétation publiée, l'enregistrement des contrôles. Les pointeurs sont durables. Les artefacts sont stockés dans un registre civique qui ne bouge pas silencieusement lorsqu'un site web est refait. PubLedge est la couche utilisée par le schéma ObligationFirst à cet effet.

Elle survit à la gestion des versions. Les statuts sont modifiés. Les orientations de l'agence sont révisées. L'application est enjoinée ou dégelée. La représentation gère ces transitions comme des relations de première classe, pas comme des remplacements silencieux. Le devoir qui s'appliquait hier et le devoir qui s'applique aujourd'hui sont tous deux interrogeables. Un plaignant discutant des événements survenus sous l'ancien devoir peut encore trouver l'ancien devoir dans l'enregistrement.

Le modèle dans le flux de travail est suffisant. Le modèle qui porte le flux de travail est le problème.

À quoi ressemble l'alternative stratégique

L'alternative n'est pas d'abandonner l'IA dans le travail de conformité. C'est de placer le modèle derrière une représentation structurée de l'obligation, au lieu de le placer devant.

Dans l'architecture alternative, l'obligation est représentée dans un schéma comme ObligationFirst, avec des champs pour l'acteur, l'action, la condition, l'échéance, l'autorité et l'exception. La provenance pointe vers les artefacts PubLedge. Le modèle est utilisé pour les parties du flux de travail où les modèles sont bons : faire remonter les obligations pertinentes à partir du graphe, rédiger le langage pour examen humain, expliquer un devoir à un non-spécialiste, signaler où le graphe de l'obligation semble silencieux sur une question à laquelle l'entreprise doit répondre. Le modèle ne génère pas le devoir. Le modèle navigue le devoir.

Ce n'est pas une alternative hypothétique. Le schéma existe. Les premiers domaines sont modélisés. Les exemples travaillés sont publics. Le passage des outils de conformité actuels à une posture défendable est incrémental, pas un tout ou rien.

Ce que cela signifie pour les achats

Si votre entreprise achète un outil de conformité IA, la question à poser au fournisseur n'est plus : "lit-il la loi." Les modèles lisent du texte. Ce n'est plus le facteur différenciateur. Les questions sont :

L'outil conserve-t-il une représentation structurée des obligations qu'il prétend vérifier, séparée de l'interprétation du modèle ?

L'outil peut-il montrer son travail sous une forme qu'un régulateur accepterait — chaînes de citation vers les artefacts d'autorité, historique de version de l'obligation vérifiée, et une piste d'audit qui survit au remplacement du modèle au trimestre prochain ?

L'outil gère-t-il les cas où la loi est instable — partiellement enjoinée, récemment modifiée, en cours de réglementation — ou se contente-t-il de présumer silencieusement la version la plus récente du texte dans les données d'entraînement ?

Si la réponse aux trois est oui, le fournisseur a construit quelque chose de défendable. Si la réponse à l'une est "le modèle s'en charge", le fournisseur a construit un problème de fluidité.

En bref

Paraître conforme et être conforme ne sont pas la même chose. La distinction n'est pas nouvelle. Elle s'applique à la pratique juridique, au reporting réglementaire et aux personnes qui font le travail. Elle s'applique maintenant également aux outils que les gens utilisent.

Le choix qui incombe aux entreprises réglementées n'est pas d'utiliser l'IA en conformité. C'est de savoir si le modèle doit être devant ou derrière l'obligation. L'un est une stratégie. L'autre est un espoir.

Vous souhaitez évaluer la préparation de votre équipe à la collaboration IA ? Découvrez PAICE pour les organisations ou faites une évaluation individuelle pour le voir par vous-même.