Azure OpenAI Service: Integration in Microsoft 365 Copilot-Erweiterungen

Consulting Briefing · 07.08.2026 · boddenberg.de

Executive Summary

Kurzfassung für alle, die gleich ins nächste Meeting müssen: Azure OpenAI ist nicht länger der kleine Extradienst, den sich die Entwicklungsabteilung heimlich in einer Subscription angelegt hat. Er ist der Motor unter jeder Copilot-Erweiterung, die über den Werkszustand hinausgeht. Der Dienst heißt inzwischen offiziell „Azure OpenAI in Foundry Models“ und wohnt in Microsoft Foundry — jener Plattform, die bis vor kurzem noch Azure AI Foundry hieß und davor Azure AI Studio. Wenn du dich beim Lesen fragst, ob du etwas verpasst hast: ja, aber nur den Namen.

Die eigentliche Nachricht ist eine architektonische. Microsoft hat die Copilot-Erweiterbarkeit sauber in zwei Welten geteilt. Declarative Agents nutzen Microsofts Modelle und Microsofts Orchestrator, du lieferst nur Instruktionen, Wissen und Aktionen. Custom Engine Agents bringen eigene Modelle und eigene Orchestrierung mit, und genau hier kommt Azure OpenAI ins Spiel. Seit Sommer 2026 kannst du einen fertigen Foundry-Agenten mit wenigen Klicks direkt aus dem Foundry-Portal nach Microsoft 365 Copilot und Teams veröffentlichen. Foundry legt dabei automatisch den Azure Bot Service samt Entra-Registrierung an und schiebt das Teams-Manifest in den Agentenkatalog deines Tenants.

Für dich als Entscheider heißt das: Die technische Hürde ist gefallen, die organisatorische ist gestiegen. Wer heute ohne Governance-Konzept loslegt, hat in sechs Monaten dreißig Agenten im Tenant, von denen niemand weiß, welches Modell sie benutzen, auf welche Postfächer sie zugreifen und welche Kostenstelle die Token bezahlt. Die gute Nachricht: Microsoft hat mit Entra Agent ID und Agent 365 die Werkzeuge dafür geliefert. Die schlechte: Sie kosten extra, und niemand hat sie eingeplant.

Worum geht es im Detail?

Fangen wir mit dem an, was in den meisten Präsentationen fehlt: der Anatomie. Eine Copilot-Erweiterung besteht immer aus denselben fünf Schichten. Oben die Oberfläche, in der der Anwender tippt — Copilot Chat, Teams, Outlook, Word. Darunter der Agententyp. Dann die Orchestrierung, also die Instanz, die entscheidet, welches Werkzeug wann gerufen wird. Darunter das Modell. Und ganz unten Wissen und Aktionen. Azure OpenAI sitzt in der vierten Schicht. Das klingt banal, ist aber der entscheidende Punkt: Du kannst nicht ein bisschen Azure OpenAI in einen Declarative Agent hineinstreuen. Entweder du nutzt Microsofts Modell, oder du übernimmst die ganze Schicht darunter gleich mit.

Abbildung 1: Der Erweiterungsstapel. Je tiefer und weiter rechts du greifst, desto mehr Verantwortung wechselt den Besitzer.

Declarative Agent — der bequeme Weg

Ein Declarative Agent ist im Kern eine JSON-Datei mit Anweisungen. Du beschreibst, wie sich Copilot verhalten soll, hängst Wissensquellen an — SharePoint, OneDrive, Teams-Nachrichten, Copilot Connectors — und definierst Aktionen über OpenAPI oder inzwischen über MCP-Server. Orchestrator und Modell stellt Microsoft. Der Vorteil ist erdrückend: keine Hostingkosten, keine Inferenzrechnung, und die Compliance-, Sicherheits- und Responsible-AI-Zusagen von Microsoft 365 gelten automatisch mit. Seit Manifest 1.8 kann so ein Agent auch schreiben — Mails triagieren, Termine anlegen, Postfachregeln setzen, Antworten vorbereiten. Wer bei diesem Satz kurz zusammengezuckt ist, hat den Risikoabschnitt schon verstanden.

Custom Engine Agent — der Weg mit Azure OpenAI

