GDPR + AI Act 2026: Vad svenska företag faktiskt måste göra

Många svenska bolag behandlar GDPR och EU:s AI Act som två separata projekt med två separata jurister. I praktiken handlar de om samma sak från olika håll: hur ni hanterar data och de system som bearbetar den. Bygger ni en AI-funktion på personuppgifter aktiveras båda regelverken samtidigt, och de ställer delvis olika krav på samma aktivitet. Den här guiden reder ut var de möts och vad ni faktiskt behöver göra under 2026.

Jag arbetar med det här skärningsfältet inom cybersäkerhet och compliance, och min utgångspunkt är pragmatisk: regelefterlevnad ska byggas in i hur ni redan utvecklar, inte läggas på som ett separat lager efteråt. Det vanligaste jag ser är att bolag antingen överreagerar och stoppar all AI-användning av rädsla, eller underreagerar och rullar ut funktioner utan att ha tänkt igenom datan bakom. Båda ytterligheterna är onödiga. Med rätt struktur är det fullt möjligt att bygga AI-funktioner som både är användbara och regelmässigt försvarbara.

Två regelverk, en gemensam grund

GDPR styr behandling av personuppgifter och har gällt sedan 2018. AI Act är EU:s riskbaserade ramverk för AI-system, som trädde i kraft 2024 och vars bestämmelser fasas in stegvis fram till 2027. De överlappar så fort ett AI-system tränas på eller fattar beslut om personer. GDPR frågar: har ni laglig grund, är behandlingen proportionerlig, kan den registrerade utöva sina rättigheter? AI Act frågar: vilken risknivå har systemet, är det transparent, och har ni rätt styrning kring det?

Det viktiga att förstå är att de inte ersätter varandra. Ett system kan vara helt korrekt enligt GDPR och ändå bryta mot AI Act, eller tvärtom. GDPR är teknikneutralt och bryr sig om personuppgifterna oavsett vad som behandlar dem; AI Act bryr sig specifikt om AI-systemet och dess egenskaper, även när inga personuppgifter är inblandade. När bägge gäller samtidigt behöver ni uppfylla båda, och det är den dubbelheten som gör att ett samlat grepp är effektivare än två parallella spår.

AI Act:s riskklassning i korthet

AI Act delar in system efter risk, och det är klassningen som avgör hur tunga kraven blir:

• Oacceptabel risk, vissa tillämpningar är förbjudna, exempelvis social poängsättning av medborgare.
• Hög risk, system inom till exempel rekrytering, kreditbedömning eller kritisk infrastruktur. Här gäller de strängaste kraven på dokumentation, riskhantering och mänsklig tillsyn.
• Begränsad risk, främst transparenskrav, som att användaren ska veta att den pratar med en chattbot eller ser AI-genererat innehåll.
• Minimal risk, merparten av vanliga tillämpningar, där få specifika krav tillkommer.

De flesta mindre och medelstora bolag jag möter ligger i kategorin begränsad eller minimal risk. Det viktiga är att ni gör klassningen medvetet och dokumenterar slutsatsen, snarare än att anta att ni hamnar lågt. En vanlig fälla är att tänka att en inköpt chattbot eller ett kundtjänstverktyg "bara är en SaaS-tjänst" och därför inte berör er. Men om ni bestämmer hur det används och på vilka data, har ni ett ansvar oavsett vem som byggt verktyget. Klassningen ska göras per användningsfall, inte per produkt.

Roller och ansvar: vem äger frågan?

En praktisk komplikation är att AI Act introducerar roller som inte mappar exakt mot GDPR:s. Under GDPR är ni personuppgiftsansvarig eller personuppgiftsbiträde. Under AI Act kan ni vara leverantör (den som utvecklar eller släpper ett system) eller den som tar i bruk ett system. Samma bolag kan ha olika roller för olika system, och rollen avgör vilka skyldigheter som faller på er. Bygger ni en egen AI-funktion är ni leverantör med ett tyngre ansvar; använder ni en inköpt tjänst ligger en del av ansvaret hos leverantören, men inte allt. Att reda ut vilken roll ni har för varje system är ett av de första stegen, och det är ofta här de praktiska skyldigheterna blir tydliga.

Där GDPR och AI Act faktiskt krockar i vardagen

Den vanligaste konflikten gäller träningsdata. AI Act vill ha spårbarhet och representativ data; GDPR vill ha uppgiftsminimering och tydligt ändamål. En modell tränad på personuppgifter behöver alltså både en laglig grund enligt GDPR och en dokumenterad datahärkomst enligt AI Act. En annan återkommande fråga är rätten till förklaring: GDPR ger registrerade rätt till information om automatiserat beslutsfattande, och AI Act förstärker transparenskraven för system som påverkar människor.

Här gör jag mid-vägs alltid samma sak: kartlägger flödet av personuppgifter genom AI-systemet, från insamling till modell till output, så att vi ser var båda regelverken biter. Den kartan är ofta första gången ett bolag ser helheten. Vill ni ha den gjord systematiskt ingår det i cybersäkerhetsuppdraget.

Praktisk checklista för 2026

• Inventera era AI-system. Lista varje funktion som bygger på AI, inklusive inköpta SaaS-verktyg där leverantören använder era data.
• Riskklassa varje system enligt AI Act och dokumentera bedömningen.
• Koppla in GDPR för de system som behandlar personuppgifter: laglig grund, ändamål, gallring och vid behov en konsekvensbedömning (DPIA).
• Granska era leverantörer. Använder ni en extern modell-leverantör behöver ni veta var data hamnar och om den används för träning.
• Säkra transparens. Användare ska veta när de interagerar med AI, och ni ska kunna förklara väsentliga automatiserade beslut.

Sanktioner: varför det är värt att göra rätt

Båda regelverken har kännbara sanktionsmöjligheter, och det är en del av varför frågan når ledningsnivå. GDPR är känt för sina böter kopplade till global omsättning, och AI Act har en egen, separat sanktionsskala för överträdelser, där de förbjudna tillämpningarna ligger högst. Poängen är inte att skrämmas, för de flesta bolag är den verkliga risken inte en rekordbot utan förlorat kundförtroende och stoppade affärer när en upphandlande motpart ställer frågor ni inte kan svara på. Att ha gjort hemläxan blir därmed lika mycket en kommersiell tillgång som en juridisk försäkring.

Var jag brukar börja

Börja inte med juridiken i ett vakuum. Börja med inventeringen, för utan en korrekt bild av vilka system ni har går det inte att klassa risk eller bedöma laglig grund. När kartan finns blir resten överraskande hanterbart: de flesta system kräver måttliga åtgärder, och de få högrisk-systemen är värda den extra dokumentationen. Jag brukar lägga upp arbetet i tre steg, inventera, klassa, åtgärda, och låta de tunga insatserna landa bara där risken faktiskt motiverar dem. På så sätt blir efterlevnad ett avgränsat projekt med ett slut, inte en diffus oro som ligger och gnager. Se hur jag lägger upp liknande genomlysningar i kundcase.

Relaterat

• NIS2-compliance: Artikel 21-checklistan för svenska bolag
• DORA för fintech: Operativ resiliens, ICT-risk och tredjepartshantering
• Säkerhetsgranskning av AI-applikationer: OWASP LLM Top 10

Vill du ta det vidare?

Jag hjälper svenska bolag att hantera GDPR och AI Act som ett sammanhängande arbete istället för två parallella projekt. Boka ett samtal så går vi igenom era system och var ni står.