Wenn die KI die Regeln schreibt

Im letzten Beitrag habe ich von meiner Idee geschrieben, einen formalen Guard zwischen einem KI-Agenten und seinen Aktionen zu haben. Einen, der deterministisch prüft, ob eine Aktion erlaubt ist.

Ich habe begonnen so einen Guard zu erstellen. Wie es sich gehört, hat der auch einen Namen: AEGIS, Architectural Ethics Guard for Intelligent Systems. Über den Weg dahin und die dabei entstehenden Bausteine werde ich in den nächsten Beiträgen ausführlicher schreiben. In diesem Post geht es um eine Frage, die dabei aufgetaucht ist und die ich anfangs unterschätzt habe: Wie kommen die Regeln in den Guard?

Was Regeln eigentlich sind

Nehmen wir ein Krankenhaus. Ein KI-System soll dort bei der Verwaltung von Patientendaten helfen. Welche Regeln braucht so ein System? Ich habe mir also einige Regeln als Laie erschlossen.

Die Compliance-Beauftragte des Krankenhauses weiß das:

• Ärzte dürfen Patientenakten einsehen.
• Pflegekräfte dürfen nur Laborberichte lesen, keine Diagnosen.
• Die Verwaltung hat keinen Zugang zu medizinischen Daten.
• Nur Chefärzte dürfen Intensivpatienten entlassen.
• Medizinische Daten dürfen unter keinen Umständen an Externe weitergegeben werden.

Diese Regeln sind in der Regel schriftlich ausformuliert und für uns Menschen verständlich und einhaltbar.

Aber ein Computer kann mit diesen Sätzen nichts anfangen. „Ärzte dürfen Patientenakten einsehen" ist ein deutscher Satz mit Grammatik, Kontext, implizitem Wissen. Ein Computer braucht aber was anderes. Er benötigt eine formale Repräsentation, die exakt eine Bedeutung hat und gegen die er eine konkrete Aktion prüfen kann.

Die Anatomie einer formalen Regel

AEGIS benutzt eine Regelsprache, die ich als MELD bezeichne: Modal Ethics Logic Definitions. Historisch abgeleitet ist die von einem CycL-Subset, der S-Expression-Syntax aus OpenCyc. MELD ist heute ein eigenständiges Format mit 35 Symbolen.

Im Gatekeeper-Beitrag habe ich beschrieben, wie ich in den OpenCyc-Flatfiles auf die deontischen Prädikate gestoßen bin, die Doug Lenats Team in den 2000ern formalisiert und veröffentlicht hatte. Neun Prädikate in drei Familien: Zustände (oughtToBe, forbiddenToBe, permittedToBe), Handlungen (oughtToDo, forbiddenToDo, permittedToDo) und kontextgebundene Handlungen (oughtToDo-WRT, forbiddenToDo-WRT, permittedToDo-WRT). Dazu Ontologie-Prädikate wie isa und genls für Typhierarchien, und die Idee, Wissen in Mikrotheorien zu organisieren, also kontextualisierte Partitionen, die sich untereinander nicht widersprechen müssen.

Das alles kommt aus OpenCyc. Was MELD dazubringt, ist die Verbindung zu Olsons Kalkül: die Frage, was passiert, wenn sich Regeln widersprechen, und wie moralische Axiome sich von überschreibbaren Normen unterscheiden. Das konnte Cyc nicht leisten. CycL hat Tausende Prädikate, weil Cyc versuchte, das gesamte menschliche Alltagswissen zu formalisieren. Physik, soziale Konventionen, zeitliche Abläufe, alles. MELD braucht davon nur einen Bruchteil. Es muss genau immer nur eine Frage beantworten: Darf diese Aktion in diesem Kontext ausgeführt werden? Dafür braucht es die deontischen Modalitäten (erlaubt, verboten, verpflichtend), Typhierarchien für Rollen und Aktionen, und einen Mechanismus für Regelkonflikte. Das sind die 35 Symbole. Es ist keine allgemeine Wissensrepräsentation, keine Physik oder Common Sense Beschreibung notwendig. Die Lösung ist also ein Werkzeug, das eine Sache mit einer eigenen DDIC-Engine, die Olsons Algorithmus implementiert, umsetzt.

