SAFR implementieren: Architektur, Muster und Make-or-Buy

Die SAFR-Referenzarchitektur¶

SAFR sitzt zwischen dem Agenten und den Systemen, auf die er einwirkt, bewertet vorgeschlagene Aktionen vor der Ausführung und arbeitet dabei mit bestehenden Zahlungsverkehrsinfrastrukturen, Abwicklungsprotokollen, Compliance-Engines und Kernbankensystemen zusammen. Das Gestaltungsziel des Papiers: Keine agentische Aktion gelangt zur Ausführung, ohne deklariert, autorisiert und bewertet worden zu sein. Eine Implementierung ist eine Pipeline mit fester Reihenfolge und einem Audit Log, das jede ihrer Stufen aufzeichnet.

Die Pipeline läuft so ab. Der Agent schlägt eine Aktion vor. Bevor etwas ausgeführt wird, wird der Vorschlag in einen Governance Envelope gepackt, der drei Klassen von Informationen enthält: die Aktion selbst (Typ, Umfang, Parameter), die Aktionsspur (die Schritte, die der Agent tatsächlich ausgeführt hat, um zum Vorschlag zu gelangen, einschließlich Tool-Aufrufen, abgerufener Daten und durchgeführter Prüfungen) und Kontextmetadaten (Agentenidentität, anwendbares Mandat, aktueller Konto- oder Systemzustand und geltende Richtlinienvorgaben). Der Envelope wird auf Vollständigkeit und Stimmigkeit geprüft. Danach verifiziert Agent Identity den vorschlagenden Agenten gegen das maßgebliche Register; scheitert die Prüfung, wird die Aktion sofort abgelehnt und im Audit Log festgehalten. Das Controls Repository bestimmt, welche Kontrollen des Instituts gelten. Die Disposition Engine bewertet die Aktion gegen diese Kontrollen und liefert eines von vier verbindlichen Ergebnissen: Deny, Escalate, Auto-Execute oder Observe. Die Finanzinfrastruktur führt die Aktion genau dann aus, wenn das Ergebnis es zulässt, und das Audit Log zeichnet für jedes Ergebnis die vollständige Governance-Spur auf, Ablehnungen eingeschlossen.

Die Integrität des Envelope ist ein vorrangiges Designproblem. Aktionsspur und Aktionsdetails werden beide vom Agenten deklariert, und eine ausgefeilte gegnerische Injektion kann beides zugleich fälschen. Version 1.1 sagt das direkt: Der Governance Envelope sollte nicht als selbstverifizierend behandelt werden. Wo möglich, sollten die vom Agenten gelieferten Felder gegen Aufzeichnungen geprüft werden, die unabhängig vom Agenten erfasst wurden, etwa die auslösende Anweisung, die tatsächliche Aktionsnutzlast und systemseitig erzeugte Aufzeichnungen von Tool-Aufrufen und Datenzugriffen, und der Envelope sollte an den verifizierten Agenten, die Sitzung und das Mandat gebunden sein. In der Praxis führt das dazu, den Envelope an einer Stelle zu erfassen, die der Agent nicht fälschen kann (im Ausführungspfad oder an der Netzwerkgrenze), und es ist das stärkste Argument dafür, das Bereitstellungsmuster bewusst zu wählen.

Nativ oder Gateway: das Bereitstellungsmuster wählen¶

Das Whitepaper definiert zwei Integrationsmuster, und die meisten Institute werden am Ende beide betreiben. SAFR erklärt beschreibt die Mechanik beider Muster, die Ausgabe des Envelope im Agenten und das Abfangen durch ein Gateway auf Infrastrukturebene; die Umsetzungsentscheidung lautet, wann welches Muster passt.

