LLM-Integration mit Microsoft Foundry in .NET

Die LLM-Integration in eine bestehende .NET-Anwendung scheitert selten am Modellaufruf. Der ist in zwanzig Zeilen erledigt. Sie scheitert an vier Entscheidungen, die davor liegen — und die man später nicht mehr billig zurücknimmt: Wo werden die Daten verarbeitet? Über welchen Endpoint sprechen wir mit dem Modell? Wie authentifiziert sich der Dienst? Und was passiert, wenn das Kontingent aufgebraucht ist?

Dieser Artikel geht diese vier Entscheidungen der Reihe nach durch, am Beispiel von Microsoft Foundry und einem .NET-Backend. Kein Portal-Klickpfad, keine Screenshot-Tour — die altern schneller, als ein Artikel gepflegt werden kann. Stattdessen die Struktur darunter, die stabil bleibt.

Vorab: Der Dienst heißt inzwischen anders

Wer nach „Azure AI Foundry” sucht, sucht nach dem richtigen Produkt unter einem Namen, den es offiziell nicht mehr gibt. Die Kette ist inzwischen drei Stationen lang: Azure AI Studio → Azure AI Foundry → Microsoft Foundry, letzteres seit Januar 2026. Mit umbenannt wurden die RBAC-Rollen: aus Azure AI User wurde Foundry User, aus Azure AI Project Manager wurde Foundry Project Manager. Die Role-IDs und die dahinterliegenden Berechtigungen sind unverändert geblieben — wer Rollen über Bicep oder Terraform per ID zuweist, hat von der Umbenennung nichts gemerkt. Wer sie per Anzeigename zugewiesen hat, schon.

Das ist mehr als eine Fußnote, es ist die erste Designregel für dieses Thema: Bauen Sie gegen das, was stabil ist. Ressourcen-IDs, SKU-Codes und Endpoint-Formate haben die letzten beiden Umbenennungen überlebt. Anzeigenamen, Portal-Navigation und Marketingbegriffe nicht. Das gilt für Ihren Infrastruktur-Code genauso wie für die interne Dokumentation, die ein Jahr später noch stimmen soll.

Ein zweiter Punkt, der Verwirrung stiftet: Azure OpenAI Service wurde nicht abgeschafft. Es gibt weiterhin zwei unterschiedliche Ressourcentypen. Eine Foundry-Ressource stellt alle Endpoints bereit; eine reine Azure-OpenAI-Ressource stellt nur den /openai/v1-Endpoint bereit. Welchen Sie brauchen, ergibt sich aus der nächsten Entscheidung.

Entscheidung 1: Welcher Endpoint, welches SDK

Foundry bietet mehrere Zugangswege zum selben Modell. Das ist kein Versehen, sondern Absicht — sie unterscheiden sich in Funktionsumfang und Latenz.

Zugang	Wofür	Endpoint-Form
Foundry SDK	Agents, Evaluations, Foundry-eigene Tools	https://<resource>.services.ai.azure.com/api/projects/<project>
OpenAI SDK	Maximale OpenAI-Kompatibilität, niedrigste Latenz, Embeddings	https://<resource>.openai.azure.com/openai/v1
Anthropic SDK	Claude-Modelle, die in Foundry deployt sind	https://<resource>.services.ai.azure.com/anthropic
Agent Framework	Orchestrierung mehrerer Agenten in C#/.NET	Responses API über den Projekt-Endpoint

Für ein typisches Produkt-Feature — Zusammenfassung, Klassifikation, Extraktion — ist der Projekt-Endpoint über das Foundry SDK der pragmatische Startpunkt: eine Konfigurationsgröße statt drei, und der Weg zu Agents und Evaluations steht offen, ohne die Anbindung neu zu bauen.

In .NET sieht das so aus:

using Azure.AI.Projects;
using Azure.AI.Extensions.OpenAI;
using Azure.Identity;

string endpoint = "https://<resource>.services.ai.azure.com/api/projects/<project>";

AIProjectClient projectClient = new(
    endpoint: new Uri(endpoint),
    tokenProvider: new DefaultAzureCredential());

