Onderwerp 8.4 — Bestuur van AI en opkomende technologie

In één zin: Kunstmatige intelligentie in gezondheid en zorg is een lerende, van data afhankelijke en vaak ondoorzichtige technologie die zowel baat als schade sneller kan opschalen dan enig systeem dat u ooit bestuurde, dus u moet haar over haar hele levenscyclus besturen als kwestie van klinische veiligheid, billijkheid en publiek vertrouwen — en haar niet behandelen als gewone software die u eenmaal koopt en vergeet.

Waarom dit ertoe doet in gezondheid en zorg#

De meeste software die u hebt ingezet gedraagt zich morgen zoals vandaag: haar logica is opgeschreven, haar gedrag is testbaar en wanneer zij fout is, is zij gewoonlijk fout op een zichtbare, herhaalbare manier. Kunstmatige intelligentie breekt alle drie deze gemakken. Zij leert statistische patronen uit data in plaats van regels te volgen die een mens schreef; haar gedrag hangt geheel af van de data waarop zij werd getraind en de data die zij nu tegenkomt; en haar redeneren is vaak ondoorzichtig, zelfs voor degenen die haar bouwden. Die combinatie is waarom AI een eigen bestuurlijke discipline nodig heeft in plaats van in een generieke checklist voor software te worden gestopt.

In gezondheid en zorg zijn de gevolgen niet abstract. Een model dat ziekte onderdetecteert bij een groep die ondervertegenwoordigd was in de trainingsdata maakt geen losse fout — het maakt dezelfde fout, stilletjes, duizenden keren, en verankert en schaalt zo gezondheidsongelijkheid op. Een generatief model dat een aannemelijk klinkend klinisch detail verzint kan een uitgerekte clinicus op precies het verkeerde moment misleiden. Een instrument dat prachtig werkt in de populatie waarop het werd gevalideerd kan stilletjes verslechteren wanneer de populatie, het zorgtraject of de upstream data veranderen. AI kan goede beslissingen opschalen en kan vooroordelen, fouten en schade even efficiënt opschalen.

Dit onderwerp gaat over het besturen van dat risico zonder de hype te ademen of de technologie te verbieden. Het herhaalt bewust niet de fundamenten die elders zijn gelegd: klinische veiligheid (zie Onderwerp 1.6 — Klinische veiligheid en risicobeheer), informatiebestuur, gegevensbescherming en cyberbeveiliging (zie Onderwerp 1.7 — Informatiebeheer, gegevensbescherming en cyberbeveiliging) en op bewijs gebaseerde besluitvorming (zie Onderwerp 1.3 — Op bewijs gebaseerde besluitvorming). Het verankert zich daarin en voegt toe wat specifiek is voor lerende systemen. Behandel het als de AI-vormige uitbreiding van uw bestaande borging en als het bestuurde zusje van innovatie gefaseerd invoeren (zie Onderwerp 8.0 — Innovatie gefaseerd invoeren).

Kernbegrippen#

Kunstmatige intelligentie en machine learning. Voor een leider is het praktische onderscheid dit: de meeste AI in gezondheid en zorg is vandaag machine learning — systemen die patronen afleiden uit voorbeelden in plaats van met de hand geschreven regels uit te voeren. Daarom zijn de data evenzeer het product als de code: verander de trainingsdata en u verandert het gedrag. Het betekent ook dat een model niets “weet”; het schat, en het kan met zelfvertrouwen fout zijn. Dit op conceptueel niveau begrijpen volstaat om de juiste bestuurlijke vragen te stellen; u hoeft de wiskunde niet te lezen.

Software as a Medical Device (SaMD) en de MHRA. Wanneer software een medisch doel heeft — diagnosticeren, screenen, triëren, een dosis berekenen, verslechtering voorspellen — is zij heel vaak wettelijk een medisch hulpmiddel, ongeacht of zij op een telefoon of een server draait. Medische software van dit soort, bekend als Software as a Medical Device (SaMD), wordt in het Verenigd Koninkrijk gereguleerd door de Medicines and Healthcare products Regulatory Agency (MHRA). Als u een AI-instrument met een klinisch doel in opdracht geeft of bouwt, is de eerste bestuurlijke vraag of het een gereguleerd hulpmiddel is en, zo ja, of het geldige conformiteitsmarkering heeft. Dit verkeerd doen is geen technisch detail; een niet-geregistreerd medisch hulpmiddel inzetten is onrechtmatig en onveilig.

De AI Airlock. De MHRA heeft een regelgevende sandbox opgezet, de AI Airlock genoemd, om in een gecontroleerde, gemonitorde setting uit te werken hoe AI als medisch hulpmiddel moet worden gereguleerd. Een regelgevende sandbox laat een toezichthouder en een klein aantal ontwikkelaars harde, nieuwe vragen onderzoeken — bijvoorbeeld hoe een model te valideren dat in de tijd wordt bijgewerkt — onder toezicht, voordat algemene regels worden vastgesteld. Wees nuchter over wat dit is: de Airlock is een leeromgeving voor de toezichthouder en een handvol deelnemers, geen snelle goedkeuringsroute, en erbij betrokken zijn betekent niet dat een product is goedgekeurd voor algemeen klinisch gebruik.

