KI-Anwendungen mit Azure sicher skalieren: Ein Leitfaden für den Mittelstand

Eine KI-Demo ist schnell gebaut. Eine produktive KI-Anwendung ist etwas anderes. Das merkt man spätestens dann, wenn nicht mehr zehn Testfragen im Browser gestellt werden, sondern echte Mitarbeitende mit echten Dokumenten arbeiten. Dann zählen andere Fragen: Wer darf worauf zugreifen? Was passiert, wenn 500 Dokumente gleichzeitig verarbeitet werden? Wer sieht, wenn die Kosten explodieren? Und warum antwortet das Modell plötzlich mit HTTP 429?

Genau an dieser Stelle entscheidet sich, ob ein KI-Projekt ein Pilot bleibt oder im Unternehmen wirklich genutzt wird. Dieser Leitfaden zeigt, wie man KI-Anwendungen auf Microsoft Azure so aufbaut, dass sie sicher, skalierbar und kontrollierbar bleiben. Nicht als theoretische Cloud-Architektur, sondern als pragmatischer Rahmen für mittelständische Unternehmen, die mit Microsoft 365, Teams, SharePoint und Azure bereits eine gute Grundlage haben.

Eine produktionsreife KI-Anwendung auf Azure braucht sieben Bausteine: Identität über Microsoft Entra ID statt API-Keys, Queue-basierte Verarbeitung mit Azure Service Bus, skalierbare Worker über Azure Container Apps Jobs, Budgets und Kostenwarnungen mit sauberem Tagging, Monitoring über Log Analytics und Application Insights, aktives Rate-Limit-Management für Tokens und Requests sowie eine klare Datenschutz- und Regionsstrategie für EU-Datenhaltung.

Wenn einer dieser Bausteine fehlt, funktioniert die Anwendung oft trotzdem in der Demo. Im Betrieb wird sie aber schwer wartbar, teuer oder riskant.

Ein typisches Mittelstandsprojekt ist ein KI-Wissensassistent für Service- und Montageteams. Das Problem dabei ist konkret: Reparaturwissen steckt in Köpfen, verstreuten Dateien und informellen Rückfragen. Neue Mitarbeitende und Monteure brauchen Antworten direkt im Arbeitsfluss, ohne sich dabei durch mehrere Telefonate kämpfen zu müssen.

Eine sinnvolle Zielarchitektur sieht so aus: SharePoint dient als Wissensbasis. Microsoft Teams ist die Oberfläche für Mitarbeitende. Azure OpenAI beantwortet Fragen auf Basis indexierter Dokumente, ein RAG-Backend sucht dafür die relevanten Inhalte heraus. Azure-Ressourcen laufen in einer dedizierten Ressourcengruppe, Zugriff läuft über Microsoft Entra ID und definierte Gruppen.

Technisch klingt das beherrschbar. Die eigentliche Herausforderung liegt im Betrieb: Die Anwendung muss Dokumente regelmäßig indexieren, Benutzerrechte respektieren, Kosten kontrollieren, Fehler sichtbar machen und Lastspitzen abfangen. Genau dafür braucht es eine durchdachte Azure-Architektur.

Viele KI-Prototypen starten mit einem API-Key. Das ist bequem, aber für den produktiven Betrieb eine schlechte Grundlage. Ein API-Key ist wie ein geteilter Generalschlüssel: Wer ihn besitzt, kann den Dienst nutzen, und es ist kaum nachvollziehbar, welche Anwendung oder Person ihn verwendet hat. Wenn ein Entwickler das Team verlässt oder ein Key versehentlich in Logs oder Repositories auftaucht, bleibt oft nur Rotation und Schadensbegrenzung.

Für produktive Azure-KI-Anwendungen sollte der Zugriff über Microsoft Entra ID laufen. Anwendungen auf Azure erhalten eine Managed Identity, externe Dienste nutzen einen klar begrenzten Service Principal, Rollen werden nach dem Least-Privilege-Prinzip vergeben, und Zugriffe sind auditierbar. API-Keys werden deaktiviert.

