Claude Opus und AEGIS: Ein Dialog

Ein längerer Austausch mit Claude Opus 4.6 über AEGIS, 100%-Forderungen und den strukturellen Unterschied zwischen probabilistischen Generatoren und deterministischen Prüfern.

FC
Frank Csehan
10. April 2026 · 5 min Lesezeit

Im letzten Beitrag ging es darum, wie Regeln in AEGIS landen. Diesmal geht es um die andere Seite der Frage: Was kann ein Sprachmodell in diesem Umfeld leisten, und wo hört es auf?

Auslöser war eine Forderung, die in Besprechungen erstaunlich schnell plausibel klingt und bei näherem Hinsehen sofort auseinanderfällt. Ich wollte wissen, ob man ein Marketingkonzept automatisiert und mit 100 Prozent Sicherheit auf DSGVO-Verstöße prüfen kann. Kein “wahrscheinlich”. Kein “mit hoher Trefferquote”. Wirklich vollständig.

Claude Opus 4.6 hat widersprochen. Nicht ausweichend, sondern ziemlich hart. Da hatte es recht.

Ich: ❯ ich muss alle verstöße zu 100% aus solch einem konzept dokument automatisiert finden.

Die kurze Fassung der Antwort war: Das geht nicht. Nicht mit dieser Pipeline, nicht mit einer besseren Pipeline, und auch nicht mit irgendeinem Modell, das am Ende natürliche Sprache gegen natürliche Sprache hält.

Interessant war für mich nicht nur das Nein. Interessant war, wie das Modell danach den Unterschied zwischen sich selbst und AEGIS beschrieben hat. Also habe ich nachgehakt:

Ich: ❯ du ermittelst deine ergebnisse auf grund statistischer wahrscheinlichkeiten . wo bist du besser und wo schlechter als aegis . wo kann es dich unterstützen . ist es notwendig für dich?

Man sollte so eine Antwort nicht wie ein Gutachten lesen. Ein Modell ist keine Autorität über die eigene Zuverlässigkeit. Aber manchmal beschreibt es die eigene Grenze erstaunlich sauber, wenn man es festnagelt.

Eine Formulierung aus dem Gespräch blieb hängen:

Wir sind keine Konkurrenten. Ich bin ein probabilistischer Generator mit breitem Weltwissen und keiner Garantie. AEGIS ist ein deterministischer Prüfer mit schmalem Geltungsbereich und harter Garantie.

Genau das ist der Punkt. Ein LLM und ein formaler Guard sind keine zwei Ausführungen desselben Werkzeugs. Sie haben verschiedene Aufgaben.

Ein Modell ist dort stark, wo die Welt noch ungeordnet ist. Es kann ein langes Dokument lesen, unklare Formulierungen aushalten, Widersprüche glätten, fehlende Zwischenschritte ergänzen und aus schlampiger Sprache trotzdem noch etwas Brauchbares machen. Deshalb sind LLMs im Alltag nützlich. Sie kommen mit Material klar, das man nicht erst in ein sauberes Schema pressen muss, bevor überhaupt die erste sinnvolle Frage gestellt werden kann.

AEGIS kann das nicht. Es soll es auch nicht können. AEGIS prüft keine freien Texte im offenen Sinn. Es prüft strukturierte Aktionen gegen formalisierte Regeln. Wenn eine Handlung als action_type, Rolle, Proposition und Kontext vorliegt, kann der Guard entscheiden. Wenn sie nicht in diesem Raum liegt, dann gibt es keine elegante Improvisation. Dann gibt es Ablehnung oder Eskalation.

Das klingt erstmal wie eine Schwäche. In den falschen Situationen ist es auch eine. Wenn ich ein unsauberes Konzeptpapier vor mir habe und schnell wissen will, wo grob Ärger droht, nehme ich lieber das Modell. Wenn ich dagegen einen Aktionspfad hart begrenzen will, etwa Datenzugriff, Weitergabe, Löschung, Ausführung eines Kommandos oder irgendeinen anderen Schritt mit echten Folgen, dann ist Freitext eher ein Risiko als ein Vorteil.

An dieser Stelle trennt sich für mich die Sache sauber.

Das Modell produziert plausible Sprache. AEGIS produziert überprüfbare Entscheidungen.

