Documents générés par l'IA et validité juridique : le fossé de conformité
Les systèmes d’IA peuvent désormais produire un projet de contrat, un rapport de conformité ou une facture structurée en quelques secondes. La production est grammaticalement correcte, formatée de manière professionnelle et souvent indiscernable d’un document rédigé par un humain au premier coup d’oeil.
Cette capacité crée un fossé de conformité qui n’est pas bien compris. Ce fossé ne porte pas sur la qualité de l’écriture par l’IA. Il se situe entre “générer un texte qui ressemble à un document juridique” et “produire un document juridiquement valide.”
Ce sont des problèmes différents, et résoudre le premier ne résout pas le second.
Ce qui rend un document juridiquement valide
La validité juridique n’est pas une propriété du texte. C’est une propriété du processus qui a produit le document et des preuves pouvant être présentées concernant ce processus.
Un contrat est juridiquement valide s’il a été formé par des parties ayant la capacité de contracter, exprime leur véritable consentement mutuel, et a été créé par un processus pouvant être démontré en cas de contestation. Les mots du contrat importent, mais la provenance aussi : qui a accepté, quand, dans quelles circonstances, et tout cela peut-il être prouvé en cas de litige ?
Une facture est juridiquement valide à des fins fiscales si elle contient les champs requis dans le format requis, a été émise par la partie identifiée et n’a pas été modifiée après son émission. La conformité de format est nécessaire mais pas suffisante. La facture doit aussi être prouvablement non modifiée.
Un rapport de conformité est juridiquement valide s’il reflète fidèlement l’état qu’il prétend documenter, a été produit par une méthodologie pouvant être examinée, et est attribuable à une partie responsable.
Dans chaque cas, la validité requiert l’intégrité du processus, pas seulement la qualité du contenu. L’IA peut produire le contenu. Elle ne peut pas produire les preuves du processus.
Le problème d’hallucination dans les documents juridiques
Les modèles de langage IA produisent des sorties statistiquement plausibles compte tenu de leurs données d’entraînement. Ils ne récupèrent pas des faits ; ils génèrent du texte. Pour certains types de documents, cette distinction est sans importance : une facture basée sur un modèle où l’IA renseigne les montants à partir d’une entrée structurée est essentiellement déterministe et le risque d’hallucination est faible.
Pour les documents où l’IA génère un contenu substantiel (une clause contractuelle, une analyse réglementaire, une assertion de conformité), le risque est plus élevé. Le modèle peut :
- Citer des réglementations qui n’existent pas ou qui ont été abrogées
- Énoncer des faits sur les parties qui sont incorrects ou obsolètes
- Omettre des mentions obligatoires parce qu’elles n’étaient pas dans les données d’entraînement pour des documents similaires
- Produire des combinaisons de clauses qui sont incohérentes en interne d’une manière non détectable en lisant chaque clause séparément
La conséquence pratique : les documents juridiques générés par l’IA nécessitent une étape de révision substantielle, pas seulement une étape de relecture. La révision doit être effectuée par quelqu’un qui possède les connaissances du domaine pour détecter des erreurs que l’IA ne signalerait pas, car l’IA ne sait pas ce qu’elle ignore.
La vérification de conformité comme couche distincte
Pour les types de documents structurés où il existe un schéma formel ou un ensemble de règles, la vérification automatique de conformité peut valider que la production générée par l’IA répond aux exigences formelles, indépendamment de l’exactitude du contenu.
Une facture conforme à EN16931 a des règles de validation formelles : champs obligatoires, relations arithmétiques entre les montants, codes de catégorie de TVA et règles métier Schematron. Ceux-ci peuvent être vérifiés automatiquement et de manière déterministe. Un générateur de factures IA qui passe toutes les règles Schematron EN16931 est au moins formellement correct, même si les montants de la facture eux-mêmes sont incorrects (ce qui serait une erreur de saisie de données, pas une erreur de production de l’IA).
Pour les contrats et les rapports, les schémas formels sont plus rares, mais ils existent dans des domaines spécifiques : la documentation hypothécaire (format ESIS normalisé de l’UE), les documents d’informations clés d’assurance (format KID PRIIPs de l’UE), et les avis de marchés publics (eForms de l’UE).
Le schéma est le suivant : utilisez l’IA pour la vitesse de génération, utilisez la validation formelle pour l’assurance de conformité, et conservez-les comme des étapes distinctes du pipeline. La production de l’IA est une entrée dans l’étape de validation, pas le produit final.
Chaîne de custody pour les documents générés par l’IA
Un document généré par l’IA pose une question de provenance que les documents rédigés par des humains ne rencontrent pas : qu’est-ce qui l’a généré, avec quelle entrée, à quel moment, et la production a-t-elle été modifiée avant son utilisation ?
Cela importe pour deux raisons. D’abord, si un document est contesté, vous devez pouvoir montrer que le processus de génération était sain. Ensuite, l’article 22 du RGPD crée des obligations spécifiques concernant la prise de décision automatisée qui affecte les personnes. Un contrat ou un avis généré entièrement par l’IA peut déclencher des obligations de divulgation s’il affecte les droits d’une personne.
La réponse est la même que pour tout autre document : une piste d’audit à chaîne de hachage qui enregistre l’événement de génération (y compris la version du modèle, les paramètres d’entrée et le hachage de la production), toutes les étapes ultérieures de révision et d’approbation, et l’action d’archivage final. Cette piste ne prouve pas l’exactitude du contenu, mais prouve que le processus a été suivi.
Exigences d’explicabilité pour les décisions de conformité
Certains flux de travail de conformité assistés par l’IA impliquent des décisions, pas seulement la génération de documents : classer la catégorie de conservation d’un document, signaler une clause de contrat pour révision, ou déterminer si une transaction nécessite une vérification supplémentaire.
Pour les décisions qui affectent les personnes ou qui doivent être auditables en vertu de la loi, le composant IA doit produire une explication en même temps que la sortie. Une classification qui dit “conserver 10 ans” sans raisonnement n’est pas utile pour un auditeur qui demande pourquoi cette classification a été faite.
L’explicabilité dans ce contexte signifie une sortie structurée qui enregistre la classification, le niveau de confiance et les caractéristiques ou règles qui ont guidé la décision. Cette sortie fait partie de la piste d’audit du document et est incluse dans le pack de preuves.
Sans explicabilité, les décisions de l’IA dans les flux de travail de conformité produisent des sorties qui ne peuvent pas être défendues rétrospectivement. La décision semble arbitraire car il n’y a aucune trace de la raison pour laquelle elle a été prise.
La question de gouvernance pour l’IA dans les flux documentaires
Les organisations utilisant l’IA dans des flux documentaires ont besoin d’un cadre de gouvernance qui réponde aux questions suivantes :
- Quels types de documents sont approuvés pour la génération par l’IA sans révision humaine obligatoire ?
- Lesquels nécessitent une étape de révision humaine avant que le document puisse être archivé ou envoyé ?
- Quel est le processus pour détecter et corriger les erreurs de l’IA qui se retrouvent dans une archive ?
- Comment les mises à jour des modèles d’IA sont-elles gérées ? Une mise à jour de modèle nécessite-t-elle une revalidation des documents générés précédemment ?
- Quelle piste d’audit existe pour l’étape de génération par l’IA elle-même ?
Ce ne sont pas des questions sur la qualité de l’IA. Ce sont des questions sur les contrôles de processus qui s’appliqueraient à tout système automatisé dans un environnement réglementé.
SealDoc et les flux documentaires IA
SealDoc fournit la couche de preuves pour les documents générés par l’IA. L’étape de génération (par tout système d’IA) produit un document. SealDoc valide ce document par rapport aux règles de format applicables (EN16931, PDF/A-3, XRechnung ou schémas personnalisés), applique un horodatage RFC 3161, enregistre le résultat de validation et l’horodatage dans une piste d’audit à chaîne de hachage, et regroupe tout dans un Pack de Preuves Légales.
Il en résulte que le document généré par l’IA dispose de la même infrastructure de preuves qu’un document rédigé par un humain : un moment de création prouvable, un résultat de validation formelle capturé à la création, et une piste d’audit inviolable.
Ce que SealDoc ne fait pas, c’est vérifier l’exactitude substantielle du contenu. C’est une étape de révision humaine spécifique au domaine. L’infrastructure gère tout ce qui est formellement vérifiable. Le jugement sur la pertinence des clauses du contrat reste aux personnes responsables du document.
Cette séparation est la bonne architecture pour l’IA dans les flux de travail de conformité : l’IA pour la vitesse de génération, la validation formelle pour la conformité structurelle, la révision humaine pour l’exactitude substantielle, l’infrastructure de preuves pour tout ce qui doit survivre à une contestation.