Emne 8.4 — Styring af AI og ny teknologi

I én sætning: Kunstig intelligens i sundhed og pleje er en lærende, dataafhængig og ofte uigennemsigtig teknologi, der kan skalere både gevinst og skade hurtigere end noget system, I har styret før, så I må styre den som et spørgsmål om klinisk sikkerhed, lighed og offentlig tillid gennem hele dens livscyklus — ikke behandle den som almindelig software, I køber én gang og glemmer.

Hvorfor det er vigtigt i sundhed og pleje#

Det meste software, I har udrullet, opfører sig i morgen, som det gør i dag: dets logik er nedskrevet, dets adfærd er testbar, og når det tager fejl, tager det typisk fejl på en synlig, gentagelig måde. Kunstig intelligens bryder alle tre trygheder. Den lærer statistiske mønstre fra data frem for at følge regler, et menneske har skrevet; dens adfærd afhænger helt af de data, den er trænet på, og de data, den nu møder; og dens ræsonnement er ofte uigennemsigtigt, selv for dem, der byggede den. Den kombination er grunden til, at AI har brug for sin egen styringsdisciplin frem for at blive foldet ind i en generisk softwaretjekliste.

I sundhed og pleje er konsekvenserne ikke abstrakte. En model, der underdetekterer sygdom hos en gruppe, der var underrepræsenteret i dens træningsdata, begår ikke en isoleret fejl — den begår den samme fejl, i det stille, tusindvis af gange, og forankrer og skalerer sundhedsuligheder. En generativ model, der fabrikerer en plausibelt klingende klinisk detalje, kan vildlede en presset kliniker på netop det forkerte tidspunkt. Et værktøj, der virker smukt på den befolkning, det blev valideret på, kan i det stille forfalde, når befolkningen, plejeforløbet eller de opstrøms data ændrer sig. AI kan skalere gode beslutninger, og den kan skalere bias, fejl og skade med lige stor effektivitet.

Dette emne handler om at styre den risiko uden hverken at indånde hypen eller forbyde teknologien. Det gentager bevidst ikke de fundamenter, der er lagt andetsteds: klinisk sikkerhed (se emne 1.6 — Klinisk sikkerhed og risikostyring), informationsstyring, databeskyttelse og cybersikkerhed (se emne 1.7 — Informationsstyring, databeskyttelse og cybersikkerhed) og evidensbaseret beslutningstagning (se emne 1.3 — Evidensbaserede beslutninger). Det forankres i dem og tilføjer det, der er specifikt for lærende systemer. Behandl det som den AI-formede udvidelse af jeres eksisterende assurance og som det styrede søskende til indfasning af innovation (se emne 8.0 — Indfasning af innovation).

Kernebegreber#

Kunstig intelligens og maskinlæring. For en leder er det praktiske skel dette: det meste AI i sundhed og pleje i dag er maskinlæring — systemer, der udleder mønstre fra eksempler frem for at udføre håndskrevne regler. Det er grunden til, at dataene er produktet lige så meget som koden: ændrer I træningsdataene, ændrer I adfærden. Det betyder også, at en model ikke "ved" noget; den estimerer, og den kan være selvsikkert forkert. At forstå dette på et begrebsligt niveau er nok til at stille de rette styringsspørgsmål; I behøver ikke læse matematikken.

Software som medicinsk udstyr (SaMD) og MHRA. Når software har et medicinsk formål — diagnosticering, screening, triagering, beregning af en dosis, forudsigelse af forværring — er det meget ofte medicinsk udstyr juridisk set, uanset om det kører på en telefon eller en server. Medicinsk software af den art, kendt som Software as a Medical Device (SaMD), reguleres i Storbritannien af Medicines and Healthcare products Regulatory Agency (MHRA). Hvis I bestiller eller bygger et AI-værktøj med et klinisk formål, er det første styringsspørgsmål, om det er et reguleret udstyr, og hvis ja, om det har gyldig overensstemmelsesmærkning. At tage fejl her er ikke en teknikalitet; at udrulle uregistreret medicinsk udstyr er ulovligt og usikkert.

