KI-Plattform: Servicebeschreibung

Diese Seite beschreibt, was die KI-Plattform bietet und wo sie aufhört. Sie basiert auf den Terraform-Modulen der Lösung. Kommerzielle Bedingungen (Preis, Zeiten, Reaktionszeiten) stehen in deinem Vertrag oder onboarding-Dokument, nicht hier.

Was angeboten wird

Komponente	Was sie ist
Gemeinsamer Foundry-Account	Ein Azure-AI-Services-Account (Kind AIServices) pro Plattform, mit aktiviertem Projektmanagement. Alle Projekte liegen darin.
Foundry-Projekt pro Workload	Ein isoliertes Projekt mit eigener Managed Identity, eigenem Storage Account, eigenem Application Insights, eigenen Connections und einem Agents Capability Host.
Datenspeicher für Agents	Azure Cosmos DB (Agent-Threads und State) und Azure AI Search (Vector Store). Auf Plattformebene geteilt und mit jedem Projekt verbunden.
Compute und Registry für workloads	Das Referenzdesign enthält eine Azure-Container-Apps-Umgebung und eine Azure Container Registry für die Anwendungen, die die Agents aufrufen.
Zugriff über Gruppen	Pro Projekt eine Owner-, Contributor- und Reader-Gruppe, mit Rollen auf dem Projekt und seinen Datenspeichern.
Workload Identity	Eine User-assigned Managed Identity pro Anwendung, mit einer Liste von Rollenzuweisungen.
Lookups	Reine Daten-Module, damit workload-Code die Plattformressourcen und das Projekt ohne fest verdrahtete IDs findet.

Die Komponentenliste folgt dem Design der Lösung. Die Module dieses Repositorys erstellen den Foundry-Account, das Projekt und seine Ressourcen sowie die Workload Identity. Die Container-Apps-Umgebung, die Registry, der Cosmos-DB-Account, der AI- Search-Service, das Key Vault und der Log-Analytics-Workspace werden von den Modulen nachgeschlagen, sie existieren also, bevor ein Projekt erstellt wird. Welche davon deine Plattform betreibt und wie sie deployt werden, ist plattformspezifisch.

Nicht enthalten

• Model Deployments. Modelle werden auf Plattformebene deployt und gehören nicht zum Projekt-Modul. So bleibt das Quota- Management zentral und über alle Projekte hinweg einheitlich. Ein Aufruf des Projekt-Moduls erstellt kein Model Deployment.
• Anwendungscode und Agents. Die Agents, Prompts, Tools und Anwendungen gehören dir.
• Content- und Data-Governance. Welche Daten du an ein Modell sendest, wie lange Konversationen aufbewahrt werden und die Regeln für die Nutzung von KI sind Entscheidungen deiner Organisation.
• Eine Deployment-pipeline. Das Quell-Repository liefert Module. Umgebungsspezifischer Deployment-Code ist für eine spätere Phase geplant (siehe Bekannte Probleme).

Servicemodell

	Plattform-Team	Workload-Team
Foundry-Account, gemeinsame Datenspeicher, Netzwerkintegration	Ja
Ein Foundry-Projekt erstellen, ändern und entfernen	Ja, nach einer Anfrage	Stellt die Anfrage
Zugriffsgruppen und Rollenzuweisungen eines Projekts	Ja	Die Owners der Gruppen entscheiden über die Mitglieder
Im Account verfügbare Modelle	Ja	Fragt nach einem Modell oder Quota
Agents, Anwendungen, Prompts, Daten in den Speichern		Ja

Details stehen unter Verantwortlichkeiten. Das Plattform-Team ist XMMS im Managed-Service-Modell und dein eigenes Team im Eigenbetrieb: Betriebsmodelle.

Einschränkungen aus der Quelle

Einschränkung	Wert
Regionen im Referenzdesign	westeurope, swedencentral
Umgebungen	development, test, acceptance, production, nonprod
Name des workloads (Projekts)	Maximal 8 Zeichen
Tags auf allen Ressourcen	Environment und Workload

Das sind Konventionen des Quell-Repositorys für den geplanten Deployment-Code. Die Module selbst erzwingen sie nicht mit Validierungsregeln. Frag dein Plattform-Team, welche Werte auf deiner Plattform gelten. Allgemeine Namen und Tags stehen unter Namen und Tags.

So fragst du an

Sende eine Anfrage über den Kanal deiner Plattform (<support channel>), siehe So stellst du eine Anfrage. Nenne bei einem neuen Projekt den workload, die Umgebung, die Region und die Mitglieder der Owner-, Contributor- und Reader-Gruppe. Das genaue Intake-Formular für die KI-Plattform ist in den Quellen nicht definiert.