Автоматическая генерация документов: когда нужна нейросеть, а когда шаблон

Короткий ответ: документ, у которого есть юридическая сила, собирают шаблоном, а нейросеть ставят на вход генератора, а не на выход. Формулировка в договоре, заявлении или уведомлении должна быть ровно той, которую согласовал юрист. Генеративная модель по своей природе даёт каждый раз немного другой текст, и это ровно то свойство, которое здесь недопустимо.

Дальше разберём, из чего состоит генератор документов, что в нём ломается на практике и в каком месте нейросеть действительно экономит часы. Опираемся на партнёрский кабинет URITECH: платформу для процедур банкротства физлиц, где генерация документов была одним из восьми модулей.

Нужна ли нейросеть для генерации документов

Судя по поисковым запросам, большинство ищет именно её. Формулировки со словами «нейросеть» и «ии» дают 681 обращение в месяц на всю Россию: «нейросеть для генерации документов» 311, «ии для генерации документов» 290, «генерация юридических документов ии» 52 и ещё две близкие. Формулировки без них набирают 265: «автоматическая генерация документов» 226 и «генерация документов по шаблону» 39. Источник — Яндекс Вордстат, Россия, окно 08.09–07.10.2026.

Разрыв объясним: нейросеть обещает избавить от работы по описанию шаблона. Проблема в том, что эта работа и есть содержание задачи. Когда юрист говорит «нам нужна генерация документов», он имеет в виду не сочинение текста, а подстановку: тридцать полей из карточки дела в документ, который уже написан и уже согласован.

Разделить стоит по одному признаку: кто отвечает за формулировку.

• Формулировку задаёт закон, суд или подписанный договор — только шаблон. Вариативность текста здесь дефект, а не свойство.
• Формулировку пишет человек и каждый раз заново (письмо клиенту, коммерческое предложение, описание вакансии) — LLM уместна, и готовых инструментов для этого хватает без разработки.

Между этими полюсами есть третий случай, где разработка окупается лучше всего: текст задан шаблоном, а вот данные для него лежат в неструктурированном виде — в сканах, переписке, выписках. Там нейросеть стоит на входе и собирает поля, а шаблон остаётся детерминированным. Про этот случай ниже отдельный раздел.

Генерация документов по шаблону: из чего она состоит

Модуль, который кажется простым («подставить данные в Word»), на практике состоит из пяти частей, и четыре из них не про подстановку.

Хранилище шаблонов. Файлы DOCX лежат в объектном хранилище, в платформе URITECH это S3. Шаблон — не часть кода, у него свой жизненный цикл.

Редактирование шаблонов без релиза. Это главное требование, которое выясняется позже всего. Формулировка в шаблоне меняется чаще, чем выходит новая версия платформы. Если для правки одной фразы нужен деплой, юристы вернутся в Word и генератором пользоваться перестанут. В кабинете URITECH все изменения шаблонов идут через админку.

Подстановка. Собственно сборка файла: в нашем случае python-docx, данные берутся из карточки клиента. Это самая дешёвая часть работы.

Версионирование. Документ, собранный полгода назад, должен объясняться той версией шаблона, которая действовала тогда. Без этого разобрать спорную ситуацию невозможно: на руках у клиента один текст, в системе другой, и доказать, что подмены не было, нечем.

Привязка к этапу процедуры. В кабинете URITECH состав документов определяется статус-машиной из тридцати с лишним этапов: на каждом шаге доступны свои шаблоны. Это снимает самую частую ошибку — документ, собранный не вовремя или не тот.

Почему генерировать надо в Word, а не в PDF

На демонстрации красиво выглядит PDF: его нельзя испортить. В работе выясняется обратное: юристы правят документы после генерации, всегда. Шаблон не покрывает всех формулировок, а юрист по профессии тот человек, который формулировки меняет.

