Produktive KI auf Microsoft Foundry: ein privates Referenz-Setup für Agenten
Die meisten KI-Piloten auf Azure beginnen mit einem Key, der in eine App kopiert wird, und einem Modell-Endpunkt, der offen im Internet hängt. Für eine Demo reicht das, beim ersten Security-Review fällt es durch. Das hier ist das Setup, das ich verwende, wenn ein Agent auf Microsoft Foundry live gehen soll: Entra ID statt Keys, alles hinter Private Endpoints, Guardrails auf jedem Schritt des Agenten, Evaluationen vor jedem Release und Traces in Application Insights. Jede Aussage verweist auf die offiziellen Microsoft-Seiten, damit Sie sie prüfen können.
11 Min. Lesezeit
1. Wann Azure das richtige Zuhause für Ihre KI ist, und was sich bei den Namen geändert hat
Azure ist die naheliegende Wahl, wenn Ihr Unternehmen schon in der Microsoft-Welt lebt: Identitäten in Entra ID, Dokumente in SharePoint, Menschen in Teams, Workloads in Azure-Subscriptions mit Landing Zones und Policies. Dann erbt Ihre KI-Plattform die Governance, die Sie bereits haben, statt eine zweite aufzubauen. Die Modellauswahl ist breit: Microsoft beschreibt im Foundry-Models-Katalog Zugriff auf mehr als 10'000 Modelle von Microsoft, OpenAI, Anthropic, Meta und weiteren.
Die Namen haben sich zweimal geändert, was viele Suchergebnisse verwirrt. Microsofts eigene Übersichtsseite zeigt die Geschichte: Azure AI Studio, dann Azure AI Foundry und heute Microsoft Foundry. Auch die Agent-API hat gewechselt. Dieselbe Seite ordnet die alte Assistants API (Agents v0.5/v1) der Responses API (Agents v2) zu, und die alten Begriffe Threads, Messages und Runs werden zu Conversations, Items und Responses. Wenn ein Tutorial noch Threads und Runs anlegt, beschreibt es die klassische Variante.
Im Rest des Artikels folge ich der aktuellen Microsoft-Learn-Dokumentation zu Foundry und der Baseline-Referenzarchitektur für Microsoft-Foundry-Chat im Azure Architecture Center, dem offiziellen Bauplan, der einem Enterprise-Agenten am nächsten kommt.
2. Ressource, Projekt und Identität: keine Keys im Code
Foundry hat zwei Ebenen: eine Foundry-Ressource mit Netzwerk, Policies und Modell-Deployments und darin Projekte, in denen Teams Agenten bauen. Legen Sie die Ressource mit einer systemzugewiesenen Managed Identity und aktivierter Projektverwaltung an. Microsofts Quickstart sagt klar, dass die Projekterstellung ohne Managed Identity fehlschlägt und dass die Azure CLI für die Projektbefehle mindestens Version 2.80.0 braucht.
Lassen Sie Anwendungen ab Tag eins über Microsoft Entra ID authentifizieren: Die Web-App nutzt ihre Managed Identity, Menschen erhalten Rollen über Gruppen, und niemand kopiert einen API-Key in eine Konfigurationsdatei. Die Baseline-Architektur macht genau das: Die Web-App ruft den Agenten über einen Private Endpoint auf und authentifiziert sich mit ihrer Managed Identity bei Foundry. Keys sind die Ausnahme für Tools ohne Entra-ID-Unterstützung, und dann gehören sie mit Rotation in Key Vault, nicht in den Code.
Halten Sie mindestens zwei Projekte, besser zwei Ressourcen in getrennten Subscriptions, für Nicht-Produktion und Produktion. Modell-Deployments, Quoten und Guardrails unterscheiden sich, und Sie wollen eine Änderung testen, bevor Ihre Kunden sie erleben.
# Azure CLI 2.80.0+ (project commands). Names are examples.
az group create --name my-foundry-rg --location eastus
# Foundry resource with a managed identity and project management
az cognitiveservices account create \
--name my-foundry-resource \
--resource-group my-foundry-rg \
--kind AIServices \
--sku S0 \
--location eastus \
--custom-domain my-foundry-resource \
--assign-identity \
--allow-project-management true
# A project for the team that builds the agent
az cognitiveservices account project create \
--name my-foundry-resource \
--resource-group my-foundry-rg \
--project-name my-foundry-project \
--location eastusTipp aus der Praxis
Scheitert die Projekterstellung mit dem Hinweis, dass eine Managed Identity aktiviert sein muss, wurde die Ressource ohne --assign-identity angelegt. Korrigieren Sie es dort, statt auf Keys auszuweichen.
3. Standardmässig privat: das Standard-Agent-Setup im eigenen Netzwerk
Der Foundry Agent Service bietet ein Standard-Setup mit privatem Netzwerk. Dabei bringen Sie Ihr eigenes virtuelles Netzwerk und eigene Azure-Ressourcen für Chat- und Agentenzustand mit: Azure Storage für Dateien, Azure Cosmos DB für Konversationen und Azure AI Search für Vektordaten. Alle liegen hinter Private Endpoints, und der öffentliche Netzwerkzugriff auf die Foundry-Ressource ist deaktiviert. Die Baseline-Referenzarchitektur ergänzt die Ränder: Nutzer kommen über Azure Application Gateway mit Web Application Firewall herein, die Chat-Oberfläche läuft auf App Service über drei Availability Zones, und ausgehender Verkehr der Agenten läuft strikt über Azure Firewall, die Egress-Regeln durchsetzt.
Der letzte Punkt ist wichtiger, als er aussieht. Ein Agent mit Websuche oder MCP-Verbindung ist Software, die im Auftrag eines Prompts nach aussen ruft. Mit einer expliziten Egress-Allowlist auf der Firewall kann eine Prompt Injection Daten nicht still an einen beliebigen Host schicken.
Planen Sie Subnetze und private DNS-Zonen, bevor Sie etwas anlegen. Die Architektur nutzt getrennte Subnetze für die App-Service-Integration, Private Endpoints, die Agenten-Integration, Azure Bastion, Build-Agenten und die Firewall. Privates Netzwerk nachträglich in eine laufende Agentenumgebung einzubauen, ist viel schwieriger, als damit zu starten.
Tipp aus der Praxis
Starten Sie mit Microsofts Referenzimplementierung für den Foundry Agent Service, die in der Baseline-Architektur verlinkt ist. Sie legt Netzwerk, Private Endpoints und Firewall per Infrastructure as Code an und spart Tage an DNS-Fehlersuche.
4. Modell wählen und bereitstellen: Standard, Batch, Priority oder Provisioned
Wählen Sie das Modell nach der Aufgabe, nicht nach der Schlagzeile: ein kleines, schnelles Modell für Routing und Extraktion, ein stärkeres für Antworten mit viel Denkarbeit und ein Embedding-Modell für die Suche. Dann der Deployment-Typ. Microsoft vergleicht vier: Standard-Deployments teilen sich Rechenkapazität mit anderen Kunden, der Durchsatz kann also schwanken; Batch passt für grosse Offline-Jobs; Priority Processing kauft niedrigere Latenz; und Provisioned Throughput hält eine feste Kapazität exklusiv für Ihr Deployment bereit, ob Anfragen kommen oder nicht.
Dieser letzte Satz ist Kostenfalle und Vorteil zugleich. Provisioned Throughput bringt planbare Latenz für einen stark und gleichmässig ausgelasteten Workload, aber Sie zahlen auch um drei Uhr nachts. Starten Sie mit einem Standard-Deployment, messen Sie einige Wochen lang Tokens pro Minute und Latenz, und entscheiden Sie erst dann, ob die gleichmässige Grundlast Provisioned-Kapazität rechtfertigt.
Prüfen Sie vor dem Deployment, welche Modellversionen und SKUs Ihre Region wirklich anbietet. Der Quickstart zeigt dafür einen Befehl, und ein Deployment scheitert mit DeploymentModelNotSupported, wenn die Kombination in Ihrer Region nicht existiert.
# Which versions and SKUs of a model exist in your region?
az cognitiveservices model list \
--location eastus \
--query "[?model.name=='gpt-5-mini'].{version:model.version,skus:join(',',model.skus[].name)}" \
--output table
# Standard (shared capacity) deployment to start with
az cognitiveservices account deployment create \
--name my-foundry-resource \
--resource-group my-foundry-rg \
--deployment-name gpt-5-mini \
--model-name gpt-5-mini \
--model-version "2025-08-07" \
--model-format OpenAI \
--sku-capacity 10 \
--sku-name GlobalStandard5. Den Agenten bauen: Prompt Agent, Hosted Agent und eine kuratierte Toolbox
Der Foundry Agent Service holt Sie irgendwo zwischen deklarativ und vollem Code ab. Ein Prompt Agent wird durch Anweisungen, ein Modell und Tools definiert, und Foundry führt ihn aus. Ein Hosted Agent verpackt Ihren eigenen Code, etwa ein Framework, das Sie schon nutzen, und Foundry hostet und skaliert ihn. Oder Sie rufen die Responses API aus einem Agenten auf, der woanders läuft. Die Agent Runtime verwaltet Konversationen, Tool-Aufrufe und den Lebenszyklus des Agenten.
Tools machen Agenten nützlich und zugleich riskant. Mit den Toolboxes in Foundry kuratieren Sie einmal eine Auswahl an Tools, etwa Websuche, Dateisuche, Code Interpreter, MCP-Server und eigene Funktionen, und teilen sie über Agenten hinweg. Behandeln Sie eine Toolbox wie eine veröffentlichte API: Jedes Tool hat einen Owner, eine klare Beschreibung, Least-Privilege-Zugriff und einen Test. Für Antworten auf Basis eigener Dokumente verbindet die Baseline-Architektur den Agenten über einen Private Endpoint mit Azure AI Search, die Suche bleibt also in Ihrem Netzwerk.
Starten Sie mit einem Prompt Agent und zwei oder drei Tools. Der meiste Nutzen eines ersten Releases kommt aus guten Anweisungen und verlässlicher Suche, nicht aus einer langen Tool-Liste. Fügen Sie Tools erst hinzu, wenn eine Evaluation zeigt, dass der Agent sie braucht.
6. Guardrails auf jedem Schritt, nicht nur im Chatfenster
Klassische Inhaltsfilter schauen auf zwei Stellen: was der Nutzer tippt und was das Modell antwortet. Agenten haben zwei weitere. Guardrails in Microsoft Foundry sind benannte Sammlungen von Controls, und jedes Control definiert ein Risiko, die zu prüfenden Eingriffspunkte und die Aktion. Unterstützt werden vier Eingriffspunkte: Nutzereingabe, Tool-Aufruf, Tool-Antwort und Ausgabe. Tool-Aufruf und Tool-Antwort gibt es nur für Agenten und in der Preview, wie Agenten-Guardrails insgesamt.
Die Tool-Antwort vergessen die meisten Teams. Indirekte Prompt Injection kommt über Inhalte, die der Agent liest, etwa eine Webseite oder ein Dokument, nicht über den Nutzer. Wer Tool-Antworten prüft, erwischt versteckte Anweisungen in diesen Inhalten, bevor das Modell danach handelt. Zur Control-Liste gehören auch geschütztes Material, personenbezogene Daten und Task Adherence in der Preview, sodass ein Agent markiert werden kann, der von seiner Aufgabe abweicht.
Ein Datum zum Merken: Microsoft kündigt an, dass die Groundedness Detection (Preview) in Azure OpenAI am 30. April 2027 eingestellt wird. Wer darauf baut, plant den Ersatz jetzt und prüft Groundedness zusätzlich mit Evaluationen.
Tipp aus der Praxis
Führen Sie eine kleine Datei mit Angriffs-Prompts für Ihr Fachgebiet, inklusive Anweisungen, die in einem vom Agenten gelesenen Dokument versteckt sind, und lassen Sie sie bei jeder Guardrail-Änderung laufen. Ein ungetesteter Guardrail ist eine Vermutung.
7. Vor jedem Release evaluieren: Qualität, Sicherheit und Agentenverhalten
Ein Agent ändert sein Verhalten bei jeder angepassten Anweisung, jeder neuen Modellversion und jedem zusätzlichen Tool. Ohne Evaluationen erfahren Sie es von Kunden. Die Evaluatoren in Foundry decken allgemeine Qualität ab, suchspezifische Metriken wie Groundedness und Relevance, Safety und Security sowie agentenspezifische Metriken. Die Agenten-Evaluatoren sind die spannenden: Task Adherence prüft, ob die Aktionen des Agenten seinen Regeln und Policy-Vorgaben folgen, Intent Resolution, ob er verstanden hat, was der Nutzer wollte, und Tool Call Accuracy, ob er die richtigen Tools mit den richtigen Parametern aufgerufen hat.
Bauen Sie ein Testset aus 50 bis 200 echten Fragen mit erwarteten Ergebnissen, inklusive der unbequemen aus Support-Tickets. Lassen Sie es in Ihrer Pipeline bei jeder Änderung an Anweisungen, Tools oder Modellversion laufen und blockieren Sie das Release, wenn ein Wert unter den letzten akzeptierten Lauf fällt. Eigene Evaluatoren für Fachregeln sind möglich, etwa dass eine Antwort zu einem Vertrag immer die Klausel nennt.
Microsoft beschreibt zudem einen Agent Optimizer (Preview), der das Agentenverhalten bewertet und bessere Anweisungen, Tool-Beschreibungen und Modelle vorschlägt. Nutzen Sie solche Vorschläge wie einen Pull Request, der Ihre Evaluation trotzdem bestehen muss, nie als automatische Änderung in Produktion.
8. In Produktion beobachten und Kosten steuern, dann die Clouds vergleichen
Das Tracing in Foundry basiert auf OpenTelemetry und ist in Azure Monitor Application Insights integriert. Ein Trace zeigt den Ablauf einer Anfrage: Modellaufrufe, Tool-Aufrufe und Entscheidungen des Agenten, genau das, was Sie brauchen, wenn ein Agent am Dienstag eine seltsame Antwort gab. Darüber beschreibt Microsoft Produktions-Dashboards für Token-Verbrauch, Latenz, Fehlerraten und Qualitätswerte, mit Alerts, wenn Ausgaben Qualitätsschwellen verfehlen oder schädliche Inhalte erzeugen.
Kostenkontrolle ist vor allem Disziplin: ein Budget mit Prognose-Alerts auf der Subscription, Token-Verbrauch pro Agent und Projekt in den Dashboards, für jeden Schritt das kleinste Modell, das Ihre Evaluation besteht, und ein regelmässiger Blick darauf, ob eine gleichmässige Last gross genug für Provisioned Throughput geworden ist. Gehen Sie die Azure-Well-Architected-Empfehlungen für KI-Workloads einmal vor dem Go-live und dann jedes Quartal durch.
Die häufigsten Fehler, die ich sehe: Keys in App-Settings, öffentlicher Netzwerkzugriff nach dem Piloten nicht abgeschaltet, keine Egress-Kontrolle für Agenten mit Tools, Evaluationen einmal von Hand statt in der Pipeline, und eine stillschweigend aktualisierte Modellversion. Wie dasselbe Setup auf AWS aussieht, steht in /blog/aws-bedrock, auf Google Cloud in /blog/google-vertex-ai. Die Bausteine sind ähnlich; Namen, Netzwerkmodell und Governance-Werkzeuge unterscheiden sich.
Tipp aus der Praxis
Fixieren Sie Modellversionen in Produktion und aktualisieren Sie sie wie jede andere Abhängigkeit: zuerst in Nicht-Produktion, durch das Evaluations-Gate, mit Rückfallplan.
Fazit
Auf Azure ist ein produktiver Agent vor allem die Plattform, die Sie schon betreiben: Entra ID, Private Endpoints, eine Firewall und Application Insights, mit den Guardrails und Evaluationen von Foundry als Tore, durch die jede Änderung muss.
Echte Projekte dazu
Selbst ausprobieren
Quellen und offizielle Leitfäden
- Microsoft Learn: What is Microsoft Foundry?
- Microsoft Learn: What is Microsoft Foundry Agent Service?
- Azure Architecture Center: Baseline Microsoft Foundry chat reference architecture
- Microsoft Learn: Set up private networking for Foundry Agent Service
- Microsoft Learn: Configure network isolation for Microsoft Foundry
- Microsoft Learn: Quickstart, set up Microsoft Foundry resources
- Microsoft Learn: Provisioned throughput for Foundry Models
- Microsoft Learn: Guardrails and controls overview in Microsoft Foundry
- Microsoft Learn: Agent evaluators for generative AI
- Microsoft Learn: Observability in generative AI
- Azure Well-Architected Framework: AI workloads
Weitere Artikel
- 3'025 Pull Requests in zehn Monaten: ein KI-gestützter Delivery-Prozess von innen
- Der EU AI Act für den Mittelstand: was für Sie gilt, und ab wann
- FinOps für KI-Kosten: Tokens, Caching, Routing und Budgets, die halten
- Ein Restaurant-Netzwerk in KI-Antworten sichtbar machen: ein GEO-Projekt Schritt für Schritt
- Wie diese Website gebaut ist: statisch, wo es geht, streamend, wo es muss
- Kubernetes-Kosten auf EKS und GKE: dasselbe Playbook, andere Hebel
- Eine Landing Zone für den Mittelstand, in Terraform oder Bicep: die Teile, die zählen
- Das Playbook für Legacy-Migrationen: Wellen, Parallelbetrieb und identische Zeilenzahlen und Prüfsummen
- MCP-Sicherheit im Detail: KI-Assistenten ins Produkt lassen, ohne die Türen zu öffnen
- Monitoring auf Geschäftsergebnisse: grüne Dashboards, leere Kasse
- KI-Agenten am Telefon: die Architektur, und die Stolperfallen, die keine Demo zeigt
- Restore-Tests: Ein Backup, das nie wiederhergestellt wurde, ist nur eine Hoffnung
- KI-Antworten auf Azure Static Web Apps streamen: der eine Header, der alles zurückhielt
- Einen KI-Assistenten für WhatsApp bauen, von Anfang bis Ende: was es über die Demo hinaus braucht
- Air-gapped-Systeme: kritische Software ganz ohne Internet betreiben
- Produktive KI auf AWS: Amazon Bedrock und AgentCore in einem privaten Setup
- /goal, /loop oder Routines: Hören Sie auf, Ihren Coding-Agenten zu babysitten
- Claudes neue Pläne: Max, Ultra und was sie für Teams bedeuten
- OpenAI Codex Ende 2026: Goal Mode, Dots und wie man es absichert
- GitHub Copilot, Claude Code oder Codex? So würde ich für ein Unternehmen entscheiden
- GEO-Grundlagen: So erscheinen Sie in KI-Antworten
- Produktive KI auf Google Cloud: von Vertex AI zur Gemini Enterprise Agent Platform
- Lokale LLMs im Air-Gap-Netz: KI für Ihre sensibelsten Daten
- Ich will ein lokales LLM betreiben: Welchen Server soll ich kaufen?
- MiniMax M3: ein offenes Spitzenmodell zum Selbstbetreiben?
- Prompt-Research im grossen Stil mit einem offenen Modell
- SEO und GEO zusammen: ein praktisches Audit in 6 Schritten
- Kubernetes richtig dimensionieren: das Playbook, mit dem ein Cluster von 7 auf 4 Nodes kam
- Private KI für sensible Daten: ein lokales LLM-Setup, das durch die Sicherheitsprüfung kommt
- Vom KI-Prototyp zur Produktion: die acht Schichten, die ich ergänze, in dieser Reihenfolge
