Azure AI Foundry i EU – konfigurationen som avgör

Av de stora vägarna till generativ AI är Azure AI Foundry den som ger mest styrning: identitet, nycklar, åtkomst och granskning hänger ihop med resten av Microsoft-miljön. Men styrningen gäller bara om konfigurationen är rätt – och defaulten pekar åt fel håll.

Tre deployment-typer – bara två håller data i EU

När en modell driftsätts i Foundry väljs en deployment-typ, och det valet avgör var anropen behandlas:

Två saker gör Global till en fälla. Den är default, så residensen försvinner om ingen aktivt väljer bort den. Och nya modeller släpps ofta först som Global – trycket att ”bara testa nya modellen” blir därmed ett tryck att lämna EU, utan att någon fattat ett medvetet beslut om det. Sätt policy i Azure som blockerar Global-deployment i miljöer där residens krävs. Gör också deployment-typen till en obligatorisk kolumn i er interna tjänstekatalog: den som beställer en modell anger typ, region och motivering, så att residensbeslutet fattas vid beställningen i stället för att upptäckas i efterhand.

Styrkorna: mest styrning av de stora alternativen

Rätt konfigurerad är Foundry-vägen svårslagen på kontrollsidan:

• EU Data Boundary på rätt SKU – Microsofts ramverk för att hålla dataflöden inom EU/EFTA.
• RBAC via Entra ID – behörigheter i samma modell som er övriga Azure-miljö.
• Kundhanterade nycklar (CMK) i Key Vault för data i vila.
• Customer Lockbox – godkännandeflöde när Microsoft-support behöver åtkomst.
• Defender for AI – hotdetektering för AI-arbetslasterna.

För organisationer som redan lever i Azure är detta hemmaplan: samma identiteter, samma loggning, samma granskningsverktyg. Styrkan är inte funktionerna var för sig utan att de hänger ihop – compliance-arbetet blir en förlängning av det ni redan gör i stället för ett parallellt spår.

Nyanserna en granskning hittar

Två punkter förtjänar särskild uppmärksamhet. CMK skyddar data i vila, men inte nödvändigtvis klartexten under själva inferensen – när modellen bearbetar ett anrop finns innehållet okrypterat i beräkningsmiljön. Skriv in det som kvarvarande risk i stället för att låta ”kundnycklar” låta som ett totalskydd.

Och en klassisk miss: API-nyckelautentisering går förbi RBAC-modellen. Så länge key-auth är på kan den som har nyckeln anropa resursen oavsett rollstyrning. Stäng av nyckelautentisering och kör Entra-identiteter – annars är behörighetsmodellen en pappersprodukt. Gå i samma veva igenom diagnostikinställningarna: vilka loggar som skickas vart, och om innehållsdata kan hamna i flöden som lämnar regionen.

Regionverkligheten: Sweden Central först

För avancerade modeller är Sweden Central den bredaste EU-regionen, med France Central som tvåa. Men utbud och kapacitet svänger, och det är där nästa fälla ligger.

Ett scenario: ett team kör Standard-deployment i en EU-region. En kapacitetstopp gör att kvoten inte räcker, deadline närmar sig, och någon växlar ”tillfälligt” till Global för att komma vidare. Residensen ryker i tysthet, och ingen dokumenterar avsteget. Motmedlet är att bygga failover till en andra EU-region från början – då finns en godkänd reservväg när kapaciteten tryter, i stället för en genväg som bryter mot DPIA:n. Reservvägen ska dessutom övas, inte bara finnas i ett dokument – en failover som aldrig testats är i praktiken ingen failover.

Verifiera regionmatrisen före varje beslut

Modelltillgången per region och deployment-typ ändras ofta. Gör region availability-dokumentationen till en obligatorisk kontrollpunkt före varje driftsättning och varje modelluppgradering, och spara en daterad kopia i beslutsunderlaget. Det som gällde vid förra släppet gäller inte säkert vid nästa. Samma disciplin gäller kvoter: begär kapacitet i god tid i den region ni valt, så att kapacitetsbrist aldrig blir argumentet som fäller residensen.

Bygger ni AI-funktioner på Azure och vill ha hjälp att få styrningen och arkitekturen rätt från start? Vi på Weapp arbetar med AI-lösningar och cloud-arkitektur i just sådana miljöer – hör av dig för ett samtal om er uppsättning.