Lesen
Welche Quellen, Chunks, Knoten, Kanten und Attribute darf eine Person oder ein Agent sehen?
Praxis · Betrieb absichern
Governance und Security definieren Rollen, Datenzugriff, Schreibrechte, Auditierbarkeit und Grenzen für Agentenaktionen.
Wer darf was sehen, schreiben, ableiten oder ausführen?
GraphRAG und Agenten verbinden Wissen, Tools und Aktionen. Ohne Governance können Systeme vertrauliche Daten mischen, falsche Aktionen ausführen oder nicht nachvollziehbare Entscheidungen treffen.
Die wichtigsten Prinzipien dieses Themas auf einen Blick.
Lesen, Schreiben, Ableiten und Ausführen sind unterschiedliche Rechte.
Berechtigungen müssen in Retrieval, Graphabfragen, Semantic Layer und Tools wirken.
Agentenaktionen brauchen stärkere Kontrolle als reine Antworten.
Audit Trails sind Teil des Produkts und des Betriebslogs.
Diese Fragen machen das Thema praktisch prüfbar. Hak sie ab – sie eignen sich als Einstieg für Workshops, Pilotvorhaben oder Architekturreviews.
Governance beantwortet, welche Regeln für Wissen, Rollen, Qualität und Verantwortung gelten. Security setzt diese Regeln technisch durch. Für GraphRAG ist das anspruchsvoll, weil Dokumente geschützt werden müssen. Auch Chunks, Knoten, Kanten, Pfade, Ableitungen, Quellen und Agentenaktionen können vertraulich oder kritisch sein.
Ein häufiger Denkfehler ist: Wer etwas sehen darf, darf damit auch alles tun. In GraphRAG- und Agentensystemen müssen Rechte feiner getrennt werden.
Welche Quellen, Chunks, Knoten, Kanten und Attribute darf eine Person oder ein Agent sehen?
Wer darf neues Wissen erzeugen, bestehende Aussagen ändern oder Korrekturen in den Graph schreiben?
Welche Schlussfolgerungen darf das System aus erlaubten Daten bilden, wenn die Ableitung selbst sensibel ist?
Welche Tools, Workflows oder Aktionen darf ein Agent starten, und wann braucht es eine Freigabe?
Die wichtigste Regel: Berechtigungen dürfen nicht erst am Ende in der Oberfläche geprüft werden. Sie müssen in jedem relevanten Schritt der Pipeline wirken.
Berechtigungen, Datenklassen, Quelle, Eigentümer und Aufbewahrungsregeln werden schon beim Import als Metadaten gespeichert.
Filter verhindern, dass semantisch passende, aber nicht erlaubte Treffer überhaupt ins Kontextpaket gelangen.
Knoten, Kanten, Pfade und Attribute müssen dieselben Rechte respektieren wie die ursprünglichen Quellen.
Die Antwort darf keine Information zusammenführen, die der Nutzer einzeln oder in Kombination nicht sehen dürfte.
Aktionen mit Nebenwirkung brauchen engere Grenzen als reine Recherche: Allowlist, Freigabe, Simulation oder Vier-Augen-Prinzip.
Später muss nachvollziehbar sein, wer gefragt hat, welche Quellen genutzt wurden und welche Aktion ausgelöst wurde.
Gute Governance wird greifbar, wenn man konkrete Risiken und passende Kontrollen nebeneinander legt.
Risiko
Ein Manager fragt nach Team-Fluktuation. Einzelne Krankheitsdaten dürfen nicht indirekt über Graphpfade sichtbar werden.
Kontrolle
Antwort nur auf aggregierter Ebene, Mindestgruppengröße, keine sensiblen Knoten im Kontextpaket.
Risiko
Ein Nutzer darf Vertrag A sehen, aber nicht den verknüpften Rahmenvertrag oder vertrauliche Preisanhänge.
Kontrolle
Retrieval und Graphpfade nach Dokumentberechtigung, Vertragstyp und Attributklasse filtern.
Risiko
Ein Agent findet ein Risiko und möchte automatisch ein Ticket, eine E-Mail oder eine Systemänderung auslösen.
Kontrolle
Erst Simulation und Begründung anzeigen, dann explizite Freigabe für Aktionen mit Nebenwirkung verlangen.
Modelliere für jeden Use Case eine kleine Policy-Matrix: Rolle, Datenklasse, erlaubte Quellen, erlaubte Graphpfade, erlaubte Tools und Freigabeschwelle. Danach testest du gute Fragen und Grenzfälle: Was darf ein Nutzer knapp nicht sehen, ableiten oder ausführen?
Governance scheitert selten an einer einzelnen fehlenden Regel. Meist entstehen Lücken, weil Regeln nicht durch die ganze Pipeline getragen werden.