AI Airlock. MHRA har etableret en regulatorisk sandkasse kaldet AI Airlock for at arbejde sig igennem, hvordan AI som medicinsk udstyr bør reguleres i en kontrolleret, overvåget setting. En regulatorisk sandkasse lader en regulator og et lille antal udviklere undersøge svære, nye spørgsmål — for eksempel hvordan man validerer en model, der opdateres over tid — under tilsyn, før der fastsættes generelle regler. Vær nøgterne om, hvad dette er: Airlock er et læringsmiljø for regulatoren og en håndfuld deltagere, ikke en hurtig godkendelsesvej, og at være knyttet til den betyder ikke, at et produkt er godkendt til generel klinisk brug.

Algoritmisk bias og fairness. Algoritmisk bias er tendensen hos et system til at producere systematisk uretfærdige udfald for bestemte grupper. I sundhed og pleje er den hyppigste kilde træningsdataene: hvis en gruppe er underrepræsenteret, fejlmærket eller målt med et biased instrument, lærer modellen at betjene den gruppe dårligere. Fordi modellen derefter anvender dette i skala og med et skær af objektivitet, kan biased AI udvide netop de uligheder, jeres organisation er lovpligtig til at reducere.

Forklarbarhed og den sorte boks. Forklarlig kunstig intelligens angår, om et menneske kan forstå, hvorfor en model producerede et givet output. Mange højtydende modeller er reelt "sorte bokse": nøjagtige i aggregat, men ude af stand til at give en kliniker en troværdig begrundelse for en enkelt beslutning. I en klinisk setting betyder det noget for ansvar, informeret samtykke og klinikerens pligt til at udøve dømmekraft — en læge kan ikke meningsfuldt tage ansvar for råd, vedkommende ikke kan udspørge.

Modeldrift og overvågning efter markedsføring. En models nøjagtighed er ikke fast. Konceptdrift — en ændring over tid i forholdet mellem input og det, der forudsiges — betyder, at en model valideret sidste år i det stille kan forringes i år, efterhånden som befolkninger, forløb eller opstrøms data ændrer sig. Det er grunden til, at AI kræver løbende overvågning efter markedsføring (post-market surveillance), ikke blot en engangsvalidering ved go-live.

MLOps og modellens livscyklus. MLOps er den operationelle disciplin at udrulle, overvåge, versionere og gentræne modeller pålideligt i produktion. Det er maskineriet, der gør livscyklusstyring reel: at vide, hvilken modelversion der er i drift, på hvilke data, med hvilken ydelse, og at kunne rulle tilbage.

Menneske i løkken. Et menneske-i-løkken-design holder et menneske — som regel en kliniker — meningsfuldt inde i beslutningen, med beføjelsen og informationen til at tilsidesætte modellen. Gjort godt bevarer det ansvar; gjort som gummistempel giver det kun illusionen af tilsyn.

Generativ AI og store sprogmodeller. Generativ kunstig intelligens, herunder store sprogmodeller (LLM’er), producerer flydende tekst og andet indhold. Dens realistiske værdi på kort sigt i sundhed og pleje er i høj grad administrativ — udarbejdelse af dokumentation, opsummering, lettelse af papirarbejde. Dens definerende risiko er hallucination: den selvsikre generering af falsk, men plausibelt indhold, forværret af fortrolighedsrisici, når patientdata indtastes i tredjepartstjenester.

Digitale terapeutika og sundhedsapps. Digitale terapeutika (DTx) er softwaredrevne, evidensbaserede interventioner, der forebygger, håndterer eller behandler en tilstand — forskellige fra generelle velværeapps netop fordi de fremsætter et klinisk krav, hvilket betyder, at mange er Software as a Medical Device og kræver samme evidens og assurance som enhver anden intervention, I ordinerer eller anbefaler.

Bedste praksis#

1. Klassificér værktøjet, før I gør andet. Fastslå skriftligt og med klinisk og regulatorisk input, om AI’en har et medicinsk formål og derfor er et reguleret medicinsk udstyr, og om den har gyldig MHRA-overensstemmelsesmærkning. Denne ene afgørelse styrer alt nedstrøms — assurancevejen, ansvarsforholdene, udrulningens lovlighed. I tvivlstilfælde, søg regulatorisk rådgivning frem for at antage, at et administrativt værktøj er uden for omfanget.

