AI, GDPR och EU:s AI-förordning: vad ett svenskt företag behöver ha ordning på

Regelfrågan är den vanligaste anledningen till att ett AI-projekt aldrig kommer förbi diskussionsstadiet i ett svenskt företag. Inte för att svaret är nej — det är det nästan aldrig — utan för att ingen i rummet vet vad frågan egentligen är, och osäkerhet är ett bekvämt skäl att skjuta upp.

Den här artikeln reder ut vad ni själva måste ha ordning på och vad som hör hemma hos en jurist. Den är inte juridisk rådgivning, och den innehåller medvetet inga datum, artikelnummer eller bötesbelopp: de delarna förändras, och en artikel som har fel om dem gör mer skada än en som aldrig nämnde dem. Kontrollera det mot en aktuell källa eller ert ombud.

GDPR ställer i praktiken två frågor

Dataskyddsreglerna är inte AI-specifika. De gäller när personuppgifter behandlas, och en språkmodell är en behandling som vilken annan. För ett AI-projekt kokar det ned till två frågor ni måste kunna besvara i en mening var.

1. Vilka personuppgifter skickas till modellen, och varför?

Det vanligaste felet är att skicka mer än uppgiften kräver, för att det var enklare. Ska modellen sammanfatta ett ärende behöver den ärendetexten — inte hela kundkortet, personnumret och betalningshistoriken. Att begränsa det som skickas är både den enklaste och den mest verkningsfulla åtgärden, och den kostar ingenting att göra rätt från början.

I många flöden går det att gå längre och maskera identifierande uppgifter innan texten lämnar era system. Modellen klarar att sammanfatta ett ärende där kunden heter Kund A.

2. Var behandlas uppgifterna, och av vem?

Ni ska kunna svara på var uppgifterna tar vägen med en mening. Det avgörs av vilken leverantör och vilket driftsätt ni väljer, och det valet ska göras utifrån hur känsligt materialet är — inte utifrån vilket API som var enklast att komma igång med.

Alternativen i fallande känslighetsordning: en modell som körs i er egen miljö, en modell hos en leverantör med drift inom EU, eller ett vanligt API. Det finns fall för alla tre. Poängen är att valet ska vara ett beslut som är nedskrivet, inte ett utfall.

Vad som måste stå i avtalet

Leverantörsavtalet är där de flesta obehagliga överraskningarna sitter. Tre punkter är värda att kontrollera specifikt innan ni börjar bygga:

• Att er data inte används för att träna leverantörens modeller. De flesta företagsavtal säger detta; flera gratisnivåer och konsumentplaner gör det inte. Det är samma leverantör och en helt annan produkt.
• Hur länge inskickat material sparas och i vilket syfte. Loggning för missbruksdetektering är vanligt och oftast rimligt, men det är en lagring och ni behöver veta att den finns.
• Var behandlingen sker geografiskt, och vilket underlag som finns för överföringar utanför EU om sådana förekommer.

De här punkterna hör hemma i ett personuppgiftsbiträdesavtal, och det är ert ombud som ska granska formuleringarna. Er uppgift är att veta att frågorna ska ställas.

AI-förordningen: hur den är byggd

EU:s AI-förordning reglerar inte tekniken utan användningen, och sorterar tillämpningar efter risk. Strukturen är enkel att hålla i huvudet, och den avgör hur mycket arbete som väntar er:

• Förbjuden användning. Ett litet antal tillämpningar som inte får förekomma alls.
• Hög risk. Användning som påverkar människors möjligheter på ett avgörande sätt — rekrytering, kreditbedömning, tillträde till utbildning, vissa delar av vård och myndighetsutövning. Här finns dokumentationskrav, krav på mänsklig kontroll och krav på uppföljning.
• Begränsad risk. Främst krav på öppenhet: en användare ska veta att de talar med ett system och att material är AI-genererat.
• Minimal risk. Merparten av det som byggs i vanliga företag. Inga särskilda krav utöver den lagstiftning som redan gäller.

Det praktiska beskedet: de flesta interna effektiviseringsprojekt — sammanfatta ärenden, läsa fakturor, ta fram utkast — hamnar i den nedersta kategorin. Det som drar upp er i högriskfacket är nästan alltid att systemet fattar eller starkt påverkar ett beslut om en enskild person.

Tidplanen för när de olika delarna börjar tillämpas är stegvis och ska kontrolleras mot en aktuell källa. Det som inte förändras är klassificeringen: gör den tidigt, för den avgör om projektet är en eftermiddags dokumentation eller ett eget arbetspaket.

Fem saker som gör er faktiskt redo

1. En rad per AI-användning i era befintliga register: vad systemet gör, vilka uppgifter det ser, vilken leverantör som används och vem som äger det internt.
2. Klassificera varje användning enligt risknivåerna ovan. Skriv ned motiveringen, inte bara slutsatsen.
3. Kontrollera de tre avtalspunkterna med varje leverantör innan bygget, inte efter.
4. Behåll en människa i beslutet överallt där utfallet påverkar en person. Det är god teknik oavsett vad reglerna kräver.
5. Logga vad systemet gjorde. Ni behöver det för felsökning ändå, och det är samma logg som efterfrågas när någon vill veta hur ett beslut kom till.

Vad som inte är ert jobb

Bedömningen av om en viss användning är högrisk i lagens mening, formuleringarna i biträdesavtalet och den rättsliga grunden för behandlingen är juridiska frågor. Vi levererar underlaget — vad systemet gör, vilka uppgifter det ser, var de behandlas och vad som loggas — och er jurist gör bedömningen. Ett utvecklingsbolag som säger sig kunna avgöra det åt er säger något det inte kan hålla.

Hur den tekniska sidan byggs beskrivs under AI och automation. Ramverket för vilka flöden som bör bli projekt över huvud taget finns i AI för företag, och avvägningen mellan leverantörer och egen drift i bygga eller köpa AI.