Governance-Audit · Feld-Anatomie

Was in einer Governance-Entscheidung steht

Jeder KI-gestützte Zugriff hinterlässt einen dauerhaften Record. Er ist so aufgebaut, dass er dieselben sechs Fragen beantwortet — für den Kunden lesbar, für eine Analyse nach einem Sicherheitsvorfall belastbar, und für den Architekten ein Abbild einer klaren, geschichteten Kontrolle.

Zwei echte Beispiele

kernel.mediated.decision Erlaubt

Werhmac:d434… · regulärer Nutzer

WasKI-Antwort erzeugen (call_llm, lokal)

DatenKRITIS-gebunden · KRITIS-interne Zone

Regel12 Kernel-Prüfungen bestanden (kernelabi:7)

Nachweis2026-07-29 07:46:48 UTC · op-0aa1b9…-185

Record als JSON — Kennungen gekürzt

{
  "event": "kernel.mediated.decision",
  "timestamp": "2026-07-29T07:46:48.857366534Z",
  "level": "audit",
  "owner_sub_pseudo": "hmac:d434…",
  "admin_bypass": false,
  "retention_class": "critical",
  "operation_id": "op-0aa1b9…-185",
  "step_seq": 1,
  "details": {
    "op": "call_llm",
    "verdict": "admitted",
    "provider": "local",
    "policy_engine_version": "kernelabi:7",
    "cumulative_class": "KRITIS-bound",
    "cumulative_layer": 4,
    "cumulative_zone": "KRITIS-intern",
    "decisive_rules": [
      "capability_op_authority", "abi_known_op", "step_budget",
      "resource_cost_validation", "resource_budget_tokens",
      "resource_budget_retrieval_docs", "resource_budget_recall_docs",
      "resource_budget_crossing_calls", "resource_budget_payload_bytes",
      "label_ceiling_layer", "label_ceiling_class", "label_ceiling_zone"
    ]
  }
}

authz.denied Blockiert · 403

Werhmac:8a2a… · regulärer Nutzer

WasAnfrage an ein Projekt (POST …/devops/query)

DatenProjekt devops

RegelAblehnung belegt · Regel nicht im Wortlaut

Nachweis2026-07-29 14:38:25 UTC · trace c69b1701…

Record als JSON — Kennungen gekürzt

{
  "event": "authz.denied",
  "timestamp": "2026-07-29T14:38:25.26110952Z",
  "level": "audit",
  "owner_sub_pseudo": "hmac:8a2a…",
  "admin_bypass": false,
  "retention_class": "critical",
  "method": "POST",
  "path": "/api/projects/devops/query",
  "status": 403,
  "project": "devops",
  "trace_id": "c69b1701…",
  "details": {
    "outcome": "denied"
  }
}

Beide sind unverändert aus dem System — ein erlaubter und ein blockierter Zugriff, beide von regulären Nutzern (keine Admin-Sonderrechte), beide dauerhaft festgehalten.

Sechs Fragen, die jeder Record beantwortet

Dieselben Felder — drei Blickwinkel

Wer hat gehandelt?

owner_sub_pseudoadmin_bypass

erlaubthmac:d434… · regulär blockierthmac:8a2a… · regulär

Der Akteur als pseudonymisierte Kennung — kein Klartext-Name, aber für Berechtigte auflösbar. admin_bypass sagt, ob es ein regulärer Zugriff war oder eine Sonderberechtigung.

ArchitekturPseudonymisierung an genau einer Schicht — Datenschutz von Haus aus, ohne die Zurechenbarkeit zu verlieren. Auch Ausnahmen tragen die Kennung: kein blinder Fleck.

Was wurde getan oder versucht?

eventopmethodpath

erlaubtKI-Antwort erzeugen (call_llm) blockiertProjekt-Anfrage (POST …/devops/query)

Die Art der Entscheidung und der konkrete Vorgang. event unterscheidet eine vom Governance-Kernel vermittelte KI-Operation von einer am Zugriffs-Layer geprüften Anfrage.

