eDiscovery & technology-assisted review (litigation, investigations, DSAR)

In litigation, regulatory requests, internal investigations and bulk GDPR access requests, a party must find the relevant needles in millions of emails, chats and files. Technology-assisted review (TAR) ranks documents with active learning; since 2023-2024 LLM-based first-pass review adds natural-language review criteria with written rationales. Combined with statistical validation (recall, elusion), this shrinks the volume that lawyers read, while keeping the process defensible before a court or authority.

Problem & value

• Today: collections from custodians run to hundreds of thousands or millions of items. Keyword culling is crude; linear review by contract attorneys is slow and expensive. A RAND study of US e-discovery costs is the classic reference that review is the dominant cost component [8]. The same pressure exists in EU practice: antitrust dawn raids, internal compliance investigations, whistleblower cases and mass GDPR Art. 15 requests.
• AI value: (1) dedup, email threading and near-duplicate grouping; (2) TAR/continuous active learning to prioritise; (3) LLM first-pass review with reasons and citations; (4) QC of human review against a statistical sample; (5) privilege and personal-data identification; (6) chronologies and case summaries.
• Reported results (vendor claims, treat as claims): Relativity states aiR for Review delivers "90%+ recall" without the setup of classic TAR models [1]. A research paper on graph/LLM eDiscovery describes retrieval and reasoning methods for investigations [5]. Always replicate on your own matter with a validation sample.
• Legal acceptance: US courts approved TAR from 2012 (Moore v. Publicis), called it "black letter law" in Rio Tinto v. Vale (2015) and in Hyles v. NYC (2016) saw it as likely the best tool in most cases, but would not force it on the responding party [4]. English and Irish courts followed (e.g. Pyrrho v MWB, 2016).

Variants

• Litigation / arbitration: responsiveness, issue coding, privilege review and privilege log.
• Regulatory and antitrust requests: high-recall review under authority deadlines; multi-language collections.
• Internal and whistleblower investigations: targeted custodians, chat and mobile data, timeline building; works-council and employee-data rules apply (BDSG §26, Betriebsrat).
• GDPR Art. 15 DSAR response: find all personal data of one subject in mail and files, separate third-party data, redact (see DOC-018). The EDPB guidelines on the right of access (final version April 2023) set the expected search effort and limits [3].
• Legal hold and early case assessment: preserve, estimate volume, assess merits before collecting everything.
• SMB / private: very small matters use review features inside M365/Google Vault or a pay-per-GB SaaS; no private-consumer use case.

How it works

1. legal hold + collection (M365, Google, Slack/Teams, file shares, mobile)
2. processing: extraction, OCR, language detection, dedup, email threading, near-dup grouping
3. search/culling: date, custodian, keywords, concept/embedding search
4. prioritisation: TAR (continuous active learning) and/or LLM first-pass scoring
5. review: lawyers code samples; LLM proposes responsive/issue/privilege tags with rationale and cited passages
6. validation: random sample
7. recall, precision, elusion with confidence interval
8. privilege log, redaction (DOC-018), production or DSAR pack
9. audit trail and protocol documentation

• TAR 1.0/2.0: a classifier (logistic regression or similar over text features) is trained on lawyer decisions; in continuous active learning the highest-ranked unreviewed documents go next, and the process stops when a validated recall target is reached.
• LLM review: the case team writes review criteria as a prompt; the model returns a label, a rationale and quoted passages for each document (or document family). It is calibrated on a sample set against senior-lawyer decisions before roll-out.
• Human-in-the-loop: counsel defines issues, signs off the protocol, decides on privilege, and certifies production. Models never decide privilege waiver or production alone.

Data preparation

The data is the collection itself: mailboxes and Teams/Slack chats (M365, Google), file shares, DMS, cloud documents, mobile data and paper scans. Typical gaps are image-only PDFs without text, duplicate and near-duplicate copies across custodians, missing custodian and date metadata, password-protected or exotic file formats, mixed languages, and unclear access rights to private chats and mailboxes.

Preparation steps: issue a legal hold and fix the custodian list first; collect with forensically sound export tools (Purview, platform collectors); run processing for text extraction, OCR (see PREP-006), de-duplication, e-mail threading and language detection; convert legacy archives (PREP-007); and pseudonymise exports used for testing (PREP-022). Check the legal basis for reusing the data for the matter (PREP-025) and classify what may go into which AI tool (PREP-024). Then build a small seed and validation set with senior lawyers (PREP-018) and define issue categories before the first AI run (PREP-019).

Most processing is handled by the platform, so data preparation is a medium share of the effort, roughly 20 to 30 percent. The real work sits in scoping, legal hold and access rights per matter. See also DOC-018 for redaction and GUIDE-003 for a readiness check.

Implementation paths

Which path for whom

• smb: Path A, because eDiscovery and DSAR matters are episodic and a hosted review platform or a DSAR tool brings the audit trail without building anything.
• enterprise: Path A, because court-accepted defensibility and mature platforms matter more than cost per seat; move to B only for recurring, high-volume internal investigations.
• public: Path C, because privileged and investigative material often may not leave the authority and air-gapped operation is possible.
• developer: Path B, because law firms and legal-tech vendors build tailored review or DSAR tools on EU-hosted APIs and can document validation.

