Sujet 8.4 — Gouvernance de l'IA et des technologies émergentes

En une phrase : L'intelligence artificielle dans la santé et l'action sociale est une technologie apprenante, dépendante des données, et souvent opaque qui peut échelonner à la fois le bénéfice et le dommage plus rapidement que tout système que vous avez gouverné auparavant, donc vous devez la gouverner comme une question de sécurité clinique, d'équité, et de confiance publique tout au long de son cycle de vie complet — pas la traiter comme un logiciel ordinaire que vous achetez une fois et oubliez.

Pourquoi c'est important dans la santé et l'action sociale#

La plupart du logiciel que vous avez déployé se comporte de la même façon demain qu'aujourd'hui : sa logique est écrite, son comportement est testable, et quand il a tort, il a tendance à avoir tort d'une façon visible et répétable. L'intelligence artificielle brise ces trois conforts. Elle apprend des motifs statistiques à partir des données plutôt que de suivre des règles qu'une personne a écrites ; son comportement dépend entièrement des données sur lesquelles elle a été entraînée et des données qu'elle rencontre maintenant ; et son raisonnement est fréquemment opaque même pour les personnes qui l'ont construite. Cette combinaison est pourquoi l'IA a besoin de sa propre discipline de gouvernance plutôt que d'être repliée dans une liste de contrôle logicielle générique.

Dans la santé et l'action sociale, les conséquences ne sont pas abstraites. Un modèle qui sous-détecte une maladie chez un groupe sous-représenté dans ses données d'entraînement ne fait pas une erreur isolée — il fait la même erreur, silencieusement, des milliers de fois, ancrant et échelonnant les inégalités de santé. Un modèle génératif qui fabrique un détail clinique plausible peut induire en erreur un clinicien étiré exactement au mauvais moment. Un outil qui fonctionne magnifiquement dans la population sur laquelle il a été validé peut discrètement se dégrader quand la population, le parcours de soins, ou les données en amont changent. L'IA peut échelonner de bonnes décisions et elle peut échelonner le biais, l'erreur, et le dommage avec une égale efficacité.

Ce sujet concerne la gouvernance de ce risque sans ni respirer le battage médiatique ni interdire la technologie. Il ne répète délibérément pas les fondations posées ailleurs : la sécurité clinique (voir Sujet 1.6 — Sécurité clinique et gestion des risques), la gouvernance de l'information, la protection des données et la cybersécurité (voir Sujet 1.7 — Gouvernance de l'information, protection des données et cybersécurité), et la prise de décision pilotée par les preuves (voir Sujet 1.3 — Décisions fondées sur les preuves). Il s'ancre à eux, et ajoute ce qui est spécifique aux systèmes apprenants. Traitez-le comme l'extension façonnée par l'IA de votre assurance existante, et comme le frère gouverné de l'échelonnement de l'innovation (voir Sujet 8.0 — Échelonner l'innovation).

Concepts fondamentaux#

Intelligence artificielle et apprentissage automatique. Pour un dirigeant, la distinction pratique est celle-ci : la plupart de l'IA dans la santé et l'action sociale aujourd'hui est de l'apprentissage automatique — des systèmes qui infèrent des motifs à partir d'exemples plutôt que d'exécuter des règles écrites à la main. C'est pourquoi les données sont le produit autant que le code : changez les données d'entraînement et vous changez le comportement. Cela signifie aussi qu'un modèle ne « sait » rien ; il estime, et il peut avoir tort avec confiance. Comprendre cela à un niveau conceptuel suffit pour poser les bonnes questions de gouvernance ; vous n'avez pas besoin de lire les mathématiques.

Software as a Medical Device (SaMD) et la MHRA. Quand un logiciel a un but médical — diagnostiquer, dépister, trier, calculer une dose, prédire une détérioration — c'est très souvent un dispositif médical en droit, peu importe s'il fonctionne sur un téléphone ou un serveur. Le logiciel médical de ce type, connu comme Software as a Medical Device (SaMD), est réglementé au Royaume-Uni par la Medicines and Healthcare products Regulatory Agency (MHRA). Si vous commandez ou construisez un outil IA avec un but clinique, la première question de gouvernance est si c'est un dispositif réglementé et, si oui, s'il détient un marquage de conformité valide. Se tromper là-dessus n'est pas une technicité ; déployer un dispositif médical non enregistré est illégal et dangereux.

