Pourquoi une fonderie d'IA locale et quels changements GxP

Partie 1 sur 6. L'index de la série, avec des liens vers chaque partie au fur et à mesure de sa publication, est la partie 0 : Introduction et carte de la série. Cette série s'adresse aux personnes qui doivent défendre des capacités d'IA partagées dans une organisation réglementée des sciences de la vie : responsables de l'architecture, directeurs techniques et vice-présidents de l'ingénierie, ainsi que leurs partenaires en matière de qualité, de validation et de sécurité. Cela suppose que vous savez ce que sont un modèle de langage et un index vectoriel. Les termes de base sont définis dans le glossaire à la fin de la série. Le statut réglementaire est indiqué à compter de septembre 2026 et va changer. Ceci est un guide technique et non un conseil juridique.

Le problème que cette série résout

La plupart des éditeurs de logiciels des sciences de la vie démarrent l’IA de la même manière. Une équipe produit appelle un modèle hébergé. Un autre choisit un modèle différent. Un troisième construit son propre pipeline de récupération. Chaque équipe fait un choix local judicieux. L'organisation se retrouve avec un problème que personne n'a choisi.

Les symptômes sont prévisibles.

• Les documents sont copiés dans plusieurs index et les copies s'éloignent des versions approuvées dans le système de gestion documentaire.
• Les règles d'accès sont appliquées par certaines intégrations et pas par d'autres, de sorte que le même utilisateur obtient des réponses différentes à la question « puis-je voir ceci ?
• Les invites sont présentes dans le code, dans les feuilles de calcul et dans les historiques de discussion, et personne ne peut dire quelle invite a généré le résultat du mois dernier.
• Il n'y a pas de référence d'évaluation partagée, donc « le modèle s'est amélioré » et « le modèle s'est détérioré » sont des opinions et non des mesures.
• Chaque intégration conserve ses propres logs, dans son propre format, avec sa propre période de conservation, ou sans aucune.

Dans un environnement GxP, ce ne sont pas des désagréments techniques. Ce sont des conclusions d’inspection qui attendent d’être produites. Un inspecteur qui voit un résumé d’écart rédigé par l’IA posera une chaîne de questions. Quelle version de la procédure le système a-t-il lu ? Qui avait le droit de le voir ? Quel modèle et quelle invite ont produit le texte ? Qu’est-ce qui a changé depuis la validation du système ? Qui a examiné le résultat avant qu’il ne soit enregistré dans le dossier ? Une succession ad hoc ne peut pas répondre à ces questions de manière cohérente, et une réponse incohérente est pire que pas de réponse.

Les faits montrent que la voie ponctuelle est rarement payante, même en dehors du travail réglementé. Une étude du MIT de 2025 sur l'IA générative d'entreprise, basée sur une enquête auprès de 153 dirigeants, 52 entretiens avec des dirigeants et une analyse de plus de 300 déploiements publics, a révélé qu'environ 95 % des projets pilotes n'ont produit aucun impact mesurable en termes de profits et de pertes [16]. L'étude accuse un déficit d'apprentissage et une faible intégration dans les flux de travail réels, et non la qualité du modèle. Les gagnants étaient des systèmes de back-office étroits qui s'adaptaient à un processus existant, et les organisations qui s'associaient à des spécialistes réussissaient environ deux fois plus vite que celles qui construisaient seules [16]. Un rapport RAND de 2024 indique que, selon certaines estimations, plus de 80 % des projets d’IA échouent, soit deux fois plus que les autres projets informatiques. À partir de 65 entretiens avec des data scientists et des ingénieurs, il identifie cinq causes profondes : un problème mal compris, des données inadéquates, une poursuite de la technologie au lieu du résultat, un sous-investissement dans l'infrastructure de déploiement et des problèmes au-delà de ce que l'IA actuelle peut faire [17]. La plupart de ces causes sont organisationnelles, et une plateforme est une réponse organisationnelle.

Une fonderie d’IA locale est cette réponse. Il s'agit d'une plate-forme partagée et auto-hébergée qui fournit des modèles, la récupération, l'application des politiques, l'évaluation, l'audit et les opérations à chaque produit, tout en gardant isolés les données, les autorisations, les invites et les seuils de qualité de chaque produit. Les équipes produit utilisent une petite API stable. L’équipe de la plateforme est propriétaire des contrôles sur lesquels les inspecteurs poseront des questions.

La répartition des responsabilités est au cœur de l'idée.

