Assistent für gerichtliche Massenverfahren (Aktenbearbeitung auf Gerichtsseite)

Massenverfahren (Dieselabgas-Klagen, Fluggastrechte-Klagen, Datenschutz-Klagen) überschwemmen Gerichte mit Tausenden nahezu gleichartiger, aber individuell begründeter Akten. Ein Assistent auf Gerichtsseite extrahiert die entscheidenden Tatsachen aus jedem Schriftsatz, gruppiert ähnliche Fälle, erstellt eine strukturierte Übersicht und füllt Beschluss- oder Urteilsbausteine vor. Die Richterin oder der Richter liest die Quellen, ändert und entscheidet. Es ist ein Hochrisiko-System nach der KI-Verordnung und muss auf die richterliche Unabhängigkeit hin entworfen werden.

Problem & Nutzen

• Heute: Richterinnen, Richter und Geschäftsstellenpersonal lesen jeden Schriftsatz, kopieren Fahrzeugdaten, Flugdaten, Daten und Beträge in Tabellen und verwenden Textbausteine früherer Entscheidungen von Hand wieder. Spitzen (eine neue Klagewelle nach einem Grundsatzurteil) überlasten einzelne Kammern.
• KI-Nutzen: Das repetitive Lesen und Abschreiben wird automatisiert; die Richterin oder der Richter sieht eine geprüfte, mit Quellen verknüpfte Übersicht und einen Bausteinentwurf. Es bleibt Zeit für die rechtliche Würdigung des Einzelfalls. Die einheitliche Behandlung paralleler Fälle lässt sich leichter beobachten.
• Reale Einsätze (Deutschland): Das Oberlandesgericht Stuttgart (OLG Stuttgart) betreibt den Assistenten OLGA für Dieselabgas-Massenverfahren und das Amtsgericht Frankfurt (AG Frankfurt) nutzt seit 2021 FRAUKE für Fluggastrechte-Verfahren (Presseberichte); das AG Königs Wusterhausen (Brandenburg) setzt seit Februar 2025 ein ähnliches Werkzeug, KAI, ein [7]. Die Landesregierung Baden-Württemberg gibt an, dass OLGA nach Einschätzung der Richter den Zeitaufwand für die Erfassung des Streitstands erheblich verringert, nennt aber keinen Prozentwert [8]. Eine gemessene Evaluation ist nicht veröffentlicht, daher zitieren Sie keine Effizienzzahlen, bevor Sie die Evaluationsberichte der Gerichte selbst haben.
• Warum getrennt von Nachbarn: Anders als Rechtsrecherche (KNOW-006) verarbeitet er die eigene Akte der Parteien; anders als Formularverarbeitung (DOC-003) ist die Eingabe juristische Argumentation in Freitext; anders als Vertrags- analyse (DOC-009) fließen die Ergebnisse in einen richterlichen Entscheidungsprozess ein.

Varianten

• Gerichtsseite (Kern): Extraktion, Clustering, Fallübersicht, vorausgefüllte Bausteine, stets mit Freigabe durch die Richterin oder den Richter; Betrieb innerhalb der souveränen Justiz-IT.
• Nur Geschäftsstelle/Verwaltung: Anonymisierung, Pseudonymisierung von Entscheidungen, Postsortierung, Aktenindexierung. Erwägungsgrund 61 stuft rein nebensächliche Verwaltungsaufgaben, die einzelne Fälle nicht berühren, als außerhalb der Hochrisiko-Kategorie ein [3].
• Kanzlei-/Legal-Tech-Seite: Massenaufnahme von Klagen (Mandatsunterlagen, Klageparameter, Entwurf von Standardschriftsätzen). Kein Justizsystem, daher gilt Anhang III Nr. 8 nicht, wohl aber die DSGVO und das Berufsgeheimnis; kombinierbar mit DOC-021.
• Verwaltungsgerichte und Schiedsverfahren: gleiche Architektur für Asyl-, Sozial- oder Steuersachen; besondere Sorgfalt, weil KI, die von oder für Stellen der alternativen Streitbeilegung eingesetzt wird, ebenfalls unter Anhang III Nr. 8 fällt [1].

So funktioniert es