var responseClient = projectClient.ProjectOpenAIClient
    .GetProjectResponsesClientForModel("<deployment-name>");

Die Pakete dazu:

dotnet add package Azure.AI.Projects
dotnet add package Azure.AI.Extensions.OpenAI
dotnet add package Azure.Identity

Zwei Fallstricke, die Zeit kosten:

Erstens die Paketwahl. Azure.AI.Projects.OpenAI (Preview) und Azure.AI.Extensions.OpenAI (GA) definieren dieselben Typen in unterschiedlichen Namespaces. Beide zusammen installiert, bekommen Sie mehrdeutige Referenzen und einen Compiler-Fehler, dessen Ursache man nicht sofort sieht. Nehmen Sie das GA-Paket. Achten Sie außerdem auf die Version: 2.0.0 adressiert das neue Foundry, 1.1.0 das inzwischen als classic geführte.

Zweitens — und das trifft jeden, der Richtung RAG baut: Der Projekt-Endpoint routet derzeit keine Embedding-Anfragen. Embeddings laufen über den /openai/v1-Endpoint. Wer eine semantische Suche baut, hat also zwei Clients im Prozess, nicht einen. Das ist keine große Sache, wenn man es zu Beginn weiß, und ärgerlich, wenn man es beim Verdrahten der Indexierungs-Pipeline entdeckt.

Wie so eine Pipeline in einem ausgelieferten Produkt aussieht — automatisierte Erfassung, semantische Klassifikation, Matching und generierte Texte über einen durchgehenden Prozess —, haben wir in der KI-Ausschreibungsplattform beschrieben.

Entscheidung 2: Der Deployment-Typ ist die Compliance-Entscheidung

Das ist der Teil, den technische Tutorials überspringen und der in der Praxis über das halbe Projekt entscheidet. Beim Deployment eines Modells wählen Sie einen Typ, und dieser Typ legt drei Dinge gleichzeitig fest: wo Ihre Daten verarbeitet werden, wie Sie zahlen, und wie stabil die Latenz ist.

Deployment-Typ	SKU-Code	Verarbeitung	Abrechnung
Global Standard	GlobalStandard	beliebige Azure-Region	pro Token
Data Zone Standard	DataZoneStandard	innerhalb der Datenzone	pro Token
Standard	Standard	Deployment-Region	pro Token
Global Provisioned	GlobalProvisionedManaged	beliebige Azure-Region	reservierte PTU
Data Zone Provisioned	DataZoneProvisionedManaged	innerhalb der Datenzone	reservierte PTU
Regional Provisioned	ProvisionedManaged	Deployment-Region	reservierte PTU
Global Batch	GlobalBatch	beliebige Azure-Region	~50 % günstiger, 24 h
Data Zone Batch	DataZoneBatch	innerhalb der Datenzone	~50 % günstiger, 24 h

Wichtig ist die Unterscheidung, die Microsoft hier trifft: Ruhende Daten bleiben in der zugewiesenen Azure-Geografie — bei allen Typen. Was sich unterscheidet, ist die Verarbeitung der Inferenz-Anfragen. Bei Global-Typen kann ein Prompt in jeder Region verarbeitet werden, in der das Modell deployt ist. Bei DataZone-Typen bleibt er innerhalb der angegebenen Zone.

Für die EU-Zone heißt das konkret: Verarbeitung innerhalb der EU Data Boundary. Stand Mai 2026 umfasst das Regionen in Frankreich, Deutschland, Italien, den Niederlanden, Norwegen, Polen, Spanien, Schweden und der Schweiz. Microsoft behält sich vor, weitere Regionen innerhalb der Boundary ohne Vorankündigung aufzunehmen — planen Sie also auf die Boundary, nicht auf eine Länderliste.

Damit ist die Entscheidungsregel unspektakulär, aber belastbar:

