Seit der Umbenennung auf der Ignite ist Azure AI Foundry in vielen Kundenprojekten, die ich begleite, zur zentralen Anlaufstelle für KI-Initiativen geworden. Gleichzeitig werden die Governance-Fragen immer vielschichtiger. Wer darf eigene Modelle deployen? Wie lässt sich Wildwuchs bei API-Keys und Ressourcen verhindern? Und wie steuert man Kosten und Zugriffe zentral, ohne jeden einzelnen Entwickler auszubremsen? Governance ist in Azure AI Foundry längst keine Formalität mehr. Von ihr hängt ab, ob und wie sich KI-Innovationen in der Organisation skalieren und absichern lassen.

Hubs, Projekte und Rollen bringen Ordnung in die Berechtigungen

Mit dem neuen Hub- und Projektmodell von Azure AI Foundry (Einführung) kehrt endlich Ordnung in die Ressourcenflut ein, die frühere OpenAI-Einführungswellen hinterlassen haben. Ein Foundry-Hub dient als Container für KI-Projekte. Zugriff, Netzwerk, Policies und Budget steuert man hier gemeinsam für eine ganze Gruppe von Projekten. Über die fein abgestuften Rollen wie Azure AI Developer, Azure AI User/Inference User und Cognitive Services OpenAI User wird festgelegt, wer Modelle einsehen, Deployments anstoßen oder lediglich Abfragen stellen darf (RBAC-Konzepte). Fehlt ein klares Rollenmodell, endet das nach meiner Erfahrung schnell im Berechtigungschaos, und plötzlich haben viel zu viele Personen vollen Zugriff auf Trainingsdaten oder Modelldefinitionen. Die Foundry-spezifischen Rollen weist man wie bei anderen Azure-Ressourcen im Hub oder im Projekt zu. Wer das automatisieren möchte, arbeitet mit Gruppen.

Managed Identities lösen die API-Keys bei der Authentifizierung ab

Dass Entwickler API-Keys im Klartext in Jupyter-Notebooks ablegen, sollte im Unternehmen endgültig der Vergangenheit angehören. In Azure AI Foundry lässt sich die lokale Authentifizierung, also der Zugang per API-Key, mit der Einstellung disableLocalAuth in der jeweiligen Cognitive-Services-Instanz abschalten. Danach greifen nur noch verwaltete Identitäten oder Service Principals zu, und das Risiko von Key-Leaks und Missbrauch sinkt deutlich. Greifen Anwendungen von Azure-Diensten aus auf OpenAI-Modelle zu, sind Managed Identities die richtige Wahl. Das Prinzip habe ich bereits im Beitrag zu Workload-Identitäten in Entra ID beschrieben. Konfiguriert wird das Ganze im Azure-Portal direkt an der Cognitive-Services-Instanz. Unter „API keys“ deaktiviert man die lokale Authentifizierung, unter „Identity“ richtet man die Managed Identity ein und regelt den Zugriff anschließend über Rollen (How-to).

Praktischer Tipp: Aktiviert disableLocalAuth und gebt jeder Anwendung ihre eigene Managed Identity. Dann bleibt jeder Zugriff nachvollziehbar, und im Rahmen der Incident Response lässt er sich schnell einschränken.

Private Netzwerke, Azure Policy und KI-Filter schirmen die Modelle ab

Wer KI-Modelle produktiv betreibt, sollte die Foundry-Hubs grundsätzlich mit privaten Endpunkten und Managed Virtual Networks ausstatten. So bleiben Zugriffe auf interne Systeme und Trainingsdaten konsequent abgeschottet. Diesen Schritt gehen bislang erstaunlich wenige Unternehmen. Ebenso lohnt sich der Gang in die Azure-Policy-Bibliothek. Für Cognitive Services und AI Foundry stehen dort zahlreiche Built-in-Policies bereit, die beispielsweise bestimmte Regionen vorschreiben, die lokale Authentifizierung abschalten oder eine Netzwerkisolation verpflichtend machen. Weist man die Policies Managementgruppen oder einzelnen Subscriptions zu, ist die Governance von Anfang an verankert.

Zu den wichtigsten Governance-Werkzeugen in Azure AI Foundry gehören die konfigurierbaren Content Filter und Prompt Shields. Sie blockieren unerwünschte Prompts, Ausgaben oder Inhalte in Echtzeit, bevor diese das Unternehmen verlassen oder KI-generierte Fehlinformationen nach außen gelangen. Pro Hub und Projekt lassen sich die Filter fein justieren, etwa nach Sprache, Typ oder weiteren Kriterien.

Beim Zugriff auf ein KI-Modell greifen die Governance-Kontrollen typischerweise so ineinander:

flowchart TD
User["Benutzer mit Rolle"] --> App["App mit Managed Identity"]
App --> Hub["Foundry Hub"]
Hub --> VNet["Privates VNet/Endpoint"]
Hub --> Policy["Azure Policy"]
Hub --> Filter["Content Filter / Prompt Shield"]
Filter --> Model["KI-Modell Deployment"]

Abbildung: Governance-Kontrollen bei der Nutzung von Azure AI Foundry.

Quotas, Budgets und Freigaben halten die Kosten im Rahmen

Im Alltag stolpern viele über die Kosten. Fehlt eine Kontrolle, steigt der KI-Anteil an den Ausgaben schnell ins Uferlose. Azure AI Foundry erlaubt es, Quotas und Budgets pro Hub und Projekt festzulegen. In der Praxis sollten die Quoten auf API-Nutzung, Modellanzahl oder Compute-Zeit wirken, damit sich „Runaway“-Jobs und allzu ehrgeizige Experimente rechtzeitig stoppen lassen. Größeren Unternehmen rate ich, zusätzlich zentrale Azure-Budgets und Cost Alerts anzubinden. Darüber hinaus kann man Deployments neuer Modelle im Hub über einen Workflow zur Freigabe vorlegen. Live geht ein Modell dann erst, wenn ein berechtigter Reviewer ausdrücklich zugestimmt hat. Gerade das schützt vor Compliance-Risiken und ungewollten Veröffentlichungen.

Wer GPT-Modelle darüber hinaus auf Enterprise-Niveau absichern will, findet in meinem Beitrag zu den Governance-Praktiken für Azure OpenAI Service weitere Anregungen. Vieles davon lässt sich unmittelbar auf Foundry-Hubs übertragen, zum Beispiel das Monitoring von Prompt-Logs, die Durchsetzung der Datenklassifizierung oder die Anbindung an das SIEM.

Saubere Governance lässt KI-Projekte schneller anlaufen

In den vergangenen Monaten hat sich bei mir immer wieder dasselbe Bild ergeben: Je besser die Governance in Azure AI Foundry greift, desto schneller und sicherer kommen KI-Projekte in Gang. Deshalb lohnt es sich, Rollen, Netzwerke, Budgets und Policies schon im Pilotprojekt ordentlich aufzusetzen und alle Beteiligten früh mit den neuen Governance-Mechanismen vertraut zu machen. Gute Governance schützt das Unternehmen und beschleunigt zugleich Innovation, sofern sie Freiräume lässt, ohne die Kontrolle aus der Hand zu geben.