L'AI Airlock. La MHRA a établi un bac à sable réglementaire appelé l'AI Airlock pour travailler sur comment l'IA en tant que dispositif médical devrait être réglementée dans un cadre contrôlé et surveillé. Un bac à sable réglementaire laisse un régulateur et un petit nombre de développeurs examiner des questions difficiles et nouvelles — par exemple comment valider un modèle qui se met à jour dans le temps — sous supervision, avant que des règles générales ne soient fixées. Soyez sobre sur ce que c'est : l'Airlock est un environnement d'apprentissage pour le régulateur et une poignée de participants, pas une voie d'approbation accélérée, et être associé à lui ne signifie pas qu'un produit est approuvé pour l'usage clinique général.

Biais algorithmique et équité. Le biais algorithmique est la tendance d'un système à produire des résultats systématiquement injustes pour des groupes particuliers. Dans la santé et l'action sociale, sa source la plus courante est les données d'entraînement : si un groupe est sous-représenté, mal étiqueté, ou mesuré avec un instrument biaisé, le modèle apprend à mieux ou moins bien servir ce groupe. Parce que le modèle applique ensuite cela à l'échelle et avec un air d'objectivité, une IA biaisée peut élargir les inégalités mêmes que votre organisation est statutairement obligée de réduire.

Explicabilité et la boîte noire. L'intelligence artificielle explicable concerne si un humain peut comprendre pourquoi un modèle a produit une sortie donnée. De nombreux modèles hautement performants sont effectivement des « boîtes noires » : précis en agrégat mais incapables de donner à un clinicien une raison digne de confiance pour une décision individuelle. Dans un cadre clinique, cela compte pour la responsabilité, le consentement éclairé, et le devoir du clinicien d'exercer un jugement — un médecin ne peut pas de manière significative prendre la responsabilité d'un conseil qu'il ne peut pas interroger.

Dérive de modèle et surveillance post-commercialisation. La précision d'un modèle n'est pas fixe. La dérive de concept — un changement dans le temps de la relation entre les entrées et la chose prédite — signifie qu'un modèle validé l'année dernière peut se dégrader silencieusement cette année à mesure que les populations, parcours, ou données en amont changent. C'est pourquoi l'IA exige une surveillance post-commercialisation et une surveillance continues, pas seulement une validation ponctuelle à la mise en production.

MLOps et le cycle de vie du modèle. MLOps est la discipline opérationnelle consistant à déployer, surveiller, versionner, et réentraîner les modèles de manière fiable en production. C'est la machinerie qui rend la gouvernance de cycle de vie réelle : savoir quelle version de modèle est en direct, sur quelles données, avec quelle performance, et être capable de revenir en arrière.

Humain dans la boucle. Une conception à humain dans la boucle garde une personne — habituellement un clinicien — de manière significative dans la décision, avec l'autorité et l'information pour outrepasser le modèle. Bien faite, elle préserve la responsabilité ; faite comme un tampon d'approbation, elle ne fournit que l'illusion de surveillance.

IA générative et grands modèles de langage. L'intelligence artificielle générative, y compris les grands modèles de langage (LLM), produit du texte fluide et autre contenu. Sa valeur réaliste à court terme dans la santé et l'action sociale est largement administrative — rédiger de la documentation, résumer, faciliter la paperasse. Son risque déterminant est l'hallucination : la génération confiante de contenu faux mais plausible, aggravée par des risques de confidentialité quand les données patients sont entrées dans des services tiers.

Thérapeutiques numériques et applications de santé. Les thérapeutiques numériques (DTx) sont des interventions pilotées par logiciel et fondées sur les preuves qui préviennent, gèrent, ou traitent une condition — distinctes des applications de bien-être générales précisément parce qu'elles font une revendication clinique, ce qui signifie que beaucoup sont des Software as a Medical Device et exigent la même preuve et assurance que toute autre intervention que vous prescrivez ou recommandez.

Bonnes pratiques#

1. Classifiez l'outil avant de faire quoi que ce soit d'autre. Établissez, par écrit et avec une contribution clinique et réglementaire, si l'IA a un but médical et est donc un dispositif médical réglementé, et si elle détient un marquage de conformité MHRA valide. Cette détermination unique gouverne tout ce qui suit — la voie d'assurance, les responsabilités, la légalité du déploiement. En cas de doute, cherchez un conseil réglementaire plutôt que de supposer qu'un outil administratif est hors de portée.

2. Faites passer l'IA à travers votre machinerie existante de sécurité clinique et de gouvernance de l'information, étendue pas contournée. Chaque déploiement d'IA clinique a besoin de la gestion des risques cliniques DCB0129/DCB0160 (voir Sujet 1.6) et d'une évaluation d'impact sur la protection des données sous votre cadre de gouvernance de l'information (voir Sujet 1.7). Ne laissez pas la nouveauté ou l'enthousiasme du fournisseur créer un processus parallèle et plus léger. Les dangers spécifiques à l'IA — biais, dérive, opacité, biais d'automatisation — devraient être ajoutés au journal des dangers, pas le remplacer.

