Microsoft Foundry vs. Azure OpenAI Service — die Verwirrung beenden

Letzte Woche, Kunden-Call. Architekt vom Mittelständler fragt: „Wir nutzen seit zwei Jahren Azure OpenAI. Müssen wir jetzt auf Foundry migrieren oder können wir das ignorieren?“

Drei Tage später, anderer Kunde: „Wir nutzen Document Intelligence für unsere Rechnungen. Ist das jetzt eigentlich auch Foundry? Oder gehört das woanders hin?“

Ich höre diese Fragen jede Woche. Und ich verstehe sie. Microsoft hat seine AI-Plattform innerhalb von 18 Monaten dreimal umbenannt — Azure AI Studio, Azure AI Foundry, jetzt Microsoft Foundry. Gleichzeitig wurden „Cognitive Services“ zu „Azure AI Services“ umbenannt, und „Form Recognizer“ zu „Document Intelligence“. Wer da nicht durchblickt, ist nicht doof. Der ist nur ein normaler IT-Pro mit zu vielen Baustellen.

Dieser Artikel räumt auf. Kein Marketing-Sprech, keine Feature-Liste. Drei Fragen, drei klare Antworten — und ein Entscheidungsbaum, den du nach dem Lesen anwenden kannst.

Das große Bild — Azure AI Services, OpenAI Service, Foundry

Bevor wir vergleichen, brauchen wir die Hierarchie. Sonst diskutieren wir Äpfel mit Birnen.

Ebene 1 — Azure AI Services (die Familie der AI-APIs)

Eine ganze Sammlung spezialisierter KI-Services, jeder mit eigener API, eigenem Resource-Typ, eigenem Preismodell. Die wichtigsten:

  • Azure OpenAI Service — GPT-4o, o-Serie, Embeddings, DALL-E
  • Azure AI Document Intelligence — Layout-Erkennung, Prebuilt-Modelle für Rechnungen/Ausweise/Visitenkarten, Custom-Modelle
  • Azure AI Vision — Bildanalyse, OCR, Object Detection
  • Azure AI Speech — STT, TTS, Translation, Speaker Recognition
  • Azure AI Language — Entity Extraction, Sentiment, Summarization, PII-Erkennung
  • Azure AI Search — Hybrid Search (Keyword + Vector + Semantic Ranking)
  • Azure AI Content Safety — Moderation, Jailbreak-Detection, Groundedness
  • Azure AI Translator

Alle diese Services kannst du direkt per REST/SDK ansprechen. Sie funktionieren komplett ohne Foundry. Document Intelligence existiert seit 2019, OpenAI Service seit 2023 — Foundry ist neuer als beide.

Ebene 2 — Microsoft Foundry (die Plattform drumherum)

Eine UI, ein Hub-Konzept, ein Agent Service, ein Model Catalog, Prompt Flow, Evaluations, Tracing. Foundry bindet die AI Services via Connections ein. Du kannst in Foundry einen Agent bauen, der intern Document Intelligence aufruft, dann ein Embeddings-Modell, dann GPT-4o — alles orchestriert, evaluiert, getraced.

ℹ️
Der Knoten löst sich so

Foundry ersetzt keinen einzigen AI Service. Foundry dirigiert sie. Du kannst jeden Service solo nutzen — oder du nutzt Foundry als Orchestrator drumherum.

Wo passt Document Intelligence konkret rein?

Drei Pattern aus der Praxis:

Pattern A
Document Intelligence solo
Du hast Rechnungen, willst Header-Felder, Lieferadresse, Positionen, Gesamtbetrag extrahieren. Prebuilt-Invoice-Modell aufrufen, JSON zurückbekommen, in dein ERP schreiben. Fertig. Kein LLM nötig, kein Foundry nötig. Ein API-Call, deterministisches Schema, vorhersehbare Kosten.
Pattern B
Document Intelligence als Pre-Step für RAG
Chatbot über deine Vertragssammlung. Pipeline: Document Intelligence Layout-Modell extrahiert Text + Tabellen + Überschriften strukturiert aus PDFs (deutlich besser als simples PDF-zu-Text), dann chunked dein Code semantisch, dann Embeddings via OpenAI, dann ab in AI Search als Vektor-Index, zur Laufzeit GPT-4o mit Retrieval. Drei AI Services nebeneinander — entweder im Code orchestriert oder via Foundry Prompt Flow zusammengeklickt.
Pattern C
Document Intelligence als Tool eines Foundry-Agents
Schadens-Triage-Agent in der Versicherung. User lädt Schadensbericht hoch. Agent ruft autonom Document Intelligence (Custom-Modell für Schadensformulare), dann Language-Modell für Sentiment, dann GPT-4o für Klassifikation und nächste Action. Foundry Agent Service Pflicht, weil du Tool-Calls, Memory, Multi-Step-Reasoning und Tracing brauchst.

