Constantin, Azure und KI-Plattform bei Pexon Consulting | 11 Min. Lesezeit | aktualisiert 12.09.2026
TL;DR
Azure AI Foundry vs Copilot ist eine Schichtenfrage, kein Glaubenskrieg. Copilot Studio ist Low-Code für Fachprozesse in Power Platform. Azure AI Foundry ist Katalog, SDK, Evaluation und Agents im Azure-Tenant. Microsoft 365 Copilot ist der Seat, ein dritter Kasten. Der Plattform-Überblick bleibt der Leitfaden. Wer nur den Studio-Bot hat, bleibt im POC.
| Schicht | Job | Was sie nicht ist |
|---|---|---|
| Microsoft 365 Copilot | Seat in Word, Excel, Teams | keine eigene Plattform |
| Copilot Studio | Low-Code-Agent, Power Platform | kein Modellkatalog fürs Engineering |
| Azure AI Foundry | Modelle, Agents, Eval, Netz im Tenant | kein M365-Seat |
Welche Query welche URL behält
Azure AI Foundry vs Copilot Studio beantwortet die Auswahl. Es erklärt Foundry nicht noch einmal.
| Query | Owner |
|---|---|
| azure ai foundry | Leitfaden |
| Azure AI Foundry Beratung | Foundry-LP |
| Copilot Studio, Orchestrierung | Agent-Orchestrierung |
| Copilot Hybrid / offene Plattform | Hybrid-LP |
| Azure AI Foundry vs Copilot | dieser Text |
Früher hieß die Entwickleroberfläche Azure AI Studio. Der Produktname ist Azure AI Foundry. Studio im Rest dieses Textes meint Copilot Studio, nicht die alte Foundry-UI.
Drei Kästen, nicht Make oder Buy
Die alte Folie Copilot kaufen oder Foundry bauen vermischt drei Produkte. Azure AI Foundry vs Copilot Studio wird erst klar, wenn der Seat getrennt bleibt.
Microsoft 365 Copilot sitzt in den Office-Apps. Lizenz pro Nutzer. Gut für Entwurf, Meeting, Mail. Kein Ort für branchenspezifische Agenten auf Fachdaten außerhalb von M365.
Copilot Studio baut Agenten ohne Pipeline. Knowledge anbinden, testen, in Teams oder eine Website legen. Der erste Agent entsteht im Browser. Hier zählt die Grenze: Studio orchestriert Fachprozesse. Es ist nicht der Ort, an dem Platform Engineering Modelle versioniert, evaluiert und über Private Link legt.
Azure AI Foundry ist die Azure-Plattform: Model Catalog, Deployments, Agent Service, Evaluation, Content Safety, Netz und Identität im Tenant. Mehrere Use-Cases, eigene Daten, Audit. Die Tiefe steht im Leitfaden. Dieser Artikel entscheidet nur, wann Studio endet.
Seat (M365 Copilot)
-> Standardproduktivität in den Apps
Studio (Copilot Studio)
-> Fachprozess, Low-Code, Power Platform
Foundry (Azure AI Foundry)
-> Modelle, SDK, Eval, Agents unter Azure-GovernanceHybrid ist erlaubt. Seat wo er trägt, Studio für den Fach-Bot, Foundry wenn dasselbe Thema zum zweiten Mal gebaut wird oder Netz und Eval Pflicht werden. Die Hybrid-LP beschreibt die offene Kontrollplane. Sie stiehlt diesen Vergleich nicht.
Entscheidungsmatrix
| Frage | Copilot Studio | Azure AI Foundry |
|---|---|---|
| Wer baut? | Fachbereich plus Maker | Platform / Engineering |
| Daten | Knowledge, Connectoren, Dataverse | eigene Quellen, RAG, Private Link |
| Modelle | von Microsoft vorgegeben | Katalog, Routing, eigene Deployments |
| Governance | Power Platform, DLP, Umgebungen | Azure RBAC, Policy, Netz, Eval |
| Kostenlogik | Seat und Studio-Kapazität | Verbrauch, PTU, Kapazität im Tenant |
| Wann es reicht | ein Fachprozess, schnelle Demo | mehrere Teams, Audit, Wiederverwendung |
Keine erfundenen Nutzerzahlen. Ob Studio oder Foundry günstiger ist, hängt an Seats, Tokens und wie oft derselbe Agent kopiert wird. Das gehört in den Check, nicht in eine Folie mit einer magischen Nutzergrenze.
- Studio zuerst, wenn der Prozess in M365 oder Power Platform lebt und in Wochen sichtbar sein muss.
- Foundry zuerst, wenn Modelle, Eval oder Netz die eigentliche Arbeit sind.
- Beides, wenn der Fach-Bot in Studio startet und dasselbe Wissen später als Dienst im Tenant wiederverwendet wird.
Pexon-Meinung: Studio ist ein gültiger Einstieg. Es wird teuer, sobald derselbe Prompt in drei Abteilungen landet und niemand evaluiert. Dann ist Foundry die Plattform, nicht ein zweites Studio.
Was IT-Leiter in der ersten Stunde klären
Drei Fragen reichen. Alles andere ist Produktfolien.
Erstens: Lebt der Prozess in M365? Dann ist der Seat der Start, Studio höchstens der Bot daneben. Wer denselben Inhalt als API für ein Fachverfahren braucht, ist schon in Foundry.
Zweitens: Wer darf den Agent ändern, wenn der Fachbereich im Urlaub ist? In Studio hängt das oft an einer Umgebung und einem Maker. In Foundry hängen Identity, Repo und Pipeline. Wenn diese Antwort fehlt, bleibt der Bot ein POC, egal welches Produktlogo oben steht.
Drittens: Muss jemand halluzinierte Antworten gegen Referenzdaten messen? Dann ist Evaluation kein Nice-to-have. Foundry hat dafür den Werkzeugkasten. Studio zeigt, ob der Agent antwortet. Es zeigt selten, ob die Antwort in der Akte bestehen würde.
Daten entscheiden früher als Modelle. Connector plus Dateiablage reicht für interne FAQs. Sobald die Quelle in einem Netz hängt, das Power Platform nicht sehen darf, endet Studio. Private Link, eigene Indexe, eigene Chunk-Strategie: das ist Tenant-Arbeit.
Kosten folgen der Schicht. Der Seat ist planbar pro Kopf. Studio kommt als Kapazität und als Zeit der Maker. Foundry ist Verbrauch plus die Leute, die Deployments und Eval betreiben. Wer nur die Token-Preisliste vergleicht, ignoriert den teureren Posten: doppelte Agents ohne Owner.
Ein Muster, das wir oft sehen, ohne Namen: Fachbereich baut in Studio einen Bot auf Richtlinien-PDFs. Nach acht Wochen will der zweite Fachbereich denselben Inhalt. Kopieren verdoppelt Drift. Foundry macht daraus einen Dienst mit einem Index, einem Eval-Satz und einem Deployment. Studio darf der Kanal bleiben, über den der Mensch den Dienst trifft. Der Kanal ist nicht die Plattform.
Die Hybrid-LP sagt dasselbe für Copilot-Sitze plus offenes Gateway. Dieser Vergleich bleibt enger: Studio gegen Foundry, Seat als dritter Kasten, Leitfaden für die Plattformtiefe.
Was Azure AI Foundry vs Copilot Studio in der Praxis spaltet, ist Wiederholung. Ein Bot ist Studio. Der zweite Bot auf denselben Richtlinien, der dritte auf denselben Tickets: das ist Plattform. Foundry lohnt sich nicht, weil das Logo seriöser wirkt. Es lohnt sich, wenn Evaluation, Netz und ein Deployment mehrfach gebraucht werden.
Governance folgt dem Produkt. Power Platform DLP stoppt Connectoren. Azure Policy stoppt Deployments. Wer CISO-Fragen nur mit Studio-Umgebungen beantwortet, hat die Azure-Seite der Akte nicht. Wer umgekehrt Foundry aufsetzt, ohne denselben Fachprozess in einem Kanal zu landen, den Menschen täglich öffnen, hat eine Plattform ohne Nutzung.
Netz ist die harte Kante. Private Endpoints, eigene DNS, kein öffentlicher Modell-Endpunkt: Foundry. Studio holt Wissen über Connectoren, die das Netz der Power Platform sehen. Liegen die Daten hinter einem Jump Host, endet der Low-Code-Weg oder er erzeugt Schattenkopien. Schattenkopien sind der Befund, den Datenschutz zuerst findet.
Evaluation ist die zweite Kante. Ein Studio-Testchat ist kein Goldsatz. Foundry erlaubt, Antworten gegen Referenzfragen zu messen, Content Safety vorzuschalten und Deployments zu versionieren. Ohne diese Schleife bleibt jeder Agent eine Demo, auch wenn er in Teams hängt.
CI/CD ist die dritte. Maker klicken. Engineering merged. Sobald der Agent in einem regulierten Verfahren Antworten schreibt, die irgendwo in einer Akte landen, gehört die Änderung in Git. Studio kann der Kanal bleiben. Die Quelle der Wahrheit darf nicht der letzte Klick eines Makers sein.
Azure AI Foundry vs Copilot Studio bleibt damit eine Reihenfolge, kein Trophy. Wer noch keinen Bot hat, darf in Studio starten. Wer denselben Inhalt zum zweiten Mal baut, wechselt die Schicht. Der Leitfaden erklärt Foundry. Die Beratung setzt sie im Tenant. Dieser Text hält nur die Matrix.
Production-Gap: Studio-Agent ja, Tenant-Governance nein
Häufig gestellte Fragen
Was ist der Unterschied bei Azure AI Foundry vs Copilot Studio?
Copilot Studio ist Low-Code für Fachagenten. Azure AI Foundry ist die Azure-Plattform für Modelle, Agents und Evaluation. M365 Copilot bleibt der Seat in den Office-Apps.
Ist Azure AI Foundry dasselbe wie Azure AI Studio?
Die alte Oberfläche hieß Azure AI Studio. Der Name der Plattform ist Azure AI Foundry. Copilot Studio ist ein anderes Produkt.
Können wir beides nutzen?
Ja. Seat für Standardarbeit, Studio für den Fachprozess, Foundry wenn Plattform und Audit zählen.
Wohin mit einem reinen Copilot-Studio-Prototyp?
Zuerst der Low-Code-Weg im Studio, dann die Orchestrierung, sobald mehr als ein Agent hängt. Dieser Text entscheidet nur den Schnitt zur Plattform.
Ist das der Foundry-Leitfaden?
Nein. Der Leitfaden erklärt Foundry. Hier bleibt die Auswahl gegen Studio.
Nächster Schritt
Verwandte Themen
Wenn Foundry die Laufzeit trägt und der Agent trotzdem in Copilot oder Teams sichtbar sein soll, ist das der Job der Copilot Custom Engine Agents, nicht dieser Schichtvergleich.
