Flere virksomheder køber løsninger, hvor kunstig intelligens er en central del: en kundeservicebot, et system til at klassificere dokumenter, en prognosemodel eller en assistent bygget oven på en stor sprogmodel. Når løsningen ikke virker som forventet, ligner tvisten en almindelig sag om mangler ved en IT-leverance. Men bevisførelsen er sværere. En AI-model kan give forskellige svar på samme spørgsmål, den kan ændre sig over tid, og dens kvalitet afhænger af data, som parterne måske ikke har styr på. Denne artikel handler om, hvad der skal dokumenteres, og hvornår.
Hvorfor AI-leverancer er særlige
I en traditionel IT-leverance kan en fejl som regel gentages. Samme input giver samme output, og en skønsmand kan se fejlen ske. I en AI-løsning er det ikke givet:
- Variation. Mange sprogmodeller giver bevidst varierende svar. Et dårligt svar i går kommer måske ikke igen i dag.
- Udskiftning. Løsningen kan bygge på en model fra en tredjepart, som opdateres uden varsel. Den model, der var i brug, da fejlen opstod, findes måske ikke længere.
- Afhængighed af data. Kvaliteten afhænger af de data, modellen er trænet eller tilpasset på, og af de data, kunden selv leverer i drift.
- Uklare krav. Aftalen lover ofte “høj præcision” eller “menneskelignende svar” uden målbare kriterier.
Derfor bliver dokumentationen af, hvad der faktisk var leveret på et bestemt tidspunkt, central. → Mangler ved IT-leverancer
Det, der blev vist før aftalen
Mange AI-leverancer sælges på baggrund af en demonstration eller et pilotprojekt. Kunden så løsningen svare flot på udvalgte spørgsmål og købte på det grundlag. Senere, i drift, er kvaliteten en anden. Så bliver det relevant, hvad demonstrationen faktisk viste:
- Hvilken model og hvilken version blev brugt i demonstrationen?
- Var spørgsmålene udvalgt på forhånd, og af hvem?
- Byggede den på kundens rigtige data eller på et tilrettet eksempel?
- Findes der optagelser, præsentationer eller rapporter fra piloten?
Materialet bør sikres med datoer og i original form. En præsentation, der senere er opdateret, viser ikke nødvendigvis det, kunden så. Versionshistorik i delte dokumenter kan hjælpe med at fastslå, hvad der var vist hvornår. Pilotrapporter med konkrete resultater er særligt værdifulde, fordi de kan sammenlignes direkte med målinger fra drift. → Versionshistorik i kontraktudkast
Fire ting, der skal kunne dokumenteres
1. Modellen. Hvilken model, i hvilken version, med hvilke indstillinger? For løsninger bygget på en ekstern sprogmodel omfatter det modelnavn og version, parametre der styrer variation, og de faste instruktioner (systemprompten), som løsningen sender med hver forespørgsel.
2. Data. Hvilke data er brugt til at træne, tilpasse eller fodre modellen? Hvem leverede dem, og i hvilken stand? Hvis løsningen henter svar fra kundens egne dokumenter, er det også relevant, hvilke dokumenter der var tilgængelige, og hvornår.
3. Test og evaluering. Hvordan blev løsningen testet før overtagelse? Hvilke testsæt blev brugt, og hvilke resultater blev opnået? En evaluering, som parterne godkendte, kan blive det vigtigste dokument i sagen.
4. Output i drift. Hvad svarede løsningen faktisk, hvornår, og på hvilket input? Det kræver logs med forespørgsel, svar, tidspunkt og modelversion.
Logs er afgørende
Uden logs bliver sagen et spørgsmål om enkelte skærmbilleder og vidneforklaringer. Med logs kan det undersøges, hvor ofte fejlene forekom, under hvilke betingelser, og om de ændrede sig efter en opdatering.
For højrisikosystemer stiller EU’s AI-forordning, forordning (EU) 2024/1689, i artikel 12, stk. 1, krav om, at systemerne teknisk skal muliggøre automatisk registrering af hændelser (logfiler) i systemets levetid. Mange erhvervsløsninger er ikke højrisikosystemer, og så afhænger logningen af aftalen og af opsætningen.
Spørg derfor tidligt:
- Logges forespørgsler og svar, og hvor længe gemmes de?
- Logges modelversionen sammen med hvert svar?
- Hvem har adgang til logs: kunden, leverandøren eller kun modeludbyderen?
- Sletter systemet automatisk efter en fast periode?
Hvis logs slettes løbende, bør der hurtigt sendes en meddelelse om bevarelse. → Bevarelsespligt og litigation hold
Når fejlen skal vises
En påstand om, at løsningen “ofte svarer forkert”, kræver et mål. To metoder bruges ofte:
- Gennemgang af logs. En stikprøve af faktiske forespørgsler og svar vurderes efter faste kriterier. Kriterierne skal fastlægges, før gennemgangen begynder.
- Kontrolleret test. Et fast sæt spørgsmål køres mod løsningen flere gange, så variationen kan måles. Det kræver, at den relevante modelversion stadig kan køres.
Begge metoder bør dokumenteres, så de kan gentages. Hvem valgte spørgsmålene? Hvem vurderede svarene? Hvilken version blev testet? Det er netop de spørgsmål, modparten vil stille.
Hvem har dataene
AI-løsninger involverer ofte tre parter: kunden, leverandøren og en udbyder af den underliggende model. Leverandøren har typisk konfiguration, testresultater og logs. Modeludbyderen kan have yderligere logs, men vil sjældent udlevere dem uden videre. Kunden har sine egne input, brugeres klager og interne beskeder om fejl.
Er data hos leverandøren, kan opfordring eller edition blive nødvendig. Er klienten selv leverandøren, gælder de samme overvejelser om at sikre egne data, før de bearbejdes. → Når klienten er IT-leverandøren
Kundens egen andel
Leverandøren vil ofte pege på kunden: dårlige data, ændrede arbejdsgange, brugere der stiller spørgsmål uden for løsningens formål. Det er relevant at dokumentere, hvad kunden leverede af data og hvornår, og hvordan løsningen faktisk blev brugt. Brugsstatistik kan vise, om fejlene ramte løsningens kerneopgave eller kanttilfælde. Interne beskeder, hvor brugere melder fejl, kan både støtte og svække kundens sag og bør sikres samlet.
Skønstemaer
Skønstemaer i AI-sager bør være konkrete og målbare. “Fungerer løsningen?” er for bredt. Bedre er spørgsmål om andelen af korrekte svar i et defineret testsæt, om resultaterne svarer til den godkendte evaluering, og om ændringer i modelversion har påvirket kvaliteten. → Skabelon til skønstema i IT-sager
Hvad en IT-sagkyndig kan og ikke kan konkludere
En sagkyndig kan undersøge, hvilken model og konfiguration der var i brug i en bestemt periode, hvis logs og opsætning er bevaret. Det kan måles, hvor stor en andel af svarene i et defineret testsæt der opfylder fastlagte kriterier, og om andelen ændrede sig efter en opdatering. Det kan også undersøges, om de data, kunden leverede, havde mangler, som må forventes at påvirke kvaliteten, fx dubletter, forældede dokumenter eller manglende felter.
Der er grænser. En sagkyndig kan sjældent forklare, hvorfor en stor sprogmodel gav et bestemt svar i et enkelt tilfælde. Modellens indre virkemåde er ikke tilgængelig på samme måde som kildekoden i et almindeligt program, og den eksterne udbyder vil typisk ikke give indsigt. Det er heller ikke muligt at fastslå med sikkerhed, hvordan løsningen ville have klaret sig med andre data eller en anden model, uden at det faktisk testes.
Det betyder, at konklusioner i AI-sager ofte vil være statistiske og betingede. Advokaten bør være opmærksom på det, når skønstemaer formuleres, og når modpartens sagkyndige drager mere bastante slutninger end datagrundlaget bærer. → Spørgsmål til modpartens sagkyndige
Typiske fejl
- At sikre skærmbilleder af enkelte dårlige svar i stedet for logs.
- At overse, at den underliggende model er skiftet.
- At teste uden at dokumentere version og indstillinger.
- At lade logs slette automatisk under tvisten.
- At formulere krav og skønstemaer uden målbare kriterier.
Tjekliste
- ☐ Modelversion, indstillinger og systemprompt er dokumenteret
- ☐ Trænings- og kundedata er beskrevet
- ☐ Testsæt og godkendte evalueringer er sikret
- ☐ Logs med input, output, tid og version er sikret
- ☐ Automatisk sletning er standset
- ☐ Metode til at måle fejl er fastlagt før gennemgangen
→ Send en sag · Tlf. 70 13 63 23 · IT-sagkyndig bistand til advokater hos Nielco IT