1. E-Akte (Schriftsätze, Anlagen)
2. OCR + Layout-Analyse (Scans, Tabellen, Anlagenlisten) [ocr-docparse]
3. Dokumenttypisierung (Klage, Erwiderung, Gutachten, Beschluss) [text-classifier]
4. Parameterextraktion gegen einen Katalog je Klagetyp [llm-general, schemagebunden] (Fahrzeug/Motor, Kaufdatum, Laufleistung, Flugnummer, Verspätung, Betrag, geltend gemachter Schadensposten)
5. Quellenverknüpfung (jeder Wert
6. Seite + Zitat) [Zitatprüfung]
7. Clustering / Ähnlichkeitssuche über das Verfahrensregister [embedding-text, vector-db]
8. Fallübersicht + Ausreißerhinweise für die Kammer
9. vorausgefüllter Beschluss-/Hinweis-/Urteilsbaustein (Entwurf) [llm-reasoning, Vorlagen]
10. Richterin oder Richter prüft, korrigiert, entscheidet; Änderungen werden protokolliert [Human-in-the-Loop]

• Die Extraktion folgt einem geschlossenen Katalog, nicht einer offenen juristischen Argumentation: Der Katalog wird vom Gericht (Richterschaft und IT) gepflegt, sodass das System bekannte Felder füllt, statt Streitpunkte zu erfinden.
• Vorausgefüllte Bausteine kombinieren vom Gericht freigegebene Textbausteine mit extrahierten Parametern. Freie Erzeugung juristischer Begründungen wird bewusst begrenzt; jeder erzeugte Abschnitt ist als Entwurf gekennzeichnet.
• Mensch-in-der-Schleife (Human-in-the-Loop): Die Richterin oder der Richter prüft jeden extrahierten Wert anhand der markierten Quelle und entscheidet allein über Zulässigkeit, Begründetheit und Beträge. Abweichungs- und Änderungsraten werden protokolliert.

Datenaufbereitung

Die Daten sind E-Akten, Schriftsätze, Anlagen und Entscheidungen, die in Fachverfahren der Gerichte, im DMS oder auf Dateiablagen liegen; bei Kanzleien auch E-Mails und Vorlagen. Typische Lücken sind gescannte Anlagen ohne Textebene, uneinheitliche Benennung nahezu gleichartiger Klagen, fehlende Verfahrensparameter als strukturierte Felder, verstreute Vorlagen für Beschlüsse und Urteile sowie strenge Zugriffsrechte je Verfahren, die sich in jedem Index fortsetzen müssen.

Aufbereitungsschritte: - Die zu extrahierenden Verfahrensparameter (Kläger, Fahrzeug, Klagebetrag, Daten) als festes Schema definieren, siehe PREP-019. - Gescannte Anlagen per OCR verarbeiten, siehe PREP-006, und Formate konvertieren, siehe PREP-007. - Von Richtern freigegebene Musterentscheidungen und Beschlussbausteine sammeln, siehe PREP-016. - Mit Richtern und Geschäftsstelle einen Testdatensatz aus 100-200 annotierten Eingaben aufbauen, siehe PREP-018. - Für Tuning oder Evaluierung genutztes Material pseudonymisieren, siehe PREP-022, und die Zugriffsrechte je Akte beibehalten, siehe PREP-023.

Grober Aufwandsanteil: 30 Prozent, vor allem Schema, Annotation und Rechte. Werkzeuge: Docling, PaddleOCR, Indexierung im Stil von Paperless-ngx, LLMs mit offenen Gewichten. Siehe auch DOC-018 und GUIDE-003.

Umsetzungswege

Welcher Weg für wen

• Öffentlicher Sektor (Gerichte): Weg C, weil Gerichtsakten hochsensible personenbezogene Daten enthalten, die Justiz einen souveränen Betrieb braucht und dieselbe Plattform mehrere Verfahrensarten bedienen kann.
• Großunternehmen (Kanzleien, Rechtsabteilungen): Weg C, weil Mandantengeheimnis und Berufsgeheimnis gegen externe Clouds sprechen und Massenverfahrensvolumina Lizenz- oder API-Kosten in die Höhe treiben.
• Entwickler: Weg C, weil Modelle mit offenen Gewichten und quelloffene Parser direkt in Justiz- oder Kanzleisysteme eingebaut werden können.

Weg A — Kaufen (Standardsoftware)

Nur wenige Produkte zielen speziell auf die Richterbank. Kommerzielle Legal-AI- und eDiscovery-Suiten (z. B. die deutschen Legal-Tech-Anbieter und die KI-Assistenten der großen juristischen Verlage) bedienen überwiegend Kanzleien; bei Gerichten dominieren Justiz-IT-Verbünde und Eigenprojekte. Sinnvoll, wenn der Bedarf in der Massenaufnahme auf Kanzleiseite oder in reinen Geschäftsstellenaufgaben liegt. Für den richterlichen Einsatz verlangen Sie: EU-Hosting, kein Training mit Gerichtsdaten, Anbieterdokumentation nach KI-Verordnung (Art. 13), Konformitätsbewertung.