2. Led AI gennem jeres eksisterende kliniske sikkerheds- og informationsstyringsmaskineri, udvidet ikke omgået. Enhver klinisk AI-udrulning har brug for den kliniske risikostyring i DCB0129/DCB0160 (se emne 1.6) og en databeskyttelseskonsekvensvurdering (DPIA) under jeres informationsstyringsramme (se emne 1.7). Lad ikke nyhed eller leverandørbegejstring skabe en parallel, lettere proces. AI-specifikke farer — bias, drift, uigennemsigtighed, automatiseringsbias — bør føjes til farelogen, ikke erstatte den.

3. Udspørg træningsdataene om repræsentativitet og bias. Spørg, hvem der er i dataene, og hvem der mangler, hvordan resultater blev mærket, og om måleinstrumenterne selv var biased på tværs af grupper. Kræv, at leverandøren rapporterer ydelse opdelt efter relevante undergrupper — alder, køn, etnicitet, afsavn — ikke blot overskriftsnøjagtighed. Et værktøj, der ikke kan påvise retfærdig ydelse, er en sundhedsulighedsrisiko, uanset hvor imponerende dets gennemsnit er.

4. Kræv klinisk validering, der passer til risikoen, og foretræk prospektiv evidens. Retrospektiv nøjagtighed på kuraterede data er den svageste form for evidens. For alt, der påvirker kliniske beslutninger, søg validering i en befolkning og arbejdsgang som jeres, helst prospektiv, og led kravet gennem den passende assurancerramme — NICE Evidence Standards Framework for digitale sundhedsteknologier og Digital Technology Assessment Criteria (DTAC) som baseline-assurance. Afstem evidensens styrke med den potentielle skades størrelse.

5. Insistér på meningsfuldt menneske-i-løkken og klart ansvar. Definér, hvem der er ansvarlig for en beslutning, AI’en informerede, og sørg for, at mennesket har både beføjelsen til at tilsidesætte og informationen til at gøre det. Værn aktivt mod automatiseringsbias — tendensen til at give efter for maskinen — gennem uddannelse, grænsefladedesign og revision af tilsidesættelsesrater. Hvis tilsidesættelser aldrig sker, er jeres "menneske i løkken" dekorativt.

6. Behandl go-live som starten på overvågning, ikke slutningen på assurance. Opret overvågning efter markedsføring fra dag ét: overvåg ydelse i den virkelige verden, hold øje med konceptdrift, og definér tærsklerne og processen for at gentræne, sætte på pause eller trække modellen tilbage. Etablér modelversionering og tilbagerulning gennem sund MLOps, så I altid ved, hvad der er i drift, og kan vende sikkert tilbage. En model, der aldrig tjekkes igen, er en langsomt svigtende sikkerhedskontrol.

7. Styr generativ AI efter dens realistiske anvendelser og mod dens reelle risici. Tillad LLM’er, hvor værdien er ægte og risikoen indeholdt — administrativ udarbejdelse, opsummering, dokumentationsstøtte med menneskelig gennemgang — og forbyd ustyret indtastning af patientidentificerbare data i tredjepartstjenester. Antag at ethvert generativt output kan være fabrikeret, indtil et menneske har verificeret det, og lad aldrig ubekræftet genereret indhold komme ind i den kliniske journal. Klar, håndhævet politik slår både et generelt forbud, der driver skyggebrug, og et frit-for-alle, der lækker data.

8. Anvend informationsstyring på hele datalivscyklussen, herunder træning. De data, der bruges til at træne, finjustere og evaluere en model, er underlagt de samme krav om lovligt grundlag, minimering og gennemsigtighed som enhver anden brug (se emne 1.7). Vær eksplicitte om grundlaget for at træne på patientdata, om det er tilstrækkeligt de-identificeret, og hvad leverandøren må gøre med det. Kontrakter bør forbyde genbrug af jeres data til at træne produkter for andre uden et lovligt grundlag og jeres aftale.

9. Hold et menneskelæseligt modelregister, og kræv gennemsigtighed fra leverandører. Vedligehold en fortegnelse over AI i brug: formål, regulatorisk status, træningsdataenes proveniens, valideringsevidens, overvågningsplan og ansvarlig ejer. Kræv, at leverandører er gennemsigtige om, hvordan en model virker, dens begrænsninger og dens fejlmønstre; uigennemsigtighed fra en leverandør er i sig selv et risikosignal. I kan ikke styre det, I ikke har skrevet ned.