Le mot « fonderie » est délibéré. Une fonderie ne décide pas de ce qui est coulé. Cela garantit que tout ce qui est coulé répond à une norme.

Que signifie « local » ici

« Local » a un sens précis dans cette série.

• Auto-hébergé. Les modèles, index, invites et journaux s'exécutent sur l'infrastructure contrôlée par l'organisation.
• Capable d'espace d'air. La plate-forme doit fonctionner sans connectivité sortante. Les poids des modèles, les conteneurs et les dépendances sont importés une seule fois et mis à jour via le contrôle des modifications.
• Souverain. Aucune invite, fragment de document ou sortie ne quitte la frontière à moins qu'une décision documentée ne le permette.

Pourquoi aller si loin ? Il y a quatre raisons, et une seule d’entre elles concerne la sortie des données du bâtiment.

État validé. Un système informatisé GxP est validé pour son utilisation prévue puis conservé dans cet état [2][10]. Un modèle hébergé qui change sous vos ordres, via une mise à jour de version silencieuse, rompt cet état sans aucune demande de modification de votre part. Une version de modèle épinglée localement ne change que lorsque vous le décidez, via le contrôle des modifications, avec des preuves.

Auditabilité. La partie 11 et l'annexe 11 prévoient que les pistes d'audit, le contrôle d'accès et la conservation des enregistrements sont sous votre contrôle [8][10]. Cela est bien plus facile à prouver lorsque les journaux, les invites et le texte récupéré sont stockés dans les systèmes que vous administrez.

Responsabilité des fournisseurs. Le projet d'annexe 22 stipule que la responsabilité de la production d'IA reste du ressort de l'entreprise réglementée, et l'annexe 11 prévoit une surveillance des fournisseurs et des prestataires de services [10]. Vous ne pouvez exercer cette surveillance que sur les composants que vous pouvez inspecter et épingler.

Prévisibilité des coûts. L'inférence facturée à l'utilisation est un coût variable lié à la manière dont les utilisateurs utilisent le système. Le matériel possédé ou loué avec une utilisation régulière est un coût connu. La sixième partie revient aux chiffres.

Des conceptions hybrides sont possibles et les régulateurs n’interdisent pas le cloud. Les directives d'assurance de la FDA couvrent explicitement les modèles cloud tels que les logiciels en tant que service, les plateformes en tant que service et les infrastructures en tant que service lorsqu'ils sont utilisés pour le travail de production ou de système qualité, et elles adaptent l'assurance à l'utilisation prévue et aux risques [3]. Le fait n’est pas que le cloud soit interdit. Le fait est qu’une charge de travail non réglementée, un environnement de développement ou une expérience de données synthétiques peuvent s’exécuter sur une capacité louée, tandis que tout ce qui touche aux données GxP ou aux décisions GxP s’exécute par défaut à l’intérieur des limites. Chaque exception est une décision enregistrée et non une commodité.

Trois tests séparent « local » de « installé localement ».

1. Le test sortant. Bloquez tout le trafic réseau sortant de la plateforme. Est-ce que toutes les fonctionnalités fonctionnent toujours ? Un outil qui appelle un point de terminaison hébergé pour les intégrations, la modération, les vérifications de licence ou la télémétrie échoue à ce test.
2. Le test de mise à jour. Pouvez-vous installer un nouveau modèle, conteneur ou dépendance à partir du média que vous avez introduit, via votre propre contrôle des modifications, sans que le serveur du fournisseur soit accessible ?
3. Le test de dépendance. Disposez-vous d'une nomenclature pour chaque modèle, conteneur et bibliothèque de la plate-forme, afin qu'un avis de vulnérabilité puisse être retracé jusqu'à ce que vous exécutez réellement ?

La partie 6 applique ces tests à des outils réels.

Quels changements « réglementés »

Réglementé ne signifie pas ajouter une liste de contrôle de conformité à la fin. Cela change le design. Le tableau mappe les cadres importants pour les organisations pharmaceutiques et de dispositifs médicaux en fonction de ce que chacun exige de la plateforme. Les paragraphes après le tableau expliquent ceux qui affectent le plus l'architecture.

