Test af AI-baserede systemer – teknikker, udfordringer og retningslinjer

1. dec.

Af: Ole Chr. Hansen, Q Nation A/S

Indledning

Kunstig intelligens (AI) er i dag integreret i mange systemer, fra avancerede maskinlæringsmodeller til simple regelbaserede rutiner. At teste AI-baserede systemer er afgørende for at sikre kvalitet, pålidelighed og ansvarlig brug. Samtidig indebærer AI helt særlige udfordringer for testteams: systemerne kan opføre sig ikke-deterministisk, de kan være trænet på data med indbygget bias, de fungerer ofte som “black-box” uden let forklarlige beslutninger, og nogle modeller lærer løbende, så deres adfærd ændrer sig over tid. Traditionelle testmetoder skal derfor suppleres med nye teknikker målrettet AI for at imødegå disse udfordringer.

Denne artikel gennemgår både klassiske testteknikker og nyere AI-specifikke testmetoder. For hver teknik beskrives testdesign, metoder og typiske anvendelsesområder. Artiklen belyser også de særlige udfordringer, risici og faldgruber ved AI-test – herunder håndtering af non-determinisme, data-bias, manglende forklarlighed og kontinuerlig læring. Endelig inddrages relevante standarder og regulativer (bl.a. ISO/IEC 29119, ISO/IEC 42001 og EU’s AI-forordning) sammen med overvejelser om compliance, governance og etik. Formålet er at give testmanagere og testanalytikere et sammenhængende overblik og praktiske råd til kvalitetssikring af AI-systemer.

Klassiske testteknikker anvendt på AI-systemer

AI-systemer skal grundlæggende gennemgå mange af de samme testdiscipliner som traditionel software. Klassiske testteknikker kan og bør anvendes, omend med tilpasninger til AI’s særpræg. Nedenfor gennemgås fire velkendte teknikker – eksekveringsbaseret test, A/B-test og modelbaseret test – med fokus på deres brug i AI-sammenhæng.

Dynamisk test

Black-box test indebærer at udføre systemet med forskellige input og sammenligne de faktiske outputs med forventede outputs. Det er den klassiske “kør og verificér”-tilgang, som omfatter funktionelle tests, integrationsprøver, systemtests m.m. I AI-kontekst bruges denne teknik til at validere, at AI-komponenten leverer rimelige resultater for en række testcases. For regelbaserede AI-systemer (f.eks. ekspertsystemer) eller ML-modeller i velafgrænsede domæner kan man nogle gange udlede forventede outputs til specifikke input og dermed udføre traditionel verifikation.

Testdesign: Man udarbejder testcases baseret på krav eller kendte scenarier. Klassiske testdesign-teknikker som ækvivalensklasser og grænseværdianalyse kan anvendes, hvor det giver mening. For eksempel kan et AI-system til kreditvurdering testes med input der repræsenterer forskellige låntagerprofiler (høj/lav indkomst, forskellige alder osv.) for at se om systemets output (f.eks. “godkendt”/“fejlet”) stemmer overens med forretningsreglerne. Hvis der findes resultatdata (f.eks. en valideret testdataset med korrekte svar), kan traditionel nøjagtighedsmåling benyttes: man sammenligner modellens output med de rigtige labels og sikrer, at den opfylder kravene til præcision.

Anvendelse og begrænsninger: Eksekveringsbaseret test er uundværlig for at opdage åbenlyse fejl og verificere kendt funktionalitet. Testere kan behandle AI-komponenten som en black-box og tjekke om input-output-forholdet giver mening. Dog støder man hurtigt på oracle-problemet i mange AI-tilfælde: det kan være svært at vide, hvad det korrekte output bør være for et vilkårligt givent input. Moderne AI-modeller kan tage komplekse beslutninger, hvor selv eksperter er i tvivl om “facit”. ISO’s AI-teststandard peger netop på dette testorakel-problem som en hovedudfordring ved AI-test – testere kan have svært ved at fastlægge forventede resultater og dermed afgøre, om testen er bestået. Derfor suppleres eksekveringsbaserede tests ofte med de nyere teknikker beskrevet senere (som metamorfiske tests). Desuden kan AI-systemer være non-deterministiske, så gentagne eksekveringer med samme input kan variere – her må man i stedet for et fast forventet output arbejde med statistiske eller tolerancebaseredeassertions (f.eks. “95% af gangene skal systemet levere en klassifikation i kategori X”).

A/B-test (eksperimenter i drift)

A/B-test er en teknik hvor to versioner af et system sammenlignes ved at lade en brugerpulje interagere med enten version A eller version B og måle forskelle i deres præstation eller brugeradfærd. Denne metode er særlig udbredt ved online eksperimenter og er højrelevant for AI, især når nye ML-modeller skal rulles ud. Typisk laves en kontrolleret eksperimentel sammenligning: en ny model (B) køres parallelt med den gamle model (A) på en andel af live-trafikken eller brugerne, hvorefter man ser om B leverer forbedrede resultater (eller eventuelle negative effekter) i forhold til A.

Testdesign: Nøglen til A/B-test er at definere klare metriker man vil optimere eller overvåge. For en AI-baseret anbefalingsmotor kan metrikken f.eks. være klikrate eller konverteringsrate; for en sprogmodel kan det være brugerbedømt svar-kvalitet. Man udvælger derefter en repræsentativ prøve af brugere eller inputdata, og fordeler tilfældigt, hvem der får hvilken version. Begge versioners output logges og analyseres statistisk. Testperioden skal være tilstrækkelig til at få signifikante resultater, og man skal på forhånd have fastlagt succeskriterier (f.eks. “den nye model skal forbedre konverteringsraten med mindst 2% uden at øge fejlrate”). A/B-test er således en eksperimentel testmetode, der ofte kræver samarbejde mellem test, drift og data science teams.

Anvendelse: A/B-tests bruges mest i sen testfase eller i produktion, når man vil validere en AI-models effekt i den virkelige verden. Det er oplagt ved løbende ML-opdateringer – f.eks. en webshop der jævnligt træner sin anbefalingsmodel på nye data vil A/B-teste den nye model mod den eksisterende før fuld udrulning. Teknikken kan afsløre om modellen faktisk forbedrer brugeroplevelsen eller forretningsmål, og samtidig om der opstår uønskede bivirkninger (f.eks. bias mod en brugergruppe). EU’s AI-forordning stiller krav om løbende overvågning og test af visse højrisiko AI-systemer, bl.a. via post-market monitoring, netop for at fange eventuelle performanceændringer under virkelige forhold. A/B-test i produktion understøtter dette ved at give data om modeldrift og generaliseringsevne i praksis. Vær dog opmærksom på etik og brugerimpact: for højrisiko systemer (f.eks. medicinsk diagnose-AI) kan man ikke blot eksperimentere frit på brugere uden kontrol – her skal A/B-forsøg designes meget omhyggeligt eller udføres i simulerede omgivelser af hensyn til sikkerhed og compliance.