3. Interrogez les données d'entraînement pour la représentativité et le biais. Demandez qui est dans les données et qui manque, comment les résultats ont été étiquetés, et si les instruments de mesure eux-mêmes étaient biaisés à travers les groupes. Exigez que le fournisseur rapporte la performance décomposée par sous-groupes pertinents — âge, sexe, ethnicité, précarité — pas seulement la précision vedette. Un outil qui ne peut pas démontrer une performance équitable est un risque d'inégalité de santé peu importe combien sa moyenne est impressionnante.

4. Exigez une validation clinique appropriée au risque, et préférez la preuve prospective. La précision rétrospective sur des données organisées est la forme de preuve la plus faible. Pour tout ce qui influence les décisions cliniques, cherchez une validation dans une population et un flux de travail comme les vôtres, idéalement prospective, et acheminez la revendication via le cadre d'assurance approprié — le NICE Evidence Standards Framework pour les technologies de santé numérique et les Digital Technology Assessment Criteria (DTAC) comme assurance de base. Faites correspondre la force de la preuve à l'ampleur du dommage potentiel.

5. Insistez sur un humain-dans-la-boucle significatif et une responsabilité claire. Définissez qui est responsable d'une décision que l'IA a informée, et assurez-vous que l'humain a à la fois l'autorité d'outrepasser et l'information pour le faire. Gardez-vous activement contre le biais d'automatisation — la tendance à déférer à la machine — via la formation, la conception d'interface, et l'audit des taux d'outrepassement. Si les outrepassements ne se produisent jamais, votre « humain dans la boucle » est décoratif.

6. Traitez la mise en production comme le début de la surveillance, pas la fin de l'assurance. Mettez en place la surveillance post-commercialisation dès le premier jour : surveillez la performance en conditions réelles, guettez la dérive de concept, et définissez les seuils et le processus pour réentraîner, mettre en pause, ou retirer le modèle. Établissez le versionnage de modèle et le retour en arrière via un MLOps solide afin que vous sachiez toujours ce qui est en direct et puissiez revenir en arrière en toute sécurité. Un modèle jamais revérifié est un contrôle de sécurité qui échoue lentement.

7. Gouvernez l'IA générative selon ses usages réalistes et contre ses véritables risques. Permettez les LLM là où la valeur est véritable et le risque est contenu — rédaction administrative, résumé, support de documentation avec revue humaine — et interdisez l'entrée non gérée de données identifiables de patients dans des services tiers. Supposez que toute sortie générative peut être fabriquée jusqu'à ce qu'un humain la vérifie, et ne laissez jamais du contenu généré non vérifié entrer dans le dossier clinique. Une politique claire et appliquée bat à la fois une interdiction générale qui pousse vers l'usage fantôme et un laisser-faire qui fuit les données.

8. Appliquez la gouvernance de l'information à tout le cycle de vie des données, y compris l'entraînement. Les données utilisées pour entraîner, affiner, et évaluer un modèle sont soumises aux mêmes obligations de base légale, minimisation, et transparence que tout autre usage (voir Sujet 1.7). Soyez explicite sur la base de l'entraînement sur les données patients, si elle est adéquatement désidentifiée, et ce que le fournisseur peut en faire. Les contrats devraient interdire la réutilisation de vos données pour entraîner des produits pour d'autres sans base légale et votre accord.

9. Tenez un registre de modèles lisible par l'humain et exigez la transparence des fournisseurs. Maintenez un inventaire de l'IA en usage : but, statut réglementaire, provenance des données d'entraînement, preuve de validation, plan de surveillance, et propriétaire responsable. Exigez que les fournisseurs soient transparents sur comment un modèle fonctionne, ses limitations, et ses modes d'échec ; l'opacité d'un fournisseur est elle-même un signal de risque. Vous ne pouvez pas gouverner ce que vous n'avez pas écrit.

10. Scannez l'horizon délibérément et échelonnez via une évaluation contrôlée. Au-delà de l'IA d'aujourd'hui, surveillez les technologies émergentes — documentation ambiante, modèles de fondation, et plus loin, le quantique et les nouveaux capteurs — avec un balayage d'horizon structuré plutôt qu'un achat réactif. Introduisez tout ce qui est véritablement nouveau via l'approche contrôlée, réversible, et évaluée de l'échelonnement de l'innovation (voir Sujet 8.0), commençant petit, mesurant honnêtement, et retenant la capacité d'arrêter.