Weg B — Auf Cloud-KI-Diensten aufbauen

Technisch möglich (Spitzenmodelle in EU-Regionen oder EU-Anbieter per API plus Parsing-Dienst), aber Gerichte halten sensible personenbezogene Daten, in manchen Sachen auch besondere Kategorien, und unterliegen der richterlichen Verschwiegenheit und Souveränitätserwartungen. Öffentliche Cloud-APIs sind nur realistisch für nicht vertrauliche Prototypen mit synthetischen oder anonymisierten Akten oder für Kanzleien unter Berufsgeheimnis-Verträgen und AVV. Ein Einsatz im öffentlichen Sektor muss außerdem die Sicherheits- und Cloud-Vorgaben der Justizverwaltung erfüllen.

Weg C — Selbst betreiben (Open Source) — für Gerichte empfohlen

• Parsing: Docling (MIT-Lizenz) für PDFs und Scans; PaddleOCR oder Ähnliches für schlechte Scans [5].
• Modelle: LLMs mit offenen Gewichten, im eigenen Rechenzentrum des Gerichts über vLLM betrieben (z. B. Modelle der Familien Qwen, Mistral oder Llama im Bereich 30–120B) mit schemagebundener Dekodierung; offene Embedding-Modelle und ein Reranker für Clustering und Suche nach ähnlichen Fällen.
• Stack: PostgreSQL mit pgvector oder OpenSearch, eine Workflow-Engine, Anbindung an das E-Akte-System über dessen Schnittstellen, rollenbasierter Zugriff je Kammer.
• Hardware: HW3 (eine GPU mit 48–141 GB) ist ein sinnvolles Minimum für einen Pilot an einem Gericht; HW4 für einen landesweit gemeinsam genutzten Dienst. Der Betrieb erfordert ein ML-Ops-Team in der Justiz-IT.

Weg D — Eigenes Training

Lohnt sich, sobald annotierte Daten vorliegen: Korrekturen der Richterschaft an extrahierten Werten sind ideale Trainingsdaten für einen kleinen feingetunten Extraktor (günstiger und berechenbarer als ein großes Allzweckmodell) und für einen Klassifikator, der eingehende Schriftsätze nach Klagetyp sortiert. Hunderte bis einige Tausend annotierte Akten je Klagetyp; das Training bleibt innerhalb der Umgebung des Gerichts.

Stand der Technik (2026)

• Dokument-zu-JSON-Extraktion mit Vision-Language- oder Text-LLMs ist Standard; die Präzision ist hoch bei wohlgeformten Kopfdaten und schwächer bei langen, polemischen Schriftsätzen, Anlagen- tabellen und gescannter Handschrift. Die Quellenangabe je Wert ist die zentrale Kontrolle.
• Clustering über Embeddings plus regelbasierte Parameter findet parallele Fälle und Ausreißer; die Ähnlichkeitssuche über frühere Entscheidungen fördert Einheitlichkeit, kann aber auch alte Fehler fortschreiben.
• Reasoning-Modelle können strukturierte juristische Bausteine entwerfen, neigen aber weiter zu erfundenen Zitaten und zu subtilen Fehllesungen von Daten oder Beträgen; eine deterministische Prüfung von Rechnungen und Fristen sollte außerhalb des Modells liegen.
• Governance-Praxis: Europäische Leitlinien für Justiz-KI (Ethik-Charta der CEPEJ) betonen Grundrechte, Nichtdiskriminierung, Qualität und Sicherheit, Transparenz und „unter Kontrolle der Nutzer"; die KI-Verordnung macht Teile davon für Hochrisiko-Systeme nun verbindlich.
• Grenzen: Automationsbias (der Entwurf verankert die Richterin oder den Richter), ungleichmäßige Qualität je nach Schreibstil der Kanzleien, Drift, wenn sich die Rechtslage nach einem Urteil einer höheren Instanz ändert, und die Unfähigkeit, Glaubwürdigkeit oder Beweiswert zu beurteilen. Genau deshalb entscheidet der Richter.

Gemeinsame Bausteine & Kombinationen

