Die vier Prinzipien
Der AI Systems Manager ist die Umsetzung einer Methode. Hinter der Plattform stehen vier Prinzipien, die festlegen, wie ein Unternehmen seine AI-Features verwaltet. Jedes Prinzip beantwortet eine Frage, die sich beim Betrieb von AI-Features in Produktion zwangsläufig stellt, und jedes spiegelt sich an einer konkreten Stelle der Oberfläche wider. Diese Seite erklärt die vier Prinzipien und zeigt, wo sie in der Plattform greifen.
1. Contract-first
Abschnitt betitelt „1. Contract-first“Der Agent Contract ist das stabile Interface. Ein AI-Feature besteht aus einem Prompt (der Anweisung an das Modell), der sich oft ändert, und aus dem Output-Schema (der festen Struktur der Antwort, mit der die umgebende Software rechnet), das stabil bleiben muss. Contract-first bedeutet: Beides wird in einer zentralen, versionierten Definition zusammengeführt, dem Agent Contract. Fachliche Iteration am Prompt und die feste Zusage an den Code laufen nicht mehr aneinander vorbei, sondern über ein gemeinsames, geprüftes Dokument.
In der Plattform zeigt sich das im Feature-Detail. Öffne ein Feature und arbeite über die Tab-Leiste an den Bestandteilen des Contracts: Schema (das Output-Schema), Prompt, Models (Modelle) und weitere. Eine veröffentlichte Version ist schreibgeschützt; Änderungen entstehen über Neuen Draft anlegen und werden anschließend als neue Version veröffentlicht. Beim Veröffentlichen prüft die Plattform den Contract mit einem Linter und führt eine Fortschrittsleiste über die Reife-Kriterien (Production-Readiness). Eine das Schema brechende Änderung ist ein Major-Schritt und muss ausdrücklich bestätigt werden.
Mehr dazu unter Der Agent Contract und Veröffentlichen.
2. Evaluation statt Bauchgefühl
Abschnitt betitelt „2. Evaluation statt Bauchgefühl“Qualität wird gemessen, nicht geschätzt. Ob ein Feature gut arbeitet, lässt sich nicht am Gefühl ablesen. Eval (kurz für Evaluation, die systematische Qualitätsmessung eines AI-Features) prüft das Verhalten an festgelegten Fällen. Drei Arten von Prüfern greifen ineinander: ein Code-Grader prüft maschinell und deterministisch, ein LLM-Judge bewertet mit einem Modell, was sich nicht hart in Regeln fassen lässt, und ein Human-Grader holt das Urteil eines Menschen ein. Ein Regression-Set, also eine feste Sammlung bekannter Fälle, hält fest, was bereits funktioniert hat, und schlägt an, wenn eine neue Version dahinter zurückfällt.
In der Plattform liegt das im Feature-Detail im Tab Eval. Dort sind die Eval-Kriterien und die Baseline (die Schwellwerte, die eine Version erfüllen muss) des Contracts verankert. So wird Qualität an die Version gebunden statt an eine Einschätzung.
Mehr dazu unter Evaluation.
3. Observability statt Blindflug
Abschnitt betitelt „3. Observability statt Blindflug“Jeder Vorgang ist nachvollziehbar. AI-Features in Produktion dürfen keine Blackbox sein. Observability (die durchgängige Beobachtbarkeit des Betriebs) sorgt dafür, dass jeder Aufruf, jeder Provider-Wechsel und jede Kostenzeile sichtbar bleibt. Das SDK, das die Features in der Kundenumgebung ausführt, instrumentiert die Ausführung automatisch über OpenTelemetry (einen offenen Standard für Telemetriedaten) und meldet die Daten an einen mitgelieferten Collector (die gebündelte Sammelstelle für diese Telemetrie). Von dort fließen sie in die Auswertung der Plattform.
In der Plattform zeigt sich das an zwei Stellen. Der Sidebar-Bereich Audit führt das übergreifende, manipulationssichere Protokoll aller Vorgänge mit Suche und Filtern. Das Cost Dashboard macht die Kosten je Feature und Team transparent. Beide Bereiche sind voll funktionsfähig.
Mehr dazu unter Audit und Kosten.
4. Action Safety statt Vollzugriff
Abschnitt betitelt „4. Action Safety statt Vollzugriff“Werkzeuge bekommen kontrollierte Rechte, keinen Freibrief. Sobald ein AI-Feature über das reine Antworten hinaus handelt, etwa Daten abruft oder ändert, braucht es Grenzen. Ein Tool (eine Funktion, die ein Feature aufrufen kann) wird zentral in der Tool-Registry (dem zentralen Verzeichnis aller Werkzeuge) geführt, mit Eigentümer und Einordnung. Jedes Feature trägt zudem eine Risikoklasse (Risk Tier 1, 2 oder 3), die festhält, wie kritisch es ist. Ein Feature greift nicht beliebig auf Werkzeuge zu, sondern nur auf die freigegebenen.
In der Plattform zeigt sich das in den Bereichen Tools und Tool-Requests. Über einen Tool-Request fordert ein Feature die Nutzung eines Werkzeugs an; die Freigabe ist eine eigene, rollengebundene Aktion. Die Risikoklasse eines Features ist Teil seines Contracts und wird im Feature-Detail gepflegt.
Mehr dazu unter Tools. Welche Rolle einen Tool-Request freigeben darf, steht unter Rollen und Rechte.
Vertiefung
Abschnitt betitelt „Vertiefung“Die vier Prinzipien stammen aus der AI Systems Architecture, der fachlichen Grundlage des Produkts. Wer die Methode hinter der Plattform weiter nachlesen möchte, findet die Darstellung unter ai-systems-architecture.com.