Hoppa till innehåll på sidan
IMY-bloggen

En säkrare AI-resa?

Publicerad: 11 september 2025
Välkommen till vår bloggserie i tre delar om AI-säkerhet. Den här serien riktar sig framför allt till dig med viss teknisk bakgrund. Vår förhoppning är dock att fler ska ha nytta av blogginläggen – kanske du som har en framträdande position i hur din organisation använder AI?

Trevlig läsning!

Christelle Bourquin, chef för enheten för säkerhetstillsyn på IMY

Del 1: ”Nya” säkerhetsrisker med AI

Likt andra digitala system medför AI-system olika typer av säkerhetsrisker. Ett växande hot är de olika typer av attacker mot eller manipulering av AI-modeller. Det kan vara hot som dataförgiftning där skadliga data tillförs för att förvränga utdata eller obehörig åtkomst till data.

AI kan som bekant behandla personuppgifter, företagshemligheter och andra icke-offentliga uppgifter. Dessa typer av data är naturligtvis känsliga och behöver på olika sätt skyddas. I de rekommendationer för offentlig sektor som Myndigheten för digitalisering (DIGG) och IMY publicerade tidigare i år, berör vi kraven på just säkerhet vid implementering av generativ AI i offentlig sektor, men även näringslivet har stor nytta av dessa råd.

I denna bloggserie kommer vi därför resonera vidare hur AI-system i sig kan medföra nya risker och ibland förstärka vissa säkerhetsrisker vid sidan av de ”vanliga” cybersäkerhetsriskerna som ”alla” uppkopplade system behöver hantera. Kryptering och starka åtkomstkontroller är viktiga skyddsåtgärder även för AI-system. Vi tänkte här även fokusera på personuppgifter och säkerhet och i det sammanhanget är naturligtvis principen om uppgiftsminimering en central del.

Men vi börjar med att konstatera att det första steget för att bygga och implementera säker AI är att först veta vilken information man har och på vilket sätt den är skyddsvärd. Först därefter kan en säker AI-resa (ett uttjatat begrepp, ja vi vet) ta sin början.

Vi gör inga anspråk på att vara heltäckande – det är inte vårt syfte och utvecklingen pågår alltjämt i skrivande stund – men vi hoppas och tror att detta kan bidra till goda förutsättningar att reflektera kring vad som gör att er AI-resa kanske kan bli en lite säkrare resa ur ett dataskyddsperspektiv. 

Det här menar vi med AI

Ordförklaringar

I denna text använder vi begreppet "AI". En viktig del av AI är "maskininlärning" som innebär att datorer lär sig att hitta mönster och göra förutsägelser med hjälp av stora mängder data. Även om all AI inte bygger på maskininlärning, är det just den tekniken som ligger bakom mycket av dagens AI, till exempel i bildigenkänning, röststyrning, beslutstöd eller vid bedömning av kreditrisk. Vi väljer därför att utgå från den AI som är baserad på maskininlärningstekniken och hur den påverkar dataskyddet. För läsbarhetens skull använder vi dock endast begreppet AI, väl medveten om att all AI inte bygger på maskininlärningstekniken och därmed kan medföra andra utmaningar.
Gå till ordlistsidan

 

Vi börjar från början – vilka risker finns med AI?

Vi börjar från början, vilka säkerhetsrisker kan användning av ett AI-system medföra? I likhet med andra digitala system behöver ett AI-system som behandlar personuppgifter ha en lämplig säkerhetsnivå mot obehörig eller olaglig behandling, oavsiktlig förlust, förstöring eller skada enligt artikel 32 i dataskyddsförordningen, GDPR. Tyvärr finns det ingen universallösning som passar alla. Säkerhetsåtgärderna behöver alltid anpassas efter vilken typ av behandling som sker och den risknivå den medför. AI-systemet kan dock förstärka kända risker och ibland även försvåra kontrollen av dessa risker. När du börjar använda AI-system för att behandla personuppgifter kommer din säkerhet och riskexponering förändras och det kräver att de hanteras och förbyggs.

