Rollen und Rechte
Der AI Systems Manager trennt Governance und Ausführung: Die Plattform verwaltet die Agent Contracts zentral, das SDK führt die Features lokal aus. Damit diese zentrale Verwaltung nicht jeder beliebig ändern kann, ordnet die Plattform jedem Konto eine Rolle zu. Die Rolle entscheidet, welche Bereiche in der Navigation erscheinen und welche Aktionen erlaubt sind.
Wichtig dabei: Die Oberfläche blendet nur aus, was eine Rolle ohnehin nicht ausführen darf. Das ist eine Affordance, also eine Hilfestellung, damit niemand eine Aktion versucht, die ohnehin abgelehnt würde. Die eigentliche Durchsetzung passiert im Backend. Wer also einen ausgeblendeten Knopf über Umwege doch erreicht, wird trotzdem abgewiesen.
Die sechs Rollen
Abschnitt betitelt „Die sechs Rollen“Es gibt sechs Rollen. Die folgenden Persona-Bezeichnungen (Platform Engineer, System-Admin, Engineering Lead, Domänenexperte) sind nur zur Veranschaulichung genannt; in der Praxis kann jede Person jede Rolle tragen.
- platform_engineer — die technisch führende Rolle (typischer Platform Engineer). Verwaltet den gesamten Lebenszyklus: Features anlegen und löschen, Provider und Modelle pflegen, Contracts bearbeiten und veröffentlichen, Tool-Requests bearbeiten.
- admin — die plattformweite Verwaltungsrolle (typischer System-Admin). Hat in fast allen Bereichen dieselben Rechte wie platform_engineer und zusätzlich Zugriff auf Compliance und auf gelöschte Quellen.
- developer — die Rolle für die Code-Anbindung (typischer Entwickler). Arbeitet am Agent Contract, fragt Tools an und nutzt das SDK, hat aber keinen Zugriff auf Provider- oder Compliance-Verwaltung.
- domain_expert — die fachliche Rolle (typischer Domänenexperte). Arbeitet im selben Contract-Editor wie der developer, bearbeitet und veröffentlicht also Prompt und Schema, kann eine Version aber nicht auf eine frühere zurücksetzen.
- compliance_officer — die prüfende Rolle (typischer Compliance Officer). Liest weitgehend mit (Features, Kosten, Master-Tokens, Tool-Registry) und hat exklusiven Zugriff auf den Compliance-Bereich und auf gelöschte Quellen.
- viewer — die reine Leserolle (etwa ein Engineering Lead, der nur den Stand verfolgt). Sieht die Übersicht, das Feature-Verzeichnis (nur lesend) und das Audit-Protokoll.
Rechte-Matrix
Abschnitt betitelt „Rechte-Matrix“Die Tabelle zeigt pro Aktion, was jede Rolle darf: Ja für ausführen, Lesen für ausschließlich anzeigen, — für kein Zugriff.
| Aktion | platform_engineer | admin | developer | domain_expert | compliance_officer | viewer |
|---|---|---|---|---|---|---|
| Features anlegen / löschen | Ja | Ja | — | — | — | — |
| Quellen verwalten | Ja | Ja | Ja | Ja | — | — |
| Gelöschte Quellen sehen | — | Ja | — | — | Ja | — |
| Contract bearbeiten (Prompt / Schema / Modelle) | Ja | Ja | Ja | Ja | Lesen | — |
| Version veröffentlichen | Ja | Ja | Ja | Ja | — | — |
| Auf frühere Version zurücksetzen | Ja | Ja | Ja | — | — | — |
| Contract-Audit sehen | Ja | Ja | — | — | Ja | — |
| Provider verwalten | Ja | Ja | — | — | — | — |
| Master-Tokens verwalten | Ja | Ja | — | — | Lesen | — |
| Tool-Requests bearbeiten | Ja | Ja | Ja | — | — | — |
| Compliance-Bereich | — | Ja | — | — | Ja | — |
| Cost Dashboard | Ja | Ja | — | — | Lesen | — |
Sperre im Lebenszyklus
Abschnitt betitelt „Sperre im Lebenszyklus“Unabhängig von der Rolle gilt: Sobald ein Feature in den Lebenszyklus-Status sunset (stillgelegt) übergeht, kann es niemand mehr bearbeiten. Der Contract-Editor ist dann für alle Rollen gesperrt; nur noch lesender Zugriff bleibt erhalten. Ebenso ist eine bereits veröffentlichte Version schreibgeschützt: Änderungen erfordern den Schritt Neuen Draft anlegen, der wiederum den oben genannten Bearbeitungsrechten unterliegt.
Sichtbarkeit in der Navigation
Abschnitt betitelt „Sichtbarkeit in der Navigation“Welche Sidebar-Einträge eine Rolle sieht, ist eng an diese Rechte gekoppelt, aber nicht identisch: Manche Bereiche erscheinen für eine Rolle nur lesend. Die vollständige Zuordnung von Rolle zu sichtbaren Bereichen steht in der Oberflächen-Referenz.