Claude på Azure Foundry: hvad EU-kunder skal vide

At finde Claude i Azure AI Foundrys modelkatalog fører let til en forhastet konklusion: at modellen dermed er Azure-hostet og omfattet af Microsofts forpligtelser om data residency i EU. Det passer ikke, og misforståelsen kan blive dyr for den der har strenge krav til hvor data behandles. Her er hvad EU-kunder faktisk har brug for at vide.

Kernen: Anthropic er databehandler, ikke Microsoft

Det afgørende er at forstå rollefordelingen. Selv om Claude tilbydes via Foundry-kataloget, er det Anthropic, ikke Microsoft, der er databehandler for dine prompts og modellens output. Data kan desuden behandles uden for din region af hensyn til drift og kapacitet.

Med andre ord: Claude på Foundry skal behandles som hostet hos en partner, ikke som en Azure-intern tjeneste. Kataloget giver dig adgang til modellen, men det flytter ikke databehandlingen ind under Microsofts forpligtelser om data residency. Partnermodeller er underlagt deres egen leverandørs vilkår.

Hvorfor misforståelsen opstår

Forvekslingen er forståelig. Foundry-kataloget samler modeller fra flere leverandører ét sted, i samme brugerflade, bag samme login og på samme faktura som resten af Azure. Alt signalerer at du befinder dig inde i Microsofts miljø, og Azure forbindes på sin side med EU-regioner og EU Data Boundary. Skridtet til at antage at også Claude er omfattet af disse forpligtelser, er kort.

Men kataloget er en distributionsflade, ikke en hostingaftale. At en model kan bestilles via Azure, siger intet om hvem der behandler data bag kulisserne. For Azures egne tjenester er det Microsoft; for en partnermodel som Claude er det partneren. Netop fordi brugerfladen skjuler den forskel, skal den fremhæves eksplicit i en gennemgang. Ellers arver dokumentationen det forkerte billede.

Konsekvensen for EU Data Boundary

For en organisation med strenge krav til EU Data Boundary gør det Claude på Foundry til et risikopunkt, ikke en løsning. Da data kan behandles uden for jeres region, kan man ikke læne sig op ad Foundry-kataloget som om det garanterede data residency i EU.

Den praktiske anbefaling er klar: Send ikke følsomme dataflows gennem Claude på Foundry hvis I har strenge krav til data residency. Har I brug for Claude med data residency i EU, findes der mere egnede veje: Bedrock eller Vertex i en EU-region, hvor databehandlingen kan holdes inden for EU på en anden måde. Foundry-vejen er bekvem, men det forkerte værktøj til streng data residency.

Det betyder ikke at Claude er uegnet til europæiske organisationer, kun at vejen ind er afgørende. Samme model kan køres med stærkere garantier for data residency når den tilgås via en cloudplatform hvor I selv styrer region og nøglehåndtering, i stedet for via et katalog hvor behandlingen kan flyttes af hensyn til drift og kapacitet. Forskellen ligger altså ikke i modellen, men i opsætningen omkring den. En rimelig holdning er at skelne mellem anvendelsesområder: Til åbent, ikke-følsomt materiale kan Foundry-vejen være helt tilstrækkelig og smidig mens følsomme dataflows med personoplysninger styres til en vej hvor I kan vise hvor data behandles. At lave den opdeling bevidst er bedre end at lade bekvemmeligheden afgøre det hele.

Fakturering ændrer ikke databehandlingen

En almindelig fejlkilde er at blande betalingsvej og databehandlingsvej sammen. At Claude på Foundry faktureres gennem Azure, siger intet om hvor eller af hvem data behandles.

Anthropic er databehandler uanset hvordan betalingen foregår, og det betyder at jeres oversigt over underdatabehandlere eksplicit skal vise Anthropic-leddet. Et konkret scenarie: En virksomhed ser Azure på fakturaen og angiver Microsoft som databehandler for Claude i den tro at alt er Azure-internt. Ved gennemgangen bliver det påpeget at Anthropic er den faktiske databehandler og at oversigten dermed er forkert. Fakturavejen førte dokumentationen på afveje.

Sådan håndterer I det rigtigt

Opsummeret er der tre ting at tage med sig om Claude på Azure Foundry:

1. Behandl det som hostet hos en partner. Anthropic er databehandler, og data kan forlade jeres region af hensyn til drift og kapacitet.
2. Undgå det ved strenge EU-krav. Brug Bedrock eller Vertex i en EU-region når der kræves Claude med data residency.
3. Lad oversigten over underdatabehandlere vise Anthropic-leddet, uanset at faktureringen går via Azure.

Og da partnermodellernes vilkår og understøttede regioner udvikler sig over tid: Verificér den aktuelle dokumentation før I træffer beslutninger. Det der gælder i dag, kan ændre sig, og spørgsmålet om data residency er for vigtigt til at bygge på en antagelse.

Vil du se hvordan Claude på Foundry forholder sig til EU Data Boundary, data residency og myndigheders adgang til data i et helt AI-projekt, er der mere på vores AI-side. Har I brug for hjælp til at vælge den rigtige vej til Claude med data residency i EU? Kontakt os, så gennemgår vi jeres dataflows.