GAMP 5 et le guide GAMP AI. GAMP 5 n'est pas une loi. Il s'agit de la méthode standard de l'industrie pour valider les systèmes informatisés en GxP, et les inspecteurs la connaissent bien. La deuxième édition, publiée en 2022, a ajouté une annexe sur l'IA et l'apprentissage automatique. En juillet 2025, l'ISPE a publié un guide d'IA autonome à utiliser en parallèle [1][2]. Le Guide de l'IA couvre le cycle de vie de l'IA, du concept au retrait, comprend des annexes sur la gestion des fournisseurs et la qualité dès la conception, intègre les enregistrements et les directives d'intégrité des données de l'ISPE, et prend explicitement en compte la norme ISO/IEC 42001 [1]. Son accent est le même que celui de la deuxième édition : la sécurité des patients, la qualité des produits, l'intégrité des données et la pensée critique au lieu de cocher des cases. Pour un architecte, le message pratique est simple. Les systèmes basés sur l'IA sont des systèmes validés, et le cycle de vie de validation doit couvrir les modèles et les données, pas seulement le code.

FDA Computer Software Assurance. En septembre 2025, la FDA a finalisé ses lignes directrices CSA pour les logiciels utilisés dans la production de dispositifs et les systèmes qualité, remplaçant la section 6 de ses lignes directrices sur la validation des logiciels de 2002 [3][4]. L’approche est basée sur les risques et la moins lourde. Vous identifiez l'utilisation prévue de chaque fonctionnalité logicielle, évaluez son risque pour la sécurité des patients et la qualité du produit et choisissez les activités d'assurance en proportion : tests scriptés lorsque le risque est élevé, tests non scriptés ou exploratoires lorsqu'il est plus faible, surveillance continue comme preuve continue et preuves du fournisseur lorsqu'elles existent [3]. Cela s’applique aussi bien aux logiciels sur site que dans le cloud, et ne s’applique pas aux logiciels qui sont eux-mêmes un dispositif médical [3]. Son champ d'application formel concerne les appareils, mais l'approche est également devenue le vocabulaire commun des équipes de qualité pharmaceutique, car GAMP 5 va déjà dans le même sens. La partie 4 construit l'approche de validation sur cette base.

Le projet de cadre de crédibilité de la FDA. Le projet de lignes directrices de la FDA de janvier 2025, toujours à l'état de projet en septembre 2026, propose un cadre en sept étapes pour établir la crédibilité d'un modèle d'IA pour un contexte d'utilisation spécifique [5]. Les étapes sont les suivantes : définir la question qui vous intéresse ; définir le contexte d'utilisation ; évaluer le risque du modèle en fonction de l'influence du modèle et des conséquences de la décision ; élaborer un plan pour établir la crédibilité ; exécuter le plan ; documenter les résultats et tout écart ; et déterminer si le modèle est adéquat au contexte d'utilisation [5]. Le projet concerne l’IA utilisée pour soutenir les décisions réglementaires concernant les médicaments et les produits biologiques, et non tous les outils commerciaux. Mais ses deux idées centrales, le contexte d’utilisation et le risque comme influence multipliée par la conséquence, constituent la manière la plus claire de raisonner sur toute fonctionnalité d’IA dans un produit réglementé. Cette série les utilise partout.

Les principes communs de la FDA et de l'EMA. En janvier 2026, les deux agences ont publié dix principes non contraignants de bonnes pratiques d'IA dans le développement de médicaments, en s'appuyant sur le document de réflexion de l'EMA de 2024 [6][15]. Ils couvrent les valeurs centrées sur l'humain, le respect des normes, une approche basée sur les risques, un contexte d'utilisation clair, la gouvernance des données, l'expertise multidisciplinaire, la gestion du cycle de vie, la transparence, la surveillance humaine et la coopération internationale [6]. Rien de tout cela n’est nouveau pour un praticien GAMP. Ce qui compte, c’est que les deux plus grands régulateurs disent désormais les mêmes choses dans un seul document.

Enregistrements et intégrité des données. 21 CFR Part 11 exige des pistes d'audit sécurisées, générées par ordinateur et horodatées qui enregistrent la date et l'heure des entrées et des actions de l'opérateur qui créent, modifient ou suppriment des enregistrements électroniques, conservées pendant au moins aussi longtemps que les enregistrements eux-mêmes [8]. Les directives d'intégrité des données de la FDA définissent ALCOA+ : les enregistrements doivent être attribuables, lisibles, contemporains, originaux et précis, mais également complets, cohérents, durables et disponibles [9]. Dans l'UE, l'annexe 11 définit des attentes similaires pour les systèmes informatisés, et le PIC/S PI 041 donne aux inspecteurs une vision commune de l'intégrité des données dans les environnements BPF et PIB [10][24]. Pour une plateforme d’IA, cela soulève une question que la plupart des équipes ne se sont pas posée. Lorsqu’un résultat de l’IA influence une décision GxP, le résultat lui-même constitue-t-il un record ? La réponse sûre est oui. La partie 2 conçoit cela.

