AI validering i life science efter EU AI Act 2026

Ja. Hvis jeres AI påvirker patientsikkerhed, produktkvalitet eller dataintegritet, skal den valideres efter GAMP 5 kategori 5 samt IEC 62304 og ISO 13485 hvor det er relevant, og den skal opfylde EU AI Act for højrisiko AI fra 2. august 2026. Det kræver skriftlige krav, risikostyring, dokumenterede træningsdata efter ALCOA+, test for bias og en fast plan for drift og retraining.

Timingen er perfekt nu, fordi tre regelsæt mødes på samme tid. EU AI Act trådte i kraft 1. august 2024 og fases ind frem mod 2026 og 2027. MDR og IEC 62304 gælder stadig for medicinsk software. Samtidig køber mange danske pharma og medico teams AI komponenter som API, model eller copilot funktion uden en valideringsplan, og det giver observationspunkter ved inspektion. Den gode nyhed er, at GAMP 5 allerede giver jer strukturen til at håndtere AI, hvis I behandler modellen som det, den er: specialudviklet logik med data som råvare.

Hos QualiPartner bygger vi pharma og medico software der er validatorbar fra første linje, og vi ser det samme mønster hos kunderne: AI delen er købt hurtigt, mens kravene, dataene og testene mangler. Denne artikel giver jer en praktisk vej fra EU AI Act til valideret drift.

Hvad kræver EU AI Act for højrisiko AI?

EU AI Act stiller krav om risikostyring, datakvalitet, teknisk dokumentation, logning, gennemsigtighed, menneskeligt tilsyn og robusthed for højrisiko AI systemer. For life science teams er det afgørende at forstå, at EU AI Act kommer oven på GxP, ikke i stedet for GxP.

Fakta om tidsplanen, som I skal planlægge efter: EU AI Act trådte i kraft 1. august 2024. Forbudte AI metoder har været forbudt siden 2. februar 2025. Forpligtelser for modeller til generelle formål har været gældende siden 2. august 2025. Krav til højrisiko AI systemer finder anvendelse fra 2. august 2026. Udvalgte højrisiko systemer under bilag 2 samt visse gennemsigtighedskrav får virkning frem mod 2. august 2027. Kilde: EU Kommissionen.

Højrisiko AI i life science er typisk AI der indgår som sikkerhedskomponent, eller AI der er omfattet af MDR (EU) 2017/745 og kræver tredjepartsvurdering. Eksempler er AI til triage, diagnostisk beslutningsstøtte, dosisberegning, kvalitetsafvigelser i produktion og frigivelse af batch. Hvis jeres AI kun skriver udkast til en SOP som et menneske godkender med fuld kontrol, er risikoklassen ofte lavere, men dokumentationspligten forsvinder ikke, når output kan påvirke GxP data.

Det betyder konkret tre ting for jer i 2026. For det første skal I klassificere jeres AI skriftligt: er den højrisiko efter EU AI Act, er den medicinsk software efter MDR, og hvilken IEC 62304 klasse har den. For det andet skal I kunne vise data governance: hvor kommer træningsdata fra, hvor repræsentative er de, og hvordan måler I bias. For det tredje skal I kunne vise kontrol i drift: logning af input og output, menneskeligt tilsyn, afvigelseshåndtering og plan for retraining. Det er samme tankegang som CSV-validering efter GAMP 5, blot med data og modeladfærd som nye testobjekter.

En typisk fejl er at tro, at CE mærkning efter MDR dækker EU AI Act. Det gør den ikke alene. I skal opfylde begge regelsæt og vise sporbarhed mellem dem, så en inspektør kan følge krav fra MDR og EU AI Act ned til test.

Hvordan validerer man en AI komponent efter GAMP 5 kategori 5?

Man validerer en AI komponent som GAMP 5 kategori 5, fordi modellen er specialudviklet logik med høj risiko. Kategori 5 kræver fuld livscyklus med krav, specifikationer, risikobaseret test og sporbarhed. Købte API og biblioteker indgår som leverandørdokumentation, men de fritager jer ikke for validering af jeres egen anvendelse.

