Nachweise — Technischer Blueprint
Gesteuerte KI- und Agentenarchitektur
Wie man KI und, wo gerechtfertigt, einen Agenten in einen kritischen Betrieb einbettet, sodass die Fähigkeit wächst, ohne dass die Befugnis die Konsequenz überholt. Die wiederverwendbare Form der Kontrollgrenze des Flaggschiffs — mit klar benannten Kompromissen, Fehlermodi und Grenzen.
Technischer Blueprint
Eine Referenzarchitektur, verallgemeinert aus dem Flaggschiffsystem. Kein Produkt und keine Kundenarbeit.
Zweck
Wofür diese Architektur gedacht ist.
Diese Architektur bringt KI, und wo gerechtfertigt einen Agenten, in einen kritischen Betrieb ein, sodass die Fähigkeit wachsen kann, ohne dass die Befugnis der Konsequenz vorauseilt. Es ist die wiederverwendbare Form der Kontrollgrenze, die im Gesteuerten Fallbearbeitungssystem umgesetzt wird.
Wann sie geeignet ist
- Arbeit mit hohem Volumen, die das Lesen unstrukturierter Dokumente, das Abrufen von Richtlinien oder Kontext und das Entwerfen einer fundierten Bewertung umfasst.
- Entscheidungen, die bis zu einer Quelle rückverfolgbar und im Nachhinein verteidigbar sein müssen.
- Betriebe, in denen manche Aktionen routinemäßig und sicher zu automatisieren sind, während andere folgenreich sind und für einen Menschen anhalten müssen.
Architektur
Komponenten, Beziehungen und Grenzen.
Das Modell läuft nie allein. Es ist eine Komponente innerhalb eines deterministischen Systems, das entscheidet, was als Nächstes passiert, und jeden Schritt protokolliert.
Kontrollgrenze
Textbeschreibung dieses Diagramms
Das Modell oder der Agent sitzt innerhalb einer Kontrollgrenze und ist von der Governance umhüllt, die es braucht, um sicher zu laufen: begrenzte Berechtigungen, die Werkzeuge und das Retrieval, die es nutzen darf, Evaluation, Überwachung und Wiederherstellung.
Folgenreiche Aktionen verlassen die Grenze nicht von selbst — sie durchlaufen ein menschliches Genehmigungstor. Die Befugnis ist proportional zur Konsequenz.
Komponenten
- Workflow-Orchestrator
- Die deterministische Engine, die Arbeit durch benannte Zustände voranbringt und entscheidet, wann das Modell aufgerufen wird. Sie, nicht das Modell, hält die Kontrolle.
- Retrieval
- Ruft die Richtlinie und den vorherigen Kontext ab, die eine Aufgabe benötigt, mit Herkunftsnachweis, sodass das Modell mit fundiertem Material arbeitet statt aus dem Gedächtnis.
- Modell-Gateway
- Der einzige, beobachtbare Pfad zum Modell. Er erzwingt Kontextminimierung, Limits, Zeitüberschreitungen und datenschutzfreundliche Protokollierung.
- Richtlinien- und Regel-Engine
- Deterministische Prüfungen, die die Ausgabe des Modells bestehen muss — erforderliche Zitate, verbotene Inhalte und Geschäftsregeln.
- Werkzeug- und Aktionsregister
- Eine Positivliste der Aktionen, die das System ausführen darf, jede eingegrenzt und nur vom Orchestrator aufgerufen, niemals direkt durch die Modellausgabe.
- Freigabe-Gate
- Ein benannter Zustand, in dem eine Person mit der richtigen Befugnis folgenreiche Aktionen genehmigt, bevor sie die Grenze verlassen.
- Evaluationsrahmen und Audit-Log
- Misst das System vor der Freigabe gegen Datensätze und protokolliert jeden Akteur, jede Eingabe, jedes Zitat und jede Entscheidung im Betrieb.
Daten- und Befugnisgrenzen
Das gesamte System läuft innerhalb einer Kontrollgrenze. Daten und Befugnis sind eingegrenzt, sodass Fähigkeit begrenzt bleibt.
- Geringste Rechte: Jeder Dienst und jede Rolle besitzt nur die Berechtigungen, die sie benötigt; das Modell-Gateway kann nicht in ein System der Aufzeichnung schreiben.
- Eingegrenzter Kontext: Das Gateway sendet dem Modell den für die Aufgabe minimal erforderlichen Kontext und protokolliert, was gesendet wurde.
- Aktionen auf Positivliste: Das System kann nur Aktionen aus dem Register ausführen, und nur über Integrationsadapter, die die Grenze sehen kann.
- Inhalt ist kein Befehl: Text innerhalb eines abgerufenen Dokuments kann niemals ein Werkzeug zum Ausführen bringen — Anweisungen kommen nur vom Orchestrator.
- Geheimnisse bleiben außerhalb des Modellpfads und werden als Bindings bereitgestellt, niemals in Prompts oder Protokollen platziert.
Menschliche Befugnis
Wo ein Mensch die Kontrolle behält.
Befugnis wird proportional zur Konsequenz der Handlung gewährt. Die menschliche Rolle ist gestaltet, nicht improvisiert.
- Schritte mit geringer Konsequenz laufen automatisch innerhalb expliziter Grenzen.
- Arbeit mit mittlerer Konsequenz wird von einem Bediener entschieden, unterstützt vom Modell.
- Aktionen mit hoher Konsequenz erfordern einen Senior-Genehmiger am Gate.
- Eine Person kann immer eingreifen; das Eingreifen, seine Autorin oder sein Autor und der Grund werden protokolliert.
- Geringe Modellkonfidenz, eine fehlgeschlagene Richtlinienprüfung oder eine unlesbare Eingabe eskaliert zu einem Menschen, statt fortzufahren.
Evaluation
Wie sie gemessen wird und wie mit Unsicherheit umgegangen wird.
Das System ist nur vertrauenswürdig, wenn es vor und während des Betriebs gemessen und an einem Standard gehalten werden kann.
Was gemessen wird
- Verankerung (Groundedness) — wird jede Aussage des Modells durch ein abgerufenes Zitat gestützt?
- Aufgabenerfolg — erfüllt die Ausgabe die Abnahmekriterien der Aufgabe?
- Präzision und Trefferquote der Richtlinienprüfung — werden die richtigen Ausgaben markiert, ohne Bediener in Falschmeldungen zu ertränken?
- Rate menschlicher Übersteuerung — wie oft korrigieren Bediener den Entwurf, und warum?
- Korrektheit der Eskalation — erreichen folgenreiche oder Fälle mit geringer Konfidenz einen Menschen?
- Latenz und Kosten pro Arbeitseinheit — ist es bei Volumen betreibbar?
Unsicherheit
Das Modell liefert eine kalibrierte Konfidenz, keine blanke Antwort. Unterhalb eines festgelegten Schwellenwerts hält es sich zurück und eskaliert, statt zu raten. Die Kalibrierung selbst wird gemessen, denn ein übermäßig selbstsicheres Modell ist gefährlicher als ein vorsichtiges.
Observability
Jeder Schritt erzeugt eine datenschutzfreundliche Spur: welcher Zustand lief, welche Werkzeuge aufgerufen wurden, wie lange es dauerte, und das Ergebnis — niemals die vertraulichen Feldwerte. Metriken und Spuren machen eine Regression sichtbar, bevor sie zu einem Vorfall wird.
Fehlermodi
Wie sie versagt, und was hält.
| Fehlermodus | Gegenmaßnahme |
|---|---|
| Unbegründete oder erfundene Ausgabe | Zitate verlangen, deterministische Richtlinienprüfungen durchführen und folgenreiche Aktionen hinter einem Menschen absichern. Eine unbelegte Aussage kann nicht durchdringen. |
| Prompt-Injection durch ein abgerufenes Dokument | Allen Inhalt als Daten behandeln, niemals als Anweisungen; Werkzeuge laufen nur vom Orchestrator aus; das Aktionsregister ist eine Positivliste. |
| Missbrauch von Werkzeugen oder Aktionen | Berechtigungen jeder Aktion eingrenzen, Bestätigung für folgenreiche Aktionen verlangen, und jeden Aufruf protokollieren. |
| Ausfall von Modell oder Anbieter | Geordnet zu einer manuellen Warteschlange degradieren; der Workflow läuft ohne das Modell weiter, statt den Betrieb scheitern zu lassen. |
| Stille Qualitätsdrift | Die Evaluationsmetriken im Betrieb überwachen; eine Drift über einen Schwellenwert hinaus löst eine Überprüfung und, falls nötig, einen Rollback aus. |
| Sensible Daten erreichen das Modell | Kontext minimieren und wo möglich schwärzen; genau protokollieren, was gesendet wurde; die Grenze auditierbar halten. |
Verworfene Alternativen
Was erwogen wurde, und warum es nicht gewählt wurde.
-
Ein vollständig autonomer Agent ohne menschliches Gate
Erwogen Er verspricht den höchsten Durchsatz und den geringsten menschlichen Aufwand.
Verworfen Die Befugnis würde der Konsequenz vorauseilen: Eine einzige falsche Handlung könnte nicht abgefangen werden, bevor sie die Grenze verlässt. Autonomie wird stattdessen an die Konsequenz gebunden.
-
Ein großer Prompt, der alles erledigt
Erwogen Er ist schnell zu bauen und demonstriert sich gut.
Verworfen Er kann nicht Schritt für Schritt inspiziert, getestet oder gesteuert werden und versagt undurchsichtig. Stattdessen wird ein deterministischer Workflow mit diskreten, testbaren Zuständen verwendet.
-
Fine-Tuning als primäre Kontrolle
Erwogen Ein feinabgestimmtes Modell kann offensichtliche Fehler reduzieren.
Verworfen Feinabstimmung ändert das Verhalten im Durchschnitt, bietet aber keine Laufzeitgarantie. Governance muss durch Retrieval, Richtlinienprüfungen und das Gate erzwungen werden — nicht von den Gewichten erhofft.
-
Nur deterministische Automatisierung (RPA)
Erwogen Sie ist vorhersehbar und benötigt kein Modell.
Verworfen Sie ist brüchig bei unstrukturierten Dokumenten und mehrdeutigen Fällen — genau dort, wo diese Architektur ihren Platz verdient. Wo die Eingabe vollständig strukturiert ist, ist der einfachere Ansatz richtig (siehe unten).
Einsatz & Kosten
Wie sie eingesetzt wird, und was ihre Kosten bestimmt.
- Kunden-Cloud oder VPC
- Das System läuft innerhalb der Umgebung des Kunden mit kundenkontrollierten Schlüsseln; Daten verlassen dessen Grenze nicht.
- Gehostete Modell-API vs. selbst gehostetes Modell
- Eine gehostete API ist schneller zu betreiben und zu aktualisieren; ein selbst gehostetes Modell bietet volle Datenkontrolle und vorhersehbare Kosten um den Preis operativen Aufwands. Das Gateway isoliert diese Wahl, sodass sie sich später ändern lässt.
- Isoliert oder vor Ort (On-Premise)
- Für die sensibelsten Daten läuft der gesamte Pfad — einschließlich des Modells — in einer isolierten Umgebung, was höhere Kosten und langsamere Modellaktualisierungen bedeutet.
Betriebskosten
Die Betriebskosten werden von der Modellinferenz, der Retrieval- und Vektorinfrastruktur und der menschlichen Prüfzeit dominiert — nicht von der Orchestrierung selbst. Die Kosten werden hier qualitativ beschrieben; eine reale Zahl hängt vom Volumen, der Modellwahl und der Prüfrate ab und wird pro Mandat geschätzt statt behauptet.
Wann diese Architektur nicht verwendet werden sollte
Die ehrlichen Grenzen.
- Wenn eine deterministische Regel, ein Formular oder ein Bericht das Problem bereits löst — kein Modell um seiner selbst willen hinzufügen.
- Wenn die Eingabe vollständig strukturiert und eindeutig ist; konventionelle Automatisierung ist günstiger und vorhersehbarer.
- Wenn die Konsequenz eines verbleibenden Fehlers so hoch ist, dass ein Mensch die gesamte Aufgabe erledigen muss, nicht nur genehmigen.
- Wenn die Daten nicht gesteuert oder der Betrieb nicht auditiert werden können — die Grenze ist der Kernpunkt, und ohne sie sollte die Architektur nicht ausgeliefert werden.
- Wenn das Volumen zu gering ist, um die Evaluation und Überwachung zu rechtfertigen, die die Architektur zur Sicherheit benötigt.
Was dies beweist und was nicht
Es zeigt
- Dass Autonomie proportional zur Konsequenz gestaltet werden kann, mit expliziten Gates und Grenzen.
- Dass Governance-Komponenten (Retrieval, Validierung, Richtlinien, Evaluation, Audit) Architektur sind, kein nachträglicher Gedanke.
Es zeigt nicht
- Dass ein bestimmtes Modell oder Agenten-Framework für ein gegebenes Problem das beste ist.
- Quantitative Zuverlässigkeitswerte für eine bestimmte Implementierung.
Wie man es prüft
Lesen Sie die Architektur, die Befugnisgrenzen, die Fehlermodi und den expliziten Abschnitt „Wann dies nicht verwenden“. Sie wird konkret im Flaggschiffsystem umgesetzt.
Beauftragung
Beginnen Sie mit dem, was sich ändern muss.
Wenn KI in einem Prototyp funktioniert, aber in Ihrem Betrieb noch nicht vertrauenswürdig ist, beginnt ein Mandat mit der Kontrollgrenze, innerhalb der sie laufen muss.
Alternativ können Sie eine Ausschreibung einreichen, oder zuerst eine NDA anfordern.