GDPR och AI är en kombination som fortfarande skapar huvudvärk hos de flesta dataskyddsombud. Den grundläggande utmaningen: AI-system bygger på att lära sig mönster från data, ofta persondata — och GDPR ställer strikta krav på ändamålsbegränsning, lagringsminimering och transparens som är svåra att förena med hur moderna ML-modeller faktiskt fungerar.

Det viktigaste att förstå är principen om ändamålsbegränsning. Om ni samlar in kunddata för att leverera en tjänst kan ni inte utan vidare använda samma data för att träna en modell, även om ni tänkt er att modellen ska förbättra just den tjänsten. Syftet med insamlingen måste vara tydligt formulerat i integritetspolicyn, och användningen av data för ML-träning kräver ofta en ny rättslig grund.

Transparens är en annan utmaning. GDPR ger individer rätt att få förklaringar till automatiserade beslut som påverkar dem. En black-box-modell som fattar kreditbeslut, medicinska rekommendationer eller personalurval uppfyller troligtvis inte detta krav utan ett förklaringslager ovanpå.

Vår rekommendation: genomför en Data Protection Impact Assessment (DPIA) tidigt i projektet — inte som dokumentationsövning utan som ett genuint designverktyg. De flesta compliance-problem vi ser hade kunnat undvikas med en halvdags workshop med rätt personer i rummet.

ISO 27001 är idag närmast obligatorisk för nordiska tech-bolag som säljer till enterprise-kunder. Standarden täcker informationssäkerhet brett: åtkomstkontroll, riskhantering, incident response, fysisk säkerhet. Men den designades i en era innan AI var en produktionskritisk komponent i de flesta system — och det syns.

En av de största luckorna är supply chain-risker kopplade till ML-modeller. Ni certifierar era egna processer, men vad vet ni om säkerhetsegenskaperna hos den foundation model ni bygger på? En modell tränad på poisonad data kan producera systematiskt felaktiga eller manipulerade utfall — ett hot som ISO 27001 inte explicit adresserar.

En annan lucka är adversarial attacks. En välutbildad angripare kan via specifikt konstruerad input manipulera en AI-modells beteende på sätt som inte liknar traditionella cyberhot. Prompt injection mot LLM-baserade system är ett aktuellt exempel — och det finns ännu ingen vedertagen kontroll i 27001-ramverket för det.

Vår rekommendation: komplettera er 27001-implementation med explicita kontroller för AI-specifika hot. Det handlar om modellproveniens (vet ni vad modellen tränades på?), input/output-validering, och regelbunden adversarial testning. Vi hjälper er att bygga det lagret utan att röra er befintliga certifieringsstruktur.