Version 1.1 ergänzt einen Punkt zur Topologie: SAFR erfordert keine Umsetzung als einzelne zentrale Plattform innerhalb eines Instituts. Die Komponenten können als zentraler Dienst, innerhalb einzelner Agenteneinsätze, als gemeinsame institutsweite Dienste oder hybrid laufen, sofern jede Aktion im Anwendungsbereich vor der Ausführung die erforderlichen SAFR-Funktionen durchläuft und jede Implementierung gemeinsame Standards für Envelopes, Dispositionsergebnisse, Kontrollsemantik und Prüfbarkeit einhält.

Die Empfehlung zur Reihenfolge stammt direkt aus dem Papier: Für Institute mit vielen bestehenden Agenten ist das Gateway-Muster ein praktischer Ausgangspunkt, weil es zuerst Abdeckung herstellt; die native Instrumentierung kann für Neuentwicklungen folgen. Konkret: Neue Fähigkeiten werden vom ersten Tag an nativ instrumentiert, und vor den Bestand kommt ein Gateway. Betreiben Sie beide Muster mit einem Controls Repository, einer Disposition Engine und einem Audit Log, damit eine gemischte Landschaft einen einzigen, einheitlichen Governance-Nachweis erzeugt.

Was in SAFR-Kontrollen kodiert wird¶

Eine Kontrolle in SAFR legt fünf Dinge fest: zulässige Aktionstypen, Entscheidungslogik, Eskalationsbedingungen, eine Gültigkeitsdauer und die Befugnis des Prinzipals, unter der der Agent handelt. Kontrollen speisen sich aus vier Quellen: Unternehmensrichtlinien, regulatorischen Anforderungen, Produktregeln und Mandaten der Nutzer.

Das Mandat ist der Anker. Nach SAFR ist ein Mandat der Mechanismus, mit dem delegierte Befugnisse abgegrenzt und in maschinenlesbarer Form ausgedrückt werden: was der Agent tun darf, in welchen Grenzen und unter welchen Bedingungen. Ein Agent kann den Umfang eines Mandats nicht durch eigenes Schlussfolgern erweitern. Das Design steht in der Tradition der fähigkeitsbasierten Sicherheit (capability-based security), des Modells, auf dem auch OAuth 2.0 beruht; als prominentes Branchenbeispiel nennt das Papier das Agent Payments Protocol (AP2) mit seinen kryptografisch signierten Mandaten.

Das Papier ordnet die Kontrollen in vier Kategorien:

Kontrollen für einen Treasury-Zahlungsagenten kalibrieren¶

So sieht das kalibriert für einen Treasury-Zahlungsagenten aus. Die Werte sind beispielhaft; legen Sie Ihre eigenen anhand Ihrer Kompetenzordnung fest.

Bei einem Agenten für die Compliance-Triage (Anreicherung von Alerts, Vorschläge zur Risikoeinstufung, Vorbereitung von Meldungen) tragen die Schwellen für die Evidenzqualität die Hauptlast: Das automatische Schließen eines Alerts setzt voraus, dass der Nachweisvertrag auf oder über der Schwelle erfüllt ist, vorgeschlagene Hochrisiko-Einstufungen werden an einen namentlich benannten Prüfer eskaliert, und jede Aktion, die einen offenen Alert unterdrücken würde, wird ohne Weiteres abgelehnt. Diesen Prozess gehen wir durch alle vier Komponenten hindurch in SAFR für AML und Compliance-Triage durch.

Die vier Dispositionen kalibrieren¶

Jede Aktion im Anwendungsbereich erhält von der Disposition Engine eines von vier Ergebnissen:

Alle vier Ergebnisse fließen in das Audit Log ein. Die Zuordnung folgt fünf Kalibrierungsfaktoren, die das Papier nennt: Umkehrbarkeit der Aktion, finanzielle Wesentlichkeit, Schwere der Auswirkung auf Kunden, regulatorische Sensibilität sowie Neuartigkeit oder Anomalie, also die Abweichung von etablierten Mustern innerhalb des Mandats. Höhere Risikoprofile verschieben die Ergebnisse in Richtung Deny oder Escalate. Die Kalibrierung wird zur Entwurfszeit über die Governance-Parameter der Kontrollen festgelegt; deshalb sieht der Pilotplan unten eine volle Woche für die Abstimmung an realem Verkehr vor.

