Legal Document Extraction AI On-Prem: The Intake Guide

A personal injury or clinical negligence file arrives at a UK law firm as a pile of documents long before it becomes a case. Medical records, GP letters, discharge summaries, treatment invoices, correspondence and the client's own account all land in the first weeks, and someone has to turn them into an indexed bundle, a chronology and a limitation diary entry. The NHS figures point upward. NHS Resolution's annual report for 2025/26 records 15,236 new clinical negligence claims and reported incidents, up from 14,428 the year before.

That is the problem legal document extraction is meant to address, and it is also where the data constraints are hardest. An intake file in these practice areas holds health data about an identifiable person and material the firm must keep confidential, so the question of where a model runs comes before the question of how well it reads. This guide is written for the Head of Technology or the Chief Data and AI Officer at a firm weighing on-premise extraction for intake. It covers what legal intake extraction is, why the clinical negligence file is the sharpest test, which fields a model can draft and which a lawyer must decide, and how to test a model without breaking confidentiality.

It also states its boundaries, and it sits with our other industry guides. The intake call itself belongs to our guide on AI voice for law firm client intake. Supervision of agent work across a matter belongs to the supervision record for AI agent work. The firm-wide map of where each DILR line fits sits in AI for law firms in the UK. And how clinical extraction models are measured belongs to the clinical document extraction guide. This post holds the intake file itself, and it is honest about one thing above all: legal intake is a research direction for Dilr Mira, not a shipped legal product.

This guide is shipped by the team behind Dilr Mira, private clinical small language models that turn scans, lab reports and claim forms into source-grounded, schema-valid JSON on the customer's own hardware. Or see DATS, the five-stage AI consulting system through which private model work is scoped and delivered.

What is legal intake document extraction?

Legal intake document extraction is the conversion of the documents a law firm receives at the start of a matter into structured fields a fee earner can check: parties, dates, providers, events, document types and page references. The output is a draft index and chronology, not advice. For a UK firm the defining constraint is that intake documents are confidential and often contain health data, so where the extraction model runs matters as much as its accuracy.

In practice an intake file is a mix of document types with very different shapes. A client questionnaire is semi-structured. A treatment invoice is a table. A discharge summary is clinical shorthand. A letter from a consultant is narrative prose. A solicitor's letter of claim is legal argument. An extraction model asked to read all of these into one schema is being asked to do several jobs at once, which is why the honest unit of evaluation is the document type, not the file.

The schema is where a firm encodes its own practice. A clinical negligence team will want treating provider, date of attendance, presenting complaint, procedure, medication and the page of the bundle each fact came from. A personal injury team will want the accident date, first attendance, diagnosis and the treatment timeline. The idea of the schema as an input, rather than a fixed set of categories baked into the tool, is what makes the approach portable across practice areas, and it is the same idea the KYC document extraction guide applied to onboarding packs, where the fields and the regulation are entirely different.

What extraction does not do is decide anything. Every field it produces is a claim about what a document says, and the value of a well-built extraction step lies in making each of those claims traceable to a page so a person can check it quickly.

Why is a clinical negligence intake file a medical records problem?

A clinical negligence intake file is a medical records problem because the case is built from the claimant's health records before anything else. Under the Pre-Action Protocol for the Resolution of Clinical Disputes, the claimant requests copies of those records, the healthcare provider supplies them, and the claimant's side should organise them into a usable bundle. In practice the reading, indexing and dating of those records is work the claimant's firm does.

The protocol sets the timetable. Paragraph 3.4.1 of the Pre-Action Protocol for the Resolution of Clinical Disputes says copy records should be provided within 40 days of the request, and paragraph 3.7 lets the claimant apply to court under CPR 31.16 for pre-action disclosure if neither the records nor an explanation arrive in that time. The expectation to supply sits with the healthcare provider as defendant. The expectation to organise what arrives sits with the claimant's side, in the protocol's own words:

"At the earliest opportunity, legible copies of the claimant’s medical and other records should be placed in an indexed and paginated bundle by the claimant."