• Keine Auflagen: Global Standard. Höchstes Standardkontingent, breiteste Modellverfügbarkeit, neue Modelle zuerst.
• Verarbeitung muss in der EU bleiben: Data Zone Standard in einer EU-Region.
• Genau eine Region, vertraglich zugesagt: Standard.
• Gleichbleibend hohes Volumen, enge Latenzzusagen: die Provisioned-Varianten.
• Große asynchrone Jobs: Batch, zum halben Preis bei 24-Stunden-Ziel.

Die Kosten dieser Entscheidung sind asymmetrisch. Von Global Standard auf Data Zone Standard zu wechseln, ist ein neues Deployment und eine geänderte Konfiguration — überschaubar. Einem Kunden nach dem Audit zu erklären, warum seine Vertragsdokumente ein Jahr lang in beliebigen Azure-Regionen verarbeitet wurden, ist es nicht. Wer für ein Unternehmen baut, das unter NIS-2-Anforderungen an seine Software-Lieferanten fällt, trifft diese Wahl am Anfang bewusst und dokumentiert sie.

Welcher Deployment-Typ zu Ihren vertraglichen Zusagen passt, ist eine Frage, die man einmal sauber beantwortet und danach dokumentiert hat — nicht eine, die man nach dem ersten Audit neu stellt. Genau dafür ist eine kompakte Discovery-Phase da: bevor das erste Deployment steht.

Die Entscheidung technisch absichern

Eine Regel, die nur in einem Architekturdokument steht, ist keine Regel — sie ist eine Bitte. Deployment-Typen lassen sich per Azure Policy erzwingen, indem Sie den SKU-Namen auf Ressourcenebene sperren:

{
  "mode": "All",
  "policyRule": {
    "if": {
      "allOf": [
        {
          "field": "type",
          "equals": "Microsoft.CognitiveServices/accounts/deployments"
        },
        {
          "field": "Microsoft.CognitiveServices/accounts/deployments/sku.name",
          "equals": "GlobalStandard"
        }
      ]
    }
  }
}

Das ist derselbe Gedanke, den wir bei Hooks als Quality Gates beschrieben haben: Ein hartes Gate ist etwas anderes als ein weicher Vorschlag. Wenn die Datenresidenz eine Zusage an den Kunden ist, gehört sie in die Policy und nicht in eine Wiki-Seite, an die sich in acht Monaten niemand erinnert.

Entscheidung 3: Entra ID statt API-Schlüssel

Die Beispiele in der offiziellen Dokumentation authentifizieren über Microsoft Entra ID mit DefaultAzureCredential. Das ist keine Stilfrage. API-Schlüssel funktionieren nur auf dem /openai/v1-Endpoint — wer über den Projekt-Endpoint arbeitet, authentifiziert ohnehin über Entra ID.

Der praktische Gewinn ist derselbe wie überall in Azure: In der Entwicklung greift DefaultAzureCredential auf die angemeldete Entwickleridentität zu, im Betrieb auf die Managed Identity des Dienstes. In beiden Fällen liegt kein Geheimnis in der Konfiguration, das rotiert, geleakt oder in ein Repository committet werden könnte. Wie wir mit den Geheimnissen umgehen, die sich nicht vermeiden lassen, steht in Secrets sicher ablegen mit Azure Key Vault.

Was dabei regelmäßig übersehen wird: Die Identität braucht eine Rollenzuweisung. Ohne mindestens Foundry User auf dem Projekt scheitert der Aufruf mit DefaultAzureCredential failed to retrieve a token — eine Meldung, die nach einem Netzwerkproblem klingt und keines ist. Beim Deployment in eine neue Umgebung ist das der häufigste erste Fehler, und er kostet zuverlässig eine halbe Stunde, wenn man ihn nicht kennt.

Entscheidung 4: Was im Betrieb tatsächlich passiert

Ein Modellaufruf im Happy Path ist unspektakulär. Interessant wird es an den Rändern.

Kontingente. Der Durchsatz ist in Tokens pro Minute gedeckelt. Wird das Kontingent überschritten, antwortet der Dienst mit HTTP 429. Das ist kein Ausnahmefall, den man wegloggt, sondern ein normaler Betriebszustand unter Last — und er gehört von Anfang an behandelt: Retry mit exponentiellem Backoff, Warteschlange für alles, was nicht synchron sein muss, und eine bewusste Entscheidung darüber, was passiert, wenn ein Nutzer gerade wartet. Ein Zusammenfassungs-Feature darf in die Warteschlange. Ein Chat-Fenster nicht.

