Sådan kortlægger I underdatabehandlerne for jeres AI-tjeneste
Et kort over underdatabehandlere for AI viser hele kæden af parter der behandler jeres data. Det er sværere end for almindelig SaaS fordi adgangsvejen afgør kæden: Samme model kan have modeludbyderen som direkte databehandler eller som underdatabehandler via en hyperscaler. Tegn part, rolle, land, overførselsmekanisme og retention for hvert led.
Et kort over underdatabehandlere tegner hele kæden af parter der må røre ved jeres data: hvem, i hvilken rolle, i hvilket land. For en almindelig cloudtjeneste er det et rimelig ligetil stykke arbejde. For AI er det mere indviklet, af en grund der er let at overse: Det er adgangsvejen til modellen der afgør hvordan kæden ser ud.
Hvorfor AI bryder mønstret
For en typisk SaaS-tjeneste offentliggør leverandøren en liste over sine underdatabehandlere, og så er sagen klar. AI fungerer anderledes fordi den samme model kan nås på flere måder, og måden bestemmer rollerne.
Har I en direkte aftale med modeludbyderen, er udbyderen jeres databehandler. Når I den samme model via en hyperscaler eller forhandler, bliver modeludbyderen i stedet en underdatabehandler længere nede i kæden, og det er mellemleddet der er jeres databehandler. Modellen er den samme, men kortet ser helt forskelligt ud afhængigt af hvilken dør I gik ind ad.
Derfor kan man ikke kopiere en andens kort. Jeres kæde afhænger af jeres aftaler, ikke af modellens navn.
Hvad der skal fremgå af kortet
Underlaget peger på nogle konkrete kæder som ofte overrasker, og som bør fremgå tydeligt:
- Microsoft Azure som OpenAIs primære underleverandør. Bruger I OpenAIs modeller, er Azure ofte med i kæden, også når I ikke selv har indgået aftale med Microsoft.
- Anthropics afhængighed af AWS og Google for EU-vejen. Claude i EU hviler på hyperscalernes infrastruktur, hvilket tilføjer led til kortet.
- Multimodelplatformenes parallelle kæder. En grænseflade der dirigerer mellem flere modeludbydere, har flere kæder på samme tid: én for hver model den kan kalde.
Hvis de led ikke fremgår, er kortet ikke færdigt, uanset hvor pænt det ser ud.
Kortets kolonner
Et brugbart kort over underdatabehandlere for AI har som minimum disse felter:
| Kolonne | Hvad den indfanger |
|---|---|
| Part | Hvilken virksomhed der behandler data i leddet |
| Rolle | Databehandler eller underdatabehandler |
| Land | Hvor behandlingen sker |
| Overførselsmekanisme | Grundlaget for en eventuel overførsel til tredjelande |
| Retention for hvert led | Hvor længe data gemmes i netop det led |
| Ved modelskifte | Hvad der ændres hvis modellen udskiftes |
Den sidste kolonne er den der oftest mangler, og den vigtigste på sigt. Et modelskifte kan i stilhed erstatte hele kæden bag tjenesten: ny leverandør, ny jurisdiktion, ny retention. Uden den kolonne opdager I det først ved næste gennemgang.
Hvor kortet plejer at slå revner
Selv de der tegner et kort, overser ofte de samme ting. Tre tilbagevendende faldgruber:
- En grænseflade tegnes som én kæde. En multimodelplatform ligner én leverandør, men kan dirigere jeres data til flere modeludbydere afhængigt af forespørgslen. Hver mulig vej er en selvstændig kæde der skal fremgå.
- Man stopper ved den direkte leverandør. At jeres leverandør ligger i EU, siger intet om hvor dens underdatabehandlere befinder sig. Kæden er først kortlagt når I har fulgt den hele vejen ned, ikke kun til det første led.
- Kortet afspejler aftalen, ikke virkeligheden. En direkte aftale og en vej via en hyperscaler giver forskellige kæder for samme model. Tegn ud fra hvordan I faktisk når modellen, ikke hvordan I tror at I gør.
En brugbar kontrol er at spørge for hvert led: “Kan jeg navngive parten, landet og hvad der sker med data her?” Kan I ikke det, er kortet ikke færdigt, uanset hvor ryddeligt det ser ud.
Driften: et kort der lever
Et kort over underdatabehandlere der tegnes én gang og lægges i en mappe, er værdiløst inden for et halvt år. Behandl det som et levende dokument:
- Abonnér på subprocessor-notifikationer fra leverandørerne, så en ændring i deres underdatabehandlere automatisk når frem til jer.
- Versionér kortet, så I kan vise hvordan kæden så ud på et givet tidspunkt. Det er ofte et spørgsmål ved en revision.
- Kobl kortet til jeres DPIA, så en ændring i kæden udløser en gennemgang af konsekvensanalysen i stedet for at blive glemt.
Et lille konkret eksempel: En leverandør meddeler at der kommer en ny underdatabehandler i et tredjeland til. Har I notifikationer, versionering og kobling til jeres DPIA på plads, bliver det en kontrolleret opdatering. Mangler de, opdages det af en revisor, på det værst tænkelige tidspunkt.
At kortlægge kæden korrekt kræver at man forstår både aftalerne og teknikken bag. Vil I have hjælp til at tegne og vedligeholde jeres kort over underdatabehandlere, kan du læse om vores AI-ydelser eller kontakte os med en beskrivelse af hvilke AI-flows I kører i dag.
Ofte stillede spørgsmål
Hvorfor er det sværere at kortlægge underdatabehandlere for AI end for SaaS?
For almindelig SaaS er kæden ofte givet af leverandøren. For AI afgør adgangsvejen hvilken kæde der gælder: Samme model kan have modeludbyderen som direkte databehandler hvis I har en direkte aftale, eller som underdatabehandler hvis I når den via en hyperscaler eller forhandler. Samme model, forskellige kort.
Hvilke parter skal fremgå af kortet for AI?
Alle led der behandler data. Eksempler fra underlaget: Microsoft Azure som OpenAIs primære underleverandør, Anthropics afhængighed af AWS og Google for EU-vejen samt multimodelplatformenes parallelle kæder, hvor flere modeludbydere ligger bag den samme grænseflade.
Hvilke kolonner skal kortet have?
Mindst: part, rolle (databehandler eller underdatabehandler), land, overførselsmekanisme, retention for hvert led, og hvad der sker ved et modelskifte. Den sidste kolonne er let at glemme, men afgørende: Et modelskifte kan i stilhed udskifte hele kæden bag tjenesten.
Hvordan holder vi kortet aktuelt?
Abonnér på leverandørernes subprocessor-notifikationer så I får besked når underdatabehandlerne ændres, versionér kortet så historikken bevares, og kobl det til jeres DPIA så en ændring i kæden udløser en gennemgang af konsekvensanalysen.
Hvad sker der med kortet når vi skifter model?
Et modelskifte kan ændre hele kæden: ny leverandør, ny jurisdiktion, nye underdatabehandlere og ny retention. Derfor er kolonnen for modelskifte vigtig. Den tvinger jer til at tegne det led om der faktisk påvirkes, i stedet for at antage at kortet står stille.