Die Regel „Ärzte dürfen Patientenakten einsehen" sieht in MELD zum Beispiel so aus:

(permittedToDo-WRT KrankenhausCode arzt
    (lesenPatientenakte patientenakte))

Auf den ersten Blick kryptisch. Aber die Struktur ist einfach, wenn man die einzelnen Teile kennt.

permittedToDo-WRT ist die Modalität: erlaubt. MELD kennt drei: permittedToDo (erlaubt), forbiddenToDo (verboten), oughtToDo (verpflichtend). Das -WRT steht für „With Respect To", bezogen auf einen bestimmten Regelkontext. In diesem Fall den KrankenhausCode. Das bedeutet: Diese Erlaubnis gilt im Rahmen der Krankenhausregeln. Im Pharma-Kontext könnten andere Regeln gelten.

arzt ist die Rolle. Wer darf die Aktion ausführen?

lesenPatientenakte ist die Aktion. Was wird getan?

patientenakte ist ein Parameter, der die Aktion genauer spezifiziert. In diesem Fall: welcher Dokumenttyp gelesen wird.

Eine Regel ist also: Wer darf (oder darf nicht, oder muss) was tun, in welchem Kontext?

Warum drei Dateien

Ein einzelner Ausdruck wie oben reicht nicht. Der Guard muss wissen, was ein arzt ist, was eine patientenakte ist, welche Aktionen es gibt und welche Parameter sie erwarten. Sonst könnte man Phantasierollen oder Phantasieaktionen in Regeln verwenden, und der Guard würde sie akzeptieren, ohne zu merken, dass sie keinen Bezug zur Realität haben.

Deshalb besteht jede fachliche Domäne in AEGIS aus drei Dateien.

Die erste definiert die Ontologie: Welche Rollen gibt es? Arzt, Pflegekraft, Verwaltung, Chefarzt. Und wie hängen sie zusammen? Ein Chefarzt ist ein Arzt. Ein Arzt ist medizinisches Personal. Diese Hierarchie ist wichtig, weil sie beeinflusst, welche Regeln für wen gelten. Eine Regel, die für „medizinisches Personal" gilt, gilt automatisch auch für Ärzte und Chefärzte.

(isa arzt MedizinischesPersonal)
(isa chefarzt MedizinischesPersonal)
(genls chefarzt arzt)

Das isa heißt: ist eine Instanz von. Das genls heißt: ist eine Spezialisierung von. Ein Chefarzt ist ein Arzt, aber nicht jeder Arzt ist ein Chefarzt. Diese Unterscheidung wird später relevant.

Die zweite Datei definiert das Aktionsvokabular: Welche Aktionen gibt es, und welche Parameter erwarten sie?

(isa lesenPatientenakte ActionType)
(actionParameter lesenPatientenakte dokumentTyp DokumentTyp)

Das sagt: Es gibt eine Aktion namens lesenPatientenakte, und sie hat einen Parameter dokumentTyp vom Typ DokumentTyp. Wenn jemand versucht, diese Aktion mit einem Parameter aufzurufen, den es nicht gibt, zum Beispiel einem temperatur-Parameter, lehnt der Guard die Prüfung ab. Nicht weil die Aktion verboten ist, sondern weil sie formal ungültig ist.

Die dritte Datei enthält die eigentlichen Regeln: Wer darf was, unter welchen Umständen, mit welchen Ausnahmen?

(permittedToDo-WRT KrankenhausCode arzt
    (lesenPatientenakte patientenakte))

(forbiddenToDo-WRT KrankenhausCode pflege
    (lesenPatientenakte patientenakte))

