AI och GDPR: vad ni får och inte får göra

Det här är en teknisk genomgång från oss som bygger systemen, inte juridisk rådgivning. Är behandlingen omfattande eller känslig ska ni stämma av med jurist, och den här texten är i så fall en bra förberedelse inför det mötet.

Vad GDPR faktiskt kräver när AI används

Den viktigaste insikten först: AI utlöser inga nya regler i GDPR. Förordningen bryr sig inte om att behandlingen sker i en språkmodell i stället för i ett kalkylblad. Reglerna är desamma som de varit sedan 2018. Det som förändras är att AI-verktyg gör det mycket lättare att bryta mot dem av ren slentrian, eftersom det tar två sekunder att klistra in något i ett fönster.

Fem krav är det som blir aktuella i praktiken när ett AI-verktyg införs.

• Laglig grund. Ni behöver en giltig grund för behandlingen, oftast avtal, rättslig förpliktelse eller berättigat intresse. Att uppgifterna redan finns i era system betyder inte automatiskt att de får skickas till en ny mottagare för ett nytt ändamål.
• Ändamålsbegränsning. Uppgifter som samlats in för att fullgöra ett kundavtal får inte utan vidare användas för att träna eller finjustera en modell. Det är ett nytt ändamål och behöver bedömas som ett sådant.
• Uppgiftsminimering. Bara de uppgifter som behövs för uppgiften. Det här är den regel som oftast bryts i AI-sammanhang, och den enda som går att följa till nästan noll kostnad.
• Lagringsminimering. Uppgifterna får inte sparas längre än nödvändigt. I AI-system betyder det främst konversationshistorik, loggar och eventuella mellanlagrade filer, vilket är den del som glöms bort i nio fall av tio.
• Ansvarsskyldighet. Ni ska kunna visa att ni gjort rätt. En kort skriftlig bedömning innan verktyget införs är billigare än att rekonstruera resonemanget i efterhand.

Till detta kommer två saker som ofta blandas ihop med GDPR men är egna spår. Artikel 22 om automatiserat beslutsfattande blir aktuell först om systemet fattar beslut med rättsliga följder eller liknande betydande effekt för en person utan mänsklig inblandning, vilket är ovanligt i den sortens automationer vi bygger, just för att vi lämnar en människa i beslutet. AI-förordningen är en separat regelbok som ställer krav på hur AI-system klassas och dokumenteras. Den ersätter ingenting i GDPR, den läggs ovanpå.

Personuppgifter i promptar: huvudregeln

Att klistra in text i ett AI-verktyg är en överföring av uppgifter till en extern leverantör. Innehåller texten personuppgifter är det en personuppgiftsbehandling, oavsett hur informell handlingen känns för den som gör den.

Huvudregeln vi ger våra kunder är kortare än de flesta policyer: lägg inte in personuppgifter som inte behövs för uppgiften. Behöver ni hjälp att formulera ett svar till en kund behöver modellen sällan veta kundens namn, personnummer, adress eller vad hen köpt tidigare. Ta bort det, skriv kunden, och sätt tillbaka uppgifterna själva i den färdiga texten.

Behövs uppgifterna faktiskt för uppgiften, till exempel när ett system automatiskt ska läsa in ett ärende, då är svaret inte att smyga med det utan att behandla det som vilken annan personuppgiftsbehandling som helst: laglig grund, biträdesavtal, dokumenterat ändamål, bestämd gallring.

Tre kategorier förtjänar en egen mening. Känsliga personuppgifter enligt artikel 9, alltså hälsa, facklig tillhörighet, etniskt ursprung, religion, sexualliv och biometri, har ett starkare skydd och ska normalt inte alls förekomma i ett allmänt AI-verktyg. Uppgifter om lagöverträdelser har egna regler. Uppgifter om barn kräver särskild försiktighet. Ligger något av det i ert flöde är det inte en fråga ni ska lösa i en promptmall.

Molnmodeller, EU-lagring och tredjelandsöverföring

De starkaste modellerna körs hos leverantörer i USA. Det är inte förbjudet, men det gör överföringen till tredjeland till en fråga ni måste ha ett svar på.

Det finns i huvudsak tre vägar, och de skiljer sig mer i praktik än i juridik.

• Amerikansk leverantör under adekvansbeslut eller standardavtalsklausuler. Fungerar, är vanligast, och kräver att ni kontrollerar att just den leverantör och tjänst ni använder faktiskt omfattas. Adekvansbeslut har historiskt ogiltigförklarats två gånger, så bygg inte en arkitektur som blir omöjlig att flytta om det sker igen.
• Samma modeller via en europeisk molnregion. De stora molnleverantörerna erbjuder modellerna med databehandling inom EU. Det löser lagringsfrågan i praktiken och är oftast den enklaste vägen för ett svenskt bolag som vill slippa diskussionen.
• Modell som körs i er egen miljö. Öppna modeller på egen eller europeisk infrastruktur ger full kontroll. Priset är att modellerna är svagare än de bästa kommersiella och att någon måste drifta dem. Det är rätt val när uppgifterna är känsliga nog att motivera kostnaden, och overkill när de inte är det.