Annexe 22, le projet qui compte le plus. En juillet 2025, la Commission européenne a ouvert une consultation sur un chapitre 4 révisé, une annexe 11 révisée et une nouvelle annexe 22 sur l'IA dans les BPF, préparées avec le groupe de travail des inspecteurs de l'EMA et du PIC/S [10]. La consultation s'est clôturée le 7 octobre 2025 avec environ 1 300 commentaires. En septembre 2026, les trois textes étaient encore des projets, le plan de travail de l'EMA vise un texte final pour fin 2026 et aucune date d'entrée en vigueur n'a été annoncée [10]. Le champ d'application du projet concerne l'IA dans les applications critiques BPF, c'est-à-dire celles ayant un impact direct sur la sécurité des patients, la qualité des produits ou l'intégrité des données. Sa déclaration centrale est que les modèles dynamiques, les modèles qui peuvent renvoyer des sorties différentes pour des entrées identiques, l'IA générative et les LLM ne doivent pas être utilisés dans ces applications critiques [10]. Pour les modèles statiques qu'il autorise, il attend une utilisation prévue définie, des données de validation qui représentent les conditions de fonctionnement réelles, une explicabilité, des seuils de confiance le cas échéant, une surveillance humaine, un contrôle des modifications et une surveillance continue des performances [10]. Il permet l'IA générative dans des utilisations non critiques, telles que la synthèse d'un rapport d'écart ou de procédures de recherche, lorsqu'une personne qualifiée examine le résultat et conserve une responsabilité documentée. Et il est explicite que la responsabilité incombe à l’entreprise réglementée et non au fournisseur. L'EMA a organisé un atelier les 30 juin et 1er juillet 2026 pour déterminer si les modèles adaptatifs et génératifs pouvaient être abordés dans le cadre de garanties basées sur les risques, mais le texte publié n'a pas changé [10]. Une plate-forme prudente traite désormais le projet comme un guide de conception. Si le texte final assouplit la règle, rien n’est perdu. Si ce n’est pas le cas, la plateforme est déjà alignée.

La loi de l'UE sur l'IA, telle que modifiée. La loi sur l'IA est entrée en vigueur en août 2024. En juillet 2026, le Digital Omnibus on AI l'a modifiée et modifié le calendrier [11][12]. Les obligations de transparence de l’article 50, telles que le fait d’informer les gens qu’elles interagissent avec l’IA et de marquer le contenu généré de manière lisible par machine, s’appliquent depuis le 2 août 2026, avec un délai de grâce jusqu’au 2 décembre 2026 pour les systèmes déjà sur le marché [12]. Les obligations à haut risque s'appliquent désormais à partir du 2 décembre 2027 pour les systèmes autonomes répertoriés à l'annexe III, et à partir du 2 août 2028 pour l'IA intégrée dans les produits couverts par la législation européenne sur les produits en vertu de l'annexe I, tels que les dispositifs médicaux [12]. Les systèmes mis sur le marché avant ces dates bénéficient d'une clause d'antériorité à moins qu'ils ne subissent une modification de conception significative, et le seuil de « significatif » n'est pas encore défini [12]. Pour un système qualité ou un assistant documentaire, les deux crochets plausibles à haut risque sont la gestion des travailleurs selon l'annexe III, par exemple si le système attribue des tâches ou surveille les performances, et le fait d'être un composant de sécurité d'un dispositif médical selon l'annexe I [11]. La plupart des assistants du système qualité ne présentent pas de risque élevé. Mais la classification doit être documentée, et les obligations d’alphabétisation en IA de l’article 4 et les obligations de transparence de l’article 50 s’appliquent indépendamment. La partie 5 travaille à travers la classification.

