Vad händer med företagets data när ni använder AI?

”Används vår data för att träna modellen?” är en viktig fråga, men den räcker inte. Företaget behöver också veta var informationen behandlas, hur länge den lagras, vilka loggar som skapas, vilka underleverantörer som får åtkomst och hur data raderas eller exporteras.

Svaret varierar mellan konsumenttjänster, företagsabonnemang, API-tjänster, privata molnmiljöer och lokalt körda modeller. Det går därför inte att bedöma säkerheten utifrån modellens namn. Den faktiska tjänsten, avtalet och konfigurationen måste granskas.

Vilka data lämnar användaren?

När en medarbetare använder en generativ tjänst kan flera datatyper behandlas:

• prompten, alltså instruktionen eller frågan

• text som klistras in

• uppladdade dokument, bilder eller ljud

• metadata som användare, tid, IP-adress och enhetsinformation

• konversationshistorik och feedback

• resultat som modellen skapar

• loggar från integrationer och säkerhetskontroller

Även en till synes ofarlig fråga kan innehålla namn, kunduppgifter eller affärshemligheter. Det behövs därför både godkända verktyg och tydliga användningsregler.

Skillnaden mellan prompt, dokument, loggar och träningsdata

Begreppen bör hållas isär. Inputdata är det som skickas för att tjänsten ska utföra uppgiften. Lagrad användardata är information som sparas för historik, felsökning eller funktionalitet. Loggdata registreras för drift, säkerhet och uppföljning. Träningsdata används för att förändra modellens parametrar.

En leverantör kan lova att kundens data inte används för modellträning men ändå lagra den under en period för missbruksövervakning eller support. Det kan vara ett rimligt upplägg, men organisationen måste veta att lagringen sker och bedöma den mot informationens krav.

Det räcker inte att fråga om data används för träning. Ni behöver veta var den behandlas, lagras, loggas och av vem.

Används företagets data för modellträning?

Många leverantörer skiljer mellan konsumenttjänster och företags- eller API-erbjudanden. OpenAI uppger exempelvis att data från deras företagsprodukter och API som standard inte används för att träna modeller.[1] Microsoft beskriver särskilda datahanteringsvillkor för Azure-baserade OpenAI-tjänster.[2]

Det betyder inte att alla produkter från samma leverantör har identiska villkor. Inställningar, tilläggsfunktioner och supportärenden kan påverka flödet. Kontrollera därför den exakta produkten, regionen, avtalstexten och aktuell dokumentation. Villkor förändras och bör granskas återkommande.

Om en organisation själv finjusterar en modell eller bygger ett utvärderingsdataset blir den egna datan en del av en separat tränings- eller testprocess. Även då behövs regler för urval, lagring, åtkomst och radering.

Var behandlas och lagras informationen?

Data kan passera flera tekniska lager: användarens enhet, applikationen, integrationsplattformen, modellleverantören, loggtjänster och säkerhetsverktyg. Varje lager kan ha en egen lagringsplats och retentionstid.

Fråga om både datalokalitet och rättslig kontroll. Att en primär databas finns i Sverige eller EU säger inte alltid var support, loggar eller underbiträden finns. Samtidigt är utomeuropeisk leverantör inte automatiskt samma sak som att all information överförs utanför EU. Det faktiska avtals- och systemflödet är avgörande.

Dokumentera följande för varje komponent:

• region för behandling och lagring

• kryptering under överföring och i vila

• nyckelhantering

• standardretention och möjlighet till kortare retention

• säkerhetskopior och raderingsförlopp

• åtkomst för support och driftpersonal

Vilka underleverantörer berörs?

En applikation kan använda en modell från en leverantör, molninfrastruktur från en annan och teknisk övervakning- eller loggtjänster från en tredje. Om personuppgifter behandlas behöver organisationen förstå personuppgiftsansvaret, biträdesrelationer och eventuella underbiträden.

Begär en aktuell lista över underleverantörer och en process för hur förändringar meddelas. Bedöm om nya leverantörer eller regioner kräver förnyad risk- och dataskyddsbedömning.