10. Scan horisonten bevidst, og indfas gennem kontrolleret evaluering. Ud over dagens AI, hold øje med fremvoksende teknologier — ambient dokumentation, fundamentmodeller og, længere ude, kvante og ny sensorik — med struktureret horisontscanning frem for reaktive indkøb. Indfør alt reelt nyt gennem den kontrollerede, reversible, evaluerede tilgang i indfasning af innovation (se emne 8.0), start småt, mål ærligt og bevar evnen til at stoppe.

11. Behandl digitale terapeutika og sundhedsapps som interventioner, ikke forbruger-downloads. Når en app fremsætter et klinisk krav — at behandle, håndtere eller forebygge en tilstand — er den en intervention, patienter vil handle på, og den fortjener samme granskning som et lægemiddel eller udstyr, før I ordinerer eller anbefaler den. Fastslå, om den er Software as a Medical Device med gyldig overensstemmelsesmærkning, kræv evidens proportional med dens krav, og gennemfør en klinisk sikkerhedsvurdering (se emne 1.6) frem for at stole på en app-store-vurdering eller en leverandørs begejstring. En uassureret app, en kliniker støtter, bærer jeres organisations navn og jeres ansvar, hvis den skader.

12. Led sundhedsapps gennem eksisterende assurance, og hold et kurateret, sikkert bibliotek. Vurdér digitale terapeutika gennem det samme maskineri, I allerede kører — DTAC som baseline, NICE Evidence Standards Framework afstemt med det kliniske krav og klinisk sikkerheds- og informationsstyringsgennemgang — og byg evalueringsevidens fra den virkelige verden over tid (se emne 8.6). Vedligehold et kurateret bibliotek af apps, I har assureret og står bag, med hver apps regulatoriske status, evidens og ejer registreret, så klinikere anbefaler fra en sikker, styret shortlist. Alternativet — en ukontrolleret uhæmmet vækst af uvurderede apps anbefalet uformelt på tværs af teams — er uhåndterbart og usikkert.

Spørgsmål at drøfte med dit team#

1. For hvert AI-værktøj, vi overvejer eller allerede bruger, ved vi så faktisk, om det er et reguleret medicinsk udstyr — og kan vi fremlægge evidensen? Det lyder som en compliance-formalitet, men det er det bærende spørgsmål, fordi svaret afgør, hvad der er lovligt, hvem der hæfter, og hvilken assurance I skylder offentligheden. Det er let at antage, at et værktøj, der "blot hjælper med triagering" eller "blot opsummerer notater", er harmløs administrativ software, når dets medicinske formål i virkeligheden gør det til et reguleret udstyr, der kræver MHRA-overensstemmelsesmærkning. Diskussionen bør tvinge jer til at nævne hvert AI-værktøj i brug eller i pipelinen, angive dets tilsigtede formål i klart klinisk sprog og identificere, hvem der traf klassifikationsafgørelsen og på hvilket grundlag. Den bør bringe de ubehagelige tilfælde frem, hvor et værktøj blev indkøbt gennem en almindelig it-vej uden nogen regulatorisk kontrol overhovedet. Vær ærlige om, hvorvidt I i dag kunne fremlægge overensstemmelsesdokumentationen og valideringsevidensen, hvis en regulator eller en retsmedicinsk undersøger spurgte. Samtalens værdi er, at den omsætter en vag fornemmelse af, at "nogen må have tjekket", til en dokumenteret, ejet position — og afslører de værktøjer, hvor ingen har.

2. Har vi krævet at se, hvordan denne model præsterer for de grupper, der er mest tilbøjelige til at blive skadet, eller har vi accepteret et overskriftsnøjagtighedstal? Gennemsnitlig nøjagtighed er det tal, leverandører leder med, og det tal, der skjuler algoritmisk bias, fordi en model kan være meget nøjagtig samlet set, mens den præsterer markant dårligere for en underrepræsenteret gruppe. I sundhed og pleje er det ikke en statistisk kuriositet; det er en mekanisme til at udvide de uligheder, I er juridisk og moralsk forpligtet til at reducere, anvendt i det stille og i skala. Teamet bør drøfte, hvilken undergruppeevidens I faktisk har set — ydelse opdelt efter alder, køn, etnicitet og afsavn — og om I ved, hvem der var i træningsdataene, og hvem der manglede. Det er værd at nævne ubehaget her: at presse en leverandør på fairness kan føles som at obstruere en spændende innovation, og det ærlige spørgsmål er, om I er villige til at sige nej til et værktøj, der ikke kan påvise retfærdig ydelse. Overvej også, hvordan I overhovedet ville opdage uretfærdige udfald efter udrulning, da bias, der var usynlig ved indkøbet, vil være usynlig i produktion, medmindre I overvåger for den. En god diskussion ender med en konkret evidensbarre for fairness, der gælder, før nogen klinisk AI går i drift, og en plan for at blive ved med at holde øje bagefter.

