Azure AI Foundry ist Microsofts stärkstes Angebot für Enterprise-Governance, aber eine unglückliche Wahl für den ersten Schritt. Es ist die Plattform, die Azure OpenAI Service, Azure AI Search und Azure Machine Learning unter einer Steuerungsebene, einem Identitätsmodell und einer zentralen Überwachungsinstanz für Ihre Agenten vereint.
Stellen Sie es sich wie einen Kontrollturm vor. Hervorragend, wenn vierzig Flugzeuge im Landeanflug sind. Sehr teuer, wenn man nur ein einziges Flugzeug besitzt. Deshalb zahlt sich Azure AI Foundry erst beim zweiten oder dritten Anwendungsfall aus, nicht beim ersten. (Microsoft benannte es Microsoft Foundry auf der Ignite im November 2025 um. In den meisten Verträgen und Stellenbeschreibungen steht immer noch Azure AI Foundry, daher verwenden wir hier diesen Begriff. Es ist dieselbe Plattform.)
Nun zu dem Teil, den die Produktseiten verschweigen. Die meisten Azure AI Foundry-Projekte scheitern nicht am Modell. Sie scheitern in den zwei Wochen nach der Demo, wenn jemand fragt, wer die Verantwortung für die Aktionen des Agenten übernimmt, und niemand eine Antwort hat. Die Plattform war nie der Flaschenhals. Die Daten lagen in drei Systemen mit drei verschiedenen Berechtigungsmodellen, und der zuständige Business Owner, der die Ergebnisse hätte abnehmen oder ablehnen sollen, war nie benannt worden.
Azure AI Foundry vereint die KI-Dienste, für die Sie wahrscheinlich ohnehin schon bezahlen: Azure OpenAI Service, Azure AI Search, Azure Machine Learning und Microsoft Fabric. Eine Steuerungsebene. Ein Identitätsmodell. Eine Beobachtungsebene.
Das Rebranding zu Microsoft Foundry war nicht nur kosmetischer Natur; die inhaltlichen Änderungen wirken sich darauf aus, was Sie tatsächlich erwerben.
Was bringt Ihnen das also konkret? Keine Innovation. Es bringt Ihnen die Möglichkeit, mehr als eine KI-Workload zu betreiben, ohne dass jede einzelne zu einem eigenen Governance-Projekt wird. Das ist das Hauptargument für eine Plattform gegenüber einer Einzellösung, und es zahlt sich nur aus, wenn Sie planen, mehr als nur eine Anwendung zu entwickeln.
Verwandte IC-Lektüre: Leitfaden für Azure Machine Learning-Bereitstellung und MLOps
Jedes unserer Projekte beginnt mit denselben vier Fragen. Sie klingen vielleicht langweilig, sind aber aussagekräftiger für den Erfolg einer KI-Transformation als jeder technische Aspekt.
Bewerten Sie jede Dimension mit 0 bis 3, wobei 0 für „trifft überhaupt nicht zu“ und 3 für „trifft heute voll und ganz zu“ steht.
Kann der Agent auf die benötigten Daten zugreifen – rechtlich, technisch und in einer Qualität, die einen Mehrwert bietet? Es geht nicht darum, ob die Daten vorhanden sind. Die entscheidenden Fragen sind: Liegen sie in einem System mit API vor? Übersteht das Berechtigungskonzept den Zugriff durch einen Agenten im Namen des Nutzers? Und würde ein Mensch das Ergebnis als korrekt anerkennen?
Häufige Fehlerquelle: Die Wissensdatenbank existiert zwar, ist aber zu 40 % veraltet und niemand fühlt sich dafür verantwortlich. Der Agent gibt daraufhin mit voller Überzeugung eine Richtlinie wieder, die bereits 2023 außer Kraft gesetzt wurde.
Gibt es eine konkrete Person– kein Komitee und nicht „das Unternehmen“ –, die die Ergebnisse des Agenten abnimmt oder ablehnt? Jemand, dessen Arbeit durch den Erfolg des Projekts tatsächlich erleichtert wird?
Häufige Fehlerquelle: Das KI-Projekt liegt beim Innovationsteam, der zu automatisierende Prozess jedoch bei der Betriebsabteilung. Die Betriebsabteilung wurde nie einbezogen. Der Pilot läuft hervorragend, wird aber nie in den produktiven Einsatz übernommen.
Wissen Sie, was passiert, wenn der Agent einen Fehler macht? Wer trägt die Verantwortung, wie sieht der Audit-Trail aus und an welchen Stellen ist ein Mensch zwingend einzubinden?
Häufige Fehlerquelle: Diese Fragen werden auf die Zeit „vor dem Go-Live“ verschoben und blockieren dann den Start um vier Monate. In regulierten Branchen ist dies der häufigste Grund, warum ein funktionierender Prototyp nie veröffentlicht wird.
Wird das Team, das die Ergebnisse erhält, seine Arbeitsweise ändern? Wurden sie informiert? Ändern sich die Zielvorgaben für irgendjemanden?
Das Problem, das wir beobachten: Der Agent erstellt den Entwurf, der dann ignoriert wird, weil sich das Arbeitspensum für niemanden tatsächlich verringert hat. Sie prüfen nun den KI-Output und erledigen die ursprüngliche Aufgabe trotzdem. Mehr Arbeit. Nicht weniger.
| Punkte | Phase | Was zu tun ist |
|---|---|---|
| 0 bis 3 | Erkundung | Noch nicht entwickeln. Der Engpass liegt nicht bei der Plattform. Benennen Sie zuerst einen Entscheidungsträger und klären Sie die Datenverantwortung. Typischerweise vier bis acht Wochen unglamouröse Arbeit, aber günstiger als ein gescheitertes Pilotprojekt. |
| 4 bis 6 | Pilotierung | Ein schmaler Anwendungsfall, keine Bindung an eine Plattform. Beweisen Sie den Business Case an einem einzelnen Workflow, bevor Sie irgendetwas architektonisch aufbauen. |
| 7 bis 9 | Bereitstellung | Azure AI Foundry ist gerechtfertigt. Bauen Sie von Tag eins an für den Live-Betrieb – mit direkt integrierter Governance und Evaluierung, statt diese erst nachträglich aufzupfropfen. |
| 10 bis 12 | Flotte | Sie sind bereit für mehrere Agenten unter gemeinsamer Governance. An diesem Punkt zahlt sich die Wirtschaftlichkeit der Plattform endlich für Sie aus. |
Meistens kommen Unternehmen zu uns, die überzeugt sind, dass sie bei Bereitstellung liegen, landen aber bei einem Score im Bereich Pilotphase. Das ist keine Kritik. Es ist der normale Zustand einer Organisation, die seit achtzehn Monaten KI-Experimente ohne eine grundlegende Plattformentscheidung durchführt.
Das ist der Punkt, den die meisten Anbieter in ihren Inhalten auslassen – gehen wir also direkt darauf ein.
Für Azure AI Foundry fallen keine Lizenzgebühren an. Microsoft berechnet die zugrunde liegenden Dienste, die darüber orchestriert werden,, daher finden Sie auf Ihrer Abrechnung Posten wie Azure OpenAI Service, Azure AI Search, Azure Machine Learning und Speicher. Einen Posten namens „Foundry“ werden Sie dort nicht finden. Das sorgt bei Finanzabteilungen zuverlässig für Verwirrung.
Nehmen wir einen Agenten zur Schadensfall-Triage, der 20.000 Fälle pro Monat bearbeitet. Jeder Fall verbraucht etwa 6.000 Eingabe-Token (der Fall plus der abgerufene Kontext) und 800 Ausgabe-Token.
Dann folgt der Teil, der den Business Case tatsächlich entscheidet: das Engineering für die Aufnahme und Pflege des Dokumentenbestands sowie die Zeit, die Prüfer für den Aufbau und die Wartung des Evaluierungssets aufwenden. Diese Faktoren werden eher in Personenwochen als in Dollar pro Token gemessen und übersteigen im ersten Jahr in der Regel die Plattformkosten bei weitem.
Erstellen Sie Ihr eigenes Szenario mit dem Azure-Preisrechnerund betrachten Sie jede veröffentlichte Preisspanne – auch unsere – eher als Größenordnung denn als festes Budget. Die Unterschiede zwischen zwei nominell ähnlichen Implementierungen sind enorm und hängen fast ausschließlich vom Dokumentenvolumen und den Abfragemustern ab.
Nutzen Sie Microsoft Copilot , wenn Sie KI innerhalb von Microsoft 365, Dynamics oder GitHub benötigen und mit der Standardfunktionalität zufrieden sind. Es ist günstiger, schneller und erfordert kein eigenes Engineering-Team.
Nutzen Sie Azure AI Foundry , wenn mindestens zwei der folgenden Punkte zutreffen:
Nichts davon trifft zu? Kaufen Sie Copilot-Lizenzen und hören Sie auf zu lesen. Wir sagen Ihnen das lieber jetzt als nach einer Discovery-Phase.
.webp)
Governance ist der Grund, warum sich Unternehmen für Azure AI Foundry und gegen günstigere Alternativen entscheiden. Es ist aber auch der Punkt, an dem die meisten Prototypen scheitern. Vier Fragen entscheiden darüber, ob Ihre Lösung in Produktion geht.
Kann der Agent Dinge sehen, die dem Benutzer verborgen bleiben?Dies ist der Fehler, der Projekte zum Scheitern bringt. Ein Agent, der Dokumentenbestände indiziert und Fragen dazu beantwortet, kann Inhalte preisgeben, für die der fragende Benutzer keine Berechtigung hat. Die Lösung: Der Abruf muss Ihre bestehenden Berechtigungen respektieren, sodass der Agent die Zugriffsrechte des Benutzers erbt, anstatt selbst über pauschale Zugriffsrechte zu verfügen. Foundry unterstützt dies durch RBAC (rollenbasierte Zugriffskontrolle: Berechtigungen werden einer Rolle wie „Sachbearbeiter“ zugewiesen und nicht einzelnen Personen, sodass der Zugriff an die Funktion und nicht an die Person gebunden ist) und identitätsbewussten Abruf. Das geschieht nicht von allein. Sie müssen es von Anfang an einplanen.
Wer ist verantwortlich, wenn etwas schiefgeht?Entra Agent ID weist dem Agenten eine Verzeichnisidentität zu, wodurch seine Aktionen nachvollziehbar und widerrufbar werden. Ohne eine solche Identität wird „die KI war’s“ zu einem Audit-Befund, den Sie nicht entkräften können.
Wo liegen die Daten physisch und wer hat Zugriff darauf?Die Wahl des Modells beeinflusst die Datenresidenz. Foundry hostet viele Modelle direkt, aber für Modelle von Drittanbietern, die über den Katalog bezogen werden, gelten eigene Bedingungen. Wenn Sie unter EU-Datenresidenzanforderungen arbeiten, ist dies eine Frage der Beschaffung, nicht der Technik. Klären Sie das, bevor Sie sich für ein Modell entscheiden, und nicht erst, nachdem Sie darauf aufgebaut haben.
Was hält den Agenten davon ab, Schaden anzurichten?Inhaltsfilter, Guardrails und Interventionspunkte bei Prompts, Ausgaben und Tool-Aufrufen. Der wichtigste Interventionspunkt in einem Unternehmen ist der Tool-Aufruf: der Moment, in dem ein Agent aufhört zu antworten und beginnt, aktiv zu werden in einem System. Ein menschlicher Freigabeschritt an dieser Stelle ist meist der entscheidende Unterschied zwischen einer Genehmigung oder Ablehnung durch das Risikokomitee.
Und das Risiko, das niemand auf eine Folie schreibt? Schleichende Verschlechterung. Eine Modellversion wird aktualisiert, der Agent wird unbemerkt schlechter, und sechs Wochen lang merkt es niemand, weil es kein Evaluierungsset gibt. Genau deshalb erstellen wir ein solches, bevor wir irgendetwas anderes bauen.
Seit 2025 haben sich zwei Dinge so grundlegend verändert, dass ältere Anleitungen heute in die Irre führen.
Agenten-Orchestrierung. Microsoft hat seine beiden Agenten-Frameworks, AutoGen (das Multi-Agenten-Forschungsprojekt) und Semantic Kernel (das Enterprise-SDK), zum Microsoft Agent Frameworkzusammengeführt, das von denselben Teams entwickelt wurde. Es unterstützt zwei Orchestrierungsmodi, und die Wahl zwischen ihnen ist eine geschäftliche Entscheidung, die als technische getarnt ist.
Die Dokumentation von Microsoft enthält einen Satz, den man jedem Team vorlesen sollte, das sich übernimmt: Wenn Sie eine Funktion schreiben können, um die Aufgabe zu erledigen, schreiben Sie die Funktion, anstatt einen Agenten zu verwenden.
Multimodale Fähigkeiten. Foundry Tools decken Text, Dokumente, Bilder, Sprache und Video auf einer einzigen Plattform ab. In der Praxis bedeutet das, dass ein Schadensregulierer die Notizen des Gutachters, die PDF-Police und das Foto der verbeulten Motorhaube in einem einzigen Workflow verarbeiten kann, anstatt über drei Integrationen und eine Übergabe hinweg. Für dokumentenintensive Branchen liegt hier meist die eigentliche Zeitersparnis verborgen. Dies wird zudem chronisch unterschätzt, da sich Teams zu sehr auf Chatbots fixieren und die Suche einstellen.
Die meisten Implementierungs-Roadmaps bestehen aus denselben fünf Phasen, nur mit anderen Begriffen: Analyse, Design, Pilotierung, Skalierung, Optimierung. Sie sind nicht direkt falsch, aber sie liefern keine echten Erkenntnisse. Wir gehen anders vor.
Noch vor jeder Architektur nehmen wir uns 200 reale Fälle aus dem betreffenden Prozess vor und setzen uns mit dem Verantwortlichen zusammen, um zu definieren, wie eine korrekte Antwort aussieht. Das ist mühsam, aber es ist die wertvollste Woche des gesamten Projekts, denn sie liefert ein Evaluierungs-Framework: ein festes Set an realen Fällen mit bekannten korrekten Antworten, das bei jeder Änderung automatisch gegen den Agenten läuft. So können Sie belegen, dass sich das System verbessert hat, statt darüber zu diskutieren.
Überspringen Sie diesen Schritt, werden Sie sechs Monate später darüber streiten, ob der Agent schlechter geworden ist – rein nach Gefühl.
So sieht das Framework aus, das wir hinterlassen. Es ist bewusst nicht das Beispiel aus der Microsoft-Dokumentation, das nur einen Qualitätswert berechnet und eine Zahl ausgibt. Wir unterscheiden uns in drei Punkten, die jeweils aus Projekten stammen, in denen das Fehlen dieser Prüfungen uns teuer zu stehen kam. Wir prüfen drei Dimensionen statt nur einer. Wir lassen kein Modell das Eskalationsverhalten bewerten, denn die Frage „Hätte das an einen Menschen eskaliert werden müssen?“ müssen Sie gegenüber einer Aufsichtsbehörde rechtfertigen können, ohne zu sagen: „Das dachte ein anderes Modell auch.“ Zudem bricht der Build bei Fehlern ab, anstatt nur eine Warnung zu protokollieren, die niemand liest.
# eval_harness.py — IC pattern for Azure AI Foundry agents
# Runs on every model change, prompt change and index rebuild. Blocks the deploy.
import json, sys
from dataclasses import dataclass
from azure.ai.projects import AIProjectClient
from azure.identity import DefaultAzureCredential
# The golden set comes out of ground-truth week: real cases, labelled by the
# business owner who has to live with the output. Each record carries WHO
# labelled it and WHEN, because in 14 months someone will dispute a label,
# and "the business agreed" is not an answer.
GOLDEN_SET = "eval/golden_set.jsonl" # ~200 cases, versioned in git
BASELINE = "eval/baseline.json" # scores from the last shipped build
@dataclass
class Case:
id: str
payload: dict
expected_outcome: str # the label
must_escalate: bool # ground truth: does this REQUIRE a human?
visible_to: str # the requesting user's identity
@dataclass
class Result:
correct: bool
escalation_ok: bool # deterministic, not model-judged
permission_ok: bool # did it cite anything this user cannot see?
def evaluate(agent, case: Case) -> Result:
run = agent.run(case.payload, on_behalf_of=case.visible_to)
# Gate 1. Correctness. Model-judged is acceptable here, with a rubric.
correct = judge_outcome(run.outcome, case.expected_outcome)
# Gate 2. Escalation. NOT model-judged. The agent either handed off or it
# did not. Silent over-confidence on a must-escalate case is the failure
# that ends projects, and a fuzzy scorer will not catch it.
escalation_ok = (run.escalated == case.must_escalate)
# Gate 3. Permission integrity. Every citation the agent returned must be
# readable by the user who asked. This catches the leak BEFORE a user does.
permission_ok = all(
can_read(case.visible_to, source.id) for source in run.citations
)
return Result(correct, escalation_ok, permission_ok)
def main() -> int:
client = AIProjectClient(endpoint=FOUNDRY_ENDPOINT,
credential=DefaultAzureCredential())
agent = client.agents.get(AGENT_ID)
cases = [Case(**json.loads(line)) for line in open(GOLDEN_SET)]
results = [evaluate(agent, c) for c in cases]
scores = {
"accuracy": mean(r.correct for r in results),
"escalation": mean(r.escalation_ok for r in results),
"permission": mean(r.permission_ok for r in results),
}
baseline = json.load(open(BASELINE))
# Permission is absolute. One leak fails the build. There is no tolerance
# band here, and every client who argued for one later agreed.
if scores["permission"] < 1.0:
fail(f"PERMISSION LEAK on {count_failures(results)} case(s). Blocked.")
# Accuracy and escalation are graded against the LAST SHIPPED BUILD, not an
# absolute bar. Absolute bars get negotiated downward. Regressions do not.
for gate in ("accuracy", "escalation"):
drift = scores[gate] - baseline[gate]
if drift < -0.02: # 2pp regression tolerance
fail(f"{gate} regressed {drift:.1%} vs shipped build. Blocked.")
print(f"PASS {scores} (baseline {baseline})")
return 0
if __name__ == "__main__":
sys.exit(main())
Ein PoC beweist nur, dass die Technologie funktioniert. Dass sie funktioniert, wissen wir alle bereits. Deshalb bauen wir stattdessen einen schmalen Pfad direkt bis in die Produktion: ein Workflow, eine Datenquelle, echte Nutzer, echte Berechtigungen, ein echter Audit-Trail. Im Umfang bewusst bescheiden, in der Tiefe bewusst vollständig.
Der Punkt ist: So treten Integrations- und Governance-Probleme bereits in der dritten Woche auf, wenn sie noch kostengünstig zu beheben sind – und nicht erst im fünften Monat, wenn es teuer wird.
Entra Agent ID, RBAC, Content-Filter und der Eskalationspfad mit menschlicher Kontrolle werden bereits während des Thin Slice konfiguriert. Bei regulierten Kunden ist das nicht verhandelbar. Bei unregulierten Kunden sorgt es dafür, dass der zweite und dritte Anwendungsfall nicht genauso viel kosten wie der erste.
Das Test-Framework aus Stufe 1 kontrolliert jede Freigabe. Kein Agent erweitert seinen Aufgabenbereich, bevor er nicht die Hürde bei bisher unbekannten Fällen genommen hat. Genau das unterscheidet eine strukturierte Flotte von einem unkontrollierten Chaos.
Wir übergeben Ihrem Team nicht nur den Code, sondern auch das Evaluierungs-Framework und das Runbook. Ein Partner, der für jedes Modell-Update erneut hinzugezogen werden muss, hat seine Arbeit nicht zu Ende gebracht.
Für einen einzelnen, klar definierten Workflow dauert die technische Umsetzung bis zu einem produktiven „Thin Slice“ nur wenige Wochen. Doch der eigentliche Engpass ist fast nie die Technik. Ein realistischer Zeitplan sieht so aus.
Die Zeile für die Sicherheitsprüfung ist der Punkt, an dem zwei identische Projekte um ein ganzes Quartal auseinanderdriften können. Fragen Sie daher jeden potenziellen Partner, welche Annahmen seinem Zeitplan über Ihr Unternehmen zugrunde liegen – und seien Sie skeptisch bei jedem, der antwortet, bevor er sich Ihre Datenlandschaft angesehen hat.
Der Funktionsvergleich ist weitaus weniger wichtig, als die Anbieter es gerne hätten. In der Praxis wurde die Entscheidung für Sie bereits vor Jahren durch zwei Faktoren getroffen: wo Ihre Daten liegen und wo Ihr Identitätsmodell läuft. Vergleichen wir sie dennoch, da Sie ohnehin danach gefragt werden.
| Funktion | Azure AI Foundry | AWS Bedrock | Google Vertex AI |
|---|---|---|---|
| Stärken bei | Ihre Organisation nutzt Microsoft: Entra, M365, Fabric, Dynamics | Ihre Daten und Workloads befinden sich bereits in AWS | Ihr Data Engineering nutzt bereits BigQuery |
| Governance-Modell | Verzeichnisnativ (Entra Agent ID, RBAC). Das stärkste der drei für regulierte Unternehmen | Solides IAM, dünnere Agenten-Governance-Schicht | Starke ML-Tools, Governance weniger agentenzentriert |
| Am besten für | Agenten-Flotten unter gemeinsamer Governance | Modellzugriff und -vielfalt | Echte ML-Experimente statt Agenten-Zusammenstellung |
| Achten Sie auf | Rebranding-Veränderungen und Migrationsfristen | Enterprise-Governance erfordert mehr Aufwand beim Aufbau | Am wenigsten geeignet, wenn Ihre Belegschaft M365 nutzt |
Hier ist der strategische Punkt, der wichtiger ist als der technische. Die Wahl der Plattform, auf der Ihre Daten nicht liegen, nur weil sie in einer Funktionsmatrix besser abgeschnitten hat, ist eine Entscheidung, für die Sie in den nächsten fünf Jahren jedes Quartal mit Integrationsaufwand bezahlen werden. Die Integrationssteuer summiert sich. Funktionslücken schließen sich.
Das führt zu einer etwas unangenehmen Erkenntnis. Wenn Sie ein Microsoft-Unternehmen sind, ist die Plattformfrage weitgehend bereits beantwortet, und die eigentliche Arbeit besteht in der oben genannten Frage der Bereitschaft. Drei Monate Anbieter-Vergleich sind oft drei Monate, in denen man dem schwierigeren Gespräch ausweicht.
Microsofts einheitliche Plattform für die Entwicklung, Bereitstellung und Verwaltung von KI-Anwendungen und Agenten. Sie fungiert als übergeordnete Ebene für Azure OpenAI Service, Azure AI Search und Azure Machine Learning und bietet eine zentrale Steuerung, ein einheitliches Identitätsmodell sowie einen zentralen Ort zur Überwachung Ihrer Agenten.
Für die Plattform selbst fallen keine Lizenzgebühren an; Sie können Projekte erstellen und die Funktionen kostenfrei erkunden. Sie bezahlen lediglich für die zugrunde liegenden Dienste: Modellinferenz (Token), Azure AI Search, Speicher, Rechenleistung und Überwachung. Der Einstieg ist also kostenlos, der Betrieb jedoch nicht. Die Kosten werden auf Ihrer Azure-Rechnung unter den Namen der jeweiligen Einzeldienste ausgewiesen, nicht unter „Foundry“.
Azure OpenAI Service ist eine einzelne Komponente, während Azure AI Foundry die Plattform darstellt, die diese umgibt. Der OpenAI Service stellt Ihnen Modell-Endpunkte bereit; Foundry ergänzt dies um einen Modellkatalog (einschließlich Modellen von Drittanbietern wie Anthropic Claude), Agenten-Tools, Retrieval, Evaluierung, Observability und Governance. Wenn Sie lediglich einen Modell-Endpunkt benötigen, ist Foundry nicht erforderlich. Wenn Sie jedoch Agenten produktiv einsetzen und deren Aktivitäten nachvollziehbar machen müssen, ist Foundry die richtige Wahl.
Nutzen Sie Copilot, wenn Sie KI in Microsoft 365, Dynamics oder GitHub integrieren möchten und mit der Standardfunktionalität zufrieden sind, da Copilot ein fertiges Produkt ist. Nutzen Sie Azure AI Foundry, wenn Sie eine spezifische Lösung für Ihr Unternehmen entwickeln, auf eigene Daten unter Einhaltung Ihrer Berechtigungsstrukturen zugreifen oder regulatorische Anforderungen erfüllen müssen. Foundry ist eine Plattform zur Entwicklung von Produkten – und Sie sollten keine Plattform kaufen, um ein Problem zu lösen, für das es bereits ein fertiges Produkt gibt.
Ja. Microsoft hat die Umbenennung auf der Ignite im November 2025 bekannt gegeben, und die Produktbedingungen vom Januar 2026 haben dies formalisiert. In Ihren Verträgen und internen Dokumentationen können beide Bezeichnungen vorkommen.
Modell-Endpunkte sind REST-APIs, daher können sie von jeder Sprache aus aufgerufen werden. Für die Agentenentwicklung unterstützt das Microsoft Agent Framework derzeit Python und C#/.NET, wobei Microsoft zugesichert hat, dass beide Sprachen zum Zeitpunkt der allgemeinen Verfügbarkeit gleichwertig unterstützt werden. Wenn Ihr Entwicklungsteam hauptsächlich mit Java, Go oder TypeScript arbeitet, ist das Tooling für Agenten weniger ausgereift; dies sollten Sie vor einer Entscheidung prüfen. Es handelt sich um eine echte Einschränkung, die im Marketing kaum thematisiert wird.
Ihre bestehenden Inferenz-Workloads laufen weiter, die Umbenennung erfordert also keine Migration. Die Fristen sind jedoch verbindlich. Der Support für das Azure ML SDK v1 endet am 30. Juni 2026, und der Support für die CLI v1 ist bereits im September 2025 ausgelaufen, gemäß Microsofts offiziellen Migrationsrichtlinien. Alles, was auf azureml-sdk basiert, benötigt jetzt einen Plan. Auch die Assistants API wird eingestellt; prüfen Sie daher das aktuelle Datum in Microsoft Learn, bevor Sie Ihre Planung darauf ausrichten.
Vier, in der Reihenfolge, in der sie typischerweise kritisch werden. Berechtigungslecks, bei denen ein Agent Inhalte anzeigt, die der anfragende Benutzer niemals sehen dürfte. Stille Verschlechterung, bei der die Leistung eines Agenten nach einem Modell-Update unbemerkt nachlässt, ohne dass dies durch ein Evaluierungs-Set erkannt wird. Plattform-Fluktuation, denn zwei Rebrandings innerhalb von zwölf Monaten und tatsächliche Deprecation-Fristen führen dazu, dass Dokumentationen und Schulungen schnell veralten. Und Kostenanstieg, da der Token-Verbrauch mit der Nutzung skaliert und ohne Modell-Routing schneller wächst als der Mehrwert. Alle vier Punkte sind beherrschbar. Keiner davon wird standardmäßig verwaltet.
Ein produktiver „Thin Slice“, also ein Workflow mit echten Benutzern und echter Governance, erfordert einige Wochen Entwicklungszeit. Die tatsächliche Dauer ist meist länger, wobei der entscheidende Faktor intern liegt: Sicherheitsüberprüfungen und die Genehmigung des Datenzugriffs dauern routinemäßig zwei bis sechs Wochen und sind der größte Zeitfresser. Seien Sie vorsichtig bei Zeitplänen, die genannt werden, bevor jemand Ihre Datenlandschaft geprüft hat.
Einen Plattform-Ingenieur, der für das Azure-Abonnement und das Identitätsmodell verantwortlich ist, einen benannten Business Owner pro Anwendungsfall sowie eine Einbindung der Compliance-Abteilung vor Beginn der Entwicklung statt erst bei der Abnahme. Wenn Sie die Person nicht benennen können, die den Output des Agenten akzeptiert oder ablehnt, sind Sie noch nicht bereit. Das ist jedoch ein Problem, das sich in vier Wochen lösen lässt, nicht in vier Monaten.
Es funktioniert. Aber die Wirtschaftlichkeit spricht für Unternehmen, die mehr als einen KI-Workload betreiben, da der Wert der Plattform darin liegt, viele Agenten zentral zu steuern, anstatt jeden einzeln. Bei einem einzelnen Anwendungsfall existiert dieser Vorteil noch nicht.
Der Vorteil von Azure AI Foundry liegt in der Governance, nicht in der reinen Leistungsfähigkeit, denn jede große Plattform kann auf leistungsstarke Modelle zugreifen. Foundry bietet Ihnen eine ganze Flotte von Agenten, die unter einem einheitlichen Regelwerk laufen. Deshalb amortisiert sich die Investition erst beim zweiten oder dritten Anwendungsfall, nicht beim ersten.
Die Rechnung ist keine Lizenzgebühr, denn es gibt keine Lizenz. Es geht um Tokens, Retrieval, Ingestion und Personal – wobei Ingestion der Punkt ist, den niemand im Budget einplant. Alles andere wird entschieden, bevor die erste Zeile Code geschrieben wird, und zwar durch vier unspektakuläre Voraussetzungen: erreichbare Daten, ein benannter Entscheidungsträger, ein Governance-Konzept und ein Team, das bereit ist, seine Arbeitsweise zu ändern.
Ist die Plattform die größte Hürde? Nein, natürlich nicht. Die größte Hürde sind Sie selbst.
Bewerten Sie sich anhand des Foundry Readiness Model. Wenn Sie sich in der Phase Erkundungbefinden, ist es das Nützlichste, was wir für Sie tun können, dies offen auszusprechen. Und wenn Sie eine zweite Meinung dazu wünschen, wo Sie tatsächlich stehen, oder wenn Sie einen Prototyp haben, der es einfach nicht in die Produktion schafft und Sie nicht wissen, warum, sprechen Sie mit uns.
Alexandra Mendes ist Senior Growth Specialist bei Imaginary Cloud und verfügt über mehr als 3 Jahre Erfahrung in der Erstellung von Texten über Softwareentwicklung, KI und digitale Transformation. Nach Abschluss eines Frontend-Entwicklungskurses erwarb Alexandra einige praktische Programmierkenntnisse und arbeitet nun eng mit technischen Teams zusammen. Alexandra ist begeistert davon, wie neue Technologien Wirtschaft und Gesellschaft prägen. Sie liebt es, komplexe Themen in klare, hilfreiche Inhalte für Entscheidungsträger umzuwandeln.
Inês Silva ist eine Projektmanagerin mit über vier Jahren Erfahrung im Schreiben über Software-Bereitstellung, agile Methoden und Tech-Leadership. Da sie ihre Karriere als Entwicklerin begann, bringt Inês ein echtes, tiefgreifendes technisches Verständnis in die Management-Seite ein. Sie liebt es, die Lücke zwischen übergeordneter Geschäftsstrategie und der täglichen technischen Umsetzung zu schließen, und sie teilt leidenschaftlich gerne praktische Tipps, die Teams helfen, besser zusammenzuarbeiten und großartige Produkte zu liefern.
People who read this post, also found these interesting:
-%2520Survey%2520Insights.webp)
