Vérifier les sorties d'IA en criminalistique numérique : ce qu'une juridiction doit pouvoir voir
La question intéressante à propos de l'IA en criminalistique n'est pas de savoir si elle hallucine. C'est de savoir ce que fait votre processus quand elle hallucine.
Toute conversation sur l’IA en criminalistique numérique aboutit à la même question, en général formulée comme un défi : comment savons-nous qu’elle n’invente pas.
C’est la bonne question, et les réponses habituelles sont mauvaises. Les éditeurs répondent par des pourcentages de précision, infalsifiables au prétoire parce que personne ne peut reproduire le protocole. Ou ils répondent par des assurances sur la qualité du modèle, ce qui est une affirmation sur un composant plutôt que sur le processus qu’a subi l’élément de preuve.
La meilleure réponse est inconfortable et bien plus solide : supposez qu’elle se trompera parfois, et construisez de sorte que l’erreur soit peu coûteuse à détecter.
Ce qu’une juridiction demande réellement
Une juridiction n’évalue pas un modèle. Elle demande si une affirmation factuelle précise d’un rapport peut être étayée.
Cette question a une forme antérieure à l’IA de plusieurs décennies. D’où cela vient-il. Qui l’a examiné. Peut-on me le montrer. La défense peut-elle examiner le même matériel. Quelque chose a-t-il été modifié. L’introduction d’un modèle de langage dans le flux de travail ne change pas la question, elle change seulement la facilité avec laquelle on peut y répondre.
L’exigence de conception n’est donc pas que le modèle ait raison. C’est que chaque affirmation qu’il produit résolve vers un enregistrement précis qu’un humain peut ouvrir, lire et, au besoin, présenter à un magistrat.
Si une affirmation ne peut pas être reliée à un enregistrement, elle n’a pas sa place dans le rapport, qu’elle vienne d’un modèle ou d’un humain fatigué à vingt-trois heures.
La citation est une propriété structurelle, pas une fonctionnalité
Il y a une grande différence entre un système qui mentionne habituellement ses sources et un système incapable de produire une sortie sans elles.
Dans le premier, la citation est un comportement. Elle s’obtient en le demandant gentiment, elle se dégrade dans les cas inhabituels, et elle échoue exactement là où on en a le plus besoin : la réponse longue et complexe qui synthétise plusieurs fils, celle que l’analyste est le moins capable de contrôler de mémoire.
Dans le second, l’étape de recherche a lieu d’abord et l’identité des enregistrements retrouvés accompagne la réponse tout au long de la chaîne. La citation n’est pas quelque chose que le modèle a rédigé. C’est le relevé des lignes qui ont été lues.
C’est cette distinction qu’un évaluateur devrait sonder. La question utile n’est pas « cite-t-il ses sources » mais « que se passe-t-il s’il n’en trouve pas », et la seule réponse acceptable est qu’aucune affirmation n’est produite.
La vérification doit être bon marché, sinon elle n’aura pas lieu
Voici la partie sous-estimée, et c’est un problème de facteurs humains plutôt que de technique.
Tout processus exigeant qu’un analyste passe une après-midi à confirmer un constat produira, sous charge, moins de constats confirmés. Non par négligence, mais parce que le temps est fini et que cette confirmation entre en concurrence avec les douze autres scellés en attente. Une vérification coûteuse est une vérification rationnée, et une vérification rationnée est pire qu’aucune automatisation, parce qu’elle donne l’apparence de la rigueur sans la substance.
La mesure qui compte est donc le coût d’un contrôle. Si atterrir sur l’enregistrement source tient en un clic et montre la ligne d’origine dans son contexte, la vérification cesse d’être une décision que l’analyste doit prendre. Elle devient le comportement par défaut, parce que la sauter ne fait rien gagner.
C’est l’argument en faveur d’une traçabilité inscrite dans le modèle d’enregistrement plutôt que reconstruite à l’affichage. Une citation qui résout encore après révision du mapping qui l’a produite est une citation sur laquelle un analyste peut s’appuyer des mois plus tard, quand l’affaire arrive à l’audience et que personne ne se souvient des détails.
Quatre questions à poser à un éditeur
Si vous évaluez un outil comportant un assistant IA, quatre questions séparent les sérieux des autres.
Puis-je cliquer sur n’importe quelle affirmation et atterrir sur l’enregistrement source ? Pas un document, pas une page : l’enregistrement. Demandez qu’on le fasse en direct, sur une affirmation que vous choisissez, dans un fil que vous désignez.
Qu’est-ce qui est journalisé ? Chaque action de l’assistant et chaque résultat reçu doivent être écrits dans un endroit que vous contrôlez et pouvez lire. Si le journal réside chez l’éditeur, c’est un autre produit avec un autre profil de risque.
Où vont les données ? Si la réponse implique un fournisseur d’inférence tiers, c’est une décision que votre service doit prendre délibérément plutôt que découvrir lors d’un audit de sécurité après déploiement.
Que fait-il quand il ne sait pas ? Posez une question à laquelle les données ne peuvent pas répondre et observez. Un système qui produit un paragraphe assuré, bien écrit et entièrement infondé vous a tout dit de son comportement sur une vraie affaire à deux heures du matin.
La position honnête
Les experts judiciaires indépendants sont constants sur ce point : une sortie d’IA doit être vérifiée contre les données d’origine avant de pouvoir être exploitée. Ce n’est pas une limitation à contourner par l’ingénierie, c’est la relation correcte entre un système automatisé et un processus probatoire.
L’intérêt d’introduire un modèle dans le travail criminalistique n’est pas de remplacer le jugement de l’analyste. C’est de rendre l’exercice de ce jugement possible à un volume où il cesse autrement d’avoir lieu, discrètement. Un analyste qui pouvait auparavant lire cinq pour cent d’un appareil et qui lit maintenant la partie pertinente de l’ensemble, avec chaque conclusion contrôlable en un clic, fait du meilleur travail criminalistique, pas du travail criminalistique plus automatisé.
C’est la seule affirmation qui mérite d’être faite, et c’est celle sur laquelle je préfère être jugé.
VERA
VERA est un logiciel d'analyse criminalistique pour supports numériques saisis. Il structure une extraction Full File System brute, la rend consultable et interrogeable avec citation des sources, et fonctionne entièrement hors ligne sur votre infrastructure.
Demander une démonstrationÀ lire aussi
Pourquoi l'hébergement sur site compte pour les données de supports saisis
Pour un laboratoire de criminalistique, faire tourner un logiciel d'analyse sur sa propre infrastructure n'est pas une préférence d'architecture informatique. C'est en général la différence entre pouvoir acheter un produit et ne pas pouvoir.
Applications non prises en charge : le goulet d'étranglement silencieux des laboratoires
Les applications qu'un outil de criminalistique ne sait pas lire n'ont rien d'exotique. Elles sont régionales, elles sont récentes, ou elles se sont simplement mises à jour le mois dernier, et ensemble elles représentent une part notable des preuves jamais exploitées.