Azure AI Foundry vs. Microsoft Foundry: der Unterschied

Wenn Sie gerade im Azure-Portal nach „Azure AI Foundry” gesucht haben und stattdessen nur noch Microsoft Foundry finden, sind Sie nicht allein. In den letzten Monaten häufen sich in IT-Teams dieselben Fragen: Ist das ein neues Produkt? Muss ich meine Azure-OpenAI-Ressourcen jetzt migrieren? Und was ist eigentlich dieses „Foundry (classic)”, das in manchen Tutorials noch auftaucht, im aktuellen Portal aber fehlt?

Die kurze Antwort: Microsoft Foundry ist keine neue Plattform, sondern der dritte Name für dieselbe Plattform innerhalb weniger Jahre. Das erklärt die Verwirrung - löst sie aber noch nicht auf. Dieser Artikel ordnet die Namenskette ein, zeigt, was sich technisch wirklich geändert hat, und benennt die Fallstricke, die beim optionalen Upgrade von Azure OpenAI auf Foundry lauern.

Die Namenskette: Von Azure AI Studio zu Microsoft Foundry

Microsoft dokumentiert die Entwicklung selbst so: „Microsoft’s AI Platform has evolved from Azure AI Studio → Azure AI Foundry → to Microsoft Foundry (current).” Drei Namen, eine Plattform. Die Umbenennung zu Microsoft Foundry fiel auf der Ignite 2025 (November 2025). Ein förmliches Ankündigungsdatum nennt Microsofts eigene Dokumentation nicht - belegbar ist aber, dass Microsofts eigener Ignite-Rückblick im Azure-Blog vom 18.11.2025 die Plattform bereits durchgängig „Microsoft Foundry” nennt.

Parallel zur Plattform wurde auch das Services-Portfolio umbenannt: Aus Azure Cognitive Services wurde Azure AI Services, und daraus wurde „Foundry Tools” - die Sammelbezeichnung für Speech, Vision, Language, Content Safety und Content Understanding.

Für die Suche im Alltag heißt das: „Azure AI Foundry” ist kein falscher, sondern ein veralteter Begriff. Wer heute danach googelt, landet inzwischen meist ohnehin bei Microsoft-Foundry-Dokumentation - nur die Navigation im Portal und in älteren internen Runbooks hinkt oft noch hinterher.

Was „Foundry (classic)” ist - und warum Sie den Begriff noch sehen

Wer schon vor der Umbenennung mit Azure AI Studio oder frühen Azure-AI-Foundry-Versionen gearbeitet hat, kennt Hub-basierte Projekte, das „Management Center” und die Assistants API. Diese Architektur existiert weiter - als eigener, parallel gepflegter Dokumentationsbereich unter der Bezeichnung „Foundry (classic)”. Im Portal schaltet ein Toggle („New Foundry” an/aus) zwischen beiden Erlebniswelten um. Microsoft ist dabei eindeutig: „Hub-based projects are accessible in the Foundry (classic) portal. New investments are focused on Foundry projects in the new portal.” Neue Funktionen landen also im aktuellen Portal. Überflüssig ist classic damit trotzdem nicht: Microsoft verweist ausdrücklich auf das classic-Portal, wenn Sie Funktionen brauchen, die im aktuellen Portal noch fehlen - genannt werden Prompt Flow und Modell-Deployments auf Managed Compute - oder wenn Sie mit Hub-basierten Projekten und reinen Azure-OpenAI-Ressourcen arbeiten. Ein dauerhaft sicherer Hafen ist classic aber ebenso wenig: Einzelne classic-Bausteine haben harte Enddaten, dazu weiter unten.

Die wichtigsten Begriffe im Vergleich, damit Sie alte Screenshots und aktuelle Doku richtig zuordnen können:

Konzept	Foundry (classic)	Microsoft Foundry (aktuell)
Portal	Foundry (classic) portal	Foundry portal
Portal-Einstellungen	Management Center	Operate section
Ressourcentyp	Azure OpenAI + Hub	Foundry Resource (`AIServices`-Kind mit Child-Projects)
AI-Services	Azure AI Services	Foundry Tools
Modell-Billing	Model-as-a-Service (MaaS)	Foundry Direct Models
RBAC-Rollen	Cognitive Services OpenAI User	Foundry User / Foundry Project Manager / Foundry Owner
API-Wire-Protocol	Assistants API	Responses API
API-Versionierung	monatliche `api-version`-Parameter	v1 stable routes (kein Version-Parameter)
Conversation State	Threads	Conversations
Ausführung	Runs (async, gepollt)	Responses (standardmäßig synchron)