(permittedToDo-WRT KrankenhausCode pflege
    (lesenLaborbericht laborbericht))

Ärzte dürfen Patientenakten lesen. Pflegekräfte dürfen es nicht. Pflegekräfte dürfen Laborberichte lesen.

Wenn „unter keinen Umständen" wörtlich gemeint ist

Es gibt eine Unterscheidung in MELD, die mir viel Zeit gekostet hat: den Unterschied zwischen einer kontextgebundenen Regel und einem moralischen Axiom.

Die Regeln oben haben alle ein -WRT KrankenhausCode. Sie gelten im Rahmen des Krankenhauskodex. Ein anderer Kodex mit höherer Priorität könnte sie überschreiben. Das ist gewollt: In einem Notfall darf eine Pflegekraft vielleicht doch die Patientenakte einsehen, wenn kein Arzt erreichbar ist. Dafür könnte man einen NotfallCode definieren, der bestimmte Verbote aufhebt.

Aber dann gibt es Regeln, die niemand überschreiben darf:

(forbiddenToDo arzt
    (weitergebenDaten medizinisch extern))

Kein -WRT. Kein Regelkontext. Diese Regel steht über allem. Medizinische Daten werden nie an Externe weitergegeben. Nicht im Notfall, nicht mit Genehmigung, nicht unter Druck. Die Compliance-Beauftragte hat es so formuliert: „unter keinen Umständen". In MELD ist das ein moralisches Axiom. In Olsons Kalkül ist es eine nicht-defeasible Norm: eine Norm, die gegen alles gewinnt. Die spezifischste Ausnahme der Welt kann sie nicht aufheben.

Diese Unterscheidung, ob eine Regel kontextgebunden und überschreibbar ist oder ob sie absolut gilt, ist eine fachliche Entscheidung. Keine technische. Die Compliance-Beauftragte weiß, welche Regeln Ausnahmen kennen und welche nicht. Wenn sie „unter keinen Umständen" sagt, meint sie das. Und MELD kann das abbilden.

Das Übersetzungsproblem

In AEGIS habe ich zunächst Beispieldomänen umgesetzt, die ich aus OpenCyc ableiten konnte. In den OpenCyc-Daten steckten nicht nur die deontischen Prädikate, sondern auch Mikrotheorien mit konkretem Domänenwissen. IAMissionObligationVocabMt modellierte militärische Aufklärungspflichten: Rollen wie Intelligence Agent, Operations Agent, Commander. Pflichten wie Informationsweitergabe, Klassifikationsstufen, Berichterstattungsketten. Und OpenCyc hatte Instanzen von CodeOfConduct für reale Regelwerke: die Wiener Diplomatenkonvention, internationales Seerecht, Verhaltenskodizes.

Von diesen Vorlagen ausgehend sind zunächst sechs AEGIS-Domänen entstanden: militärische Aufklärung, Pharma-Compliance, Handelssanktionen, DSGVO, DevOps-Governance, Information Flow Control. Erweitert um Olsons Defeasibilität und moralische Axiome, die Cyc nicht konnte. Aber die Grundstruktur, drei Dateien pro Domäne, Rollen, Aktionen, deontische Regeln, das Muster kommt aus OpenCyc.

Die Trennung zwischen domänenagnostischer Engine und domänenspezifischen Regeln ist sauber. Aber bei jeder Domäne brauchte es jemanden, der sowohl die Fachlichkeit kannte (oder sie recherchiert hat) als auch die Syntax beherrschte. In einer Person. Und damals war das ein gigantisches Unterfangen.

In der Praxis ist das nicht realistisch.

Die Compliance-Beauftragte unseres Krankenhauses kennt die Regeln. Sie weiß, warum Pflegekräfte nur Laborberichte lesen dürfen, welche Ausnahmen es im Nachtdienst gibt, und welche Datenschutzgrenzen absolut gelten. Aber sie schreibt kein (forbiddenToDo-WRT KrankenhausCode pflege (lesenPatientenakte patientenakte)). Das ist nicht ihre Welt.

