Databehandleravtale for AI: Dette må avtalen dekke utover standard
En databehandleravtale for AI-tjenester trenger flere klausuler enn standardavtalen: forbud mot trening uten uttrykkelig samtykke, vilkår for lagringstid og ZDR angitt per endepunkt, et tydelig unntak for misbruksdeteksjon og avtalt varslingstid ved utfasing av modeller. Via en hyperscaler er det skyleverandørens DPA som styrer, og modellselskapet blir underleverandør. Kontroller nøye at begge leddene er regulert.
En databehandleravtale, DPA, er standard ved alle innkjøp av skytjenester. Men for AI-tjenester holder standardordlyden sjelden. Det finnes en rekke spørsmål som bare oppstår når en språkmodell er involvert, og hvis avtalen er taus om dem, har dere et hull. Denne siden går lenger enn den generelle definisjonen av en databehandleravtale og ser på nettopp de AI-spesifikke klausulene.
Hvorfor standard ikke holder
En vanlig databehandleravtale regulerer behandling generelt: hva databehandleren har lov til å gjøre, sikkerhetskrav, sletting når avtalen opphører. Det er nødvendig, men ikke tilstrekkelig for AI fordi AI tilfører tre nye former for atferd:
- Kundedata kan brukes til å trene modellen.
- Data kan lagres ulikt lenge på ulike endepunkter.
- Modeller fases ut, noen ganger med kort varsel, og det tvinger frem en migrering.
Ingen av disse fanges opp av en klausul skrevet for en vanlig database. De må inn som uttrykkelige tillegg.
De fire AI-tilleggene å se etter
Når du leser en databehandleravtale for en AI-tjeneste, bør du aktivt se etter disse:
- Forbud mot trening uten uttrykkelig samtykke. Avtalen skal slå fast at dataene deres ikke brukes til trening med mindre dere aktivt godkjenner det. «Kan reservere seg» er svakere enn «forbudt uten samtykke».
- Vilkår for lagringstid og ZDR per endepunkt. Zero data retention på ett endepunkt hjelper ikke hvis et annet lagrer alt. Vilkårene skal angis per endepunkt, ikke i en generell setning.
- Unntak for misbruksdeteksjon. Nesten alle leverandører beholder noe data for å oppdage misbruk. Det skal gå tydelig frem hva unntaket omfatter, og hvor lenge, ellers uthuler det i det stille kravene deres til lagringstid.
- Avtalt varslingstid ved utfasing av modeller. Dere trenger tid til å validere på nytt før en modell forsvinner. Uten en avtalt varslingstid kan dere bli tvunget til å bytte modell før dere har rukket å gjøre deres egen gjennomgang.
Rollebyttet når dere går via en hyperscaler
En vanlig feil er å regulere bare forholdet til modellselskapet. Kjører dere AI via en hyperscaler, ser bildet annerledes ut.
| Vei inn | Hvilken DPA som styrer |
|---|---|
| Direkte avtale med modellselskapet | Modellselskapets DPA |
| Via hyperscaler | Skyleverandørens DPA styrer; modellselskapet blir underleverandør |
Går dere via en hyperscaler, er det altså skyleverandørens databehandleravtale som er det styrende dokumentet, og modellselskapet havner som underleverandør i kjeden. Kontroller at begge leddene er regulert: at avtalen med skyleverandøren faktisk dekker behandlingen deres, og at underleverandøren er bundet av tilsvarende vilkår. Er bare det ene leddet regulert, finnes det en glipe der ansvaret kan falle mellom to stoler.
Kontrollpunkter sett med kontrollørens øyne
Utover AI-tilleggene finnes det noen punkter som ifølge underlaget ofte avgjør hvordan en kontroll ender:
- SCC-modul og UK-addendum. Riktig modul av standard personvernbestemmelser (SCC) for deres konkrete konstellasjon, og et UK-addendum hvis britiske data er involvert.
- Varslingstid ved avvik (brudd på personopplysningssikkerheten). Standardordlyden er ofte for romslig. Det er et punkt som er verdt å skjerpe i et tillegg slik at dere får beskjed i tide til å handle.
- Revisjonslogger som kan eksporteres. Kan dere ikke hente ut loggene, kan dere heller ikke vise hva som har skjedd. At loggene kan eksporteres, er forskjellen på en behandling som kan dokumenteres, og en som ikke kan det.
Slik går du gjennom avtalen i praksis
Når databehandleravtalen først ligger på bordet, er det lett å drukne i tekst. Et par konkrete grep gjør gjennomgangen håndterbar. Ikke les alt lineært. Let målrettet etter de AI-spesifikke klausulene først, for det er der standardmaler oftest er tause. Søk på ord som «trening», «lagring», «utfasing» og «misbruk», og se hva avtalen faktisk sier, ikke hva dere håper at den sier.
Vær særlig på vakt overfor formuleringer som høres betryggende ut, men ikke forplikter. «Vi bruker normalt ikke kundedata til trening» er ikke det samme som et forbud. «Data slettes innen rimelig tid» er ikke det samme som en angitt lagringstid per endepunkt. Forskjellen mellom en myk intensjonserklæring og en bindende klausul er nettopp det en kontrollør ser etter.
En vanlig fallgruve er å nøye seg med leverandørens standard databehandleravtale fordi den ser komplett ut. Den dekker det generelle, men sjelden AI-tilleggene, og dem må dere ofte be om separat. En annen er å regulere bare modellselskapet og glemme at det er skyleverandørens avtale som styrer når dere går via en hyperscaler. Mangler ett av leddene, kan ansvaret falle mellom to stoler.
Hold avtalen levende
Vilkårene til AI-leverandørene endres ofte. Be derfor om daterte avtaleversjoner slik at dere vet nøyaktig hvilken ordlyd som gjelder på hvert tidspunkt, og valider avtalen på nytt ved endringer i modeller og vilkår. En databehandleravtale som ble skrevet for et år siden, kan i dag regulere en tjeneste som ikke lenger oppfører seg som da avtalen ble signert.
Å gå gjennom en databehandleravtale for AI på riktig måte krever at man forstår både jussen og hvordan tjenesten fungerer teknisk. Vil dere ha en sparringpartner før et AI-innkjøp, kan dere lese om AI-tjenestene våre eller ta kontakt. Denne siden er beslutningsstøtte, ikke juridisk rådgivning.
Ofte stilte spørsmål
Er en vanlig databehandleravtale nok for en AI-tjeneste?
Sjelden. En standard databehandleravtale regulerer behandling generelt, men fanger ikke opp det som er spesifikt for AI: at kundedata kan brukes til trening, at lagringstiden varierer mellom endepunkter, og at modeller fases ut med kort varsel. Disse punktene må legges til som AI-tillegg.
Hvilke AI-spesifikke klausuler bør vi se etter?
Fire tillegg bærer det meste: forbud mot trening uten uttrykkelig samtykke, vilkår for lagringstid og zero data retention angitt per endepunkt, et tydelig unntak for misbruksdeteksjon og en avtalt varslingstid før en modell fases ut, slik at dere rekker å validere på nytt.
Hvem er databehandler når vi kjører AI via en hyperscaler?
Via en hyperscaler er det skyleverandørens DPA som styrer, og modellselskapet blir underleverandør. Det betyr at dere må kontrollere at begge leddene er regulert: at avtalen med skyleverandøren dekker behandlingen deres, og at underleverandøren er bundet av tilsvarende vilkår.
Hvilke kontrollpunkter er særlig viktige?
Ifølge underlaget: riktig SCC-modul og UK-addendum for overføringer, varslingstid ved avvik, som ofte er verdt å skjerpe i et tillegg, og revisjonslogger som kan eksporteres slik at dere kan vise hva som har skjedd. Disse tre punktene dukker ofte opp i en kontroll.
Hvordan holder vi databehandleravtalen oppdatert over tid?
Be om daterte avtaleversjoner, så dere vet nøyaktig hvilken ordlyd som gjelder, og valider avtalen på nytt ved endringer i modeller og vilkår. Vilkårene til AI-leverandørene endres ofte, og en databehandleravtale som ikke er fulgt opp, kan regulere en tjeneste som ikke lenger ser ut som da avtalen ble skrevet.