Start med afgrænsning og risikovurdering. Beskriv intended use i én sætning: hvad gør modellen, for hvem, med hvilke input, og hvad sker der ved forkert output. Klassificer softwaren efter IEC 62304 klasse A, B eller C. Klasse A betyder at ingen skade er mulig ved fejl. Klasse B betyder at ikke alvorlig skade er mulig. Klasse C betyder at død eller alvorlig skade er mulig. De fleste GxP relevante AI funktioner ender i klasse B eller C, og det styrer testdybden. Knyt risikovurderingen til ISO 13485 processer, hvis I udvikler medicinsk udstyr, så designkontrol, leverandørstyring og CAPA hænger sammen.

Skriv derefter URS, FS og DS som ved al anden kategori 5 validering. URS beskriver forretningskrav og regulatoriske krav, inklusiv krav fra EU AI Act om datakvalitet, logning og menneskeligt tilsyn. FS beskriver funktionen, inklusiv modelversion, tærskelværdier, inputformat og fejlhåndtering. DS beskriver designet, inklusiv datapipeline, preprocessing, modelarkitektur, infrastruktur og audit trail. Uden disse tre dokumenter kan I ikke lave en troværdig sporbarhedsmatrix, og uden sporbarhed dumper valideringen ved audit.

Test i IQ, OQ og PQ med AI specifikke tilføjelser. IQ verificerer installation og versioner: modelversion, kodeversion, dataversion, container og parametre. OQ udfordrer funktionen med grænsetilfælde, ugyldig input, manglende felter og tiltænkt misbrug. PQ tester i produktionslignende data med foruddefinerede acceptkriterier for nøjagtighed, sensitivitet, specificitet eller anden relevant metrik. Fastlås testdata før PQ, så ingen kan tune modellen mod testen. Gem seeden, versionen og datasættets hash, så testen kan reproduceres.

Leverandørens rolle skal være skriftlig. Hvis I bruger en ekstern model eller platform, skal I lave leverandørkvalificering med spørgeskema, audit hvor risikoen kræver det, aftale om ændringsvarsling og adgang til relevante optegnelser. Efter IEC 62304 håndteres tredjepartssoftware som SOUP, altså software af ukendt oprindelse, med krav til identifikation, risikovurdering og vedligehold. Efter GAMP 5 vurderer I om leverandørens test kan genbruges som løftestang, men jeres PQ på egne data er altid jeres eget ansvar. Det er her mange teams sparer forkert: de genbruger leverandørens marketing benchmarks i stedet for at teste på danske produktionsdata.

Læs hvordan vi strukturerer valideringsplan, sporbarhed og IQ OQ PQ, så AI valideringen passer ind i jeres eksisterende kvalitetssystem i stedet for at leve som et sideprojekt.

Hvad gør I med bias og drift i valideret AI?

I behandler bias som en valideret egenskab og drift som en styret ændring. Bias testes før frigivelse. Drift overvåges i drift og udløser CAPA eller revalidering efter faste grænser. Uden de to elementer er AI validering kun et øjebliksbillede.

Bias opstår når træningsdata ikke matcher den population eller proces, som modellen bruges på. I pharma kan det være batch typer, udstyr, operatører, sprog i afvigelsesrapporter eller patientgrupper. Test derfor stratificeret: opdel testdata efter køn, alder, lokation, udstyrstype, batch størrelse eller anden relevant faktor, og rapporter performance per gruppe, ikke kun samlet nøjagtighed. En samlet nøjagtighed på 96 procent kan skjule 78 procent på en lille men kritisk undergruppe. Fastlæg acceptkriterier for minimumsperformance per gruppe i URS, så testen ikke bliver pynt.

Et konkret eksempel: en model der læser afvigelser og foreslår CAPA kategori kan virke stærk på historiske data fra ét site, men fejle på et andet site med anden skrivestil. Løsningen er at inkludere data fra alle sites i testdata, at teste per site og at kræve menneskelig godkendelse indtil per site kriterierne er opfyldt. Dokumenter beslutningen i risikovurderingen med henvisning til patientsikkerhed og datapålidelighed.

Drift betyder at modellens input eller performance ændrer sig over tid. Datadrift er ændrede input, for eksempel nye råvarer, nye sensorer eller ændret sprogbrug. Modeldrift er faldende performance, for eksempel flere falske afvigelser. Definér derfor overvågning fra dag ét: hvilke metrikker logges, hvor ofte de reviewes, og hvilke grænser der udløser handling. Typisk overvåger man fordeling af input, andel af afviste forslag, manuel override rate og periodisk stikprøve mod ground truth.

