Granska chatbot-leverantörer: DPA, underbiträden och tredjelandsöverföringar

En chatbot-leverantör kan visa upp en övertygande demo, en EU-region och ett färdigt personuppgiftsbiträdesavtal (DPA) – och ändå kvarstår avgörande frågor. Det är nämligen inte bara den synliga chatboten som behandlar data. Ofta är modell-API:er, hosting, vektordatabaser, felanalys, supportverktyg, e-posttjänster och säkerhetskopior inblandade i leveransen. För webbplatsägare är det den verifierbara behandlingskedjan som räknas, inte dataskyddsfloskler på en säljsida.

Denna checklista hjälper dig att göra en strukturerad leverantörsgranskning före inköp och go-live. Den är avsedd som praktisk vägledning och utgör inte juridisk rådgivning. Roller, rättsliga grunder, informationsplikter och överföringsmekanismer måste granskas för det konkreta användningsfallet. Vid förhöjd risk, särskilda kategorier av personuppgifter eller oklara avtalsfrågor bör dataskyddsombud eller kvalificerad juridisk rådgivning kopplas in.

Förstå dataflödet först, utvärdera avtalet sedan

Den centrala frågan är inte bara "Var står servern?", utan: Vilka personuppgifter når vilken juridisk person när, av vilken anledning och hur länge? En besökare kan ange namn, e-postadresser, kundnummer eller fritext i chatten. Dessutom skapas IP-adresser, tidsstämplar, enhetsinformation, sessions-ID:n, konversationshistorik, betyg och tekniska loggar. Även från en påstått anonym konversation kan en personkoppling uppstå genom att kombinera flera egenskaper.

Rita därför en enkel karta över dataflödet före avtalsgranskningen. Den bör minst innehålla webbläsarwidget, chatbot-plattform, kunskapsbas, modellleverantör, analys- och feltjänster, supportåtkomst, säkerhetskopior samt raderingsvägar. För varje station registreras ansvarig aktör, land, ändamål, datakategorier, lagringstid och möjlig fjärråtkomst. Ett påstående om "EU-hosting" besvarar till exempel inte om ett supportteam utanför Europeiska ekonomiska samarbetsområdet (EES) kan få åtkomst till skarpa loggar.

Fastställ dataskyddsroller per ändamål

Om en leverantör är personuppgiftsbiträde eller själv personuppgiftsansvarig för enskilda ändamål framgår av den faktiska verksamheten. Europeiska dataskyddsstyrelsens riktlinjer 07/2020 förklarar gränsdragningen. En leverantör kan till exempel behandla samtalsdata på dokumenterad instruktion, men hävda en annan roll för sina egna säkerhets-, fakturerings- eller produktändamål. Se till att varje ändamål, respektive roll och den rättsliga grunden uttryckligen tilldelas. Ett DPA täcker inte automatiskt leverantörens egna fristående ändamål.

Granska DPA: Obligatoriskt innehåll måste stämma överens med den faktiska tjänsten

Artikel 28 i GDPR kräver att personuppgiftsansvariga endast anlitar personuppgiftsbiträden som ger tillräckliga garantier för lämpliga tekniska och organisatoriska åtgärder. Avtalet måste bland annat fastställa föremål och varaktighet, art och ändamål, typ av personuppgifter, kategorier av registrerade samt den personuppgiftsansvariges rättigheter och skyldigheter. Härtill kommer dokumenterade instruktioner, konfidentialitet, säkerhet, bistånd vid registrerades rättigheter och dataskyddsskyldigheter, radering eller återlämnande samt information och medverkan vid granskningar.

Jämför inte bara DPA-avtalet med en mall, utan med din dataflödeskarta och det prisabonnemang du faktiskt har tecknat. Ett bra avtal beskriver chattdriften, träning respektive indexering av kunskapsbasen, loggning, supportåtkomst och valfria funktioner på ett begripligt sätt. Otydliga samlingsbegrepp som "tjänsteförbättring" bör brytas ned i konkreta data, ändamål, valmöjligheter och roller.

• Instruktion: Är det tydligt att innehåll och metadata endast behandlas för kundens dokumenterade ändamål? Vilken konfiguration gäller som instruktion?
• Användning för modeller: Används promptar, svar eller uppladdat innehåll för allmän modellträning eller produktförbättring? Om nej bör detta vara avtalsmässigt och tekniskt verifierbart; om ja måste roll och rättslig grund utvärderas separat.
• Radering: Finns det konkreta tidsfrister för samtalshistorik, loggar, vektorindex, säkerhetskopior och supportkopior? Vad händer efter att avtalet upphör?
• Säkerhet: Beskrivs åtkomstkontroller, kundseparering (tenantisolering), kryptering, loggning, hantering av sårbarheter och incidentprocesser?
• Bistånd: Reglerar DPA-avtalet exporter, rättelse, radering, registerutdrag, säkerhetsincidenter och eventuella konsekvensbedömningar avseende dataskydd på ett praktiskt sätt?
• Bevis: Finns granskningsrapporter, certifieringar eller andra tillförlitliga bevis tillgängliga, och gäller de för exakt de tjänster och platser som används?