Path A — Buy (recommended)

• Review platforms with GenAI: Relativity (RelativityOne with aiR for Review and aiR for Case Strategy) [1]; Everlaw; DISCO; Reveal (incl. Logikcull, Brainspace); Nuix; Exterro; Epiq and other service providers who bundle platform plus managed review. Verify hosting region, data-processing agreement and which LLM subprocessor is used per feature.
• In-platform for M365 users: Microsoft Purview eDiscovery (Standard/Premium) with legal hold, custodian management, review sets, threading, near-duplicate analysis and predictive coding models [2]; the classic experiences were retired on 31 Aug 2025, so use the new Purview-portal experience.
• EU/German context: check EU-region hosting at each vendor; German providers of DSAR/eDiscovery tooling and legal-tech integrators exist but should be evaluated individually. DSAR-specific SaaS (privacy-management suites) is often enough for Art. 15 workloads.
• Choose A when: matters are episodic, defensibility and court acceptance matter most, and you need an audit trail that opposing counsel and regulators know.

Path B — Build on cloud APIs

• Frontier or EU-hosted LLMs via cloud APIs (Azure OpenAI in EU regions, Mistral, Claude or Gemini in EU regions) for document-level classification with structured output (label, rationale, quote, confidence).
• Embedding + reranker for concept search and active-learning seeds; hybrid index (OpenSearch/Elasticsearch plus vectors).
• Pipeline in Python with Tika/Docling-style extraction; orchestration by n8n or a job queue. Required: zero-retention contracts, per-matter data isolation, EU data residency, logging of every prompt/response for later defence.
• Choose B when: you are a law firm, Big-4 or software vendor building a tailored review or DSAR tool and can document validation.

Path C — Self-host (open source)

• Stack: ingestion with Apache Tika, Docling or PaddleOCR; OpenSearch for full-text; Postgres/pgvector or Qdrant; open-weight LLMs (Qwen, Mistral, Llama families, 30-120B class) served with vLLM; multilingual embedding and reranker models (e.g. BGE, Qwen3-Embedding). TAR classifiers with scikit-learn are cheap and run on CPU. Open-source eDiscovery frameworks exist but are far less complete than commercial review platforms, so expect to build review UI, hold management and production formats yourself.
• Hardware: HW3 (one 48-141 GB GPU) for a 30-70B model over a few hundred thousand documents; air-gapped operation is possible, which suits state authorities and high-sensitivity investigations.
• Choose C when: data may not leave the organisation (public sector, defence-adjacent, privileged investigations) and volumes justify the engineering.

Path D — Custom training

