Wenn ein autonomes AI-System unzuverlässig ist, liegt der erste Reflex darin, das Modell zu wechseln. Grösseres Modell, neueres Modell, feiner abgestimmtes Modell. In zwei Jahren regulierter Mandate habe ich diesen Reflex regelmässig beobachtet, und in genau einem Fall hat er das eigentliche Problem gelöst. In allen anderen Fällen lag die Ursache der Unzuverlässigkeit nicht im Modell, sondern in der Architektur.
Was Klienten meinen, wenn sie Reliability sagen
Drei Bedeutungen tauchen am häufigsten auf, und sie werden oft verwechselt. Die erste ist Konsistenz, also dieselbe Eingabe ergibt dieselbe Ausgabe. Die zweite ist Robustheit, also das System verhält sich auch bei abweichenden Eingaben sinnvoll. Die dritte ist Auditierbarkeit, also es lässt sich später nachvollziehen, warum eine Entscheidung so getroffen wurde. Modellverbesserungen helfen vor allem bei der zweiten Bedeutung. Bei der ersten und dritten sind sie nahezu wirkungslos, weil dort Architekturentscheidungen den Unterschied machen.
Wo die meisten Architekturen brechen
Aus den Mandaten der letzten Jahre haben sich vier wiederkehrende Schwachstellen herauskristallisiert. Erstens, die Übergabe zwischen Modell-Output und Geschäftsprozess ist häufig undokumentiert. Was als strukturierte Antwort des Modells beginnt, wird in nachgelagerten Schritten so umgeformt, dass die ursprüngliche Information verloren geht. Zweitens, der Zustand des Systems ist nicht konserviert. Welcher Modellstand, welche Konfiguration, welche Datenbasis zum Zeitpunkt einer Entscheidung aktiv waren, wird selten festgehalten. Drittens, Fehlerpfade sind nicht erstrangig. Was passiert, wenn das Modell keine Antwort liefert oder eine Antwort, die offensichtlich falsch ist? Viertens, Reversibilität ist kein Designkriterium. Entscheidungen werden gefällt, ohne dass ihre Rückgängigmachung mitgedacht wird.
Was Architektur leisten kann, was Modelle nicht können
Architektur kann Konsistenz erzeugen, indem sie Determinismus an den Stellen einführt, wo Determinismus möglich ist. Sie kann Auditierbarkeit erzwingen, indem sie jeden Zustand persistiert, der für eine spätere Rekonstruktion nötig ist. Sie kann Reversibilität herstellen, indem sie Entscheidungen mit Kompensationsschritten paart. Und sie kann das Verhalten in Grenzfällen bestimmen, indem sie Fallback-Pfade vorab spezifiziert. Keine dieser vier Eigenschaften wird durch ein leistungsfähigeres Modell verbessert, alle vier werden durch eine schlechte Architektur untergraben.
Die Falle der Modell-Iteration
In mehreren Mandaten haben Klienten Monate damit verbracht, Modelle zu vergleichen, zu evaluieren und zu wechseln. Die Resultate waren in allen Fällen marginal, gemessen an den Anforderungen, die die Aufsicht stellte. Im selben Zeitraum hätten dieselben Teams die Übergabe-Schichten, das Zustandsmanagement und die Fallback-Logik überarbeiten können. Das wäre messbar wirksamer gewesen, wäre aber als Architekturarbeit weniger sichtbar als ein neues Modell, das im Datenblatt drei Prozentpunkte besser abschneidet.
Wie AAIA Trinity STAR diese Diagnose adressiert
Die Säule Architektur im Trinity-Modell behandelt Reliability nicht als Eigenschaft des Modells, sondern als Eigenschaft des Gesamtsystems. Die vier STAR-Risikoachsen, Security, Traceability, Accountability und Reversibility, sind genau die Achsen, an denen Architektur den Unterschied macht. Modelle erscheinen in diesem Modell als austauschbare Komponenten, die Architektur ist das, was bleibt. Eine ausführliche Beschreibung findet sich auf /aaia-trinity-star.
Die einzige sinnvolle Reihenfolge
Bevor an einem Modell etwas verändert wird, sollten drei Fragen beantwortet sein. Erstens, ist die Übergabe zwischen Modell und Prozess vollständig spezifiziert. Zweitens, ist der Zustand zum Zeitpunkt jeder Entscheidung rekonstruierbar. Drittens, gibt es für jeden Modellausfall einen vordefinierten Fallback-Pfad. Wenn eine dieser drei Fragen verneint wird, ist Modell-Iteration die falsche Investition.
Lesen Sie weiter
Im dritten Beitrag dieser Reihe, Schweizer Compliance als Design-Philosophie, wird die regulatorische Strenge der DACH-Region als Konstruktionsprinzip beschrieben, nicht als Hindernis. Den ersten Beitrag dieser Reihe, Warum ich AAIA Trinity gebaut habe, finden Sie hier.