Modelbaseret test

Modelbaseret test (MBT) går ud på at opbygge en model af systemets forventede opførsel eller omgivelser, og dernæst generere testcases automatisk fra denne model. Modellen kan være en formel specifikation (f.eks. en UML-tilstandsmaskine, beslutningstabel eller en matematisk model), som repræsenterer kravene til systemet. For AI-systemer kan MBT anvendes på to måder:

Modellering af miljøet eller usecases: Hvis AI’en indgår i et større system (f.eks. en robot eller en selvkørende bil), kan man lave en simulationsmodel af omgivelserne og mulige scenarier. Herefter genereres testforløb der udsætter AI’en for forskellige situationer. Et eksempel er simulering af trafikscenarier for en selvkørende AI: Ved at modellere vejkryds, fodgængere, vejrforhold osv. kan MBT værktøjer generere hundredevis af scenarier (testcases) og afvikle dem i en simulator for at se, hvordan AI’en reagerer.
Modellering af AI’ens logik på højt niveau: I nogle tilfælde kan man forsøge at beskrive, hvad AI’en burde gøre under givne omstændigheder, selv om den indre løsning er kompleks. For et regelbaseret system kan modellen reelt være selve regeldokumentationen. F.eks. kunne en talegenkendelses-AI modelleres som en tilstandsgraf med stier for støj, dialekter osv., og MBT kunne sikre, at tests dækker alle tilstande (f.eks. “høj baggrundsstøj” som én tilstand, “stærk accent” som en anden).

Testdesign: Man skal først have en abstrakt model klar. For dynamiske miljøer bruges ofte eksisterende simuleringsrammer eller digital twins. Testdesignværktøjer kan herefter gennemløbe modellens stater og overgange for at generere testcases der kommer rundt i hjørnerne. Modelbaseret test er godt til at skabe en systematisk og bred dækning af mulige situationer – noget der er svært ved rent manuelle tests, især når inputrummet er stort (hvilket er typisk for AI).

Anvendelse: MBT er velegnet i komplekse, dynamiske domains, typisk hvor AI’en styrer fysiske processer eller sekventielle beslutninger. Eksempler:

Robotter og autonome agenter: Man kan modellere forskellige tilstande af omgivelserne og missioner, og teste om agenten (med AI-styring) træffer korrekte valg i hver situation.
Dialogsystemer: For en AI-chatbot kan man lave et tilstandsdiagram af bruger- og dialogforløb, og autogenerere dialogtests for at se om bot’en håndterer alle forventede henvendelser korrekt.
Software med ML-komponent: Hvis en softwarefunktion bruger ML til en delopgave, kan man modellere den omgivende logik og dens interaktion med ML-output. MBT kan så teste integrationen – f.eks. at systemet går i den rigtige tilstand selv hvis ML’en mis-klassificerer noget.

MBT’s styrke er at den finder kombinationer og sekvenser af events, som man måske ikke selv ville tænke på. Den er dog afhængig af, at man rent faktisk kan opstille en nogenlunde dækkende model af forventet adfærd – hvilket er svært for visse AI’er. Oftest bruges MBT derfor i kombination med andre tests for at sikre brede scenariedækning, mens selve AI’ens indre kvalitet så må testes med andre metoder (f.eks. metamorfiske eller adversarielle tests).

Nye testmetoder målrettet AI

Ud over at tilpasse de klassiske metoder som ovenfor, er der udviklet nye testtilgange specifikt for AI. Disse adresserer problemer som manglende orakler, robusthed over for angreb, fairness og forklarlighed. Nedenfor beskrives fire fremtrædende teknikker: metamorfisk test, fairness-/bias-test og forklarlighedstest.

Metamorfisk test

Metamorfisk test er en metode udviklet til situationer, hvor man ikke kan definere et entydigt forventet resultat for et enkelt testinput. I stedet tester man, om systemet bevarer forudbestemte relationer mellem input og output, når input ændres på bestemte måder. Man udnytter altså kendte egenskaber ved problemdomenet til at formulere metamorfiske relationer.

Testdesign: Først identificeres nogle relationer eller invariants, som output bør opfylde, når input modificeres. Eksempler på metamorfiske relationer:

For en billedklassificeringsmodel kunne en relation være translations-invarians: hvis et billede forskydes en smule eller beskæres marginalt, bør modellens klassifikation forblive den samme.
For et spamfilter kunne en relation være ordrækkefølge-uafhængighed: to emails med samme ord blot i forskellig rækkefølge bør give samme spam/non-spam resultat.
For en ruteplanlægnings-AI kunne det være monotoniegenskab: hvis man forkorter afstanden mellem to punkter, må den beregnede rejsetid ikke blive længere end før.

Når relationerne er defineret, designes testcases i par eller grupper: Man giver AI’en et basisinput, noterer output, og konstruerer så afledte input (ved at ændre basisinput i henhold til en metamorfisk relation). Derefter kontrolleres om outputs opfylder den forventede relation. Hvis relationen brydes, indikerer det en fejl. Bemærk at man her tester konsistens og logik frem for nøjagtighed mod en gold standard.

Anvendelsesområder: Metamorfisk test er værdifuldt når testoraklet mangler – dvs. almindeligt for komplekse ML-modeller. Teknikken adresserer netop orakel-problemet i ML ved at definere relationer mellem flere testkørsler frem for at kræve kendskab til det korrekte svar på forhånd. Det bruges f.eks. i:

Billed- og signalbehandling: test af klassifikatorers robusthed over for rotation, skalering, lysstyrkeændringer mm.
Vidensbaserede systemer: tjekke at symmetrier eller transitiviteter i vidensdomænet holdes.
Komplekse beregningsmodeller: hvor man kender visse sammenhænge (f.eks. hvis input øges, skal output ikke falde – en monoton relation).