Algoritmische vooringenomenheid en eerlijkheid. Algoritmische vooringenomenheid is de neiging van een systeem om systematisch oneerlijke uitkomsten voor bepaalde groepen voort te brengen. In gezondheid en zorg is de meest gangbare bron de trainingsdata: als een groep ondervertegenwoordigd is, verkeerd gelabeld of gemeten met een bevooroordeeld instrument, leert het model die groep slechter te bedienen. Omdat het model dit dan op schaal en met een air van objectiviteit toepast, kan bevooroordeelde AI juist de ongelijkheden vergroten die uw organisatie wettelijk moet verkleinen.

Verklaarbaarheid en de black box. Verklaarbare kunstmatige intelligentie gaat over of een mens kan begrijpen waarom een model een bepaalde uitvoer produceerde. Veel goed presterende modellen zijn in feite “black boxes”: in totaal nauwkeurig maar niet in staat een clinicus een betrouwbare reden voor een individuele beslissing te geven. In een klinische setting doet dit ertoe voor verantwoording, geïnformeerde toestemming en de plicht van de clinicus om oordeel te vellen — een arts kan niet zinvol verantwoordelijkheid nemen voor advies dat hij niet kan bevragen.

Modeldrift en bewaking na het in de handel brengen. De nauwkeurigheid van een model staat niet vast. Conceptdrift — een verandering in de tijd in het verband tussen invoer en datgene wat wordt voorspeld — betekent dat een model dat vorig jaar is gevalideerd dit jaar stilletjes kan verslechteren naarmate populaties, trajecten of upstream data veranderen. Daarom vereist AI doorlopende bewaking na het in de handel brengen (post-market surveillance) en monitoring, niet slechts een eenmalige validatie bij go-live.

MLOps en de levenscyclus van modellen. MLOps is de operationele discipline van het betrouwbaar uitrollen, monitoren, versioneren en hertrainen van modellen in productie. Het is de machinerie die bestuur over de levenscyclus echt maakt: weten welke versie van het model live is, op welke data, met welke prestaties, en kunnen terugdraaien.

Mens in de lus. Een ontwerp met een mens in de lus houdt een persoon — gewoonlijk een clinicus — op betekenisvolle wijze in de beslissing, met het gezag en de informatie om het model te overrulen. Goed gedaan behoudt het verantwoording; als stempel gedaan biedt het slechts de illusie van toezicht.

Generatieve AI en grote taalmodellen. Generatieve kunstmatige intelligentie, inclusief grote taalmodellen (LLM’s), produceert vlotte tekst en andere inhoud. Haar realistische waarde op korte termijn in gezondheid en zorg is grotendeels administratief — documentatie opstellen, samenvatten, papierwerk verlichten. Haar bepalende risico is hallucinatie: het zelfverzekerd genereren van onware maar aannemelijke inhoud, verergerd door risico’s voor vertrouwelijkheid wanneer patiëntdata in diensten van derden worden ingevoerd.

Digitale therapeutica en gezondheidsapps. Digitale therapeutica (DTx) zijn door software aangedreven, op bewijs gebaseerde interventies die een aandoening voorkomen, beheren of behandelen — onderscheiden van algemene welzijnsapps juist omdat zij een klinische claim doen, wat betekent dat veel ervan Software as a Medical Device zijn en hetzelfde bewijs en dezelfde borging vragen als elke andere interventie die u voorschrijft of aanbeveelt.

Beste praktijken#

1. Classificeer het instrument voordat u iets anders doet. Stel schriftelijk en met klinische en regelgevende inbreng vast of de AI een medisch doel heeft en daarom een gereguleerd medisch hulpmiddel is, en of zij geldige conformiteitsmarkering van de MHRA heeft. Deze ene bepaling stuurt alles stroomafwaarts — de route van borging, de aansprakelijkheden, de rechtmatigheid van inzet. Zoek bij twijfel regelgevend advies in plaats van aan te nemen dat een administratief instrument buiten het bereik valt.

2. Leid AI door uw bestaande machinerie voor klinische veiligheid en informatiebestuur, uitgebreid en niet omzeild. Elke klinische inzet van AI vraagt het klinisch risicobeheer van DCB0129/DCB0160 (zie Onderwerp 1.6) en een Data Protection Impact Assessment onder uw kader voor informatiebestuur (zie Onderwerp 1.7). Laat nieuwigheid of enthousiasme van de leverancier geen parallel, lichter proces scheppen. Gevaren specifiek voor AI — vooringenomenheid, drift, ondoorzichtigheid, automatiseringsbias — moeten aan het gevarenlogboek worden toegevoegd en haar niet vervangen.

