Vor zwei Jahren stand ich in einem Sitzungszimmer einer Schweizer Bank und beantwortete dieselbe Frage zum vierten Mal in einem Quartal. Ein Vorstand wollte wissen, wie ein autonomer AI-Agent eine Compliance-Entscheidung treffen darf, ohne dass die Aufsicht später eine Rechtfertigung verlangt, die niemand mehr rekonstruieren kann. Es gab keine Antwort, die beide Seiten zufriedenstellte. Aus diesem Moment ist AAIA Trinity STAR entstanden.
Das Problem hinter der Frage
Die Frage selbst ist banal, ihre Implikation nicht. Ein autonomer AI-Agent verändert in einer regulierten Branche nicht nur die Geschwindigkeit von Entscheidungen, sondern die Verteilung von Verantwortung. Wer haftet, wenn das Modell den Risiko-Score falsch berechnet? Wer beweist im Streitfall, welcher Modellstand zum Zeitpunkt der Entscheidung aktiv war? Diese Fragen haben in den letzten zwei Jahren in jedem Mandat eine Rolle gespielt, in Banking, Pharma und in der Industrie. Die Antworten der Hersteller waren in den meisten Fällen unzureichend, weil sie die Architektur als technisches Problem behandelt haben, nicht als regulatorisches.
Drei Beobachtungen, die alles verändert haben
Im Verlauf von vierundzwanzig Mandaten haben sich drei Beobachtungen verfestigt. Erstens, die meisten Vorhaben scheitern nicht am Modell, sondern an der Übergabe zwischen Modell und Geschäftsprozess. Zweitens, die regulatorische Last lässt sich nicht nach hinten verschieben, sie muss in die Architektur eingebaut werden, sonst rächt sich der erste Audit. Drittens, die Sprache zwischen IT, Fachbereich und Aufsicht ist die eigentliche Schwachstelle, nicht die Technik.
Warum eine eigene Referenzarchitektur
Es gibt genug Frameworks, das ist nicht das Problem. Das Problem ist, dass keines die drei Sprachen gleichzeitig spricht. Ein Architektur-Framework wie TOGAF beantwortet die Frage des Vorstands nicht. Ein Compliance-Framework wie COSO beantwortet die Frage des Architekten nicht. Und kein etabliertes Framework war für autonome Agenten gedacht, weil es sie zur Entstehungszeit dieser Frameworks schlicht nicht gab. AAIA Trinity STAR füllt diese Lücke. Drei Säulen, vier Risikoachsen, eine gemeinsame Sprache, die in einem dreissigminütigen Vorstandsgespräch erklärbar ist und gleichzeitig in einem Architektur-Dossier präzise genug ist, um daraus zu implementieren.
Was Trinity nicht ist
Es ist kein Produkt, kein SaaS, kein lizenziertes Werk. Es ist eine Referenzmethodik, frei nutzbar, dokumentiert auf /aaia-trinity-star. Wer das Framework anwenden möchte, braucht weder mich noch eine Beratungsfirma. Es ist als Grundlage gedacht, von der aus Teams ihre eigene Implementierung ableiten. Mein eigener Beitrag besteht in der Begleitung der ersten Phasen, wenn Klienten das Framework auf ihren konkreten Anwendungsfall übertragen wollen, und in der Pflege der Methodik selbst.
Was als Nächstes kommt
Die nächsten Beiträge in dieser Reihe behandeln zwei Themen, die in jedem Mandat aufkommen. Im zweiten Beitrag, Reliability ist kein Modellproblem, geht es um die hartnäckige Annahme, dass bessere Modelle robustere Systeme ergeben. Im dritten Beitrag, Schweizer Compliance als Design-Philosophie, wird der regulatorische Rahmen nicht als Hindernis, sondern als Konstruktionsprinzip beschrieben.
Wenn Sie das Framework auf Ihren Fall anwenden möchten
Ein dreissigminütiges Erstgespräch klärt, ob das Framework zu Ihrem Vorhaben passt. Es kostet nichts und endet entweder mit einer klaren Empfehlung oder mit einer Absage. Beides ist nützlicher als ein langer Sales-Prozess.