Personuppgifter och rättslig grund

GDPR gäller när personuppgifter behandlas, oavsett om behandlingen kallas AI. Organisationen behöver ett tydligt ändamål och rättslig grund, ska minimera uppgifterna och måste kunna hantera registrerade rättigheter. Vid hög risk för individers rättigheter och friheter kan en konsekvensbedömning avseende dataskydd, DPIA, krävas.

IMY betonar dataskydd genom hela livscykeln: från behov och datainsamling till användning, uppföljning och avveckling.[3] För generativa tjänster behöver ni också bedöma risken att personuppgifter återges i utdata, hamnar i loggar eller används på ett annat sätt än användaren förstår.

Vad förändras med lokal drift?

En lokalt körd modell kan göra det möjligt att behandla information i en miljö som organisationen eller en svensk driftpartner kontrollerar. Det kan vara avgörande för vissa informationsklasser och krav på datalokalitet.

Lokal drift är dock inte automatiskt säker. Organisationen ansvarar då i högre grad för patchning, åtkomst, modellfiler, övervakning, kapacitet och incidenthantering. Även kringliggande komponenter – dokumentindex, loggar och backup – måste omfattas av säkerhetsarkitekturen.

En hybridlösning kan dirigera olika uppgifter till olika modeller. Öppen information kan behandlas i en extern API-tjänst medan känsligare information går till en lokal modell. För att det ska fungera krävs tillförlitlig klassning och en arkitektur där datan inte oavsiktligt korsar gränsen.

Konsumenttjänst, företagsavtal eller API?

En konsumenttjänst är snabb att börja använda men ger ofta mindre organisatorisk kontroll. Ett företagsavtal kan ge central administration, identitet, avtalade villkor och bättre kontroll över data.

Ett API ger möjlighet att bygga egna gränssnitt, behörigheter och logik, men flyttar mer ansvar till organisationen och dess utvecklingspartner.

Bedömningen bör omfatta hela applikationen, inte bara anropet till modellen. En säker modellkoppling hjälper inte om användargränssnittet visar fel data eller om loggarna är öppna för för många.

Frågor att ställa till leverantören

• Används promptar, dokument, utdata eller feedback för modellträning?

• Vilka data sparas, i vilket syfte och hur länge?

• I vilka regioner behandlas primärdata, loggar och säkerhetskopior?

• Vilka underleverantörer kan få åtkomst?

• Kan retention stängas av eller konfigureras?

• Hur raderas data, inklusive backupkopior?

• Hur isoleras vår data från andra kunders data?

• Vilka personer hos leverantören kan få administrativ åtkomst?

• Hur loggas och meddelas säkerhetsincidenter?

• Kan vi exportera vår data, konfiguration och loggar?

• Vilka villkor gäller om leverantören byter modell eller underleverantör?

• Vilka kontroller behöver vi själva konfigurera?

Kartlägg dataflödet innan ni godkänner användningen

Rita upp flödet från användare till datakälla, applikation, modell och logg. Märk varje steg med informationsklass, ansvarig part, region, retention och tillåten åtkomst. Då blir säkerhetsdiskussionen konkret och möjlig att verifiera.

Koppla kartan till en AI-policy. Medarbetarna behöver veta vilket verktyg som är godkänt för vilken information och vad de ska göra om känsliga uppgifter har matats in av misstag.

Källor

1. OpenAI, Enterprise privacy:
   https://openai.com/enterprise-privacy/

2. Microsoft, Data, privacy, and security for Azure OpenAI Service:
   https://learn.microsoft.com/en-us/azure/foundry/responsible-ai/openai/data-privacy

3. IMY, Vägledning om GDPR och AI:
   https://www.imy.se/verksamhet/dataskydd/innovationsportalen/vagledning-om-gdpr-och-ai/

4. Google Cloud, Zero data retention:
   https://docs.cloud.google.com/gemini-enterprise-agent-platform/resources/zero-data-retention

5. AWS, Data protection in Amazon Bedrock:
   https://docs.aws.amazon.com/bedrock/latest/userguide/data-protection.html