Sobald du ein anderes Modell brauchst, eigene Geschäftslogik erzwingen musst oder der Agent auch außerhalb von Microsoft 365 leben soll, landest du beim Custom Engine Agent. Hier bringst du Orchestrator und Modell selbst mit. Vier Wege führen dorthin: Copilot Studio als Low-Code-Variante, die per „Bring Your Own Model“ Modelle aus Foundry einbinden kann. Das Teams SDK für gruppenzentrierte Szenarien in Kanälen und Besprechungen. Das Microsoft 365 Agents SDK für Multi-Channel-Agenten mit eigenem Orchestrator, typischerweise Agent Framework oder LangChain. Und schließlich Microsoft Foundry selbst.

Der Foundry-Weg ist der interessanteste, weil er 2026 erwachsen geworden ist. Du baust und testest den Agenten im Foundry-Portal, wählst eine aktive Version — entweder fest gepinnt oder „immer die neueste“ — und drückst auf Publish. Foundry validiert die Metadaten, kompiliert ein Teams-App-Manifest als ZIP, reicht es bei den Copilot- und Teams-Katalogen ein, aktiviert das Activity-Protokoll und setzt ein Autorisierungsschema. Veröffentlichst du nur für dich selbst, geht das ohne Freigabe. Veröffentlichst du für die Organisation, landet der Antrag im Microsoft 365 Admin Center und wartet auf einen Menschen. Danach erscheint der Agent im Store unter „Built by your org“.

Ein Detail, das viele übersehen: Der veröffentlichte Endpunkt ist stabil. Du rollst neue Agentenversionen in Foundry aus, und die Anwender merken davon nichts, solange der Versionsselektor auf „immer neueste“ steht. Das ist elegant und gefährlich zugleich. Elegant, weil du ohne erneutes Publish aktualisierst. Gefährlich, weil eine neue Version am Freitagabend produktiv geht, ohne dass jemand einen Change-Record gesehen hat. Wer schon einmal einen Freitagabend-Rollout erlebt hat, kennt den Rest der Geschichte inklusive Wochenendbereitschaft.

Abbildung 2: Der Entscheidungspfad. Die meisten Projekte kommen weiter oben zur Ruhe, als ihre Beteiligten sich das wünschen.

Praxisbeispiel aus einem mittelständischen Maschinenbau im Frühjahr: Die Fachabteilung wollte einen Agenten, der Serviceberichte auswertet. Der Entwicklungsleiter hatte bereits eine Foundry-Instanz mit einem feingetunten Modell, also klarer Fall für Publish aus Foundry. Nach zwei Wochen Betrieb stellte sich heraus: Achtzig Prozent der Anfragen waren schlichte Volltextsuchen in SharePoint. Ein Declarative Agent mit angebundenem Bibliothekswissen hätte das genauso gut beantwortet, zu exakt null zusätzlichen Kosten. Die Lehre ist unangenehm, wiederholt sich aber in fast jedem Projekt: Die Modellwahl ist selten das Problem. Die Datenqualität ist es immer.

Was sind Chancen? Was sind Risiken?

Die Chance ist konkret und sie ist wirtschaftlich. Wer bereits KI-Logik in Foundry betreibt, für ein Portal, eine App oder einen internen Dienst, kann dieselbe Logik ohne Neuentwicklung dorthin bringen, wo die Leute ohnehin den ganzen Tag sitzen. Das ist der eigentliche Hebel: nicht noch ein Chatbot, sondern eine bestehende Fachlogik, die plötzlich in Teams ansprechbar ist. Dazu kommt Modellvielfalt. Foundry führt heute nicht nur OpenAI-Modelle, sondern auch Anthropic, Meta, Mistral, xAI und feingetunte Varianten. Du kannst pro Aufgabe entscheiden, welches Modell rechnet: ein kleines für Klassifikation, ein großes für die Analyse.

Die zweite Chance ist Governance, und zwar ausnahmsweise ernst gemeint. Mit Entra Agent ID bekommt jeder Agent eine eigene Identität statt eines geteilten Dienstkontos, das seit 2019 SVC-KI-TEST heißt und dessen Kennwort im Wiki steht. Agent 365 ist seit Mai 2026 der zentrale Katalog und die Kontrollebene für alle Agenten im Tenant. Zum ersten Mal kannst du die Frage „Was läuft hier eigentlich?“ beantworten, ohne drei Abteilungen zu befragen und zwei davon zu verärgern.