Für Azure OpenAI und Azure AI Foundry ist das kein Sonderweg, sondern die Richtung, in die Microsoft die Plattform entwickelt. In neueren Setups ist lokale API-Key-Authentifizierung teilweise bereits deaktiviert. Wer dann weiter mit Keys arbeitet, bekommt Fehler wie AuthenticationTypeDisabled: disableLocalAuth is set to true. Das ist kein Fehler der Plattform, sondern ein klarer Hinweis: Die Architektur muss auf Entra ID umgestellt werden.

KI-Anwendungen haben oft ein ungleichmäßiges Lastprofil. Tagsüber stellen Mitarbeitende einzelne Fragen. Nachts werden Dokumente indexiert. Nach einem großen Upload müssen plötzlich 200 PDFs verarbeitet werden. Passiert diese Arbeit direkt in einer Web-App, entstehen Timeouts, hohe Latenzen und schwer nachvollziehbare Fehler.

Besser ist eine Queue-basierte Architektur: Ein Dokument-Upload legt eine Aufgabe in eine Azure Service Bus Queue. Ein KEDA Scaler beobachtet die Queue und startet bei Bedarf Azure Container Apps Jobs. Diese Worker holen die Aufgabe ab, verarbeiten das Dokument, erzeugen Embeddings und aktualisieren den Index in pgvector.

Azure Container Apps Jobs eignen sich dafür besonders gut. Sie starten bei Bedarf, verarbeiten Nachrichten und stoppen danach wieder. Wenn keine Arbeit anliegt, laufen keine Worker. Das reduziert Kosten und macht Lastspitzen beherrschbar. Für einen Teams-Wissensassistenten heißt das: Wenn neue Serviceanleitungen in SharePoint landen, wird ein Indexierungsjob ausgelöst. Der Bot bleibt schnell, während die schwere Arbeit im Hintergrund läuft.

KI-Kosten verhalten sich anders als klassische Serverkosten. Ein Container, der nicht läuft, kostet wenig bis nichts. Ein fehlerhafter Prompt, eine Endlosschleife oder ein zu großzügig gesetztes max_tokens kann dagegen sehr schnell Kosten erzeugen. Gerade bei Azure OpenAI entstehen viele Kosten nicht durch Laufzeit, sondern durch Tokens.

Budgets und Kostenwarnungen gehören deshalb von Anfang an dazu: getrennte Budgets für Entwicklung und Produktion, auf Ressourcengruppen-Ebene definiert. Ressourcen werden mit Tags für Project, Environment und Owner versehen. Warnungen greifen bei 70 Prozent der prognostizierten Kosten, bei 85 Prozent der tatsächlichen Kosten und eskalieren bei 100 Prozent. Azure Cost Anomaly Alerts erkennen ungewöhnliche Verbrauchsspitzen.

Wichtig dabei: Ein Budget stoppt keine Ressource automatisch. Es warnt nur. Wer bei Überschreitung automatisch reagieren will, braucht eine Action Group, zum Beispiel mit einer Logic App, einer Teams-Nachricht oder einem Automation Runbook. Für Mittelstandsprojekte ist das kein Luxus. Es schafft Vertrauen.

Eine KI-Anwendung kann äußerlich erreichbar sein und trotzdem fachlich versagen: Der Bot antwortet, aber auf Basis falscher Dokumente. Die Indexierung läuft nicht mehr. Die Queue wächst. Das Modell liefert 429-Fehler. Ein Container startet immer wieder neu. Ohne Monitoring fällt das oft erst auf, wenn Nutzende sich beschweren.

Azure bringt die passenden Bausteine mit: Log Analytics für zentrale Logs, Azure Monitor für Metriken und Alerts, Application Insights für Latenz, Fehlerraten und Durchsatz, Service-Bus-Metriken für Queue-Tiefe und Dead-Letter-Nachrichten sowie Container-Apps-Logs für Worker-Fehler und Neustarts.

