Sådan vurderer du chatbot-udbydere: Databehandleraftale, underdatabehandlere og tredjelandsoverførsler

En chatbot-udbyder kan fremvise en overbevisende demo, en EU-region og en færdig databehandleraftale (DPA) – og alligevel kan der være afgørende spørgsmål, der står ubesvarede hen. For det er ikke kun den synlige chatbot, der behandler data. Ofte er model-API'er, hosting, vektordatabaser, fejlanalyse, supportværktøjer, e-mailtjenester og backups involveret i leveringen af tjenesten. For webstedsejere er det derfor den efterprøvbare behandlingskæde, der tæller, og ikke blot et databeskyttelses-buzzword på en salgsside.

Denne tjekliste hjælper dig med en struktureret udbyderevaluering før indkøb og go-live. Den tjener som praktisk orientering og udgør ikke juridisk rådgivning. Roller, retsgrundlag, oplysningspligter og overførselsmekanismer skal vurderes for det specifikke anvendelsesscenarie; ved forhøjet risiko, særlige datakategorier eller uafklarede kontraktlige spørgsmål bør databeskyttelsesrådgivere eller kvalificeret juridisk rådgivning inddrages.

Forstå datastrømmen først, og vurder derefter kontrakten

Det centrale spørgsmål er ikke kun "Hvor står serveren?", men derimod: Hvilke personoplysninger når frem til hvilken juridisk enhed, hvornår, af hvilken grund og hvor længe? En besøgende kan indtaste navne, e-mailadresser, kundenumre eller fritekst i chatten. Derudover genereres der IP-adresser, tidsstempler, enhedsoplysninger, sessions-ID'er, chat-historik, bedømmelser og tekniske logfiler. Selv en tilsyneladende anonym samtale kan ved at kombinere flere karakteristika blive til personhenførbare data.

Kortlæg derfor en simpel datastrøm, før du gennemgår kontrakten. Den bør som minimum omfatte browser-widget, chatbot-platform, videnbase, modeludbyder, analyse- og fejltjenester, supportadgang, backups samt sletningsprocedurer. For hver station registreres operatør, land, formål, datakategorier, opbevaringsperiode og mulige fjernadgange. En påstand om "EU-hosting" besvarer for eksempel ikke, om et supportteam uden for Det Europæiske Økonomiske Samarbejdsområde (EØS) kan tilgå produktionslogfiler.

Fastlæg databeskyttelsesroller for hvert formål

Om en udbyder er databehandler eller selvstændigt dataansvarlig for specifikke formål, afhænger af den faktiske aktivitet. Det Europæiske Databeskyttelsesråds retningslinjer 07/2020 forklarer afgrænsningen. En udbyder kan f.eks. behandle samtaledata ud fra dokumenterede instrukser, men kræve en anden rolle for visse af sine egne sikkerheds-, afregnings- eller produktformål. Sørg for, at hvert formål, den respektive rolle og retsgrundlaget er udtrykkeligt angivet. En databehandleraftale dækker ikke automatisk udbyderens egne, uafhængige formål.

Tjek databehandleraftalen: Obligatorisk indhold skal passe til den faktiske tjeneste

GDPR artikel 28 kræver, at dataansvarlige kun benytter databehandlere, der stiller de fornødne garantier for at gennemføre passende tekniske og organisatoriske foranstaltninger. Kontrakten skal bl.a. fastsætte genstand og varighed, art og formål, datatyper, kategorier af registrerede samt den dataansvarliges rettigheder og pligter. Dertil kommer dokumenterede instrukser, fortrolighed, sikkerhed, bistand ved registreredes rettigheder og databeskyttelsesforpligtelser, sletning eller returnering samt information og medvirken ved revisioner.

Sammenlign ikke kun databehandleraftalen med en standardtjekliste, men med dit datastrømskort og den faktiske valgte pakke/tarif. En god kontrakt beskriver tydeligt chatdriften, træning eller indeksering af videnbasen, logning, supportadgang og valfrie funktioner. Uklare samlebetegnelser som "serviceforbedring" bør nedbrydes i konkrete data, formål, valgmuligheder og roller.

• Instruks: Er det helt klart, at indhold og metadata kun behandles til kundens dokumenterede formål? Hvilken konfiguration tæller som en instruks?
• Brug til modeller: Anvendes prompts, svar eller uploadet indhold til generel modeltræning eller produktforbedring? Hvis nej, bør dette fremgå kontraktligt og være teknisk efterprøvbart; hvis ja, skal rolle og retsgrundlag vurderes særskilt.
• Sletning: Er der konkrete frister for samtalehistorik, logfiler, vektorindeks, backups og supportkopier? Hvad sker der ved aftalens ophør?
• Sikkerhed: Er adgangskontrol, adskillelse af kunder (tenant isolation), kryptering, logning, sårbarhedsstyring og processer for sikkerhedshændelser beskrevet?
• Bistand: Håndterer databehandleraftalen eksport, berigtigelse, sletning, indsigt, sikkerhedshændelser og eventuelle konsekvensanalyser vedrørende databeskyttelse (DPIA) på en praktisk måde?
• Dokumentation: Er revisionsrapporter, certificeringer eller andre solide beviser tilgængelige, og gælder de for nøjagtigt de anvendte tjenester og lokationer?