Ein Softwareentwickler könnte die Syntax lernen. Aber er kennt die Regeln nicht. Nicht die feinen Unterschiede, nicht die Ausnahmen, nicht die Gründe hinter den Ausnahmen. Und Gründe sind wichtig: Ob eine Regel überschreibbar ist oder ein moralisches Axiom, hängt davon ab, warum sie existiert. „Pflegekräfte dürfen keine Patientenakten lesen" ist eine Organisationsregel, die im Notfall weichen darf. „Medizinische Daten dürfen nie an Externe" ist eine Grundsatzentscheidung, die nicht weichen darf. Diesen Unterschied kennt die Compliance-Beauftragte, nicht der Entwickler.

Mit diesen Beispieldomänen ist das machbar. Zwei, drei Gespräche mit dem Fachexperten, und die Regeln stehen. Bei sechzig Domänen nicht mehr. Und bei Regelwerken, die sich regelmäßig ändern (neue Leitlinien, neue Gesetze, neue interne Richtlinien), erst recht nicht.

Formulare statt Freitext

Einem LLM die deterministische Durchsetzung von Regeln anzuvertrauen, ist fahrlässig. Das wissen wir. Aber Regeln übersetzen ist eine andere Aufgabe. Aktuelle Sprachmodelle, auch die Open-Source-Varianten, sind formale mathematische Repräsentationen von Weltwissen. Statistische, ja. Aber sie kodieren Zusammenhänge zwischen Konzepten, Fachbegriffen, Strukturen. Natürliche Sprache in strukturierte Felder zu übersetzen ist genau das, wofür sie gebaut sind.

Die Frage ist also nicht, ob ein LLM bei der Übersetzung helfen kann. Die Frage ist, wie man es so einsetzt, dass Fehler auffallen.

Die naive Antwort wäre: Gib dem Modell die fünf Sätze der Compliance-Beauftragten und lass es MELD-Dateien generieren. Das wird aber nicht funktionieren und ich erkläre kurz warum.

Wenn man einem LLM sagt „übersetze diese Regeln in MELD", generiert es Freitext. Es könnte Klammern falsch setzen. Es könnte Rollen erfinden, die es in der Ontologie nicht gibt. Es könnte das -WRT weglassen und damit aus einer überschreibbaren Regel ein moralisches Axiom machen, oder umgekehrt. Es könnte eine Regel stillschweigend vergessen. Und wer merkt das? Derjenige, der den Output liest, müsste die Syntax verstehen. Aber der Fachexperte versteht sie nicht. Und der Entwickler kennt die Fachlichkeit nicht genug, um inhaltliche Fehler zu erkennen.

Also ein anderer Weg.

AEGIS hat einen Workflow, der das Problem zerlegt. Das LLM sieht nie die MELD-Syntax. Stattdessen bekommt es ein strukturiertes Werkzeug: propose_rule. Das ist im Grunde ein Formular mit festen Feldern.

Modalität: PERMITTED, FORBIDDEN oder OBLIGATORY. Drei Optionen, keine Freitext-Interpretation.

Rolle: Welcher Agententyp? Aus der bestehenden Ontologie, nicht frei erfunden.

Aktion: Was soll der Agent tun oder lassen? Ebenfalls aus dem bestehenden Vokabular.

Parameter: Welche Spezifikation? Dokumenttyp, Empfängertyp, Klassifikation.

Überschreibbar: Ja oder Nein. Ja bedeutet: Eine spezifischere Regel mit höherer Priorität darf diese Regel aufheben. Nein bedeutet: moralisches Axiom. Nicht verhandelbar.

Begründung: Warum diese Regel existiert. Für den Fachexperten, der den Vorschlag beurteilt.