Certifikat och granskningsrapporter kan ge viktiga indikationer, men de ersätter varken granskningen av den konkreta behandlingen eller lämpliga avtalsklausuler. Även ett standardiserat DPA är bara så bra som dess utfyllda bilagor och hur väl det stämmer överens med den tekniska verkligheten.

Underbiträden: Kontrollera namn, uppgifter och ändringar

Enligt artikel 28 punkt 2 i GDPR får ett personuppgiftsbiträde inte anlita ett annat biträde utan ett föregående specifikt eller allmänt skriftligt tillstånd. Vid ett allmänt skriftligt tillstånd ska biträdet informera om planerade ändringar eller utbyten och ge möjlighet att göra invändningar. Europeiska kommissionens frågor och svar om standardavtalsklausuler förtydligar dessutom att enbart kategorier inte räcker: de enskilda underbiträdena måste namnges.

Begär en aktuell, exporterbar lista med juridiskt namn, land, konkret tjänst och berörda data. Kontrollera också om ett företag bara är avtalspart eller faktiskt behandlar data på flera platser. Särskilt relevanta är modell- och embedding-leverantörer, molnhosting, databaser, CDN, övervakning, felanalys, support, e-post och säkerhetskopiering. För varje post måste det framgå om data lagras, bara överförs eller kan läsas av personal.

Ändringsprocessen hör också till utvärderingen: Hur meddelas kunderna, hur lång är förvarningstiden och vad händer vid en motiverad invändning? Ett e-postmeddelande samma dag som ändringen sker, utan möjlighet till teknisk eller avtalsmässig reaktion, är inte mycket värt. Klargör om en alternativ konfiguration, inaktivering av funktionen eller i nödfall en ordnad uppsägning inklusive dataexport är möjlig. För underliggande underbiträden måste samma dataskyddsskyldigheter föras vidare; det första biträdet förblir ansvarigt gentemot den personuppgiftsansvarige för att dessa skyldigheter uppfylls.

Tredjelandsöverföringar: Granska mekanism och faktisk verkan

Kapitel V i GDPR gäller för överföringar av personuppgifter till tredjeländer och för vidareöverföringar. En överföring uppstår inte bara genom permanent lagring; även administrativ åtkomst, supportåtkomst eller datahämtning som görs av en tjänst utanför EES kan vara relevant. Koppla därför ett destinationsland, en mottagare och en överföringsmekanism till varje pil i dataflödeskartan.

1. Beslut om adekvat skyddsnivå: Kontrollera på den löpande uppdaterade listan från Europeiska kommissionen om beslut, område, sektor och konkret mottagare omfattas. Vid begränsade ramverk räcker det inte med att bara ha ett etablerat kontor i ett land.
2. Lämpliga skyddsåtgärder: Om ett lämpligt beslut om adekvat skyddsnivå saknas kan verktyg enligt artikel 46 i GDPR övervägas, beroende på konstellation. Ofta används Europeiska kommissionens standardavtalsklausuler (SCC). Modul, parter, bilagor, överföringsbeskrivning och tekniska åtgärder måste passa den verkliga kedjan.
3. Bedömning av effektivitet: Ett undertecknat SCC-dokument avslutar inte granskningen automatiskt. De slutliga EDPB-rekommendationerna 01/2020 beskriver en riskbaserad process: känn till överföringarna, fastställ verktyg, utvärdera tredjelandets lagstiftning och praxis, fastställ eventuella kompletterande åtgärder, slutför formella steg och gör regelbundna omutvärderingar.

Kompletterande tekniska åtgärder måste passa den konkreta risken. Kryptering är till exempel bara meningsfullt om nyckelhantering, behörigheter och behandlingsändamål beaktas. En modellleverantör som måste behandla klartext och själv har tillgång till nycklarna är en helt annan situation än en ren krypterad backup-lagring. Generella påståenden som "AES-256" eller "GDPR-compliant" ersätter inte denna bedömning. Undantag enligt artikel 49 i GDPR är inte heller någon smidig standardväg för planerad, återkommande SaaS-behandling.

Praktiskt exempel: EU-region med global tjänstekedja

