# Azure AI Gateway Decision Kit ## Entscheidungsmatrix für direkten Modellzugriff, gemeinsames Gateway und zentrale Kontrollschicht **Unabhängige Arbeitsvorlage — keine Microsoft-Publikation und keine Produktempfehlung.** Dieses Kit hilft Teams, eine konkrete Architekturfrage vorzubereiten: Reicht der direkte Zugriff auf Modellendpunkte derzeit aus, oder sollten wir ein gemeinsames AI Gateway beziehungsweise eine zentrale kontrollierte Modellzugangsschicht näher prüfen? Es ist für Azure-geprägte Organisationen mit mehreren geplanten oder bestehenden KI-Anwendungen gedacht. Es entscheidet **nicht** über Security, Compliance, Datenschutz, Produktionsfreigabe, Anbieterwahl oder eine kundenspezifische Zielarchitektur. Halten Sie für die Anwendung grob fest: betroffene Anwendungen und technische Clients, Modell- und Providerpfade, Zugriffsmuster, wiederkehrende Regeln, Ausfall- und Drosselungserfahrungen sowie die heute verfügbaren Nutzungs-, Kosten- und Betriebssignale. ## 1. Die drei Muster im Vergleich | Kriterium | Direkter Modellzugriff | Gemeinsames AI Gateway | Zentrale Kontroll- und Evidenzschicht | | --- | --- | --- | --- | | Clients | Wenige, gut steuerbare Clients | Mehrere Clients mit ähnlichen Zugangspfaden | Wachsende oder heterogene Clientlandschaft mit gemeinsamen Verantwortlichkeiten | | Modelle und Provider | Wenige stabile Endpunkte | Mehrere Bereitstellungen oder Wechselpfade sollen zentral geroutet werden | Mehrere Modelle, Provider oder Umgebungen benötigen einen gemeinsamen Steuerungsrahmen | | Authentifizierung und Zugangsdaten | Je Client überschaubar verwaltbar | Clientzugang und Backendzugang sollen getrennt geprüft werden | Identitätsmuster, Berechtigungen und Verantwortlichkeiten müssen übergreifend nachvollziehbar bleiben | | Gemeinsame Guardrails | Wenige Regeln, lokal vertretbar | Wiederkehrende Regeln sollen an einer Stelle angewendet werden | Gemeinsame Kontrollen brauchen einen nachvollziehbaren Owner und Änderungsweg | | Quoten und Rate Limits | Lokal ausreichend steuerbar | Grenzen und Drosselungsreaktionen sollen konsistent behandelt werden | Grenzwerte, Ausnahmewege und Evidenz müssen bereichsübergreifend erklärbar sein | | Routing und Resilienz | Client kann Endpunktwahl und Fehlerbehandlung tragen | Routing, Wiederholung oder Failover sollen nicht je Client neu entstehen | Architekturentscheidungen zu Backends, Ausfällen und Änderungen brauchen gemeinsame Evidenz | | Nutzungs- und Kostenzuordnung | Direkte Zuordnung ist bereits möglich | Nutzung pro Client oder Use-Case soll über mehrere Backends sichtbar werden | Portfolio-, Use-Case- und Betriebssignale sollen zusammenhängend eingeordnet werden | | Observability und Evidenz | Einzelne Signale genügen den Verantwortlichen | Fehler, Latenz und Routing sollen zentral zusammengeführt werden | Nachvollziehbarkeit für Plattform-, Security-, FinOps- und Use-Case-Owner wird gemeinsam benötigt | | Betriebsverantwortung | Ein Team kann Muster und Änderungen tragen | Ein klarer Gateway-Owner kann wiederkehrende Aufgaben tragen | Verantwortlichkeiten, Änderungs- und Evidenzwege müssen explizit abgestimmt werden | | Änderungs- und Onboarding-Häufigkeit | Selten und kontrollierbar | Wiederkehrende Konfigurationsänderungen oder neue Clients | Häufige neue Use-Cases, Modelle oder Owner führen sonst zu Fragmentierung | Keines dieser Muster ist pauschal richtig oder falsch. Ein Gateway fügt auch eine Betriebs-, Leistungs- und Zuverlässigkeitskomponente hinzu. Direkter Zugriff bleibt deshalb sinnvoll, wenn er einfacher steuerbar ist als die neue Schicht. ## 2. Zwölf Entscheidungsfragen Notieren Sie pro Frage eine kurze Beobachtung: **heute klar**, **uneinheitlich** oder **unbekannt**. Die Fragen verlangen keine vertraulichen Daten. 1. Wie viele Anwendungen oder technische Clients greifen heute oder im nächsten Planungsabschnitt auf Modellendpunkte zu? 2. Greifen diese Clients auf dieselbe Modellbereitstellung, mehrere Bereitstellungen oder mehrere Providerpfade zu? 3. Werden Zugangsdaten oder direkte Berechtigungen an mehrere Anwendungen verteilt? 4. Kann ein Client einen Modellendpunkt außerhalb eines vorgesehenen Kontrollpunkts direkt erreichen? 5. Müssen Limits, Inhaltsfilter oder andere technische Guardrails für mehrere Anwendungen konsistent gepflegt werden? 6. Wo wird entschieden, welches Modell oder welcher Provider für eine Anfrage verwendet wird, und wie wird diese Entscheidung geändert? 7. Wie wird heute reagiert, wenn ein Modellendpunkt drosselt, nicht erreichbar ist oder eine Anfrage fehlschlägt? 8. Müssen Gespräche oder andere zustandsbehaftete Abläufe an dieselbe Modellbereitstellung gebunden bleiben? 9. Kann Nutzung einem Use-Case, einer Anwendung oder einem verantwortlichen Bereich zugeordnet werden, auch wenn mehrere Backends beteiligt sind? 10. Wo werden Fehler-, Latenz-, Volumen- und Routingsignale zusammengeführt? 11. Wer verantwortet wiederkehrende Änderungen an Zugängen, Regeln, Routing und Ausnahmewegen? 12. Wie oft kommen neue Use-Cases, Clients, Modelle, Provider oder Verantwortliche hinzu, und beginnt die Entscheidung jeweils neu? ## 3. Ergebnisinterpretation: Signalmuster statt Punktzahl ### Direkter Zugriff ist derzeit wahrscheinlich ausreichend Dieses Muster passt eher, wenn es wenige gut steuerbare Clients gibt, die Endpunkte stabil sind, lokale Zugangsmuster klar bleiben und Clientteams Routing, Fehlerbehandlung sowie Signale belastbar tragen können. **Nächste interne Fragen:** Welche Änderungen stehen realistisch an? Welche direkten Zugänge müssen dokumentiert bleiben? Ab welchem zusätzlichen Client würde die lokale Pflege unverhältnismäßig? **Einbeziehen:** verantwortliches Anwendungsteam, Plattform- oder Cloud-Architektur und bei Bedarf der Modellhost-Owner. **Noch fehlende Informationen:** tatsächliche Änderungsfrequenz, geplante neue Backends und die Zuverlässigkeit der vorhandenen Nutzungs- und Betriebssignale. ### Ein gemeinsames Gateway sollte näher geprüft werden Dieses Muster wird wahrscheinlicher, wenn mehrere Clients unterschiedliche Modellbereitstellungen nutzen, wiederkehrende Regeln oder Grenzen je Anwendung neu umgesetzt werden, Routingwechsel schwer kontrollierbar sind oder Fehlerbehandlung mehrfach entsteht. **Nächste interne Fragen:** Welche Aufgaben sollen wirklich zentralisiert werden? Welche Clientverträge müssen kompatibel bleiben? Welche Backends dürfen bei welchem Ereignis als Alternative dienen? Wo entstehen neue Abhängigkeiten oder Latenz? **Einbeziehen:** Plattformteam, Cloud- und Enterprise-Architektur, Anwendungsverantwortliche sowie Security- und Netzwerkverantwortliche für die tatsächliche Zugriffskette. **Noch fehlende Informationen:** Clientfähigkeiten, Modellkompatibilität, Netzwerkpfade, Drosselungsverhalten und ein testbarer Änderungs- und Rückfallplan. ### Eine zentrale Kontroll- und Evidenzschicht ist als Zielbild prüfenswert Dieses Muster wird wahrscheinlicher, wenn viele Teams, Clients oder Providerpfade beteiligt sind, Zugänge und Regeln fragmentiert sind, Nutzung und Kosten nicht nachvollziehbar zugeordnet werden können und mehrere Owner einen gemeinsamen Steuerungs- und Evidenzweg benötigen. **Nächste interne Fragen:** Welche gemeinsamen Kontrollen sind tatsächlich erforderlich? Welche Evidenz wird für Plattform, FinOps, Security und Use-Case-Owner gebraucht? Wer darf Änderungen freigeben, betreiben und nachvollziehen? **Einbeziehen:** AI Platform Owner, Enterprise Architecture, Cloud Platform, Security, FinOps und die wichtigsten Use-Case-Owner. **Noch fehlende Informationen:** verbindliche Verantwortungsgrenzen, Daten- und Netzwerkvorgaben, erwartete Onboarding-Frequenz, Metrikbedarf und die Kosten sowie der Betrieb der zusätzlichen Schicht. ## 4. Internes Decision Brief **Bestehende Use-Cases und Clients** - Betroffene Anwendungen oder technischen Clients: - Verwendete Modelle, Bereitstellungen und Providerpfade: **Aktuelles Zugriffsmuster** - Direkte Endpunkte, Zugangsmuster und heutige Verantwortliche: - Routing-, Ausfall- oder Drosselungslogik: **Wichtigste Fragmentierung** - Wiederholt gepflegte Regeln, Zugänge oder Konfigurationen: - Fehlende Zuordnung oder zusammenhängende Betriebssignale: **Benötigte gemeinsame Kontrollen** - Welche technischen Regeln, Grenzen oder Routingentscheidungen sollen konsistent behandelt werden? **Offene Architekturentscheidungen** - Was ist bewusst noch nicht entschieden? Welche Annahme muss geprüft werden? **Beteiligte Owner** - Plattform, Architektur, Security, FinOps, Netzwerk und Use-Case-Owner: **Sinnvoller nächster Prüfungsschritt** - Direkten Zugriff begründet beibehalten, Gateway-Option technisch bewerten oder Zielbild einer zentralen Kontroll- und Evidenzschicht schärfen: ## 5. Abgrenzung und sachlicher Übergang Dieses Kit liefert keine Security-, Compliance- oder Produktionsfreigabe. Eine belastbare Architekturentscheidung hängt vom tatsächlichen Kontext ab, einschließlich Anwendungen, Netzwerk, Identitäten, Datenflüssen, Verantwortlichkeiten und Betriebsmodell. Der AI Control Tower ist eine klar begrenzte Implementierungsleistung für eine erste Ausbaustufe im Azure-Tenant des Kunden. Die vereinbarte Lösung verbindet standardisierten Modellzugang, technische Guardrails sowie zurechenbare Nutzungs-, Kosten- und Betriebsinformationen. Prüfen Sie, wie eine zentrale Modellzugangsschicht im [AI Control Tower](/ai-control-tower/#passung) umgesetzt und abgegrenzt wird. ## Quellen und Aktualitätsnotiz Stand der technischen Quellenprüfung: 21. August 2026. Das Kit beschreibt Architektursignale; konkrete Dienstfunktionen, Verfügbarkeit und Vorschau-Status müssen vor einer Implementierungsentscheidung erneut geprüft werden. - Microsoft Learn, *Verwenden Sie ein Gateway vor mehreren Modellbereitstellungen oder Instanzen*: https://learn.microsoft.com/de-de/azure/architecture/ai-ml/guide/azure-openai-gateway-multi-backend - Microsoft Learn, *AI gateway capabilities in Azure API Management*: https://learn.microsoft.com/en-us/azure/api-management/genai-gateway-capabilities - Microsoft Learn, *Übersicht über die AI Gateway-Dienstebene (Vorschau)*: https://learn.microsoft.com/de-de/azure/api-management/ai-gateway-overview - Microsoft Learn, *Microsoft Foundry-Architektur*: https://learn.microsoft.com/de-de/azure/foundry/concepts/architecture - Produktclaims: `contracts/claims-registry.json`, CLM-001 und CLM-002.