Till skillnad från ”traditionell” teknik är utgångspunkterna för säkerhetsarbetet inom AI något annorlunda. Tekniskt sett för att AI-systemen är komplexa – de är vanligen beroende av tredjepartskod och består av ett flertal steg och många komponenter. Sen är det ju vi människor. De som idag utvecklar AI-system (vi får väl se hur länge till det är sant för majoriteten av de AI-system som sätts på marknaden) har många olika bakgrunder till exempel mjukvaruingenjörer, datavetare och domänexperter. Tyvärr är det dock inte helt ovanligt att det finns en brist på kunskap om dataskyddslagstiftning och säkerhetskrav i dessa utvecklingsteam eller för den delen i andra delar av organisationen såsom hos produktägare och marknadsavdelningen.

En annan utmaning som inte ska underskattas är att rutiner för säker behandling av personuppgifter inom AI och datavetenskap ännu är under utveckling och, som i förhållande till den snabba teknikutvecklingen av AI-system, än så länge ligger lite efter. Likt annat cybersäkerhetsarbete behöver man som organisation hålla sig uppdaterad och följa den senaste utvecklingen även inom detta.

Så något förenklat beror effekten som AI-system har på säkerheten på teknikens utformning, organisationens komplexitet, dess kompetens och mognad i riskhantering och som alltid databehandlingens art, syfte, sammanhang och ändamål. Man behöver därför anpassa sitt arbete för att kunna säkerställa att personuppgifter som behandlas är skyddade i sin AI-miljö.

AI som bygger på maskininlärning (härefter endast benämnt AI) kräver stora mängder tränings- och testdata som ofta måste väljas ut från sin ursprungliga källa (”source selection”), extraheras och slutligen bearbetas, struktureras och lagras i olika format och på olika platser, ofta hos en tredje part. Detta gäller både data i grundmodellerna och vid så kallad ”finjustering” dvs. verksamhetsanpassad träning av en AI-modell. Detta kan göra det svårare att hålla koll på data och hantera den. Några saker man från en teknisk sida behöver hålla koll på: 

  • Dokumentera all överföring och lagring av personuppgifter. Som i allt annat säkerhetsarbetet är tydliga loggar en förutsättning för att uppfylla kraven på dokumentation och säkerhet.
  • Etablera effektiva rutiner för radering tillfällig behandling eller mellanlagring av data, i till exempel databaser eller testmiljöer så snart de inte längre behövs.
  • Beroende på typen av behandling, fundera på om ni behöva använda någon form av anonymiserings- eller pseudonymiseringsteknik innan data delas internt eller med en extern part. Läs gärna EDPB:s riktlinjer om pseudonymisering.
  • Planera för tid från insamling av rådata och information till den registrerade till att träningen/finjusteringen påbörjas, så att den registrerade har möjlighet att samtycka och därmed har möjlighet att utöva sina rättigheter enligt GDPR. Läs gärna IMY:s webbyhet EDPB yttrar sig över träning och användning av AI-modeller, EDPB:s ställningstagande och samt den ursprungliga art 64.2-frågan från Irland.

De flesta organisationer bygger dock inte AI-system helt själva. Utveckling, träning och drift sker ofta i viss utsträckning av tredje part. Men även med en egen utveckling är man dock ofta beroende av någon annans källkod, oavsett om ens AI helt eller delvist bygger på öppen källkod, vilket innebär både för- och nackdelar. Öppen källkod kan vara effektivt och spara tid och resurser. Men det kan även leda till omfattande beroenden av externa komponenter vilket i sig kan medföra risker om man till exempel inkluderar kod som inte systematiskt granskats vilken då kan innehålla okända sårbarheter. Att införa AI kommer därmed innebära förändringar i en organisations programvaruuppsättning (och möjligen även dess tekniska plattform), vilket kan medföra säkerhetsrisker. Man behöver därför bedöma säkerhetsrisker både för intern och extern kod. Några åtgärder att överväga är att följa kodstandarder, införa kodgranskning, prenumerera på säkerhetsbulletiner och se till att personalen har fått utbildning i säkerhet och att man har en säker utvecklingsmiljö som är separerad från den övriga IT-infrastrukturen.

Tack för att du har läst del 1 av vår bloggserie om AI-säkerhet. Nästa vecka kommer del 2: Så skyddar du din AI-modell mot attacker.

Christelle Bourquin, chef för enheten för säkerhetstillsyn på IMY

Senast uppdaterad: 11 september 2025
Senast uppdaterad: 11 september 2025
Sidans etiketter