Confidentialité. La loi indienne sur la protection des données personnelles numériques de 2023 est devenue opérationnelle grâce aux règles DPDP notifiées en novembre 2025, avec des obligations introduites progressivement jusqu'en 2027 [13]. L’organisation qui décide de la finalité et des moyens du traitement est un fiduciaire des données, et cela inclut la formation ou le déploiement de l’IA sur les données personnelles. Le signalement des violations se déroule en deux étapes : informer sans délai le Comité de protection des données, puis déposer un rapport détaillé dans les 72 heures et informer les personnes concernées sans seuil de matérialité [13]. Les sanctions atteignent 250 crores ₹ pour les défaillances des mesures de sécurité raisonnables [13]. Les organisations opérant en Europe travaillent dans le cadre du RGPD, y compris ses règles sur les décisions automatisées et les analyses d'impact. La partie 5 couvre la confidentialité à l’intérieur de la plateforme.

Normes de gestion. La norme ISO/IEC 42001 :2023 définit un système de gestion de l'IA qui peut être certifié et qui s'intègre à la norme ISO/IEC 27001 [19]. Le cadre de gestion des risques de l'IA du NIST fournit un vocabulaire partagé de quatre fonctions : gouverner, cartographier, mesurer et gérer, et son profil d'IA générative 2024 ajoute des risques spécifiques aux systèmes génératifs, notamment la confabulation et l'intégrité de l'information [20][22]. Ce n’est pas non plus une exigence GxP. Les deux constituent un échafaudage utile pour la gouvernance de la partie 5.

Deux choses ressortent de tout cela.

Premièrement, les cadres s’accordent les uns avec les autres. Ils exigent tous une utilisation prévue définie, une assurance basée sur les risques, une responsabilité humaine, des preuves documentées et un contrôle du changement. Une plate-forme construite pour l’un d’eux constitue l’essentiel du chemin vers les autres.

Deuxièmement, la contrainte la plus dure reste le projet. C’est une raison pour le concevoir maintenant, pas une raison pour attendre. Le coût de l’intégration d’un examen humain et de preuves dans la plateforme est faible. Le coût de sa rénovation après une inspection ne l’est pas.

La conséquence qui façonne tout le reste

Assemblez les cadres et une règle suit. Chaque usage de l’IA doit être classé avant d’être construit, selon deux axes.

1. Impact GxP. Le résultat touche-t-il la qualité du produit, la sécurité des patients ou un dossier réglementé ? Critique ou non critique ?
2. Influence sur la décision. Le résultat éclaire-t-il une décision humaine ou prend-il la décision ? C'est la logique du cadre de crédibilité de la FDA, où le risque du modèle augmente avec l'influence du modèle et avec les conséquences d'une mauvaise décision [5]. C'est également la logique de l'ICH Q9(R1), qui lie la formalité de la gestion des risques à l'importance de la décision et met en garde contre la subjectivité dans l'évaluation des risques [14].

Ensemble, les deux axes forment quatre quadrants.

La plateforme se situe par défaut dans le quadrant supérieur gauche : aide à la décision, utilisation non critique, avec une personne nommée qui révise et signe. Tout le reste est une exception avec son propre cas de validation. Le quadrant inférieur droit n’est pas disponible pour les modèles génératifs jusqu’à ce que les régulateurs disent le contraire.

La FDA a déjà montré ce qui se passe sans cela. En avril 2026, elle a envoyé une lettre d'avertissement à un fabricant après qu'une inspection a révélé que l'entreprise avait eu recours à un agent d'IA pour rédiger des spécifications et des dossiers sans examen adéquat [7]. L'entreprise a déclaré aux enquêteurs qu'elle n'avait pas procédé à la validation du processus parce que l'agent ne lui avait jamais dit que la validation était requise. La lettre indique qu'une entreprise utilisant l'IA comme aide à la création de documents doit examiner l'exactitude et la conformité des documents générés, et elle cite 21 CFR 211.22(c), la règle qui rend l'unité qualité responsable des procédures et des spécifications, et 211.100 sur les contrôles de production écrits [7]. Le remède attendu par la FDA était simple : une personne autorisée doit examiner et effacer toute sortie d’un agent d’IA [7]. La MHRA britannique a fait valoir un point similaire en juin 2026 à propos des réponses assistées par l’IA aux résultats des inspections : elles doivent être exactes, examinées techniquement et approuvées par une personne responsable [23].

Cette lettre constitue le cahier des charges d’une plateforme d’IA réglementée. Le système peut rédiger. Une personne décide. Le dossier montre qui.

La classification détermine également la profondeur de la validation et le niveau d'examen. Sous CSA, une fonctionnalité d'aide à la décision non critique peut être assurée avec des tests et une surveillance non scriptés, tandis qu'une fonctionnalité critique nécessite des preuves scriptées par contexte d'utilisation [3]. Dans le cadre du cadre de crédibilité de la FDA, le plan de crédibilité grandit avec l'influence du modèle et les conséquences de la décision [5]. La partie 4 transforme cela en une procédure concrète.