Metamorfisk test har afsløret mange fejl i ML-modeller, som traditionelle tests ikke fangede. F.eks. kan en billedgenkendelsesmodel give korrekt resultat på et klart billede af en kat, men fejle hvis billedet er svagt forskudt – et brud på metamorfisk invariant antyder, at modellen ikke generaliserer logisk. Man skal dog nøje vælge relevante relationer; ikke alle relationer er sande for alle modeller. Der er også kommet udvidelser som statistisk metamorfisk test, hvor man håndterer model-randomness ved at gentage test og bruge hypotesetest for at se om relationen overholdes i gennemsnit.

Kort sagt giver metamorfisk test en struktur til at teste det uforudsigelige: i stedet for at spørge “gav modellen det rigtige svar?”, spørger man “opfører modellen sig på en konsistent og forventelig måde, når vi laver veldefinerede ændringer i input?”. Det gør det muligt at teste AI-systemer selv når facit ikke er kendt.

Fairness- og bias-test

En af de største bekymringer omkring AI er potentialet for biased eller uretfærdige beslutninger. Fairness-test har til formål at afdække om en AI-model systematisk favoriserer eller diskriminerer visse grupper, og generelt om modellen opfører sig etisk forsvarligt på tværs af forskellige demografier og scenarier. Dette er både et teknisk og et etisk anliggende, og det er tæt koblet til datakvaliteten bag AI’en.

Testdesign: For at teste fairness skal man typisk analysere modellens output på varierede datasæt:

Man samler eller genererer testdata der repræsenterer forskellige subgrupper (f.eks. forskellige køn, aldre, etniciteter, geografier, sprogvarianter, osv. afhængigt af konteksten). Et princip er at behandle datadiversitet som et krav, lige så vel som funktionelle krav. Testsuiten bør indeholde cases, der dækker bredden af legitim variation blandt brugere.
For hver gruppe sammenlignes modellens præstation. Det kan være simple output-sammenligninger: f.eks. at en kreditvurderingsmodel har samme godkendelsesrate for to ansøgergrupper med samme økonomi men forskelligt køn eller etnicitet. Eller at et ansigtsfilter virker lige godt på lys og mørk hudtone.
Man kan indbygge fairness-assertions i testoraklet: ikke kun “er output korrekt?”, men også “er det lige så korrekt for alle relevante kontekster?”. Hvis en model har 90% nøjagtighed for mænd og 70% for kvinder på samme opgave, afslører testen et fairness problem selvom den samlede nøjagtighed måske var acceptabel.
Ofte beregnes fairness-metrikker: f.eks. difference i fejlrate mellem grupper (disparate impact), bias-plots, eller fairness-indekser. Værktøjer som IBM’s AI Fairness 360, Microsoft Fairlearn osv. kan automatisere en del af denne evaluering, ved at kvantificere skævheder.

Anvendelsesområder: Fairness-test er relevant for alle AI-systemer, der træffer beslutninger om eller på vegne af mennesker – især i følsomme domæner: ansættelse, lån, forsikring, sundhed, uddannelse, det offentlige mv. EU’s kommende AI-forordning lægger stor vægt på at sikre at højrisiko AI-systemer benytter højkvalitets datasæt uden bias og at man løbende overvåger for diskriminerende outputs. Derfor bliver systematisk bias-test en compliance-opgave såvel som kvalitetsopgave.

Eksempel: Et ansigtsgenkendelsessystem kan testes ved at køre et stort udvalg af ansigtsfotos igennem og se om genkendelsesraten er markant lavere for bestemte etniske grupper – noget der desværre er set i nogle kommercielle systemer. Tilsvarende kan en sprogmodel testes for stereotyper ved at give den prompts om forskellige grupper og se om den associerer dem med negative konnotationer. I praktiske forsøg har man f.eks. brugt “værdi-dilemmaer” og tradeoff-scenarier til at teste store sprogmodellers moralske og etiske bias – ved at præsentere dem for et hav af etiske dilemma-cases kan man måle, om modellen konsekvent hælder til bestemte værdier eller overskrider retningslinjer. Sådanne stresstests kan afsløre, om en model systematisk favoriserer bestemte grupper eller værdier, og om den håndterer følsomme emner (sundhed, ligestilling, retfærdighed) på en ansvarlig måde.

For testteams betyder fairness-test, at man skal tænke dataindsamling og -udvælgelse ind i testdesignet: Har vi testdata, der dækker forskellige brugerprofiler? Hvis ikke, må det skaffes eller syntetiseres. QA har en rolle i at “være de første der opdager”, hvis systemet fungerer strålende for nogle brugere men fejler for andre. Så snart en systematisk skævhed identificeres, bør det rapporteres som en defekt – ofte kan rodårsagen findes i træningsdata, der så skal forbedres. Fairness-test handler altså både om at teste modellen og validere de data og forudsætninger modellen bygger på. Det er en løbende proces, hvor test og data science samarbejder om at gøre AI’en mere retfærdig.

Forklarlighedstest (explainability-test)

Mange AI-systemer – især dem baseret på “black-box” modeller som dybe neurale net – lider af manglende gennemsigtighed. Forklarlighedstest har til formål at sikre, at AI-systemet kan give meningfulde forklaringer på sine beslutninger, og at disse forklaringer faktisk er korrekte i forhold til modellens adfærd. Forklarlighed (ofte kaldet XAI – eXplainable AI) er kritisk i domæner hvor man skal kunne stole på eller verificere AI’ens output, f.eks. i medicinsk diagnostik, finansielle afgørelser eller andre højtstående beslutninger. Som testdisciplin er XAI-test relativt ny, men grundidéen er: “Tester vi ikke kun hvad modellen gør, men også hvorfor den gør det.”.

Testdesign: Forklarlighedstest kan angribes fra flere vinkler:

Først kræver det, at systemet overhovedet producerer en form for forklaring eller rationale sammen med sine beslutninger (eller at man har værktøjer til at udlede en forklaring, f.eks. SHAP-værdier, LIME eller lignende). Testeren skal have adgang til disse forklaringer.
En basistest er at kontrollere forklarings-indhold: Er der overhovedet konsistens mellem den givne forklaring og output? Hvis en AI afslår en låneansøgning og angiver “for lav indkomst” som forklaring, kan man variere indkomsten og se om beslutningen ændrer sig tilsvarende. Hvis forklaringen ikke matcher modellens egentlige beslutningslogik (dvs. er uærlig eller irrelevant), har vi et problem.
Forklarings-konsistens: Man kan teste, at lignende tilfælde giver lignende forklaringer. F.eks. to patienter med næsten ens profil som får forskellig model-anbefaling, bør have klart forskellige forklaringer – ellers tyder det på at forklaringerne er generiske eller tilfældige. Omvendt, hvis to inputs giver samme output, bør deres forklaringer ikke modsige hinanden.
Stabilitet: Man kan lave små ændringer i input og se om forklaringen ændrer sig proportionalt. For eksempel i billedgenkendelse: Hvis en lille ændring i billedet ikke ændrer klassifikationen, burde forklaringen (f.eks. hvilke billedområder der var vigtige) også forblive omtrent den samme. Drastiske ændringer tyder på forklaringsmetoden er ustabil.
Menneskelig validitet: Forklaringerne kan evalueres af domæneeksperter eller testere for at se, om de giver mening overhovedet. En del af testdesignet kan involvere inspektion: Tag et udvalg af modelbeslutninger og deres forklaringer, og lad en ekspert vurdere om forklaringen er plausibel og acceptabel som begrundelse. Dette er vigtigt, da en forklaring kan være teknisk korrekt (f.eks. “fordi interne neuron X aktiverede”), men ubrugelig for en slutbruger. I test-regi bør man have kriterier for hvad en god forklaring er (f.eks. specificitet, sandhed, klarhed).

Anvendelsesområder: Forklarlighedstest er ofte påkrævet i regulerede sektorer og højrisiko AI-systemer. I bank/finans skal man begrunde afslag på automatisk vis; i sundhed vil læger vide hvorfor en algoritme anbefaler en vis behandling. EU’s AI Act forventes at kræve en vis transparens i højrisiko AI, hvilket implicit betyder at systemerne skal kunne auditeres for deres beslutninger. Testteamet har her en rolle i at verificere, at de mekanismer der skal skabe gennemsigtighed faktisk virker – og at de opfylder et defensibelt transparens-niveau, hvor man kan forsvare systemets afgørelser med de givne forklaringer.

Konkrete eksempler:

En billeddiagnosticerings-AI markerer områder på røntgenbilleder som begrundelse for sin diagnose. Test her kan bestå i at give den en kendt case (hvor læger ved, at plet på lunge er tegn på sygdom) og se om AI’ens forklaringsmarkering faktisk dækker pletten. Hvis forklaringen peger helt andre steder hen, er der et forklarlighedsproblem.
En beslutningsstøtte-AI i HR sammenhæng, der skærer kandidater fra, kan påkræves at give “salgsargumenter” for og imod hver kandidat. Testere kunne tjekke at disse argumenter ændrer sig konsistent hvis kandidatens CV ændres (f.eks. at “mangler bestemt certifikat” forsvinder fra forklaringerne, når man tilføjer det certifikat i CV’et).
Ved brug af forklarings-værktøjer som LIME/SHAP vil testere kontrollere at integrationen af disse i systemet fungerer (dvs. at der genereres forklaringer hvor de skal), og at runtime-performance er acceptabel (forklaringsgenerering kan være tungt).

Forklarlighedstest overlapper med validering af krav til transparens og dokumentation. Et godt råd er at behandle manglende eller uforståelige forklaringer som en testfejl på lige fod med et forkert output. Det tvinger udviklere til at adressere forklarlighed tidligt. Over tid kan test af forklarlighed også fange modellens drift: Hvis en ny modelversion pludselig begynder at “forklare” sine beslutninger meget anderledes end tidligere (uden god grund), kunne det indikere at noget fundamentalt har ændret sig, måske til det værre. Derfor bør forklarings-output indgå i regressionstests, når modeller forbedres.

Særlige udfordringer ved test af AI-systemer

Som det fremgår, kræver test af AI en bred palette af teknikker. Men selv med disse på plads, må testteams være opmærksomme på en række fundamentale udfordringer og risici der følger med AI. Nedenfor gennemgås nogle af de mest markante: non-determinisme, data-bias, manglende forklarlighed (black box-problemet) og kontinuerlig læring. For hver udfordring beskrives konsekvensen for testarbejdet samt mulige tilgange til at håndtere den.

Non-determinisme og stokastisk adfærd

Traditionel software er overvejende deterministisk: samme input giver samme output hver gang. Mange AI-systemer “griner ad den antagelse” – de indeholder sandsynlighedsbaserede processer og kan give forskellige resultater på gentagne kørsler. Årsagerne kan være interne (tilfældig initialisering, parallelliseringsrækkefølger, anvendelse af dropout/noise i modellen) eller eksterne (modellen træner/lærer løbende og ændrer sig over tid). For test betyder det, at testresultater kan variere mellem kørsel. Et testscript kan ene dag passere, næste dag fejle, uden at koden er ændret – hvilket er frustrerende for QA.

Konsekvenser for test: Non-determinisme underminerer den klassiske “forventet vs. faktisk resultat” sammenligning. Testere kan ikke altid kræve binært ja/nej, men må tænke i statistik og sandsynlighed. F.eks. kan man definere, at en given outputværdi skal ligge inden for et interval, eller at en model skal producere samme kategori f.eks. 9 ud af 10 gange på samme input. Man skal planlægge for gentagne testkørsler og analysere distributionsforskelle snarere end enkeltafvigelser. Et godt eksempel er performance-målinger: i stedet for at kræve præcision = 90% på én testkørsel, måler man måske gennemsnitlig præcision over N gentagelser og laver en hypotesetest for om middelværdien opfylder kriteriet.

Håndtering:

Frys og kontroller variation: I nogle tilfælde kan man reducere non-determinisme ved at fastlåse random seeds, bruge deterministiske algoritmer eller slå ubenyttet parallel udførsel fra i testmiljøet. Dette kan stabilisere tests, men må bruges med omtanke – i produktion har man jo den fulde stokastiske adfærd, så test skal ikke skjule reelle effekter.
Statistisk testorakel: Som nævnt kan man inkorporere statistiske analyser i testkoden. ISO’s AI-test guidelines bemærker behovet for at “evolvere ud over faste testcases” netop på grund af non-determinisme. Metoder som metamorfisk test og property-based test (hvor man tester egenskaber i stedet for eksakte outputs) bliver uundværlige. I Microsofts rammeværk for AI-test foreslås det at bruge hypotesetest og konfidensintervaller til at verificere metamorfiske relationer på tværs af multiple kørsler.
Selv-healende tests: Et nyere koncept er test-suiter der automatisk justerer sig, hvis en model ændrer adfærd, men stadig inden for acceptable rammer. Eksempel: hvis en ny modelversion har ændret en output-skala, kan testene opdage det og kalibrere assertions uden manuel indgriben (forudsat ændringen er tilsigtet). Sådanne mekanismer kræver AI-assistance i testværktøjerne og er et aktivt forskningsområde.

