Når AI laver en fejl: hvad gør virksomheden bagefter?

I artiklen 10 afsnit

1. Hvem gør hvad, når en AI-løsning har lavet en fejl?
2. Hvad sker der, hvis ingen ved, hvem der ejer hændelsen?
3. Hvilken slags hændelse er det?
4. Fem scenarier: hvad gør I?
5. Klokken 10.14: trin for trin
6. Hvad skal hændelsesnotatet indeholde?
7. Hvordan sikrer I, at hændelsen ikke gentager sig?
8. Hvor skal hændelser registreres og følges op?
9. Hvad kan I gøre nu?
10. Ofte stillede spørgsmål

Hvem gør hvad, når en AI-løsning har lavet en fejl?

Modellen har syv trin: Stop → Begræns → Forstå → Vurdér → Dokumentér → Ret → Følg op. Den er min egen måde at strukturere en hændelse på, ikke en standard. Forudsætningen er, at en hændelsesejer er udpeget på forhånd. Det er den person, der koordinerer, uanset hvem der opdagede fejlen.

1. Stop: Den, der opdager fejlen, stopper brugen eller handlingen og melder den til hændelsesejeren. Det kan betyde at slå en automatisering fra, lukke en agents adgang eller undlade at sende flere svar fra løsningen.
2. Begræns: Hvem er berørt, og kan skaden stoppes? Kan et svar trækkes tilbage, kan kunden kontaktes, og kan en adgang lukkes?
3. Forstå: Hvad skete der, hvornår, med hvilke data, i hvilken løsning og version? Gem eksempler, fx skærmbilleder eller logfiler.
4. Vurdér: Hvilken slags hændelse er det, og skal nogen kontaktes: it-sikkerhed, den, der har ansvar for persondata, ledelsen eller leverandøren?
5. Dokumentér: Skriv hændelsesnotatet, mens det er friskt. Skabelonen står længere nede.
6. Ret: Ret fejlen, ret oplysninger hos dem, der har fået dem, og fortæl dem, der skal vide det.
7. Følg op: Hvad ændres, så det ikke sker igen, hvem gør det, og hvornår tjekkes det?

Hvad sker der, hvis ingen ved, hvem der ejer hændelsen?

Hvis ingen ved, hvem der ejer hændelsen, hvor den registreres, og hvem der følger op, risikerer virksomheden at gentage samme fejl. Konsekvenserne er praktiske:

• Kunden venter. Ingen ved, hvem der skal ringe tilbage.
• Forskellige svar. Hver kollega siger noget forskelligt til kunden.
• Viden forsvinder. Hændelsen huskes af dem, der var med, og ingen andre.
• Samme fejl igen. Ingen ændrer instruktion, test eller kontrol, så fejlen kommer tilbage.
• Intet svar til kunder og ledelse. Spørger nogen, om det er sket før, kan I ikke svare.

Det er ikke en trussel, men det er en uforudsigelig udgift, I selv kan fjerne ved at beslutte rollerne i dag.

Hvilken slags hændelse er det?

Den første vurdering handler om, hvilken slags hændelse I står med. De fire typer overlapper, så en hændelse kan være flere ad gangen:

Fire spørgsmål hjælper vurderingen, uden at de afgør den: Indgår der persondata? Er de kommet til uvedkommende, gået tabt eller ændret? Er en adgang eller konto misbrugt? Har nogen handlet på det forkerte grundlag?

Et brud på persondatasikkerheden er et brud på sikkerheden, der fører til hændelig eller ulovlig tilintetgørelse, tab, ændring, uautoriseret videregivelse af eller adgang til personoplysninger (GDPR, artikel 4, nr. 12). Et brud skal anmeldes til tilsynsmyndigheden uden unødigt ophold og om muligt senest 72 timer efter, at I er blevet opmærksomme på det, medmindre det er usandsynligt, at bruddet indebærer en risiko for de berørte (artikel 33). Indebærer det sandsynligvis en høj risiko, skal de berørte som udgangspunkt også underrettes (artikel 34). Om en konkret hændelse er et brud, er en juridisk vurdering, og jeg er ikke jurist. Derfor skal vurderingen ske hurtigt, og den skal ligge hos en person, der har ansvar for persondata.

For højrisiko-AI-systemer findes der desuden regler om alvorlige hændelser. Udbydere skal indberette dem til de relevante myndigheder, som udgangspunkt senest 15 dage efter, at de har opdaget dem, og kortere ved visse typer hændelser (AI-forordningen, artikel 73). Idriftsættere skal uden unødigt ophold underrette udbyderen og de relevante myndigheder og standse brugen, hvis de har grund til at tro, at brugen indebærer en risiko (artikel 26, stk. 5). Se hvornår AI er højrisiko. Reglerne er set den 3. oktober 2026.