3. Når denne model tager fejl — og det vil den — hvem er så ansvarlig, vil et menneske reelt fange det, og hvordan ville vi overhovedet vide det? Hver model svigter undertiden, og lærende systemer kan drive ind i at svigte oftere over tid, så det modne spørgsmål er ikke om fejl opstår, men om jeres værn er ægte. Teamet bør teste, om menneske-i-løkken er meningsfuldt eller dekorativt: har klinikeren beføjelsen og informationen til at tilsidesætte, og hvis I så på tilsidesættelsesrater, ville I finde, at de nogensinde faktisk tilsidesætter, eller er automatiseringsbias slået ind? Drøft, hvem der er nævnt som ansvarlig for en beslutning, AI’en informerede — klinikeren, organisationen, leverandøren — for "algoritmen gjorde det" er ikke en forsvarlig position over for en patient eller en retsmedicinsk undersøger. Konfrontér jeres overvågning ærligt: har I overvågning efter markedsføring, der ville opdage konceptdrift, definerede tærskler for at sætte på pause eller trække modellen tilbage og MLOps-maskineriet til at vide, hvilken version der er i drift, og til at rulle den tilbage? For generative værktøjer, tilføj hallucinationsspørgsmålet — hvad forhindrer fabrikeret indhold i at komme ind i den kliniske journal, og hvem verificerer output, før det stoles på? Den mest nyttige version af denne samtale afslører hullet mellem det beroligende diagram over "menneskeligt tilsyn" og det, der faktisk ville ske klokken 3 om natten på en travl afdeling.

4. Hvad sker der med vores patienters data, når vi træner, finjusterer og kører disse modeller — og hvad har leverandøren forbeholdt sig ret til at gøre med dem? AI koncentrerer datastyringsrisiko netop fordi dataene er produktet: en model er kun så pålidelig som det lovlige grundlag, den minimering og den gennemsigtighed, der ligger bag hvert datasæt, den rørte, herunder de trænings- og evalueringsdata, der går forud for go-live. Teamet bør kunne angive, for hvert værktøj, det lovlige grundlag for enhver brug af patientdata, om de-identifikation er tilstrækkelig frem for blot påstået, og hvor dataene fysisk flyder hen, når de forlader jeres kontrol. En tilbagevendende fælde er kontrakten, der i det stille tillader leverandøren at genbruge jeres data til at forbedre produkter, den vil sælge til andre; drøft, om jeres aftaler forbyder det uden et lovligt grundlag og jeres eksplicitte samtykke, og om nogen faktisk har læst de klausuler. Det knytter sig direkte til jeres informationsstyringsramme (se emne 1.7), og det er, hvor begejstring for et kapabelt værktøj oftest løber fra due diligence. Et ærligt svar nævner, hvem der ejer DPIA’en, hvad leverandøren må og ikke må, og hvor I i dag er eksponerede — frem for at antage, at fordi demoen var imponerende, må papirerne være i orden.

5. Hvordan beslutter vi, hvad vi IKKE skal adoptere, og kan vi modstå presset for at købe det, alle er begejstrede for? Den sværeste styringsdisciplin med en hurtigt bevægende teknologi er at sige "ikke endnu" eller "ikke dette", og et team, der ikke kan formulere sine kriterier for at afslå, vil ende med at adoptere ved drift og hype frem for ved evidens. Drøft, hvad der ville få jer til at gå fra et ellers attraktivt værktøj — svag undergruppeevidens, uklar regulatorisk status, en anvendelse, hvor den realistiske gevinst er tynd i forhold til risikoen — og om de røde linjer er skrevet ned eller blot følt. Der er en reel spænding her mellem omkostningen ved at misse en ægte forbedring og omkostningen ved en skaleret fiasko, der skader offentlig tillid, og fornuftige mennesker vil veje dem forskelligt. Det er værd at nævne den politiske virkelighed, at presset for at adoptere ofte kommer fra en bestyrelse, et leverandørforhold eller et nationalt påbud, ikke fra det kliniske behov selv. Emnets holdning er at horisontscanne bevidst og indfase gennem kontrolleret, reversibel evaluering (se emne 8.0), så et ærligt svar beskriver, hvordan et lovende, men ubeviset værktøj kommer ind som et lille, målt, stoppebart pilotforsøg frem for en gennemgribende udrulning — og hvem der har beføjelsen til at stoppe det.