3. Ondervraag de trainingsdata op representativiteit en vooringenomenheid. Vraag wie in de data zit en wie ontbreekt, hoe uitkomsten werden gelabeld en of de meetinstrumenten zelf over groepen heen bevooroordeeld waren. Eis dat de leverancier prestaties rapporteert uitgesplitst naar relevante subgroepen — leeftijd, geslacht, etniciteit, kansarmoede — en niet alleen de nauwkeurigheid in het algemeen. Een instrument dat geen billijke prestaties kan aantonen is een risico voor gezondheidsongelijkheid, hoe indrukwekkend het gemiddelde ook is.

4. Eis klinische validatie die past bij het risico en geef de voorkeur aan prospectief bewijs. Retrospectieve nauwkeurigheid op gecureerde data is de zwakste vorm van bewijs. Zoek voor alles wat klinische beslissingen beïnvloedt validatie in een populatie en werkstroom zoals de uwe, idealiter prospectief, en leid de claim door het passende kader van borging — het Evidence Standards Framework van NICE voor digitale gezondheidstechnologieën en de Digital Technology Assessment Criteria (DTAC) als basisborging. Stem de sterkte van het bewijs af op de omvang van de mogelijke schade.

5. Sta erop op een betekenisvolle mens in de lus en duidelijke verantwoording. Definieer wie verantwoordelijk is voor een beslissing waarover de AI informeerde en zorg dat de mens zowel het gezag heeft om te overrulen als de informatie om dat te doen. Waak actief tegen automatiseringsbias — de neiging zich aan de machine te onderwerpen — via training, ontwerp van de interface en audit van overrulepercentages. Als overrulen nooit gebeurt, is uw “mens in de lus” decoratief.

6. Behandel go-live als het begin van monitoring, niet het einde van borging. Zet vanaf dag één bewaking na het in de handel brengen op: monitor prestaties in de praktijk, let op conceptdrift en definieer de drempels en het proces voor hertrainen, pauzeren of terugtrekken van het model. Stel versiebeheer van modellen en terugdraaien in via gedegen MLOps zodat u altijd weet wat live is en veilig kunt terugkeren. Een model dat nooit opnieuw wordt gecontroleerd is een langzaam falende veiligheidsmaatregel.

7. Bestuur generatieve AI naar haar realistische gebruik en tegen haar echte risico’s. Sta LLM’s toe waar de waarde echt is en het risico beperkt — administratief opstellen, samenvatten, ondersteuning van documentatie met menselijke toetsing — en verbied het ongecontroleerd invoeren van patiënt-identificeerbare data in diensten van derden. Neem aan dat elke generatieve uitvoer verzonnen kan zijn tot een mens haar verifieert en laat nooit niet-geverifieerde gegenereerde inhoud in het klinische dossier komen. Duidelijk, afgedwongen beleid verslaat zowel een algemeen verbod dat schaduwgebruik drijft als een vrije-voor-allen die data lekt.

8. Pas informatiebestuur toe op de hele levenscyclus van data, inclusief training. De data die worden gebruikt om een model te trainen, fijn af te stellen en te evalueren vallen onder dezelfde verplichtingen tot rechtsgrond, minimalisatie en transparantie als elk ander gebruik (zie Onderwerp 1.7). Wees expliciet over de grondslag voor training op patiëntdata, of ze adequaat zijn gede-identificeerd en wat de leverancier ermee mag doen. Contracten moeten hergebruik van uw data om producten voor anderen te trainen zonder rechtmatige grondslag en uw instemming verbieden.

9. Houd een voor mensen leesbaar modelregister bij en eis transparantie van leveranciers. Houd een inventaris bij van AI in gebruik: doel, regelgevende status, herkomst van trainingsdata, bewijs van validatie, plan voor monitoring en verantwoordelijke eigenaar. Eis dat leveranciers transparant zijn over hoe een model werkt, haar beperkingen en haar faalwijzen; ondoorzichtigheid van een leverancier is zelf een risicosignaal. U kunt niet besturen wat u niet hebt opgeschreven.

10. Scan de horizon bewust en voer gefaseerd in via gecontroleerde evaluatie. Let voorbij de AI van vandaag op opkomende technologieën — ambient documentatie, foundation models en verder weg, kwantum en nieuwe sensoren — met gestructureerde horizonscanning in plaats van reactieve inkoop. Voer alles wat werkelijk nieuw is in via de gecontroleerde, omkeerbare, geëvalueerde aanpak van innovatie gefaseerd invoeren (zie Onderwerp 8.0), klein beginnend, eerlijk metend en het vermogen behoudend te stoppen.