• Gleicher Stack (ocr-docparse + llm-general + embedding-text + vector-db): DOC-014 Parsing, DOC-003 Formulare, DOC-008 Klassifizierung eingehender Post, DOC-009 und DOC-011 für die Prüfung von Verträgen und Datenräumen; ein selbst betriebener HW3-Inferenzserver kann mehrere davon bedienen.
• Ergänzend: KNOW-006 (Rechtsrecherche für den Richter, als getrenntes Werkzeug geführt), DOC-021 (eDiscovery/TAR, das Gegenstück auf Kanzleiseite für große Dokumentenmengen), DOC-005 (historisches oder handschriftliches Aktenmaterial).
• Gemeinsame Bausteine: Dokumentenparser, Zitat-/Verifikationsschicht, Speicher für das Audit-Protokoll, Guardrails für Vertraulichkeit, Workflow-Engine für die Kammerzuweisung.
• Hardware: HW3 gemeinsam für Gerichtsanwendungen genutzt; Mandantentrennung je Gerichtsbarkeit beibehalten.

Aufwand, Kosten & Kennzahlen

• Weg A: Wochen (Kanzlei-Variante); Preis pro Dokument oder pro Arbeitsplatz.
• Weg B: 2–4 Monate für einen Prototyp; für den produktiven Gerichtseinsatz nicht empfohlen.
• Weg C: 6–18 Monate inkl. Katalogentwurf mit der Richterschaft, E-Akte-Integration, Konformität und Registrierung; ein GPU-Server plus ein internes oder beauftragtes Team.
• Weg D: erhöht den Annotationsaufwand; zahlt sich bei Klagetypen mit hohem Volumen aus.
• Kennzahlen: Genauigkeit der Extraktion auf Feldebene gegenüber von Richtern geprüften Werten, Anteil der vom Richter korrigierten Werte, Zeit je Fall für Lesen und Entwerfen, Rückstand und Durchsatz bei den Massenverfahren, Einheitlichkeit der Ergebnisse über Kammern hinweg (beobachtet, nicht erzwungen), Zufriedenheit der Richterschaft; keine dieser Zahlen sollte ohne gemessene Ausgangsbasis zitiert werden.

Menschen & Veränderung

Beziehen Sie zuerst die Gerichtsleitung oder die Kanzleipartner ein, dann die Richterinnen, Richter und Kammervorsitzenden, die die Verfahren verantworten, die Geschäftsstellen als tägliche Nutzer, IT und IT-Sicherheit (isolierter Betrieb) sowie die/den Datenschutzbeauftragte(n), denn Gerichtsakten enthalten besondere Kategorien von Daten und eine DSFA ist sehr wahrscheinlich. Beziehen Sie die Personalvertretung früh ein.

Betriebsrat: in der Praxis ja. In Gerichten bestimmt der Personalrat (BPersVG oder Landesrecht) bei Software mit, die zur Überwachung von Beschäftigten geeignet ist, in Kanzleien der Betriebsrat nach § 87 Abs. 1 Nr. 6 BetrVG, da das BAG die objektive Eignung als ausreichend ansieht; § 90 Abs. 1 Nr. 3 verlangt rechtzeitige Information, und § 80 Abs. 3 erlaubt dem Betriebsrat, einen KI-Sachverständigen hinzuzuziehen. Die richterliche Unabhängigkeit bleibt unberührt: Das System schlägt vor, die Richterin oder der Richter entscheidet.