Was bleibt gleich: Ressourcentyp, RBAC-Rollen, Endpunkte

Für IT-Entscheider ist eine Zeile in der Microsoft-Doku wichtiger als der ganze Namensstreit: „Despite the platform evolution, the Azure resource type remains Microsoft.CognitiveServices/accounts.” Der Azure-Ressourcentyp hat sich also nicht geändert. Wer Policies, RBAC-Assignments oder Bicep-/Terraform-Module gegen diesen Ressourcentyp betreibt, muss deswegen nichts anpassen - sie funktionieren nach der Umbenennung genauso wie vorher.

Auch bei den RBAC-Rollen gibt es zwar neue Namen, aber keinen Bruch: Foundry User, Foundry Owner, Foundry Account Owner und Foundry Project Manager hießen früher Azure AI User, Azure AI Owner, Azure AI Account Owner und Azure AI Project Manager. Microsoft stellt klar: „The role IDs and core permissions are unchanged by the rename.” Bestehende Terraform-Referenzen auf role_definition_id brechen also nicht - nur die Anzeigenamen im Portal ändern sich.

Auch der Begriff „Azure OpenAI Service” ist nicht verschwunden. Er lebt weiter - allerdings jetzt als Modell-Kategorie innerhalb von Foundry, geführt unter „Azure OpenAI in Microsoft Foundry models”. Die Azure-OpenAI-API mit Batch, Stored Completions, Fine-Tuning und Evaluation bleibt erhalten, und der gewohnte Endpunkt {custom-domain}.openai.azure.com funktioniert nach einem Upgrade unverändert weiter.

Muss ich von Azure OpenAI auf Foundry migrieren?

Die für viele Admins wichtigste Aussage aus der Microsoft-Doku lautet: „Upgrading your Azure OpenAI resource is an opt-in capability. If needed, you can roll back to your previous setup.” Und weiter: „Both services are generally available and supported before and after the upgrade.” Es gibt also keinen Stichtag, an dem bestehende Azure-OpenAI-Ressourcen zwangsweise auf Foundry umgestellt würden (Stand: August 2026).

Technisch ist das Upgrade ein Wechsel des kind-Attributs der Ressource: von OpenAI auf AIServices, kombiniert mit allowProjectManagement = true und einer konfigurierten Managed Identity. Ein Rollback funktioniert in die Gegenrichtung - zurück auf kind: 'OpenAI' - , setzt aber voraus, dass Projekte, Connections und Nicht-OpenAI-Deployments vorher gelöscht werden. Wer das per Infrastructure-as-Code steuert: Für ein nicht destruktives Update über den AzureRM-Provider ist eine Terraform-CLI-Version größer als 4.57.0 nötig - mit älteren Versionen droht der ungewollte Neuaufbau der Ressource.

Beim Upgrade selbst bleiben zentrale Eckdaten erhalten: Ressourcenname, Tags, Netzwerk-Konfiguration, Access/Identity-Einstellungen, API-Endpunkt und API-Key, Custom Domain Name sowie bestehender Zustand wie laufende Fine-Tuning-Jobs, Batch-Jobs und Stored Completions. Ein Upgrade ist also kein Ressourcen-Neubau, sondern eine Konfigurationsänderung an einer bestehenden Ressource.

Fallstricke beim Upgrade von Azure OpenAI auf Foundry

So unkompliziert der Schalter klingt: In der Praxis gibt es mehrere Stellen, an denen ein Upgrade nicht „einfach durchklicken” ist.

Customer-Managed Keys (CMK): Ressourcen mit CMK lassen sich nicht direkt upgraden - Microsoft verlangt dafür ein separates Antragsformular. Wer CMK für Compliance-Anforderungen einsetzt, sollte das vor jedem geplanten Upgrade-Termin einplanen.
Bestehende Private Endpoints: Ressourcen mit vorhandenen Private Endpoints lassen sich weder über das Foundry-Portal noch über das Azure-Portal upgraden. Die Endpoints müssen vorher gelöscht und nach dem Upgrade neu angelegt werden - alternativ steuern Sie das Upgrade über Bicep oder Terraform. Den Private-Link-Endpoint müssen Sie laut Microsoft aber in jedem Fall neu erstellen, damit die IP-Konfigurationen für services.ai.azure.com und {custom-domain}.cognitiveservices.azure.com überhaupt entstehen.
Drei FQDNs statt einem: Nach dem Upgrade exponiert die Ressource drei Domainmuster (*.openai.azure.com, *.services.ai.azure.com, *.cognitiveservices.azure.com). Wer privates DNS betreibt, muss für alle drei Zonen bzw. Forwarder-Einträge anlegen - sonst brechen Teile der Konnektivität nach dem Upgrade, ohne dass das sofort auffällt.