Für KI-Anwendungen sollten mindestens diese Signale überwacht werden: Die Fehlerrate der Modellaufrufe zeigt Auth-, Quota- oder Modellprobleme. Hohe Latenz weist auf Überlast oder langsame Retrieval-Schritte hin. HTTP-429-Fehler zeigen Rate-Limiting. Eine wachsende Queue-Tiefe zeigt, ob Jobs schneller eingehen als verarbeitet werden. Dead-Letter-Nachrichten zeigen wiederholt fehlgeschlagene Aufgaben. Und der Token-Verbrauch zeigt, wo Kosten und Prompt-Probleme entstehen.

Eine wichtige Unterscheidung: Wenn die Queue-Tiefe steigt und gleichzeitig HTTP-429-Fehler auftreten, liegt kein Infrastrukturproblem vor. Die Anwendung schlägt gegen das Modelllimit, und mehr Container helfen dabei nicht weiter.

Azure OpenAI skaliert nicht unbegrenzt. Jedes Modell-Deployment hat Limits für Tokens per Minute und Requests per Minute. Diese Limits gelten pro Subscription, Region und Modell. Wenn sie überschritten werden, antwortet die API mit HTTP 429. Das ist normales Rate-Limiting, kein Ausfall.

Der wichtigste Fallstrick dabei: Die Limit-Berechnung orientiert sich nicht nur an tatsächlich erzeugten Antworttokens, sondern berücksichtigt auch das konfigurierte Maximum. Wer max_tokens pauschal auf 4.000 setzt, obwohl real meist 300 Tokens gebraucht werden, verbraucht unnötig viel Kapazität gegen das Minutenlimit.

Praktische Maßnahmen: max_tokens realistisch setzen, Retry mit exponential backoff implementieren, Rate-Limit-Header auslesen und monitoren, parallele Worker begrenzen und Quotas vor dem Go-Live prüfen. Bei konstant hoher Last lohnt es sich, Provisioned Throughput früh zu evaluieren, bevor der erste Engpass im Betrieb auftritt.

Für deutsche Mittelständler ist die technische Skalierbarkeit nur eine Seite. Die andere Seite ist Datenhaltung. Die wichtigsten Fragen kommen fast immer: In welcher Region liegen die Daten? Werden Eingaben zum Training verwendet? Wer kann auf Dokumente zugreifen? Werden personenbezogene Daten in Queues gespeichert? Können Zugriffe später nachvollzogen werden?

Für Azure-Projekte im deutschen Mittelstand ist Germany West Central meist die naheliegende Primärregion. Alternativ kommt West Europe infrage, wenn bestimmte Modelle oder Dienste dort besser verfügbar sind. Die Region sollte nicht zufällig gewählt werden. Ein späterer Wechsel ist aufwendig.

Bei RAG-Anwendungen sollte außerdem sauber getrennt werden: Dokumente liegen in SharePoint oder Blob Storage, die Queue enthält möglichst nur Referenzen und Metadaten, Zugriffe werden über Entra ID und Gruppen gesteuert, und Logs enthalten keine Prompts mit sensiblen Inhalten.

Gerade beim Teams-Wissensassistenten ist das entscheidend. Mitarbeitende erwarten, dass der Bot nur auf freigegebene Informationen zugreift. Ein KI-System darf keine Abkürzung um bestehende Berechtigungen herum sein.

Frameworks wie LangChain, LangGraph, Semantic Kernel oder Azure AI Foundry Prompt Flow können viel Entwicklungsarbeit sparen. Sie helfen bei Dokumentenverarbeitung, Chunking, Embeddings, Retrieval, Prompt-Templates, Tool-Aufrufen, Retry-Logik, Agenten-Orchestrierung sowie Tracing und Evaluation.

Für Azure-nahe Projekte sind drei Optionen besonders relevant: LangChain und LangGraph eignen sich für Python-Teams mit RAG-Anforderungen und flexibler Orchestrierung. Semantic Kernel und das Microsoft Agent Framework sind stark in .NET-Teams und Azure-nativen Architekturen. Azure AI Foundry Prompt Flow ermöglicht nachvollziehbare KI-Pipelines direkt in Foundry.

