Beziehungen statt Findings.
Die meisten Compliance-Tools liefern Findings: einen Tracker, eine offene DPIA, einen abgelaufenen DPA. Was fehlt, ist der Kontext — welcher KI-Usecase nutzt den Tracker, welche Regulation greift, welches Evidence-Pack belegt die Maßnahme. Genau diese Beziehungs-Schicht ist der Governance Graph. Sie macht aus einem Befund einen nachvollziehbaren Pfad.
Entitäten
Der Graph speichert 22 Entitätstypen: Tenant, User, Website, Page, Script, Cookie, Tracker, Vendor, AiUsecase, Model, Dataset, Prompt, Agent, Policy, Control, Regulation, Risk, Evidence, Workflow, Deployment, ApiEndpoint, CloudResource. Jede Entität trägt tenant_id als Partition-Key — Cross-Tenant-Traversal ist nur mit einer explizit auditbaren cross_tenant_admin-Rolle möglich.
Beziehungen, die zählen
(:Page)-[:LOADS]->(:Script)und(:Script)-[:SERVED_BY]->(:Vendor)ergeben den vollen Tracking-Pfad einer Seite.(:AiUsecase)-[:USES_MODEL]->(:Model)und(:AiUsecase)-[:CONSUMES_DATASET]->(:Dataset)ergeben die Abhängigkeitskette einer KI-Anwendung.(:AiUsecase)-[:GOVERNED_BY]->(:Policy)-[:IMPLEMENTS]->(:Control)-[:REQUIRED_BY]->(:Regulation)ist der Pflicht-Pfad: vom konkreten System bis zur Rechtsgrundlage.(:Evidence)-[:PROVES]->(:Control)verknüpft Belege mit dem, was sie belegen sollen.
Drei Anfragen, die ein Audit-Tool nicht beantworten kann
Blast-Radius: "Was bricht, wenn Vendor X seinen Adequacy-Status verliert?" — eine Traversierung von :Vendor rückwärts über :SERVED_BY,:USES_VENDOR liefert die betroffenen Websites + Usecases in einer Query.
Compliance-Lineage: "Welche Evidence belegt Art. 13 für Usecase Y?" — Pfad von :AiUsecase über :GOVERNED_BY, :IMPLEMENTS,:PROVES auf die Evidence-Records mit ihren Hashes und Sealed-Timestamps.
Shadow AI: "Welche Usecases sind deployed, haben aber keine Policy?" — eine NOT-EXISTS-Cypher-Query findet die Lücken, bevor der Auditor sie findet.
Tech-Choice: Postgres + Apache AGE
Der Graph läuft nicht in Neo4j oder Neptune, sondern als Apache-AGE-Extension auf demselben Postgres, der auch Relationen, RLS und Audit-Log hält. Drei Gründe: ein transaktionaler Store für relationale und Graph-Daten, native RLS für Tenant-Isolation, ein Backup-Restore-Pfad statt zwei. Die Skalierungsgrenze (≥10⁸ Edges) wird durch die Implementierungs-Roadmap überwacht; ab dort kommt ein per-Tenant-Mirror in Neptune dazu.
Wie die Daten in den Graph kommen
Direkt schreiben in den Graph dürfen nur Service-Role-Connections. Telemetrie-Events landen über den Graph-Projector — eine idempotente Pipeline, die das Kafka-Topictelemetry.events liest, dedupliziert, rate-limitiert und schließlich Apache-AGE-Upserts ausführt. Replays des Topics ergeben deterministisch denselben Graph-State; das ist eine harte Invariante, keine Option.
Was Agents sehen dürfen
Agenten lesen den Graph über eine Cypher-über-HTTP-API mit drei Guards: Tenant-Scope wird in jede Query injiziert, Traversal-Tiefe ist auf 5 Hops gecapped (außer fürauditor-Agents), Result-Sets sind auf 1000 Zeilen gecapped. Schreiben dürfen Agenten nur über graph.propose — der Proposal landet in einer Pending-Queue und braucht entweder einen Higher-Trust-Agent oder einen Menschen, der bestätigt.