11. Behandel digitale therapeutica en gezondheidsapps als interventies, niet als consumentendownloads. Wanneer een app een klinische claim doet — om een aandoening te behandelen, beheren of voorkomen — is zij een interventie waarop patiënten zullen handelen, en verdient zij dezelfde toetsing als een geneesmiddel of hulpmiddel voordat u haar voorschrijft of aanbeveelt. Stel vast of zij Software as a Medical Device is met geldige conformiteitsmarkering, eis bewijs dat past bij haar claim en voltooi een beoordeling van klinische veiligheid (zie Onderwerp 1.6) in plaats van te vertrouwen op een beoordeling in een app-winkel of het enthousiasme van een leverancier. Een niet-geborgde app die een clinicus onderschrijft draagt de naam van uw organisatie en uw verantwoording als zij schaadt.

12. Leid gezondheidsapps door bestaande borging en houd een gecureerde, veilige bibliotheek bij. Beoordeel digitale therapeutica via dezelfde machinerie die u al draait — DTAC als basis, het Evidence Standards Framework van NICE afgestemd op de klinische claim en toetsing van klinische veiligheid en informatiebestuur — en bouw in de tijd bewijs op via evaluatie in de praktijk (zie Onderwerp 8.6). Houd een gecureerde bibliotheek bij van apps die u hebt geborgd en waarvoor u instaat, met van elke app de regelgevende status, het bewijs en de eigenaar vastgelegd, zodat clinici aanbevelen uit een veilige, bestuurde shortlist. Het alternatief — een ongecontroleerde wildgroei van niet-beoordeelde apps die informeel over teams worden aanbevolen — is onbeheersbaar en onveilig.

Vragen om met uw team te bespreken#

1. Weten wij voor elk AI-instrument dat wij overwegen of al gebruiken werkelijk of het een gereguleerd medisch hulpmiddel is — en kunnen wij het bewijs overleggen? Dit klinkt als een formaliteit van naleving maar het is de dragende vraag, omdat het antwoord bepaalt wat rechtmatig is, wie aansprakelijk is en welke borging u het publiek verschuldigd bent. Het is gemakkelijk aan te nemen dat een instrument dat “alleen helpt bij triage” of “alleen notities samenvat” onschuldige administratieve software is terwijl zijn medische doel het in werkelijkheid een gereguleerd hulpmiddel maakt dat conformiteitsmarkering van de MHRA vereist. De discussie moet u dwingen elk AI-instrument in gebruik of in de pijplijn te noemen, het beoogde doel in gewone klinische termen te zeggen en vast te stellen wie de beslissing over de classificatie van het hulpmiddel nam en op welke grondslag. Zij moet de ongemakkelijke gevallen aan het licht brengen waarin een instrument via een gewone IT-route werd aangeschaft zonder enige regelgevende controle. Wees eerlijk of u vandaag de documentatie van conformiteit en het bewijs van validatie zou kunnen overleggen als een toezichthouder of een lijkschouwer erom vroeg. De waarde van het gesprek is dat het een vaag gevoel dat “iemand het vast heeft gecontroleerd” omzet in een gedocumenteerde, bezeten positie — en de instrumenten onthult waarvoor niemand dat deed.

2. Hebben wij geëist te zien hoe dit model presteert voor de groepen die het meest waarschijnlijk worden geschaad, of hebben wij een cijfer voor nauwkeurigheid in het algemeen aanvaard? Gemiddelde nauwkeurigheid is het getal waarmee leveranciers openen en het getal dat algoritmische vooringenomenheid verbergt, omdat een model in totaal zeer nauwkeurig kan zijn terwijl het merkbaar slechter presteert voor een ondervertegenwoordigde groep. In gezondheid en zorg is dat geen statistische curiositeit; het is een mechanisme om de ongelijkheden te vergroten die u wettelijk en moreel moet verkleinen, stilletjes en op schaal toegepast. Het team moet bespreken welk bewijs voor subgroepen u werkelijk hebt gezien — prestaties uitgesplitst naar leeftijd, geslacht, etniciteit en kansarmoede — en of u weet wie in de trainingsdata zat en wie ontbrak. Het loont het ongemak te benoemen: een leverancier op eerlijkheid aandringen kan voelen als het dwarsbomen van een opwindende innovatie, en de eerlijke vraag is of u bereid bent nee te zeggen tegen een instrument dat geen billijke prestaties kan aantonen. Overweeg ook hoe u onbillijke uitkomsten na inzet zelfs zou opsporen, want vooringenomenheid die bij de aanschaf onzichtbaar was zal in productie onzichtbaar zijn tenzij u ernaar zoekt. Een goede discussie eindigt met een concrete lat voor bewijs van eerlijkheid die geldt voordat enige klinische AI live gaat, en een plan om daarna te blijven kijken.