That single sentence describes an extraction task. Indexing means knowing what each document is and when it was written. Paginating means every later fact can point to a page. A chronology built on that bundle is what a fee earner, counsel and an expert all work from, so an error introduced at indexing travels through the whole matter.

The scale is not small. NHS Resolution, which administers the NHS indemnity schemes in England and handles the associated compensation claims, received 15,236 new clinical negligence claims and reported incidents in 2025/26 against 14,428 in 2024/25, and the same report says 84% of clinical claims were kept out of formal court proceedings in 2025/26, a figure NHS Resolution also highlighted in its press release of 9 July 2026. Those are defendant-side counts of claims and reported incidents, not a measure of claimant firm intake, but a claim that resolves without litigation still needs its records read and organised, so the records work does not disappear when a case stays out of court.

Personal injury files carry the same records-heavy shape, and the practice area is a large one for complaints as well: the Legal Ombudsman's 2024/25 complaints data records personal injury as 14% of the complaints it accepted, 1,016 complaints in the year. The healthcare side of the same records problem is covered in AI for healthcare in the UK, which looks at it from the provider's desk rather than the claimant's.

What does UK GDPR Article 9 mean for a firm holding health records?

UK GDPR Article 9 means a law firm holding a claimant's medical records is processing special category data and needs a condition for doing so. Article 9(2)(f) covers processing that is necessary for the establishment, exercise or defence of legal claims, or where courts or tribunals act in their judicial capacity. The firm relies on that condition as controller and remains accountable for the processing whichever tool it uses.

The text of Article 9 on legislation.gov.uk is the starting point for a litigation team. What matters for extraction design is the word necessary. Sending a full set of medical records to an external service so a model can read them is a processing step the firm has to be able to justify, document and secure, and the ICO guidance on AI and data protection sets out the accountability questions a controller should be able to answer when AI sits in that processing chain.

Professional guidance points the same way. The Law Society's Generative AI: the essentials, updated on 30 June 2026, advises firms to establish whether a generative AI tool is a closed system within the firm's boundaries or also operates as a training model for third parties. It also says it is generally advisable not to feed confidential information into generative AI tools where the firm lacks direct control and oversight of the tool's development and deployment, and that confidential data should not go into a free online service at all.

Article 9 does not say where a model should run. The accountability it creates, read with the Law Society guidance, is what turns deployment location into a first-order design choice. A model that runs on the firm's own hardware keeps the medical records inside the firm's existing security perimeter, with the firm's existing access controls, logging and retention rules. A model behind an external API adds a processor, a transfer and a set of contract terms to examine. Neither is automatically unlawful. The point is that the on-premise route removes questions rather than answering them, which is why the AI operating model decision about where models run belongs before any tool selection.

Which intake fields can a model draft, and which must a lawyer decide?

A model can draft the descriptive fields in a legal intake file: document type, author, date, provider, page reference, medications, procedures and the order of events. A lawyer must decide the evaluative fields: the limitation date, whether a document is privileged, whether a breach of duty is arguable, causation and merits. Extraction speeds up the first list. It has no role in deciding the second, and a well-designed workflow keeps the two visibly separate.

The limitation date is the clearest example of why. Under section 11 of the Limitation Act 1980, the period for a personal injury action is three years from the date the cause of action accrued or, if later, the date of knowledge of the person injured, and section 14 defines that date of knowledge by reference to when the claimant knew the injury was significant and attributable to the act or omission complained of. A model can extract the date of a scan and the date of a diagnosis letter. It cannot decide which of those, if either, fixed the claimant's knowledge.

The table is deliberately conservative. Each "yes" in the middle column is a draft that a fee earner confirms against the page, which is why a page reference on every extracted value is not a nice-to-have. Without it, checking a field means rereading the document, and the time saved disappears.

The same discipline answers a common objection from supervising partners: that extraction will tempt junior staff to trust the output. The answer is a workflow in which the draft index cannot be finalised without a named person confirming it, and in which every value links to its source. That is a design decision for the firm's AI execution office to own, not a feature of any model.

Does Dilr Mira read legal intake files today?