Six principes de conception

Ces principes transparaissent dans chaque partie ultérieure. Chacun vient avec ce qu’il signifie en pratique, et ce qu’il empêche.

1. Souverain par défaut. Les données, les modèles et les journaux restent à l'intérieur des limites. En pratique : une liste approuvée de ce qui peut franchir la frontière, et rien d'autre. Cela évite toute divulgation accidentelle et rend possible la surveillance du fournisseur attendue par les annexes 11 et 22 [10].
2. Refus par défaut, appliqué avant la récupération. La plateforme sait qui demande et quels documents ils peuvent voir, et elle filtre avant qu'un texte n'atteigne un modèle. L’isolement au niveau du produit ne suffit pas. Deux utilisateurs du même produit peuvent avoir des droits différents sur le même document. En pratique : l'identité et les droits de l'appelant voyagent avec la requête, et le récupérateur les filtre avant le classement, jamais après la génération. Il empêche les chemins de fuite que l'OWASP répertorie comme divulgation d'informations sensibles et comme vecteurs et faiblesses d'intégration [21].
3. Les preuves d'abord. Chaque réponse cite le document source, la version et la section utilisée. Si les preuves sont minces, le système le dit au lieu de deviner. En pratique : les citations portent l’identité du document, sa version, sa date d’entrée en vigueur et sa section, et le système s’abstient en dessous d’un seuil de preuve. Il fournit le type de preuves demandées par le cadre de crédibilité de la FDA [5].
4. La responsabilité humaine dès la conception. Les résultats sont une aide à la décision. Une personne qualifiée examine tout ce qui alimente un enregistrement ou une décision GxP, et l'examen est en soi un enregistrement. En pratique : un niveau de révision par quadrant et un enregistrement capturé de qui a révisé quoi, quand. C’est la règle dans la lettre d’avertissement d’avril 2026 et dans le projet d’annexe 22 [7][10].
5. Validation basée sur les risques et contrôle des modifications. L'utilisation prévue est définie par fonctionnalité. Les modifications apportées à un modèle, une invite, un paramètre de récupération ou un modèle d'intégration sont des modifications contrôlées avec des preuves, et non des modifications de configuration. En pratique : une suite d’évaluation qui s’exécute à chaque modification et un registre qui enregistre exactement ce qui est déployé. Il s'aligne sur le CSA et le GAMP et protège les droits acquis en vertu de la loi sur l'IA en faisant du « changement important » une décision documentée plutôt qu'un accident [2][3][12].
6. Des enregistrements, pas des journaux. Les pistes d'audit répondent aux attentes du 21 CFR Part 11 et de l'Annexe 11 : sécurisées, horodatées, attribuables, inaltérables et conservées pendant toute la durée de vie de l'enregistrement [8][10]. En pratique : les événements d'audit sont écrits dans un magasin avec les mêmes contrôles que les autres enregistrements GxP, et leur conservation suit l'enregistrement auquel ils se rapportent.

Modèles et fournisseurs, en bref

Le modèle est la partie la moins stable de la plateforme. De nouvelles versions apparaissent tous les quelques mois, les licences changent et les fournisseurs abandonnent leurs modèles. Ainsi, la plate-forme ne doit dépendre d'aucun modèle en particulier, et la conception doit faire d'un échange de modèle un changement contrôlé et prouvé plutôt qu'une reconstruction. La partie 2 présente le modèle de routeur qui rend cela possible. Quatre points comptent au départ.

Les modèles ouverts et pris en charge par le fournisseur peuvent tous deux s'exécuter localement. Les modèles ouverts sont téléchargés et auto-hébergés. Les modèles pris en charge par le fournisseur sont fournis et pris en charge sous une licence commerciale, mais ils fonctionnent toujours sur votre matériel. La différence réside dans le support, l’indemnisation, l’emballage et le coût. Ce n'est pas la souveraineté. L’un ou l’autre chemin réussit le test sortant s’il est déployé correctement, et l’un ou l’autre échoue si les outils qui l’entourent téléphonent à la maison.