Die RBAC-Falle: Cognitive Services User nach dem Upgrade

Das ist der Fallstrick mit dem größten Blast Radius. Die Rolle Cognitive Services User gewährt vor dem Upgrade nur Zugriff auf OpenAI-Funktionen - nach dem Upgrade aber alle Foundry-Features. Wer diese Rolle breit vergeben hat (z. B. per Wildcard-Policy oder Gruppenzuweisung), gewährt mit dem Upgrade unbeabsichtigt zusätzliche Berechtigungen. Nicht zu verwechseln mit der enger geschnittenen Rolle Cognitive Services OpenAI User: Die bleibt laut Microsoft vor wie nach dem Upgrade auf OpenAI-Funktionen beschränkt. Vor jedem Upgrade lohnt sich deshalb ein Blick in bestehende Rollenzuweisungen und Azure-Policies, die auf diese Rolle referenzieren.

Keiner dieser Punkte macht das Upgrade grundsätzlich riskant - aber sie zeigen, dass „Upgrade” hier mehr heißt als ein Klick im Portal, sobald Netzwerksegmentierung, Verschlüsselung oder differenzierte Berechtigungen im Spiel sind.

Was Microsoft Foundry mehr kann als die Azure-OpenAI-Ressource

Der Namenswechsel ist nicht nur Kosmetik: Er spiegelt, dass die Plattform inzwischen deutlich mehr als eine Hülle für OpenAI-Modelle ist. Im Modellkatalog stehen mittlerweile auch Modelle anderer Anbieter - etwa Claude von Anthropic, dazu je nach Region weitere Partnermodelle wie Mistral, Cohere oder Bildmodelle wie FLUX (Stand: August 2026, Verfügbarkeit variiert je Region). Eine Ressource, die reine „Azure OpenAI”-Ressource bleibt (kind: OpenAI), sieht diesen erweiterten Katalog nicht - er ist an das AIServices-Kind gebunden.

Für Unternehmen, die konkret an Claude in Microsoft Foundry interessiert sind - was der GA-Status von Claude in Microsoft Foundry konkret bedeutet, also Hosting-Optionen, Abrechnung und EU-Datenresidenz - , gehen wir in einem eigenen Beitrag in die Tiefe: Claude in Microsoft Foundry ist GA. Welcher Deployment-Typ dabei überhaupt EU-Verarbeitung liefert, ordnet ein weiterer Artikel ein: Global Standard, Data Zone und Regional im Vergleich. Wer zusätzlich prüfen will, was das für die DSGVO-Bewertung von KI-Workloads auf Azure bedeutet, findet den Gesamtüberblick hier: Claude DSGVO-konform betreiben.

Der Zeitanlass: Sunset der Assistants API

Ein Grund, warum das Thema gerade jetzt Fahrt aufnimmt: Die Assistants API ist von Microsoft als deprecated gekennzeichnet und zum 26.08.2026 ausgelaufen - Ersatz ist der Microsoft Foundry Agents Service, für den Microsoft einen eigenen Migrationsleitfaden bereitstellt. Bereits zum 30.05.2026 wurde außerdem das Paket azure-ai-inference retired (Migration auf das openai-Paket), und auch die „Agents (classic)” sind bereits als deprecated markiert; ihr Retirement ist für den 31.03.2027 terminiert.

Wer noch auf der Assistants API aufsetzt - etwa über Foundry (classic) - , muss den Umstieg auf die Responses API bzw. den Foundry Agents Service jetzt nachholen, unabhängig davon, ob die zugrunde liegende Ressource sonst upgegradet wird.

Wer sollte jetzt upgraden - und wer kann bleiben?

Aus den Fakten oben lässt sich eine pragmatische Faustregel ableiten:

Bleiben Sie vorerst auf Azure OpenAI, wenn Ihre Workloads ausschließlich OpenAI-Modelle nutzen, Sie keine Claude- oder Partnermodelle brauchen, und Ihr aktuelles Setup stabil läuft. Da beide Varianten „generally available and supported” sind, entsteht durch Abwarten kein technisches Risiko - außer bei Assistants-API-Workloads, die ohnehin migrieren mussten.