Fem scenarier: hvad gør I?

Fem scenarier viser, hvordan trinene ser ud i praksis. Kolonnen "Kan være" er en retning og ikke en afgørelse. Den kan ændre sig, når I forstår mere.

Hvordan du vælger mellem automatisering, integration og AI-agent, står i artiklen om AI-agent, automatisering eller integration. Og hvem der opdager fejlene først, er ofte de brugere, der kender løsningen bedst. Se skygge-AI for de tilfælde, hvor løsningen slet ikke er kendt.

Klokken 10.14: trin for trin

Hvad skal hændelsesnotatet indeholde?

Et hændelsesnotat er en kort beskrivelse af, hvad der skete. Det behøver ikke være langt, men det skal kunne læses af en, der ikke var der. Skabelonen har otte felter:

Hvordan sikrer I, at hændelsen ikke gentager sig?

Opfølgning er det, der gør en hændelse til læring. Spørg:

• Lå fejlen i data, instruktioner, modellen, kontrollen eller adgangen?
• Hvad ændres: instruktion, test, menneskelig kontrol eller adgang?
• Hvilken test skal tilføjes, så fejlen fanges næste gang?
• Skal dokumentationen opdateres? Se hvad I skal dokumentere.
• Hvem har ansvaret for ændringen, og hvornår tjekkes den?

Fokusér på, hvad der skal ændres, ikke på hvem der skal have skylden. Det er min anbefaling og ikke et lovkrav. Medarbejdere, der frygter at melde fejl, melder færre, og så lærer I ikke noget.

Hvor skal hændelser registreres og følges op?

Hændelser, der ligger i mails og i folks hukommelse, bliver glemt. Der skal et fast sted til at registrere dem, se, hvem der ejer dem, og følge op. Ud fra det, SPOR-siden beskriver, kan SPOR det:

• En hændelse registreres med det samme, og alt bliver logget.
• SPOR viser fristen ved brud på persondatasikkerheden.
• Opfølgning bliver til opgaver med en ansvarlig og en frist.
• En hændelseslog samler hændelserne, så I kan svare, når en kunde eller ledelsen spørger.

SPOR opdager ikke hændelser, afgør ikke, om noget er et brud, og er hverken juridisk rådgivning, certificering eller garanti. Det er stedet, hvor hændelsen skrives ned og følges op. Se SPOR og fra AI-prototype til drift, hvis løsningen er ny.

Hvad kan I gøre nu?

Gør dette, før den næste hændelse sker:

1. Udpeg en hændelsesejer og en stedfortræder.
2. Bestem, hvor hændelser registreres.
3. Skriv ned, hvem der kontaktes: it-sikkerhed, den, der har ansvar for persondata, ledelsen og leverandøren.
4. Øv ét scenarie, fx klokken 10.14, og se, hvor planen går i stå.

Kort sagt: Det vigtige er ikke at love, at fejl aldrig sker. Det er at vide, hvad I gør, når de gør. Har I en AI-løsning og er i tvivl om, hvad der mangler i planen, så send den, så kigger vi på den sammen.

Ofte stillede spørgsmål

Skal enhver AI-fejl registreres?

Min anbefaling er at registrere alle fejl, der har nået en kunde, en beslutning eller en persons data. Små fejl, som brugeren fanger, før de bruges, kan samles i en kort liste. Mønstre i de små fejl viser, hvad der skal ændres.

Hvem skal kontaktes først?

Hændelsesejeren, som er udpeget på forhånd. Derefter den, der har ansvar for it-sikkerhed, og den, der har ansvar for persondata, hvis der kan være tale om persondata. Udpeg dem, før noget sker.

Hvornår er en hændelse et persondatabrud?

Spørg: Indgår der persondata, og er de kommet til uvedkommende, gået tabt eller ændret ved en sikkerhedsfejl? Er svaret ja eller måske, skal en person med ansvar for persondata vurdere det hurtigt, fordi fristen på 72 timer regnes fra, I bliver opmærksomme. Selve vurderingen er en juridisk opgave.

Skal kunden have besked om en AI-fejl?

Har kunden fået en forkert oplysning, bør kunden have den rettet. Om kunden skal have en særlig besked, afhænger af hændelsen. Er det et persondatabrud med høj risiko for de berørte, er der regler om underretning, som en ansvarlig skal vurdere.

Artiklen er generel vejledning og ikke juridisk rådgivning. Udgivet 3. oktober 2026.