Anta att en chatbot lagrar sin huvuddatabas i Frankfurt. Svaren genereras dock av ett modell-API från ett amerikanskt företag, felrapporter skickas till en annan tjänst och ett globalt supportteam kan öppna samtalsloggar vid eskaleringar. "Datalagring i EU" beskriver då bara en del av systemet.

Denna Due Diligence skiljer på fyra frågor: Vilket innehåll lämnar EES för modellgenerering? Lagras promptar där eller används de för andra ändamål? Innehåller felrapporter klartext, identifierare eller bara minimerade tekniska data? Under vilka villkor kan support utanför EES få åtkomst? Först därefter kan överföringsverktyg, kompletterande åtgärder och kvarstående osäkerhet utvärderas.

Tekniskt sett kan webbplatsägaren ofta minska risken: stänga av onödiga loggfält, maskera känsliga uppgifter i indata före externa anrop, ställa in korta lagringstider, separera känsliga områden från den offentliga boten, isolera kunskapskällor per kund och logga supportåtkomster med krav på godkännande. Hur en offentlig bot och en kundportal separeras rent visas i artikeln Offentlig AI-chatbot vs. Kundportal. För uppladdade filer kompletterar checklistan om Filgranskning, dataskydd och handoff leverantörsgranskningen.

Beslut med trafikljus istället för magkänsla

Granskningspunkt	Grön	Gul	Röd
Dataflöde	Fullständigt, aktuellt och kopplat till det valda avtalet	Enstaka åtkomster eller lagringsplatser oklara	Endast marknadsföringspåstående om EU-region
DPA	Konkreta ändamål, data, tidsfrister och stöd	Kompletteringar krävs före go-live	Ingen tydlig instruktionsbindning eller radering
Underbiträden	Namngiven lista med land och uppgift	Ändringsprocessen är opraktisk	Bara kategorier eller okänd kedja
Tredjelandsöverföring	Mekanism, omfattning och utvärdering påvisad	Åtgärder återstår att verifiera	"EU-server" påstås förklara alla överföringar
Drift	Ägare, granskningsdatum och exit testat	Bevis finns utan fastställd granskning	Ingen uppföljning efter avtalstecknande

En gul punkt behöver inte automatiskt tala emot leverantören. Men den kräver en ansvarig person, en tidsfrist och ett verifierbart godkännandekriterium. En röd punkt i en central behandlingskedja bör blockera den skarpa starten tills avtal, konfiguration eller leverantörsval har anpassats. Dokumentera även accepterade kvarstående risker och vem som har fattat beslutet.

Kompakt go-live-checklista för webbplatsägare

• Dataflödeskarta och roller per ändamål är godkända.
• DPA och bilagor motsvarar abonnemang, funktioner, datatyper och lagringstider.
• Alla underbiträden är dokumenterade med namn, land, uppgift och ändringsprocess.
• Varje tredjelandsöverföring har en lämplig, nyligen granskad mekanism och eventuella kompletterande åtgärder.
• Modellträning eller annan egenanvändning av chattdata är klarlagd och konfigurerad enligt avtal.
• Loggning, supportåtkomst, dataexport, radering och avtalsslut har testats i praktiken.
• Dataskyddsinformation och chattgränssnitt förklarar behandlingen begripligt; användare förleds inte att ange onödiga känsliga uppgifter.
• Det är granskat om en konsekvensbedömning avseende dataskydd krävs för det konkreta användningsfallet.
• En ägare övervakar ändringar hos underbiträden, överföringsmekanismer, funktioner och säkerhetsbevis.

Det lönar sig dessutom att stämma av mot den grundläggande översikten AI-chatbot och GDPR samt guiden för datasnål chatbot-analys. På så sätt behandlas inte inköp, teknisk konfiguration och löpande drift som separata projekt.

Fortsätt granska efter avtalstecknandet

Due Diligence är inte en engångsmapp med PDF-filer. Fastställ minst ett regelbundet granskningsintervall och händelsebaserade kontroller. Utlösande händelser kan vara nya underbiträden, en annan modellleverantör, nya produktfunktioner, ändrade lagringsplatser, en säkerhetsincident, utgående certifikat eller ändringar i ett beslut om adekvat skyddsnivå. Den aktuella underbiträdeslistan och centrala avtalsversioner bör arkiveras med datum så att senare ändringar kan spåras.

Måttet i praktiken är enkelt: Kan ditt team för varje relevant dataflöde förklara vem som behandlar vad och varför, var detta sker, hur länge data ligger kvar, vilka skyddsåtgärder som tillämpas och hur en exit fungerar? När dessa svar är belagda förvandlas ett allmänt dataskyddspåstående till ett välgrundat inköpsbeslut. Om centrala stationer förblir okända bör chatboten ännu inte arbeta med reella besökardata.