Upgraden Sie gezielt, wenn Sie Modelle jenseits von OpenAI einsetzen wollen (etwa Claude), Sie den Foundry Agents Service statt der ausgelaufenen Assistants API nutzen möchten, oder Sie ohnehin gerade neue Deployments aufsetzen - dort lohnt sich der direkte Start mit kind: AIServices mehr als ein späterer Umstieg.

Planen Sie das Upgrade als Projekt, nicht als Klick, wenn CMK, Private Endpoints, privates DNS oder breite RBAC-Zuweisungen im Spiel sind. Hier zahlt sich eine kurze Bestandsaufnahme vor dem Upgrade aus - insbesondere der Blick auf alle Zuweisungen der Rolle Cognitive Services User.

Wenn Sie diese Bestandsaufnahme nicht selbst durchführen möchten oder eine zweite Meinung zur bestehenden Azure-KI-Landschaft brauchen: Das ist genau der Punkt, an dem sich eine externe Einschätzung lohnt.

FAQ: Die häufigsten Verwirrungsfragen

Ist Azure AI Foundry dasselbe wie Microsoft Foundry?

Ja - es ist dieselbe Plattform unter neuem Namen. Microsoft dokumentiert die Entwicklung selbst als „Azure AI Studio → Azure AI Foundry → Microsoft Foundry (current)”: drei Namen für eine Plattform, zuletzt umbenannt zur Ignite 2025 im November 2025 (Stand: August 2026).

Ist Azure OpenAI eingestellt?

Nein. Der Begriff existiert weiter - als Modell-Kategorie innerhalb von Microsoft Foundry und über die reine Azure-OpenAI-Ressource (kind: OpenAI), die parallel weiterläuft. Beide Formen sind laut Microsoft „generally available and supported”.

Muss ich von Azure OpenAI auf Microsoft Foundry migrieren?

Nein. Das Upgrade von der Azure-OpenAI-Ressource auf eine Foundry-Ressource ist ausdrücklich opt-in und laut Microsoft reversibel. Es gibt keinen angekündigten Zwangstermin für bestehende Azure-OpenAI-Ressourcen. Eine Ausnahme sind Workloads auf der Assistants API - die ist unabhängig vom Ressourcen-Upgrade zum 26.08.2026 ausgelaufen. Für das Upgrade selbst dokumentiert Microsoft keine Zusatzkosten: „When you upgrade to Foundry, you don’t pay more for existing Azure OpenAI functionality.” Geld kosten können erst die Funktionen, die durch das Upgrade neu dazukommen - erweiterter Modellkatalog, Agent Service, Evaluation - , mit eigenen Preismodellen laut Azure-Preisrechner.

Ist „Foundry (classic)” dasselbe wie „Azure AI Foundry”?

Größtenteils ja: „Foundry (classic)” bezeichnet die frühere, Hub-basierte Portal- und Projektarchitektur mit Management Center und Assistants API. Sie ist weiterhin nutzbar und dokumentiert, bekommt laut Microsoft aber keine neuen Investitionen mehr - die Weiterentwicklung findet im aktuellen Foundry-Portal statt.

Brechen meine Terraform-Skripte durch die Umbenennung?

Nein, sofern sie auf Microsoft.CognitiveServices/accounts oder auf RBAC-Rollen-IDs zielen - beide sind laut Microsoft von der Umbenennung unberührt geblieben. Nur wer aktiv das kind-Attribut auf AIServices umstellt, löst das eigentliche Upgrade aus.

Fazit

Microsoft Foundry ist keine neue Plattform, sondern der aktuelle Name einer gewachsenen Plattform - mit stabilem Ressourcentyp und unverändert gültigen RBAC-Rollen-IDs im Hintergrund. Ein Upgrade von Azure OpenAI auf Foundry lohnt sich vor allem, wenn Sie Modelle jenseits von OpenAI nutzen wollen oder ohnehin neu aufsetzen - für reine Bestandssysteme besteht kein Zeitdruck, außer bei der ausgelaufenen Assistants API. Wer upgradet, sollte CMK, Private Endpoints, DNS und vor allem die Rechtevergabe über Cognitive Services User vorher prüfen statt hinterher zu reparieren.

Quellen (Stand: August 2026):

Aus Azure AI Foundry wird Microsoft Foundry: Was sich geändert hat - und was IT-Entscheider jetzt wissen müssen