6. Kan vi forklare, hvad denne model gør, for de klinikere, der skal stole på den, og de patienter, den berører — og har vi været ærlige om dens grænser? En model, en kliniker ikke kan udspørge, og en patient ikke kan forstå, ætser den informerede dømmekraft og det informerede samtykke, klinisk pleje afhænger af, uanset hvor nøjagtig den er i aggregat. Teamet bør drøfte, hvor megen forklarbarhed netop denne anvendelse reelt kræver: et køprioriteringsværktøj kræver mindre end et værktøj, der påvirker en diagnose eller en behandlingsbeslutning, og at afstemme forklaringen med indsatsen er et styringsvalg, ikke en teknisk eftertanke. Overvej, hvad I fortæller de klinikere, der forventes at bruge den — dens formål, dens kendte fejlmønstre, de grupper, den er mindre pålidelig for — og om den briefing er åben eller et marketingresumé. Patientvendt ærlighed betyder også noget: får folk at vide, når AI er involveret i deres pleje, og i et sprog, de kan handle på? Det er også et arbejdsstyrkespørgsmål, fordi for lav tillid betyder, at et nyttigt værktøj ignoreres, mens for høj tillid producerer den automatiseringsbias, der udhuler tilsynet. Et ærligt svar konfronterer, om jeres uddannelse og kommunikation bygger kalibreret tillid eller blot sælger værktøjet.

I praksis: et eksempel fra sundhed og pleje#

Et integreret plejesystem tilbydes et AI-værktøj, der læser røntgenbilleder af thorax og markerer sandsynlige abnormiteter for at prioritere radiologiens beskrivelseskø. Den kliniske sikkerhedsansvarlige og den lægefaglige direktør modstår presset for at indkøbe det hurtigt og lader det i stedet gennemgå ordentlig styring.

Først klassificering: værktøjet har et klart medicinsk formål, så det bekræftes som Software as a Medical Device, og dets MHRA-overensstemmelsesmærkning og tilsigtede brugserklæring verificeres — den tilsigtede brug er triageringsstøtte, ikke autonom diagnose, hvilket former alt, hvad der følger. Dernæst assurance: værktøjet tages gennem DTAC som baseline, dets kliniske krav tjekkes mod NICE Evidence Standards Framework, en DCB0160 klinisk risikovurdering gennemføres, og en DPIA dækker billeddataene (se emne 1.6 og 1.7). Teamet beder om undergruppeydelse og opdager, at valideringsbefolkningen underrepræsenterede en lokal demografi; de kræver yderligere lokal validering før videre fremdrift og behandler potentiel bias som en sundhedsulighedsrisiko frem for en fodnote.

Ved udrulning bevarer designet et menneske i løkken: hvert billede beskrives stadig af en radiolog, og AI’en omordner kun køen, så en misset markering ikke i sig selv kan forårsage en misset diagnose. Overvågning efter markedsføring oprettes fra dag ét — overvågning af detektionsrater, uoverensstemmelse mellem modellen og de beskrivende radiologer og enhver drift, når scannerhardware og sagsmix ændrer sig — med forhåndsaftalte tærskler for at sætte værktøjet på pause og en tilbagerulningsvej gennem leverandørens versionerede udrulning. Separat, da en afdeling beder om at indsætte patienthistorier i en offentlig LLM for at udarbejde udskrivningsresuméer, siger det samme styringsforum nej til den ustyrede vej og bestiller i stedet et godkendt, indeholdt værktøj med menneskelig verifikation. Et år senere har køprioriteringsværktøjet beskedent forbedret beskrivelsesgennemløbstiden, dets overvågning har fanget én episode af drift efter en scanneropgradering, og — afgørende — organisationen kan vise præcis, hvordan det styres.

