KI-Plattform: Bekannte Probleme und offene Punkte

Diese Seite sammelt, was die Quellen als bekannte Probleme nennen und was du für dein eigenes Deployment bestätigen solltest. Punkte mit Bestätigen sind Abweichungen oder Lücken in den Quellen, kein verifiziertes Verhalten.

Bekannte Probleme (aus den modules)

Problem	Auswirkung	Workaround
Das Aktualisieren eines Capability Hosts wird von der ARM API nicht unterstützt	Eine Änderung am Host (zum Beispiel eine weitere Verbindung) schlägt fehl	In der Quelle nicht genannt. Plane Änderungen an Verbindungen vor dem ersten Deployment.
terraform destroy schlägt mit einem Fehler beim Löschen des Subnets fehl	Das Integration-Subnet wird von Service Association Links des Agent Service gehalten	In der Quelle nicht genannt. Rechne damit, es später erneut zu versuchen, und siehe den nächsten Punkt.
Das Integration-Subnet lässt sich direkt nach einem destroy nicht löschen	Abhängigkeiten von Azure-Services geben das Subnet erst nach einer Verzögerung frei	Warte und lösche danach.

Offene Punkte

Thema	Was die Quellen zeigen	Was zu bestätigen ist
Public network access	Das account module setzt publicNetworkAccess auf Enabled, auch wenn es einen private endpoint erstellt. Die README des project modules sagt „private endpoints for secure access“.	Ob öffentlicher Zugriff auf deiner Plattform akzeptabel ist oder per Policy oder andere Einstellung geschlossen wird.
Account-Diagnose	Das project module setzt Diagnoseeinstellungen auf dem account nur im Standalone-Modus. Das account module setzt keine.	Wohin die Logs des gemeinsamen accounts auf deiner Plattform gehen.
Fest verdrahtete Plattformnamen	platform_data enthält feste Namen für ein Deployment. Seine README und main.tf unterscheiden sich außerdem bei einigen Namen (Container Registry, Platform Storage Account).	Nimm den Code als Single Source of Truth und ersetze die Werte für dein Deployment.
Veraltete README-Beispiele	Die README von platform_data zeigt foundry_project-Inputs (resource_group_name, storage_account_id), die das module nicht mehr hat, und nennt einen PostgreSQL Flexible Server, für den es keine Data Source gibt. Die README von project_data verlinkt auf Spezifikationsdateien, die nicht im Repository liegen.	Folge den Variablen des modules, nicht den README-Beispielen.
Project-Name	project_name hat im Code den Default null, ist aber praktisch Pflicht.	Setze ihn immer.
Gruppen-Inputs	Die drei Gruppen-IDs haben den Default null, aber die Rollenzuweisungen sind unbedingt.	Setze immer alle drei.
Reader-Gruppe	Die Reader-Gruppe bekommt nur eine Rolle auf dem Search-Index.	Ob Reader auch eine Rolle auf dem project oder Storage brauchen.
Deploy roots	Für eine spätere Phase geplant.	Wie deine Plattform die modules heute deployt.
Container Apps environment, Registry, Cosmos DB, AI Search	Das Referenzdesign schlägt sie nach. Das Repository hat kein module, das sie erstellt.	Wo und wie sie auf deiner Plattform deployt werden.
Modelle	Werden auf Plattformebene deployt, im Migrationsbeispiel mit azurerm_cognitive_deployment. Im Repository liegt kein Deployment-Code.	Welche Modelle, Regionen und Quotas es gibt und wer sie ändert.
Provider-Versionen	AzureRM ist unterhalb von 5.0 fixiert.	Plane das vor einem AzureRM-Major-Upgrade ein.
Backup, Restore, SLA, support-Zeiten	Nicht in den Quellen.	Dein Vertrag oder onboarding-Dokument.

Kompatibilität

• Das project module ist „backward compatible“: Bestehende Standalone-Deployments laufen weiter, neue sollten account_id übergeben.
• Die module-Variable model_deployments wurde aus dem project module entfernt. Ein Aufruf, der sie noch setzt, muss sie entfernen und Modell-Deployments getrennt auf Plattformebene verwalten.