NÄR AI-ANVÄNDNINGEN BLIR EN INCIDENT – FÖRSTA TIMMENS CHECKLISTA PÅ JOBBET
En kollega har klistrat in kunduppgifter i fel AI-tjänst. En AI-agent har skickat något den inte skulle. Ett genererat underlag har redan påverkat en kund eller ett beslut. Den första timmens uppgift är inte att ensam avgöra juridik eller skuld. Den är att stoppa fortsatt skada, säkra rätt fakta och snabbt få händelsen till organisationens incidentansvariga.
Ett första arbetsstöd – inte en egen juridisk bedömning
Checklistan riktar sig till medarbetare, chefer och projektledare som upptäcker en möjlig incident i arbetets AI-användning. Den kompletterar, men ersätter inte, verksamhetens rutiner för informationssäkerhet, dataskydd, arbetsmiljö, kundkommunikation eller andra avvikelser.
En felaktig AI-text är inte automatiskt en personuppgiftsincident. En sådan incident kräver att en säkerhetsincident har påverkat personuppgifter, till exempel genom obehörigt röjande eller åtkomst, förlust, ändring eller förstöring. Samtidigt kan ett AI-fel vara allvarligt av andra skäl: felaktiga kundlöften, diskriminerande urval, obehöriga åtgärder, röjda affärshemligheter eller skadliga instruktioner.
Exempel: ett felaktigt AI-förslag som upptäcks och kasseras kan vara en kvalitetsavvikelse. Om samma underlag samtidigt har skickats med kunduppgifter till en obehörig tjänst behöver händelsen också bedömas mot IMY:s definition av personuppgiftsincident (öppnas i ny flik).
Stoppa fortsatt skada utan att förstöra spåren
- Avbryt flödet. Stoppa fler AI-anrop, automatiska utskick, publiceringar eller beslut från det berörda flödet om du kan göra det inom din behörighet.
- Återkalla inte på måfå. Radera inte chattar, loggar, filer eller konton innan incidentansvarig har sagt hur bevis ska säkras. Börja inte heller ”testa om felet händer igen” med verkliga uppgifter.
- Begränsa åtkomsten. Om ett dokument eller en länk är felaktigt delad, använd verksamhetens godkända sätt att stoppa fortsatt åtkomst. Byt eller spärra en röjd nyckel genom rätt teknisk funktion – kopiera den inte till incidentchatten.
- Skydda människor först. Om händelsen kan orsaka omedelbar fysisk, ekonomisk eller annan allvarlig skada följer du verksamhetens akuta eskaleringsväg direkt.
Målet är kontrollerad inneslutning. Om du saknar behörighet att stoppa systemet skriver du vem som har den och ringer eller larmar enligt rutinen. Vänta inte på ett perfekt formulerat ärende.
Skriv ned sex fakta – utan att skapa en ny läcka
Incidentansvarig behöver en tidslinje och en avgränsning, inte en stor osorterad export. Skriv följande i organisationens godkända incidentkanal:
- När: när händelsen upptäcktes och, om känt, när den började.
- Vad: vilket AI-verktyg, konto, agentflöde eller integration som berörs.
- Handling: vad användaren eller systemet gjorde precis före händelsen.
- Information: vilka typer av uppgifter som kan ha berörts – inte fullständiga kopior.
- Räckvidd: kända personer, kunder, dokument, mottagare eller system som kan vara påverkade.
- Åtgärd: vad som redan har stoppats, spärrats eller lämnats orört.
Notera verktygets namn och version om det syns, klockslag, ärende-ID, modell eller leverantör samt relevanta loggreferenser. Klistra inte in hela prompten om den innehåller samma personuppgifter eller hemligheter som orsakade incidenten. Hänvisa till originalplatsen eller be incidentansvarig ange en skyddad bevisyta.
Eskalera efter konsekvens – inte efter verktygets varumärke
Rapportera till den funktion som äger incidentprocessen. Det kan vara servicedesk, informationssäkerhetsansvarig, dataskyddsombud, jurist, HR, kommunikation eller verksamhetsansvarig. Du behöver inte veta exakt vem som ska göra vad; den beslutade ingången ska fördela ärendet.
| Det som kan ha hänt | Funktion som normalt behöver kopplas in |
|---|---|
| Personuppgifter har röjts, ändrats, förlorats eller blivit åtkomliga för obehörig | Incidentansvarig och dataskyddsfunktion |
| Nyckel, lösenord, intern instruktion eller affärshemlighet kan ha läckt | Informations- eller IT-säkerhet och systemägare |
| AI har skickat, publicerat, beställt eller ändrat något utan rätt kontroll | Systemägare och ansvarig verksamhetschef |
| En person kan ha missgynnats i rekrytering, kredit, vård, myndighetsutövning eller annan känslig process | Ansvarig chef samt relevant juridisk, HR- eller specialistfunktion |
| Felaktigt material har nått kunder, allmänhet eller media | Verksamhetsansvarig och kommunikation |
Kontakta inte leverantören, mottagarna, tillsynsmyndigheten eller media på eget initiativ om inte er rutin ger dig den rollen. För tidig eller motsägelsefull kommunikation kan försvåra både åtgärder och korrekt information till drabbade.
Bekräfta ägare, omfattning och nästa kontrollpunkt
Innan första timmen är slut ska någon namngiven funktion ha tagit emot ärendet. Bekräfta vem som leder arbetet, vem som kan göra teknisk inneslutning, vem som bedömer personuppgifter och andra skyldigheter samt när nästa status lämnas.
Gör en första lista över det ni vet, det ni inte vet och det som måste verifieras. Exempel: ”Vi vet att tre dokument laddades upp med konto X. Vi vet inte om leverantören använde innehållet för andra ändamål. Avtalsägaren kontrollerar villkoren och säkerhetsansvarig hämtar åtkomstloggen.” Den formen hindrar antaganden från att bli rapporterade som fakta.
Om tjänsten ska startas igen krävs ett uttryckligt beslut av rätt ägare. Att felet inte längre syns betyder inte att orsaken är förstådd eller att upprepning är förhindrad.
Mall för första rapporten
En möjlig personuppgiftsincident måste bedömas direkt
Om händelsen är en personuppgiftsincident och det inte är osannolikt att den medför risk för registrerades rättigheter och friheter ska den personuppgiftsansvariga anmäla till behörig tillsynsmyndighet utan onödigt dröjsmål och, om möjligt, inom 72 timmar efter att ha fått vetskap. Om all information inte är klar kan den lämnas i etapper.
Det betyder tre saker i praktiken. För det första gäller tidsfristen inte varje AI-fel. För det andra börjar arbetet inte efter 72 timmar – bedömning och begränsning måste starta genast. För det tredje är det normalt organisationens utsedda funktion, inte den enskilda medarbetaren, som beslutar om och gör anmälan.
En personuppgiftsincident ska dokumenteras även när slutsatsen blir att den inte behöver anmälas: vad som hänt, varför det hände och vilka uppgifter som berörts. Skälen till bedömningen bör dokumenteras med, så att beslutet går att förklara i efterhand. Följ IMY:s vägledning och verksamhetens dataskyddsrutin. Om incidenten gäller annan lagstiftning eller avtal kan helt andra tidsfrister och mottagare gälla.
Fem vanliga misstag under första timmen
- Att fortsätta fråga AI vad som hände. Modellen har inte tillgång till hela loggen och kan skapa en övertygande men felaktig förklaring.
- Att kopiera allt till en gruppchatt. Då kan den ursprungliga exponeringen bli större och svårare att avgränsa.
- Att radera bevis för att ”städa”. Incidentteamet kan behöva tidsstämplar, loggar och originalhändelser för att förstå räckvidden.
- Att lova en orsak eller lösning för tidigt. Säg vad som är stoppat och vad som utreds.
- Att starta om utan ägare. Återstart är ett riskbeslut, inte ett tecken på att felrutan har försvunnit.
Gör checklistan till en del av verksamhetens incidentplan
NIST:s profil för generativ AI rekommenderar tydligt ägarskap, incidentplaner för tredjepartsteknik, regelbundna övningar och anpassning till rapporterings- och dataskyddskrav. Översätt det till ett kort bordsprov: en medarbetare upptäcker att ett AI-verktyg fått fel underlag, flödet stoppas och gruppen går igenom vem som tar emot, var bevis sparas och vem som beslutar om återstart.
Testet ska avslöja telefonnummer som saknas, verktyg som ingen äger och loggar som inte går att få fram. Uppdatera sedan er AI-beslutslogg och AI-policy så att godkända verktyg, incidentväg och ansvar framgår före nästa händelse.
Vanliga frågor om AI-incidenter
Är varje felaktigt AI-svar en personuppgiftsincident?
Nej. En personuppgiftsincident kräver att en säkerhetsincident har påverkat personuppgifter genom exempelvis obehörigt röjande, åtkomst, förlust, ändring eller förstöring. Rapportera ändå händelsen internt så att rätt funktion kan bedöma den.
Har vi alltid 72 timmar på oss?
Nej. 72-timmarsregeln gäller anmälan av vissa personuppgiftsincidenter från det att den personuppgiftsansvariga fått vetskap. Den är inte en allmän tidsfrist för AI-incidenter och betyder inte att arbetet kan vänta.
Ska jag skärmdumpa hela AI-chatten?
Inte slentrianmässigt. Bevara de fakta incidentansvarig behöver, men undvik att sprida personuppgifter, hemligheter eller åtkomstuppgifter till nya kanaler. Följ organisationens beslutade rutin för bevis och loggar.
I samma serie
- AI-beslutslogg på jobbet – visa vad AI bidrog med och vem som gjorde kontrollen.
- Checklista innan du klistrar in information i AI – dra datagränsen före användningen.
- AI för chefer – ansvar, införande och uppföljning i verksamheten.
Officiella källor och vidare läsning
- IMY: Personuppgiftsincidenter (öppnas i ny flik)
- IMY: Hantering av personuppgiftsincidenter (öppnas i ny flik)
- IMY: Checklista vid personuppgiftsincidenter (öppnas i ny flik)
- EUR-Lex: dataskyddsförordningen, särskilt artikel 33–34 (öppnas i ny flik)
- NIST AI 600-1: Generative AI Profile (öppnas i ny flik)