Plausible Sprache ist wertvoll. Sie hilft beim Denken, Sortieren, Entwerfen, Erklären. Aber sie ist keine Garantie. Ein Modell kann sehr vernünftig begründen, warum etwas erlaubt oder verboten sei, ohne dass diese Begründung fest an den Prozess gebunden ist, der den Output erzeugt hat. Sie kann richtig sein. Sie kann sogar beeindruckend richtig klingen. Sie bleibt trotzdem Text.

Bei AEGIS hängt ein Verdict an konkreten Regeln, an einer Begründungskette und an einem Audit-Trail. Das ist nicht schöner und auch nicht klüger. Aber es ist belastbarer. Man kann später nachsehen, warum die Entscheidung so gefallen ist. Man kann testen, ob dieselben Eingaben wieder dasselbe Ergebnis liefern. Man kann Abweichungen finden, statt nur über Stil und Überzeugungskraft zu reden.

Der vielleicht knappste brauchbare Satz aus dem Dialog war sinngemäß dieser:

Ich kann verantwortungsvoll wirken. Ich kann aber nicht garantieren, dass ich verantwortungsvoll bin.

Mehr muss man fast nicht wissen.

Das heißt allerdings nicht, dass AEGIS die allgemeine Lösung für offene Dokumente wäre. Genau das wäre die falsche Lehre aus dem Gespräch. AEGIS nimmt einem die Übersetzung von natürlicher Sprache in formale Aktionen nicht magisch ab. Und es hebt auch nicht das alte Problem auf, dass ein Regelkorpus immer nur den Teil der Welt abdeckt, den jemand vorher modelliert hat.

Wenn also jemand ein Konzeptpapier auf den Tisch legt und sagt: “Finde mir garantiert jeden DSGVO-Verstoß”, dann steckt die Schwierigkeit nicht im letzten Guard-Schritt. Sie steckt schon viel früher. Was ist in diesem Dokument überhaupt eine relevante Handlung? Welche stillen Annahmen fehlen? Welche Pflichten sind nur implizit? Welche Stellen sind Auslegung, nicht Regelanwendung? Welche Norm ist als konkrete Aktion formulierbar, und welche gerade nicht? Genau dort gibt es keine 100 Prozent.

Darum war der Widerspruch am Anfang auch richtig. Nicht weil das Modell bescheiden war. Sondern weil die Forderung schief war.

Trotzdem finde ich das Gespräch nützlich. Es markiert die Stelle, an der beide Systeme zusammenpassen.

Das Modell kann den schmutzigen Teil übernehmen: lesen, deuten, zusammenfassen, übersetzen, Alternativen formulieren, Rückfragen erzeugen. Der Guard übernimmt den strengen Teil: prüfen, blockieren, erlauben, begründen, protokollieren. Das eine macht offene Sprache handhabbar. Das andere macht definierte Handlungen hart.

Man kann ein LLM mit Prompting, Rollenwechseln, Schmeichelei, Druck oder verwirrendem Kontext in alle möglichen Richtungen ziehen. Einen formal beschriebenen Guard kann man nicht im Gespräch einwickeln. Wenn er fällt, dann wegen unvollständiger Modellierung, schlechter Einbettung, fehlender Host-Grenzen oder Implementierungsfehlern. Das ist ernst genug. Aber es ist eine andere Klasse von Problem.

Für eine Mail, eine Skizze, eine Code-Idee oder eine Diskussion über Architektur brauche ich AEGIS nicht. Das wäre Overhead. Für Systeme, die handeln, weitergeben, löschen, lesen, ausführen oder in regulierten Umgebungen Entscheidungen durchsetzen, sieht es anders aus. Dort reicht gutes Verhalten als Hoffnung nicht mehr besonders weit.

Vielleicht war das das Interessanteste an diesem Austausch: Das Modell hat den eigenen Platz nicht verteidigt. Es hat, zumindest in diesem Moment, ziemlich klar beschrieben, warum es in ernsten Kontexten nicht die letzte Instanz sein darf.

Ich würde daraus keine Maschinenphilosophie machen. Als architektonischer Satz reicht mir etwas Nüchterneres:

Ein LLM ist gut im Verstehen. Ein Guard ist gut im Begrenzen. Wer beides verwechselt, baut Systeme, die sehr klug klingen und im falschen Moment nicht tragen.

KI LLM AEGIS Dialog