Sektorperspektiver#

Startup#

En digital sundhedsstartup er ofte AI’en, så dens styringsmodenhed er dens markedsadgang. Grundlæggere bør behandle regulatorisk klassificering, klinisk validering og biasevidens som kerneproduktarbejde, ikke en compliance-skat boltet på før et salg, fordi en købers kliniske sikkerhedsansvarlige vil spørge om netop disse, og et "nej" afslutter handlen. At engagere sig tidligt med MHRA — potentielt gennem mekanismer som AI Airlock for reelt nye spørgsmål — og designe til DTAC og NICE Evidence Standards Framework fra begyndelsen gør assurance til en konkurrencefordel. Den karakteristiske startuprisiko er overdrivelse: marketing, der løber fra evidensen, eller en demo af gennemsnitlig nøjagtighed, der skjuler dårlig undergruppeydelse. Den disciplinerede grundlægger bygger overvågning og overvågning efter markedsføring ind i produktet tidligt, fordi en enkelt skaleret fiasko på et referencested er en eksistentiel begivenhed for et lille firma.

Lille virksomhed#

En etableret lille udbyder — en lægepraksis, et lokalt apotek, et plejehjem, en enkelt klinik — er som regel en køber af AI snarere end en bygger, men bærer de samme pligter som et stort hospital uden de dedikerede kliniske sikkerheds-, informationsstyrings- eller informatikmedarbejdere til at opfylde dem. Den praktiske risiko er at adoptere et værktøj på en leverandørs forsikringer, fordi der ikke er intern kapacitet til at kræve enhedsklassificering, undergruppeevidens eller en DPIA, og ingen til at bemærke, når en model driver. Læn jer kraftigt op ad den assurance, andre allerede har udført: foretræk værktøjer, der klart har MHRA-overensstemmelsesmærkning og har bestået DTAC, køb fra leverandører, der offentliggør deres evidens, og anbefal sundhedsapps kun fra et kurateret bibliotek, jeres ICS eller et nationalt organ har assureret, frem for selv at vurdere hver enkelt. Hvor I ikke personligt kan verificere et værktøjs sikkerhed, er det en grund til at henholde jer til jeres systems fælles assurance, ikke til at springe tjekket over. At holde selv et let register over, hvilke AI-værktøjer I bruger, til hvad og hvem der ejer dem, gør en uhåndterbar pligt proportional.

Stor virksomhed#

Et stort hospital eller ICS har apparatet til at styre AI ordentligt og den skala, der gør det alvorligt at tage fejl. Dets opgave er at udvide eksisterende kliniske sikkerheds-, informationsstyrings- og assurancefunktioner til at dække AI — et modelregister, fairness-barrierer for undergrupper, overvågning efter markedsføring, MLOps til versionering og tilbagerulning — frem for at lade AI ankomme gennem ugranskede it- eller forskningsveje. Virksomhedens reelle fare er fragmentering: dusinvis af pilotforsøg, ambient-skriver-forsøg og afdelings-LLM-eksperimenter, der formerer sig uden central fortegnelse, uden konsistent DPIA og uden nogen ansvarlig, når et værktøj driver. Forandringstræthed og leverandørpres skubber mod hurtig adoption, så ledelsen må holde linjen om, at nyhed ikke fortjener en lettere proces. Gjort godt kan virksomheden også generere den prospektive, lokale valideringsevidens, mindre aktører ikke kan, og dele den på tværs af systemet.

Myndighed#

Nationale og lokale offentlige organer — MHRA, NHS England, DHSC, NICE, delegerede administrationer og lokale myndigheder — fastsætter de betingelser, hvorunder alle andre udruller AI. Deres instrumenter er regulering, standarder, assurancerammer (DTAC, Evidence Standards Framework), safe harbour-mekanismer som AI Airlock og den finansiering og vejledning, der styrer sikker adoption på tværs af et føderalt system, de ikke direkte linjeleder. Ansvaret går til ministre, parlamentet og offentligheden, så en skaleret AI-fiasko eller en påviselig bias i et nationalt værktøj er en offentlig tillidsbegivenhed med en lang skygge. Statens rette rolle er at gøre den sikre vej til den nemme vej — klare regler, genanvendelig assurance, ærlig offentlig kommunikation om, hvad AI kan og ikke kan — mens den modstår både hypedrevne påbud og refleksmæssigt forbud. At få balancen forkert i begge retninger koster år af tillid.