Неизменяемый PDF означает, что документ придётся переверстать с нуля. Поэтому генерировать надо в редактируемый формат, а PDF делать отдельным действием на финальной версии, если он вообще нужен.

Отсюда же следует неочевидное требование к шаблону: в нём должны сохраняться стили, нумерация и таблицы в том виде, в котором их потом будет править человек. Шаблон, собранный программистом из голого текста, формально работает, а по факту заставляет форматировать каждый документ руками.

Что ломается в генерации юридических документов

Четыре вещи, которые выясняются на боевых данных, а не на демо.

Падежи и склонения. Русский шаблон не сводится к подстановке строк: «от Иванова Ивана Ивановича», «Иванову Ивану Ивановичу», «Иванов Иван Иванович» — это три разных поля из одних данных. Либо поля хранятся в нужных формах, либо в шаблоне появляются конструкции вида «от гражданина: Иванов И. И.», которые юриста обычно не устраивают.

Числа и даты прописью. «Пятьдесят тысяч рублей 00 копеек» в документе о деньгах пишется прописью, и это отдельная функция с собственными тестами. Ошибка здесь не косметическая.

Пустые поля. Если данных нет, в документе не должно остаться {{ФИО}} или пустой строки посреди предложения. Поведение на отсутствующем поле описывается заранее: не собирать документ вовсе, подставить прочерк или оставить явный маркер для заполнения от руки.

Кто и когда собрал документ. В юридическом контуре это требование, а не удобство: к каждому файлу нужен след — кто нажал кнопку, по какой версии шаблона, какие данные подставились.

Где нейросеть действительно помогает

Три места, где LLM в документообороте окупается, и во всех трёх она не пишет итоговый текст.

Разбор входящих документов. Клиент присылает фотографию справки, выписку из банка, скан постановления. Извлечь оттуда поля и положить в карточку — задача, для которой модель подходит, а регулярные выражения нет. Про подводные камни разбора корпоративных документов у нас есть отдельный разбор: RAG на реальных документах.

Проверка собранного документа. Модель сравнивает готовый файл с карточкой дела и отмечает расхождения: сумма в тексте не совпадает с суммой в системе, дата раньше предыдущего этапа. Решение остаётся за человеком, и это важно: модель здесь сигнализирует, а не подписывает.

Черновики необязательных текстов. Письмо-сопровождение, пояснение клиенту, ответ на типовой вопрос. Текста без юридических последствий в любой платформе больше, чем кажется.

Граница простая: модель может читать и проверять, но не формулировать то, под чем кто-то ставит подпись.

Когда генератор документов вам не нужен

Честный ответ, который сокращает нашу же воронку: при небольшом потоке документов разработка не окупается.

Ориентир — объём и однотипность. Если документов десятки в месяц и шаблонов три-четыре, слияние в Word с таблицей Excel закрывает задачу за день работы и ноль рублей на разработку. Генератор как часть системы начинает иметь смысл, когда появляется хотя бы одно из трёх:

• документы собирает не автор шаблона, а десятки людей с разной квалификацией;
• состав документов зависит от этапа процесса, и порядок нарушать нельзя;
• нужен след: кто, когда и по какой версии шаблона собрал файл.

Все три пункта — про организацию, а не про текст. Поэтому генерация документов почти никогда не бывает самостоятельным проектом: она оказывается модулем внутри платформы, которая ведёт процесс. Бюджетные вилки по такой платформе разобраны в статье сколько стоит legaltech-платформа: основные деньги уходят на описание процедуры, а не на сборку файлов.

Итог

Правило выбора в одну строку: нейросеть ставим на вход, шаблон на выход.

Если формулировку согласовал юрист, собирайте документ шаблоном в DOCX, версионируйте шаблоны и дайте менять их без релиза. Если данные для документа приходят в сканах и переписке, ставьте модель на разбор входящих и на сверку готового файла. Если документов мало и делает их один человек, не покупайте разработку: слияние в Word закроет задачу.