3. Wanneer dit model fout is — en dat zal gebeuren — wie is verantwoordelijk, zal een mens het werkelijk vangen en hoe zouden wij het zelfs weten? Elk model faalt soms, en lerende systemen kunnen in de tijd afdrijven naar vaker falen, dus de volwassen vraag is niet of fouten optreden maar of uw waarborgen echt zijn. Het team moet toetsen of de mens in de lus betekenisvol is of decoratief: heeft de clinicus het gezag en de informatie om te overrulen, en als u naar overrulepercentages keek, zou u dan vinden dat er ooit werkelijk wordt overruled, of is automatiseringsbias ingetreden? Bespreek wie als verantwoordelijk wordt genoemd voor een beslissing waarover de AI informeerde — de clinicus, de organisatie, de leverancier — want “het algoritme deed het” is geen verdedigbare positie tegenover een patiënt of een lijkschouwer. Confronteer uw monitoring eerlijk: hebt u bewaking na het in de handel brengen die conceptdrift zou opsporen, gedefinieerde drempels om het model te pauzeren of terug te trekken en de MLOps-machinerie om te weten welke versie live is en haar terug te draaien? Voeg voor generatieve instrumenten de vraag van hallucinatie toe — wat voorkomt dat verzonnen inhoud het klinische dossier binnenkomt, en wie verifieert uitvoer voordat zij wordt vertrouwd? De nuttigste versie van dit gesprek legt de kloof bloot tussen het geruststellende diagram van “menselijk toezicht” en wat er werkelijk zou gebeuren om 3 uur ’s nachts op een drukke afdeling.

4. Wat gebeurt er met de data van onze patiënten wanneer wij deze modellen trainen, fijn afstellen en draaien — en welk recht heeft de leverancier zich voorbehouden om ermee te doen? AI concentreert risico voor databestuur juist omdat de data het product zijn: een model is slechts zo betrouwbaar als de rechtsgrond, minimalisatie en transparantie achter elke dataset die zij raakte, inclusief de trainings- en evaluatiedata die aan go-live voorafgaat. Het team moet voor elk instrument kunnen zeggen wat de rechtsgrond is voor enig gebruik van patiëntdata, of de de-identificatie adequaat is en niet louter beweerd en waar de data fysiek heen stromen zodra zij uw controle verlaten. Een terugkerende valkuil is het contract dat de leverancier stilletjes toestaat uw data te hergebruiken om producten te verbeteren die hij aan anderen zal verkopen; bespreek of uw overeenkomsten dat zonder rechtmatige grondslag en uw uitdrukkelijke toestemming verbieden en of iemand die bepalingen werkelijk heeft gelezen. Dit hangt rechtstreeks samen met uw kader voor informatiebestuur (zie Onderwerp 1.7), en het is waar enthousiasme voor een capabel instrument het vaakst voorbijschiet aan zorgvuldig onderzoek. Een eerlijk antwoord noemt wie de DPIA bezit, wat de leverancier wel en niet mag doen en waar u nu bloot staat — in plaats van aan te nemen dat omdat de demo indrukwekkend was het papierwerk wel in orde zal zijn.

5. Hoe besluiten wij wat wij NIET overnemen, en kunnen wij de druk weerstaan te kopen waar iedereen enthousiast over is? De moeilijkste bestuurlijke discipline bij een snel bewegende technologie is “nog niet” of “dit niet” zeggen, en een team dat zijn criteria voor afwijzen niet kan verwoorden zal eindigen met overnemen door afdrijven en hype in plaats van door bewijs. Bespreek wat u zou doen weglopen van een anders aantrekkelijk instrument — zwak bewijs voor subgroepen, een onduidelijke regelgevende status, een toepassing waarbij de realistische baat dun is ten opzichte van het risico — en of die rode lijnen zijn opgeschreven of louter gevoeld. Er is een echte spanning tussen de kosten van het missen van een werkelijke verbetering en de kosten van een geschaald falen dat publiek vertrouwen beschadigt, en redelijke mensen zullen ze verschillend wegen. Het loont de politieke werkelijkheid te benoemen dat de druk om over te nemen vaak komt van een bestuur, een relatie met een leverancier of een nationaal mandaat en niet van de klinische behoefte zelf. De houding van dit onderwerp is de horizon bewust te scannen en gefaseerd in te voeren via gecontroleerde, omkeerbare evaluatie (zie Onderwerp 8.0), dus een eerlijk antwoord beschrijft hoe een veelbelovend maar onbewezen instrument binnenkomt als kleine, gemeten, stopbare pilot en niet als uitrol in het groot — en wie het gezag heeft het te stoppen.

