L’Annexe 22 ne fait pas encore partie des BPF de l’UE dans leur version définitive. L’actuelle Annexe 11 reste la référence applicable. Voici un cadre pratique pour préparer les cas d’usage de l’intelligence artificielle dans la fabrication pharmaceutique.
L’Annexe 22 ne fait pas actuellement partie des BPF de l’UE
Le premier point de décision est simple : l’Annexe 22 ne doit pas être traitée comme un texte déjà en vigueur.
Statut vérifié le 26 juillet 2026. Le texte publié reste le projet soumis à consultation en juillet 2025. Il ne s’agit pas d’une annexe opérationnelle des BPF de l’UE.
Il serait donc inexact d’affirmer que les BPF de l’UE autorisent, exigent ou ont déjà accepté une approche de validation particulière pour l’IA adaptative, probabiliste ou générative dans les applications BPF critiques.
Attendre passivement serait également une mauvaise réponse. L’atelier de l’EMA de juin–juillet 2026 a recueilli l’avis d’experts sur la possibilité et la manière d’aborder l’IA adaptative, probabiliste et générative dans de futures lignes directrices. Les questions soulevées concernaient notamment la validation, les garde-fous, la supervision humaine, la dérive, la cybersécurité et les services externalisés ou fondés sur le cloud.
Si de futures lignes directrices définissent une voie, quelles preuves, limites et mesures de maîtrise du cycle de vie votre site devra-t-il présenter pour démontrer qu’un système d’IA est compris et maîtrisé ?
La référence BPF actuelle reste l’Annexe 11
Pour les BPF européennes applicables aux médicaments à usage humain, la référence actuelle concernant les systèmes informatisés utilisés dans les activités réglementées par les BPF reste l’Annexe 11, complétée, le cas échéant, par l’Annexe 15, le Chapitre 1 et le Chapitre 7.
Selon l’Annexe 11, l’application doit être validée et l’infrastructure informatique qualifiée. L’étendue de la validation et des mesures de maîtrise de l’intégrité des données doit découler d’une analyse de risques justifiée et documentée prenant en compte la sécurité des patients, l’intégrité des données et la qualité du produit.
Les attentes sur l’ensemble du cycle de vie comprennent également la gestion maîtrisée des changements, l’évaluation périodique, la gestion des incidents, la sécurité, la conservation des données et, le cas échéant, les pistes d’audit et la continuité d’activité. L’étiquette « IA » ne soustrait pas un système à ce cycle de vie. Les éléments déterminants sont son usage prévu et son impact BPF.
Ce que proposait le projet d’Annexe 22 — et ce qu’il n’a pas instauré
Le projet soumis à consultation en juillet 2025 proposait des orientations supplémentaires propres à l’IA entraînée sur des données ou aux modèles de machine learning intégrés dans des systèmes informatisés lorsque leur utilisation affecte directement la sécurité des patients, la qualité du produit ou l’intégrité des données.
Ces propositions portaient notamment sur l’usage prévu, l’espace d’échantillonnage des données d’entrée, les données de test indépendantes, les critères de performance prédéfinis, l’explicabilité lorsqu’elle est applicable, les seuils de confiance, la gestion des changements et la surveillance continue.
Le projet proposait également de ne pas utiliser, dans les applications BPF critiques, les modèles dynamiques ou adaptatifs, les modèles à sortie probabiliste, l’IA générative et les grands modèles de langage. Il s’agit de positions figurant dans un projet et non d’interdictions opérationnelles actuellement en vigueur. L’atelier de 2026 ne les a pas remplacées et n’a pas créé de voie d’autorisation ; il a recueilli des éléments destinés à d’éventuelles orientations futures.
Une démarche pratique de préparation selon l’actuelle Annexe 11
Un score moyen élevé du modèle ne suffit pas pour l’aide à la décision BPF. Le site doit définir la décision à laquelle le modèle contribue, comprendre les conditions dans lesquelles il peut ne pas être fiable et déterminer la réponse du processus lorsque ces conditions se présentent.
1. Définir l’usage prévu et la limite des droits de décision
Décrivez précisément les données d’entrée, la sortie, l’utilisateur, l’étape du processus et la personne responsable de la décision. Indiquez également ce que le système ne fait pas.
« Aide aux décisions qualité » est trop large. Une limite plus précise pourrait indiquer qu’un modèle hiérarchise les enregistrements de surveillance environnementale pour leur examen par un analyste, mais qu’il ne détermine pas les excursions, n’approuve pas les investigations, ne décide pas du devenir du produit et ne libère pas les lots.
2. Évaluer le risque BPF et la réponse aux défaillances
Appliquez l’approche actuelle fondée sur les risques pour identifier les conditions de défaillance prévisibles, notamment une sortie incorrecte, un faible niveau de confiance, une entrée inadaptée, une indisponibilité ou un changement non évalué.
Pour chaque condition significative, définissez la détection, l’escalade, la solution de repli et la réévaluation, proportionnellement à l’impact potentiel sur la sécurité des patients, la qualité du produit et l’intégrité des données.
3. Définir les limites des données et utiliser des tests indépendants
Documentez la nature, la source, la qualité et les limites des données que le modèle est autorisé à recevoir : son espace d’échantillonnage d’entrée approuvé.
Séparez les données de développement des données de test indépendantes et représentatives. Consignez les situations hors limites approuvées et la conduite que le processus doit adopter lorsqu’elles surviennent.
4. Prédéfinir les critères de performance et d’incertitude
Définissez des mesures de performance adaptées au cas d’usage et des critères d’acceptation minimaux avant l’évaluation.
Pour les sorties probabilistes, ne vous fiez pas uniquement à une moyenne globale. Examinez les sous-groupes et les types d’erreurs pertinents, puis définissez la réponse opérationnelle à l’incertitude : signalement, escalade, suppression de la recommandation, abstention ou poursuite uniquement dans le cadre d’un examen humain défini.
5. Faire de l’examen humain une véritable mesure de maîtrise
La supervision humaine est une mesure de maîtrise, et non un substitut à une conception maîtrisée, aux tests ou à la gestion du cycle de vie.
Définissez qui effectue l’examen, quelles informations cette personne voit, quand une escalade est nécessaire, ce qu’elle peut modifier et comment la décision BPF finale est enregistrée. Le simple fait de placer une personne après le modèle ne constitue pas automatiquement une mesure de maîtrise efficace.
6. Maîtriser la surveillance, les changements et les fournisseurs
Les tests initiaux ne mettent pas fin à la stratégie de maîtrise. Identifiez les événements qui déclenchent une évaluation, tels qu’un changement de la chaîne de données, une modification de la population d’entrée, une mise à jour du modèle par le fournisseur, un réentraînement, une dérive significative des performances, des sorties récurrentes à faible niveau de confiance, un incident de sécurité ou une modification du processus d’examen humain.
Lorsqu’un fournisseur, un prestataire cloud ou un fournisseur externe de garde-fous intervient, des accords formels avec les tiers doivent être en place. La documentation du fournisseur peut contribuer à l’évaluation, mais elle ne transfère pas la responsabilité BPF.
Checklist synthétique de préparation à l’IA
| Domaine | Éléments à documenter dès maintenant |
|---|---|
| Usage prévu | Décision soutenue, étape du processus, utilisateur et décideur humain responsable. |
| Limite décisionnelle | Ce que le modèle fait et ce qu’il ne fait explicitement pas. |
| Risque BPF | Impact sur la sécurité des patients, la qualité du produit et l’intégrité des données. |
| Limites des entrées | Espace d’échantillonnage approuvé, sources des données et situations hors limites. |
| Tests | Justification des données de test indépendantes et critères de performance adaptés au cas. |
| Maîtrise de l’incertitude | Règle de confiance ou d’abstention, circuit d’escalade et solution manuelle de repli. |
| Supervision humaine | Rôle de l’examinateur, règles d’override et conception de l’enregistrement BPF final. |
| Déclencheurs du cycle de vie | Changements, dérive, réentraînement, indisponibilités, désaccords et événements de réévaluation. |
| Tiers | Dépendances fournisseurs et cloud, accords et plan de supervision. |
Une erreur fréquente à éviter
« Une personne examine la sortie » ne suffit pas à elle seule.
Cette affirmation ne précise pas quelles sorties nécessitent un examen, ce que l’examinateur doit évaluer, comment l’incertitude est présentée, ce qui se passe lorsque le modèle et l’examinateur sont en désaccord, ni comment la décision finale est enregistrée.
Action du lundi : cartographier un cas d’usage de l’IA
Consignez la décision que le système soutient ou automatise, son impact direct sur la sécurité des patients, la qualité du produit et l’intégrité des données, ainsi que le décideur humain responsable.
- Distinguez l’usage prévu des caractéristiques du modèle.
- Consignez l’espace d’échantillonnage d’entrée approuvé et la règle de gestion de l’incertitude.
- Définissez la solution manuelle de repli, les enregistrements d’audit et les déclencheurs de réévaluation.
FAQ
L’Annexe 22 fait-elle actuellement partie des BPF de l’UE ?
Non. Au 26 juillet 2026, le texte publié reste un projet soumis à consultation et ne constitue pas une annexe opérationnelle des BPF de l’UE.
Quelles exigences s’appliquent aujourd’hui à l’IA utilisée dans les activités BPF ?
Les mesures actuelles de maîtrise des systèmes informatisés restent fondées sur l’Annexe 11, complétée, le cas échéant, par l’Annexe 15, le Chapitre 1 et le Chapitre 7.
Les sites doivent-ils attendre la version définitive de l’Annexe 22 ?
Non. Les sites peuvent déjà documenter l’usage prévu, les limites décisionnelles, le risque BPF, les limites des données, les tests, la maîtrise de l’incertitude, la responsabilité humaine et les déclencheurs de réévaluation du cycle de vie.
L’examen humain rend-il un système d’IA conforme ?
Pas à lui seul. L’examen humain doit être une mesure de maîtrise conçue, assortie d’exigences définies concernant les informations, l’autorité, l’escalade, l’override et l’enregistrement.
Sources officielles
- EMA multistakeholder workshop on Annex 22 guidance development
- European Commission consultation on Chapter 4, Annex 11 and new Annex 22
- EudraLex Volume 4
Besoin d’une base de validation plus solide selon l’Annexe 11 ?
L’Operational Guide to Computer System Validation (CSV) in the GxP Environment fournit une base pratique pour le cycle de vie de la validation des systèmes informatisés, la définition des preuves et la préparation aux audits.
