KI-Plattform: Entscheidungen¶

Verdichtete Design-Entscheidungen der Lösung, entnommen den Projektkonventionen und dem Modulcode. Die Quelle enthält keine formalen Decision Records, deshalb nennt jeder Eintrag die Entscheidung und den Grund, der sich aus dem Code ablesen lässt.

Ein gemeinsamer Foundry-Account, ein Projekt pro Workload¶

Alle workloads teilen sich einen Account, und jeder workload bekommt ein Projekt. Das Projekt ist die Isolationsgrenze für Connections, die Identität, Dateien und Agent-Daten, während Quota und Modelle zentral bleiben. Status: im Modul-Design in Verwendung.

Model Deployments werden auf Plattformebene verwaltet¶

Das Projekt-Modul erstellt keine Model Deployments. So bleibt das Quota-Management zentral und über alle Projekte hinweg einheitlich. Konsequenz: Ein Workload-Team bittet das Plattform-Team um ein Modell oder um Quota.

Identität statt Keys¶

Beim Account ist die lokale Authentifizierung deaktiviert, Connections nutzen Entra ID, und das Projekt und der workload haben jeweils eine User-assigned Managed Identity. Der Zugriff für Personen läuft über Gruppen. Konsequenz: keine Keys, die rotiert werden müssen, aber die Rollenzuweisungen müssen stimmen, bevor etwas funktioniert.

User-assigned Identities¶

User-assigned Identities werden von Terraform vor den Ressourcen erstellt, die sie verwenden. So lassen sich Rollenzuweisungen vorab vornehmen, und die Erstellung der Identität bleibt von der Erstellung der Ressource getrennt (das Modul workload_identity gibt es aus diesem Grund).

AzAPI für Foundry-Ressourcen¶

Account, Projekt, Connections und Capability Host werden mit dem Provider azapi erstellt, weil azurerm sie nicht vollständig unterstützt. Konsequenz: Die API-Version ist im Code festgelegt und die Schemavalidierung ist abgeschaltet, also prüfe Pläne sorgfältig.

Network Injection und private endpoints¶

Agents laufen in einem Subnetz des Spokes (Network Injection, eigenes Subnetz statt eines von Microsoft verwalteten Netzwerks). Services werden über private endpoints erreicht. Siehe Architektur.

Gemeinsame Datenspeicher mit Collections pro Projekt¶

Cosmos DB und AI Search werden geteilt. Projekte bekommen eigene Collections und Rollenzuweisungen und ein Storage Account pro Projekt. Konsequenz: Ein plattformweites Limit oder ein Incident bei diesen Services betrifft alle Projekte.

Reine Lookup-Module¶

platform_data und project_data lassen workload-Code Plattformressourcen finden, ohne Remote State oder fest verdrahtete IDs. Abwägung: Die Namen in platform_data sind pro Deployment fest (siehe Bekannte Probleme).

Erst Module, später Deployment-Code¶

Die erste Phase liefert Module. Deployment-Roots folgen, in der Reihenfolge Shared Platform, Projekte, workloads. Die Backend-Konfiguration wird bei terraform init übergeben und nie im Repository gespeichert.