Was ist Microsoft Foundry? Architektur, Projekte und Einsatzgrenzen

Was ist Microsoft Foundry im Unternehmenskontext?

Was ist Microsoft Foundry? Die Plattform bündelt Entwicklung, Bereitstellung und Governance von KI-Anwendungen und Agents in Azure. Sie verbindet Modellzugriff, Agent Service, Evaluierung, Tracing und angebundene Dienste unter einem gemeinsamen Ressourcen- und Projektmodell. Damit richtet sie sich vor allem an Teams, die mehr Kontrolle benötigen, als ein fertiger Produktivitäts-Copilot oder eine reine Low-Code-Konfiguration bietet.

Microsoft Foundry ist die aktuelle Bezeichnung für die weiterentwickelte Plattform, die zuvor als Azure AI Studio beziehungsweise Azure AI Foundry bekannt war. Ältere Suchanfragen und Dokumentationen verwenden diese Namen noch. Für neue Architekturen sollte geprüft werden, ob sie bereits das aktuelle Foundry-Ressourcenmodell oder noch klassische Hub-basierte Strukturen beschreiben.

Welche Probleme die Plattform löst

Ein direkter Modellaufruf kann einen Prototyp schnell ermöglichen. Für den produktiven Einsatz kommen jedoch Identitäten, Netzwerkgrenzen, Modellbereitstellungen, Tools, Datenzugriff, Tests, Protokollierung und Kostenkontrolle hinzu. Werden diese Aufgaben in jedem Projekt neu gelöst, entstehen uneinheitliche Sicherheits- und Betriebsmodelle.

Foundry schafft dafür eine gemeinsame Plattformebene. Teams können Modelle vergleichen, Agents entwickeln, Evaluierungen ausführen und Telemetrie mit Azure-Diensten verbinden. Das ersetzt keine fachliche Architekturentscheidung, reduziert aber die Zahl selbst gebauter Plattformkomponenten. Der Artikel zur Skalierung von KI-Transformationen beschreibt, warum genau diese Betriebsfragen nach einem erfolgreichen Pilot relevant werden.

Foundry-Ressource und Projekte sauber trennen

Die Foundry-Ressource bildet die übergeordnete Verwaltungsgrenze. Dort werden gemeinsame Modellzugänge, Richtlinien, Netzwerk- und Zugriffsentscheidungen verankert. Projekte schaffen darunter getrennte Arbeitsbereiche für Anwendungen, Teams oder Lifecycle-Stufen. Diese Trennung ist entscheidend, wenn mehrere Fachbereiche dieselbe Plattform verwenden.

Ein Projekt ist keine vollständige Sicherheitsstrategie. Verantwortliche müssen festlegen, welche Ressourcen geteilt werden dürfen, wie Entwicklung und Produktion getrennt bleiben und wer Modelle bereitstellen oder Agents veröffentlichen kann. Namenskonventionen, Tags und Kostenstellen sollten bereits beim ersten produktiven Projekt feststehen.

Modelle sind austauschbare Architekturbausteine

Foundry stellt einen Modellkatalog mit Modellen unterschiedlicher Anbieter und Bereitstellungsarten bereit. Die Auswahl richtet sich nicht allein nach allgemeiner Modellqualität. Kontextfenster, Sprache, Latenz, Werkzeugnutzung, Datenresidenz, Kosten und Verfügbarkeit in der Zielregion beeinflussen den Anwendungsfall.

Ein Modell wird als versionierter technischer Baustein behandelt. Wechsel oder Versionsupdates benötigen Regressionstests, weil identische Anweisungen andere Ergebnisse erzeugen können. Für kritische Prozesse sollte die Anwendung Modellname, Deployment und relevante Parameter nachvollziehbar protokollieren.

Agent Service verbindet Modell, Anweisungen und Tools

Ein Agent ergänzt den Modellaufruf um Anweisungen, Werkzeuge, Gesprächszustand und gegebenenfalls Wissen. Foundry Agent Service stellt dafür verwaltete Laufzeitfunktionen bereit. Prompt Agents lassen sich deklarativer konfigurieren; Hosted Agents erlauben eigenen Code und Frameworks, wenn Orchestrierung oder Laufzeit stärker angepasst werden müssen.

Die Plattform übernimmt dabei Hostingaufgaben, aber nicht die fachliche Verantwortung. Jedes Tool benötigt begrenzte Berechtigungen und eine klar definierte Schnittstelle. Ein Agent, der Daten verändern darf, muss Fehler, Wiederholung, Bestätigung und Abbruch genauso behandeln wie eine andere produktive Anwendung.

Tools und angebundene Azure-Dienste

Tools verbinden den Agenten mit Suche, Funktionen, APIs oder Geschäftssystemen. Häufige Bausteine sind Azure AI Search, Azure Functions, Logic Apps, OpenAPI-Schnittstellen oder MCP-Server. Je nach Anwendungsfall kommen Storage, Key Vault und Application Insights hinzu.

