En funktion, der bygger på en sprogmodel, vil en gang imellem svare forkert og lyde sikker imens. Det kaldes hallucination, og det kan begrænses, men ikke fjernes helt. Når en kunde melder et forkert svar, er der derfor to opgaver: at håndtere den konkrete sag, og at ændre produktet, så samme type fejl gør mindre skade næste gang. Det sidste handler mest om design, kildehenvisninger og en klar aftale om, hvem der retter hvad.
Sådan håndterer I sagen, når den kommer
Tag det som en driftssag med en ejer, og gå gennem disse trin samme dag:
- Find samtalen. Hvad blev der spurgt om, hvilke data blev brugt, og hvilken modelversion svarede? Uden log kan I kun gætte, så det bør være bygget ind fra begyndelsen.
- Vurder skaden. Har kunden handlet på svaret, har andre fået samme svar, og er det en enkelt fejl eller et mønster?
- Brems, hvis det er alvorligt. Slå funktionen fra for den pågældende opgave eller kunde, mens I undersøger.
- Svar kunden konkret. Sig, hvad der skete, og hvad I gør. En standardtekst om, at AI kan tage fejl, løser ikke sagen.
- Læg eksemplet i testsamlingen, så fejlen fanges, hvis den vender tilbage, se test af AI-funktioner.
Find årsagen, før I retter
Forkerte svar har forskellige årsager, og rettelsen afhænger af, hvilken det er.
- Data er forkerte eller forældede. Modellen gentager, hvad den får. Så skal kilden rettes, og det er ofte en opgave for fagfolkene i huset.
- De rigtige data blev ikke fundet. Søgningen fandt det forkerte dokument, og modellen gjorde sit bedste. Her skal fremsøgningen forbedres.
- Instruktionerne er uklare. Modellen fik lov at svare, hvor den burde have sagt, at den ikke ved det.
- Modellen digter. Den fylder et hul med noget, der lyder rigtigt. Det kræver en strammere opgave eller en kontrol bag efter.
- Opgaven passer ikke til teknikken. Beregninger og regelopslag bør gøres af almindelig kode, som modellen kalder.
Design, der begrænser skaden
De fleste fejl bliver først alvorlige, når brugeren ikke opdager dem. Derfor skal designet gøre det let at kontrollere svaret.
- Vis kilden. Lad svaret pege på det dokument eller den række, det bygger på, og kontrollér med kode, at kilden findes.
- Lad brugeren godkende. Et forslag, der skal bekræftes, er noget andet end en handling, der er sket. Det gælder især, når funktionen må ændre noget, se AI-agenter i produktet.
- Giv funktionen lov til at sige “det ved jeg ikke”. Skriv det ind i instruktionerne, og test det.
- Afgræns emnet. En funktion, der kun svarer inden for jeres produkt, fejler mindre end en, der svarer på alt.
- Skil det hentede fra det genererede. Tal, datoer og navne, der kommer direkte fra jeres database, bør vises som data og ikke omskrives af modellen.
- Fortæl, hvad funktionen er. Det er både ærligt og et krav i flere tilfælde, se gennemsigtighedskravene.
En kort tekst om, at svar kan være forkerte, er rimelig, men den er ingen erstatning for designet. Den hjælper lidt, hvis brugeren har travlt og stoler på det, der står på skærmen.
Fejlmelding fra brugeren
Giv brugeren en enkel vej. Tommel ned ved svaret, og et felt til, hvad der var galt. Meldingen skal lande et sted, hvor nogen ser den, sammen med samtalen, modelversionen og de data, der blev brugt. Vis gerne kunden, at I har taget den op. Mange kunder melder ikke fejl, så antallet af meldinger er kun en del af billedet. Læs derfor også et udsnit af svarene med faste mellemrum, så langt jeres aftaler med kunderne tillader det.
Hvem retter hvad
Her går det ofte galt, for fejlen ligger mellem flere stole. Lav en lille fordeling, før den første sag kommer:
- Fagligt indhold: produktansvarlig eller en fagperson, fx ved en forkert regel i hjælpeteksten.
- Fremsøgning og data: udvikling, fx når det forkerte dokument blev fundet.
- Instruktioner: udvikling og produkt i fællesskab, fx når funktionen svarer uden for emnet.
- Kundens egne data: kunden, med vejledning fra support, fx ved et forældet dokument hos kunden.
- Modelskift: den, der ejer funktionen, fx når svarene ændrede sig efter en opdatering.
Fordelingen bør stå i supportens vejledning, og én person bør have det samlede ansvar for funktionens kvalitet.
Ansvar og aftaler
Stil to spørgsmål til advokaten, før fejl bliver en tvist. Hvad står der i jeres kundevilkår om AI-genererede svar, og hvad står der i aftalen med modelleverandøren? Vilkår løser sjældent sagen alene, når produktet opfører sig forkert.
Software og AI-systemer nævnes desuden i høringsudkastet til ny lov om produktansvar. Lovforslaget er ikke vedtaget, og ansvaret vedrører skader hos fysiske personer, ikke erhvervskunders driftstab. Læs mere i produktansvar for software. Kan et forkert svar påvirke en patient, skal I også læse software med sundhedsformål.
Rapportér til ledelsen med få tal: antal meldte fejl, hvor mange der er rettet, og hvilken type fejl der fylder mest. Det hører hjemme i teknologien på ledelsesmødet.
Det skal I lade være med
- At love, at fejlene forsvinder med næste model · nyere modeller kan fejle færre steder, men fejlen forsvinder ikke.
- At gemme jer bag en ansvarsfraskrivelse · kunden vurderer jer på, hvordan I håndterer sagen.
- At rette i instruktionerne, før årsagen er fundet · så flytter I blot problemet.
- At lade supporten stå alene med sagen · uden log og en vej videre kan den kun undskylde.
Det skal I kræve af den eksterne
- ☐ En fast gang for fejlsager fra melding til rettelse.
- ☐ En fordeling af, hvem der retter hvad, som alle kender.
- ☐ Krav om log af spørgsmål, svar, kilder og modelversion.
- ☐ Spørgsmål til aftaler og vilkår samlet til jeres advokat.
- ☐ Få tal til ledelsen om fejl og rettelser.
Kilder
- Høringsudkast til lov om produktansvar: software og AI-systemer som eksempler på produkter. L 32 er fremsat med foreslået ikrafttræden 9. december 2026, men ikke vedtaget.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Demoen virker · Kundedata i AI-funktionen
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