Latenzstreuung. Global Standard verteilt Anfragen dynamisch über verfügbare Rechenzentren. Das liefert das höchste Kontingent, und bei gleichbleibend hohem Volumen eine spürbar schwankende Antwortzeit. Microsoft nennt hier ausdrücklich die Provisioned-Typen als Antwort, wenn geringe Latenzstreuung gefordert ist. Für ein interaktives Feature ist der p95 die relevante Zahl, nicht der Mittelwert — und der p95 ist genau das, was bei Standard-Deployments unter Last wandert.

Verfügbarkeit. Bei Global Standard und Data Zone Standard gilt: Fällt die primäre Region aus, ist der gesamte zunächst dorthin geroutete Verkehr betroffen. Dynamisches Routing ist kein Ersatz für ein Ausfallkonzept.

Kosten. Die Abrechnung erfolgt pro Token, und die Rechnung wächst mit der Kontextgröße — nicht mit der Anzahl der Aufrufe. Wer einem Modell bei jeder Anfrage vorsichtshalber das komplette Dokument mitgibt, zahlt für Kontext, den das Modell nicht braucht. Dieselbe Mechanik, dieselbe Disziplin, die wir in Token-Kosten und Modell-Routing für den Entwicklungs-Workflow beschrieben haben, gilt im Produktivbetrieb genauso: das kleinste Modell, das die Aufgabe zuverlässig löst, und nur der Kontext, der gebraucht wird.

Was davon bleibt

Der Modellaufruf ist der einfachste Teil dieser Aufgabe, und er wird jedes Jahr einfacher. Die vier Entscheidungen davor sind der eigentliche Inhalt:

1. Ressourcentyp und Endpoint — Foundry-Ressource für den vollen Funktionsumfang, Azure-OpenAI-Ressource, wenn nur /openai/v1 gebraucht wird. Embeddings laufen über /openai/v1.
2. Deployment-Typ — die Datenresidenz-Entscheidung, in einem SKU-Code verdichtet, per Azure Policy erzwingbar.
3. Authentifizierung — Entra ID mit Managed Identity, kein Schlüssel in der Konfiguration, und die Rollenzuweisung nicht vergessen.
4. Betriebsverhalten — 429 als Normalzustand, Latenzstreuung als bewusste Abwägung, Kontextgröße als Kostentreiber.

Keine dieser Entscheidungen setzt voraus, dass man Modelle trainiert oder versteht, wie ein Transformer intern arbeitet. Wen das dennoch interessiert: Die Ebene darunter haben wir in Datenebene und Modellarchitektur aufgeschrieben. Für die Integration selbst zählt etwas anderes — die gleiche Sorgfalt, die man jeder anderen externen Abhängigkeit im System entgegenbringt.

Genau das ist unsere Arbeit bei der KI-Integration: keine eigenen Modelle, sondern bestehende Dienste sauber, nachvollziehbar und auditfest in Software einbauen — auf einem Cloud-Fundament, das die Entscheidungen von oben trägt.

---

Sie stehen vor genau diesen Entscheidungen — oder haben einen Prototypen, der unter Last, Budget und Audit noch nicht bestanden hat? Wir ordnen Endpoint, Deployment-Typ, Authentifizierung und Betriebsverhalten für Ihren konkreten Fall ein, im kostenlosen Erstgespräch und bevor Sie sich festlegen. Wenn Sie dafür nur einen zweiten Blick von außen brauchen, geht das auch über Teamverstärkung.

Alle technischen Angaben in diesem Artikel beziehen sich auf den Stand der Microsoft-Foundry-Dokumentation im Juli 2026. Deployment-Typen, SDK-Pakete und Regionslisten ändern sich; die SKU-Codes und Endpoint-Formate haben sich als deutlich stabiler erwiesen als die Produktnamen.