Azure AI Foundry är Microsofts tyngsta satsning på företagsstyrning, men ett dåligt första köp. Det är plattformen som förenar Azure OpenAI Service, Azure AI Search och Azure Machine Learning under ett kontrollplan, en identitetsmodell och en central plats för att övervaka vad dina agenter faktiskt gör.
Se det som ett kontrolltorn. Fantastiskt när fyrtio flygplan cirkulerar. Väldigt dyrt när du bara äger ett plan. Det är därför Azure AI Foundry lönar sig först vid ditt andra eller tredje användningsområde, snarare än det första. (Microsoft döpte om det till Microsoft Foundry vid Ignite i november 2025. De flesta kontrakt och platsannonser använder fortfarande namnet Azure AI Foundry, så det är den termen vi använder här. Det är samma plattform.)
Nu till det som produktsidorna utelämnar. De flesta Azure AI Foundry-projekt misslyckas inte på grund av modellen. De faller under de två veckorna efter demon, när någon frågar vem som ansvarar för vad agenten precis gjorde, och ingen har ett svar. Plattformen var aldrig flaskhalsen. Datan fanns i tre system med tre olika behörighetsmodeller, och den verksamhetsansvarige som skulle godkänna eller förkasta resultatet hade aldrig utsetts.
Azure AI Foundry förenar de AI-tjänster du förmodligen redan betalar för: Azure OpenAI Service, Azure AI Search, Azure Machine Learning och Microsoft Fabric. Ett kontrollplan. En identitetsmodell. Ett lager för observerbarhet.
Namnbytet till Microsoft Foundry var inte bara kosmetiskt; innehållet förändrar vad det är du faktiskt köper.
Så vad får du egentligen för pengarna? Inte innovation. Du får förmågan att köra mer än en AI-arbetsbelastning utan att varje enskilt projekt kräver sin egen omfattande styrningsmodell. Det är hela poängen med en plattform jämfört med en punktlösning, och det lönar sig bara om du har för avsikt att bygga mer än en sak.
Relaterad läsning från IC: Guide för driftsättning och MLOps i Azure Machine Learning
Varje samarbete vi inleder börjar med samma fyra frågor. De är tråkiga frågor. Men de förutspår bättre än något tekniskt om ett AI-transformationsprogram når produktion.
Poängsätt varje dimension 0 till 3, där 0 betyder inte alls sant och 3 betyder helt sant idag.
Kan agenten nå den data den behöver, på ett lagligt, tekniskt och tillräckligt rent sätt för att vara användbar? Frågan är inte "har vi datan". De verkliga frågorna är om den finns i ett system med ett API, om dess behörighetsmodell fungerar när en agent läser den för en användares räkning, och om en människa skulle känna igen svaret den producerar.
Det misslyckande vi ser: kunskapsbasen finns, men den är till 40 % inaktuell och ingen äger den. Agenten upprepar då, med fullt självförtroende, en policy som togs ur bruk 2023.
Finns det en namngiven person, inte en kommitté och inte "verksamheten", som kommer att acceptera eller förkasta det agenten producerar? Någon vars jobb blir bättre om det fungerar?
Det misslyckande vi ser: AI-projektet tillhör innovationsteamet. Processen det automatiserar tillhör driftavdelningen. Driftavdelningen blev aldrig tillfrågad. Pilotprojektet fungerar utmärkt men blir aldrig implementerat.
Vet ni vad som händer när agenten har fel? Vem är ansvarig, hur ser granskningsspåret ut och var krävs en människa i loopen?
Det misslyckande vi ser: detta skjuts upp till "innan driftsättning", och blockerar sedan driftsättningen i fyra månader. Inom reglerade sektorer är detta den enskilt vanligaste anledningen till att en fungerande prototyp aldrig lanseras.
Kommer teamet som tar emot resultatet att ändra sitt arbetssätt? Har de blivit informerade? Är det någon vars mål förändras?
Det misslyckande vi ser: agenten skapar ett utkast till svar, men utkastet ignoreras eftersom ingen faktiskt har fått en minskad arbetsbörda. De granskar nu AI-genererat innehåll och utför den ursprungliga uppgiften. Mer arbete. Inte mindre.
Oftare än inte är de företag som kommer hit övertygade om att de befinner sig i Driftsättning poäng någonstans i Pilotfasen. Det är inte menat som kritik. Det är det normala tillståndet för en organisation som har kört AI-experiment i arton månader utan att ha fattat ett plattformsbeslut.
Det här är den del som de flesta leverantörer hoppar över, så låt oss vara raka med det.
Azure AI Foundry har ingen licensavgift. Microsoft tar betalt för de underliggande tjänster som plattformen orkestrerar, så din faktura kommer att visa Azure OpenAI Service, Azure AI Search, Azure Machine Learning och lagring. Det kommer inte att finnas någon rad som heter "Foundry". Detta förvirrar ekonomiavdelningar med imponerande tillförlitlighet.
Vi tar en agent för skadereglering som hanterar 20 000 ärenden i månaden. Varje ärende förbrukar ungefär 6 000 indatatokens (ärendet plus hämtad kontext) och 800 utdatatokens.
Sedan kommer den del som faktiskt avgör affärsnyttan: ingenjörsarbetet för att hämta in och underhålla dokumentmassan, samt tiden som granskare lägger på att bygga och underhålla utvärderingsunderlaget. Detta mäts i personveckor snarare än dollar per token, och under det första året kommer det vanligtvis att överskugga plattformskostnaderna fullständigt.
Modellera ditt eget scenario utifrån Azure-priskalkylatorn, och betrakta alla publicerade prisintervall, inklusive våra egna, som storleksordningar snarare än en budget. Skillnaden mellan två till synes likvärdiga implementeringar är enorm, och den drivs nästan uteslutande av dokumentvolym och frågemönster.
Använd Microsoft Copilot om du behöver AI inuti Microsoft 365, Dynamics eller GitHub, och kan acceptera hur det fungerar direkt ur lådan. Det är billigare, snabbare och kräver inget ingenjörsteam.
Använd Azure AI Foundry när minst två av följande påståenden stämmer:
Inget av detta som stämmer? Köp Copilot-licenser och sluta läsa. Vi säger hellre det nu än efter en förstudiefas.
.webp)
Styrning är anledningen till att företag väljer Azure AI Foundry framför billigare alternativ. Det är också här de flesta prototyper dör. Fyra frågor avgör om din lösning blir verklighet.
Kan agenten se något som användaren inte kan?Detta är felkällan som sätter stopp för projekt. En agent som indexerar dokument och svarar på frågor utifrån dem kan läcka innehåll som användaren inte har behörighet att se. Lösningen är att hämtningen måste respektera dina befintliga behörigheter, så att agenten ärver användarens åtkomst istället för att ha obegränsad åtkomst. Foundry stöder detta genom RBAC (rollbaserad åtkomstkontroll: behörigheter som tilldelas en roll, till exempel "skadereglerare", snarare än individer, så att åtkomsten följer arbetsuppgiften istället för personen) och identitetsmedveten hämtning. Det sker inte av en slump. Du måste bygga in det från början.
Vem bär ansvaret när det blir fel?Entra Agent ID ger agenten en identitet i katalogen, vilket gör dess handlingar spårbara och möjliga att återkalla. Utan en sådan blir "AI:n gjorde det" en revisionsanmärkning du inte kan besvara.
Var hamnar datan fysiskt och vem ser den?Valet av modell påverkar datalagringen. Foundry är värd för många modeller direkt, men tredjepartsmodeller som nås via katalogen har egna villkor. Om du verkar under EU:s krav på datalagring är detta en upphandlingsfråga snarare än en teknisk, och den bör ställas innan du väljer modell, inte efter att du har byggt på den.
Vad hindrar agenten från att göra något skadligt?Innehållsfiltrering, skyddsmekanismer och kontrollpunkter för prompter, utdata och verktygsanrop. Den kontrollpunkt som är viktigast i en företagsmiljö är verktygsanropet: ögonblicket då en agent slutar svara och börjar agera i ett system. Ett manuellt godkännandesteg där är oftast skillnaden mellan att en riskkommitté godkänner eller nekar.
Och risken som ingen tar upp i en presentation? Tyst försämring. En modellversion uppdateras, agenten blir i tysthet sämre, och ingen märker det på sex veckor eftersom det saknas en utvärderingsuppsättning. Vilket är precis anledningen till att vi bygger en sådan innan vi bygger något annat.
Två saker har förändrats så pass mycket sedan 2025 att äldre guider numera är missvisande.
Agentorkestrering. Microsoft har slagit samman sina två agentramverk, AutoGen (forskningsprojektet för multi-agenter) och Semantic Kernel (företags-SDK:n), till Microsoft Agent Framework, som utvecklas av samma team. Det stöder två orkestreringslägen, och valet mellan dem är ett affärsbeslut förklätt till ett tekniskt sådant.
Microsofts egen dokumentation innehåller en rad som är värd att läsa högt för alla team som tar sig vatten över huvudet: om du kan skriva en funktion för att hantera uppgiften, skriv funktionen istället för att använda en agent.
Multimodal förmåga. Foundry Tools täcker text, dokument, bilder, tal och video i en och samma plattform. I praktiken innebär det att en skaderegleringsagent kan läsa skadereglerarens anteckningar, försäkringsvillkoren i PDF-format och fotografiet på den krockade motorhuven i ett enda arbetsflöde, istället för att behöva hantera tre integrationer och en överlämning. För dokumenttunga branscher är det oftast här de verkliga tidsvinsterna finns. Det är också ett område som är kroniskt underutforskat, eftersom team fastnar i chatbot-tänket och slutar leta vidare.
De flesta implementeringsplaner består av samma fem faser med olika namn. Analysera, designa, testa, skala, optimera. De är inte direkt felaktiga, men de ger ingen egentlig information. Så här gör vi annorlunda.
Innan vi påbörjar någon arkitektur hämtar vi 200 verkliga ärenden från den aktuella processen och sätter oss ner med verksamhetsansvarig för att definiera vad ett korrekt svar innebär. Det är tidskrävande. Det är också den mest värdefulla veckan i hela samarbetet, eftersom den resulterar i en utvärderingsmodell: en fast uppsättning verkliga ärenden med kända korrekta svar som körs automatiskt mot agenten varje gång något ändras. På så sätt kan du bevisa att systemet har förbättrats istället för att behöva diskutera saken.
Hoppar du över detta kommer du sex månader senare att debattera om agenten har blivit sämre. Baserat på magkänsla.
Så här ser utvärderingsmodellen ut som vi lämnar efter oss. Den är medvetet inte samma exempel som finns i Microsofts dokumentation, som bara mäter en kvalitetsaspekt och ger ett värde. Tre saker skiljer sig åt, och var och en kommer från ett projekt där avsaknaden av kontroll kostade oss dyrt. Vi använder tre dimensioner för utvärdering istället för en. Vi låter inte en modell bedöma eskaleringsbeteende, eftersom frågan "borde detta ha gått till en människa?" är något du måste kunna försvara inför en tillsynsmyndighet utan att säga "en annan modell tyckte det". Dessutom avbryts bygget vid fel, istället för att bara logga en varning som ingen läser.
# eval_harness.py — IC pattern for Azure AI Foundry agents
# Runs on every model change, prompt change and index rebuild. Blocks the deploy.
import json, sys
from dataclasses import dataclass
from azure.ai.projects import AIProjectClient
from azure.identity import DefaultAzureCredential
# The golden set comes out of ground-truth week: real cases, labelled by the
# business owner who has to live with the output. Each record carries WHO
# labelled it and WHEN, because in 14 months someone will dispute a label,
# and "the business agreed" is not an answer.
GOLDEN_SET = "eval/golden_set.jsonl" # ~200 cases, versioned in git
BASELINE = "eval/baseline.json" # scores from the last shipped build
@dataclass
class Case:
id: str
payload: dict
expected_outcome: str # the label
must_escalate: bool # ground truth: does this REQUIRE a human?
visible_to: str # the requesting user's identity
@dataclass
class Result:
correct: bool
escalation_ok: bool # deterministic, not model-judged
permission_ok: bool # did it cite anything this user cannot see?
def evaluate(agent, case: Case) -> Result:
run = agent.run(case.payload, on_behalf_of=case.visible_to)
# Gate 1. Correctness. Model-judged is acceptable here, with a rubric.
correct = judge_outcome(run.outcome, case.expected_outcome)
# Gate 2. Escalation. NOT model-judged. The agent either handed off or it
# did not. Silent over-confidence on a must-escalate case is the failure
# that ends projects, and a fuzzy scorer will not catch it.
escalation_ok = (run.escalated == case.must_escalate)
# Gate 3. Permission integrity. Every citation the agent returned must be
# readable by the user who asked. This catches the leak BEFORE a user does.
permission_ok = all(
can_read(case.visible_to, source.id) for source in run.citations
)
return Result(correct, escalation_ok, permission_ok)
def main() -> int:
client = AIProjectClient(endpoint=FOUNDRY_ENDPOINT,
credential=DefaultAzureCredential())
agent = client.agents.get(AGENT_ID)
cases = [Case(**json.loads(line)) for line in open(GOLDEN_SET)]
results = [evaluate(agent, c) for c in cases]
scores = {
"accuracy": mean(r.correct for r in results),
"escalation": mean(r.escalation_ok for r in results),
"permission": mean(r.permission_ok for r in results),
}
baseline = json.load(open(BASELINE))
# Permission is absolute. One leak fails the build. There is no tolerance
# band here, and every client who argued for one later agreed.
if scores["permission"] < 1.0:
fail(f"PERMISSION LEAK on {count_failures(results)} case(s). Blocked.")
# Accuracy and escalation are graded against the LAST SHIPPED BUILD, not an
# absolute bar. Absolute bars get negotiated downward. Regressions do not.
for gate in ("accuracy", "escalation"):
drift = scores[gate] - baseline[gate]
if drift < -0.02: # 2pp regression tolerance
fail(f"{gate} regressed {drift:.1%} vs shipped build. Blocked.")
print(f"PASS {scores} (baseline {baseline})")
return 0
if __name__ == "__main__":
sys.exit(main())
Ett konceptbevis (PoC) visar att tekniken fungerar. Alla vet redan att tekniken fungerar. Istället bygger vi en smal väg hela vägen till produktion: ett arbetsflöde, en datakälla, verkliga användare, verkliga behörigheter och en fullständig granskningslogg. Medvetet begränsad i omfattning. Medvetet komplett på djupet.
Poängen är att det blottlägger integrations- och styrningsproblem redan under vecka tre, när de är billiga att åtgärda, istället för under månad fem när de inte är det.
Entra Agent ID, RBAC, innehållsfilter och eskaleringsvägar med mänsklig inblandning konfigureras under den första skivan. För reglerade kunder är detta icke förhandlingsbart. För oreglerade kunder är det vad som gör att det andra och tredje användningsområdet inte kostar lika mycket som det första.
Testmiljön från steg 1 fungerar som en grindvakt för varje release. Ingen agent utökar sitt ansvarsområde förrän den har klarat kraven för fall den aldrig tidigare stött på. Det är skillnaden mellan en strukturerad flotta och ett kaos.
Vi ser till att ert team äger både utvärderingsmiljön och instruktionsboken, inte bara koden. En partner som måste anlitas på nytt för varje modelluppdatering har inte slutfört sitt uppdrag.
För ett enskilt, väl avgränsat arbetsflöde tar det några veckor att utveckla en första fungerande produktionslösning. Men den verkliga begränsningen är nästan aldrig själva tekniken. En realistisk tidsplan ser ut så här.
Raden för säkerhetsgranskning är där två identiska projekt kan skilja sig åt med ett helt kvartal. Fråga därför alla potentiella partners vad deras tidsplan förutsätter om er organisation, och var skeptisk mot alla som svarar innan de har granskat er datamiljö.
Funktionsjämförelsen spelar betydligt mindre roll än vad leverantörerna vill göra gällande. I praktiken fattades beslutet åt dig för flera år sedan av två faktorer: var din data lagras och var din identitetsmodell körs. Låt oss ändå jämföra dem, eftersom du kommer att få frågan.
Här är den strategiska poängen snarare än den tekniska. Att välja den plattform där din data inte finns, bara för att den fick högre poäng i en funktionsmatris, är ett beslut du kommer att få betala för i form av integrationsarbete varje kvartal under de kommande fem åren. Integrationskostnader ackumuleras. Funktionsgap minskar.
Vilket leder till en något obekväm slutsats. Om ni är en Microsoft-miljö är plattformsfrågan i stort sett redan besvarad, och det verkliga arbetet ligger i beredskapsfrågan ovan. Tre månaders utvärdering av leverantörer är ofta tre månader av att undvika det svårare samtalet.
Microsofts enhetliga plattform för att bygga, distribuera och styra AI-applikationer och agenter. Den ligger ovanpå Azure OpenAI Service, Azure AI Search och Azure Machine Learning, och ger dem ett gemensamt kontrollplan, en enhetlig identitetsmodell och en central plats för att övervaka vad dina agenter gör.
Själva plattformen har ingen licensavgift, och du kan skapa ett projekt och utforska den utan kostnad. Du betalar för de underliggande tjänsterna: modellinferens (tokens), Azure AI Search, lagring, beräkningskraft och övervakning. Det är alltså gratis att börja, men inte gratis att köra. Kostnaderna hamnar på din Azure-faktura under respektive tjänstenamn snarare än under "Foundry".
Azure OpenAI Service är en komponent. Azure AI Foundry är plattformen runt omkring. OpenAI Service ger dig modellslutpunkter; Foundry lägger till modellkatalogen (inklusive modeller som inte kommer från OpenAI, såsom Anthropics Claude), verktyg för agenter, hämtning, utvärdering, observerbarhet och styrning. Om allt du behöver är en modellslutpunkt behöver du inte Foundry. Om du behöver köra agenter i produktion och kunna bevisa vad de har gjort, då behöver du det.
Välj Copilot om du vill ha AI i Microsoft 365, Dynamics eller GitHub och kan acceptera hur det fungerar direkt ur lådan, eftersom Copilot är en färdig produkt. Välj Azure AI Foundry om du behöver bygga något som är specifikt för din verksamhet, komma åt din egen data under dina egna behörigheter eller uppfylla regulatoriska krav. Foundry är en plattform för att bygga produkter, och du bör inte köpa en plattform för att lösa ett problem som en produkt redan löser.
Ja. Microsoft bytte namn på det under Ignite i november 2025, och produktvillkoren från januari 2026 formaliserade ändringen. Dina avtal och interna dokument kan referera till båda namnen.
Modellslutpunkter är REST-API:er, så de kan anropas från vilket språk som helst. För utveckling av agenter fokuserar Microsoft Agent Framework för närvarande på Python och C#/.NET, och Microsoft har lovat att uppnå paritet mellan de två vid allmän tillgänglighet. Om ert utvecklingsteam främst använder Java, Go eller TypeScript är verktygen för agenter mer begränsade, vilket ni bör kontrollera innan ni fattar ett beslut. Det är en verklig begränsning som inte framgår tydligt i marknadsföringen.
Era befintliga inferensarbetsflöden fortsätter att köras, så namnbytet innebär inte att ni behöver migrera. Tidsfristerna är dock verkliga. Supporten för Azure ML SDK v1 upphör den 30 juni 2026, och supporten för CLI v1 upphörde redan i september 2025, enligt Microsofts egen migreringsvägledning. Allt som är byggt på azureml-sdk kräver en plan nu. Assistants API håller också på att fasas ut, så kontrollera det aktuella datumet i Microsoft Learn innan ni planerar utifrån det.
Fyra stycken, i den ordning de brukar bli problematiska. Behörighetsläckage, där en agent exponerar innehåll som användaren inte borde ha tillgång till. Tyst försämring, där agenten gradvis blir sämre efter en modelluppdatering utan att det upptäcks av utvärderingsverktyg. Plattformsförändringar, eftersom två varumärkesbyten på tolv månader och faktiska avvecklingsdatum gör att dokumentation och utbildningsmaterial snabbt blir inaktuella. Och kostnadsdrivning, eftersom tokenförbrukningen skalar med användningen, och utan modellstyrning ökar den snabbare än värdet. Alla fyra är hanterbara. Ingen av dem hanteras som standard.
En produktionsklar delmängd, det vill säga ett arbetsflöde med riktiga användare och korrekt styrning, tar några veckors utveckling. Den totala tiden är oftast längre, och den avgörande faktorn är intern: säkerhetsgranskning och godkännande av datatillgång tar rutinmässigt två till sex veckor och är den enskilt största tidstjuven. Var vaksam på tidsplaner som ges innan någon har granskat er datamiljö.
En plattformstekniker som ansvarar för Azure-prenumerationen och dess identitetsmodell, en utsedd affärsansvarig för varje användningsområde, samt att efterlevnadsteamet involveras före utvecklingen snarare än vid godkännandet. Om ni inte kan namnge personen som ska acceptera eller förkasta agentens resultat är ni inte redo. Det är dock ett problem som går att lösa på fyra veckor, inte fyra månader.
Det fungerar. Men ekonomin gynnar organisationer som kör mer än en AI-arbetsbelastning, eftersom plattformens värde ligger i att styra många agenter samtidigt istället för en i taget. Med ett enskilt användningsområde finns den fördelen ännu inte.
Fördelen med Azure AI Foundry ligger i styrningen snarare än i själva kapaciteten, eftersom alla större plattformar kan anropa en bra modell. Det Foundry ger dig är en flotta av agenter som körs under en och samma uppsättning regler. Det är därför det blir kostnadseffektivt först vid ditt andra eller tredje användningsområde, inte det första.
Fakturan är inte licensen, för det finns ingen licens. Det handlar om tokens, hämtning, datainläsning och personal, och datainläsning är den post som ingen budgeterar för. Allt annat avgörs innan en enda rad kod har skrivits, utifrån fyra oglamorösa förutsättningar: tillgänglig data, en utsedd beslutsfattare, en plan för styrning och ett team som är villigt att förändra sitt arbetssätt.
Är plattformen den svåra biten? Nej, naturligtvis inte. Det är du som är den svåra biten.
Utvärdera dig själv utifrån Foundry Readiness Model. Om du hamnar i Utforskar, är det mest värdefulla vi kan göra för dig att säga det rakt ut. Och om du vill ha en second opinion om var ni faktiskt befinner er, eller om du har en prototyp som inte tar steget till produktion och du inte kan förstå varför, prata med oss.
Alexandra Mendes är Senior Growth Specialist på Imaginary Cloud med 3+ års erfarenhet av att skriva om mjukvaruutveckling, AI och digital transformation. Efter att ha avslutat en frontend-utvecklingskurs tog Alexandra upp några praktiska kodningskunskaper och arbetar nu nära med tekniska team. Alexandra brinner för hur ny teknik formar affärer och samhälle och tycker om att förvandla komplexa ämnen till tydligt och användbart innehåll för beslutsfattare.
Inês Silva är projektledare med över fyra års erfarenhet av att skriva om mjukvaruleverans, agila metoder och tekniskt ledarskap. Eftersom hon började sin karriär som utvecklare, bidrar Inês med en verklig, djupt teknisk förståelse till ledningssidan. Hon älskar att överbrygga klyftan mellan övergripande affärsstrategi och det dagliga ingenjörsarbetet, och hon brinner för att dela med sig av praktiska tips som hjälper team att samarbeta bättre och leverera fantastiska produkter.
People who read this post, also found these interesting:
-%2520Survey%2520Insights.webp)
