Judicial mass-proceedings assistant (court-side case-file processing)

Mass proceedings (diesel-emissions claims, air-passenger-rights claims, data-breach claims) flood courts with thousands of near-identical but individually argued files. A court-side assistant extracts the decisive facts from each pleading, groups similar cases, produces a structured overview and pre-fills order or judgment modules. The judge reads the sources, edits and decides. It is a high-risk system under the EU AI Act and must be designed around judicial independence.

Problem & value

• Today: judges and registry staff read each pleading, copy vehicle data, flight data, dates and amounts into spreadsheets, and reuse text blocks from earlier decisions by hand. Peaks (a new wave of claims after a landmark ruling) overload individual chambers.
• AI value: the repetitive reading and transcription is automated; the judge sees a verified, source-linked overview and a draft module. Time is freed for the legal assessment of the individual case. Consistent handling of parallel cases is easier to monitor.
• Real deployments (Germany): the Stuttgart Higher Regional Court (OLG Stuttgart) runs the assistant OLGA for diesel-emissions mass proceedings and the Frankfurt Local Court (AG Frankfurt) has used FRAUKE for air-passenger-rights cases since 2021 (press reports); the AG Königs Wusterhausen (Brandenburg) started a similar tool, KAI, in February 2025 [7]. The Baden-Württemberg government states that judges find OLGA considerably cuts the time needed to capture the state of the dispute, but gives no percentage [8]. No measured evaluation has been published, so do not quote efficiency figures until you have the courts' own evaluation reports.
• Why separate from neighbours: unlike legal research (KNOW-006) it processes the parties' own file; unlike form processing (DOC-003) the input is free-text legal argument; unlike contract analysis (DOC-009) the outputs feed a judicial decision process.

Variants

• Court side (core): extraction, clustering, case overview, pre-filled modules, always with judge approval; running inside sovereign justice IT.
• Registry/administrative only: anonymisation, pseudonymisation of decisions, mail sorting, file indexing. Recital 61 treats purely ancillary administrative tasks that do not affect individual cases as outside the high-risk category [3].
• Law-firm / legal-tech side: bulk intake of mass claims (mandate documents, claim parameters, drafting of standard pleadings). Not a judicial system, so Annex III No. 8 does not apply, but GDPR and professional-secrecy rules do; combinable with DOC-021.
• Administrative courts and arbitration: same architecture for asylum, social or tax matters; extra care because AI used by or for alternative dispute resolution bodies also falls under Annex III No. 8 [1].

How it works

1. e-file (pleadings, annexes)
2. OCR + layout parsing (scans, tables, annex lists) [ocr-docparse]
3. document typing (complaint, reply, expert opinion, order) [text-classifier]
4. parameter extraction against a catalogue per claim type [llm-general, schema-constrained] (vehicle/engine, purchase date, mileage, flight number, delay, amount, claimed head of loss)
5. source linking (every value
6. page + quote) [citation check]
7. clustering / similarity search across the docket [embedding-text, vector-db]
8. case overview + outlier flags for the chamber
9. pre-filled order / hint / judgment module (draft) [llm-reasoning, templates]
10. judge reviews, corrects, decides; edits logged [human-in-the-loop]

• Extraction is a closed catalogue, not open legal reasoning: the catalogue is maintained by the court (judges and IT) so that the system fills known fields rather than inventing issues.
• Pre-filled modules combine court-approved text blocks with extracted parameters. Free generation of legal reasoning is deliberately limited; every generated passage is marked as draft.
• Human-in-the-loop: the judge verifies each extracted value against the highlighted source, and alone decides on admissibility, merits and amounts. Disagreement and edit rates are logged.

Data preparation

The data are e-files (e-Akte), pleadings, annexes and decisions, held in court case-management systems, DMS or on file shares; at law firms also mail and templates. Typical gaps are scanned annexes without text layer, inconsistent naming of near-identical claims, missing case parameters as structured fields, scattered templates for orders and judgments, and strict access rights per proceeding that must carry over into any index.