Som QA skal man acceptere, at “flakiness” kan være vilkår i AI-tests. Løsningen er ikke at ignorere fejlede tests, men at analysere fejlnaturerne statistisk. Non-deterministiske fejl kan dække over reelle problemer (f.eks. en model der er marginalt stabil, eller en træningsproces med for høj varians). Endelig kan det hjælpe at øge observabiliteten: logge interne tilfældige valg, versioner af modelvægte osv., så man i det mindste kan forklare hvorfor to testkørsler afveg.

Databias og skæve træningsdata

AI’s hjerne er data – og hvis data er skævt eller ufuldstændigt, bliver systemets præstation derefter. Databias er en af de hyppigste kilder til fejl og uforudsigelige modelresultater. Et træningsdatasæt kan have indbyggede skævheder (f.eks. underrepræsentation af en gruppe, eller historisk bias), hvilket kan føre til at modellen systematisk favoriserer én udfald frem for et andet på uretfærdigt grundlag. Selv uden direkte diskrimination kan datakvalitetsproblemer (manglende data, støj, fejlmærkninger) give blinde vinkler, hvor modellen fejler i visse situationer.

Konsekvenser for test: Et system kan bestå mange funktionelle tests og stadig være ubrugeligt pga. data-bias. QA skal derfor tænke ud over “virker softwaren som kodet?” til “er data og modellens verdenssyn sundt?”. Som tidligere nævnt skal test cases dække diversitet, og resultater analyseres for mønstre. Hvis testteamet f.eks. observerer at systemet klarer sig fremragende for nogle brugere og mystisk dårligt for andre, bør alarmklokker ringe. Det kan være tegn på bias eller datamangler og ikke blot “random edge cases”. Test skal i højere grad finde disse mønstre end enkeltstående fejl.

Håndtering:

Test datasættene: Inkludér datagennemgang som del af teststrategien. Har vores trænings- og testdata repræsentativ dækning? ISO/IEC 29119-11 anbefaler testere at validere datasæt, herunder metadata om kilder, antagelser og kendte begrænsninger. Man kan lave simple statistikchecks på datasets: demografi-fordelinger, korrelationer mellem features og labels etc.
Bias-detektion værktøjer: Der findes værktøjer til at måle fairness metrics (som nævnt, IBM AI Fairness 360, Fairlearn m.fl.). Testere kan bruge disse til at kvantificere eventuel bias i modellens output. For eksempel kan man automatisere beregningen af “equal opportunity” (samme recall for alle grupper) eller “statistical parity” (samme positiv-rate for alle grupper) på testresultaterne og få en rapport.
Eksplorativ test for bias: Udover planlagte tests kan tester-teamet lave eksplorative undersøgelser: prøv forskellige inputkombinationer, stress test modellen med både typiske og atypiske data. Idéen er at lede efter mønstre snarere end isolerede fejl. F.eks. feed en sprogmodel 100 forskellige sætninger hvor kun personenavnet varieres mellem typisk mandlige og kvindelige navne, og se om output ændrer sig i kvalitet eller tonalitet afhængigt af køn (det kunne indikere bias).

Databias er ofte en organisationsudfordring: testafdelingen skal have lov til at påpege problemer i træningsdata, selvom det måske ikke traditionelt anses som “deres ansvar”. Faktisk bør QA involveres tidligt i AI-udviklingen for at vurdere dataopsamling og annotering – dette er en del af “shift-left” tankegangen for AI-risici. Hvis data er rådden, nytter fancy algoritmer og tests ikke meget.QA kan fungere som uafhængig kontrolinstans der sikrer, at datasættene lever op til visse kvalitetskrav før modellen trænes (f.eks. krav om repræsentativitet, ingen duplikerede labels, dokumentation af kilder etc., jævnfør EU AI Act’s krav om data governance).

Manglende forklarlighed (black-box problem)

Som gennemgået under forklarlighedstest, er mange AI-systemer sorte bokse. For testere betyder det, at når der opstår fejl eller uventede outputs, kan det være ekstremt svært at debugge hvorfor. I klassisk software kan man ofte pinpointe en bug i koden. I en dyb læringsmodel med millioner af parametre er fejlen måske diffus – modellen “tog fejl” men vi kan ikke umiddelbart se om det var pga. enkelte features, overfitting, eller noget tredje. Denne manglede transparens gør root cause analysis udfordrende og kan gøre det svært at definere korrekte forventninger. Det er også en risiko, fordi interessenter kræver forklaringer: en testmanager kan blive spurgt hvorfor AI’en fejler på case X, og svaret “det véd vi ikke, det er en black box” er ikke acceptabelt i længden.

Konsekvenser for test: QA skal arbejde med tiltag der øger observabiliteten af AI-systemet. Dette kan involvere at få udviklerne til at instrumentere systemet bedre: logge mere data undervejs, udstille interne værdier, eller integrere XAI-værktøjer til brug for test. Testere bør planlægge analyse-skridt efter testkørsler: f.eks. hvis en test fejler, hvordan kan vi trække en forklaring ud? Det kunne være via feature importance scoring for det pågældende input for at se hvilke attributter der påvirkede beslutningen.

Håndtering:

Brug XAI under test: Som nævnt tidligere kan værktøjer som SHAP og LIME bruges proaktivt. Testere kan f.eks. automatisere, at for hvert kritisk testinput genereres forklaringsinformation, som gemmes sammen med testresultatet. Så hvis en regressionstest senere viser ændret output, kan man sammenligne forklaringsprofilen før/efter for at se hvad der ændrede sig.
Regel-baserede surrogater: En teknik er at træne en enklere, fortolkelig model (f.eks. beslutningstræ) på tværs af AI-modellens inputs/outputs (dette kaldes ofte en surrogate model). Denne kan give et tilnærmet globalt billede af, hvilke faktorer AI’en baserer beslutninger på. Som testanalytiker kan man bruge surrogaten til at sanity-tjekke: giver det mening at afgørelser primært afhænger af disse top 3 features ifølge surrogaten? Hvis ej, kan der være et problem i den sorte boks.
Peer review og tværfaglighed: Involver domæneeksperter, data scientists og udviklere sammen ved testruns hvor black-box opførsel skal tolkes. Flere øjne og perspektiver kan nogle gange forklare et mystisk AI-resultat (måske er det faktisk korrekt ud fra en obskur korrelation i data, osv.).