Die KI-Kompetenz nach Art. 4 KI-Verordnung muss durch Schulungen zu Grenzen, Automationsbias und Überprüfung extrahierter Tatsachen gefördert werden. Weil der Einsatz voraussichtlich hochriskant ist (Rechtspflege, Anhang III), planen Sie menschliche Aufsicht, Protokollierung und Dokumentation, anwendbar ab dem 2. Dez. 2027. Kommunizieren Sie offen, beginnen Sie mit einer Kammer und einem Klagetyp und sammeln Sie die Korrekturen der Richterschaft. Typische Sorgen: Verlust der Entscheidungsautonomie und Voreingenommenheit; begegnen Sie ihnen mit transparenten Vorschlägen, die Quellen zeigen, und einer verpflichtenden menschlichen Entscheidung. Leitfäden: GUIDE-004, GUIDE-014, GUIDE-006.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): Anhang III Nr. 8 Buchst. a führt KI-Systeme, die dazu bestimmt sind, von oder im Namen einer Justizbehörde verwendet zu werden, um bei der Ermittlung und Auslegung von Tatsachen und Recht und bei der Anwendung des Rechts auf Tatsachen zu unterstützen, als Hochrisiko auf [1]. Die Ausnahme nach Art. 6 Abs. 3 (eng gefasste Verfahrensaufgabe, vorbereitende Aufgabe) kann reine Extraktion oder Sortierung abdecken, aber je mehr ein System rechtliche Ergebnisse vorschlägt, desto weniger ist sie haltbar; die Ausnahme gilt nie bei Profiling natürlicher Personen, und Anbieter müssen die Bewertung dokumentieren [2]. Erwägungsgrund 61 betont, dass KI die Richterin oder den Richter unterstützen, aber nicht ersetzen darf: Die endgültige Entscheidungsfindung muss von Menschen getrieben bleiben [3].
• Betreiberpflichten (Art. 26): Nutzung gemäß Anweisung, kompetente menschliche Aufsicht, relevante Eingabe- daten, Überwachung und Meldung von Vorfällen, Aufbewahrung der Protokolle von mindestens sechs Monaten und, für öffentliche Stellen, Registrierung in der EU-Datenbank vor der Nutzung [4]. Die Pflichten nach Anhang III gelten ab dem 2. Dez. 2027 nach dem Digital Omnibus on AI (Verordnung (EU) 2026/1744, in Kraft seit dem 27. Juli 2026).
• Art. 5: Das Beurteilen, Vorhersagen oder Bewerten des Verhaltens oder der Eigenschaften von Einzelpersonen ist nicht Teil dieses Anwendungsfalls; fügen Sie keine Funktionen zum Profiling von Richtern oder Parteien hinzu.
• DSGVO: personenbezogene Daten der Parteien, teils besondere Kategorien (Gesundheit, Beschäftigung); Rechtsgrundlage im nationalen Verfahrens- und Gerichtsrecht, DSFA, Datenminimierung, kein externes Training mit Verfahrensdaten. Die justizielle Verarbeitung durch Gerichte folgt nationalem Recht und der Aufteilung zwischen Richtlinie für Strafverfolgung und DSGVO je nach Sachgebiet.
• Richterliche Unabhängigkeit und Recht auf ein faires Verfahren: keine automatisierte Entscheidung, Transparenz gegenüber den Parteien über den KI-Einsatz, soweit das nationale Recht dies verlangt, keine Steuerung des Ergebnisses, regelmäßige Überprüfung der Quoten, in denen Richter abweichen, und von Voreingenommenheit.
• Gegenmaßnahmen: geschlossene Parameterkataloge, verpflichtende Quellenverknüpfungen, deterministische Prüfungen, Protokollierung, Red-Team-Tests mit echten Aktentypen und eine Arbeitsgruppe der Richterschaft, die die Vorlagen verantwortet.

Erste Schritte

1. Einen Klagetyp mit großem Volumen und stabiler Rechtslage wählen (z. B. eine einzelne Konstellation bei Fluggastrechten oder Abgasen); eine Arbeitsgruppe aus Richterschaft, Geschäftsstelle und IT bilden.
2. Den Parameterkatalog und die Entwurfsbausteine gemeinsam definieren und festlegen, was das System niemals tun darf.
3. Einen Evaluierungsdatensatz aus 200+ von Richtern annotierten Akten aufbauen; Parser- und Modelloptionen darauf vergleichen.
4. Einen Pilot nur lesend (nur Übersicht und Extraktion) in einer Kammer durchführen, mit Quellenmarkierung und Protokollierung.
5. Die Unterlagen zur KI-Verordnung (Risikobewertung, Konzept der menschlichen Aufsicht, Registrierung, DSFA) abschließen, bevor auf vorausgefüllte Bausteine erweitert wird.

Quellen

1. EU AI Act, Annex III (point 8, administration of justice and democratic processes) — https://artificialintelligenceact.eu/annex/3/
2. EU AI Act, Article 6 (classification of high-risk systems, Art. 6(3) derogation, profiling) — https://artificialintelligenceact.eu/article/6/
3. EU AI Act, Recital 61 (judicial AI, human-driven final decision, ancillary administrative tasks) — https://artificialintelligenceact.eu/recital/61/
4. EU AI Act, Article 26 (obligations of deployers of high-risk systems) — https://artificialintelligenceact.eu/article/26/
5. Docling project (MIT-licensed document parsing) — https://github.com/docling-project/docling
6. Regulation (EU) 2024/1689 (AI Act), official text — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
7. LTO — Flut an Fluggastrechte-Klagen: KI soll Brandenburger Gericht unterstützen (FRAUKE, KAI) — https://www.lto.de/recht/nachrichten/n/verbraucherrechte-fluggastrechte-klagewelle-kuenstliche-intelligenz-amtsgerichte-frauke-frankfurt-wusterhausen
8. Landtag Baden-Württemberg, Drucksache 17/5658 (OLGA at OLG Stuttgart) — https://www.landtag-bw.de/resource/blob/264780/6034af8a83317e974461262a3cb770ca/17_5658_D.pdf