Observe verdient bewusste Gestaltung: Damit läuft eine neue Kontrolle gegen Live-Verkehr und erzeugt strukturiertes Prüfmaterial, während die Ausführung weiterläuft. Das ist die naheliegende Einstellung für Schwellen, die Sie verschärfen wollen, sobald Sie das reale Verhalten gesehen haben.

Kalibrieren Sie anhand der Historie. Als wir im Oktober 2026 in unseren eigenen Test-Tenants eine Bank-Onboarding-Übung mit gescripteten Personas für den Bankadministrator, den Compliance-Beauftragten und den Genehmiger durchführten, kamen wir zu dem Schluss, dass von Hand gebaute Richtlinien-Testfälle mit vielen Feldern nicht praktikabel sind: Ein Compliance-Beauftragter schreibt keine Unit-Tests für eine Richtlinie. Was funktioniert, ist, die letzten Läufe gegen die Entwürfe der Kontrollen erneut abzuspielen und die Veränderung gegenüber dem tatsächlichen Verlauf zu zeigen, etwa wie viele Aktionen zusätzlich zur menschlichen Prüfung gegangen wären. Diese Zahl ist die Frage der Prüfkapazität, und sie gehört vor die Menschen, die die Warteschlange besetzen werden.

Eskalationsbetrieb: vor dem Go-live gestalten¶

Das Papier beschreibt die heute typische Eskalation als Benachrichtigung, E-Mail oder Hinweis im Dashboard, ohne Frist, ohne einheitliches Entscheidungsformat, ohne Prüfnachweis. Das Papier nennt das den Anschein menschlicher Aufsicht ohne deren Substanz. Eine SAFR-Implementierung ersetzt das durch einen gestalteten Betrieb in drei Dimensionen.

Volumen. Eine Eskalationsfunktion, die mehr Prüfungen erzeugt, als das Institut sinnvoll bearbeiten kann, verfehlt nach dem Papier ihren Zweck. Bemessen Sie die Schwellen an der tatsächlichen Prüfkapazität; ergibt die Simulation mehr Escalate-Ergebnisse, als das Team bewältigen kann, korrigieren Sie die Kontrollen vor dem Start.

Bearbeitungszeit. Jede Eskalation sollte ein Zeitfenster haben. Trifft innerhalb dieses Fensters keine Entscheidung ein, wird die Aktion standardmäßig blockiert oder an einen höherrangigen Prüfer eskaliert. Legen Sie das Fenster anhand der realistischen Verfügbarkeit der Prüfer fest, einschließlich nachts und am Wochenende.

Befugnis. Prüfer brauchen die klare Befugnis, zu genehmigen, zu ändern oder abzulehnen, und ihre Entscheidungen haben dasselbe institutionelle Gewicht wie die ursprüngliche Agentenentscheidung. Das setzt namentlich benannte Prüfer voraus, eine dokumentierte Begründung bei jeder Entscheidung und Rollendefinitionen, die sich in Ihre bestehende Genehmigungshierarchie einfügen.

Jeden Schritt neu autorisieren¶

In mehrstufigen Prozessen gilt der Kontrollablauf für jede Agentenaktion einzeln. Ein Ergebnis Auto-Execute oder Observe in einem Schritt überträgt keine Befugnis auf den nächsten, weil sich der Agent bei der Arbeit an Zwischenergebnisse und veränderte Bedingungen anpasst.

Dieser eine Satz hat große Folgen für die Umsetzung. Der Bewertungspfad muss schnell genug sein, um bei jeder Aktion zu laufen; die Latenz gehört also von Anfang an ins technische Budget. Mandate müssen pro Aktion auflösbar sein. Das Zwischenspeichern von Freigaben auf Sitzungsebene ist durch das Design ausgeschlossen. Und ein Workflow mit zehn Schritten erzeugt zehn Governance-Spuren, jede mit eigenem Envelope, eigener Disposition und eigener Begründung: genau das, was ein Prüfer braucht, der den Lauf rekonstruiert.