I sidste ende er forklarlighed en kvalitetsegenskab man bør specificere og teste på lige fod med f.eks. ydeevne. Det er også et compliance-krav – f.eks. i finanssektoren med “retten til forklaring” og i ISO/IEC 42001 standarden, hvor transparens, fairness og ansvarlighed fremhæves som nøgleprincipper. Derfor skal testteams planlægge for at verificere, at disse principper er implementeret. Selvom man ikke altid kan “åbne black boxen”, kan man teste output og forklaret output for konsistens og meningsfuldhed som beskrevet. En black-box AI uden nogen form for forklaret logik er i mange tilfælde uegnet i produktionsbrug – testere bør fange dette tidligt og kræve tiltag (enten tekniske XAI-løsninger eller procesmæssig kompensation som human review af AI-beslutninger).

Kontinuerlig læring og modeldrift

Traditionel software ændrer sig kun når udviklere opdaterer koden. AI-modeller derimod kan have et liv efter idriftsættelse: nogle systemer lærer løbende af nye data (online learning), andre bliver jævnligt retrænet og versioneret, og selv hvis modellen er statisk kan dens performance drifte over tid pga. ændringer i omverdenen (concept drift). Dette betyder, at test aldrig slutter for AI-systemer – kvaliteten kan ikke “fryses” ved go-live. Modellen skal overvåges og gen-evalueres, fordi dens outputkvalitet kan ændre sig når datadynamikken ændrer sig.

Konsekvenser for test: Testteams skal udvide deres ansvarsområde til post-release overvågning og kontinuerlig test. Hvor man før måske lukkede testfasen efter deployment, skal man nu etablere mekanismer for at opsamle performance metrics i produktion, detektere datadrift og trigge ny test/rundkørsler ved behov. Det kan minde om klassisk monitorering, men QA har en rolle i at definere hvad der skal monitoreres (f.eks. modelaccuracy, fejlfordeling, edge cases log) og hvordan der skal reageres. Når en model gen-trænes (f.eks. månedligt med nye data), skal testcyklussen gentages på den nye version, helst så automatisk som muligt (dette kan ses som en form for CI/CD for modeller – ofte kaldet MLOps/ModelOps).

Håndtering:

Automatisér gentests: Byg pipelines, hvor nye modelversioner automatisk valideres mod baseline-testdatasets og -metrikker, før de skubbes til produktion. Regressionstest skal dække, at ingen eksisterende cases forværres, og at fairness/forklarlighed stadig er i orden. Vær også klar til at teste rollbacks: hvis en ny model opfører sig dårligt, kan vi så hurtigt skifte tilbage til en forrige version? Test det som en del af releaseproceduren.
Kontinuerlig monitorering: I drift kan man implementere systemer, der løbende måler modellens præstation. F.eks. for en klassifikationsmodel i produktion, prøv jævnligt at indsamle et sæt cases hvor modellens selvtillid er lav eller den ændrer mening ofte, og send dem tilbage til testteamet eller data science for nærmere analyse (dette kan fange nye typer inputs som modellen er usikker overfor). Ifølge best practices bør man have alarmer for datadrift – f.eks. hvis inputdataens statistiske profil ændrer sig markant fra træningsdatasættets, eller hvis der pludselig kommer en stigning i usikkerhed i modellens output.
Brug af ModelOps værktøjer: Disse hjælper med versionering, test og monitoring af modeller på en integreret måde. Ved at integrere test cases i ModelOps pipeline sikrer man, at hver modelversion gennemgår en standard testpakke, og at der føres log og sporbarhed for hvilke tests den består. ISO 42001 fremhæver netop system-livscyklus styring og kontinuerlig forbedringsom krav – AI governance skal have en “Plan-Do-Check-Act” cyklus, hvor “Check” svarer til overvågning og test af systemet løbende.

Testteams bør altså blive en del af AI-systemets livscyklus frem for kun projektreleaser. Det kan kræve opkvalificering (f.eks. i driftstools, dataanalyse) for QA-personale. Men gevinsten er, at man kan fange degradering eller nye fejl før de bliver til skandaler. Som en ekspert udtrykker det: AI-systemer drifter og evolverer efter go-live, så kontinuerlig testning bliver en uomgængelig disciplin.

En særlig note: kontinuerlig læring (hvor modellen selv opdaterer sig med nye data) er meget svært at teste fuldt ud forud. Her bliver etablering af sikre læringsgrænser centralt – dvs. at man i designen sikrer f.eks. at modellen kun lærer inden for visse parametre eller at der er human oversight, og tester disse mekanismer. Governance-mæssigt er det oftest klogt at begrænse fuld online-læring uden menneskelig kontrol for højrisiko systemer, netop fordi det ellers underminerer muligheden for at garantere noget som helst via test.

Standarder, regulativer og etik i AI-test

Test af AI-baserede systemer skal ikke kun sikre teknisk kvalitet, men også opfylde standarder, lovkrav og etiske principper. I dette afsnit gives et overblik over nogle væsentlige rammer, som testteams bør kende: den etablerede teststandard ISO/IEC 29119 (med nyere AI-specifik vejledning), den helt nye AI-governance standard ISO/IEC 42001, samt EU’s kommende AI-forordning (AI Act). Desuden diskuteres hvordan compliance, governance og etik spiller ind i testarbejdet.

ISO/IEC 29119 og retningslinjer for AI-test

ISO/IEC 29119 er en international standardserie for softwaretest, der dækker testprocesser, dokumentation og teknikker. Den udgør “best practice” for generel softwaretest. Selvom den ikke er skræddersyet til AI, er dens discipliner udgangspunktet for også at teste AI-systemer. Der findes dog en teknisk rapport, ISO/IEC TR 29119-11:2020, som specifikt omhandler test af AI-baserede systemer. Denne rapport fremhæver de karakteristika ved AI-systemer (kompleksitet, big data, upræcise specifikationer, non-determinisme osv.) der kræver særlig opmærksomhed, og giver guidelines til at teste dem gennem hele livscyklussen. Blandt pointerne er:

Det primære nye problem er testorakel-problemet – svært ved at definere forventede resultater. Altså, test skal ofte verificere målopfyldelse via statistiske metrikkers snarere end perfekt opfyldelse af enkelteksempler.
Den anbefaler at bruge både black-box test og white-box test (specielt rettet mod neurale net). Black-box test inkluderer f.eks. funktionel validering mod krav i systemets kontekst, mens white-box kan være at analysere netværksstrukturen, aktivere neuroner, visualisere lag osv.
TR 29119-11 beskriver også mulige testmiljøer og scenarier til AI – herunder simulation for visse typer AI og nødvendigheden af repræsentative testdatasæt.
Rapporten kobler også 29119 testprocesserne til verifikation og validering i AI-livscyklusmodellen (ISO/IEC 22989 for AI system lifecycle). Det vil sige, at testaktiviteter bør indlejres i alle faser fra dataforberedelse, modelbygning, integration, drift osv. Det understøtter mange af de praksisser vi allerede har gennemgået (f.eks. test af data før træning, overvågning efter idriftsættelse).

For testmanagers betyder ISO 29119 at man fortsat kan læne sig op ad de grundlæggende testprincipper og processer: testplanlægning, risikobaseret test, formel testdokumentation (test cases, testrapporter), osv., gælder stadig. Men man bør udvide testplanen med punkter fra TR 29119-11, f.eks. plan for hvordan orakelproblemet håndteres i hvert testniveau, plan for test af ML-komponenter vs ikke-ML komponenter, og hvordan man tester læringsprocessen selv (ikke kun det endelige system). Standarden er ikke bindende, men at følge dens retningslinjer kan hjælpe med at systematisere AI-test, så intet vigtigt overses. Samtidig kan det være et kvalitetsstempel overfor kunder/tilsyn at ens AI-testpraksis er i tråd med international standard.

ISO/IEC 42001 – AI management system og governance

ISO/IEC 42001:2023 er en ny standard, der specifikt omhandler AI-styringssystemer (AIMS). Den fungerer lidt ligesom ISO 9001 (kvalitet) eller ISO 27001 (sikkerhed), men målrettet tillidsfuld og ansvarlig AI. Standarden opstiller krav og vejledning til organisationer om at etablere et ledelsessystem omkring udvikling, drift og vedligehold af AI – med fokus på etik, risikostyring og governance.

Vigtige elementer i ISO 42001 inkluderer:

Risikostyring for AI: Organisationen skal identificere og mitigere AI-risici som bias, manglende ansvarlighed, datasikkerhed osv.. Dette passer med testdisciplinen: testaktiviteterne skal være risikobaserede, og f.eks. fairness-test direkte adresserer bias-risiko.
Etiske principper: Standarden kræver indbygning af transparens, fairness og accountability i AI-systemer. For test betyder det, at disse principper skal valideres. Vi har set hvordan transparens (forklarlighed) kan testes, fairness kan testes, og accountability kan delvist testes via audit logs osv.
Kontinuerlig overvågning og forbedring: Ligesom andre management-system standarder lægger ISO 42001 op til PDCA-cyklussen – Plan, Do, Check, Act. “Check” er hvor test og monitorering kommer ind, og “Act” handler om at lære af fejl og rette op. Testteams skal således være integreret i denne løbende proces, ikke blot ved produktaflevering.
Interessent-involvering: Standarden påpeger vigtigheden af at involvere compliance-medarbejdere, risikomanagers, domæneeksperter m.fl. i AI-udviklingen. For test vil det sige, at testcases måske skal gennemgås af et AI etisk råd eller lignende, og at testresultater skal tilgå ledelsen for beslutning om acceptabelt risikoniveau.

ISO 42001 er designet til at hjælpe organisationer med at “bygge tillid” til AI-systemer gennem struktureret governance. Selvom det ikke er en teststandard, så kan en testmanager bruge den som løftestang til at argumentere for bestemte aktiviteter: f.eks. “Vi bør have en proces for bias-test og dokumentation, fordi ISO 42001 og kommende lovgivning kræver vi håndterer bias systematisk”. Faktisk nævner standarden eksplicit, at dens rammer hjælper med at opfylde compliance bl.a. ift. EU AI Act. Så følger man 42001, er man godt rustet.

For testanalytikere betyder 42001’s eksistens, at kvalitetsarbejdet nu også handler om governance. Man kan forvente audits eller certificering, hvor testartefakter vil blive gennemgået: Kan I dokumentere, at I testede for fairness? Hvad er jeres procedure når modellen ændrer sig? osv. At have robuste testdesign-teknikker for disse aspekter er altså ikke bare nice-to-have men snart et must-have for troværdighed på markedet.

EU AI Act og lovkrav til test

Den kommende EU AI Act (AI-forordningen) er en omfattende regulering, som vil klassificere AI-systemer i risikoklasser og opstille krav især til højrisiko AI-systemer. For test og QA er det afgørende at kende de krav, der omhandler risikostyring, test før idriftsættelse, data kvalitet, dokumentation og overvågning:

Risikostyringssystem og test: Udbydere af højrisiko-AI skal etablere et løbende risikostyringssystem (som nævnt i art. 9). Dette inkluderer identifikation, analyse og evaluering af risici ved systemet samt afhjælpning gennem passende foranstaltninger. En af disse foranstaltninger er test: Forordningen kræver, at AI-systemer testes for at sikre, at de præsterer konsistent i overensstemmelse med deres tilsigtede formål, og opfylder kravene i loven. Test skal udføres i hele udviklingsprocessen og mindst før systemet bringes på markedet, mod passende metrics og probabilistiske tærskler. Dette lovfæster i praksis en testforpligtelse – QA skal dokumentere, at man har testet systemet tilstrækkeligt mod relevante scenarier inden lancering.
Datakrav (art. 10): Højrisiko AI, der trænes på data, skal bruge trænings-, validerings- og testdatasæt der er relevante, repræsentative, korrekte og komplette. Der skal især tages højde for potentielle bias i data og mangler, og disse skal adresseres. For test betyder det: Testdatasæt skal leve op til kvalitetskrav – ikke noget med at teste kun på nemt tilgængelige data, man skal sikre repræsentativ dækning (som vi også argumenterede for under fairness-test). Desuden at selve dataforvaltningen (dokumentation af data, styring af versioner etc.) er i orden; QA kan få ansvar for at tjekke om dataholds registrene er up-to-date, og at testdata håndteres forsvarligt (f.eks. ingen personfølsomme data uden hjemmel).
Teknisk dokumentation (art. 11) og registrering: Der skal udarbejdes teknisk dokumentation før markedsføring, hvori det bl.a. skal demonstreres, at systemet overholder kravene og beskrive risikostyrings- og testprocedurer. Testresultater, dækningsgrader, performance metrics osv. vil her være afgørende at have med for at vise compliance. Endvidere skal stand-alone højrisiko AI registreres i en EU-database – potentielt med et resumé af compliance, hvori test er en del.
Post-market overvågning (art. 61): Efter idriftsættelse skal udbydere indføre en overvågningsplan for at samle data om performance og compliance i driftsmiljøet og løbende evaluere det. Dette harmonerer med vores tidligere punkt om kontinuerlig test; det bliver altså også et lovkrav at have sådanne mekanismer og at reagere på dem.
Transparens og forklaring (art. 13 & 14): Højrisiko AI skal logge events for at muliggøre sporbarhed (art. 12 om logbog), og nogle systemer (især dem der interagerer med mennesker) skal give visse erklæringer eller forklaringer til brugere (f.eks. hvis man interagerer med en AI skal det oplyses, og for beslutningssystemer måske forklare kriterierne). For test kan log-kravet betyde at testers skal verificere, at logning sker korrekt og indeholder de nødvendige data. Sporbarhed er vigtig ift. audits: et godt testforløb kan prøve at rekonstruere en beslutning ud fra loggen som en slags verifikation af at logging er tilstrækkelig. Transparenskravene gør også forklarlighedstest essentielt for compliance.

