EU AI Act
Risikologik, Daten-Governance, technische Dokumentation, Record-Keeping, Robustheit und menschliche Aufsicht werden zu Architekturfragen.
Praxis · Betrieb absichern
Regulatory Governance & Assurance übersetzt EU AI Act, DSGVO, DORA und BSI-Kontext in prüfbare GraphRAG-Fähigkeiten wie ACL-Fidelity, Quellsemantik, Security Trimming und Evidence Ledger.
Welche Architekturkontrollen machen GraphRAG in regulierten Umgebungen nachweisbar?
In Enterprise- und Government-nahen Kontexten reicht eine gute Antwort nicht. Das System muss zeigen können, welche Quellen, Rechte, Versionen, Kontrollen und Nachweise hinter Retrieval, Graphpfaden und Antworten stehen.
Die wichtigsten Prinzipien dieses Themas auf einen Blick.
Governance-by-Design behandelt Nachweisbarkeit als Architekturqualität, nicht als spätes Compliance-Add-on.
ACL-Fidelity und Identity Propagation verhindern, dass Index, Graph oder Agent im falschen Berechtigungskontext arbeiten.
Quellsemantik erhält fachliche Metadaten, Versionen, Lebenszyklen und Relationen während Ingestion und Retrieval.
Evidence Ledger und QA-Gates machen Datenherkunft, Verarbeitung, Qualität und Berechtigungen prüfbar.
Diese Fragen machen das Thema praktisch prüfbar. Hak sie ab – sie eignen sich als Einstieg für Workshops, Pilotvorhaben oder Architekturreviews.
Regulatory Governance & Assurance übersetzt regulatorischen Druck in Architekturkontrollen. Die Seite ist eine technische Orientierung. Sie zeigt, welche Fähigkeiten ein GraphRAG- oder Wissenssystem braucht, damit Antworten, Quellen, Rechte, Graphpfade und Verarbeitungsschritte später nachvollziehbar und prüfbar bleiben.
Die konkreten Pflichten hängen vom Use Case ab. Für den Compass sind diese Rahmenwerke vor allem Kontextgeber: Sie erklären, warum Datenherkunft, Rechte, Dokumentation, Resilienz und Evaluation keine Nebenthemen sind.
Risikologik, Daten-Governance, technische Dokumentation, Record-Keeping, Robustheit und menschliche Aufsicht werden zu Architekturfragen.
Personenbezug, Zweckbindung, Löschung, Minimierung und Zugriffskontrolle beeinflussen Ingestion, Index, Graph und Antwortverhalten.
Digitale Resilienz, IKT-Risiken, Drittparteiensteuerung und Exit-Fähigkeit betreffen Toolwahl, Betriebsmodell und Evidence-Portabilität.
Sicherheits- und Qualitätsprinzipien wie Zero Trust, Nachvollziehbarkeit, robuste Evaluation und kontrollierte Betriebsführung werden relevant.
Aus Governance wird erst dann Systemfähigkeit, wenn sie in Ingestion, Index, Graph, Retrieval, Antwortgenerierung und Betrieb messbar greift.
Rechte aus Quellsystemen bleiben im Index, Graph und Retrieval-Kontext präzise erhalten oder werden zur Laufzeit erneut geprüft.
Metadaten, Versionen, Lifecycle-Status, Beziehungen und fachliche Kontextsignale gehen bei Ingestion und Chunking nicht verloren.
Das System arbeitet vom Login bis zum Retrieval im Kontext der Nutzeridentität und nicht dauerhaft mit einem übermächtigen Service-Account.
Treffer, Chunks und Graphpfade werden zur Laufzeit gegen aktuelle Claims gefiltert, bevor das LLM sie als Kontext erhält.
Nachweise zu Quelle, Version, Verarbeitung, Berechtigungsmodell, Retention, Kritikalität und Belegstärke bleiben portabel dokumentiert.
Retrieval, Graphqualität, Antwortbelege, Robustheit und Grenzfälle werden mit Testsets und Traces wiederholbar geprüft.
Die Integrationsentscheidung ist ein Governance-Trade-off. Materialisierung bringt zentrale Suche und Auditierbarkeit, Föderation hält sensible Daten näher an der Quelle. Für viele Systeme entsteht eine Mischform.
Passt für: Dokumente, Wikis, Archive und Wissensbestände mit stabiler Delta-Synchronisation.
Risiko: ACL-Drift, veraltete Daten, Lösch-Propagation und Datenkopien außerhalb der Quelle.
Passt für: Transaktionale Fachdaten, hochsensible Datensätze, PII und Quellen mit starker eigener Rechteprüfung.
Risiko: Latenz, API-Throttling, Quellverfügbarkeit und schwierige Multi-Source-Aggregation.
Passt für: Besonders sensible Daten, bei denen dauerhafte Kopien im Suchindex vermieden werden sollen.
Risiko: Weniger semantische Tiefe, weniger Vorberechnung und höhere Abhängigkeit von Live-Connectoren.
Ein Evidence Ledger ist im Compass zunächst ein Denkmodell: Jede abgeleitete Kontexteinheit sollte genug Nachweise tragen, damit Herkunft, Verarbeitung, Rechte und Belegkraft später überprüfbar sind.
| Feld | Zweck |
|---|---|
| provenanceHash | Integritäts- und Herkunftsnachweis der Primärquelle. |
| extractionVersion | Version der Parser-, OCR-, Chunking- oder Extraktionslogik. |
| aclModel | Berechtigungsschema zum Zeitpunkt von Ingestion oder Live-Zugriff. |
| retentionClass | Aufbewahrungs-, Lösch- und Zweckbindungslogik. |
| criticality | Bedeutung für Prozess, Risiko oder Entscheidung. |
| evidenceStrength | Belegkraft: stark belegt, plausibel oder nur Hypothese. |
Governance wird erst belastbar, wenn sie in Kontrollpunkten geprüft wird. Diese Gates sind ein pragmatisches Raster für GraphRAG-Projekte.
Sind Quelle, Rechtsgrundlage, Datenqualität, Eigentümer, Datenklasse und Löschlogik bekannt?
Sind Metadaten, Versionen, Lifecycle-Status, Berechtigungen und fachliche Relationen vollständig genug?
Schlägt das System die Baseline bei Retrieval, Graphpfaden, Quellenbelegen und Grenzfällen?
Funktionieren Berechtigungen, Auditspur, Security Trimming, Lösch-Propagation und Nachweisexport?
Starte nicht mit einer vollständigen Compliance-Matrix. Starte mit einem kritischen Use Case und frage: Welche Quellen werden genutzt, welche Rechte müssen erhalten bleiben, welche Metadaten dürfen nicht verloren gehen, welche Nachweise braucht die Antwort und welche Grenzfälle müssen im Testset auftauchen?
Diese Seite verbindet vorhandene Praxisbereiche und Architekturfragen, statt ein eigenes Rechtsmodul zu öffnen.