Praxisbeispiel
Ein Service-Agent von der Anfrage bis zur freigegebenen Aktion
Ein AI-Agent soll eingehende Servicefälle analysieren, Informationen aus mehreren Systemen abrufen, eine Handlungsempfehlung erstellen und nach menschlicher Freigabe definierte Aktionen auslösen.
Worum es geht
Das Beispiel ist bewusst branchenneutral und enthält keine vertraulichen oder erfundenen Kundendaten. Es dient als roter Faden, an dem sich die Architekturfragen der sieben Missionen konkret durchspielen lassen.
Für Einsteiger zeigt es Schritt für Schritt, woran man bei einem handelnden KI-System denken muss — von „Wer ist verantwortlich?“ bis „Wie stoppe ich es im Ernstfall?“.
Für Architektinnen, Entwickler und Entscheider stellt jeder Schritt die konkreten Architekturentscheidungen heraus, die das System verlässlich, nachvollziehbar und begrenzbar machen.
Dieses Beispiel ist bewusst didaktisch. Wie die gleichen Prinzipien in einem realen, governance-geführten System mit Demonstrator aussehen, zeigt die Praxisreferenz „AI-Operable IT-Services“.
Schritt 001 · Mission 001: Zielbild & Operating Model
Wer verantwortet den Service-Agenten, welches Ziel verfolgt er — und welche Entscheidungen darf er treffen?
- Ein benannter Owner verantwortet Betrieb, Freigabe und Abschaltung; das Vorhaben steht im AI-Inventar.
- Ziel und Nutzen sind messbar definiert (z. B. schnellere, nachvollziehbare Fallbearbeitung) — nicht „mehr KI“.
- Klare Grenze: Der Agent darf vorschlagen und vorbereiten, definierte Aktionen aber nur nach menschlicher Freigabe auslösen.
- Eine Risikoklasse legt fest, welche Auflagen (Freigaben, Protokollierung) für genau diesen Fall gelten.
Schritt 002 · Mission 002: Daten werden zu Kontext
Welche Datenquellen darf der Agent nutzen, wie aktuell sind sie — und woher stammt eine Information?
- Nur freigegebene Quellen (Wissensbasis, Fallhistorie, Stammdaten) — kein ungefilterter Zugriff auf alles.
- Die Berechtigungen des bearbeitenden Menschen werden auf den Kontextzugriff übertragen, nicht umgangen.
- Jede herangezogene Information ist auf ihre Quelle zurückführbar (Provenance), damit die Empfehlung prüfbar ist.
- Veraltete oder gesperrte Inhalte sind gekennzeichnet bzw. aus dem Index ausgeschlossen.
Schritt 003 · Mission 003: APIs werden zu Werkzeugen
Welche Systeme ruft der Agent auf — und welche Aufrufe sind lesend, welche schreibend?
- Lesende Tools (Fall abrufen, Wissen suchen) sind von schreibenden (Aktion auslösen) klar getrennt.
- Schreibende Aktionen haben einen Dry-Run und sind idempotent — ein wiederholter Aufruf richtet keinen Doppelschaden an.
- Fehler, Timeouts und Wiederholungen sind im Tool-Vertrag definiert; Mehrschritt-Abläufe haben eine Kompensationslogik.
- Alle Aufrufe laufen über ein kontrolliertes Gateway und sind auditierbar protokolliert.
Schritt 004 · Mission 004: Identität, Security & Governance
Unter welcher Identität handelt der Agent, welche Rechte hat er — und wo ist eine Freigabe Pflicht?
- Der Agent hat eine eigene Maschinenidentität (kein geteiltes Sammelkonto) mit minimalen Rechten.
- Zugriffe sind kurzlebig (befristete Tokens) und getrennt nach Lesen, Vorschlagen und Ausführen.
- Die auslösende Aktion erfordert eine ausdrückliche menschliche Freigabe (Human-in-the-Loop).
- Ein Kill Switch hält die Agentenaktivität im Ernstfall sofort an — getestet, nicht nur dokumentiert.
Schritt 005 · Mission 005: Evals, Reliability & Observability
Wie wird Antwortqualität getestet, wie werden Tool-Aufrufe protokolliert — und wann wird eskaliert?
- Golden Datasets mit typischen Servicefällen prüfen die Empfehlungsqualität fortlaufend (Continuous Evals).
- Das Tracing reicht bis zum einzelnen Tool-Aufruf, nicht nur bis zum Modellaufruf.
- Qualitäts-SLOs und überwachte Fehlerbilder lösen bei Verletzung definierte Reaktionen aus.
- Unsichere oder riskante Fälle eskalieren automatisch an einen Menschen; Vorfälle sind per Replay rekonstruierbar.
Schritt 006 · Mission 006: Portability, Sovereignty & Economics
Welche Anbieterabhängigkeiten bestehen, was kostet ein Vorgang — und welche Daten verlassen das Haus?
- Der Modellanbieter ist über ein Model Gateway austauschbar, ohne die Anwendung neu zu bauen.
- Die Kosten werden pro bearbeitetem Fall (Geschäftsergebnis) gemessen, nicht nur pro Token.
- Es ist bewusst entschieden, welche Daten externe Dienste erreichen dürfen und welche im Haus bleiben.
- Eigene Evaluationsdaten erlauben einen Vorher-Nachher-Vergleich bei einem Anbieterwechsel.
Schritt 007 · Mission 007: AI-native Software Engineering & Platform
Wie wird der Agent entwickelt, getestet und versioniert — und wie sicher ist seine Lieferkette?
- Prompts, Tool-Definitionen und Modellversionen sind versioniert und durchlaufen Reviews und Freigaben.
- Generierter Code durchläuft dieselben Quality Gates wie handgeschriebener.
- Die Herkunft von Code, Modellen und Daten ist nachvollziehbar (Provenance / AI-SBOM).
- Architekturregeln sind als ausführbare Fitness Functions hinterlegt, nicht nur als Dokument.
Dieses Beispiel auf Ihren Fall übertragen?
Nova-7 verknüpft das Szenario mit den passenden Missionen und Primärquellen.