Certifikater og revisionsrapporter kan give vigtige indikationer, men de erstatter hverken vurderingen af den konkrete behandlingsaktivitet eller passende kontraktvilkår. Selv en standardiseret databehandleraftale er kun så god som dens udfyldte bilag og overensstemmelsen med den tekniske virkelighed.

Underdatabehandlere: Kontroller navne, opgaver og ændringsprocesser

I henhold til GDPR artikel 28, stk. 2, må en databehandler ikke gøre brug af en anden databehandler (underdatabehandler) uden forudgående specifik eller generel skriftlig godkendelse. Ved en generel godkendelse skal databehandleren underrette om planlagte ændringer og give mulighed for at gøre indsigelse. EU-Kommissionens spørgsmål og svar om standardkontraktbestemmelser (SCCs) præciserer desuden, at generelle kategorier ikke er nok: De enkelte underdatabehandlere skal være navngivet.

Kræv en opdateret, eksporterbar liste med juridisk navn, land, specifik ydelse og berørte data. Tjek desuden, om en virksomhed blot er kontraktpart, eller om den faktisk behandler data på flere lokationer. Særligt relevante er model- og embedding-udbydere, cloud-hosting, databaser, CDN, overvågning, fejlanalyse, support, e-mail og backup. For hver indførsel skal det fremgå, om data opbevares, blot transmitteres eller kan tilgås af personale.

Ændringsprocessen skal også indgå i vurderingen: Hvordan underrettes kunderne, hvor lang er varslingsfristen, og hvad sker der ved en begrundet indsigelse? En e-mail på selve dagen for ændringen uden reel teknisk eller kontraktlig reaktionsmulighed har ringe værdi. Afklar, om en alternativ konfiguration, deaktivering af funktionen eller i sidste instans en ordnet opsigelse med dataeksport er muligt. For underliggende underdatabehandlere skal de samme databeskyttelsesforpligtelser videregives; den primære databehandler forbliver ansvarlig over for den dataansvarlige for opfyldelsen af disse forpligtelser.

Tredjelandsoverførsler: Tjek mekanismen og den reelle virkning

Kapitel V i GDPR gælder for overførsel af personoplysninger til tredjelande og for videreoverførsel. En overførsel sker ikke kun ved permanent opbevaring; administrativ adgang, supportadgang eller dataudtræk foretaget af en tjeneste uden for EØS kan også udgøre en overførsel. Knyt derfor et modtagerland, en modtager og en overførselsmekanisme til hver pil i datastrømskortet.

1. Afgørelse om tilstrækkelighedsniveau: Tjek på den løbende opdaterede liste fra EU-Kommissionen, om afgørelsen, området, sektoren og den konkrete modtager er dækket. Ved begrænsede ordninger er det ikke i sig selv nok blot at være etableret i et land.
2. Fornødne garantier: Hvis der mangler en gældende afgørelse om tilstrækkelighedsniveau, kommer redskaber i henhold til GDPR artikel 46 i spil. Ofte anvendes EU-Kommissionens standardkontraktbestemmelser (SCCs). Modul, parter, bilag, overførselsbeskrivelse og tekniske foranstaltninger skal matche den reelle kæde.
3. Vurdering af effektivitet: Et underskrevet SCC-dokument afslutter ikke automatisk vurderingen. De endelige EDPB-anbefalinger 01/2020 beskriver en risikobaseret proces: Kortlæg overførsler, fastlæg redskab, vurder tredjelandets lovgivning og praksis, fastsæt om nødvendigt supplerende foranstaltninger, gennemfør formelle skridt og foretag regelmæssig genvurdering.

Supplerende tekniske foranstaltninger skal passe til den konkrete risiko. Kryptering er for eksempel kun effektiv, hvis nøglestyring, adgangsrettigheder og behandlingsformålet tages i betragtning. En modeludbyder, der skal behandle klartekst og selv har adgang til nøglerne, udgør en helt anden situation end ren krypteret backup-opbevaring. Generelle påstande som "AES-256" eller "GDPR-compliant" erstatter ikke denne vurdering. Undtagelser i henhold til GDPR artikel 49 er heller ikke en bekvem standardvej for planlagt, tilbagevendende SaaS-behandling.

Praktisk eksempel: EU-region med global tjenestekæde

Antag, at en chatbot gemmer sin primære database i Frankfurt. Svarene genereres dog af en model-API fra en amerikansk virksomhed, fejlrapporter sendes til en anden tjeneste, og et globalt supportteam kan åbne samtallogge ved eskaleringer. "Dataplacering i EU" beskriver i dette tilfælde kun en del af systemet.