Fastlås også retraining politikken. Retraining er en ændring under change control, ikke rutinedrift. Beskriv hvornår I må retraine, hvilke data der må indgå, hvordan I versionerer model og data, og hvornår der kræves revalidering. Mindre datatilførsel uden arkitekturændring kan ofte håndteres med afgrænset revalidering og opdateret valideringsrapport. Ny anvendelse, nye inputtyper eller ny tærskel kræver fuld påvirkningsvurdering. Skriv det ind i jeres pharma software vedligeholdelsesproces, så driftsteamet ikke står med en sort boks efter projektet.

For højrisiko AI kræver EU AI Act desuden løbende overvågning efter ibrugtagning, inklusiv rapportering af alvorlige hændelser. Kobl den overvågning til jeres eksisterende afvigelses og CAPA proces, så der kun findes ét system for fejl, uanset om fejlen kommer fra mennesker, software eller model.

Hvordan dokumenterer man træningsdata og ALCOA+?

Man dokumenterer træningsdata som GxP rådata med identitet, version, oprindelse og audit trail, og man tester hvert datasæt mod ALCOA+. Hvis træningsdata ikke er troværdige, er modellen ikke valideret, uanset hvor pæn testrapporten ser ud.

ALCOA+ står for Attributable, Legible, Contemporaneous, Original, Accurate plus Complete, Consistent, Enduring og Available. På dansk bruges principperne direkte som designcheck for dataintegritet: data skal kunne knyttes til kilde og person eller system, være læsbare, være registreret samtidig med hændelsen, være originale, være korrekte, samt være komplette, konsistente, bevarede og tilgængelige. Kilde: EudraLex bind 4 kapitel 4 og bilag 11 samt ISPE GAMP vejledninger.

Oversæt det til en datasæt specifikation med mindst disse felter: datasættets navn og version, hash eller anden entydig identitet, kilde systemer, udtræksdato og forespørgsel, inklusions og eksklusionskriterier, anonymisering eller pseudonymisering, kendte mangler, annoteringsprocedure og annotatør kvalifikation, opdeling i træning, validering og test, samt godkendelse. Gem den præcise kode til preprocessing sammen med dataene, så datasættet kan genskabes. Uden versioneret datasæt kan I ikke bevise hvad modellen faktisk lærte af.

Audit trail skal dække hele kæden: hvem udtrak data, hvornår, fra hvilket system, hvad blev ændret under rensning, hvem annoterede, hvem godkendte, hvilken modelversion der blev trænet, og hvilke hyperparametre der blev brugt. Brug systemkonti med unikke brugere, tidsstempler fra synkroniseret tid og beskyttede logfiler. Regneark som mellemlager uden adgangskontrol og versionsstyring er en klassisk audit observation, så flyt dataklargøring ind i et styret miljø med samme adgangskontrol som jeres øvrige GxP data.

Håndter persondata og samtykke særskilt. Mange træningsdata indeholder patientdata eller medarbejderdata og er derfor omfattet af GDPR samt lokale procedurer. Dokumenter retsgrundlag, opbevaringsperiode og adgangsbegrænsning, og vis at testdata er adskilt fra træningsdata uden lækage. Hvis I ikke kan vise adskillelsen, kan I ikke forsvare PQ resultaterne.

Det er også her leverandør AI ofte fejler i praksis. Leverandøren oplyser ikke træningsdata, eller dataene må ikke bruges til jeres formål. Løsningen er at kræve en datakortlægning i kontrakten, at teste leverandørmodellen på egne validerede data og at logge produktionsdata til fremtidig dokumentation. Hvis leverandøren opdaterer modellen uden varsel, skal jeres change control fange det via versionsovervågning og fastlåste endpoints. Se vores tilgang til validatorbar arkitektur og audit trail som designmønster, som gør denne dokumentation billigere at vedligeholde.

Hvad er en realistisk plan for danske teams i 2026?

En realistisk plan tager 6 til 12 uger for én AI funktion i et eksisterende kvalitetssystem og giver jer en valideret version 1 plus en driftsaftale. Større medicinsk software i IEC 62304 klasse C tager længere, men strukturen er den samme.