ArchitekturZwei Ereignistypen aus zwei Enforcement-Schichten — KI-Mediation und Zugriffskontrolle — laufen in einen gemeinsamen Audit. Eine Sprache, egal wo die Entscheidung fiel.

Erlaubt oder blockiert?

verdictstatusoutcome

erlaubtzugelassen (admitted) blockiertabgelehnt (403 · denied)

Der Ausgang — klar und in beide Richtungen. Für eine Prüfung sind gerade die blockierten Entscheidungen die aufschlussreichsten: sie belegen, dass die Kontrolle greift.

ArchitekturZulassung und Ablehnung werden gleich behandelt und beide festgehalten — vollständige Mediation. Was der Kernel nicht ausdrücklich freigibt, findet nicht statt und bleibt sichtbar.

Welche Daten waren betroffen?

cumulative_classcumulative_zoneproject

erlaubtKRITIS-gebunden · KRITIS-intern blockiertProjekt devops

Die Schutzeinstufung bzw. das betroffene Projekt/Mandat. Ein Analyst sieht sofort, ob ein Vorgang schützenswerte Daten berührte und in welcher Zone er blieb.

ArchitekturKlassifikationsbasierter Zugriff: die Einstufung der Daten entscheidet, nicht der Zufall. Die Zone im Record belegt, dass der Vorgang den geschützten Bereich nicht verlassen hat.

Nach welcher Regel?

decisive_rulespolicy_engine_version

erlaubt12 Kernel-Prüfungen (kernelabi:7) blockiertAblehnung belegt · Regel nicht im Wortlaut

Die maßgeblichen Prüfungen und die Version, die entschieden hat. Bei einer Zulassung stehen die bestandenen Regeln, bei einer Kernel-Ablehnung die verletzte. Ehrlich: der Zugriffs-403 belegt die Ablehnung, speichert die Regel aber nicht im Wortlaut.

ArchitekturGovernance als explizite, versionierte Regeln — keine Blackbox. Über die Engine-Version ist jede Entscheidung an einen konkreten, reproduzierbaren Regelstand gebunden.

Wann — und wie nachweisbar?

timestamptrace_idoperation_id

erlaubt07:46:48 UTC · op-0aa1b9…-185 blockiert14:38:25 UTC · trace c69b1701…

Der Zeitpunkt und ein Korrelations-Anker. Genau diese IDs braucht eine Vorfall-Analyse, um aus einzelnen Records die ganze Abfolge zu rekonstruieren.

ArchitekturDer Record entsteht vor der Wirkung (write-ahead) und ist über Trace- und Operations-ID verkettbar — manipulationsresistent und lückenlos rekonstruierbar.

Was die Struktur verrät

Drei Eigenschaften — direkt aus den Feldern

Vollständig. Erlaubt und blockiert werden gleich bezeugt, über beide Kontroll-Schichten hinweg — nichts Freigegebenes bleibt unsichtbar, nichts Blockiertes fällt unter den Tisch.
Explizit. Jede Entscheidung nennt ihre maßgebliche Regel und deren Version — Governance als nachvollziehbarer Code, keine Blackbox.
Beweisbar. Der Record entsteht vor der Wirkung, ist pseudonym aber verkettbar und manipulationsresistent.

So wird nicht nur sichtbar, was geschah — sondern auch warum und wie es überprüfbar ist.

Die hier gezeigten Felder sind die für Kunde, Architekt und Vorfall-Analyse wesentlichen. Ein Record trägt darüber hinaus technische Speicher-Details (u. a. den Dedup-Schlüssel <operation_id>:<step_seq>:<event>, der ein Doppel-Schreiben idempotent macht). Die Kennungen (Akteur-Pseudonym, Operations- und Trace-ID) sind auf dieser öffentlichen Seite gekürzt; die vollständigen Werte — für die Rekonstruktion einer Vorfall-Analyse essenziell — stehen nur in der internen, angemeldeten Ansicht (/admin/gdr/).