11. Traitez les thérapeutiques numériques et applications de santé comme des interventions, pas des téléchargements grand public. Quand une application fait une revendication clinique — traiter, gérer, ou prévenir une condition — c'est une intervention sur laquelle les patients agiront, et elle mérite le même examen minutieux qu'un médicament ou un dispositif avant que vous ne la prescriviez ou recommandiez. Établissez si elle est un Software as a Medical Device avec un marquage de conformité valide, exigez une preuve proportionnée à sa revendication, et complétez une évaluation de sécurité clinique (voir Sujet 1.6) plutôt que de faire confiance à une note de magasin d'applications ou l'enthousiasme d'un fournisseur. Une application non assurée qu'un clinicien approuve porte le nom de votre organisation et votre responsabilité si elle nuit.

12. Acheminez les applications de santé via l'assurance existante et maintenez une bibliothèque organisée et sûre. Évaluez les thérapeutiques numériques via la même machinerie que vous exécutez déjà — DTAC comme base, le NICE Evidence Standards Framework correspondant à la revendication clinique, et revue de sécurité clinique et de gouvernance de l'information — et construisez la preuve d'évaluation en conditions réelles dans le temps (voir Sujet 8.6). Maintenez une bibliothèque organisée d'applications que vous avez assurées et soutenez, avec le statut réglementaire, la preuve, et le propriétaire de chaque application enregistrés, afin que les cliniciens recommandent depuis une liste courte sûre et gouvernée. L'alternative — un étalement non contrôlé d'applications non évaluées recommandées informellement à travers les équipes — est ingérable et dangereux.

Questions à discuter avec votre équipe#

1. Pour chaque outil IA que nous considérons ou utilisons déjà, savons-nous réellement s'il est un dispositif médical réglementé — et pouvons-nous produire la preuve ? Cela ressemble à une formalité de conformité mais c'est la question porteuse de charge, car la réponse détermine ce qui est légal, qui est responsable, et quelle assurance vous devez au public. Il est facile de supposer qu'un outil qui « aide juste au triage » ou « résume juste les notes » est un logiciel administratif inoffensif quand son but médical en fait en réalité un dispositif réglementé exigeant un marquage de conformité MHRA. La discussion devrait vous forcer à nommer chaque outil IA en usage ou dans le pipeline, énoncer son but prévu en termes cliniques clairs, et identifier qui a fait l'appel de classification de dispositif et sur quelle base. Elle devrait faire surgir les cas inconfortables où un outil a été acheté via une voie informatique ordinaire sans aucune vérification réglementaire du tout. Soyez honnête sur si vous pourriez, aujourd'hui, produire la documentation de conformité et la preuve de validation si un régulateur ou un coroner demandait. La valeur de la conversation est qu'elle convertit un sens vague que « quelqu'un a dû vérifier » en une position documentée et possédée — et révèle les outils où personne ne l'a fait.

2. Avons-nous exigé de voir comment ce modèle performe pour les groupes les plus susceptibles d'être lésés, ou avons-nous accepté un chiffre de précision vedette ? La précision moyenne est le chiffre avec lequel les fournisseurs mènent et le chiffre qui cache le biais algorithmique, car un modèle peut être hautement précis globalement tout en performant nettement moins bien pour un groupe sous-représenté. Dans la santé et l'action sociale, ce n'est pas une curiosité statistique ; c'est un mécanisme pour élargir les inégalités que vous êtes légalement et moralement obligés de réduire, appliqué silencieusement et à l'échelle. L'équipe devrait discuter de quelle preuve de sous-groupe vous avez réellement vue — performance décomposée par âge, sexe, ethnicité, et précarité — et si vous savez qui était dans les données d'entraînement et qui manquait. Cela vaut la peine de nommer l'inconfort ici : presser un fournisseur sur l'équité peut sembler entraver une innovation excitante, et la question honnête est si vous êtes prêt à dire non à un outil qui ne peut pas démontrer une performance équitable. Considérez aussi comment vous détecteriez même des résultats inéquitables après le déploiement, car un biais invisible à l'achat sera invisible en production à moins que vous ne le surveilliez. Une bonne discussion se termine avec une barre probante concrète pour l'équité qui s'applique avant que toute IA clinique n'entre en production, et un plan pour continuer à surveiller ensuite.