Uge 1 til 2: klassifikation og risikovurdering. Afgør EU AI Act klasse, MDR status og IEC 62304 klasse A, B eller C. Skriv intended use og acceptkriterier. Gennemgå leverandører og SOUP liste. Resultat er en risikorapport der styrer testdybden.

Uge 3 til 5: krav og data. Skriv URS, FS og DS. Fastlås datasæt specifikation med ALCOA+ vurdering. Byg audit trail og logning ind i arkitekturen. Fastlæg bias test per undergruppe og drift metrikker med grænser.

Uge 6 til 9: byg, test og dokumentér. Gennemfør IQ og OQ. Kør PQ på låste testdata. Dokumenter afvigelser og ret dem med CAPA. Skriv sporbarhedsmatrix fra krav til test.

Uge 10 til 12: frigivelse og drift. Skriv valideringsrapport. Træn superbrugere i menneskeligt tilsyn og override. Sæt periodisk review, for eksempel hvert kvartal det første år, samt procedure for retraining og hændelsesrapportering efter EU AI Act.

Start nu frem for at vente på 2. august 2026, fordi dataindsamling tager længst tid. Teams der mangler stratificerede testdata eller versionsstyring opdager det først ved PQ, og så koster forsinkelsen dyrt. En risikovurdering på 1 til 2 dage afklarer omfanget, før I binder budget til fuld validering.

Ofte stillede spørgsmål

Skal al AI i pharma valideres efter GAMP 5 kategori 5?

Nej, men det meste GxP relevante AI ender der. Hvis AI output kan påvirke patientsikkerhed, produktkvalitet eller dataintegritet, skal det valideres, og specialudviklede modeller hører hjemme i kategori 5 med fuld livscyklus. Rene infrastrukturkomponenter eller simple konfigurerbare værktøjer uden specialkode kan valideres i lavere kategori, men jeres egen anvendelse, data og tærskler skal stadig testes og dokumenteres.

Gælder EU AI Act også når vi kun bruger en leverandørs AI API?

Ja, hvis I er udbyder eller driftsansvarlig for et højrisiko system i EU. Leverandørens dokumentation hjælper, men ansvaret for klassifikation, datakvalitet, menneskeligt tilsyn, logning og overvågning efter ibrugtagning ligger hos jer som driftsansvarlig for jeres anvendelse. Fastlås modelversion, test på egne data og kræv varsling ved modelændringer i kontrakten.

Hvad udløser revalidering af en AI model?

Ny træningsdata med ændret fordeling, ny modelarkitektur, nye inputtyper, ændrede tærskler, ny intended use, ny infrastruktur eller målt drift over den fastlagte grænse. Hver ændring vurderes under change control med påvirkningsvurdering, og omfanget af revalidering fastlægges ud fra risiko. Ren genkørsel af samme version på samme data udløser ikke revalidering, men skal stadig logges.

Kan vi bruge produktionsdata til træning og test?

Kun med styring. Produktionsdata skal udtrækkes med sporbar forespørgsel, versioneres med hash, vurderes efter ALCOA+, renses for persondata efter GDPR og opdeles så testdata er låste og adskilte fra træning. Genbrug af de samme data til både træning og PQ invaliderer testen. Planlæg datasættet tidligt, da det ofte er den længste aktivitet i projektet.

Kilder

EU Kommissionen: Forordning (EU) 2024/1689 om kunstig intelligens, ikrafttræden 1. august 2024 med fasevis anvendelse i 2025, 2026 og 2027. ISPE: GAMP 5 2. udgave samt GAMP vejledning for kunstig intelligens og maskinlæring. EudraLex bind 4: kapitel 4 om dokumentation, bilag 11 om computeriserede systemer og MDR (EU) 2017/745 for medicinsk software. IEC 62304 for medicinsk software livscyklus med klasse A, B og C samt ISO 13485 for kvalitetsledelse.

Vil I have AI valideringen på plads før 2. august 2026, så start med klassifikation og data. Vi hjælper med CSV-validering fra plan til rapport og med at bygge validatorbar pharma software hvor EU AI Act, GAMP 5, IEC 62304 og ALCOA+ er tænkt ind fra start.