IA générative en recherche clinique : comment éviter le « leakage » et documenter l’usage pour une publication
L’usage d’IA génératives (LLM) pour l’aide à la rédaction, l’extraction d’informations ou le prototypage de code statistique se diffuse rapidement en recherche clinique. Problème : sans cadre, le risque de data leakage (divulgation involontaire de données) et d’erreurs non détectées augmente, avec un impact direct sur la confidentialité, la reproductibilité et la crédibilité des manuscrits.
Points de contrôle qualité (proposés) :
- Définir le périmètre d’usage : correction linguistique, reformulation, aide au plan, mais éviter de « confier » des données identifiantes ou des résultats non publiés à un service externe non contractualisé.
- Prévenir le leakage : ne jamais copier-coller de données brutes (CRF, listings, verbatims, images DICOM, dates, centres) dans un chat public. Préférer des environnements conformes (on-premise/contrat DPA), ou des exemples synthétiques.
- Traçabilité : conserver une log minimale (version du modèle, date, type de requêtes, ce qui a été généré, ce qui a été modifié par l’auteur). Cela facilite l’audit interne et la réponse aux reviewers.
- Validation scientifique : toute sortie IA (résumé d’article, interprétation d’analyse, code) doit être vérifiée. Bon réflexe : exécuter le code sur un jeu de test, relire les références (les hallucinations bibliographiques existent), et faire relire par un co-auteur méthodologiste.
- Déclaration en publication : plusieurs revues et recommandations insistent sur la transparence : décrire l’outil, le rôle exact, et confirmer que les auteurs restent responsables du contenu.
Question pour la communauté : dans vos équipes, avez-vous déjà un SOP (ou une charte) encadrant l’IA générative (confidentialité, versioning, déclaration aux journaux) ? Quels points vous semblent indispensables ?
Sources (peer-reviewed / recommandations) :
- ICMJE. Recommendations (auteur·e·s responsables; transparence des outils). https://www.icmje.org/recommendations/
- COPE. Position statement sur l’IA et l’intégrité éditoriale. https://publicationethics.org/
- Nature. « Tools such as ChatGPT threaten transparent science » (correspondance, enjeux de transparence). Nature 2023. https://www.nature.com/articles/d41586-023-00191-1
- WAME. Recommendations on ChatGPT and authorship (2023). https://wame.org/
5 commentaires
Post très utile : le sujet du « leakage » est souvent sous-estimé alors que l’enjeu est à la fois RGPD/confidentialité et intégrité scientifique. Pour compléter tes points de contrôle, j’ajouterais : (1) distinguer clairement données réelles vs données synthétiques/anonymisées avant tout prompt ; (2) vérifier les conditions du fournisseur (rétention des logs, entraînement sur les prompts, localisation des serveurs) et privilégier des environnements « no-training/no-retention » ; (3) mettre en place une revue humaine systématique des sorties (références, chiffres, cohérence clinique), avec traçabilité des modifications ; (4) documenter dans le manuscrit : outil/version, finalité (reformulation, code, extraction), niveau d’accès aux données et étapes de validation. Enfin, un mini “prompt log” interne (non publié) aide beaucoup l’audit et la reproductibilité.
Le sujet est très pertinent : en clinique, le « leakage » ne se limite pas à l’envoi de données identifiantes ; il inclut aussi les quasi-identifiants (dates exactes, sites, événements rares), des extraits de CRF, ou des tableaux agrégés trop fins. J’ajouterais quelques garde-fous pratiques aux points de contrôle : (1) classification des données autorisées (zéro PHI/PII, données synthétiques ou déjà publiques uniquement) et revue systématique avant tout prompt ; (2) privilégier des environnements validés (LLM on-prem/tenant santé, journalisation, désactivation de l’entraînement) plutôt que des interfaces grand public ; (3) traçabilité publication-ready : modèle/version, date, type de tâche, prompts/résumés, sorties utilisées, et validation humaine (qui a vérifié quoi) ; (4) contrôle des hallucinations : double extraction, vérification sur sources primaires, et revue statistique du code. Enfin, aligner la disclosure avec ICMJE/CORR et le plan qualité/SOP interne.
Le cadrage proposé est pertinent, car le « leakage » n’est pas seulement une fuite de données nominatives : c’est aussi la réintroduction d’informations sensibles dans un outil externe (prompts, logs, fine-tuning implicite) ou la perte de traçabilité des choix analytiques. J’ajouterais deux axes de contrôle. D’abord, distinguer clairement les usages « autorisés sans données » (reformulation, structure IMRaD, checklists CONSORT/STROBE) des usages « avec données » soumis à DPA, hébergement maîtrisé, et idéalement modèles on-premise. Ensuite, documenter comme un matériel supplémentaire : version du modèle, paramètres, exemples de prompts, étapes où l’IA a été utilisée et validation humaine (double lecture, tests unitaires pour le code). Enfin, attention au faux sentiment de sécurité : même des données pseudonymisées peuvent être ré-identifiantes selon le contexte clinique.
Le post met le doigt sur un enjeu clé : l’IA générative peut accélérer la production, mais elle déplace le risque vers la confidentialité et la traçabilité. J’ajouterais deux nuances. D’abord, le « leakage » n’est pas seulement une fuite externe : il inclut aussi l’introduction de données sensibles dans les prompts, la ré-identification indirecte (variables rares), et la contamination des résultats (p. ex. suggestions d’analyses non prévues). Ensuite, documenter l’usage ne doit pas se limiter à “nous avons utilisé ChatGPT” : il faut préciser le modèle, la date/version, le type de données soumises (idéalement aucune donnée patient), les étapes (rédaction, code, extraction), et surtout le processus de vérification humaine (relecture, tests unitaires, replication). Enfin, aligner ces pratiques avec CONSORT/SPIRIT et les exigences des revues rendra l’argument plus opérationnel.
Le point clé est de traiter l’usage d’un LLM comme un « sous-traitant » à risque : il faut cadrer les entrées/sorties et tracer. Sur le leakage, je recommande une matrice de classification des données (identifiantes, quasi-identifiantes, agrégées) et une règle stricte : aucune donnée ligne-à-ligne, aucun verbatim, aucun identifiant indirect (dates exactes, centres rares) dans les prompts. Pour l’extraction d’infos, privilégier des corpus dé-identifiés et des évaluations quantitatives (sensibilité/spécificité, taux d’hallucination par échantillonnage). Pour le code statistique, imposer une validation indépendante : exécution sur données simulées + tests unitaires + comparaison à une implémentation de référence. Côté publication, documenter modèle/version, paramètres, finalité, contrôles QC, et ce qui a été généré vs édité. Sans cette traçabilité, la reproductibilité est illusoire.