Die Nachweisschicht: das SAFR Audit Log¶

Jeder Eintrag im Audit Log erfasst sechs Dinge: den eingereichten Governance Envelope, das Mandat, gegen das die Aktion geprüft wurde, das Ergebnis der Disposition Engine, die angewandten Regeln, die Begründung des Ergebnisses und die in jeder Phase verstrichene Zeit. Das Log ist unveränderlich, manipulationssicher und nur anfügend. Der Maßstab des Papiers: Das Log ist der maßgebliche Nachweis, unabhängig von jeder Partei, die ein Interesse daran hat, wie die Ereignisse im Nachhinein dargestellt werden.

Dieser Maßstab liegt über dem, was gewöhnliches Anwendungslogging leistet, und drei Eigenschaften müssen von Anfang an konstruiert werden: nur anfügende Schreibvorgänge, damit sich Datensätze ansammeln und nie verändern; Manipulationserkennung, in der Praxis durch kryptografische Verkettung, damit jede Änderung eines früheren Datensatzes erkennbar ist; und unabhängige Überprüfbarkeit, sodass ein Prüfer die Integrität eines exportierten Nachweises ohne Zugang zur erzeugenden Plattform bestätigen kann. Speichern Sie den Nachweis, bevor Sie die Disposition zurückgeben. Kann eine Aktion ausgeführt werden, während ihr Nachweis noch unterwegs ist, kann ein Absturz ausgeführte Aktionen ohne Governance-Spur hinterlassen.

Ein ausgearbeitetes Mandat mit Entscheidungsnachweis¶

Das folgende Beispiel ist synthetisch. Die Northbridge Bank ist fiktiv, und Namen, Beträge und Kennungen sind beispielhaft. Es verwendet die Treasury-Kalibrierung von oben und verfolgt ein Mandat von der Delegation bis zum Nachweis.

Das Mandat. Die Leitung von Treasury Operations der Northbridge Bank delegiert Lieferanten- und konzerninterne Zahlungen an einen registrierten Agenten, treasury-payments, Release 3.2. Das Mandat ist die schriftliche Grenze dieser Delegation. Das Institut erstellt es aus seiner bestehenden Kompetenzordnung, versioniert es und genehmigt es im selben Prüfverfahren, das es für Richtlinienänderungen nutzt.

Die Delegationsgrenze und die vier Ergebnisse¶

Die letzten beiden Zeilen des Mandats ziehen die Delegationsgrenze. Alles außerhalb wird abgelehnt, gleich welche Begründung der Agent liefert, denn ein Agent kann den Umfang eines Mandats nicht durch eigenes Schlussfolgern erweitern. Innerhalb der Grenze ordnen die Kontrollen jede vorgeschlagene Aktion einer der vier SAFR-Dispositionen zu. KLA Control Plane drückt dieselben vier Ergebnisse als allow, warn, require_approval und block aus.

Vier Aktionen, die der Agent an einem Vormittag vorgeschlagen hat, zeigen jedes Ergebnis. Jede Zeile wurde für sich bewertet, ohne dass Befugnisse aus der vorherigen Zeile übernommen wurden.

Ein Genehmigungsfall von Anfang bis Ende¶

09:41. Der Agent schlägt die Zahlung über 118.000 US-Dollar vor. Der Envelope enthält den Zahlungsauftrag, die Aktionsspur (Rechnungsabfrage, Vertragsabfrage, Prüfung des Empfängers) und den Kontext: Agentenidentität, Mandat in Version 2 und die bisherige 24-Stunden-Summe von 212.000 US-Dollar. Die Identitätsprüfung ist erfolgreich. Die Kontrolle pro Aktion liefert Escalate; die kumulierte Kontrolle ist bestanden, nach dieser Zahlung bleiben 170.000 US-Dollar Spielraum.

