Comment une CRO qualifie un fournisseur d'IA dans son propre système qualité

L'appel d'offres du promoteur pose déjà la question. Votre SMQ n'a pas encore de réponse.

Au cours des deux derniers cycles, une question a migré de la diapositive innovation vers la section qualification de l'appel d'offres du promoteur. À quelques variantes près, elle se lit ainsi :

Décrivez les systèmes d'intelligence artificielle ou d'apprentissage automatique utilisés dans la prestation de ces services. Décrivez comment ces systèmes sont validés. Décrivez comment leurs sorties sont maîtrisées au sein de votre système de management de la qualité. Identifiez qui répond de la sortie.

Ce n'est pas une question d'innovation. C'est une question de qualification fournisseur, et elle atterrit sur le bureau de l'unité qualité, pas sur celui du développement commercial. La plupart des CRO y répondent aujourd'hui de deux façons, et les deux perdent l'appel d'offres.

Les deux réponses perdantes

La première est la négation. « Nous n'utilisons pas de systèmes d'IA dans la prestation de ces services. » C'était défendable il y a dix-huit mois. Le promoteur lit désormais cette phrase comme fausse ou comme non compétitive, parce qu'il sait ce que proposent les autres soumissionnaires et à quoi ressemble un flux moderne de rédaction médicale ou de faisabilité.

La seconde est le certificat de sécurité. La CRO transmet le rapport SOC 2 ou le certificat ISO 27001 du fournisseur. C'est une erreur de catégorie, et le responsable qualité du promoteur la repère immédiatement. SOC 2 indique que le fournisseur ne perdra pas vos données. Il n'indique rien sur la fiabilité de la sortie dans une soumission réglementaire. Sécurité de l'information et validation des systèmes informatisés sont deux disciplines distinctes répondant à deux questions distinctes, et l'appel d'offres a posé la seconde.

Pourquoi l'unité qualité est réellement bloquée

Il faut le dire clairement, car la difficulté est réelle et ne relève d'aucun manque de diligence.

La validation des systèmes informatisés, telle que pratiquée sous GAMP 5 et attendue par les inspecteurs, repose sur une hypothèse ancienne et parfaitement raisonnable : le système est déterministe. Vous définissez l'exigence, vous spécifiez la conception, vous testez l'installation, le fonctionnement et la performance, et vous démontrez que la même entrée produit la même sortie. La répétabilité est la poutre porteuse. Chaque artefact du dossier de validation, chaque matrice de traçabilité, chaque déclencheur de requalification repose dessus.

Un grand modèle de langage n'offre pas cette répétabilité. La même entrée peut produire des sorties différentes. Le réglage de la température et la fixation de la graine réduisent la variance mais ne rendent pas le système déterministe, et une unité qualité qui rédige un protocole de PQ affirmant le contraire a rédigé un document qu'elle ne pourra pas défendre en inspection.

On demande donc à la fonction qualité de la CRO de valider quelque chose dont le comportement fondamental brise le cadre même sur lequel la validation a été bâtie. Ce n'est pas un problème de paperasse. C'est un problème structurel, et dire à un directeur qualité d'« étendre simplement la procédure existante » n'est pas une réponse.

Ce que le promoteur demande réellement

Relisez la question et observez ce qu'elle ne demande pas. Elle ne demande pas si le modèle est précis. Elle ne réclame aucun score de benchmark. Elle demande comment la sortie est maîtrisée et qui en répond.

C'est une question de preuve, pas une question de modèle.

Le cadre réglementaire que le promoteur a en tête est celui dans lequel il vit déjà. Sous 21 CFR Part 11 et l'Annexe 11 européenne, les enregistrements soutenant une décision réglementée exigent des pistes d'audit attribuables, contemporaines et durables. Sous ALCOA+, les données correspondantes doivent être attribuables, lisibles, contemporaines, originales et exactes. Sous ICH E6(R3), le promoteur reste responsable des systèmes utilisés dans la conduite de l'essai, quel qu'en soit l'opérateur. Aucun de ces cadres ne demande si le modèle est intelligent. Tous demandent si vous pouvez démontrer votre cheminement après coup, devant quelqu'un d'hostile, des années plus tard.