Diese Komponenten sollten nicht als wahllose Funktionssammlung angebunden werden. Jede Verbindung vergrößert Berechtigungsumfang, Fehlerfläche und Kosten. Eine Schnittstelle wird nur aufgenommen, wenn ihr Zweck, ihre Authentifizierung, ihr Eigentümer und ihr Verhalten bei Ausfall dokumentiert sind.

Identität und RBAC als Kern der Architektur

Entwickler, Betreiber, Anwendungen und Agents benötigen unterschiedliche Rechte. Microsoft Entra ID und Azure RBAC steuern, wer Ressourcen verwalten, Modelle bereitstellen oder Endpunkte aufrufen darf. Produktionsanwendungen sollten nach Möglichkeit verwaltete Identitäten verwenden, statt Schlüssel in Konfigurationen oder Quellcode zu verteilen.

Rollen werden auf der kleinsten sinnvollen Ebene vergeben. Ein Entwickler benötigt nicht automatisch Eigentümerrechte auf der Subscription, und ein Agent muss nicht auf alle Datenquellen eines Projekts zugreifen. Regelmäßige Reviews entfernen veraltete Gruppenmitgliedschaften und prüfen privilegierte Änderungen.

Netzwerk, Datenflüsse und Geheimnisse planen

Für sensible Workloads reicht eine Anmeldung allein nicht immer aus. Private Endpunkte, virtuelle Netzwerke, kontrollierter ausgehender Verkehr und regionale Verfügbarkeit bestimmen, wie Daten zwischen Anwendung, Modell und angebundenen Diensten fließen. Die gewählte Architektur muss auch Entwicklungswerkzeuge, CI/CD und Supportzugriffe berücksichtigen.

Schlüssel und Verbindungsdaten gehören in einen geeigneten Secret Store. Protokolle dürfen keine vollständigen Prompts, Dokumente oder personenbezogenen Inhalte aufnehmen, wenn diese für Diagnose und Evaluation nicht erforderlich sind. Datenminimierung gilt deshalb auch für Telemetrie und Testdatensätze.

Evaluation und Observability gehören zum Produkt

Bei generativer KI reicht ein erfolgreicher HTTP-Status nicht als Qualitätsnachweis. Evaluierungen messen unter anderem Relevanz, Groundedness, Aufgabenabschluss, Toolaufrufe und Sicherheitsaspekte. Traces zeigen, welche Modell- und Werkzeugschritte zu einer Antwort geführt haben.

Application Insights und OpenTelemetry können Betriebsdaten, Latenzen und Fehlerpfade sichtbar machen. Zugriffe auf Gesprächsinhalte werden begrenzt und protokolliert. Schwellenwerte und Alarme müssen an einen Supportprozess gekoppelt sein; ein Dashboard ohne verantwortliche Reaktion verbessert den Betrieb nicht.

Wann Microsoft Foundry sinnvoll ist

Foundry passt, wenn ein Team eigene KI-Anwendungen oder Agents mit kontrollierter Laufzeit, Modellwahl, APIs und Azure-Governance entwickeln will. Typische Auslöser sind individuelle Benutzeroberflächen, komplexes Retrieval, eigene Orchestrierung, private Netzwerke oder die Integration in bestehende Softwareprodukte.

Für einen einfachen persönlichen Wissensagenten in Microsoft 365 kann die Plattform unverhältnismäßig sein. Dort sind Agent Builder oder Copilot Studio oft näher am benötigten Kanal und reduzieren den Entwicklungsaufwand. Die Entscheidung ähnelt der allgemeinen Abwägung zwischen Low-Code und Pro-Code auf Microsoft 365: Kontrolle ist wertvoll, verursacht aber auch Betriebsverantwortung.

Betriebskosten entstehen in mehreren Diensten

Die Foundry-Ressource allein beschreibt nicht die Gesamtkosten. Modelltoken, Agentlaufzeit, Search, Storage, Netzwerk, Monitoring und gegebenenfalls weitere KI-Dienste werden nach ihren jeweiligen Modellen abgerechnet. Ein Kostenmodell muss deshalb den vollständigen Daten- und Aufrufweg abbilden.

Budgets, Tags und Warnungen werden pro Projekt beziehungsweise Kostenstelle vorbereitet. Lasttests berücksichtigen neben dem Mittelwert auch lange Anfragen, wiederholte Toolaufrufe und umfangreiche Retrieval-Kontexte. Nicht mehr benötigte Deployments und Testressourcen werden geregelt entfernt.

So wird Foundry als Plattform und nicht als Playground genutzt

Microsoft Foundry schafft einen gemeinsamen Rahmen für Modelle, Agents, Evaluation und Azure-Betrieb. Der Nutzen entsteht erst, wenn Ressourcen- und Projektgrenzen, Identitäten, Datenwege und Verantwortlichkeiten bewusst gestaltet werden. Ein Playground-Ergebnis ist der Anfang einer Entwicklung, nicht deren Produktionsfreigabe.

