Så ritar ni en underbiträdeskarta för er AI-tjänst

En underbiträdeskarta ritar hela kedjan av parter som får röra era data – vem, i vilken roll, i vilket land. För vanlig molntjänst är det ett hyfsat rakt arbete. För AI är det knepigare, av en anledning som är lätt att missa: det är vägen in i modellen som avgör hur kedjan ser ut.

Varför AI bryter mönstret

För en typisk SaaS-tjänst publicerar leverantören en lista på sina underbiträden och saken är klar. AI fungerar annorlunda eftersom samma modell kan nås på flera sätt – och sättet bestämmer rollerna.

Har ni direktavtal med modellbolaget är det bolaget ert biträde. Når ni samma modell via en hyperskalare eller återförsäljare blir modellbolaget i stället en underbehandlare längre ner i kedjan, och det är mellanledet som är ert biträde. Modellen är densamma, men kartan ser helt olika ut beroende på vilken dörr ni gick in genom.

Det är därför man inte kan kopiera någon annans karta. Er kedja beror på era avtal, inte på modellens namn.

Vad som ska synas i kartan

Underlaget pekar ut några konkreta kedjor som ofta överraskar och som bör framgå tydligt:

• Microsoft Azure som OpenAI:s primära underleverantör. Använder ni OpenAI:s modeller finns Azure ofta med i kedjan, även när ni inte tecknat något med Microsoft direkt.
• Anthropics beroende av AWS och Google för EU-vägen. Claude i EU vilar på hyperskalarnas infrastruktur, vilket lägger till led i kartan.
• Multimodellplattformarnas parallella kedjor. Ett gränssnitt som dirigerar mellan flera modellbolag har flera kedjor samtidigt – en per modell den kan anropa.

Om dessa led inte syns är kartan inte färdig, hur snygg den än ser ut.

Kartans kolumner

En användbar underbiträdeskarta för AI har åtminstone dessa fält:

Den sista kolumnen är den som oftast saknas – och den viktigaste på sikt. Ett modellbyte kan tyst ersätta hela kedjan bakom tjänsten: ny leverantör, ny jurisdiktion, ny retention. Utan den kolumnen upptäcker ni det först vid nästa granskning.

Var kartan brukar spricka

Även den som ritar en karta missar ofta samma saker. Tre återkommande fallgropar:

• Ett gränssnitt ritas som en enda kedja. En multimodellplattform ser ut som en leverantör men kan dirigera er data till flera modellbolag beroende på fråga. Varje möjlig väg är en egen kedja som måste synas.
• Man stannar vid förstahandsleverantören. Att er leverantör ligger i EU säger inget om var deras underbehandlare finns. Kedjan är bara kartlagd när ni följt den hela vägen ner, inte till första ledet.
• Kartan speglar avtalet, inte verkligheten. Ett direktavtal och en väg via hyperskalare ger olika kedjor för samma modell. Rita utifrån hur ni faktiskt når modellen, inte hur ni tror att ni gör.

En användbar kontroll är att för varje led fråga: “kan jag namnge parten, landet och vad som händer med datan här?”. Kan ni inte det är kartan inte klar, oavsett hur prydlig den ser ut.

Driften: en karta som lever

En underbiträdeskarta som ritas en gång och läggs i en mapp är värdelös inom ett halvår. Behandla den som ett levande dokument:

1. Prenumerera på subprocessor-notiser från leverantörerna, så att en ändring i deras underbiträden når er automatiskt.
2. Versionera kartan, så att ni kan visa hur kedjan såg ut vid en viss tidpunkt – ofta en fråga i en revision.
3. Koppla kartan till DPIA:n, så att en förändring i kedjan triggar en översyn av konsekvensbedömningen i stället för att glömmas bort.

Ett litet konkret exempel: en leverantör meddelar att en ny underbehandlare i tredje land tillkommer. Har ni notiser, versionering och koppling till DPIA på plats blir det en kontrollerad uppdatering. Saknas de upptäcks det av en revisor, vid sämsta möjliga tillfälle.

Att kartlägga kedjan rätt kräver att man förstår både avtalen och tekniken bakom. Vill ni ha hjälp att rita och underhålla er underbiträdeskarta kan du läsa om våra AI-tjänster eller höra av dig med en beskrivning av vilka AI-flöden ni kör idag.