Vår erfarenhet är att valet oftast görs på fel grund. Företag väljer egen drift av principskäl och betalar för det i både kvalitet och driftkostnad, eller väljer det enklaste alternativet utan att någon någonsin kontrollerat var uppgifterna faktiskt hamnar. Bestäm i stället utifrån vilka uppgifter som verkligen passerar systemet, och gör om bedömningen om det ändras.

Biträdesavtal och leverantörsval

När en leverantör behandlar personuppgifter för er räkning är ni personuppgiftsansvariga och de är personuppgiftsbiträden. Då krävs ett personuppgiftsbiträdesavtal enligt artikel 28. Det är inte en formalitet ni kan hoppa över för att tjänsten köps med kreditkort.

De flesta AI-leverantörer har ett standardavtal att ingå, ofta i sina företagsvillkor. Fyra saker är värda att kontrollera innan ni skriver på.

1. Används era uppgifter för att träna leverantörens modeller? För företagsavtal är svaret normalt nej, för privatkonton och gratisversioner är det ofta ja om ni inte aktivt stänger av det. Kontrollera det i era egna inställningar, inte i en marknadsföringstext.
2. Var behandlas uppgifterna, och vilka underbiträden finns? Listan över underbiträden ska gå att få fram, och den ändras över tid.
3. Hur länge sparas indata? Många leverantörer sparar konversationer i ett antal dagar för missbruksövervakning även när träning är avstängd. Det är i sig hanterbart, men det ska ni veta om och kunna svara på när frågan kommer.
4. Vad händer vid uppsägning? Radering av data ska vara en beskriven process, inte något ni får hoppas på.

Bygger ni ett eget system tillkommer alla mellanled: var körs koden, vem hostar databasen, vilka loggverktyg används. Kedjan är inte starkare än det svagaste ledet, och det svagaste ledet är oftast ett loggverktyg som ingen tänkt på.

Loggning och gallring

Här uppstår en spänning som är värd att förstå ordentligt, för den återkommer i varje projekt. Ett AI-system behöver loggas för att gå att lita på: ni vill kunna svara på vad systemet läste, vad det föreslog, vem som godkände och när. Samtidigt är loggarna en personuppgiftsbehandling i sig, och de växer tills någon bestämt att de inte får göra det.

Så här brukar vi lösa det.

• Logga händelser och beslut, inte hela innehållet. Att ett ärende av en viss typ skapades från en viss källa och godkändes av en viss användare är oftast tillräckligt för spårbarhet.
• Separera driftloggar från granskningsloggar. Driftloggar behövs i dagar, granskningsloggar kanske i månader. Olika syfte, olika gallringstid.
• Sätt gallringen i systemet, inte i en rutin. En rutin som säger att någon rensar kvartalsvis är en rutin som inte kommer att följas i mars.
• Pseudonymisera där det går. Ett kund-id i loggen i stället för namn och adress ger nästan samma felsökningsvärde till en bråkdel av risken.
• Bestäm gallringstiden innan systemet går i drift. Efteråt blir det alltid en diskussion om vad man kanske kan tänkas behöva, och den diskussionen slutar alltid i att allt sparas.

Checklista i tio punkter

1. Kartlägg vilka personuppgifter som faktiskt passerar verktyget eller flödet. Inte vilka som skulle kunna göra det, utan vilka som gör det.
2. Bestäm laglig grund och ändamål, och skriv ner det. En halv sida räcker.
3. Minimera. Ta bort varje uppgift som inte behövs för uppgiften, redan innan den skickas iväg.
4. Teckna personuppgiftsbiträdesavtal med varje leverantör i kedjan, inte bara med den vars logotyp syns.
5. Kontrollera var behandlingen sker och hur tredjelandsöverföringen är hanterad.
6. Stäng av träning på era uppgifter, och verifiera inställningen i kontot i stället för att lita på förvalen.
7. Bestäm lagringstider för konversationer och loggar, och lägg gallringen i systemet.
8. Bedöm om en konsekvensbedömning enligt artikel 35 behövs. Storskalig behandling, känsliga uppgifter eller systematisk övervakning är signalerna.
9. Uppdatera er information till registrerade så att det framgår att AI-verktyg används i behandlingen.
10. Utbilda dem som faktiskt använder verktyget. Nio av tio incidenter är någon som klistrade in fel sak, inte en teknisk brist.

Punkt tio är den som ger mest per krona. Ett företag med en tydlig ensidig regel som alla känner till ligger bättre till än ett med en tjugosidig policy som ingen har läst.