Due diligence opdeler dette i fire spørgsmål: Hvilket indhold forlader EØS til modelgenerering? Gemmes der prompts der, eller bruges de til andre formål? Indeholder fejlrapporter klartekst, identifikatorer eller kun minimerede tekniske data? Under hvilke betingelser kan support uden for EØS få adgang? Først derefter kan overførselsredskabet, de supplerende foranstaltninger og den resterende usikkerhed vurderes.

Teknisk set kan webstedsejeren ofte reducere risikoen: Deaktiver unødvendige logfelter, maskér følsomme oplysninger i indtastninger før eksterne kald, fastsæt korte opbevaringsperioder, adskil følsomme områder fra den offentlige bot, isoler videnskilder pr. tenant, og kræv godkendelse samt logning ved supportadgang. Hvordan en offentlig bot og en kundeportal adskilles rent, vises i artiklen Offentlig AI-chatbot vs. Kundeportal. For uploadede filer supplerer tjeklisten om filkontrol, databeskyttelse og handoff udbyderevalueringen.

Beslutning med trafiklys i stedet for mavefornemmelse

Kontrolpunkt	Grøn	Gul	Rød
Datastrøm	Komplet, opdateret og tilpasset den valgte pakke	Enkelte adgange eller opbevaringssteder uafklarede	Kun markedsføringspåstand om EU-region
Databehandleraftale	Formål, data, frister og bistand er konkrete	Tilpasninger nødvendige før go-live	Ingen klar instruksbinding eller sletning
Underdatabehandlere	Navngiven liste med land og opgave	Ændringsproces upraktisk	Kun generelle kategorier eller ukendt kæde
Tredjelandsoverførsel	Mekanisme, omfang og vurdering er dokumenteret	Foranstaltninger skal stadig verificeres	"EU-server" bruges til at forklare alle overførsler
Drift	Owner, review-dato og exit er testet	Dokumentation uden fast review	Ingen overvågning efter aftaleindgåelse

Et gult punkt behøver ikke automatisk at tale imod udbyderen. Det kræver dog en ansvarlig person, en frist og et efterprøvbart godkendelseskriterium. Et rødt punkt i en central behandlingskæde bør blokere for den produktive start, indtil kontrakten, konfigurationen eller udbydervalget er tilpasset. Dokumenter også accepterede restrisici og personen, der har truffet denne beslutning.

Kompakt go-live-tjekliste for webstedsejere

• Datastrømskort og roller for hvert formål er godkendt.
• Databehandleraftale og bilag svarer til valgt pakke, funktioner, datatyper og opbevaringsperioder.
• Alle underdatabehandlere er dokumenteret ved navn med land, opgave og ændringsproces.
• Enhver tredjelandsoverførsel har en passende, aktuelt verificeret mekanisme og eventuelt supplerende foranstaltninger.
• Modeltræning eller anden egenbrug af chatdata er afklaret og konfigureret som aftalt.
• Logning, supportadgang, dataeksport, sletning og aftaleophør er testet i praksis.
• Oplysninger om databeskyttelse og chat-brugerfladen forklarer behandlingen forståeligt; brugere forledes ikke til at indtaste unødvendige følsomme oplysninger.
• Det er vurderet, om en konsekvensanalyse vedrørende databeskyttelse (DPIA) er påkrævet for den specifikke anvendelse.
• En owner overvåger ændringer hos underdatabehandlere, overførselsmekanismer, funktioner og sikkerhedsdokumentation.

Det er desuden værd at sammenholde med den grundlæggende oversigt over AI-chatbot og GDPR samt guiden til dataminimeret chatbot-analyse. Dermed behandles indkøb, teknisk konfiguration og den løbende drift ikke som adskilte projekter.

Fortsæt kontrollen efter aftaleindgåelse

Due diligence er ikke en engangs-PDF-mappe. Fastlæg mindst én fast review-kadence samt hændelsesbaserede kontroller. Udløsere kan være nye underdatabehandlere, en ny modeludbyder, nye produktfunktioner, ændrede opbevaringssteder, en sikkerhedshændelse, udløbne certifikater eller ændringer i en afgørelse om tilstrækkelighedsniveau. Den aktuelle underdatabehandlerliste og centrale kontraktversioner bør arkiveres med dato, så senere ændringer forbliver sporbare.

Den praktiske målestok er simpel: Kan dit team for enhver relevant datastrøm forklare, hvem der behandler hvad og hvorfor, hvor det sker, hvor længe data opbevares, hvilken beskyttelsesforanstaltning der gælder, og hvordan et exit fungerer? Når disse svar er dokumenteret, bliver en generel databeskyttelsespåstand til en solid indkøbsbeslutning. Hvis centrale stationer forbliver ukendte, bør chatbotten endnu ikke arbejde med rigtige besøgsdata.