Hvad betyder Hændelseshåndtering for AI?
Hændelseshåndtering for AI beskriver, hvad organisationen gør, når systemet giver et alvorligt forkert svar, viser uvedkommende data eller udfører en uønsket handling. Målet er at begrænse konsekvensen hurtigt og samtidig bevare det nødvendige grundlag for at forstå, hvad der skete.
En AI-hændelse er ikke altid et hackerangreb. Forkerte dokumentrettigheder, en ændret integration eller et uheldigt modelskift kan skabe samme behov for afgrænsning. Derfor skal medarbejderne have en enkel måde at melde hændelsen på uden først at afgøre, om den er teknisk, faglig eller juridisk.
Kontrolleret 7. september 2026: Hvis hændelsen involverer personoplysninger, skal den vurderes efter de relevante regler om brud på persondatasikkerheden. Ikke enhver AI-fejl skal anmeldes til Datatilsynet, men vurdering, dokumentation og eventuelle frister må ikke vente på, at alle tekniske detaljer er fuldt afklaret.
Stop den berørte funktion og bevar sporene
Aftal på forhånd, hvem der kan deaktivere et værktøj, tilbagekalde en nøgle eller sætte en vidensbase i karantæne. Begræns indgrebet, så nødvendige andre funktioner kan fortsætte, hvor det er forsvarligt. Gem tidsstempel, versionsoplysninger, request-ID og de nødvendige hændelsesdata med kontrolleret adgang. Undgå at kopiere hele fortrolige samtaler til åbne chatkanaler i forsøget på at koordinere fejlfinding.
Undersøg rækkevidde og godkend genåbning
Find årsagen og hvilke brugere, data eller handlinger der kan være påvirket. Skeln mellem bekræftede hændelser og mulige konsekvenser. Aftal kommunikation og relevante juridiske vurderinger med de ansvarlige. Før genåbning skal rettelsen testes mod hændelsen og beslægtede scenarier. En efterfølgende gennemgang bør resultere i ændringer i adgang, overvågning, test eller oplæring, så læringen bliver en del af systemets drift.
Et eksempel fra praksis
Illustrativt eksempel: En medarbejder opdager, at en intern assistent viser et dokument fra et andet kundeteam. Den ansvarlige slår den berørte søgekilde fra, bevarer request-ID og kontrollerer adgangen i indekset. Teamet undersøger, hvor længe fejlen har været mulig, og hvilke opslag der kan være berørt. Databeskyttelsesansvarlige vurderer de relevante pligter parallelt. Efter rettelse testes to brugerroller og en tilbagekaldt adgang før kilden åbnes igen.
Typiske faldgruber
- At vente på fuld årsagsforklaring før nødvendig afgrænsning og vurdering.
- At slette alle logs og dermed miste mulighed for at undersøge omfanget.
- At genåbne efter en kodeændring uden at teste den oprindelige hændelse.
Det skal I afklare
- Aftal kontaktvej, stopbeføjelse og ansvarlige funktioner.
- Bevar nødvendige spor med begrænset adgang og tydelig tidslinje.
- Vurdér omfang, kommunikation, pligter og kriterier for genåbning.
Spørgsmål og svar
Skal alle fejlsvar håndteres som en alvorlig hændelse?
Nej. Brug en prioritering efter konsekvens og omfang. En forkert formulering og en uautoriseret dataadgang kræver forskellige reaktioner, men begge kan give læring.
Hvad gør vi, hvis årsagen ligger hos modelleverandøren?
Afgræns jeres egen løsning og kontakt leverandøren med nødvendige spor. Jeres ansvar for berørte brugere, data og eventuelle handlinger forsvinder ikke af den grund.
Kilder og videre læsning
De tekniske begreber bygger på nedenstående kilder. Eksemplerne er illustrative og viser, hvordan I kan arbejde med emnet.
- NIST SP 800-61 Rev. 3: Incident Response ↗Primærkilde gennemgået 7. september 2026.
- Datatilsynet: Håndtering af brud på persondatasikkerheden ↗Primærkilde gennemgået 7. september 2026.