Die Regel: Document Intelligence wird mit jedem Schritt Richtung „intelligenter Workflow“ wichtiger. Solo für strukturierte Extraktion. Im Verbund für Verständnis. Im Agent für Aktion.

Wann reicht dir Azure OpenAI Service?

Drei Bedingungen, alle drei müssen zutreffen:

  1. Du brauchst ausschließlich OpenAI-Modelle. Kein Phi, kein Llama, keine Open-Source.
  2. Dein Anwendungs-Code lebt woanders — Function App, AKS, eigene Plattform — und du baust deine Pipeline-, Eval- und Monitoring-Logik selbst oder hast sie schon.
  3. Dein Use-Case ist im Kern: „Prompt rein, Antwort raus, fertig.“ Klassische RAG, Chatbot mit eigenem Backend, Batch-Klassifikation.

Wenn das passt: Kein Foundry nötig. OpenAI Service deployen, Endpoint, fertig. Du sparst dir Hub/Project-Hierarchie und die Lernkurve.

Wann brauchst du Foundry?

Sobald eines dieser Dinge zutrifft:

  • Du willst Modelle vergleichen — GPT-4o gegen Llama 3 gegen Phi-4 für denselben Use-Case
  • Du baust Agents (nicht „Chatbots“, echte Agents mit Tools, Memory, Multi-Step-Reasoning)
  • Du brauchst systematische Evaluations — Groundedness, Coherence, Custom-Metriken über Test-Datasets
  • Du willst Tracing über mehrere Steps hinweg (welcher Step hat halluziniert?)
  • Du orchestrierst mehrere AI Services in einer Pipeline (Document Intelligence → Embeddings → AI Search → GPT-4o)
  • Du willst eine UI für deine Data Scientists, in der sie ohne IT-Ticket Connections, Datasets und Deployments verwalten
  • Du brauchst zentrale Governance über mehrere AI-Projekte (Hub-Konzept) mit geteilten Resources

Übersetzt: Foundry lohnt sich, sobald AI mehr ist als ein zusätzlicher API-Call in deiner App.

Die Vergleichstabelle, die du brauchst

Aspekt Azure AI Service (z.B. OpenAI, Doc Intelligence) Microsoft Foundry
Was es ist Spezialisierter API-Service Plattform mit eigener UI
Modellauswahl Ein Service = eine Modellfamilie 1.800+ Modelle aus Catalog + alle AI Services per Connection
Setup-Zeit 10 Minuten 1–2 Stunden (Hub, Project, Connections)
Bedienung Azure Portal + REST/SDK Eigene Foundry-UI + SDK
Orchestrierung mehrerer Services Selbst bauen Prompt Flow + Agents eingebaut
Evaluations Selbst bauen Eingebaut, inkl. AI-Judge
Agents Self-built mit SDK Foundry Agent Service
Tracing Selbst (App Insights) Eingebaut über alle Steps
Governance Per Subscription/RG Hub-zentral über Projects hinweg
Lernkurve Niedrig Mittel
Kosten Token-/Call-basiert pro Service Token-/Call-basiert (gleich) — Plattform selbst kostenlos
Gut zu wissen

Foundry ist nicht teurer. Die Plattform selbst ist gratis, du zahlst nur die darunterliegenden Service-Calls — wie bei der Direkt-Nutzung auch.

Drei Szenarien aus meinem Beratungs-Alltag

Szenario 1: Klassischer M365-Kunde, sucht „Chatbot für interne Doku“

RAG-Pattern, GPT-4o, AI Search als Vektor-Store, Azure OpenAI Service direkt. Wenn die Doku nur Word/PDF mit Standardtext ist: ohne Document Intelligence. Sind die PDFs gescannt oder enthalten Tabellen, die wichtig sind: Document Intelligence Layout als Pre-Step. Foundry wäre Overkill. Setup an einem Tag durch, geht in Produktion in zwei Wochen.

Szenario 2: Versicherung, will Agent für Schadens-Triage

Foundry Pflicht. Agent Service, Document Intelligence Custom-Modell für die Schadensformulare als Tool, Language Service für Sentiment, GPT-4o für die finale Klassifikation. Self-built mit LangChain geht auch — aber dann betreibst du Tracing, Evaluation und Tool-Schema-Verwaltung selbst. In zwei Jahren willst du das nicht mehr.

Szenario 3: KMU, evaluiert „bringt uns Open-Source-LLM Kostenvorteile?“