No. Dilr Mira does not read legal intake files as a shipped product today. DILR.AI's models page lists legal intake as a research direction for the same verifier-gated, schema-as-input extraction method, alongside insurance claims, prior authorisation, KYC and onboarding, invoices and receipts, and lab networks, and states plainly that clinical extraction is what is shipped. No evaluation of Dilr Mira on legal documents has been published.

What is shipped is narrower and is described precisely on the live page. Dilr Mira is a class of private clinical small language models of around 3B parameters, built on Qwen2.5-3B-Instruct, that turn scans, lab reports and claim forms into source-grounded, schema-valid JSON on the customer's own hardware. The current release, Mira-Q2, is open on Hugging Face, runs on CPU and takes about 2 GB on disk at 4-bit, with a GPU only for speed. Its page says it is strongest on the types it was trained on: lab reports, medication lists, discharge summaries, pathology reports, intake forms and progress notes, in English, with broader document types in development for Mira-3.

Some of those document types do appear inside a clinical negligence bundle. That overlap is real, but it is not a legal product, and it should not be read as one. A bundle also holds consultant letters in narrative prose, correspondence, invoices and legal documents, and the published scores say nothing about how a model would perform on a law firm's mix of files under a law firm's schema.

The published scores themselves need careful reading, as the Mira-Q2 evaluation write-up explains. Mira-Q2 was measured on 782 documents across four test sets, with zero identifier leaks across all 782. Its field-F1 of 1.000 applies to the held-out gold set only, which the models page labels as the training distribution, with a 95% confidence interval of 0.999 to 1.0. JSON validity is 94.7% on the set of real physician documents on-schema and 85.8% on the mtsamples set of real physician documents. That gradient is published rather than hidden, and it is the right frame for any firm: performance on your documents is unknown until you measure it on documents like yours. Our guide to what Dilr Mira is sets out the line's shipped and in-development scope in full.

How should a firm test an extraction model without breaking confidentiality?

A firm should test a legal extraction model on fictional intake bundles first, inside its own environment, and measure field by field before any real client document is used. The Law Society advises that, as a general rule, personal data and client confidential information should not be used in testing or templating on generative AI, and that firms should create and use fictional data. That rules out the easy route of trying a tool on a live file.

The guidance is direct on the point, and it changes how an evaluation is built. A fictional bundle has to look like a real one: scanned pages of uneven quality, clinical shorthand, handwritten annotations transcribed badly, letters that contradict each other on dates. Building it takes effort, but it produces something more useful than a demo, because the firm writes the gold answers and so knows exactly what correct looks like for every field in its own schema.

The test design that follows from this has four stages, and the order matters because each stage gates the next.

The verifier gate in the third stage is a published part of how Dilr Mira works in clinical use: every output is a draft for human review, gated by a deterministic verifier that checks schema validity, source grounding and identifier leakage. A firm testing any extraction model, ours or another, should insist on an equivalent check. A field that cannot be grounded to a span of the source document should be flagged, not filled in, and an identifier appearing where the schema does not allow one should stop the output.

Measurement should be per field and per document type. An overall accuracy number for a mixed bundle hides the field that matters most. If the model is reliable on attendance dates and unreliable on medication doses, the firm needs to know that before it decides which fields to automate and which to leave entirely to people. The same per-field logic appears in the health insurance claims extraction guide, where a claims file faces the same mixed-document problem from the insurer's side.

The same diagnostic logic underpins our AI execution office, which puts a named owner on each shipped workflow.

Only after the fictional bundle passes should the firm consider real documents, and even then the decision belongs to the firm under its own client engagement terms and its own data protection assessment. The open-model extraction guide covers how to read published scores before that point, and how to compare them with your own.

On-premise deployment for privileged and confidential documents

On-premise deployment matters because it keeps privileged and confidential intake documents inside the firm's existing perimeter, under the firm's own access controls and logs, with no outside service processing them. For a law firm that narrows the questions the Law Society asks about an external tool, such as whether it is a closed system and how the vendor handles the firm's data. It does not remove the firm's own duties, which stay with the firm wherever the model runs.