3. Quand ce modèle a tort — et il l'aura — qui est responsable, un humain le rattrapera-t-il réellement, et comment le saurions-nous même ? Chaque modèle échoue parfois, et les systèmes apprenants peuvent dériver vers l'échec plus souvent dans le temps, donc la question mature n'est pas si des erreurs se produisent mais si vos garde-fous sont réels. L'équipe devrait tester si l'humain-dans-la-boucle est significatif ou décoratif : le clinicien a-t-il l'autorité et l'information pour outrepasser, et si vous regardiez les taux d'outrepassement, trouveriez-vous qu'il outrepasse réellement, ou le biais d'automatisation s'est-il installé ? Discutez de qui est nommé responsable d'une décision que l'IA a informée — le clinicien, l'organisation, le fournisseur — car « l'algorithme l'a fait » n'est pas une position défendable envers un patient ou un coroner. Confrontez votre surveillance honnêtement : avez-vous une surveillance post-commercialisation qui détecterait la dérive de concept, des seuils définis pour mettre en pause ou retirer le modèle, et la machinerie MLOps pour savoir quelle version est en direct et la faire revenir en arrière ? Pour les outils génératifs, ajoutez la question d'hallucination — qu'est-ce qui empêche le contenu fabriqué d'entrer dans le dossier clinique, et qui vérifie la sortie avant qu'elle ne soit fiée ? La version la plus utile de cette conversation expose l'écart entre le diagramme rassurant de « surveillance humaine » et ce qui arriverait véritablement à 3h du matin dans un service occupé.

4. Qu'arrive-t-il aux données de nos patients quand nous entraînons, affinons, et exécutons ces modèles — et qu'est-ce que le fournisseur s'est réservé le droit de faire avec elles ? L'IA concentre le risque de gouvernance des données précisément parce que les données sont le produit : un modèle n'est aussi digne de confiance que la base légale, la minimisation, et la transparence derrière chaque jeu de données qu'il a touché, y compris les données d'entraînement et d'évaluation qui précèdent la mise en production. L'équipe devrait pouvoir énoncer, pour chaque outil, la base légale pour tout usage de données patients, si la désidentification est adéquate plutôt que simplement affirmée, et où les données circulent physiquement une fois qu'elles quittent votre contrôle. Un piège récurrent est le contrat qui permet discrètement au fournisseur de réutiliser vos données pour améliorer des produits qu'il vendra à d'autres ; discutez de si vos accords interdisent cela sans base légale et votre consentement explicite, et si quelqu'un a réellement lu ces clauses. Ceci se connecte directement à votre cadre de gouvernance de l'information (voir Sujet 1.7), et c'est là où l'enthousiasme pour un outil capable dépasse le plus souvent la diligence raisonnable. Une réponse honnête nomme qui possède le DPIA, ce que le fournisseur peut et ne peut pas faire, et où vous êtes actuellement exposé — plutôt que de supposer que parce que la démo était impressionnante, la paperasse doit être solide.

5. Comment décidons-nous ce qu'il ne faut PAS adopter, et pouvons-nous résister à la pression d'acheter la chose dont tout le monde est excité ? La discipline de gouvernance la plus difficile avec une technologie qui bouge vite est de dire « pas encore » ou « pas ceci », et une équipe qui ne peut pas articuler ses critères pour décliner finira par adopter par dérive et battage médiatique plutôt que par preuve. Discutez de ce qui vous ferait vous éloigner d'un outil autrement attrayant — preuve de sous-groupe faible, statut réglementaire peu clair, cas d'usage où le bénéfice réaliste est mince relativement au risque — et si ces lignes rouges sont écrites ou simplement ressenties. Il y a une véritable tension ici entre le coût de manquer une véritable amélioration et le coût d'un échec échelonné qui endommage la confiance publique, et des personnes raisonnables les pèseront différemment. Cela vaut la peine de nommer la réalité politique que la pression d'adopter vient souvent d'un conseil d'administration, une relation fournisseur, ou un mandat national, pas du besoin clinique lui-même. La position du sujet est de balayer l'horizon délibérément et d'échelonner via une évaluation contrôlée et réversible (voir Sujet 8.0), donc une réponse honnête décrit comment un outil prometteur-mais-non-prouvé entre comme un pilote petit, mesuré, et arrêtable plutôt qu'un déploiement complet — et qui détient l'autorité de l'arrêter.

6. Pouvons-nous expliquer ce que fait ce modèle aux cliniciens qui doivent lui faire confiance et aux patients affectés par lui — et avons-nous été honnêtes sur ses limites ? Un modèle qu'un clinicien ne peut pas interroger et qu'un patient ne peut pas comprendre corrode le jugement éclairé et le consentement éclairé dont dépendent les soins cliniques, aussi précis soit-il en agrégat. L'équipe devrait discuter de combien d'explicabilité cet usage particulier exige réellement : une aide de priorisation de file d'attente en demande moins qu'un outil qui influence un diagnostic ou une décision de traitement, et faire correspondre l'explication aux enjeux est un choix de gouvernance, pas une réflexion après coup technique. Considérez ce que vous dites aux cliniciens censés l'utiliser — son but, ses modes d'échec connus, les groupes pour qui il est moins fiable — et si ce briefing est franc ou un résumé marketing. L'honnêteté destinée aux patients compte aussi : les gens sont-ils informés quand l'IA est impliquée dans leurs soins, et dans un langage sur lequel ils peuvent agir ? C'est aussi une question de main-d'œuvre, car une confiance trop faible signifie qu'un outil utile est ignoré tandis qu'une confiance trop élevée produit le biais d'automatisation qui vide la surveillance. Une réponse honnête confronte si votre formation et communication construisent une confiance calibrée ou vendent simplement l'outil.

