Zum Inhalt springen
Alle Artikel

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.

bash
# 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 eastus

Tipp 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.

Referenz-Setup auf Microsoft Foundry, angelehnt an die Baseline-Foundry-Chat-Architektur im Azure Architecture Center: alles privat, ausgehender Verkehr über die Firewall, Observability in Application Insights.
Azure-Architektur: Nutzer erreichen die Chat-App über Application Gateway mit WAF; App Service ruft den Foundry Agent Service über einen Private Endpoint mit Managed Identity auf; der Agent nutzt Modelle, Azure AI Search, Cosmos DB und Storage über Private Endpoints; Guardrails prüfen Eingabe, Tool-Aufrufe, Tool-Antworten und Ausgabe; ausgehender Verkehr läuft über Azure Firewall; Traces und Evaluationen landen in Application Insights.

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.

bash
# 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 GlobalStandard

5. 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.

Foundry Agent Service + Microsoft Agent Framework Explained, Microsoft Mechanics (YouTube). Wird erst nach Ihrem Klick von YouTube geladen.

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.

Weitere Artikel

    Kontakt aufnehmen

    Erzählen Sie mir von Ihrem Projekt, ich antworte innerhalb von 1–2 Werktagen.

    Dominik Heinrich
    Unternehmen
    MADO Consulting

    Weltweit verfügbar, remote. Vor Ort auf Anfrage, je nach Land.

    Ich antworte innerhalb von 1–2 Werktagen. Freie Termine: siehe Kalender

    Öffnet hier den Buchungskalender von Calendly. Beim Laden werden Daten an Calendly übertragen (siehe Impressum).