Die Plattform ist besonders tragfähig, wenn mehrere Teams wiederholbare Standards benötigen. Gemeinsame Vorgaben für Projekte, Modelle, Telemetrie, Secrets und Releases verhindern, dass jeder Agent eine eigene Infrastrukturinsel bildet. Damit lässt sich die technische Freiheit von Pro-Code mit einem kontrollierten Betriebsmodell verbinden.

Projektgrenzen an Verantwortung und Risiko ausrichten

Ein Projekt sollte eine nachvollziehbare Gruppe von Anwendungen und Verantwortlichen bündeln. Getrennte Datenklassifikationen, Betriebsmodelle oder Kostenstellen sprechen für getrennte Projekte. Jede kleine Experimentidee in ein eigenes Projekt zu legen, erzeugt dagegen unnötige Rollen-, Netzwerk- und Monitoringarbeit.

Die Entscheidung wird als Standard dokumentiert: zulässige Regionen, Namensschema, Tags, Eigentümer, Verbindungstypen und Übergang in Produktion. So können Teams selbstständig starten, ohne grundlegende Sicherheitsentscheidungen bei jedem Vorhaben neu zu verhandeln.

Netzwerkpfad vom Benutzer bis zur Datenquelle prüfen

Zur Architektur gehören nicht allein Foundry-Endpunkte. Der vollständige Pfad umfasst aufrufende Anwendung, Identitätsdienst, Modell, Such- oder Speicherdienst, Tools und Telemetrie. Für jede Verbindung wird geklärt, ob sie öffentlich, über Dienstendpunkte oder private Anbindung erfolgt und wie Namensauflösung sowie Firewallregeln funktionieren.

Private Vernetzung erhöht Kontrolle, bringt aber Abhängigkeiten bei DNS, Routing und Entwicklungszugang. Ein Architekturtest sollte deshalb nicht nur einen Modellaufruf aus dem Studio prüfen. Er muss denselben Pfad nutzen, den die produktive Anwendung später verwendet.

Plattformteam und Produktteam sauber trennen

Das Plattformteam verantwortet Leitplanken, Identitätsmuster, Netzwerk, Modellfreigaben, Observability und Kostenstandards. Das Produktteam verantwortet fachlichen Nutzen, Prompts, Werkzeuge, Evaluationsdaten und Support für den konkreten Anwendungsfall. Beide Seiten teilen die Verantwortung für die Produktionsfreigabe.

Diese Trennung verhindert zwei Extreme: eine zentrale Plattform, die fachliche Qualität erraten muss, und Produktteams, die Sicherheits- sowie Betriebsgrundlagen jeweils neu bauen. Ein kurzer Servicekatalog beschreibt, was die Plattform bereitstellt und welche Nachweise das Produktteam liefern muss.

Eine Referenzarchitektur als überprüfbaren Vertrag führen

Die Referenzarchitektur sollte mehr als ein Schaubild sein. Sie benennt erlaubte Ressourcentypen, Identitätsmuster, Netzwerkzonen, Protokollierungsstandard, Modellfreigabe, Datenklassifikation und Produktionskriterien. Für jede Vorgabe steht fest, ob sie technisch erzwungen, in einer Pipeline geprüft oder organisatorisch abgenommen wird. Teams erkennen damit früh, welche Teile die Plattform bereitstellt und welche sie selbst implementieren müssen.

Abweichungen werden über einen zeitlich begrenzten Entscheidungsprozess behandelt. Der Antrag beschreibt geschäftlichen Grund, Risiko, Ersatzkontrollen, Eigentümer und Rückkehr zum Standard. Erkenntnisse aus Projekten fließen regelmäßig in die Referenzarchitektur zurück. So bleibt sie mit neuen Foundry-Funktionen und realen Betriebsproblemen verbunden, ohne dass jedes Produktteam eine eigene Sicherheits- und Betriebsarchitektur erfindet.

Region und Dienstverfügbarkeit früh bestätigen

Modelle, Agentenfunktionen und abhängige Azure-Dienste sind nicht in jeder Region identisch verfügbar. Vor der Zielarchitektur werden Datenresidenz, Latenz, Kapazität, Netzwerkoptionen und aktueller Produktstatus gemeinsam geprüft. Ein Pilot in einer bequemen Region darf nicht unbemerkt zum Produktionsstandard werden, wenn fachliche oder regulatorische Vorgaben eine andere Region verlangen. Die Entscheidung enthält außerdem einen Umgang mit regionalen Engpässen und neuen Modellversionen. Dadurch bleibt nachvollziehbar, welche Abhängigkeit bewusst gewählt wurde und welche Änderung eine erneute Architekturfreigabe auslöst.