09:41. Die Aktion wird angehalten. Eine Prüfanfrage geht an die Treasury-Genehmigergruppe, mit der vorgeschlagenen Aktion, der Rechnung und den ausgelösten Kontrollen. Northbridge setzt für diese Eskalationsklasse ein Zeitfenster von vier Stunden, mit block als Standard.

10:17. Eine Treasury-Managerin öffnet die Anfrage, vergleicht die Rechnung mit der Bestellung und dem Rahmenvertrag und genehmigt mit der Begründung „Jährliche Lizenzverlängerung; PO 4471 und MSA-Klausel 6.2 stimmen mit Rechnung INV-20931 überein.“ Die Genehmigung gilt nur für diese Zahlung.

10:17. Die Zahlung wird an die Zahlungsinfrastruktur freigegeben, die eine Zahlungsreferenz zurückgibt. Der Nachweis schließt mit dem Ausführungsergebnis.

Zwei Gestaltungsentscheidungen in diesem Fall stammen aus einem Prozess zur Freigabe angehaltener Zahlungen, den wir im Oktober 2026 für ein Analystenbriefing in unserem eigenen Demo-Tenant mit synthetischen Zahlungen gebaut haben. Erstens hat jede menschliche Entscheidung genau ein Genehmigungs-Gate. Unsere erste Einreichung dieses Prozesses zur Prüfung wurde abgelehnt, weil zwei menschliche Schritte zusätzlich ein eigenes Genehmigungsflag trugen; das hätte für eine Entscheidung zwei Genehmigungsaufgaben erzeugt. Wir haben die Flags entfernt und ein Gate pro Entscheidung beibehalten. Zweitens leitet die Richtlinie jeden Fall, den keine Regel vorhergesehen hat, auf require_approval. In unserer frühesten AML-Testrichtlinie war der Standard ohne Regeltreffer block, sodass unvorhergesehene Fälle stoppten, ohne je einen Prüfer zu erreichen.

Hätte die Managerin bis 13:41 nicht reagiert, wäre die Anfrage abgelaufen und die Aktion blockiert worden, mit aufgezeichnetem Ablauf. Hätte sie abgelehnt, hätte der Agent ein block mit der Begründung der Prüferin erhalten, und ein neuer Vorschlag für dieselbe Zahlung würde von Anfang an neu bewertet.

Der Nachweis, den der Fall hinterlässt¶

SAFR nennt die Elemente, die jeder Audit-Eintrag erfassen sollte: den eingereichten Envelope, das Mandat, gegen das die Aktion geprüft wurde, das Ergebnis, die angewandten Regeln, die Begründung des Ergebnisses und die in jeder Phase verstrichene Zeit. Der Genehmigungsfall ergänzt die menschliche Entscheidung und das Ausführungsergebnis. Die Tabelle zeigt den Nachweis für die Zahlung über 118.000 US-Dollar.

Genehmigung und Abwicklung sind getrennte Nachweise. Im Showcase zur Freigabe angehaltener Zahlungen sind die Freigabegenehmigung und der bestätigte Abwicklungsstatus zwei getrennte Einträge, und eine Zahlung ist erst abgeschlossen, wenn die Abwicklungsreferenz aufgezeichnet ist. Wir halten sie getrennt, weil eine Genehmigung eine Entscheidung belegt und nur die Zahlungsinfrastruktur bestätigen kann, dass das Geld geflossen ist.

Drei Grenzen gehören zu jeder ehrlichen Lesart dieses Nachweises. Er zeigt, was der Agent vorgeschlagen hat, welche Regeln galten, wer entschieden hat und was die Zahlungsinfrastruktur zurückgegeben hat. Er zeigt nicht, dass der Lieferant das Geld erhalten hat; das ergibt sich aus Abwicklungs- und Abstimmungsnachweisen. Er belegt auch nicht, dass die Rechnung echt ist; die Kontrolle der Evidenzqualität prüft die Zuordnung, und Betrugskontrollen liegen an anderer Stelle im Zahlungsprozess. Ein Prüfer sollte diese Grenzen aus dem Nachweis ablesen können, ohne nachfragen zu müssen.