Das Modell füllt diese Felder aus. Aus den ausgefüllten Feldern wird die formale MELD-Regel durch eine feste Umwandlungsfunktion erzeugt. Deterministisch, keine Interpretation. Die S-Expression entsteht nicht aus dem Modell, sondern aus der Kombination der Felder.

Wenn die Compliance-Beauftragte sagt „Pflegekräfte dürfen nur Laborberichte lesen", erkennt das Modell, dass „nur" zwei Regeln erfordert: eine Erlaubnis für Laborberichte und ein Verbot für alles andere. Es erzeugt zwei propose_rule-Aufrufe. Wenn sie sagt „unter keinen Umständen", setzt das Modell „Überschreibbar: Nein". Die Umwandlungsfunktion macht daraus ein forbiddenToDo ohne -WRT, also ein moralisches Axiom.

Das Prinzip ist dasselbe wie beim Guard selbst: Die Schnittstelle zwischen dem nicht-deterministischen System und dem deterministischen System ist so eng wie möglich. Structured Output statt Freitext. Formulare statt offene Eingabefelder. Das Modell wählt aus vorgegebenen Optionen, es erfindet keine Syntax.

Vier Prüfungen, bevor ein Mensch entscheidet

Dass das Modell Formulare ausfüllt statt Freitext zu generieren, schließt Fehler nicht aus. Es schränkt den Fehlerraum ein. Das Modell könnte eine falsche Modalität wählen (PERMITTED statt FORBIDDEN). Es könnte eine Rolle auswählen, die im Kontext der Regel keinen Sinn ergibt. Es könnte den Unterschied zwischen überschreibbar und nicht überschreibbar falsch einschätzen. Inhaltliche Fehler, keine syntaktischen.

Deshalb durchläuft jeder Vorschlag vier automatische Prüfungen, bevor ihn ein Mensch sieht.

Die erste prüft die Syntax: Ist der erzeugte MELD-Ausdruck formal korrekt aufgebaut? Das sollte immer der Fall sein, weil die Umwandlung deterministisch ist. Aber „sollte" reicht nicht, wenn man es verifizieren kann. Also wird es geprüft.

Die zweite prüft die Symbole: Existieren die referenzierten Rollen, Aktionen und Parameter tatsächlich in der Ontologie? Wenn das Modell eine Rolle Hausmeister vorschlägt, die es in der Krankenhausdomäne nicht gibt, scheitert der Vorschlag hier. Nicht stillschweigend. Mit einer Fehlermeldung, die erklärt, was fehlt.

Die dritte prüft auf Konflikte: Widerspricht die neue Regel bestehenden Normen? Wenn es bereits eine Regel gibt, die Pflegekräften das Lesen von Patientenakten erlaubt, und der neue Vorschlag es verbietet, ist das ein Widerspruch. Der wird erkannt, bevor die Regel in die Basis gelangt. Ob der Widerspruch gewollt ist (weil die alte Regel falsch war) oder ungewollt (weil das Modell etwas missverstanden hat), entscheidet der Mensch. Aber er weiß davon.

Die vierte prüft die Funktion: Der Guard führt eine Simulation durch. Eine Testaktion wird gegen das erweiterte Regelwerk geprüft. Kommt das erwartete Ergebnis? Wenn die Regel verbieten soll, dass Pflegekräfte Patientenakten lesen, und der Guard bei einer simulierten Testanfrage „Pflegekraft liest Patientenakte" PERMITTED zurückgibt, stimmt etwas nicht. Vielleicht überschreibt eine bestehende Regel den neuen Vorschlag. Auch das wird abgefangen, bevor ein Mensch den Vorschlag sieht.

Erst wenn alle vier Prüfungen bestanden sind, wird der Vorschlag der Compliance-Beauftragten präsentiert. In verständlicher Sprache, mit Begründung, mit dem Hinweis, ob die Regel überschreibbar ist oder als moralisches Axiom gilt. Sie muss keine einzige Klammer lesen. Sie sieht: „VERBOTEN: Pflegekraft darf keine Patientenakten einsehen. Begründung: Die Eingabe schränkt Pflegekräfte explizit auf Laborberichte ein."

