Azure AI Foundry i EU: konfigurationen der afgør det
Kun med deployment-typerne DataZone eller Standard holder Azure AI Foundry data i EU. Global er default og forlader EU, også fra ressourcer i EU. Konfigureret rigtigt giver Azure mest styring blandt de store alternativer: EU Data Boundary, RBAC via Entra ID, kundeadministrerede nøgler, Customer Lockbox og Defender for AI.
Af de store veje til generativ AI er Azure AI Foundry den der giver mest styring: Identitet, nøgler, adgang og revision hænger sammen med resten af Microsoft-miljøet. Men styringen gælder kun hvis konfigurationen er rigtig, og defaulten peger i den forkerte retning.
Tre deployment-typer, kun to holder data i EU
Når en model sættes i drift i Foundry, vælger man en deployment-type, og det valg afgør hvor kaldene bliver behandlet:
| Deployment-type | Bliver data i EU? | Kommentar |
|---|---|---|
| Global | Nej | Default. Kald kan behandles hvor som helst, også fra ressourcer i EU |
| DataZone | Ja, inden for EU-datazonen | Behandling i datazonens datacentre i EU |
| Standard | Ja, i ressourcens region | Behandling i den valgte region |
To ting gør Global til en faldgrube. Den er default, så residensen forsvinder hvis ingen aktivt fravælger den. Og nye modeller bliver ofte lanceret først som Global. Presset for “lige at teste den nye model” bliver dermed et pres for at forlade EU uden at nogen har truffet en bevidst beslutning om det. Opsæt en policy i Azure der blokerer Global-deployment i miljøer hvor der kræves residens. Gør også deployment-typen til en obligatorisk kolonne i jeres interne servicekatalog: Den der bestiller en model, angiver type, region og begrundelse så beslutningen om residens bliver truffet ved bestillingen i stedet for at blive opdaget bagefter.
Styrkerne: mest styring blandt de store alternativer
Konfigureret rigtigt er Foundry-vejen svær at slå på kontrolsiden:
- EU Data Boundary på den rigtige SKU: Microsofts ramme for at holde datastrømme inden for EU/EFTA.
- RBAC via Entra ID: rettigheder i samme model som resten af jeres Azure-miljø.
- Kundeadministrerede nøgler (CMK) i Key Vault til data i hvile.
- Customer Lockbox: godkendelsesflow når Microsofts support har brug for adgang.
- Defender for AI: trusselsdetektion for AI-workloads.
For organisationer der allerede lever i Azure, er det her hjemmebane: samme identiteter, samme logning, samme revisionsværktøjer. Styrken er ikke funktionerne hver for sig, men at de hænger sammen. Compliancearbejdet bliver en forlængelse af det I allerede gør, i stedet for et parallelt spor.
Nuancerne en revision finder
To punkter fortjener særlig opmærksomhed. CMK beskytter data i hvile, men ikke nødvendigvis klarteksten under selve inferensen: Når modellen behandler et kald, ligger indholdet ukrypteret i beregningsmiljøet. Skriv det ind som en restrisiko i stedet for at lade “kundenøgler” lyde som en total beskyttelse.
Og en klassisk fejl: Autentificering med API-nøgle går uden om RBAC-modellen. Så længe key-auth er slået til, kan den der har nøglen, kalde ressourcen uanset rollestyringen. Slå autentificering med nøgle fra, og brug Entra-identiteter. Ellers er rettighedsmodellen en papirtiger. Gennemgå i samme ombæring diagnostikindstillingerne: hvilke logs der sendes hvorhen, og om indholdsdata kan havne i strømme der forlader regionen.
Regionernes virkelighed: Sweden Central først
For avancerede modeller er Sweden Central den bredeste EU-region, med France Central som nummer to. Men udvalg og kapacitet svinger, og det er dér den næste faldgrube ligger.
Et scenarie: Et team kører Standard-deployment i en EU-region. En kapacitetsspids gør at kvoten ikke slår til, deadline nærmer sig, og nogen skifter “midlertidigt” til Global for at komme videre. Residensen forsvinder i stilhed, og ingen dokumenterer afvigelsen. Modtrækket er at bygge failover til en anden EU-region fra starten. Så findes der en godkendt reservevej når kapaciteten slipper op, i stedet for en genvej der strider mod jeres DPIA. Reservevejen skal desuden øves og ikke kun findes i et dokument. En failover der aldrig er blevet testet, er i praksis ingen failover.
Verificér regionsmatricen før hver beslutning
Adgangen til modeller pr. region og deployment-type ændrer sig ofte. Gør dokumentationen for region availability til et obligatorisk kontrolpunkt før hver idriftsættelse og hver opgradering af model, og gem en dateret kopi i beslutningsgrundlaget. Det der gjaldt ved sidste lancering, gælder ikke nødvendigvis ved den næste. Den samme disciplin gælder kvoter: Bestil kapacitet i god tid i den region I har valgt så mangel på kapacitet aldrig bliver det argument der vælter residensen.
Bygger I AI-funktioner på Azure og vil have hjælp til at få styringen og arkitekturen rigtig fra start? Hos Weapp arbejder vi med AI-løsninger og cloudarkitektur i netop den slags miljøer. Kontakt os for en snak om jeres opsætning.
Ofte stillede spørgsmål
Hvorfor er Global-deployment default hvis den forlader EU?
Global giver Microsoft størst frihed til at fordele kapacitet og er derfor både billigst og først med nye modeller. Det er godt for tilgængeligheden, men forkert for residensen: Kald kan blive behandlet hvor som helst, også når ressourcen ligger i en EU-region. Residens kræver et aktivt valg af DataZone eller Standard.
Er EU Data Boundary nok som dokumentation over for GDPR?
Nej. EU Data Boundary er Microsofts ramme for at holde visse datastrømme inden for EU/EFTA, men den gælder kun på den rigtige SKU og fjerner ikke amerikansk jurisdiktion via CLOUD Act. Brug den som en byggesten i jeres dokumentation, ikke som hele svaret.
Beskytter kundeadministrerede nøgler alle vores data?
De beskytter data i hvile, altså lagrede data som leverandøren ikke kan læse uden jeres nøgle. Under selve inferensen behandles data i klartekst i beregningsmiljøet, så nøglerne fjerner ikke hele eksponeringen. Dokumentér det som en restrisiko i jeres DPIA.
Hvilken EU-region bør vi vælge til Azure AI Foundry?
Sweden Central har det bredeste udvalg af avancerede modeller blandt EU-regionerne, med France Central som nummer to. Vælg efter behovet for modeller og latens, men byg failover til en anden EU-region fra starten fordi kapacitet og udvalg svinger.
Hvad er Customer Lockbox?
Et godkendelsesflow der giver jer det sidste ord når Microsofts support har brug for adgang til jeres miljø ved fejlsøgning. Hver anmodning om adgang skal godkendes eksplicit af jer, bliver logget og kan afvises. Det er en brik i puslespillet for styring og sporbarhed i regulerede miljøer.