Voici le renversement qui débloque l'ensemble :

Vous ne validez pas le modèle. Vous validez la preuve que le modèle produit.

Un système probabiliste qui émet une affirmation invérifiable est invalidable, et aucune quantité de documentation n'y remédie. Un système probabiliste dont la sortie est contrôlée par un mécanisme distinct et indépendant avant qu'un humain la voie est un objet différent. Ce qui entre dans votre système qualité n'est pas l'avis du modèle. C'est un artefact contrôlé, doté d'une provenance traçable, et les artefacts contrôlés, votre SMQ sait déjà les traiter.

La vérification comme couche distincte

C'est le principe d'architecture qui sous-tend le Three-Gate Verification System de NexTrial, et il mérite une description structurelle plutôt qu'un argumentaire produit, car c'est la structure que l'unité qualité d'une CRO doit évaluer.

Gate 1, juridiction. L'ensemble d'exigences réglementaires applicable est résolu avant toute génération. Ce qu'exige la FDA n'est pas ce qu'exige l'ANVISA, ni ce qu'exige la CDSCO, et un système qui traite la juridiction comme un filtre postérieur a déjà produit le mauvais artefact. Gate 1 est conçu pour faire de la juridiction une contrainte d'entrée et non un contrôle en aval.

Gate 2, preuve structurelle. L'artefact généré est contrôlé face à la structure d'exigences de la juridiction par un mécanisme indépendant du modèle qui l'a produit. Tout l'intérêt de cette indépendance tient à la preuve non corrélée : un modèle qui contrôle sa propre sortie partage les modes de défaillance de ce qu'il contrôle, raison pour laquelle les scores d'auto-cohérence et les indices de confiance ne constituent pas une preuve. Cette couche de preuve structurelle est livrée et se trouve en première validation auprès d'un promoteur. Un promoteur constitue un petit n, et il est énoncé ici comme petit n délibérément.

Gate 3, supervision humaine. Le verdict va à un humain qualifié, qui décide. Ni une recommandation que l'humain contresigne, ni une automatisation que l'humain surveille. La décision demeure un acte humain, avec la preuve qui lui est attachée.

Une couche de vérification formelle construite en Lean 4 est en cours de développement. Elle n'est pas en production, et aucun chiffre de performance ne lui est associé ici, car un chiffre associé à un système non livré est un chiffre fabriqué.

Pourquoi cette structure compte pour une CRO en particulier : elle produit un artefact que vous présentez à l'auditeur du promoteur sans avoir à défendre le modèle. L'objet défendable est la preuve, pas la prédiction.

La couche juridictionnelle et ses variations régionales

Trois choses sont vraies simultanément pour une CRO opérant à l'international, et chacune engendre une version différente de la même question.

Au Brésil, un promoteur international sous l'ANVISA affronte une structure d'exigences réellement distincte de celle de la FDA, et c'est la CRO qui assure la conduite locale qui doit en démontrer la conformité. Coder cette structure, plutôt que traduire une liste de contrôle américaine, fait la différence entre une soumission qui passe et une soumission qui revient.

En Inde, les obligations de conformité au protocole devant la CDSCO pour les promoteurs étrangers coexistent avec un modèle de prestation souvent fonctionnel plutôt que complet, ce qui modifie le porteur de l'obligation qualité et la façon dont la qualification fournisseur remonte jusqu'au promoteur.

En Europe, la question ouverte est de savoir si un système donné d'appui aux essais cliniques relève de la catégorie à haut risque au titre du règlement européen sur l'IA, et quelles obligations s'y attachent le cas échéant. Cette question n'est pas tranchée pour cette classe d'outils, et tout fournisseur qui affirme le contraire à une CRO devra se rétracter plus tard. La posture correcte consiste à constituer la documentation technique et la journalisation qu'une classification à haut risque exigerait, et à pouvoir les présenter quelle que soit l'issue.