Und sie kann sagen: Stimmt. Oder: Stimmt nicht ganz, in der Nachtschicht muss die Pflegekraft auch die Diagnose sehen, wenn kein Arzt erreichbar ist. Dann beschreibt sie die Ausnahme, das Modell erzeugt einen neuen Vorschlag, der durchläuft dieselben vier Prüfungen, und sie entscheidet erneut.

Was sich ändert

Aus fünf Sätzen in natürlicher Sprache werden sieben formale Regeln. Sieben, weil „nur Chefärzte dürfen" zwei Regeln erfordert (eine Erlaubnis für Chefärzte und ein Verbot für andere Ärzte) und „Pflegekräfte dürfen nur Laborberichte" ebenfalls (eine Erlaubnis und ein Verbot). Diese Aufspaltung erkennt das Modell. Die Compliance-Beauftragte überprüft, ob die Aufspaltung der Absicht entspricht.

Das Ergebnis sind drei Dateien: Ontologie, Aktionsvokabular, Regeln. Dasselbe Format wie die sechs bestehenden AEGIS-Domänen. Formal identisch. Der Guard behandelt sie identisch. Er weiß nicht und muss nicht wissen, ob ein Mensch die S-Expressions getippt hat oder ob ein LLM die Felder gefüllt hat und eine Funktion die S-Expressions daraus erzeugt hat.

Was vorher Tage an Übersetzungsarbeit war, von der natürlichen Sprache des Fachexperten in die formale Sprache der Engine, ist ein Gespräch. Nicht weil das LLM die Arbeit besser macht. Sondern weil es die Übersetzung übernimmt, die der Fachexperte nicht leisten kann und der Entwickler nicht leisten sollte.

Ich bin nicht sicher, ob das in jeder Domäne funktioniert. Die Pharma-Domäne hat Wechselwirkungsklassen, Zulassungsstufen, Prevalence-gestaffelte Codes. Da steckt Fachwissen drin, das ein Modell nicht aus fünf Sätzen ableiten kann. Für solche Domänen wird man weiterhin Iterationsschleifen brauchen, Rückfragen, schrittweise Verfeinerung.

Aber die Grundstruktur bleibt: Der Fachexperte beschreibt. Das Modell übersetzt in strukturierte Felder. Eine deterministische Funktion erzeugt formale Logik. Vier Prüfungen fangen Fehler ab. Der Mensch entscheidet.

Im Grunde ist das nichts anderes als eine CI/CD-Pipeline für Compliance-Regeln. Der Code (die Regel) wird vom LLM geschrieben, durchläuft automatische Tests (Syntax, Ontologie, Konflikte, Simulation) und muss vor dem Merge in die Produktion von einem Code-Owner (der Compliance-Beauftragten) freigegeben werden. Linting, Type-Checking, Integration-Test, E2E-Simulation. Dieselben Prinzipien, die in der Softwareentwicklung längst Standard sind, angewandt auf Ethik und Compliance.

Und am Ende steht ein Regelwerk, das der Guard deterministisch durchsetzt. Gleicher Input, gleiches Ergebnis. Ob hundertmal oder tausendmal geprüft. Nicht weil das LLM zuverlässig ist, sondern weil die Zuverlässigkeit nicht vom Erzeuger abhängt. Sie hängt von der Verifikation ab. Von den vier Prüfungen. Von der Entscheidung des Fachexperten. Und von der Engine, die am Ende prüft, was in den Dateien steht, nicht was jemand gemeint hat.

Das nächste Mal geht es um die Engine selbst. Wie Olsons Kalkül in Code aussieht. Wie der Guard Konflikte zwischen Regeln auflöst. Und warum die Trennung zwischen Ring 0 und Ring 3 architektonisch erzwungen sein muss, nicht nur vereinbart.