There are practical limits to weigh honestly. Running a model on the firm's hardware means the firm, or a delivery partner, owns updates, monitoring and capacity. A delivery partner who maintains the model still needs governed access, like any other supplier. A small model needs less hardware than a large one, and Mira-Q2's footprint of about 2 GB at 4-bit on a CPU is the reason on-premise is practical for it, but footprint is not the same as fitness for legal documents. A firm should treat a small on-premise model as one option to evaluate, not a default.

Confidentiality also changes what a firm can ask of a vendor. With a cloud tool, the firm reviews terms on retention, training use and sub-processors. With an on-premise model, the firm reviews the model's provenance, the evaluation it was released with and the update path. Both are diligence. They are different diligence, and a firm should know which kind it is doing. If the answer is unclear, a scoping conversation is a cheaper place to find out than a failed pilot. The OpenBioLLM comparison shows how to read a model's published claims before trusting them.

What is the best approach to legal document extraction in 2026?

The best approach to legal document extraction in 2026 depends on what the firm needs to ship now and how sensitive its files are. For disclosure and review at scale, an established ediscovery platform such as Everlaw is the shipped option. For clinical documents inside a claim file, cloud medical services such as Amazon Comprehend Medical exist. For files that must stay on the firm's hardware, a small private model evaluated on fictional bundles is the route.

Each option wins somewhere. Everlaw describes itself as an ediscovery platform with use cases including early case assessment and legal holds, and a firm whose problem is review and disclosure rather than intake indexing will find a shipped product built for that work, which a research direction is not. Amazon Comprehend Medical is a HIPAA-eligible natural language processing service that extracts health data from medical text, HIPAA eligibility is a US standard and says nothing about UK GDPR on its own, so a UK firm considering a cloud service of that kind for the clinical documents in a bundle would rely on its own data protection assessment.

The criteria that should decide between them are the same in every case:

1. Where the documents are processed, and whether that location is one the firm can justify for special category data under Article 9.
2. Whether every extracted value points to a page, so a fee earner can confirm it quickly.
3. Whether the tool has been measured on documents like the firm's, by the firm, on fictional data first.
4. Whether evaluative decisions, limitation above all, stay with a named lawyer by design.

On those criteria, Dilr Mira's honest position is narrow. It is a shipped clinical extraction model that runs on the customer's own hardware, and legal intake is a research direction for its method, not a product a firm can buy today. A firm that needs a legal intake product this quarter should choose a shipped one. A firm that needs its medical records to stay inside the building can evaluate the private model route on fictional bundles first, knowing no legal evaluation of Dilr Mira exists yet, and the DATS consulting guide explains how that kind of engagement is scoped.

Can a law firm put client documents into a public AI tool?

A law firm should not put confidential client documents into a free public AI tool. The Law Society's generative AI guidance, updated on 30 June 2026, says confidential data should not go into a free online generative AI service, and advises caution wherever the firm lacks direct control and oversight of the tool. Medical records in a claim file are also special category data under UK GDPR.

How long does a healthcare provider have to supply records before a clinical negligence claim?

Under the Pre-Action Protocol for the Resolution of Clinical Disputes, a healthcare provider should supply copies of the claimant's health records within 40 days of the request. If neither the records nor an explanation arrive within 40 days, the claimant can apply to court under CPR 31.16 for pre-action disclosure, and the court can impose costs sanctions for unreasonable delay in providing records.

Is Dilr Mira a medical device or a legal product?

Dilr Mira is neither. DILR.AI describes it as an extraction tool, not a medical device: every output is a draft for human review, gated by a deterministic verifier, and never an autonomous clinical decision. It is not a legal product either, because DILR.AI lists legal intake as a research direction for the Mira method and states that clinical extraction is what is shipped today.

Want to see where private extraction fits? Read about Dilr Mira private models, book an AI placement diagnostic, see our DATS methodology, or read about our approach to placing AI inside regulated firms.

Written by the Dilr.ai engineering team, practitioners who ship enterprise AI in production. Follow us on LinkedIn for shipping notes, or subscribe via the RSS feed.