En pratique : un exemple de santé et d'action sociale#

Un système de soins intégrés se voit offrir un outil IA qui lit les radiographies thoraciques et signale les anomalies probables pour prioriser la file d'attente de reporting radiologique. L'agent de sécurité clinique et le directeur médical résistent à la pression de l'acheter rapidement et le font plutôt passer par une gouvernance appropriée.

D'abord, la classification : l'outil a un but médical clair, donc il est confirmé comme Software as a Medical Device, et son marquage de conformité MHRA et son énoncé d'usage prévu sont vérifiés — l'usage prévu est le support de triage, pas le diagnostic autonome, ce qui façonne tout ce qui suit. Ensuite, l'assurance : l'outil est passé à travers DTAC comme base, ses revendications cliniques sont vérifiées contre le NICE Evidence Standards Framework, une évaluation de risque clinique DCB0160 est complétée, et un DPIA couvre les données d'imagerie (voir Sujets 1.6 et 1.7). L'équipe demande la performance de sous-groupe et découvre que la population de validation sous-représentait une démographie locale ; ils exigent une validation locale supplémentaire avant de procéder, traitant le biais potentiel comme un risque d'inégalité de santé plutôt qu'une note de bas de page.

Au déploiement, la conception garde un humain dans la boucle : chaque image est toujours rapportée par un radiologue, et l'IA ne fait que réordonner la file d'attente, donc un signal manqué ne peut pas à lui seul causer un diagnostic manqué. La surveillance post-commercialisation est mise en place dès le premier jour — surveillant les taux de détection, la discordance entre le modèle et les radiologues rapporteurs, et toute dérive au fur et à mesure que le matériel de scanner et le mix de cas changent — avec des seuils pré-convenus pour mettre en pause l'outil et un chemin de retour en arrière via le déploiement versionné du fournisseur. Séparément, quand un service demande à coller les historiques patients dans un LLM public pour rédiger des lettres de sortie, le même forum de gouvernance dit non à cette voie non gérée et commande à la place un outil approuvé et contenu avec vérification humaine. Un an plus tard, l'outil de priorisation de file d'attente a modestement amélioré le délai de reporting, sa surveillance a attrapé un épisode de dérive après une mise à niveau de scanner, et — de manière cruciale — l'organisation peut montrer exactement comment il est gouverné.

Angles sectoriels#

Startup#

Une startup de santé numérique est souvent l'IA, donc sa maturité de gouvernance est son accès au marché. Les fondateurs devraient traiter la classification réglementaire, la validation clinique, et la preuve de biais comme un travail de produit central, pas une taxe de conformité ajoutée avant une vente, car l'agent de sécurité clinique d'un acheteur demandera exactement cela et un « non » termine l'accord. S'engager tôt avec la MHRA — potentiellement via des mécanismes tels que l'AI Airlock pour des questions véritablement nouvelles — et concevoir pour DTAC et le NICE Evidence Standards Framework dès le début transforme l'assurance en avantage compétitif. Le risque de startup caractéristique est la surrevendication : un marketing qui dépasse la preuve, ou une démo de précision moyenne qui cache une performance de sous-groupe faible. Le fondateur discipliné construit la surveillance et la surveillance post-commercialisation dans le produit tôt, car un échec échelonné unique dans un site de référence est un événement existentiel pour une petite entreprise.

Petite entreprise#

Un prestataire établi de petite taille — un cabinet de médecins généralistes, une pharmacie communautaire, une maison de retraite, une clinique monosite — est habituellement un acheteur d'IA plutôt qu'un constructeur, pourtant il porte les mêmes devoirs qu'un grand trust sans aucun du personnel dédié de sécurité clinique, gouvernance de l'information, ou informatique pour les décharger. Le risque pratique est d'adopter un outil sur les assurances d'un fournisseur car il n'y a aucune capacité interne pour exiger la classification de dispositif, la preuve de sous-groupe, ou un DPIA, et personne pour remarquer quand un modèle dérive. Appuyez-vous fortement sur l'assurance que d'autres ont déjà faite : préférez les outils qui détiennent clairement un marquage de conformité MHRA et ont passé DTAC, achetez auprès de fournisseurs qui publient leur preuve, et recommandez des applications de santé seulement depuis une bibliothèque organisée que votre ICS ou un organisme national a assurée plutôt que d'évaluer chacune vous-même. Là où vous ne pouvez pas personnellement vérifier la sécurité d'un outil, c'est une raison de déférer à l'assurance partagée de votre système, pas de sauter la vérification. Tenir même un registre léger de quels outils IA vous utilisez, pour quoi, et qui les possède transforme un devoir ingérable en un proportionné.