Fine-tuning rarely pays off: matter-specific relevance is defined per case, and TAR already trains a classifier per matter. Worth considering only for a stable recurring task (for example a bank's recurring conduct-surveillance categories or a DSAR personal-data detector) with thousands of labelled examples, or to distil a cheap small model from LLM labels to cut cost on very large volumes.

State of the art (2026)

• Two generations coexist: classic TAR with continuous active learning (court-tested, transparent, cheap) and LLM review (no training rounds, rationales, criteria change mid-matter). Platforms now offer both; practice is hybrid, e.g. LLM for first-pass scoring on a prioritised set with TAR or sampling for stopping decisions [1][2].
• Validation is the key: recall estimated from a random sample of the unreviewed (null) set, elusion rate, and comparison to senior-lawyer coding. Validation protocols are negotiated with the other side or documented for the authority.
• Agentic and graph methods for investigations: entity extraction, chronologies, communication graphs and question answering with citations over a collection [5].
• Limits and failure modes: hallucinated rationales, inconsistent labels across prompt versions, weak recall on rare issues, slang/coded language, images, voice notes, spreadsheets and chat fragments lacking context; long document families; multilingual collections; privilege judgments needing context (in-house vs outside counsel, third-party presence). Vendor recall figures come from vendor-chosen matters.

Shared resources & combinations

• Same blocks: ocr-docparse + embedding/reranker/vector index + LLM server. One RAG stack serves KNOW-002 and KNOW-001; DOC-014 supplies the parsing pipeline; DOC-008 classification and KNOW-025 retention labelling reuse text classifiers.
• Natural combinations: DOC-018 (redaction of personal data and privileged passages, DSAR packs), DOC-011 (data-room review uses similar clause/issue tagging on a curated set), DOC-009 (contract analysis for the documents found), KNOW-006 (legal research), KNOW-026 (investigative link analysis, entity resolution), SEC-017 (sensitive data discovery to scope collections), DOC-020 (court-side case-file processing receives the production sets).
• Hardware: a HW3 GPU server can host the LLM, embeddings and reranker for all of the above; fully offline for sensitive matters.

Effort, cost & KPIs

• Path A: weeks to onboard, matter-based or per-GB/month pricing; managed review adds service fees. Path B: 3-6 months incl. validation protocol and security review. Path C: 6-12 months for a comparable feature set; justified mainly by sovereignty needs. Path D: add 2-4 months and labelled data.
• Cost drivers: data volume (GB hosted), number of documents sent through LLMs, reviewer hours remaining, language mix, expert/validation work.
• KPIs: recall and precision at stop point (with confidence interval), elusion rate, documents reviewed by humans as % of collection, cost per document, review hours saved, privilege-log error/clawback rate, DSAR turnaround vs one-month deadline (Art. 12 GDPR), consistency between reviewers and model.

People & change

Involve management and legal/compliance at the start (matter policy, budget, who may use AI on privileged material). The data protection officer comes in before the first collection: legal basis, AVV with the platform and its LLM subprocessors, and a DPIA, since mass evaluation of employee communication is likely to need one (GUIDE-005). IT and IT security set up collection, access rights and tenant isolation; data owners release mailboxes and shares.

Works council: yes, as a rule. Reviewing employee mail and chat touches §87(1) no. 6 BetrVG, because the platforms log and evaluate user activity (objective suitability is enough per the BAG), and internal investigations use employee data. Inform it early under §90(1) no. 3 and agree rules on purpose, access and retention; an expert under §80(3) can be engaged (GUIDE-004). In the public sector the staff council applies.

Train reviewers (AI Act Art. 4 requires measures that support AI literacy, GUIDE-006): how the LLM proposes tags, how to spot errors and how validation works. Start with one pilot matter and a small review team, compare LLM tags against senior-lawyer decisions, and then decide go/no-go (GUIDE-009). Typical concerns are job loss among reviewers and liability for missed documents. Address them by keeping counsel in charge of privilege, protocol and certification, and by documenting recall figures.

Risks, regulation & compliance

• EU AI Act: a party's own review tool is typically not an Annex III system; AI intended to assist a judicial authority in researching and interpreting facts and law falls into Annex III point 8 (administration of justice) and is high-risk, relevant for DOC-020 and court-side use. Employee-related investigations should not slide into worker monitoring or evaluation that triggers Annex III point 4. Art. 5 bans emotion recognition at work; do not use sentiment/emotion scoring on employee communications. Art. 4 AI literacy applies. Hence: depends [6].
• GDPR: review sets contain large volumes of personal and special-category data; need a legal basis (Art. 6(1)(f) or (c), Art. 9(2)(f)), purpose limitation, data minimisation (cull early), DPIA for large investigations, processor agreements, and transfers (US requests vs Art. 48; Blocking-statute and Schrems II issues for cross-border discovery). DSAR work follows the EDPB guidelines [3].
• Employment and secrecy law: works council co-determination (§87 BetrVG), BDSG §26, telecommunications secrecy for private use of mail, lawyer-client privilege and professional secrecy (§203 StGB) when cloud providers are used.
• Procedural: duty to preserve, spoliation sanctions, cooperation duties in the chosen court; German civil procedure has no US-style discovery, so EDD in Germany centres on investigations, antitrust, arbitration and US matters.
• Mitigations: documented protocol, validation sample, senior-lawyer QC, full prompt/response logging, matter-level isolation, no training on customer data, EU hosting or air-gap, human sign-off on privilege and production.

Getting started

1. Pick a closed past matter with known outcomes and run it as a pilot, comparing the AI result with the actual human coding.
2. Define issues and review criteria precisely; have a senior lawyer code a 300-500 document control sample.
3. Evaluate 2-3 platforms (Path A) on that matter: measure recall, precision and elusion, check EU hosting and subprocessors.
4. Write the validation and stopping protocol, and get legal and data-protection sign-off (DPIA, works council where relevant).
5. Roll out to one live DSAR or internal investigation first before using it in adversarial litigation.

Sources

1. Relativity — aiR for Review / aiR for Case Strategy — https://www.relativity.com/data-solutions/air/
2. Microsoft Learn — Microsoft Purview eDiscovery overview (Standard, Premium, predictive coding, classic retirement 31 Aug 2025) — https://learn.microsoft.com/en-us/purview/ediscovery
3. EDPB — Guidelines 01/2022 on data subject rights, right of access (final April 2023) — https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-012022-data-subject-rights-right-access_en
4. Wikipedia — Electronic discovery (EDRM stages, TAR, Rio Tinto v. Vale, Hyles v. NYC) — https://en.wikipedia.org/wiki/Electronic_discovery
5. arXiv 2405.19164 — Learning from Litigation: Graphs and LLMs for Retrieval and Reasoning in eDiscovery — https://arxiv.org/abs/2405.19164
6. Regulation (EU) 2024/1689 (AI Act), Annex III and Art. 5, 6, 50 — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
7. arXiv 2512.08078 — A Comparative Study of Retrieval Methods in Azure AI Search (early case assessment) — https://arxiv.org/abs/2512.08078
8. RAND Institute for Civil Justice — Where the Money Goes: Understanding Litigant Expenditures for Producing Electronic Discovery (MG-1208) — https://www.rand.org/pubs/monographs/MG1208.html