6. Kunnen wij uitleggen wat dit model doet aan de clinici die het moeten vertrouwen en de patiënten die erdoor worden geraakt — en zijn wij eerlijk geweest over zijn grenzen? Een model dat een clinicus niet kan bevragen en een patiënt niet kan begrijpen holt het geïnformeerde oordeel en de geïnformeerde toestemming uit waarvan klinische zorg afhangt, hoe nauwkeurig het in totaal ook is. Het team moet bespreken hoeveel verklaarbaarheid dit specifieke gebruik werkelijk vereist: een hulpmiddel om een wachtrij te prioriteren vraagt minder dan een instrument dat een diagnose of behandelbeslissing beïnvloedt, en de verklaring afstemmen op de inzet is een bestuurlijke keuze en geen technische bijzaak. Overweeg wat u vertelt aan de clinici van wie wordt verwacht dat zij het gebruiken — het doel, de bekende faalwijzen, de groepen voor wie het minder betrouwbaar is — en of die briefing openhartig is of een marketingsamenvatting. Eerlijkheid jegens patiënten doet er ook toe: wordt mensen verteld wanneer AI betrokken is bij hun zorg, en in taal waarop zij kunnen handelen? Dit is ook een kwestie van personeel, omdat te laag vertrouwen een nuttig instrument genegeerd laat worden terwijl te hoog vertrouwen de automatiseringsbias produceert die toezicht uitholt. Een eerlijk antwoord confronteert of uw training en communicatie gekalibreerd vertrouwen bouwen of het instrument louter verkopen.

In de praktijk: een voorbeeld uit gezondheid en zorg#

Een integrated care system krijgt een AI-instrument aangeboden dat röntgenfoto’s van de borst leest en waarschijnlijke afwijkingen markeert om de wachtrij voor rapportage door radiologie te prioriteren. De klinischeveiligheidsfunctionaris en de medisch directeur weerstaan de druk het snel aan te schaffen en leiden het in plaats daarvan door behoorlijk bestuur.

Eerst classificatie: het instrument heeft een duidelijk medisch doel, dus wordt bevestigd dat het Software as a Medical Device is, en de conformiteitsmarkering van de MHRA en de verklaring van beoogd gebruik worden geverifieerd — het beoogde gebruik is ondersteuning van triage, niet autonome diagnose, wat alles wat volgt vormt. Daarna borging: het instrument gaat door DTAC als basis, zijn klinische claims worden getoetst aan het Evidence Standards Framework van NICE, een beoordeling van klinisch risico onder DCB0160 wordt voltooid en een DPIA dekt de beeldvormingsdata (zie Onderwerpen 1.6 en 1.7). Het team vraagt om prestaties voor subgroepen en ontdekt dat de populatie van de validatie een lokale demografische groep ondervertegenwoordigde; zij eisen aanvullende lokale validatie voordat ze doorgaan en behandelen mogelijke vooringenomenheid als risico voor gezondheidsongelijkheid en niet als voetnoot.

Bij de inzet houdt het ontwerp een mens in de lus: elk beeld wordt nog steeds door een radioloog gerapporteerd en de AI herordent alleen de wachtrij, zodat een gemiste markering niet alleen een gemiste diagnose kan veroorzaken. Bewaking na het in de handel brengen wordt vanaf dag één opgezet — monitoring van detectiepercentages, afwijkingen tussen het model en de rapporterende radiologen en elke drift naarmate scannerhardware en casemix veranderen — met vooraf afgesproken drempels om het instrument te pauzeren en een pad om terug te draaien via de geversioneerde uitrol van de leverancier. Los daarvan, wanneer een afdeling vraagt patiëntgeschiedenissen in een publiek LLM te plakken om ontslagbrieven op te stellen, zegt hetzelfde bestuursforum nee tegen die ongecontroleerde route en geeft opdracht tot een goedgekeurd, afgeschermd instrument met menselijke verificatie. Een jaar later heeft het instrument voor prioritering van de wachtrij de doorlooptijd van rapportage bescheiden verbeterd, heeft de monitoring één geval van drift gevangen na een upgrade van de scanner en — cruciaal — kan de organisatie precies tonen hoe het wordt bestuurd.

Sectorperspectieven#

Startup#

Een startup in digitale gezondheid is vaak de AI, dus haar volwassenheid van bestuur is haar toegang tot de markt. Oprichters moeten regelgevende classificatie, klinische validatie en bewijs voor vooringenomenheid behandelen als kernwerk van het product en niet als belasting van naleving die vóór een verkoop wordt aangebracht, want de klinischeveiligheidsfunctionaris van een koper zal precies hierom vragen en een “nee” beëindigt de deal. Vroeg samenwerken met de MHRA — mogelijk via mechanismen als de AI Airlock voor werkelijk nieuwe vragen — en vanaf het begin ontwerpen voor DTAC en het Evidence Standards Framework van NICE maakt borging tot concurrentievoordeel. Het kenmerkende risico van een startup is overclaimen: marketing die het bewijs vooruit snelt, of een demo van gemiddelde nauwkeurigheid die slechte prestaties voor subgroepen verbergt. De gedisciplineerde oprichter bouwt vroeg monitoring en bewaking na het in de handel brengen in het product in, want één geschaald falen op een referentielocatie is een existentiële gebeurtenis voor een klein bedrijf.

