Azure AI Foundry gegen den selbst zusammengesetzten Stack

TL;DR

Foundry nimmt Ihnen die Integrationsarbeit ab und legt Sie dafür auf eine Plattform fest. Für Häuser, die ohnehin vollständig in Azure arbeiten und keine Plattform-Kompetenz aufbauen wollen, ist das eine gute Entscheidung. Für alle, die lokale Modelle brauchen oder brauchen werden, ist es der falsche Ausgangspunkt.

Was verglichen wird

Azure AI Foundry ist Microsofts Baukasten für KI-Anwendungen: Modellkatalog, Bereitstellung, Agentendienst, Bewertungswerkzeuge, Inhaltsfilter, Nachverfolgung — alles im selben Portal, alles mit Entra ID und Azure-Governance verbunden.

Der eigene Stack besteht aus Komponenten, die Sie auswählen und verbinden: ein Gateway, ein Vektorspeicher, eine Chat-Oberfläche, ein Inferenzserver oder Cloud-Modelle, Guardrails, eine Ingestion-Pipeline.

Der Vergleich ist keiner zwischen fertig und selbstgebaut. Er ist einer zwischen zwei Arten von Arbeit: Integration selbst leisten oder Plattformbindung akzeptieren.

Was Foundry tatsächlich abnimmt

Nicht zu unterschätzen, und Techniker unterschätzen es regelmäßig:

Governance ohne Zusatzaufwand. Berechtigungen über Entra ID, Netzwerkabschottung über Private Endpoints, Protokollierung im vorhandenen Log-Speicher, Kostenzuordnung über Azure-Tags. In einem eigenen Stack bauen Sie das je Komponente einzeln.

Inhaltsfilter ab Werk. Ein Filter, der Ein- und Ausgaben prüft, ohne dass Sie ein Guardrail-Werkzeug installieren und pflegen. Was das im Eigenbau bedeutet, zeigt der Vergleich der Guardrail-Werkzeuge.

Ein Ansprechpartner. Wenn etwas nicht funktioniert, gibt es einen Vertrag und einen Support. Bei einem Stack aus fünf offenen Projekten gibt es fünf Fehlerdatenbanken.

Nachvollziehbarkeit und Bewertung. Aufrufverfolgung und Bewertungsläufe sind eingebaut. Im Eigenbau ist das zusätzliche Arbeit — machbar, aber Arbeit.

Was Foundry festlegt

Die Modelle. Der Katalog ist breit und er ist ein Katalog. Ein Modell, das nicht darin steht, betreiben Sie nicht darin. Wenn Sie ein offenes Modell auf eigener Hardware fahren wollen, ist das ein Bruch im Aufbau.

Den Verarbeitungsort. In einer Azure-Region Ihrer Wahl, aber in Azure. Für Häuser, deren Daten die eigene Infrastruktur nicht verlassen dürfen, ist die Frage damit beantwortet. Die Argumentationslinien stehen in der Einordnung souveräner KI.

Die Kostenstruktur. Verbrauchsabhängig, mit den Preisen des Anbieters. Bei hoher Dauerlast ist ein eigener GPU-Betrieb günstiger — ab wann, steht im Beitrag zu den Kosten je Million Token.

Die Ausstiegskosten. Das ist der Punkt, der am spätesten weh tut. Agenten, Bewertungsläufe und Konfigurationen sind plattformspezifisch. Ein Wechsel ist kein Export, sondern ein Neubau.

Die Entscheidung in drei Fragen

Frage 1: Dürfen Ihre Daten in Azure verarbeitet werden? Nein → eigener Stack. Die Frage ist damit beantwortet.

Frage 2: Haben Sie jemanden, der eine Plattform betreibt — oder wollen Sie das aufbauen? Nein und nein → Foundry. Ein eigener Stack ohne benannte Betriebsrolle verwahrlost innerhalb eines Jahres. Was dazugehört, steht im Beitrag zum Leistungsumfang eines Betriebsvertrags.

Frage 3: Werden Sie in absehbarer Zeit lokale Modelle brauchen? Ja → eigener Stack, oder zumindest ein Gateway als Zwischenschicht.