Les licences diffèrent et changent. Depuis septembre 2026, plusieurs familles de modèles solides utilisent des licences permissives. Les versions ouvertes de Qwen3 et d'IBM Granite 4 sont Apache 2.0, les versions DeepSeek utilisent le MIT et certains modèles Mistral sont Apache 2.0 tandis que d'autres ne le sont pas [18]. La licence communautaire Llama 4 est gratuite pour les moins de 700 millions d'utilisateurs actifs mensuels, mais comporte des règles de dénomination et d'attribution pour les modèles dérivés [18]. Certains fournisseurs utilisent des termes personnalisés plus restrictifs qu'Apache 2.0. Vérifiez la licence sur la carte modèle pour connaître la version exacte que vous déployez et enregistrez-la dans le registre des modèles décrit dans la partie 5. Il en va de même pour l'intégration et le reclassement des modèles, qui sont souvent oubliés. Ils ont également des licences et des versions, et une modification du modèle d'intégration invalide chaque vecteur construit avec l'ancien.

Vous ne pouvez pas vérifier entièrement les données de formation, alors qualifiez plutôt le fournisseur. Les cartes modèles varient considérablement dans ce qu'elles divulguent sur les données de formation et les seuils de connaissances. Il n’existe aucun moyen pratique d’auditer un corpus de formation de l’extérieur. Deux leviers aident. La loi de l’UE sur l’IA exige que les fournisseurs de modèles d’IA à usage général conservent une documentation technique, y compris un résumé du contenu utilisé pour la formation [11]. Et le guide GAMP AI comprend une annexe sur la gestion des fournisseurs, tandis que le projet d'annexe 22 indique explicitement que la responsabilité incombe à l'entreprise réglementée et non au fournisseur [1][10]. La réponse pratique est un dossier de qualification fournisseur pour chaque modèle. Il doit contenir la licence et l'identifiant de version, le résumé documenté des données de formation, les preuves d'évaluation et de biais publiées, les limitations connues, la posture de sécurité du conteneur de service, les engagements du fournisseur en matière de version et de notification de modification, les conditions d'assistance et d'indemnisation le cas échéant, et vos propres résultats d'évaluation. Les directives d'assurance de la FDA permettent aux preuves fournies par les fournisseurs de réduire vos propres tests, mais seulement si vous détenez ces preuves et pouvez les démontrer [3].

Traitez le modèle comme n'importe quel autre composant qualifié. Un système validé ne modifie pas son moteur de base de données sans demande de modification. Il ne devrait pas non plus changer son modèle de langage sans en avoir un. Cela signifie que le registre enregistre le modèle, sa version, sa licence, ses résultats d'évaluation et les produits qui l'utilisent, et qu'un échange passe par la même porte que toute autre modification contrôlée.

La suite

Toutes les parties sont liées à partir de l'index des séries dans la partie 0. La partie 2 donne l'architecture de référence : le plan de contrôle, les huit couches d'exécution et le chemin de requête qui transporte l'identité et l'autorisation jusqu'à la récupération avant qu'un texte n'atteigne un modèle. La partie 3 traite les documents comme des données gouvernées. La partie 4 répond à la question que tout responsable qualité se pose en premier : comment valider un système qui n’est pas déterministe ? La partie 5 couvre la sécurité, la confidentialité et la gouvernance. La partie 6 couvre l'hébergement, les coûts, les opérations, l'équipe et une liste de contrôle de préparation à la production.

Sources pour la partie 1

Les liens marqués (confirmer) n'ont pas été revérifiés pour ce projet et doivent être vérifiés avant la publication.