Make-or-Buy für die SAFR-Laufzeitschicht¶

SAFR ist ein Referenzansatz und lässt die Wahl der Software offen. Ein Hinweis vor der Analyse: KLA ist Anbieter in dieser Kategorie. KLA Control Plane setzt das SAFR-Muster um und ist heute verfügbar. Lesen Sie das Folgende mit diesem Wissen.

Eigenbau bedeutet, sechs Teilsysteme aufzubauen:

Zusammen sind die sechs Teilsysteme ein Vorhaben im Umfang einer Plattform, und die realistische Planungseinheit sind Team-Quartale. Die Arbeit geht nach dem Start weiter: Kalibrierung ist eine laufende Betriebsaufgabe, weil sich Schwellen mit Transaktionsvolumen, Produktänderungen und Prüfkapazität verschieben.

Eigenbau lohnt sich, wenn Sie ein starkes internes Plattformteam haben, das die Schicht als Produkt verantworten wird, wenn Ihre Zahlungs- oder Abwicklungsinfrastruktur so individuell ist, dass ein Standard-Kontrollpunkt nicht davor sitzen kann, oder wenn angrenzende Systeme, die Sie bereits betreiben (Berechtigungsverwaltung, Fallbearbeitung, Richtlinienwerkzeuge), echte Teile der obigen Tabelle abdecken.

Kauf lohnt sich, wenn innerhalb eines Quartals gesteuerte Abdeckung und exportierbare Nachweise Vorrang haben, wenn kein Plattformteam für sechs Teilsysteme verfügbar ist oder wenn Prüfer unabhängig überprüfbare Nachweise früher verlangen werden, als eine interne Roadmap sie liefern kann.

Die hybride Lösung ist oft die ehrliche Antwort: den Laufzeit-Kontrollpunkt kaufen (Register, Disposition Engine, Eskalationsprozess, Nachweisspeicher) und das Erstellen der Kontrollen im Haus behalten. Diese Aufteilung entspricht SAFR selbst: Das Framework standardisiert Datenstrukturen und Verträge, während Regelkonfigurationen und Governance-Regelungen beim Institut bleiben. In einem hybriden Modell verantworten Ihre Risiko- und Compliance-Teams, was die Kontrollen aussagen, und der Anbieter betreibt die Mechanik, die sie durchsetzt und belegt.

Zu KLA im Einzelnen: KLA Control Plane bildet SAFR Komponente für Komponente ab (Agent Registry, Policy Builder, KLA Policy Engine, Audit Trail), mit den vier Dispositionen als allow, warn, require_approval und block. Autorisierung pro Aktion, Fail-closed-Bewertung und Sealed Evidence Bundles mit Offline-Verifizierung sind ausgeliefert. Kumulierte Exposure-Fenster, Ratenlimits pro Zeitfenster, Konfidenzschwellen als Routing-Baustein, Standard-Zeitfenster für Eskalationen je Klasse und das eigenständige Gateway sind in Entwicklung. Die Zuordnung Komponente für Komponente mit Statusangaben zu jeder Anforderung steht auf unserer Seite SAFR-Implementierung.

Ein vierwöchiger SAFR-Pilot¶

Eine glaubwürdige erste Implementierung passt in vier Wochen für einen abgegrenzten Prozess, und der Plan funktioniert unabhängig davon, ob die Schicht darunter selbst gebaut, gekauft oder hybrid ist.

Bestimmen Sie vor Woche eins Ihren Stand. Die SAFR Readiness Checklist ist eine interaktive Lückenanalyse in acht Abschnitten, von der Agentenidentität bis zum Bereitstellungsmuster, mit den Nachweisen, die ein Prüfer zu jeder Frage verlangen würde.