Der Fehler liegt nicht darin, Frameworks zu nutzen. Er liegt darin, Geschäftslogik tief in Framework-spezifischen Abstraktionen zu verstecken. Eine robuste Architektur trennt Domänenlogik, Datenzugriff, Modellzugriff, Orchestrierung und Observability klar voneinander. Dann kann ein Projekt wachsen, ohne dass jedes Framework-Update zur Migration wird.

Eine pragmatische Architektur für einen Teams-basierten Wissensassistenten verbindet mehrere Azure-Dienste zu einem kohärenten System. Für die Nutzerinteraktion: Microsoft Teams als Oberfläche, Azure Bot Service als Brücke, eine Backend-API für die Anwendungslogik, Azure OpenAI für die Sprachverarbeitung, pgvector als Vektorindex für die Wissenssuche sowie SharePoint oder Blob Storage für die Dokumente.

Für die Hintergrundverarbeitung: SharePoint-Uploads lösen Events oder geplante Trigger aus, die Aufgaben in Azure Service Bus ablegen. Azure Container Apps Jobs verarbeiten diese Aufgaben: Dokumentenverarbeitung, Embedding-Erzeugung und Index-Aktualisierung in pgvector.

Querschnittsfunktionen gelten für das gesamte System: Microsoft Entra ID und Managed Identity für Zugriffskontrolle, Log Analytics und Application Insights für Observability, Azure Budgets und Monitor Alerts für Kosten und Betrieb.

Diese Architektur ist bewusst nicht maximal komplex. Sie nutzt Dienste, die in Azure gut integriert sind, vermeidet eigene Infrastruktur dort, wo sie keinen Mehrwert bringt, und lässt sich Schritt für Schritt erweitern.

Zugriff und Identität: Läuft der Zugriff über Entra ID statt API-Key? Hat jede Anwendung eine eigene Managed Identity? Sind Rollen nach Least Privilege vergeben? Sind API-Keys deaktiviert oder bewusst begrenzt?

Verarbeitung und Fehlertoleranz: Werden schwere Jobs über Service Bus und Worker verarbeitet? Gibt es eine Dead-Letter-Strategie?

Kosten und Monitoring: Sind Budgets und Kostenwarnungen aktiv? Sind Ressourcen sauber getaggt? Gibt es Alerts für Fehlerrate, Latenz, Queue-Tiefe, 429-Fehler und Token-Verbrauch? Sind Logs frei von sensiblen Prompts und Dokumentinhalten?

Betrieb und Compliance: Ist die Azure-Region bewusst gewählt? Sind Rate Limits und Quotas vor dem Go-Live geprüft? Gibt es Retry-Logik mit exponential backoff? Gibt es eine klare Betriebsverantwortung? Wenn diese Punkte ungeklärt sind, ist der Pilot noch kein produktionsreifes System.

Viele KI-Projekte behandeln Skalierung als etwas, das nach dem erfolgreichen Pilot kommt. Das ist riskant. Bei KI-Anwendungen entscheidet die Architektur sehr früh darüber, ob das System später sicher betrieben werden kann.

API-Keys, fehlende Queues, fehlende Budgets, fehlendes Monitoring und ignorierte Token-Limits wirken im Pilot harmlos. Im Betrieb werden sie zu echten Problemen. Die gute Nachricht: Auf Azure sind die notwendigen Bausteine vorhanden. Entra ID, Service Bus, Container Apps, Azure Monitor, Log Analytics, Budgets und Azure OpenAI ergeben zusammen eine robuste Plattform für KI-Anwendungen im Mittelstand.

Ein Teams-Assistent, der heute zehn Fragen beantwortet, kann morgen zum zentralen Wissenssystem für Service, Vertrieb oder Support werden. Gute Antworten allein genügen dafür nicht. Sicherer, nachvollziehbarer und kontrollierbarer Betrieb gehört genauso dazu. Das ist der Unterschied zwischen KI-Demo und KI-Anwendung.