Klein bedrijf#

Een gevestigde kleine aanbieder — een huisartsenpraktijk, een gemeenschapsapotheek, een verzorgingshuis, een kliniek met één vestiging — is gewoonlijk koper van AI en geen bouwer, maar draagt dezelfde plichten als een groot ziekenhuis zonder de eigen klinischeveiligheids-, IG- of informaticamedewerkers om ze te vervullen. Het praktische risico is een instrument overnemen op de zekerheden van een leverancier omdat er intern geen capaciteit is om classificatie van het hulpmiddel, bewijs voor subgroepen of een DPIA te eisen en niemand om op te merken wanneer een model afdrijft. Leun zwaar op de borging die anderen al hebben gedaan: geef de voorkeur aan instrumenten die duidelijk conformiteitsmarkering van de MHRA hebben en DTAC hebben doorstaan, koop van leveranciers die hun bewijs publiceren en beveel gezondheidsapps alleen aan uit een gecureerde bibliotheek die uw ICS of een nationaal orgaan heeft geborgd in plaats van elke app zelf te beoordelen. Waar u de veiligheid van een instrument niet persoonlijk kunt verifiëren, is dat een reden om u te beroepen op de gedeelde borging van uw stelsel en niet om de controle over te slaan. Zelfs een lichte registratie bijhouden van welke AI-instrumenten u gebruikt, waarvoor en wie ze bezit maakt van een onbeheersbare plicht een evenredige.

Grote onderneming#

Een groot ziekenhuis of ICS heeft het apparaat om AI behoorlijk te besturen en de schaal die het ernstig maakt als het fout gaat. Zijn taak is bestaande functies voor klinische veiligheid, IG en borging uit te breiden om AI te dekken — een modelregister, een lat voor eerlijkheid van subgroepen, bewaking na het in de handel brengen, MLOps voor versiebeheer en terugdraaien — in plaats van AI via niet-getoetste IT- of onderzoeksroutes te laten binnenkomen. Het echte gevaar voor de grote onderneming is fragmentatie: tientallen pilots, trials met ambient scribes en afdelingsexperimenten met LLM’s die zich vermenigvuldigen zonder centrale inventaris, zonder consistente DPIA en zonder dat iemand verantwoordelijk is wanneer een instrument afdrijft. Veranderingsmoeheid en druk van leveranciers duwen naar snelle adoptie, dus de leiding moet de lijn vasthouden dat nieuwigheid geen lichter proces verdient. Goed gedaan kan de grote onderneming ook het prospectieve, lokale bewijs van validatie genereren dat kleinere spelers niet kunnen, en het over het stelsel delen.

Overheid#

Nationale en lokale overheidsorganen — de MHRA, NHS England, DHSC, NICE, gedecentraliseerde overheden en lokale overheden — stellen de voorwaarden vast waaronder alle anderen AI inzetten. Hun instrumenten zijn regelgeving, normen, kaders voor borging (DTAC, het Evidence Standards Framework), mechanismen met veilige haven als de AI Airlock en de financiering en richtlijnen die veilige adoptie sturen over een gefedereerd stelsel dat zij niet rechtstreeks aansturen. Verantwoording loopt naar ministers, het Parlement en het publiek, dus een geschaald falen van AI of aantoonbare vooringenomenheid in een nationaal instrument is een gebeurtenis van publiek vertrouwen met een lange schaduw. De juiste rol van de overheid is het veilige pad het gemakkelijke pad te maken — duidelijke regels, herbruikbare borging, eerlijke publiekscommunicatie over wat AI wel en niet kan — terwijl zowel door hype gedreven mandaten als reflexmatig verbod worden weerstaan. De balans in beide richtingen fout krijgen kost jaren van vertrouwen.

Veelvoorkomende faalpatronen#

• Regelgevende classificatie overslaan. Een klinische AI inzetten alsof het gewone software was. Voorkom het door eerst met regelgevende inbreng de status van hulpmiddel en conformiteitsmarkering vast te stellen.
• Blindheid voor de nauwkeurigheid in het algemeen. Een gemiddeld cijfer aanvaarden dat slechte prestaties voor ondervertegenwoordigde groepen verbergt. Voorkom het door bewijs voor subgroepen te eisen vóór go-live en na te gaan op onbillijkheid daarna.
• Eenmaal valideren, voor altijd vergeten. Go-live behandelen als het einde van borging terwijl het model stilletjes afdrijft. Voorkom het door bewaking na het in de handel brengen op te zetten met drempels en terugdraaien.
• Decoratief menselijk toezicht. Een “mens in de lus” die afstempelt onder automatiseringsbias. Voorkom het door overrulepercentages te auditen en echt gezag om in te grijpen te ontwerpen.
• Ongecontroleerde generatieve AI. Personeel dat patiëntdata in publieke LLM’s plakt en verzonnen uitvoer vertrouwt. Voorkom het door duidelijk beleid plus een goedgekeurd, afgeschermd instrument met menselijke verificatie.
• Parallel proces met lichte hand. AI klinische veiligheid en IG laten omzeilen omdat het “innovatie” is. Voorkom het door bestaande machinerie van DCB en DPIA uit te breiden naar AI.
• Geen inventaris. Niemand die weet welke modellen live zijn, op welke data, van wie. Voorkom het door een modelregister bij te houden.