Alt i alt vil EU AI Act skærpe kravene til test formelt. Det bliver ikke længere op til producenten selv at vurdere hvor meget test er nok; der vil være minimumskrav og man skal kunne fremvise beviser for test (f.eks. testrapporter) i en eventuel compliancegennemgang. Testmanagers bør derfor allerede nu sørge for at dokumentere testarbejdet grundigt – hvad er testet, hvornår, med hvilke data og resultater – så dokumentationen kan indgå i teknisk dossier.

For testanalytikere giver loven et klart signal: fokus på bias, nøjagtighed, robusthed og cybersikkerhed (der er også krav om at AI skal være robust over for f.eks. manipulation og fejl). Der skal testes mod “intended purpose”, hvilket betyder at tests bør dække realistiske brugssituationer og worst-case scenarios. Som en del af risikostyringen forventes det, at testcases knyttes til de risici man har identificeret (f.eks. hvis en risiko er “forkert klassifikation kan skade patient”, skal der være testcases omkring de scenarier hvor den fejl kan opstå, for at sikre at sandsynligheden minimeres).

Compliance, governance og etik i praksis

Som afrunding på standarder og regulativer er det værd at fremhæve, at compliance og etik ikke er abstrakte begreber, men noget der skal omsættes til konkrete testaktiviteter og -processer. Her er nogle fremhævede pointer for testteams:

Etabler QA-governance for AI-projekter: Overvej at have en kvalitetsansvarlig eller AI Test Lead, der følger AI-projektet end-to-end og sikrer at alle disse ekstra testtyper (fairness, XAI, osv.) bliver planlagt og udført. Involvér denne person i risikovurderinger, data udvalg, designbeslutninger osv. for at “bake-in” testkravene tidligt.
Dokumentér alt for sporbarhed: Hver gang I tester for noget etisk (f.eks. fairness), så dokumentér kriterierne, datasets brugt, resultater og evt. afhjælpninger. Det giver ikke kun ro i sindet internt, men kan fremvises ved audits eller til ledelsen for at demonstrere ansvarlighed. Som Snilld-caset illustrerede, forventes det ikke længere nok at sige “vi gjorde vores bedste” – man skal bevise det sort på hvidtsnilld.dk.
Opdater testpolicy og cases i lyset af lovgivning: Virksomheder bør opdatere deres interne testpolicy til at inkludere AI-specifikke elementer, så som “Der skal udføres bias-tests for alle modeller med brugerdata” eller “Enhver højrisiko AI skal have en testplan der opfylder EU AI Act artikel 9 og 10 kravene”. Testcases skal også tags med hvilke lov/etikkrav de dækker, for at sikre dækning (f.eks. tag en testcase med “fairness-disparitet-kontrol” som knyttet til EU AI Act datareglen).
Inkorporér etiske overvejelser i testdesign: Ud over tekniske krav bør testteams bruge et etisk filter: tænk “hvad er det værste et ondsindet eller uheldigt udfald vores AI kan medføre for en bruger?”. Design tests til at simulere eller afsløre disse. Det kunne være alt fra at AI’en genererer stødende sprog, til at den behandler grupper unfair, til at den tager beslutninger der strider mod lovgivning. Ofte kan value-based scenario test hjælpe – hvor man tester AI’en mod cases indlejret med etiske dilemmaer for at se hvordan den reagerer (som i førnævnte LLM stress-tests).
Træning og kultur: Sikre at hele testteamet forstår de nye begreber: fairness metrics, adversarial examples, XAI, osv., samt kender de relevante standarder. Det kan være nødvendigt med kurser (der findes f.eks. ISTQB’s “Certified Tester AI Testing” syllabus, som dækker mange af disse emner). En kultur der belønner indrapportering af “upopulære” findings – f.eks. at rejse en bug om potentiel diskrimination eller manglende forklarlighed – er vigtig. Det viser organisationens modenhed ift. ansvarlig AI.

Konklusion: Test af AI-systemer kræver en holistisk tilgang. Testmanageren skal planlægge med både velkendte metoder og nye innovative teknikker for at komme rundt om kvaliteten. Testanalytikeren skal designe tests, der ikke alene validerer funktionalitet, men også udfordrer modellens robusthed, fairness og transparens. Undervejs skal man navigere ikke-deterministisk opførsel og manglende orakler, men med metamorfiske relationer og statistisk tænkning kommer man langt. Samtidig må testteams opgradere sig til at håndtere compliance og etik – kvalitet er ikke kun teknisk perfektion, men også fravær af bias, forklarlige beslutninger og overholdelse af lov og ret.

Ved at anvende de beskrevne teknikker og være bevidst om udfordringerne kan testteams minimere risici og øge tilliden til AI-systemerne, før de møder virkelighedens brugere. Som de nye standarder og regulativer understreger, er test og kvalitetssikring af AI en kontinuerlig rejse – men en nødvendig én, for at høste AI’s fordele på en ansvarlig måde.

Anbefalede bøger:

· Introduction to AI Testing – Guide to ISTQB CT-AI Certification
Iosif Itkin et al, BCS 2025

· Artificial Intelligence and Software Testing – Building systems you can trust
Adam Leon Smith et al, BCS 2022