Preparation steps: - Define the case parameters to extract (claimant, vehicle, claim amount, dates) as a fixed schema, see PREP-019. - OCR scanned annexes, see PREP-006, and convert formats, see PREP-007. - Collect gold-standard decisions and order modules approved by judges, see PREP-016. - Build a test set of 100-200 annotated filings with judges and clerks, see PREP-018. - Pseudonymise material used for tuning or evaluation, see PREP-022, and keep access rights per file, see PREP-023.

Rough share of effort: 30 percent, mostly schema, annotation and rights. Tools: Docling, PaddleOCR, Paperless-ngx style indexing, open-weight LLMs. See also DOC-018 and GUIDE-003.

Implementation paths

Which path for whom

• Public sector (courts): Path C, because case files contain highly sensitive personal data, the judiciary needs sovereign operation and the same platform can serve several proceedings types.
• Enterprise (law firms, legal departments): Path C, because client confidentiality and professional secrecy argue against external clouds and mass-claim volumes make seat or API costs high.
• Developer: Path C, because open-weight models and open-source parsers can be built into judicial or kanzlei systems directly.

Path A — Buy (off-the-shelf)

Few products target the bench specifically. Commercial legal-AI and eDiscovery suites (e.g. the German legal-tech providers and the large legal-research publishers' AI assistants) mostly serve law firms; for courts, justice-IT consortia and in-house projects dominate. Sensible when the need is law-firm side bulk intake or pure registry tasks. For judicial use require: EU hosting, no training on court data, AI Act provider documentation (Art. 13), conformity assessment.

Path B — Build on cloud APIs

Technically possible (EU-region frontier or EU-provider models via API plus parsing service), but courts hold sensitive personal data, including special categories in some matters, and are bound by judicial confidentiality and sovereignty expectations. Public-cloud APIs are realistic only for non-confidential prototypes with synthetic or anonymised files, or for law firms under professional-secrecy contracts and a DPA. A public-sector deployment must also satisfy the national security and cloud policies of the justice administration.

Path C — Self-host (open source) — recommended for courts

• Parsing: Docling (MIT licence) for PDFs and scans; PaddleOCR or similar for poor scans [5].
• Models: open-weight LLMs served in the court's own data centre via vLLM (e.g. Qwen, Mistral or Llama-family models in the 30–120B range) with schema-constrained decoding; open embedding models and a reranker for clustering and similar-case retrieval.
• Stack: PostgreSQL with pgvector or OpenSearch, a workflow engine, integration with the e-file system via its interfaces, role-based access per chamber.
• Hardware: HW3 (one 48–141 GB GPU) is a sensible minimum for a pilot at one court; HW4 for a state-wide shared service. Operations require an ML-ops team in the justice IT department.

Path D — Custom training

Worth it once labelled data exists: judge corrections of extracted values are ideal training data for a small fine-tuned extractor (cheaper and more predictable than a large general model), and for a classifier that sorts incoming pleadings by claim type. Hundreds to a few thousand annotated files per claim type; training stays inside the court's environment.

State of the art (2026)

• Document-to-JSON extraction with vision-language or text LLMs is mainstream; precision is high for well-formed header data and weaker for long, polemical pleadings, tables of annexes and scanned handwriting. Source citation per value is the key control.
• Clustering by embeddings plus rule-based parameters finds parallel cases and outliers; similarity search over prior decisions supports consistency but can also propagate old errors.
• Reasoning models can draft structured legal modules, but remain prone to fabricated citations and to subtle misreading of dates or amounts; a deterministic check of arithmetic and deadlines should sit outside the model.
• Governance practice: European guidance for judicial AI (CEPEJ ethical charter) stresses fundamental rights, non-discrimination, quality and security, transparency and "under user control"; the AI Act now makes parts of this binding for high-risk systems.
• Limits: automation bias (the draft anchors the judge), uneven quality across law firms' writing styles, drift when the legal position changes after a higher-court ruling, and inability to judge credibility or evidence weight. These are exactly why the judge decides.

Shared resources & combinations

• Same stack (ocr-docparse + llm-general + embedding-text + vector-db): DOC-014 parsing, DOC-003 forms, DOC-008 classification of incoming mail, DOC-009 and DOC-011 for contract and data-room review; one self-hosted HW3 inference server can serve several of them.
• Complementary: KNOW-006 (legal research for the judge, kept as a separate tool), DOC-021 (eDiscovery/TAR, the law-firm counterpart for large document sets), DOC-005 (historical or handwritten file material).
• Shared building blocks: document parser, citation/verification layer, audit-log store, guardrails for confidentiality, workflow engine for chamber assignment.
• Hardware: HW3 shared across court applications; keep tenant separation per jurisdiction.

Effort, cost & KPIs

• Path A: weeks (law-firm variant); per-document or per-seat pricing.
• Path B: 2–4 months for a prototype; not recommended for productive court use.
• Path C: 6–18 months incl. catalogue design with judges, e-file integration, conformity and registration; a GPU server plus an in-house or contracted team.
• Path D: adds annotation effort; pays back for high-volume claim types.
• KPIs: field-level extraction accuracy against judge-verified values, share of values corrected by the judge, time per case for reading and drafting, backlog and throughput of the mass-claim docket, consistency of outcomes across chambers (monitored, not enforced), judge satisfaction; none of these figures should be quoted without a measured baseline.

People & change

Involve court management or the firm partners first, then the judges and chamber heads who own the proceedings, the clerks as daily users, IT and IT security (isolated operation), and the data protection officer, because case files include special categories of data and a DPIA is very likely. Add the staff council early.

Works council: yes in practice. In courts the Personalrat (BPersVG or state law) co-determines software suited to monitor staff, and in firms the Betriebsrat does under §87(1) no. 6 BetrVG, since the BAG treats objective suitability as sufficient; §90(1) no. 3 requires information in good time and §80(3) allows the works council to bring in an AI expert. Judicial independence is untouched: the system proposes, the judge decides.

AI literacy under Art. 4 AI Act needs to be supported through training on limits, automation bias and verification of extracted facts. Because the use is likely high-risk (administration of justice, Annex III), plan human oversight, logging and documentation, applying from 2 Dec 2027. Communicate openly, start with one chamber and one claim type, and collect judges' corrections. Typical concerns: loss of decision autonomy and bias; address with transparent proposals showing sources and a mandatory human decision. Guides: GUIDE-004, GUIDE-014, GUIDE-006.

Risks, regulation & compliance

• EU AI Act: Annex III No. 8(a) lists AI systems intended to be used by or on behalf of a judicial authority to assist in researching and interpreting facts and law and in applying the law to facts as high-risk [1]. The Art. 6(3) derogation (narrow procedural task, preparatory task) may cover pure extraction or sorting, but the more a system proposes legal outcomes, the less defensible it is; the derogation never applies when profiling natural persons, and providers must document the assessment [2]. Recital 61 stresses that AI may support but not replace the judge: final decision-making must remain human-driven [3].
• Deployer duties (Art. 26): use per instructions, competent human oversight, relevant input data, monitoring and incident reporting, log retention of at least six months, and for public bodies registration in the EU database before use [4]. Annex III obligations apply from 2 Dec 2027 under the Digital Omnibus on AI (Reg. (EU) 2026/1744, in force since 27 Jul 2026).
• Art. 5: judging, predicting or scoring individuals' behaviour or characteristics is not part of this use case; do not add judge-profiling or party-profiling features.
• GDPR: parties' personal data, sometimes special categories (health, employment); legal basis in national procedural and court law, DPIA, data minimisation, no external training on case data. Judicial processing by courts follows national law and the Law Enforcement/GDPR split depending on the matter.
• Judicial independence and right to a fair trial: no automated decision, transparency for parties about AI use as national law requires, no outcome steering, regular review of judge override rates and bias.
• Mitigations: closed parameter catalogues, mandatory source links, deterministic checks, logging, red-team testing with real file types, and a judges' working group owning the templates.

Getting started

1. Pick one claim type with large volume and stable law (e.g. a single air-passenger-rights or emissions constellation); form a working group of judges, registry staff and IT.
2. Define the parameter catalogue and the draft modules together, and fix what the system must never do.
3. Build an evaluation set of 200+ judge-annotated files; compare parser and model options on it.
4. Pilot read-only (overview and extraction only) in one chamber, with source highlighting and logging.
5. Complete the AI Act file (risk assessment, human-oversight design, registration, DPIA) before extending to pre-filled modules.

Sources

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