Entreprise#

Un grand trust ou ICS a l'appareillage pour gouverner l'IA correctement et l'échelle qui rend le fait de se tromper sérieux. Son travail est d'étendre les fonctions existantes de sécurité clinique, gouvernance de l'information, et assurance pour couvrir l'IA — un registre de modèles, des barres d'équité de sous-groupe, une surveillance post-commercialisation, MLOps pour le versionnage et le retour en arrière — plutôt que de laisser l'IA arriver via des voies informatiques ou de recherche non examinées. Le véritable danger de l'entreprise est la fragmentation : des douzaines de pilotes, d'essais de scribe ambiant, et d'expériences LLM départementales proliférant sans inventaire central, aucun DPIA cohérent, et personne responsable quand un outil dérive. La fatigue de changement et la pression du fournisseur poussent vers une adoption rapide, donc le leadership doit tenir la ligne que la nouveauté ne gagne pas un processus plus léger. Bien fait, l'entreprise peut aussi générer la preuve de validation locale et prospective que les acteurs plus petits ne peuvent pas, et la partager à travers le système.

Gouvernement#

Les organismes gouvernementaux nationaux et locaux — la MHRA, NHS England, DHSC, NICE, les administrations décentralisées, et les autorités locales — fixent les conditions sous lesquelles tout le monde déploie l'IA. Leurs instruments sont la réglementation, les standards, les cadres d'assurance (DTAC, l'Evidence Standards Framework), les mécanismes de refuge sûr comme l'AI Airlock, et le financement et les directives qui pilotent l'adoption sûre à travers un système fédéré qu'ils ne gèrent pas directement en hiérarchie. La responsabilité s'étend aux ministres, au Parlement, et au public, donc un échec IA échelonné ou un biais démontrable dans un outil national est un événement de confiance publique avec une longue ombre. Le rôle propre du gouvernement est de rendre le chemin sûr le chemin facile — règles claires, assurance réutilisable, communication publique honnête sur ce que l'IA peut et ne peut pas faire — tout en résistant à la fois aux mandats pilotés par le battage médiatique et à l'interdiction réflexive. Se tromper sur l'équilibre dans une direction ou l'autre coûte des années de confiance.

Modes d'échec courants#

• Sauter la classification réglementaire. Déployer une IA clinique comme si c'était un logiciel ordinaire. Évitez-le en déterminant le statut de dispositif et le marquage de conformité en premier, avec une contribution réglementaire.
• Aveuglement à la précision vedette. Accepter un chiffre moyen qui cache une performance faible pour les groupes sous-représentés. Évitez-le en exigeant une preuve de sous-groupe avant la mise en production et en surveillant l'inéquité après.
• Valider une fois, oublier pour toujours. Traiter la mise en production comme la fin de l'assurance tandis que le modèle dérive silencieusement. Évitez-le en mettant en place une surveillance post-commercialisation avec des seuils et un retour en arrière.
• Surveillance humaine décorative. Un « humain dans la boucle » qui tamponne sous biais d'automatisation. Évitez-le en auditant les taux d'outrepassement et en concevant une véritable autorité d'intervenir.
• IA générative non gouvernée. Le personnel collant des données patients dans des LLM publics et faisant confiance à une sortie fabriquée. Évitez-le en ayant une politique claire plus un outil approuvé et contenu avec vérification humaine.
• Processus léger parallèle. Laisser l'IA contourner la sécurité clinique et la gouvernance de l'information parce que c'est de l'« innovation ». Évitez-le en étendant la machinerie DCB et DPIA existante à l'IA.
• Aucun inventaire. Personne ne sachant quels modèles sont en direct, sur quelles données, possédés par qui. Évitez-le en maintenant un registre de modèles.

Modèle de maturité#

Liste de contrôle#

• Le statut de dispositif médical de chaque outil IA et le marquage de conformité MHRA sont déterminés et documentés.
• L'IA clinique a passé DTAC, a été vérifiée contre le NICE Evidence Standards Framework, et a une évaluation de risque clinique DCB et un DPIA.
• La performance de sous-groupe (âge, sexe, ethnicité, précarité) a été vue et satisfait une barre d'équité convenue.
• La validation clinique correspond au niveau de risque et préfère la preuve prospective et locale.
• Un humain-dans-la-boucle significatif est conçu, avec l'autorité et l'information pour outrepasser.
• La responsabilité nommée pour les décisions informées par l'IA est écrite.
• La surveillance post-commercialisation, les seuils de dérive, et un plan de pause/retour en arrière sont en direct dès la mise en production.
• MLOps donne le versionnage de modèle et un retour en arrière sûr ; la version en direct est toujours connue.
• La politique d'IA générative permet des usages réalistes, interdit les données patients dans des services non gérés, et exige une vérification humaine.
• La gouvernance de l'information couvre les données d'entraînement, d'affinement, et d'évaluation, avec des limites contractuelles sur la réutilisation par le fournisseur.
• Un registre de modèles lisible par l'humain enregistre le but, la provenance, la preuve, la surveillance, et le propriétaire.
• Les technologies émergentes sont balayées à l'horizon et échelonnées via une évaluation contrôlée et réversible.

Sources clés#

• MHRA — Software and Artificial Intelligence (AI) as a Medical Device, and the AI Airlock regulatory sandbox (gov.uk).
• NICE — Evidence Standards Framework (ESF) for digital health technologies (nice.org.uk).
• NHS England — Digital Technology Assessment Criteria (DTAC) for baseline assurance of digital health technologies.
• NHS England / former NHSX — A Buyer's Guide to AI in Health and Care, and the AI Ethics Initiative.
• DCB0129 and DCB0160 — clinical risk management standards for health IT (see Sujet 1.6).
• MHRA / IMDRF — Software as a Medical Device (SaMD) framework and good machine learning practice.
• The King's Fund and the Health Foundation — analysis of AI, data, and inequalities in health and care.
• See also Sujet 1.3 — Evidence-Driven Decisions; Sujet 1.6 — Clinical Safety & Risk Management; Sujet 1.7 — Information Governance, Data Protection & Cyber Security; Sujet 8.0 — Phasing in Innovation.

Références#

1. Artificial intelligence — Wikipédia — https://en.wikipedia.org/wiki/Artificial_intelligence
2. Machine learning — Wikipédia — https://en.wikipedia.org/wiki/Machine_learning
3. Medical software (including Software as a Medical Device) — Wikipédia — https://en.wikipedia.org/wiki/Medical_software
4. Medicines and Healthcare products Regulatory Agency — Wikipédia — https://en.wikipedia.org/wiki/Medicines_and_Healthcare_products_Regulatory_Agency
5. Algorithmic bias — Wikipédia — https://en.wikipedia.org/wiki/Algorithmic_bias
6. Explainable artificial intelligence — Wikipédia — https://en.wikipedia.org/wiki/Explainable_artificial_intelligence
7. Concept drift — Wikipédia — https://en.wikipedia.org/wiki/Concept_drift
8. MLOps — Wikipédia — https://en.wikipedia.org/wiki/MLOps
9. Human-in-the-loop — Wikipédia — https://en.wikipedia.org/wiki/Human-in-the-loop
10. Generative artificial intelligence — Wikipédia — https://en.wikipedia.org/wiki/Generative_artificial_intelligence
11. Large language model — Wikipédia — https://en.wikipedia.org/wiki/Large_language_model
12. Hallucination (artificial intelligence) — Wikipédia — https://en.wikipedia.org/wiki/Hallucination_(artificial_intelligence)
13. Software and AI as a Medical Device — MHRA, GOV.UK — https://www.gov.uk/government/publications/software-and-artificial-intelligence-ai-as-a-medical-device
14. AI Airlock: the regulatory sandbox for AI as a Medical Device — MHRA, GOV.UK — https://www.gov.uk/government/collections/ai-airlock-the-regulatory-sandbox-for-aiamd
15. Evidence standards framework (ESF) for digital health technologies — NICE — https://www.nice.org.uk/about/what-we-do/digital-health/evidence-standards-framework-for-digital-health-technologies
16. Digital Technology Assessment Criteria (DTAC) — NHS England — https://transform.england.nhs.uk/key-tools-and-info/digital-technology-assessment-criteria-dtac/
17. A Buyer's Guide to AI in Health and Care — NHS Transformation Directorate — https://transform.england.nhs.uk/ai-lab/explore-all-resources/adopt-ai/a-buyers-guide-to-ai-in-health-and-care/
18. Software as a Medical Device (SaMD): Key Definitions — International Medical Device Regulators Forum (IMDRF) — https://www.imdrf.org/documents/software-medical-device-samd-key-definitions
19. Digital therapeutics — Wikipédia — https://en.wikipedia.org/wiki/Digital_therapeutics