Claude på Azure Foundry: Dette må kunder i EU/EØS vite

Å finne Claude i modellkatalogen i Azure AI Foundry fører lett til en forhastet konklusjon: at modellen dermed er hostet i Azure og omfattes av EU-residensen til Microsoft. Det stemmer ikke, og misforståelsen kan bli dyr for den som har strenge krav til hvor data behandles. Her er det kunder i EU/EØS faktisk trenger å vite.

Kjernen: Anthropic er databehandler, ikke Microsoft

Det avgjørende å forstå er rollefordelingen. Selv om Claude tilbys via Foundry-katalogen, er det Anthropic, ikke Microsoft, som er databehandler for promptene dine og modellens output. Data kan dessuten behandles utenfor regionen din av hensyn til drift og kapasitet.

Med andre ord: Claude på Foundry skal behandles som partnerhostet, ikke som en intern Azure-tjeneste. Katalogen gir deg tilgang til modellen, men den flytter ikke databehandlingen inn under Microsofts forpliktelser om dataresidens. Partnermodeller er underlagt vilkårene til sin egen leverandør.

Hvorfor misforståelsen oppstår

Forvekslingen er forståelig. Foundry-katalogen samler modeller fra flere leverandører på ett sted, i samme grensesnitt, med samme innlogging og på samme faktura som resten av Azure. Alt signaliserer at du befinner deg inne i Microsofts miljø, og Azure forbindes i sin tur med EU-regioner og EU Data Boundary. Derfra er det kort vei til å anta at også Claude omfattes av de forpliktelsene.

Men katalogen er en distribusjonskanal, ikke en hostingavtale. At en modell kan bestilles via Azure, sier ingenting om hvem som behandler dataene bak kulissene. For Azures egne tjenester er det Microsoft; for en partnermodell som Claude er det partneren. Nettopp fordi grensesnittet skjuler den forskjellen, må den løftes frem uttrykkelig i en gjennomgang, ellers arver dokumentasjonen det feilaktige bildet.

Konsekvensen for EU Data Boundary

For en virksomhet med strenge krav til EU Data Boundary gjør dette Claude på Foundry til et risikopunkt, ikke en løsning. Siden data kan behandles utenfor regionen deres, kan dere ikke lene dere på Foundry-katalogen som om den garanterte EU-residens.

Den praktiske anbefalingen er tydelig: Unngå å rute sensitive dataflyter gjennom Claude på Foundry hvis dere har strenge krav til dataresidens. Trenger dere Claude med EU-residens, finnes det bedre egnede veier, Bedrock eller Vertex i EU-region, der databehandlingen kan holdes innenfor EU på en annen måte. Foundry-veien er praktisk, men feil verktøy når kravene er strenge.

Det betyr ikke at Claude er uegnet for europeiske virksomheter, bare at veien inn avgjør. Den samme modellen kan kjøres med sterkere garantier for dataresidens når den nås via en skyplattform der dere selv styrer region og nøkkelhåndtering, i stedet for via en katalog der behandlingen kan flyttes av hensyn til drift og kapasitet. Forskjellen ligger altså ikke i modellen, men i oppsettet rundt den. En fornuftig holdning er å skille mellom bruksområder: For åpent materiale som ikke er sensitivt, kan Foundry-veien være helt tilstrekkelig og smidig, mens sensitive dataflyter med personopplysninger styres til en vei der dere kan vise hvor dataene behandles. Å gjøre den inndelingen bevisst er bedre enn å la bekvemmeligheten avgjøre alt.

Fakturering endrer ikke databehandlingen

En vanlig feilkilde er å blande sammen betalingsvei og databehandlingsvei. At Claude på Foundry faktureres gjennom Azure, sier ingenting om hvor eller av hvem dataene behandles.

Anthropic er databehandler uansett hvordan betalingen går, og det betyr at kartet deres over underleverandører må vise Anthropic-leddet uttrykkelig. Et konkret scenario: Et selskap ser Azure på fakturaen og fører opp Microsoft som databehandler for Claude, i den tro at alt er internt i Azure. Ved gjennomgangen blir det påpekt at Anthropic er den faktiske databehandleren, og at kartet dermed er feil. Faktureringsveien forledet dokumentasjonen.

Slik håndterer dere det riktig

Oppsummert er det tre ting å ta med seg for Claude på Azure Foundry:

1. Behandle det som partnerhostet. Anthropic er databehandler, og data kan forlate regionen deres av hensyn til drift og kapasitet.
2. Unngå det ved strenge EU-krav. Bruk Bedrock eller Vertex i EU-region når EU-residens for Claude er et krav.
3. La kartet over underleverandører vise Anthropic-leddet, selv om faktureringen går via Azure.

Og fordi vilkårene og regionstøtten for partnermodellene utvikler seg over tid: Verifiser gjeldende dokumentasjon før dere tar beslutninger. Det som gjelder i dag, kan endre seg, og spørsmålet om dataresidens er for viktig til å bygge på en antakelse.

Vil du se hvordan Claude på Foundry forholder seg til EU Data Boundary, dataresidens og myndighetstilgang i et helt AI-prosjekt, finner du mer på AI-siden vår. Trenger dere hjelp til å velge riktig vei for Claude med EU-residens? Ta kontakt, så går vi gjennom dataflytene deres.