Databehandleraftale for AI: hvad aftalen skal dække ud over standarden
En databehandleraftale for AI-tjenester kræver flere klausuler ud over standardaftalen: forbud mod træning uden udtrykkelig godkendelse, vilkår for retention og ZDR angivet pr. endpoint, en klar undtagelse for misbrugsdetektion og en aftalt varslingsfrist ved udfasning af modeller. Ad hyperscalervejen er det cloududbyderens aftale der styrer, og modeludbyderen bliver underdatabehandler. Kontrollér nøje at begge led er reguleret.
En databehandleraftale (på engelsk DPA) er standard ved ethvert indkøb af cloudtjenester. Men til AI-tjenester er standardordlyden sjældent nok. Der er en række spørgsmål som kun opstår når en sprogmodel er involveret, og hvis aftalen tier om dem, har I et hul. Denne side går ud over den generelle definition af en databehandleraftale og ser på netop de AI-specifikke klausuler.
Hvorfor standarden ikke er nok
En almindelig databehandleraftale regulerer behandling i al almindelighed: hvad databehandleren må gøre, sikkerhedskrav og sletning ved aftalens ophør. Det er nødvendigt, men ikke tilstrækkeligt for AI fordi AI bringer tre nye forhold med sig:
- Kundedata kan bruges til at træne modellen.
- Data kan gemmes i forskellig tid på forskellige endpoints.
- Modeller udfases, nogle gange med kort varsel, hvilket tvinger en migrering igennem.
Ingen af dem fanges af en klausul skrevet til en almindelig database. De skal ind som udtrykkelige tillæg.
De fire AI-tillæg du skal kigge efter
Når du læser en databehandleraftale for en AI-tjeneste, så kig aktivt efter disse:
- Forbud mod træning uden udtrykkelig godkendelse. Aftalen skal slå fast at jeres data ikke bruges til træning medmindre I aktivt godkender det. “Kan fravælges” er svagere end “forbudt medmindre godkendt”.
- Vilkår for retention og ZDR pr. endpoint. Zero data retention på ét endpoint hjælper ikke hvis et andet gemmer alt. Vilkårene skal angives pr. endpoint, ikke i en generel sætning.
- Undtagelse for misbrugsdetektion. Næsten alle leverandører beholder visse data for at opdage misbrug. Det skal fremgå klart hvad undtagelsen omfatter og hvor længe. Ellers udhuler den stille og roligt jeres krav til retention.
- Aftalt varslingsfrist ved udfasning af modeller. I har brug for tid til at genvalidere før en model forsvinder. Uden en aftalt varslingsfrist kan et skifte blive tvunget igennem hurtigere end jeres egen gennemgang kan følge med.
Rolleskiftet ad hyperscalervejen
En almindelig fejl er kun at regulere forholdet til modeludbyderen. Kører I AI via en hyperscaler, ser billedet anderledes ud.
| Vej ind | Hvilken aftale styrer |
|---|---|
| Direkte aftale med modeludbyderen | Modeludbyderens databehandleraftale |
| Via hyperscaler | Cloududbyderens databehandleraftale styrer; modeludbyderen bliver underdatabehandler |
Ad hyperscalervejen er det altså cloududbyderens databehandleraftale der er det styrende dokument, og modeludbyderen ender som underdatabehandler i kæden. Kontrollér at begge led er reguleret: at cloududbyderens aftale faktisk dækker jeres behandling og at underdatabehandleren er bundet af tilsvarende vilkår. Er kun det ene led reguleret, er der en sprække hvor ansvaret kan falde mellem to stole.
Verifikationspunkter set fra en auditors perspektiv
Ud over tillæggene er der nogle punkter som ifølge kildematerialet ofte afgør hvordan en gennemgang ender:
- SCC-modul og UK-addendum. Det rette modul af standardkontraktbestemmelserne til jeres konkrete konstellation, og et UK-addendum hvis britiske data er involveret.
- Frist for underretning om sikkerhedshændelser. Standardordlyden er ofte for rummelig. Det er et punkt der er værd at skærpe i et tillæg så I får besked i tide til at handle.
- Auditlogs der kan eksporteres. Kan I ikke trække logfilerne ud, kan I heller ikke vise hvad der er sket. At logfilerne kan eksporteres, er forskellen mellem en behandling der kan dokumenteres, og en der ikke kan.
Sådan gennemgår du aftalen i praksis
Når databehandleraftalen først ligger på bordet, er det let at drukne i tekst. Et par konkrete greb gør gennemgangen overkommelig. Læs ikke det hele lineært igennem. Kig målrettet efter de AI-specifikke klausuler først, for det er dér standardskabeloner oftest tier. Søg på ord som “træning”, “retention”, “udfasning” og “misbrug”, og se hvad aftalen faktisk siger, ikke hvad I håber den siger.
Vær særligt på vagt over for formuleringer der lyder betryggende, men ikke forpligter. “Vi bruger normalt ikke kundedata til træning” er ikke det samme som et forbud. “Data slettes inden for rimelig tid” er ikke det samme som en angivet retention pr. endpoint. Forskellen mellem en blød hensigtserklæring og en bindende klausul er præcis det en auditor kigger efter.
En almindelig faldgrube er at nøjes med leverandørens standardaftale fordi den ser komplet ud. Den dækker det generelle, men sjældent AI-tillæggene, og dem skal I ofte bede om separat. En anden er kun at regulere modeludbyderen og glemme at det ad hyperscalervejen er cloududbyderens aftale der styrer. Mangler et af leddene, kan ansvaret falde mellem to stole.
Hold aftalen levende
AI-leverandørernes vilkår ændres ofte. Bed derfor om daterede aftaleversioner så I ved præcis hvilken ordlyd der gælder på ethvert tidspunkt, og genvalidér aftalen ved ændringer i modeller og vilkår. En databehandleraftale der blev skrevet for et år siden, kan i dag regulere en tjeneste som ikke længere opfører sig som da aftalen blev underskrevet.
At gennemgå en databehandleraftale for AI korrekt kræver at man forstår både jura og hvordan tjenesten fungerer teknisk. Vil I have en sparringspartner før et indkøb af AI, kan du læse om vores AI-tjenester eller kontakte os. Denne side er beslutningsstøtte, ikke juridisk rådgivning.
Ofte stillede spørgsmål
Er en almindelig databehandleraftale nok til en AI-tjeneste?
Sjældent. En standardaftale regulerer behandling generelt, men fanger ikke det der er specifikt for AI: at kundedata kan bruges til træning, at retention varierer mellem endpoints og at modeller udfases med kort varsel. De punkter skal tilføjes som AI-tillæg.
Hvilke AI-specifikke klausuler skal vi kigge efter?
Fire tillæg bærer det meste: forbud mod træning uden udtrykkelig godkendelse, vilkår for retention og zero data retention angivet pr. endpoint, en klar undtagelse for misbrugsdetektion og en aftalt varslingsfrist før en model udfases så I når at genvalidere.
Hvem er databehandler når vi kører AI via en hyperscaler?
Ad hyperscalervejen er det cloududbyderens databehandleraftale der styrer, og modeludbyderen bliver underdatabehandler. Det betyder at I skal kontrollere at begge led er reguleret: at cloududbyderens aftale dækker jeres behandling og at underdatabehandleren er bundet af tilsvarende vilkår.
Hvilke verifikationspunkter er særligt vigtige?
Ifølge kildematerialet: det rette SCC-modul og UK-addendum ved overførsler, en frist for underretning om sikkerhedshændelser, som ofte er værd at skærpe i et tillæg, og auditlogs der kan eksporteres så I kan vise hvad der er sket. De tre punkter dukker ofte op i en gennemgang.
Hvordan holder vi databehandleraftalen aktuel over tid?
Bed om daterede aftaleversioner så I ved præcis hvilken ordlyd der gælder, og genvalidér aftalen ved ændringer i modeller og vilkår. AI-leverandørernes vilkår ændres ofte, og en databehandleraftale som ingen har fulgt op på, kan regulere en tjeneste der ikke længere ser ud som da aftalen blev skrevet.