Der häufigste Fall im deutschen Mittelstand ist: Frage 1 mit "teilweise" beantwortet — die meisten Daten dürfen in die Cloud, einige nicht. Genau dafür gibt es einen Mittelweg.

Der Mittelweg, den wir meistens empfehlen

Nicht entweder-oder, sondern ein Gateway als Zwischenschicht.

model_list:
  # Standard: Cloud-Modell in einer Azure-Region
  - model_name: standard
    litellm_params:
      model: azure/<ihr-deployment>
      api_base: https://ihre-instanz.openai.azure.com

  # Vertrauliches: lokal, ohne Ausweichroute nach außen
  - model_name: vertraulich
    litellm_params:
      model: openai/qwen3-30b-a3b
      api_base: http://vllm.intern:8000/v1

Damit nutzen Sie die Azure-Modelle für den Alltag und behalten die Freiheit, einzelne Anwendungsfälle lokal zu fahren. Die Anwendungen sprechen logische Namen und merken den Unterschied nicht.

Was Sie dabei aufgeben: die Bequemlichkeit des vollständigen Foundry-Baukastens. Agenten und Bewertung bauen Sie dann außerhalb. Was Sie gewinnen: eine Architektur, die eine Verschiebung der Anforderungen übersteht — und die ist im Mittelstand die Regel, nicht die Ausnahme.

Häufig gestellte Fragen

Für wen eignet sich Azure AI Foundry?

Für Unternehmen, die bereits vollständig in Azure arbeiten, keine Anforderung an lokale Verarbeitung haben und keine eigene Plattform-Kompetenz aufbauen wollen. Der Baukasten nimmt Integration, Governance und Betrieb weitgehend ab — und legt Sie dafür auf Modellkatalog, Verarbeitungsort und Kostenstruktur des Anbieters fest.

Kann ich in Foundry eigene Modelle betreiben?

Modelle aus dem Katalog lassen sich bereitstellen, ein Modell auf eigener Hardware im Rechenzentrum ist damit nicht gemeint. Wenn Sie offene Modelle selbst betreiben wollen oder müssen, brauchen Sie dafür einen eigenen Inferenzserver und sinnvollerweise ein Gateway, das beide Wege zusammenführt.

Wie hoch sind die Ausstiegskosten bei Foundry?

Höher als bei einzelnen Cloud-Diensten, weil Agenten, Bewertungsläufe und Konfigurationen plattformspezifisch sind. Ein Wechsel ist deshalb kein Export, sondern ein Neubau der Anwendungsschicht. Reduzieren lässt sich das, indem Sie zumindest die Modellzugriffe über ein eigenes Gateway führen statt direkt.

Lohnt sich ein eigener Stack für ein Unternehmen mit 300 Mitarbeitern?

Nur mit einer benannten Betriebsrolle. Die Komponenten selbst sind quelloffen und kostenfrei, der Aufwand liegt in Integration und laufender Pflege — bei mehreren Anwendungsfällen 0,5 bis 0,8 Vollzeitäquivalente. Ohne diese Stelle veraltet ein eigener Stack innerhalb eines Jahres, und dann ist der verwaltete Dienst die bessere Wahl gewesen.

Was ist die pragmatischste Architektur für gemischte Anforderungen?

Ein Gateway vor beidem: Cloud-Modelle für den Alltag, ein lokal betriebenes Modell für die Anwendungsfälle mit strengeren Anforderungen. Die Anwendungen sprechen logische Modellnamen und merken den Unterschied nicht. Diese Architektur kostet wenig zusätzlichen Aufwand und übersteht eine Verschiebung der Anforderungen.

Der nächste Schritt

Beantworten Sie Frage 1 sauber: Gibt es Daten, die Azure nicht verarbeiten darf? Wenn ja, welche und wie viel Prozent Ihrer Anwendungsfälle betrifft das? Aus dieser einen Antwort folgt die Architektur — nicht aus einem Funktionsvergleich. Bei der Klärung schauen wir gern mit.