1. ISPE. Guide ISPE GAMP : Intelligence artificielle. Juillet 2025. Final. https://ispe.org/publications/guidance-documents/gamp-guide-artificial-intelligence
2. ISPE. ISPE GAMP 5 : Une approche basée sur les risques pour des systèmes informatisés conformes à GxP, deuxième édition. 2022. Final. https://ispe.org/topics/gamp
3. FDA. Assurance logicielle informatique pour les logiciels de système de production et de qualité. Guide destiné à l'industrie et au personnel de la FDA. Septembre 2025. Final. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/computer-software-assurance-production-and-quality-system-software
4. Registre fédéral. Avis de disponibilité des orientations du CSA. 24 septembre 2025. https://www.federalregister.gov/documents/2025/09/24/2025-18468/computer-software-assurance-for-production-and-quality-system-software-guidance-for-industry-and
5. FDA. Considérations sur l'utilisation de l'intelligence artificielle pour soutenir la prise de décision réglementaire concernant les médicaments et les produits biologiques. Projet de lignes directrices, janvier 2025. Projet, non destiné à être mis en œuvre, à compter de septembre 2026. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/considerations-use-artificial-intelligence-support-regulatory-decision-making-drug-and-biological
6. FDA et EMA. Principes directeurs des bonnes pratiques d’IA dans le développement de médicaments. Janvier 2026. Non contraignant. https://www.fda.gov/media/189581/download
7. FDA. Lettre d'avertissement, référence 722591, datée du 2 avril 2026, citant 21 CFR 211.22(c) et 211.100. Base de données des lettres d'avertissement de la FDA. https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/compliance-actions-and-activities/warning-letters (lien direct vers la lettre : confirmer)
8. 21 CFR Partie 11, Dossiers électroniques ; Signatures électroniques, section 11.10(e). eCFR. https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11
9. FDA. Intégrité des données et conformité aux CGMP sur les médicaments : questions et réponses. Guide, décembre 2018. Final. (confirmer)
10. Commission européenne. Consultation des parties prenantes sur EudraLex Volume 4 : chapitre 4 révisé, annexe 11 révisée et nouvelle annexe 22, Intelligence artificielle. Consultation du 7 juillet au 7 octobre 2025. Projet, non adopté, en septembre 2026. (page de consultation : confirmer)
11. Règlement (UE) 2024/1689, loi sur l'intelligence artificielle. EUR-Lex. https://eur-lex.europa.eu/eli/reg/2024/1689/oj
12. Règlement (UE) 2026/1744, Omnibus numérique sur l’IA. Publié le 24 juillet 2026, en vigueur le 27 juillet 2026. EUR-Lex. https://eur-lex.europa.eu/eli/reg/2026/1744/oj
13. Ministère de l'électronique et des technologies de l'information, Inde. Loi sur la protection des données personnelles numériques, 2023, et Règles sur la protection des données personnelles numériques, 2025, G.S.R. 846(E), 13 novembre 2025, Gazette du 14 novembre 2025. (Lien Gazette : confirmer)
14. PCI. Q9(R1) Gestion des risques liés à la qualité. Étape 4, janvier 2023. https://database.ich.org/sites/default/files/ICH_Q9(R1)_Guideline_Step4_2022_1219.pdf
15. EMA. Document de réflexion sur l'utilisation de l'intelligence artificielle dans le cycle de vie des médicaments, EMA/CHMP/CVMP/83833/2023. Adopté en septembre 2024. https://www.ema.europa.eu/en/use-artificial-intelligence-ai-medicinal-product-lifecycle-scientific-guideline
16. MIT NANDA. The GenAI Divide : State of AI in Business 2025. Juillet 2025. (lien du rapport : confirmer)
17. Société RAND. Ryseff, De Bruhl, Newberry. Les causes profondes de l'échec des projets d'intelligence artificielle et comment ils peuvent réussir. 2024. RRA2680-1. https://www.rand.org/pubs/research_reports/RRA2680-1.html (confirmer)
18. Modèles de licences : Meta Llama 4 Commu

licence de ville ; Cartes modèles Qwen3 ; Cartes modèles IBM Granite 4 ; Cartes modèles DeepSeek ; Cartes modèles Mistral. Les termes de la licence sont indiqués sur chaque carte modèle et varient selon la version. (liens : confirmer à la publication pour les versions exactes déployées) 19. ISO. ISO/IEC 42001:2023, Système de management de l'intelligence artificielle. Décembre 2023. https://www.iso.org/standard/42001 20. NIST. Cadre de gestion des risques liés à l'intelligence artificielle (AI RMF 1.0), NIST AI 100-1. Janvier 2023. https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf (confirmer) 21. Projet de sécurité OWASP GenAI. OWASP Top 10 pour les candidatures LLM 2025. https://owasp.org/www-project-top-10-for-large-lingual-model-applications/assets/PDF/OWASP-Top-10-for-LLMs-v2025.pdf 22. NIST. Cadre de gestion des risques liés à l'intelligence artificielle : profil d'intelligence artificielle générative, NIST AI 600-1. Juillet 2024. https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf (confirmer) 23. Inspection de la MHRA. Article de blog sur l'utilisation de l'IA en réponse aux résultats des inspections GxP. 29 juin 2026. (confirmer) 24. PIC/S. PI 041-1, Bonnes pratiques pour la gestion et l'intégrité des données dans les environnements réglementés BPF/GDP. En vigueur le 1er juillet 2021. https://picscheme.org (lien du document : confirmer)firmer)