Huit questions à poser à tout fournisseur d'IA

L'unité qualité d'une CRO peut adresser ces questions à tout fournisseur de la catégorie, nous compris. Elles sont ordonnées pour que les quatre premières disqualifient rapidement.

1. Lorsque votre système produit une sortie, quel mécanisme indépendant la contrôle avant qu'un humain la voie ? Si la réponse est un indice de confiance produit par le même modèle, il n'y a pas de contrôle indépendant.
2. Ce mécanisme de contrôle est-il corrélé au modèle générateur ? Données d'entraînement, architecture ou contexte de prompt partagés signifient angles morts partagés.
3. Quel artefact votre système remet-il à notre système qualité, et quel est son enregistrement de provenance ? Vous qualifiez l'artefact, pas le logiciel.
4. Montrez-moi la piste d'audit d'une seule décision, de bout en bout. Ce qui ne peut être reconstitué sur demande ne survivra pas à une inspection.
5. Quelle structure d'exigences juridictionnelles a été appliquée, et où cet encodage est-il maintenu ? Une juridiction traitée comme une couche de traduction est une juridiction mal traitée.
6. Qu'est-ce qui, dans votre plateforme, est livré, et qu'est-ce qui est en développement ? Exigez la réponse dans ces termes. Le temps du verbe vous dit ce que vous achetez.
7. Où se situe la décision humaine dans votre flux, et peut-elle être contournée ? Si elle peut l'être sous pression de délai, elle le sera.
8. Que stocke votre système, et que ne stocke-t-il jamais ? Pour une CRO détenant des données du promoteur sous contrat, la frontière compte plus que la capacité.

Un fournisseur qui répond aux huit en langage clair est un fournisseur que votre unité qualité peut qualifier. Un fournisseur qui répond par des scores de benchmark n'a pas compris la question.

Le point commercial

La CRO capable de remettre au promoteur un dossier de validation remporte l'appel d'offres. Ni la CRO la plus dotée en IA, ni la moins dotée. C'est celle dont l'unité qualité répond à la section qualification sans broncher, car cette réponse transforme une déclaration d'innovation en service achetable.

Voilà la demande réelle. Ce n'est pas un achat de technologie. C'est un achat de preuve.

La preuve, pas la substitution. L'humain décide.

Questions fréquentes

Un système d'IA peut-il être validé sous GAMP 5 ?
Le cadre de validation présuppose un comportement déterministe, qu'un grand modèle de langage n'offre pas. L'approche viable consiste à valider la preuve produite par le système plutôt que le modèle lui-même, en exigeant un mécanisme de vérification indépendant entre la sortie générée et la décision humaine.

SOC 2 ou ISO 27001 répondent-ils à la question de qualification IA d'un promoteur ?
Non. Ces certifications portent sur la sécurité de l'information. La question de qualification du promoteur porte sur la fiabilité de la sortie dans une décision réglementée, ce qui relève de la validation des systèmes informatisés et non de la sécurité.

Qui répond d'une sortie d'IA dans un essai clinique sous ICH E6(R3) ?
La responsabilité des systèmes utilisés dans la conduite de l'essai demeure celle du promoteur, quel qu'en soit l'opérateur, raison pour laquelle la preuve de qualification fournisseur de la CRO remonte jusqu'à la préparation à l'inspection du promoteur.

Qu'est-ce que la preuve non corrélée ?
Une vérification produite par un mécanisme qui ne partage ni l'architecture, ni les données d'entraînement, ni le contexte du modèle générateur. Les contrôles corrélés reproduisent l'erreur d'origine, raison pour laquelle l'indice de confiance d'un modèle n'atteste pas de sa justesse.

Que doit demander une CRO en premier à un fournisseur d'IA ?
Quel mécanisme indépendant contrôle la sortie avant qu'un humain la voie. S'il n'y en a pas, les autres questions n'ont plus d'objet.