Volwassenheidsmodel#

Checklist#

• De status van medisch hulpmiddel en de conformiteitsmarkering van de MHRA van elk AI-instrument zijn vastgesteld en gedocumenteerd.
• Klinische AI heeft DTAC doorstaan, is getoetst aan het Evidence Standards Framework van NICE en heeft een beoordeling van klinisch risico onder DCB en een DPIA.
• Prestaties voor subgroepen (leeftijd, geslacht, etniciteit, kansarmoede) zijn gezien en voldoen aan een afgesproken lat voor eerlijkheid.
• Klinische validatie past bij het risiconiveau en geeft de voorkeur aan prospectief, lokaal bewijs.
• Een betekenisvolle mens in de lus is ontworpen, met gezag en informatie om te overrulen.
• Benoemde verantwoording voor beslissingen waarover AI informeerde is opgeschreven.
• Bewaking na het in de handel brengen, drempels voor drift en een plan om te pauzeren/terug te draaien zijn vanaf go-live live.
• MLOps geeft versiebeheer van modellen en veilig terugdraaien; de live versie is altijd bekend.
• Beleid voor generatieve AI staat realistisch gebruik toe, verbiedt patiëntdata in ongecontroleerde diensten en vereist menselijke verificatie.
• Informatiebestuur dekt data voor training, fijn afstellen en evaluatie, met contractuele grenzen aan hergebruik door de leverancier.
• Een voor mensen leesbaar modelregister legt doel, herkomst, bewijs, monitoring en eigenaar vast.
• Opkomende technologieën worden met horizonscanning gevolgd en gefaseerd ingevoerd via gecontroleerde, omkeerbare evaluatie.

Belangrijkste bronnen#

• MHRA — Software and Artificial Intelligence (AI) as a Medical Device, en de regelgevende sandbox AI Airlock (gov.uk).
• NICE — Evidence Standards Framework (ESF) voor digitale gezondheidstechnologieën (nice.org.uk).
• NHS England — Digital Technology Assessment Criteria (DTAC) voor basisborging van digitale gezondheidstechnologieën.
• NHS England / voormalige NHSX — A Buyer’s Guide to AI in Health and Care, en het AI Ethics Initiative.
• DCB0129 en DCB0160 — normen voor klinisch risicobeheer van IT in de gezondheidszorg (zie Onderwerp 1.6).
• MHRA / IMDRF — kader voor Software as a Medical Device (SaMD) en goede praktijk voor machine learning.
• The King’s Fund en de Health Foundation — analyse van AI, data en ongelijkheid in gezondheid en zorg.
• Zie ook Onderwerp 1.3 — Op bewijs gebaseerde besluitvorming; Onderwerp 1.6 — Klinische veiligheid en risicobeheer; Onderwerp 1.7 — Informatiebeheer, gegevensbescherming en cyberbeveiliging; Onderwerp 8.0 — Innovatie gefaseerd invoeren.

Referenties#

1. Artificial intelligence — Wikipedia — https://en.wikipedia.org/wiki/Artificial_intelligence
2. Machine learning — Wikipedia — https://en.wikipedia.org/wiki/Machine_learning
3. Medical software (including Software as a Medical Device) — Wikipedia — https://en.wikipedia.org/wiki/Medical_software
4. Medicines and Healthcare products Regulatory Agency — Wikipedia — https://en.wikipedia.org/wiki/Medicines_and_Healthcare_products_Regulatory_Agency
5. Algorithmic bias — Wikipedia — https://en.wikipedia.org/wiki/Algorithmic_bias
6. Explainable artificial intelligence — Wikipedia — https://en.wikipedia.org/wiki/Explainable_artificial_intelligence
7. Concept drift — Wikipedia — https://en.wikipedia.org/wiki/Concept_drift
8. MLOps — Wikipedia — https://en.wikipedia.org/wiki/MLOps
9. Human-in-the-loop — Wikipedia — https://en.wikipedia.org/wiki/Human-in-the-loop
10. Generative artificial intelligence — Wikipedia — https://en.wikipedia.org/wiki/Generative_artificial_intelligence
11. Large language model — Wikipedia — https://en.wikipedia.org/wiki/Large_language_model
12. Hallucination (artificial intelligence) — Wikipedia — 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 — Wikipedia — https://en.wikipedia.org/wiki/Digital_therapeutics