Typiske fejlmønstre#

• At springe regulatorisk klassificering over. At udrulle en klinisk AI, som var den almindelig software. Undgå det ved at fastslå udstyrsstatus og overensstemmelsesmærkning først, med regulatorisk input.
• Overskriftsnøjagtighedsblindhed. At acceptere et gennemsnitstal, der skjuler dårlig ydelse for underrepræsenterede grupper. Undgå det ved at kræve undergruppeevidens før go-live og overvåge for ulighed bagefter.
• Valider én gang, glem for evigt. At behandle go-live som slutningen på assurance, mens modellen i det stille driver. Undgå det ved at oprette overvågning efter markedsføring med tærskler og tilbagerulning.
• Dekorativt menneskeligt tilsyn. Et "menneske i løkken", der gummistempler under automatiseringsbias. Undgå det ved at revidere tilsidesættelsesrater og designe reel beføjelse til at gribe ind.
• Ustyret generativ AI. Personale der indsætter patientdata i offentlige LLM’er og stoler på fabrikeret output. Undgå det ved klar politik plus et godkendt, indeholdt værktøj med menneskelig verifikation.
• Parallel letvægtsproces. At lade AI omgå klinisk sikkerhed og informationsstyring, fordi det er "innovation". Undgå det ved at udvide eksisterende DCB- og DPIA-maskineri til AI.
• Ingen fortegnelse. Ingen ved, hvilke modeller der er i drift, på hvilke data, ejet af hvem. Undgå det ved at vedligeholde et modelregister.

Modenhedsmodel#

Tjekliste#

• Hvert AI-værktøjs status som medicinsk udstyr og MHRA-overensstemmelsesmærkning er fastslået og dokumenteret.
• Klinisk AI har bestået DTAC, er tjekket mod NICE Evidence Standards Framework og har en DCB klinisk risikovurdering og en DPIA.
• Undergruppeydelse (alder, køn, etnicitet, afsavn) er set og opfylder en aftalt fairness-barre.
• Klinisk validering matcher risikoniveauet og foretrækker prospektiv, lokal evidens.
• Et meningsfuldt menneske-i-løkken er designet, med beføjelse og information til at tilsidesætte.
• Navngivet ansvar for AI-informerede beslutninger er skrevet ned.
• Overvågning efter markedsføring, driftstærskler og en pause-/tilbagerulningsplan er i drift fra go-live.
• MLOps giver modelversionering og sikker tilbagerulning; den aktuelle version er altid kendt.
• Politik for generativ AI tillader realistiske anvendelser, forbyder patientdata i ustyrede tjenester og kræver menneskelig verifikation.
• Informationsstyring dækker trænings-, finjusterings- og evalueringsdata, med kontraktlige grænser for leverandørens genbrug.
• Et menneskelæseligt modelregister registrerer formål, proveniens, evidens, overvågning og ejer.
• Fremvoksende teknologier horisontscannes og indfases gennem kontrolleret, reversibel evaluering.

Centrale kilder#

• MHRA — Software and Artificial Intelligence (AI) as a Medical Device og den regulatoriske sandkasse AI Airlock (gov.uk).
• NICE — Evidence Standards Framework (ESF) for digitale sundhedsteknologier (nice.org.uk).
• NHS England — Digital Technology Assessment Criteria (DTAC) til baseline-assurance af digitale sundhedsteknologier.
• NHS England / tidligere NHSX — A Buyer’s Guide to AI in Health and Care og AI Ethics Initiative.
• DCB0129 og DCB0160 — kliniske risikostyringsstandarder for sundheds-it (se emne 1.6).
• MHRA / IMDRF — Software as a Medical Device (SaMD)-rammen og god praksis for maskinlæring.
• The King’s Fund og the Health Foundation — analyse af AI, data og uligheder i sundhed og pleje.
• Se også emne 1.3 — Evidensbaserede beslutninger; emne 1.6 — Klinisk sikkerhed og risikostyring; emne 1.7 — Informationsstyring, databeskyttelse og cybersikkerhed; emne 8.0 — Indfasning af innovation.

Referencer#

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