Foundry. Genau dafür ist der Model Catalog da. Phi-4 lokal, Llama 3 in Foundry, GPT-4o als Baseline, alle drei mit identischen Test-Prompts und Eval-Dataset vergleichen. In OpenAI Service alleine kannst du das nicht.

Was Microsoft hier richtig macht — und was nicht

Richtig: Foundry ist die einzige Plattform am Markt, die OpenAI-Modelle, Open-Source-Modelle, proprietäre Microsoft-Modelle UND die spezialisierten AI Services (Document Intelligence, Vision, Speech, Language) unter einem Dach hat — mit Enterprise-Governance. Das gibt dir AWS Bedrock so nicht, das gibt dir Google Vertex AI so nicht.

Nicht richtig: Das Naming-Chaos. Azure AI Studio → Azure AI Foundry → Microsoft Foundry. Cognitive Services → Azure AI Services. Form Recognizer → Document Intelligence. Dazu „Foundry Agent Service“ vs. „Foundry Hub“ vs. „Foundry Project“ vs. der nicht mehr existierende „Azure AI Hub“. Wer als Berater mit drei Kunden auf drei verschiedenen Naming-Ständen arbeitet, weiß was ich meine. Microsoft sollte hier einmal aufräumen und dann fünf Jahre Ruhe geben.

⚠️
Stille Annahme, die du kennen solltest

EU Data Boundary gilt für OpenAI-Modelle in Azure OpenAI Service und für die meisten klassischen AI Services (Document Intelligence, Vision, Language) vollständig. Für Modelle aus dem Foundry Model Catalog (Llama, Mistral und andere) gilt sie nicht automatisch — prüfe jedes Modell einzeln im Catalog. Typisches Audit-Finding, das du vermeiden willst.

Mein Entscheidungsbaum für dich

1
Strukturierte Extraktion aus Dokumenten ohne LLM-Magie?
Document Intelligence solo
2
Nur OpenAI-Modelle UND Drumherum-Logik selbst gebaut?
Azure OpenAI Service
3
Mehrere AI Services in einer Pipeline orchestriert, mit Tracing/Eval?
Foundry mit Prompt Flow
4
Agent mit Tools, Memory, Multi-Step?
Foundry Agent Service
5
Unsicher und willst klein anfangen?
Foundry Project mit OpenAI als erstem Deployment. Hält die Tür offen. Migration später kostet dich nichts außer den Workspace umzuschalten.

Punkt 5 ist mein Standard-Rat für 80% der Kunden. Du verlierst nichts, du gewinnst Optionalität.

☕ Fazit · Ferdi-Style

Was bleibt

Azure OpenAI Service ist ein Service. Document Intelligence ist noch ein Service. Vision, Speech, Language sind weitere. Microsoft Foundry ist die Plattform, die sie alle orchestriert. Du nutzt immer einen oder mehrere Services — entweder direkt oder durch die Plattform hindurch. Die Frage ist nie „Foundry ODER AI Service“, sondern „Foundry-Plattform drumherum: ja oder nein?“. Und die Antwort hängt nicht an Tech, sondern an deinem Use-Case.

Espresso-Moment

Ein guter Espresso braucht mehr als nur Bohnen — Mühle, Maschine, Wasser, Tamper. OpenAI Service ist eine Bohne. Document Intelligence ist eine Mühle. Foundry ist die Siebträger-Maschine, in der alles zusammenspielt. Du kannst die Bohnen pur kauen. Aber für alles, was nach Trinken aussehen soll, brauchst du das passende Werkzeug zur jeweiligen Aufgabe — und manchmal das ganze Setup gleichzeitig.

Das nimmst du mit

  • Foundry ersetzt keine AI Services — Foundry orchestriert sie
  • Document Intelligence ist ein eigenständiger AI Service, kein Foundry-Feature
  • Reines API-Szenario mit OpenAI-only → OpenAI Service reicht
  • Strukturierte Doku-Extraktion ohne Magie → Document Intelligence solo
  • Sobald mehrere Services zusammenspielen, Agents, Evals oder Multi-Model → Foundry
  • Foundry-Plattform kostet nichts extra — du zahlst nur die Service-Calls
  • EU Data Boundary für Catalog-Modelle (Llama, Mistral) einzeln prüfen
  • Bei Unsicherheit: Foundry Project mit OpenAI Deployment starten — maximale Optionalität
Ferdi Lethen-Oellers
Geschrieben von Ferdi Lethen-Oellers Microsoft MVP

Senior Modern Workplace Consultant bei amexus · Speaker · Autor von „Microsoft 365 Administration für Dummies“.

Frage oder Feedback? Schreib mir auf LinkedIn.

#EspressoM365Fusion