Jetzt die Risiken, und davon gibt es drei ernsthafte. Erstens die Kosten. Ein Declarative Agent kostet dich über die Lizenz hinaus nichts. Ein Foundry-Agent kostet Modell-Inferenz nach Token, Bot Service, gegebenenfalls App Service und den laufenden Betrieb. Diese Kosten landen nicht in der Microsoft-365-Rechnung, sondern in der Azure-Rechnung, also bei einer anderen Kostenstelle, oft in einer anderen Abteilung, gern erst im Quartalsbericht. Der Klassiker: Ein Pilot mit fünfzehn Anwendern kostet vierzig Euro im Monat, alle sind begeistert, dann geht er auf achthundert Anwender und niemand hat die Kurve vorher extrapoliert.

Abbildung 3: Wo die Kosten entstehen. Die Längen sind relativ, das Muster ist es leider nicht.

Zweitens die Compliance. Bei Declarative Agents erbst du Microsofts Zusagen. Bei Custom Engine Agents nicht. Microsoft schreibt das erfreulich unmissverständlich in die Dokumentation: Du musst selbst für Compliance, verantwortungsvolle KI und Sicherheit sorgen. Und beim Veröffentlichen aus Foundry heraus fließen Daten in Microsoft-365-Dienste, die dann deren Bedingungen, Compliance-Zusagen und Datenresidenz unterliegen. Wer in einem regulierten Umfeld arbeitet, sollte diesen Satz zweimal lesen und danach den Datenschutzbeauftragten anrufen. Vor dem Piloten, nicht danach.

Drittens der Wildwuchs. Der Agent Builder in Microsoft 365 Copilot ist so einfach zu bedienen, dass Fachanwender inzwischen in natürlicher Sprache beschreiben, was der Agent tun soll, und die Konfiguration automatisch entsteht. Das ist gewollt und richtig. Es bedeutet aber, dass die Zahl der Agenten in deinem Tenant nicht linear, sondern exponentiell wächst. Ohne Freigabeprozess, ohne Namenskonvention und ohne Lebenszyklusregel hast du in einem Jahr ein Agentenarchiv, das aussieht wie euer SharePoint 2013 aussah. Nur dass diese Objekte jetzt E-Mails verschicken können und Termine absagen.

Was müssen wir jetzt schon vorbereiten?

Erstens die Identitätsfrage klären, bevor der erste Agent produktiv geht. Entra Agent ID ist allgemein verfügbar und gibt jedem Agenten eine eigene, verwaltbare Identität. Agent 365 ist die Registry und Kontrollebene darüber. Beides kostet Geld: Agent 365 liegt bei fünfzehn Dollar pro Anwender und Monat und steckt im neuen Microsoft-365-E7-Paket. Für die Governance von Agentenidentitäten über Entra ID Governance brauchst du entweder E7 oder eine Agent-365-Lizenz plus mindestens Entra P1. Das ist eine Budgetposition, keine Fußnote. Und die Agent-Registry im Entra Admin Center ist zum 1. Mai 2026 abgeschaltet worden, falls dort noch jemand sucht und sich über leere Blades wundert.

Zweitens einen Entscheidungspfad definieren und auf eine Seite schreiben. Die Frage lautet nicht „Wollen wir Azure OpenAI?“, sondern „Warum genau reichen Copilots eigene Modelle für diesen Fall nicht?“. Wer das nicht in zwei Sätzen beantworten kann, baut einen Declarative Agent. Punkt. Diese eine Regel spart mehr Geld als jede Modelloptimierung, die du danach betreiben könntest.

Drittens die Azure-Grundlagen bauen, bevor die Fachabteilung drängt. Registriert den Resource Provider Microsoft.BotService. Legt fest, in welcher Ressourcengruppe Bot-Ressourcen entstehen dürfen. Vergebt die Rolle Azure Bot Service Contributor gezielt, statt Contributor flächendeckend zu verteilen. Klärt, ob eure Foundry-Projekte öffentlichen Netzwerkzugriff haben — ist er deaktiviert, funktioniert das Veröffentlichen über das Portal nicht und ihr braucht den REST-Weg. Diese vier Punkte kosten vorher einen Tag und hinterher drei Wochen.

