KI-Recht visualisiert – Ein LLM-gepflegtes Wissensnetzwerk für das Zusammenspiel von AI Act und EU-Digitalrecht
Neun EU-Rechtsakte regulieren denselben digitalen Raum. Sie verweisen aufeinander, überlappen an vielen Stellen und widersprechen sich an manchen. Eine offizielle konsolidierte, maschinell abfragbare Übersicht über die Wechselwirkungen des AI Act (AIA) mit CRA, CSA, NIS2, DSGVO, DA, DGA, DSA und DMA gibt es bisher nicht. Dies war der Anlass für ein eigenes lebendiges, LLM-gepflegtes Wissensnetzwerk, das die Interaktion des AIA mit den anderen acht Rechtsakten sichtbar macht (kostenlos in Obsidian visualisiert) und sich mittels KI-Sprachmodell abfragen lässt. Ein vergleichbarer Ansatz wurde insb. durch Andrej Karpathy geprägt, der u.a. den Begriff des LLM-Wikis etablierte.
Ein Wissensnetzwerk als Abfragebasis
Das navigierbare Netzwerk besteht im Kern aus den Artikeln der Rechtsakte, Querverweisen und Quellen. Im Graph View ist jeder Artikel und jede Quelle ein Node, jede Verbindung zwischen Artikeln bzw. Quellen eine Kante. Das Netzwerk liegt als Sammlung von Markdown-Dateien lokal auf dem Rechner, sodass man nicht an ein bestimmtes LLM oder Programm zur Visualisierung gebunden ist, da Obsidian nur ein austauschbarer Viewer ist. Zudem wird es nicht statisch gepflegt, sondern von Claude i.R.v. Claude Cowork mit Ordnerzugriff aktiv bearbeitet, um neu hochgeladene Quellen einzupflegen, Verknüpfungen zu ergänzen und Arbeitsschritte zu dokumentieren.
1. Normtexte als Markdown-Dateien
Als Erstes erfolgte eine Überführung der Volltexte in einzelne Markdown-Dateien pro Artikel und für jeden Rechtsakt in einem eigenen Unterordner. Für den AIA werden die Artikel durch die Anhänge und passende Erwägungsgründe ergänzt. Jede Datei folgt demselben Aufbau: YAML-Frontmatter mit Metadaten (Gesetz, Artikelnummer, Querverweise, Schlüsselbegriffe) am Anfang der Datei sowie daran anschließende strukturierte Abschnitte für Normtext, Querverweise mit ergänzenden Hinweisen, Quellen nach neun Ebenen und Praxishinweise.
2. Zweistufige Verknüpfung
Danach folgte eine zweistufige Verknüpfung der AIA-Artikel. Ausgangspunkt war die EP-Studie „Interplay between the AI Act and the EU digital legislative framework“ (PE 778.575), ergänzt durch eigene Überlegungen.
Erste Stufe:
a) Verweise innerhalb des AIA selbst (intern) vs. Verweise auf Normen aus anderen Rechtsakten (cross), danach differenziert, ob der Artikel auf einen anderen Artikel verweist, oder von welchem anderen Artikel der jeweilige Artikel referenziert wird sowie
b) Verweise, die ausdrücklich im Normtext vorkommen (explizit) vs. nur thematische Verweise (implizit).
Zweite Stufe:
Anschließend wurde jeder Verweis danach klassifiziert, ob ein overlap, ein gap oder eine inconsistency vorliegt. Ein overlap ist gegeben, wenn der AI Act und der herangezogene Digitalrechtsakt identische oder ähnliche Pflichten auferlegen, z.B. die parallele Pflicht zu einer Grundrechte-Folgenabschätzung gem. Art. 27 AI Act und einer Datenschutz-Folgenabschätzung gem. Art. 35 DSGVO. Ein gap liegt vor, wenn ein Regelungsgegenstand, der logischerweise von einem der beiden Rechtsakte hätte erfasst werden müssen, tatsächlich von keinem hinreichend geregelt wird, so etwa bei der Ausübung der Betroffenenrechte (Auskunft, Berichtigung, Löschung nach Art. 15 bis 22 DSGVO). Diese sind praktisch kaum durchsetzbar, sobald die personenbezogenen Daten in den Modellgewichten eingebettet oder zu Zwecken der Rückverfolgbarkeit nach dem AI Act gespeichert werden, ohne dass einer der beiden Rechtsakte regelt, wie das Recht in diesem Kontext zu verwirklichen ist. Eine inconsistency ist anzunehmen, wenn die Pflichten inhaltlich auseinanderlaufen, bspw. wenn Art. 10 Abs. 5 AI Act die Verarbeitung besonderer Datenkategorien zur Überwachung und Korrektur von Verzerrungen verlangt, während Art. 9 DSGVO eine solche Verarbeitung nur unter eng gefassten Ausnahmetatbeständen gestattet (die aktuellen Omnibus-Entwicklungen an dieser Stelle ausgeklammert). Identifizierte Widersprüche und Überschneidungen werden durch das LLM nicht aufgelöst, sondern dokumentiert und sichtbar gemacht, damit sich nicht vorschnell für eine Richtung entschieden wird.
3. Quellen nach neun Ebenen
Anschließend wurden relevante Quellen eingebunden und nach einer Hierarchie (Ebenen 01 bis 09) systematisiert: von EU-Primärrecht (01) über Sekundärrecht (02), technische Standards (03), Behördenleitlinien (04) und Rechtsprechung (05) bis hin zu offiziellen Positionen (06), Konsultationsdokumenten (07), Forschung (08) und Industrie/Medien (09), um der unterschiedlichen Aussagekraft und Bedeutung Rechnung zu tragen, insb. wenn es zwischen den Quellen zu Widersprüchen kommt.
4. Graph View
Das entstandene Wissensnetzwerk lässt sich im Graph View visualisieren. Hilfreich ist, dass sich die einzelnen Nodes mit ihren jeweiligen Verknüpfungen separat anzeigen lassen, da ein Blick auf das Gesamtnetzwerk zwar beeindruckend, für sich genommen jedoch nur begrenzt hilfreich ist.
5. Zentrale Steuerdateien
Den Rahmen für die Arbeit im und mit dem Wissensnetzwerk setzen insb. folgende, ebenfalls im Ordner hinterlegte, Dateien:
· CLAUDE.md: Verhalten, Regeln, Strukturen, Workflows, Templates. Sie wird zu Sessionbeginn zwingend vom LLM gelesen und stellt sicher, dass das LLM bei jedem Start denselben Wissensstand hat.
· _KOLLISIONEN.md: Normwidersprüche sowie Quellkonflikte werden dokumentiert und nicht aufgelöst.
· _AUDIT-LOG.md: Alle Änderungen, die in einer Session vorgenommen wurden, werden automatisch anhand einer Anleitung dokumentiert.
· _HANDOVER.md und Berichte: Zusätzlicher Kontext für ggf. andere LLMs, die keinen Zugriff auf den bisherigen Gesprächsverlauf haben, um dadurch fehlenden Kontext aus früheren Sessions zu kompensieren.
· INDEX.md und _PLANUNG.md: Gesamtübersicht über das Netzwerk (bspw. Anzahl der hinterlegten Dateien und Nodes) und Entwicklungsroadmap, in der offene Entwicklungsaufgaben und Ideen dokumentiert sind.
6. Der QUERY-Workflow
Eine QUERY.md definiert, wie juristische Fragen beantwortet werden. Claude liest zunächst die relevanten Artikel-Nodes, dann die verlinkten Quelldateien sowie die hinterlegten PDFs. Jede Aussage wird mit Artikel und Absatz belegt, jede Quelle mit Hierarchieebene gekennzeichnet. Schnittstellen zwischen Rechtsakten werden auch in der Antwort nicht aufgelöst, sondern nach den obigen Vorgaben explizit als overlap, gap oder inconsistency markiert, mit Verweis auf die betroffenen Normen und den aktuellen Regelungsstand.
Was lässt sich damit machen?
Einerseits ist der Ansatz hilfreich für das eigene vernetzte Durchdringen der Materie durch die aufbereiteten klickbaren Verlinkungen und die visualisierte Darstellung (Linked Thinking). Zugleich dient er als strukturierte Abfragebasis für ein LLM mit Ordner-Zugriff, um in der Praxis fundiertere Antworten zu erhalten.
Das System ist Work in Progress und soll daher vor allem Anregung für die Auseinandersetzung mit dem hier vorgestellten Ansatz sein, der sich selbstverständlich auf andere Rechtsgebiete übertragen lässt. Wer im Legal-Tech-Bereich ähnliche Strukturen aufbaut, durch eigene Ideen ergänzt und teilt, treibt den Bereich weiter voran. Abschließend sei noch darauf hinzuweisen, dass Google kürzlich das Open Knowledge Format (OKF) als offenen und formalisierten Standard veröffentlicht hat, der strukturell denselben Ansatz erfasst.
Autor: Adrian Janßen ist studentischer Mitarbeiter bei der auf IT- und Wirtschaftsrecht spezialisierten Kanzlei JUN Legal und hat dort seinen Schwerpunkt im Bereich Künstliche Intelligenz in rechtlicher wie technischer Hinsicht. Zudem war er in einem KI-Forschungsprojekt der Universität Würzburg tätig und teilt aktuelle Entwicklungen im Bereich der KI-Regulierung frei zugänglich auf LinkedIn u.a. im „Weekly Update Digital-Recht“-Newsletter.
