Der entscheidende Gedanke dahinter: Eine KI-Anwendung entsteht nicht mit einem einzigen Aufruf eines Sprachmodells. Zwischen der ersten Idee und einer verlässlichen, produktiven Lösung liegen viele Schritte – das passende Modell auswählen, Prompts formulieren, mehrere Bausteine zu einem Ablauf verketten, das Ergebnis systematisch bewerten, die Anwendung sicher bereitstellen und ihren Betrieb überwachen. Azure AI Foundry deckt genau diese Kette ab und gibt ihr eine gemeinsame Oberfläche und ein gemeinsames Werkzeugset. Statt einzelne Dienste manuell zu verdrahten, arbeitet man in einer zusammenhängenden Umgebung.
Foundry ist damit von einer wichtigen Nachbarschaft klar zu unterscheiden: Es ist nicht der Endanwender-Assistent wie Microsoft Copilot und auch nicht der einzelne Modell-Dienst wie Azure OpenAI. Es ist die Entwickler- und Betriebsplattform, mit der ein Unternehmen eigene, auf seine Prozesse zugeschnittene KI-Lösungen baut – von einem intelligenten Dokumenten-Assistenten über eine Wissensrecherche auf eigenen Daten bis zu einem Agenten, der mehrschrittige Aufgaben erledigt. Diese Abgrenzung ist so wichtig, dass ihr ein eigenes Kapitel gewidmet ist.
Der heutige Name ist neu, das Anliegen nicht. Microsoft hat die Plattform zunächst als Azure AI Studio eingeführt und sie später in Azure AI Foundry umbenannt und erweitert. Die Umbenennung war kein reines Marketing: Sie markiert die Verschiebung vom reinen „Studio“, in dem man Modelle ausprobiert und Prototypen baut, hin zu einer „Foundry“ – einer Gießerei, in der KI-Anwendungen und vor allem Agenten nicht nur entstehen, sondern serienreif produziert, betrieben und regiert werden. Wer noch auf ältere Dokumentation oder Schulungen stößt, in denen von Azure AI Studio die Rede ist, kann in der Regel davon ausgehen, dass dieselbe Plattform gemeint ist – nur unter dem älteren Namen und mit einem etwas engeren Funktionsumfang.
Diese Historie zu kennen, hat einen praktischen Wert: Suchergebnisse, Tutorials und Erfahrungsberichte firmieren teils noch unter dem alten Namen. Wer weiß, dass Studio und Foundry auf derselben Linie liegen, verwechselt sie nicht mit anderen Microsoft-KI-Produkten und ordnet Fundstellen richtig ein. Da Microsoft seine KI-Plattformen rasch weiterentwickelt, sollte der jeweils aktuelle Funktionsstand und die genaue Namensgebung stets bei Microsoft geprüft werden.
Die Teile ergeben erst im Zusammenhang Sinn. Am Anfang steht der Modellkatalog: Aus ihm wählt man das Modell, das den Kern der Anwendung bildet. Mit Prompt Flow gestaltet man dann den Ablauf, in dem dieses Modell arbeitet – etwa: Nutzerfrage aufnehmen, relevante Dokumente heranziehen, Antwort formulieren. Mit Evaluations prüft man, ob dieser Ablauf gute Ergebnisse liefert, bevor er in Produktion geht. Der Foundry Agent Service hebt das Ganze auf die nächste Stufe, wenn nicht nur eine feste Kette, sondern ein handelnder Agent gebraucht wird. Und über allem liegen Portal und SDK als die beiden Zugänge – grafisch für die einen, programmatisch für die anderen.
Foundry sitzt auf einer bewussten Ebene. Ganz oben, beim Endanwender, stehen fertige Assistenten wie Microsoft Copilot. Für begrenzte Anpassungen und einfache eigene Assistenten gibt es Copilot Studio als Low-Code-Werkzeug. Ganz unten liegen die reinen Modell-Dienste wie Azure OpenAI. Azure AI Foundry liegt dazwischen und darüber: als die professionelle Entwickler- und Betriebsplattform, die den Modell-Zugang mit Werkzeugen, Qualitätsmessung, Agenten und Betrieb zu einem Ganzen verbindet. Diese Positionierung erklärt, warum Foundry für maßgeschneiderte KI-Anwendungen und Agenten die richtige Wahl ist – und warum es für den einfachen Chat-Assistenten überdimensioniert wäre.
Der wichtigste konzeptionelle Sprung, den Foundry ermöglicht, betrifft den Umgang mit Prompts. In der frühen Experimentierphase tippt man Prompts in ein Chatfenster und passt sie so lange an, bis das Ergebnis brauchbar aussieht. Für eine produktive Anwendung reicht das nicht: Man braucht einen definierten Ablauf, der reproduzierbar ist, der sich versionieren und im Team teilen lässt und der bei einer Änderung nicht unbemerkt schlechter wird. Genau das leistet Prompt Flow. Es verwandelt das intuitive Herumprobieren an Formulierungen in eine strukturierte, teilbare und wartbare Konstruktion – ein wichtiger Schritt von der Bastelei zur belastbaren Softwarearbeit.
Die Fähigkeit, Qualität zu messen, ist im professionellen KI-Einsatz oft wichtiger als jede einzelne Funktion. Sprachmodelle formulieren überzeugend, auch wenn sie danebenliegen – die berüchtigten Halluzinationen. Ohne systematische Bewertung merkt niemand, wenn eine scheinbar kleine Änderung am Prompt oder ein Modellwechsel die Antwortqualität verschlechtert. Evaluations schließt diese Lücke: Es prüft einen Ablauf gegen definierte Testfälle und Kriterien und macht Qualität damit zu einer messbaren Größe. Für den Mittelstand ist das der Baustein, der aus einem netten Prototyp eine verantwortbare Lösung macht – weil er die Frage „können wir uns auf diese KI verlassen?“ mit Zahlen statt mit Hoffnung beantwortet.
Der Unterschied lässt sich gut an einem Bild fassen. Ein Assistent ist wie ein sachkundiger Gesprächspartner: Man stellt eine Frage, bekommt eine Antwort, stellt die nächste Frage. Ein Agent ist eher wie eine handelnde Assistenz, der man ein Ziel gibt: Er zerlegt die Aufgabe in Schritte, holt sich unterwegs Informationen, nutzt Werkzeuge – etwa eine Suche in eigenen Dokumenten, den Aufruf einer Fachanwendung oder das Ausführen einer Berechnung – und arbeitet auf das Ergebnis hin. Der Foundry Agent Service ist der Baustein, mit dem man solche Agenten definiert, mit Werkzeugen und Datenzugriff ausstattet und betreibt.
Für den Mittelstand eröffnet das eine neue Klasse von Anwendungen. Statt nur Texte zu formulieren oder Fragen zu beantworten, kann ein Agent zum Beispiel eine eingehende Anfrage einordnen, die nötigen Informationen aus verschiedenen Quellen zusammentragen und einen Antwortentwurf mit den passenden Anlagen vorbereiten – als Entwurf zur menschlichen Freigabe. Der Sprung von der reinen Textproduktion zur handelnden Unterstützung ist der eigentliche Reiz der Agenten-Idee.
Die Stärke eines Agenten entsteht durch den Zugriff auf Werkzeuge und Daten. Ein Sprachmodell allein kennt nur, was in seinem Training steckte und was man ihm im Gespräch mitgibt. Ein Agent im Foundry Agent Service kann darüber hinaus definierte Werkzeuge nutzen – etwa eine Suche in den Wissensbeständen des Unternehmens, die Anbindung an eine Fachanwendung oder den Abruf aktueller Daten. Erst diese Anbindung an die reale Informationswelt des Unternehmens macht einen Agenten von einer beeindruckenden Sprachmaschine zu einem nützlichen Mitarbeiter-Werkzeug. Genau hier verzahnt sich Foundry eng mit Diensten wie Azure AI Search, die dem Agenten Zugriff auf eigene Dokumente geben – dazu mehr im nächsten Kapitel.
Bei aller Faszination gehört ein nüchterner Blick dazu. Agenten sind mächtig, aber nicht unfehlbar – und je mehr Handlungsspielraum ein Agent bekommt, desto größer ist die Verantwortung, ihn einzuhegen. Ein Agent, der eigenständig Werkzeuge aufruft und Aktionen anstößt, braucht klare Grenzen: Welche Aktionen darf er auslösen, welche nur vorschlagen? Wo muss ein Mensch bestätigen, bevor etwas Verbindliches geschieht? Wie wird nachvollziehbar protokolliert, was der Agent getan hat? Diese Fragen sind kein technisches Detail, sondern die Voraussetzung dafür, dass ein Agent verantwortbar arbeitet. Der bewährte Grundsatz lautet: Je folgenreicher eine Handlung, desto enger die menschliche Kontrolle. Für den Einstieg empfehlen wir Agenten, die vorbereiten und vorschlagen, während der Mensch entscheidet und freigibt – und ein schrittweises Erweitern des Handlungsspielraums, sobald Vertrauen und Erfahrung gewachsen sind.
Ein häufiges Missverständnis ist die Vorstellung, man müsse sich zwischen Azure AI Foundry und Azure OpenAI entscheiden. Das trifft nicht zu: Azure OpenAI ist einer der Modell-Dienste, auf die Foundry zugreift. Man kann sich Azure OpenAI als eine der Kraftquellen vorstellen und Foundry als die Werkbank, die diese Kraftquelle zusammen mit Werkzeugen, Qualitätsmessung und Betrieb nutzbar macht. Wer nur einen direkten Modell-Zugang braucht, um Anfragen an ein Sprachmodell zu schicken, kommt mit Azure OpenAI allein aus. Wer eine echte Anwendung mit Ablauflogik, Datenanbindung, Qualitätsmessung und Betriebssicht bauen will, arbeitet in Foundry und nutzt Azure OpenAI darin als eine der Modellquellen.
Der wohl wichtigste Integrationspunkt für den Mittelstand ist die Verbindung zu Azure AI Search. Der eigentliche Wert vieler KI-Anwendungen entsteht nicht aus dem allgemeinen Weltwissen des Modells, sondern aus der Fähigkeit, auf Basis der eigenen Dokumente, Handbücher, Verträge oder Wissensbestände zu antworten. Genau das leistet das Zusammenspiel: Azure AI Search durchsucht die eigenen Daten und liefert die passenden Ausschnitte, das Modell in Foundry formuliert daraus eine belegte Antwort. Dieses Muster – oft als abrufgestützte Erzeugung bezeichnet – ist das Fundament von Wissens-Assistenten, die verlässlich auf die Realität des Unternehmens Bezug nehmen, statt frei zu erfinden. Für viele Mittelständler ist es der überzeugendste erste Foundry-Anwendungsfall.
Foundry und Microsoft Copilot bewegen sich auf verschiedenen Ebenen, berühren sich aber. Copilot ist der fertige Assistent für den Endanwender im Microsoft-365-Alltag; Foundry ist die Plattform, auf der man eigene KI-Fähigkeiten und Agenten baut. Der Anschluss besteht darin, dass in Foundry gebaute Fähigkeiten in die Copilot- und Microsoft-365-Welt einfließen können, sodass maßgeschneiderte KI nicht in einem isolierten Werkzeug endet, sondern dort wirkt, wo die Menschen ohnehin arbeiten. Die konkreten Wege dieser Verbindung entwickeln sich schnell weiter; die Grundidee bleibt: bauen in Foundry, wirken in der vertrauten Arbeitsumgebung.
Am unteren Ende der Skala steht Azure OpenAI als reiner Modell-Dienst. Wer nur einen direkten Zugang zu einem leistungsfähigen Sprachmodell braucht – um aus einer bestehenden Anwendung heraus Anfragen zu schicken und Antworten zu erhalten –, ist damit gut bedient. Azure OpenAI liefert die rohe Modellkraft im Azure-Rahmen, ohne die zusätzliche Werkbank drumherum. Der Preis dieser Schlankheit: Ablauflogik, Qualitätsmessung, Agenten und Betriebssicht muss man selbst zusammensetzen. Für eng umrissene, technisch geführte Einbindungen ist das oft genau richtig; für den Bau einer vollständigen KI-Anwendung wird es schnell aufwendig.
Am anderen Ende steht Copilot Studio als Low-Code-Werkzeug, mit dem auch weniger technische Anwender eigene Assistenten und einfache Automatisierungen bauen können – geführt, mit grafischen Bausteinen, ohne tiefe Entwicklungsarbeit. Wer schnell einen abgegrenzten Assistenten für eine begrenzte Aufgabe braucht, etwa einen FAQ-Bot auf einer Wissenssammlung, kommt mit Copilot Studio oft rascher und günstiger ans Ziel als mit dem vollen Foundry-Apparat. Die Grenze zeigt sich, sobald die Anforderungen an Individualität, Komplexität der Abläufe, Qualitätsmessung oder anspruchsvolle Agenten wachsen – dann stößt der Low-Code-Ansatz an seine Grenzen.
Dazwischen und darüber liegt Azure AI Foundry. Es ist die Wahl, wenn eine maßgeschneiderte KI-Anwendung oder ein anspruchsvoller Agent entstehen soll, wenn Abläufe komplex sind, wenn die Qualität systematisch gemessen werden muss und wenn der Betrieb professionell überwacht werden soll. Die Faustregel: Copilot Studio für schnelle, geführte Assistenten ohne Code; Azure OpenAI für den rohen Modell-Zugriff; Azure AI Foundry für alles dazwischen und darüber – die individuelle, betriebene KI-Anwendung mit voller Kontrolle über Ablauf, Qualität und Betrieb. Häufig ergänzen sich die Werkzeuge sogar: Foundry nutzt Azure OpenAI als Modellquelle, und einfache Assistenten aus Copilot Studio können neben anspruchsvollen Foundry-Lösungen im selben Haus existieren.
Der Betrieb von KI-Anwendungen hat eine eigene Disziplin hervorgebracht. Aus dem klassischen MLOps – dem professionellen Betrieb von Machine-Learning-Modellen – ist mit den großen Sprachmodellen LLMOps geworden, das die Besonderheiten dieser Modelle berücksichtigt. Der wichtigste Unterschied: Bei Sprachmodellen ist das Verhalten nicht so deterministisch wie bei klassischer Software. Dieselbe Frage kann leicht unterschiedliche Antworten hervorbringen, kleine Prompt-Änderungen können große Wirkung haben, und die Qualität lässt sich nicht mit einem einfachen Test abhaken. Deshalb rücken systematische Bewertung, laufende Beobachtung und kontrollierte Änderungen ins Zentrum. Foundry unterstützt genau diese Praxis – aber die Disziplin selbst muss das Unternehmen etablieren.
In unseren Projekten sehen wir immer wieder denselben Stolperstein: Ein beeindruckender Prototyp entsteht in wenigen Tagen, und die Erwartung ist, ihn schnell produktiv zu schalten. Doch zwischen einem Prototyp, der in der Demo gut aussieht, und einer Anwendung, die täglich verlässlich, sicher und mit gemessener Qualität arbeitet, liegt erhebliche Arbeit – Governance, Qualitätsmessung, Betrieb, Freigabeprozesse. Wer diesen Abstand unterschätzt, gerät in die typische Falle: eine Lösung, die in der Vorführung glänzt, im Alltag aber unzuverlässig, unkontrolliert und teuer wird. Der professionelle Betrieb ist kein Nachgedanke, sondern integraler Teil des Vorhabens.
Foundry ist ein mächtiges Werkzeug, und Mächtigkeit hat ihren Preis in Form von Aufwand und benötigter Kompetenz. Deshalb ist die ehrliche erste Frage nicht „wie bauen wir es“, sondern „lohnt es sich überhaupt“. Foundry rechnet sich dort, wo eine individuelle, wiederkehrend genutzte KI-Anwendung echten Wert schafft und sich mit fertigen Werkzeugen nicht abbilden lässt. Wer dagegen nur einen einfachen Assistenten für eine begrenzte Aufgabe braucht, ist mit Copilot Studio oder dem Standard-Copilot oft besser bedient – schneller, günstiger, ohne eigenes Entwicklungs- und Betriebsteam. Der teuerste Weg ist, mit Foundry eine Lösung zu bauen, die es fertig zu kaufen gäbe.
Ein Punkt, der in Technologie-Begeisterung gern übersehen wird: Foundry setzt Menschen voraus, die damit bauen und betreiben können. Das können eigene Entwicklerinnen und Entwickler sein oder ein Partner, der das Vorhaben begleitet. Ohne diese Kompetenz bleibt die Plattform ein ungenutztes Potenzial – oder schlimmer, ein Prototyp ohne verantwortbaren Betrieb. Für den Mittelstand bedeutet das: Die Entscheidung für Foundry ist immer auch eine Entscheidung über Kompetenzaufbau oder Partnerschaft. Diese Frage gehört an den Anfang der Überlegung, nicht ans Ende. Genau hier setzt eine ehrliche Beratung an – mit der nüchternen Prüfung, ob Foundry das richtige Werkzeug für den konkreten Fall ist, und mit dem Aufbau der nötigen Betriebsfähigkeit.
Bewusst nennt dieser Artikel keine konkreten Beträge. Die Preise für Modell-Nutzung und Azure-Dienste ändern sich regelmäßig, unterscheiden sich nach Modell, Region und Vertrag und hängen stark vom tatsächlichen Nutzungsvolumen ab. Jede genannte Zahl wäre eine Scheingenauigkeit. Verlässlich ist die Kosten-Logik: Foundry-Kosten sind überwiegend verbrauchsabhängig – man zahlt im Wesentlichen für die verarbeitete Menge, nicht einen festen Kopfpreis. Das ist eine Chance und ein Risiko zugleich: Bei kleinem Start bleiben die Kosten niedrig, bei unkontrolliertem Wachstum können sie überraschend steigen. Deshalb gehören die Beobachtung der Nutzung und klare Grenzen von Anfang an zum Betrieb. Für eine belastbare Kalkulation gehört die aktuelle Preisliste – idealerweise über den eigenen Microsoft-Partner oder das Vertragswerk – in die Rechnung, nicht ein Wert aus einem Artikel.
Für den DACH-Mittelstand ist die Datenresidenz eine zentrale Frage. Microsoft bietet mit der EU Data Boundary und der Wahl von EU-Regionen die Möglichkeit, Kundendaten innerhalb der Europäischen Union zu verarbeiten. Das stärkt die Datenresidenz erheblich und ist für viele Vorhaben die Grundlage, um Foundry überhaupt einzusetzen. Wichtig ist, diese Optionen bewusst zu konfigurieren – die Wahl der richtigen Region und der EU-Datenverarbeitung ist eine aktive Entscheidung, kein Automatismus. Welche Regionen und Modelle im konkreten Fall verfügbar sind und wie die EU Data Boundary im Detail wirkt, sollte im aktuellen Stand bei Microsoft geprüft werden, da sich der Umfang laufend erweitert.
Trotz EU-Verarbeitung bleibt eine Tatsache bestehen: Microsoft ist ein US-Konzern und unterliegt damit dem US Cloud Act. Das bedeutet ein Restrisiko eines behördlichen Zugriffs, das die EU-Datenverarbeitung zwar deutlich reduziert, aber nicht vollständig aufhebt. Für die meisten mittelständischen Anwendungsfälle ist dieses Restrisiko bei bewusster Konfiguration akzeptabel. Für besonders sensible Daten, Berufsgeheimnisträger oder KRITIS-nahe Bereiche gehört diese Frage jedoch in eine sorgfältige, fallbezogene Bewertung mit der Datenschutz- und Rechtsfunktion. Hinzu kommt die Frage, ob eigene Daten zum Training der Modelle verwendet werden: Microsoft macht hierzu Zusagen, die die Nutzung von Kundendaten für das Modelltraining ausschließen – diese sind als vertragliche Zusicherung zu behandeln, im Auftragsverarbeitungsvertrag zu verankern und im aktuellen Stand zu prüfen.
