Blog / claude-compliance
Claude connectors og GDPR: hvor ligger dine data?
Claude connectors og GDPR i praksis: hvor de 34 mest brugte connectors gemmer data, hvornår du får EU-dataresidens, og de fire valg der gør din brug lovlig.
Indhold (9 afsnit)
- En connector er ikke et datalager - den er en bro
- De tre lag, data kan forlade EU igennem
- Hvor de mest brugte Claude connectors gemmer data
- De fem dimensioner, der gør connector-brugen forsvarlig
- Et dansk eksempel: webshoppen med tre connectors
- Tre fælder, når du forbinder Claude connectors
- Hvad det koster - og hvad det koster at lade være
- Mini-tjekliste til næste gang du forbinder en connector
- FAQ
- Kilder og retsgrundlag
De fleste tror, at når de forbinder Claude til Notion eller HubSpot, så "ryger data ind i Claude". Det gør de ikke. En connector er ikke et datalager - den er en bro. Og det skifte i forståelse er hele forskellen på, om du kan svare klart, når nogen spørger, om jeres brug af Claude connectors lever op til GDPR.
For data ligger ikke "i Claude". Det ligger hos den tjeneste, broen fører hen til - Notion, Slack, Stripe - og det er den tjenestes hosting, aftaler og residens-politik, der afgør lovligheden. Den gode nyhed er, at det gør spørgsmålet håndterbart: du skal ikke vente på, at "Claude bliver godkendt". Du skal træffe nogle få, konkrete valg per connector.
En connector er ikke et datalager - den er en bro
Forestil dig, at du spurgte: "Er en USB-port GDPR-compliant?" Spørgsmålet giver ikke mening. Porten er bare en forbindelse - det afgørende er, hvad du sætter i den, og hvor de data så ender. Sådan er det også med en connector. Den samme bro kan føre til en tjeneste, der hoster i Frankfurt under en stram databehandleraftale, eller til en, der lagrer alt i USA uden EU-option.
Derfor er "er Claude connectors GDPR-compliant?" det forkerte spørgsmål. Det rigtige er: hvor fører den enkelte bro hen, og har vi styr på den anden ende? Det er den samme logik, jeg gennemgår i den samlede guide til at bruge Claude GDPR-compliant - bare anvendt på de tjenester, du kobler på.
De tre lag, data kan forlade EU igennem
Når folk spørger "hvor havner mine data?", tænker de på ét sted. I virkeligheden er der tre, og de skal styres hver for sig.
Lag 1 - Anthropic, selve modellen. Når Claude behandler din tekst, sker det på Anthropics infrastruktur. På en kommerciel plan er det dækket af Anthropics databehandleraftale, og vil du have behandlingen i EU, kører du Claude via AWS Bedrock i en EU-region.
Lag 2 - connectoren, tjenesten. Det er her, dine egentlige data bor: i Notion, i Slack, i HubSpot. Om det er konformt afhænger udelukkende af den enkelte leverandør - hvor de hoster, om der findes en databehandleraftale, og om du kan få EU-residens. Det er det lag, tabellen nedenfor handler om.
Lag 3 - selve forbindelsen. Connectoren kører over en sikker, OAuth-baseret protokol, og data flyder direkte mellem Claude og tjenesten. Det er ofte her, den reelle USA-eksponering opstår - ikke i modellen - fordi mange af de tjenester, du forbinder, kører på amerikansk infrastruktur.
Pointen: du kan godt køre modellen i EU og stadig sende data vestpå, fordi en connector peger på en USA-hostet tjeneste. Et grønt lag redder dig ikke, hvis de to andre er røde.
| Lag | Hvad det er | Hvem har ansvaret | Kan data ende i USA her? |
|---|---|---|---|
| 1. Modellen | Claude behandler din tekst | Anthropic - via din databehandleraftale eller Bedrock | Ja - medmindre du kører EU-hosting |
| 2. Connectoren | Tjenesten, dine data bor i (Notion, Stripe ...) | Den enkelte leverandør | Ja - det afhænger helt af tjenesten |
| 3. Forbindelsen | Broen mellem Claude og tjenesten | Dig - hvad du sender, plus metadata | Ja - login og metadata rammer ofte USA |
Kilde: De tre lag i en Claude-opsætning med connectors
Hvor de mest brugte Claude connectors gemmer data
Her er de connectors, danske virksomheder oftest kobler på, sorteret efter hvor let du får EU-dataresidens. Den fulde version med kilder, jurisdiktion og certificeringer ligger i et separat regneark.
| Connector | EU-dataresidens | Krav | Databehandleraftale |
|---|---|---|---|
| Microsoft 365 | Ja - EU Data Boundary (default for EU/EFTA) | Tenant i EU/EFTA | Ja |
| Salesforce | Ja - Hyperforce EU | Vælges ved provisionering | Ja |
| Supabase / Sentry / Linear | Ja - alle planer | Vælg EU-region ved oprettelse | Ja |
| Notion / Slack / HubSpot | Kun Enterprise / betalt plan | Opgradér + sæt EU-region | Ja |
| Box / Airtable / Figma / Canva | Kun Enterprise | Aktivér EU-residens | Ja |
| Zapier / Klaviyo / Apollo | Nej - kun USA | Kør på SCC'er + DPF | Ja |
| Stripe / PayPal / Plaid | Nej / global overførsel | Selvstændig dataansvarlig | Ja |
Kilde: Leverandørernes egne trust-/DPA-sider, verificeret juni 2026
Læg mærke til mønsteret: næsten alle har en databehandleraftale, men EU-residens er som regel låst bag en Enterprise-plan. Og en håndfuld tilbyder den slet ikke - uden at det gør dem ulovlige.
Tre grønne, tre gule og en rød på samme arbejdsgang er helt normalt. Derfor giver det ikke mening at spørge, om "Claude connectors er lovlige" som ét spørgsmål - du må gå tjeneste for tjeneste. Det lyder som mere arbejde, end det er: de fleste virksomheder bruger en håndfuld connectors, ikke tredive, og når først kortlægningen er lavet, er den næsten vedligeholdelsesfri.
De fem dimensioner, der gør connector-brugen forsvarlig
Når et værktøj rammer både teknik, mennesker og jura, holder det ikke at smide ansvaret over hegnet til IT alene. Jeg bruger den samme fem dimensioner-tilgang her, som jeg lægger på al AI-brug: teknologi, processer, kompetencer, kultur og governance. En connector-stack, der har styr på fire af dimensionerne og glemmer den femte, er ikke næsten i mål - den er ikke i mål.
Oversat til connector-sproget bliver de fem dimensioner til fem konkrete spørgsmål:
- Teknologi: Hvilke connectors kobler vi på, og kan de sættes til EU-residens? Det er valget i tabellen ovenfor.
- Processer: Hvilke data sender vi gennem broen, og har vi en databehandleraftale i hver ende? Dataminimering (GDPR artikel 5) starter her.
- Kompetencer: Ved medarbejderne, hvilke connectors de må forbinde, og hvilke data der ikke må røre en bestemt tjeneste?
- Kultur: Bliver reglen fulgt i en travl hverdag - eller forbinder folk bare den hurtigste connector?
- Governance: Hvem ejer beslutningen om, hvilke connectors der er godkendt?
Det smukke er, at ingen af spørgsmålene er nye. Det er præcis den vurdering, I laver for ethvert andet databehandlersystem. En connector er bare endnu en dør, der skal gennem den samme governance.
Et dansk eksempel: webshoppen med tre connectors
Tag en dansk e-commerce-virksomhed, der lader Claude arbejde på tværs af tre connectors: HubSpot (CRM), Klaviyo (e-mailflows) og Stripe (betalinger). Tre broer, tre vidt forskellige svar.
HubSpot kan flyttes til et EU-datacenter i Tyskland - men kun på en betalt plan, og det kræver, at kontoen oprettes eller migreres derhen. Klaviyo hoster udelukkende i USA; her er der ingen EU-residens at få, så grundlaget er databehandleraftalen og SCC'erne - og følsomme kategorier som helbred må holdes helt ude. Stripe er den, folk overser: Stripe er selvstændig dataansvarlig for svindel- og compliance-formål, ikke kun databehandler, så samspillet skal stå eksplicit i webshoppens privatlivspolitik.
Samme AI, samme arbejdsgang - men tre forskellige juridiske konklusioner, alt efter hvilken bro data løber over. Det er hele pointen med at se på connector-laget for sig.
Tag så en B2B-rådgivningsvirksomhed, der kører Claude på Slack, Notion og Salesforce i stedet. Her vender svarene igen: Slack kræver Enterprise Grid for EU-residens, Notion kun Enterprise - mens Salesforce kan provisioneres i en EU-region fra start. Ingen webshop, ingen betalingsdata, men nøjagtig samme øvelse: gå bro for bro. Mønsteret holder uanset branche - kun navnene på connectorerne skifter.
Tre fælder, når du forbinder Claude connectors
"EU-residens betyder, at intet forlader EU." Forkert. Selv med EU-lagring forlader metadata, support, billing og login-data ofte EU. Derfor er SCC'erne i databehandleraftalen stadig nødvendige - også når data "ligger i Frankfurt".
At behandle betalingstjenester som almindelige databehandlere. Stripe, PayPal, Square, Plaid og Airwallex er selvstændige dataansvarlige for visse formål. Det er en controller-til-controller-deling, ikke en ren databehandleraftale.
At stole på certificerings-overskriften. HubSpot er ikke selv ISO 27001-certificeret - kun underleverandøren AWS er (HubSpots egen sikkerhedsside). Ahrefs har ingen offentligt bekræftede certificeringer overhovedet. Træk certifikatet fra leverandørens trust-portal, før du regner det som dokumentation.
Hvad det koster - og hvad det koster at lade være
EU-residens er sjældent gratis: hos de fleste connectors er den et Enterprise-løft, så det er en reel post på budgettet. Men hold den op mod alternativet. En GDPR-bøde kan nå op til 20 mio. EUR eller 4 % af den globale omsætning (GDPR artikel 83) - og længe inden en bøde kommer kunden, der beder om at se, hvor jeres data ligger, før de skriver under. Derfor er det her ikke en IT-opgave alene, men en ledelsesbeslutning: det afgør, hvilke værktøjer I overhovedet kan stå inde for over for jeres egne kunder.
Hovedpointe: EU-dataresidens er ikke et lovkrav - det er en risikoreducerende foranstaltning. En USA-baseret connector er fuldt lovlig med en databehandleraftale og SCC'er. Spørg derfor ikke "ligger data i EU?", men "har vi det rigtige grundlag for, hvor data ligger?"
Mini-tjekliste til næste gang du forbinder en connector
Og har I ikke forbundet en eneste connector endnu? Så er det her huskelisten, du bruger inden den første bro - ikke en oprydning bagefter.
- Er der en databehandleraftale med tjenesten? Hvis nej - stop, før du sender persondata.
- Kræver EU-residens en Enterprise-plan, og har vi brug for den? Beslut bevidst, ikke per refleks.
- Hvilke datatyper må løbe over den her bro? Hold særlige kategorier ude, hvor du ikke har dækning.
- Er tjenesten selvstændig dataansvarlig for noget? Så skal det stå i privatlivspolitikken.
- Står connectoren i vores fortegnelse med sit overførselsgrundlag? Ellers kan I ikke dokumentere den.
Færre end fire "ja + bevis"? Så er den connector ikke i compliance-zonen endnu. Det er ikke en katastrofe - det er en eftermiddags oprydning.
FAQ
Hovedpointe: En connector er en bro, ikke et datalager. Spørg, hvor broen fører hen - og styr de tre lag hver for sig. Så er det ikke længere et spørgsmål om at turde forbinde Claude til jeres systemer, men om at gøre det klogt.
Kilder og retsgrundlag
- Leverandører: hver connectors data-residens og databehandleraftale er verificeret på leverandørens egen trust-/DPA-side, juni 2026 (samlet i det vedlagte regneark).
- Anthropic: databehandleraftale (DPA) · underdatabehandlere · regional compliance
- EU-ret: GDPR artikel 28 (databehandlere) · kapitel V (overførsler til tredjelande) · SCC-afgørelse (EU) 2021/914
Dette er generel information, ikke juridisk rådgivning til en konkret implementering. Verificér aktuelle residens-politikker og certificeringer på deployment-tidspunktet, da de ændrer sig.
Ofte stillede spørgsmål
En connector er ikke i sig selv "compliant" eller ej - det er din brug af den, der er lovlig. En connector er bare en bro mellem Claude og en tredjepartstjeneste som Notion, Slack eller HubSpot. Dine data ligger hos den tjeneste, og om det er GDPR-konformt afhænger af, hvor tjenesten hoster, om der er en databehandleraftale, og om du har et lovligt behandlingsgrundlag.