Feldnotiz · Veröffentlicht 17. Juli 2026 · Aktualisiert 26. Juli 2026 · 7 Min. Lesezeit

Microsoft Foundry ist eine Plattformentscheidung, keine KI-Strategie

Ein praxisnaher Leitfaden für Führungskräfte: Wo Microsoft Foundry in eine Enterprise-KI-Architektur gehört – und welche Entscheidungen die Plattform nicht übernehmen kann.

In einem Absatz

Microsoft Foundry kann Modelle, Agenten, Werkzeuge, Evaluationen, Beobachtbarkeit, Identität, Netzwerk und Richtlinien unter einer Managementebene vereinen. Die Plattform wählt jedoch nicht die richtige Geschäftsmission, definiert kein akzeptables Scheitern, schafft keine repräsentative Evidenz und weist keine Betriebsverantwortung zu. Beginnen Sie mit einem klar begrenzten Ergebnis und nutzen Sie Foundry dort, wo die Plattformkontrollen Delivery und Betrieb vereinfachen.

Der Name änderte sich; die operative Frage blieb

Microsoft nennt die Plattform heute Microsoft Foundry. Frühere Namen – darunter Azure AI Studio und Azure AI Foundry – finden sich weiterhin in Architekturdokumenten, Code, Suchresultaten und im Vokabular von Organisationen. Die aktuelle Plattform führt Agenten, Modelle, Werkzeuge, Evaluationen, Tracing, Monitoring, Identität, Netzwerk und Richtlinien in einem stärker vereinheitlichten Azure-Managementmodell zusammen.

Diese Konsolidierung ist nützlich. Sie ersetzt keine Strategie.

Die erste Unternehmensfrage sollte nicht lauten: «Wie führen wir Foundry ein?» Sie sollte lauten: Welches Geschäftsergebnis rechtfertigt ein klar begrenztes KI-System – und welche Evidenz erlaubt dessen Betrieb?

Was Foundry standardisieren kann

Eine Plattform verdient ihren Platz, wenn sie wiederkehrende Engineering-Arbeit reduziert, ohne wichtige Entscheidungen zu verdecken. Foundry kann für mehrere Teile des Lebenszyklus ein gemeinsames Projekt und eine gemeinsame Steuerungsebene bereitstellen:

  • Zugriff auf unterstützte Modelle über verwaltete Endpunkte;
  • Prompt- und Hosted-Agent-Runtimes;
  • Werkzeuge, Retrieval und Wissensverbindungen;
  • Evaluationen vor der Bereitstellung;
  • Tracing, Monitoring und Qualitätssignale aus dem Betrieb;
  • Microsoft-Entra-Identität, rollenbasierte Zugriffskontrolle, Netzwerkisolation und Azure Policy.

Dies kann die Zahl getrennter Portale, Zugangsdaten, SDKs und Betriebsmuster reduzieren, die ein Plattformteam steuern muss. Gleichzeitig entsteht ein klarerer Weg vom Experiment zu einem verantworteten Service.

Was die Plattform nicht entscheidet

Foundry weiss nicht, ob ein Workflow wichtig genug für Automatisierung ist. Die Plattform kann nicht definieren, welche Fehler tolerierbar sind, wer das Restrisiko akzeptiert oder wann ein Mensch eingreifen muss. Sie erstellt auch kein repräsentatives Evaluationsset, nur weil ein Evaluationsdienst verfügbar ist.

Diese Entscheidungen bleiben in der Organisation:

  1. Benennen Sie das Ergebnis und die geschäftlich verantwortliche Person.
  2. Dokumentieren Sie den heutigen Ausgangswert für Zeit, Qualität, Kosten oder Risiko.
  3. Definieren Sie die Daten- und Aktionsgrenze.
  4. Erstellen Sie Akzeptanztests aus repräsentativer Arbeit.
  5. Bestimmen Sie Betriebsverantwortung und Eskalationsweg.

Ohne diese Bedingungen beschleunigt eine leistungsfähige Plattform möglicherweise eine schwache Mission.

Mit Missionsarchitektur arbeiten

Behandeln Sie jede erste Bereitstellung als Mission mit expliziten Grenzen. Trennen Sie Geschäfts-Workflow, Modellendpunkt, Retrieval-Pipeline, Werkzeuge und Benutzeroberfläche. Halten Sie das Evaluationsset so portabel, dass Modell- oder Orchestrierungsänderungen vergleichbar bleiben. Bewahren Sie die Identität des Nutzers, wenn das System auf Geschäftsdaten oder Aktionen zugreift.

Entscheiden Sie danach, welche Foundry-Funktionen tatsächlich nützlich sind. Ein einfacher interner Assistent benötigt möglicherweise einen Modellendpunkt, Retrieval, Anwendungstelemetrie und eine schmale Evaluationspipeline. Ein werkzeugnutzender Agent braucht zusätzlich eventuell eine verwaltete Identität, versionierte Bereitstellungen, verteilte Traces, Aktionsgrenzen und menschliche Freigabepunkte. Nicht jede Mission benötigt jede Plattformfunktion.

Eine sinnvolle Einführungsreihenfolge

Erstens: die Aufgabe belegen. Nutzen Sie reale Beispiele, einschliesslich schwieriger und adversarial Fälle. Prüfen Sie, ob das System den Workflow überhaupt verbessern kann.

Zweitens: die Kontrollen belegen. Testen Sie Berechtigungen, Grounding, Werkzeugverhalten, Ablehnung, Eskalation, Latenz und Kosten – nicht nur die Antwortqualität.

Drittens: den Betrieb belegen. Versionieren Sie die Anwendung, beobachten Sie sie in Produktion, untersuchen Sie fehlgeschlagene Traces und stellen Sie sicher, dass die Verantwortung das Pilotteam überlebt.

Erst dann sollte die Organisation wiederverwendbare Plattformmuster für weitere Missionen schaffen.

Die Entscheidung für Führungskräfte

Wählen Sie Foundry, weil Kontrollen und verwaltete Funktionen zu Ihrer Azure-Landschaft passen und den Betrieb der ausgewählten Workloads vereinfachen. Wählen Sie die Plattform nicht, weil die Organisation eine sichtbare «KI-Plattform»-Initiative benötigt.

Der dauerhafte Wert ist nicht die Portalkonfiguration. Er entsteht aus einer wertvollen Mission, repräsentativer Evidenz, durchgesetzten Grenzen und einem Team, das das System auch bei veränderten Modellen und Anforderungen betreiben kann.

Offizielle Referenz

Microsoft beschreibt das aktuelle Plattformmodell und den Übergang von Azure AI Foundry in Was ist Microsoft Foundry?.

← Zurück zu News & Einblicke