Automatic document generation: when you need an LLM and when you need a template

Short answer: a document with legal force is assembled from a template, and the model goes on the input side of the generator, not the output side. The wording in a contract, a claim or a notice has to be exactly the wording a lawyer approved. A generative model produces slightly different text every time, and that is precisely the property you cannot have here.

Below: what a document generator is actually made of, what breaks in it on real data, and where an LLM does save hours. The examples come from the URITECH partner platform, a system for personal bankruptcy procedures where document generation was one of eight modules.

Do you need a neural network to generate documents?

In the Russian market, where we measure demand, the phrasings that mention a neural network or AI are the popular ones: they take 681 searches a month against 265 for “automatic document generation” and “document generation from a template” combined. Source: Yandex Wordstat, Russia, 08.09–07.10.2026.

The gap makes sense. A neural network promises to remove the work of describing the template, and that work is the substance of the task. When a lawyer says “we need document generation”, they do not mean composing text. They mean substitution: thirty fields from the case record into a document that is already written and already approved.

One criterion separates the cases: who is answerable for the wording.

• The wording is fixed by law, by a court or by a signed contract: template only. Variation in the text is a defect here, not a feature.
• The wording is written by a person from scratch each time (a letter to a client, a proposal, a job ad): an LLM fits, and off-the-shelf tools cover it without any development.

Between the two poles sits the case where custom development pays off best: the text is fixed by a template, but the data for it arrives unstructured, in scans, chat messages and statements. There the model sits on the input and assembles the fields while the template stays deterministic. That case gets its own section below.

What template-based generation is made of

The module that sounds trivial (“put the data into a Word file”) has five parts in practice, and four of them are not about substitution.

Template storage. The DOCX files live in object storage, S3 in the URITECH platform. A template is not part of the code and has its own lifecycle.

Editing templates without a release. This is the requirement that surfaces last and matters most. Wording in a template changes more often than the platform ships a new version. If fixing one sentence requires a deployment, the lawyers go back to Word and stop using the generator. In the URITECH cabinet every template change goes through the admin panel.

Substitution. The actual file assembly: python-docx in our case, with data from the client record. This is the cheapest part of the work.

Versioning. A document assembled six months ago has to be explainable by the version of the template that was in force back then. Without that you cannot reconstruct a disputed situation: the client holds one text, the system holds another, and nothing proves there was no substitution.

Binding to the stage of the procedure. In the URITECH cabinet the set of available documents is driven by a state machine of more than thirty stages, so each step exposes its own templates. That removes the most common error, a document assembled at the wrong time or the wrong document entirely.

Why generate Word rather than PDF

A PDF looks good in a demo: nobody can damage it. In daily use the opposite shows up. Lawyers edit documents after generation, always. No template covers every wording, and a lawyer is by profession the person who changes wordings.

An immutable PDF means the document has to be laid out again from scratch. So generate into an editable format and produce the PDF as a separate step on the final version, if it is needed at all.

That leads to a non-obvious requirement for the template itself: styles, numbering and tables have to survive into the file a human will then edit. A template a developer assembled out of plain text works formally and forces manual formatting on every document.

What breaks when the documents are legal ones

Four things that show up on real data rather than in a demo.

Grammatical cases and declensions. A Russian template is not string substitution: the same name has to appear in the nominative, the genitive and the dative, which means three fields out of one piece of data. Either the forms are stored, or the template fills up with constructions like “from the citizen: Ivanov I. I.”, which lawyers usually reject. Any language with case endings or gendered agreement has the same problem.

Numbers and dates in words. A money document spells the amount out in words, and that is a separate function with its own tests. An error there is not cosmetic.

Empty fields. When data is missing, the document must not keep a {{full_name}} placeholder or an empty gap mid-sentence. The behaviour on a missing field is a decision made in advance: refuse to assemble, insert a dash, or leave an explicit marker to be filled in by hand.

Who assembled the file, and when. In a legal context this is a requirement rather than a convenience: every file needs a trail of who pressed the button, against which template version, with which data.

Where a model genuinely helps

Three places where an LLM pays off in document work, and in none of them does it write the final text.

Reading incoming documents. The client sends a photo of a certificate, a bank statement, a scanned court order. Pulling fields out of that and putting them into the case record is a job a model does and regular expressions do not. We wrote up the traps of parsing corporate documents separately: RAG on real documents.

Checking the assembled document. The model compares the finished file against the case record and flags the mismatches: the amount in the text differs from the amount in the system, a date precedes the previous stage. The decision stays with a person, and that matters: here the model signals, it does not sign.

Drafts of non-binding text. A covering letter, an explanation for the client, an answer to a routine question. Any platform contains more text without legal consequences than it looks.

The boundary is simple: a model may read and check, but it may not word anything somebody signs.

When you should not build a document generator

The honest answer, and it shrinks our own pipeline: at a small volume of documents the development does not pay for itself.

The yardstick is volume and uniformity. With dozens of documents a month and three or four templates, a Word mail merge against an Excel table solves the problem in a day of work and zero development budget. A generator inside a system starts to make sense when at least one of these is true:

• the documents are assembled not by the author of the template but by dozens of people with uneven skills;
• the set of documents depends on the stage of a process whose order cannot be broken;
• a trail is required: who assembled which file, when, against which template version.

All three are about organisation rather than text. That is why document generation is almost never a standalone project: it turns out to be a module inside a platform that runs the process. Budget ranges for that kind of platform are in what a legaltech platform costs: the money goes into describing the procedure, not into assembling files.

The rule

In one line: the model goes on the input, the template on the output.

If a lawyer approved the wording, assemble the document from a DOCX template, version the templates and let people change them without a release. If the data arrives in scans and chat messages, put the model on reading the input and on checking the finished file. If there are few documents and one person makes them, do not buy development: a mail merge will do.