Viertens die Evaluierung einplanen. Seit Mai 2026 gibt es ein Evaluierungsframework samt CLI-Werkzeug für Agenten, mit dem sich Tests definieren, ausführen und auswerten lassen. Das ist nicht optional. Ein Agent ohne Testfälle ist eine Meinung mit API-Zugriff. Legt einen Satz Referenzfragen mit erwarteten Antworten an, bevor ihr live geht, und lasst ihn bei jeder Modell- oder Promptänderung durchlaufen. Modelle werden im Hintergrund aktualisiert; euer Agent ändert sein Verhalten, ohne dass jemand eine Zeile Code angefasst hat.

Fünftens, und das ist die unbequemste Vorbereitung: Räumt eure Daten auf. Jede Erweiterung, die auf Tenant-Wissen zugreift, macht Berechtigungsfehler sichtbar, die seit Jahren unbemerkt existieren. Wenn die Gehaltsliste in einer SharePoint-Bibliothek liegt, auf die „Jeder“ Leserechte hat, dann war das gestern ein latentes Problem und ist morgen ein Vorfall mit Zeitstempel und Protokoll. Ein Agent liest schneller als der neugierigste Kollege, er wird nicht müde, und er dokumentiert jeden Treffer. Das ist die Stelle, an der KI-Projekte üblicherweise in ein Berechtigungsprojekt umbenannt werden.

Häufig gestellte Fragen

Brauche ich für einen Copilot-Agenten überhaupt Azure OpenAI?

Nein, in den meisten Fällen nicht. Declarative Agents nutzen die Modelle und den Orchestrator von Microsoft 365 Copilot und verursachen dadurch keine zusätzlichen Modell- oder Hostingkosten. Azure OpenAI beziehungsweise Microsoft Foundry brauchst du erst, wenn du ein bestimmtes oder feingetuntes Modell, eigene Orchestrierung oder Kanäle außerhalb von Microsoft 365 benötigst.

Was kostet ein Custom Engine Agent im laufenden Betrieb?

Das hängt an drei Posten: Modell-Inferenz nach Token, Hosting für Orchestrator und Bot Service, sowie Copilot Credits, wenn Anwender ohne Copilot-Lizenz über den Agenten auf geteilte Tenant-Daten zugreifen. Diese Kosten erscheinen auf der Azure-Rechnung und nicht auf der Microsoft-365-Rechnung, weshalb du vorab eine Kostenstelle und einen Budget-Alert festlegen solltest.

Wie bringe ich einen bestehenden Foundry-Agenten in Microsoft 365 Copilot?

Im Foundry-Portal wählst du die aktive Agentenversion, öffnest Publish und dann „Teams and Microsoft 365 Copilot“. Foundry legt automatisch einen Azure Bot Service an, baut das Teams-Manifest und reicht es beim Katalog ein; bei organisationsweiter Veröffentlichung muss ein Administrator die Anfrage im Microsoft 365 Admin Center freigeben, bei Veröffentlichung nur für dich selbst entfällt die Freigabe.

Gelten die Compliance-Zusagen von Microsoft 365 auch für eigene Modelle?

Nur eingeschränkt. Declarative Agents erben die Sicherheits-, Compliance- und Responsible-AI-Standards von Microsoft 365 vollständig. Bei Custom Engine Agents mit eigenen Modellen musst du Compliance, Datenschutz und verantwortungsvolle KI-Praxis selbst sicherstellen; gespeichert und über Purview auffindbar bleiben allerdings auch dort die Prompts und Antworten aus Copilot Chat und Teams.

Wie verhindere ich, dass in unserem Tenant unkontrolliert Agenten entstehen?

Über drei Hebel: den Freigabeprozess für organisationsweite Agenten im Microsoft 365 Admin Center, Entra Agent ID für eindeutige Agentenidentitäten und Agent 365 als zentralen Katalog und Kontrollebene. Ergänzend steuerst du per Anwendungsrichtlinie, welche Benutzergruppen Agenten überhaupt erstellen, teilen und installieren dürfen.