Как я автоматизировал юридическую рутину

Хабр, привет! Меня зовут Ману, и я бывший фронтенд-разработчик, который уже семь лет работает корпоративным юристом. Да, звучит странно. Но именно эта комбинация помогает в моей повседневной работе, с которой сталкивается каждый практикующий юрист: бесконечное заполнение одних и тех же форм, где отличаются только наименования юрлиц и их реквизиты.

В этой статье я расскажу, как из Excel-таблиц пришел к Python-скрипту, который генерирует десятки документов за пару секунд. Эта история о том, как технический бэкграунд помогает использовать ИИ не просто для генерации текстов, а создавать инструменты, которые реально экономят часы рутинной работы. Прежде всего для минимизации фактора человеческой ошибки и автоматизации рутины.

Как Minecraft привёл меня в юриспруденцию

Начну с предыстории. Под конец 9-го класса я увлекся Minecraft, но не самой игрой, а возможностью создать свой проект под нее. Это были 2012-2015 годы, когда индустрия игровых серверов переживала настоящий бум. Сидя на форумах и изучая, как собрать лаунчер и сайт для своего проекта, я решил начать с дизайна. Так меня и втянуло в веб-разработку.

Около шести лет я проработал в небольшой студии верстальщиком и фронтендером, хотя второе можно было назвать с большой натяжкой. Потом началась взрослая жизнь, и надо было думать о чем-то более серьезном. Меня пригласили в юридическую фирму стажером просто потому, что я разбирался в компьютерах и знал, что такое Word. Да, тогда с наймом было чуточку проще :)

С 2019 года началась моя полноценная юридическая практика. Я полностью ушел из разработки и переключился на юриспруденцию. Работаю в основном с корпоративным и миграционным правом. И вот тут началось самое интересное.

Я быстро понял, что работа юриста делится на два типа. Первая – это более творческий подход, где включается и работает мозг на полную. Сюда относится все, что связано с аналитикой: составление стратегии защиты в суде, написание юридических заключений с анализом нестандартных ситуаций, разработка сложных договорных конструкций. А вторая – формализированная бюрократическая рутина, когда ты просто заполняешь типовые договора, заявления, ходатайства для государственных органов. И вот вторая часть съедала львиную долю времени.

Эксель как первая попытка не сойти с ума

Еще в начале карьеры я устал копировать одни и те же данные из документа в документ. Наименование юридического лица тут, его адрес там, ОГРН в третьем месте – и так по кругу. Тогда мне пришла идея сверстать типовые бланки в Excel и объединить их в один файл по разным вкладкам.

Схема была простая:

• На первой вкладке (мастер-вкладка) я заполнял всю информацию о клиенте;

• Со второй и по предпоследнюю (верстка) шли готовые формы документов;

• А последняя вкладка (техническая) работала как мозг всей системы.

Техническая вкладка забирала данные с первой, унифицировала их, форматировала и так далее и выдавала конечный результат. Также тут были прописаны условия вроде «если поле пустое, выведи прочерк».

После заполнения я просто переходил на нужную вкладку и печатал документ напрямую из Excel. Конечно, были сложности с версткой, потому что печать из Excel – не тоже самое, что и из Word. Приходилось возиться с отступами и размерами ячеек, чтобы все красиво укладывалось на стандартный лист А4.

Однако, этот подход можно было использовать до поры до времени. Но проблема в том, что формы живут своей жизнью. Ведомства обновляют приказы, вводят новые бланки, меняют старые. И каждый раз нужно было переверстывать Excel-файл. Учитывая сложность верстки, руки доходили до этого не сразу – проще было вручную забить данные в новый документ. Со временем форм становилось все больше, и система начала трещать по швам. Нужно было придумать что-то кардинально новое.

Мечты о красивом решении и почему я их забросил

Возвращаться обратно к Excel не хотелось. Требовалось унифицированное решение, которое можно было бы масштабировать и передать коллегам без особых проблем. Плюс использовать не только в моей практике, но и других областях. В голове сразу возникла идея: берем регламентированные формы в PDF, сохраняем их и накладываем текст поверх через SVG. Реализовать это можно было бы через обычное SPA-приложение на React.

Но когда я начал прикидывать объем работы, энтузиазм быстро остыл. Нужно было:

1. Упорно и долго писать код на JavaScript;

2. Разбираться в тонкостях React, и других библиотеках для работы с SVG или canvas;

3. Сделать превью документа;

4. Придумать интерфейс для разметки форм;

5. И много еще чего, включая дебаг и небыстрое начало к самой сути – заполнения документов.

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

Эта идея очень долго висела в моей голове мертвым грузом. Я на протяжении нескольких лет раздумывал как подступиться к этой проблеме и с чего начать. Были разные мысли о том, как группировать данные по категориям (например, база юридических лиц, база физических лиц) и при создании нового проекта просто выбирать стороны, параметры и генерировать нужные документы. Но до реализации так и не доходило.

Как ContentControl стал спасением

Время шло, формы менялись и добавлялись новые. И тут в наше бюро пришел клиент – запрос объемный и с большой типовой документацией. Откладывать больше уже было нельзя.

Все новое – хорошо забытое старое. Думал я, и решил пойти проверенным путем: скормить вордовский документ ИИ и посмотреть, что получится. Результат меня не удивил – он выдал непонятное что вместо верстки, и его нельзя в этом винить. Он не видит то, что видит человек. В его мире алгоритмов – все сделано в соответствии с правилами.

Тогда в наших юридических документах, где требовался аналитический подход, я вовсю использовал Элементы управления контентом (ContentControl). Но его применение было по минимуму: выбрать дату из календарика, вместо ручного прописывания; выбор формы юридического лица (АО или ООО); список с арбитражными судами и их адресами; выбор поверенных лиц и так далее. Простые вещи, упрощающие работу, но не более того.

И тут меня осенило: а что, если использовать ContentControl на полную катушку? Идея была такая:

• в папке проекта у нас лежит мастер-файл (вордовского формата), внутри него уже приличная и красивая таблица, где слева указаны название полей (наименование, ОГРН, ИНН и т.д.), а справа само поле ContentControl для ввода данных;

• рядом с мастер-файлом находятся подпапки с формами для разных инстанций;

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

project/ │ ├── master.docx # Мастер-файл с данными ├── script.py # Скрипт обработки │ ├── forms_tax/ │ ├── *.docx # Формы с ContentControl │ ├── *_map.json # Конфиги (если нужны) │ └── PDF/ # ← создается скриптом │ ├── forms_migration/ │ ├── *.docx │ └── PDF/ │ └── forms_court/ ├── *.docx └── PDF/

А дальше в дело вступает скрипт на Python, который и является мозгом всей этой затеи. Запускаем через консоль скрипт, и он проходится по всем подпапкам, смотрит вордовские файлы и вставляет данные из мастер-файла в соответствующие поля с одинаковыми идентификаторами. Если в процессе выполнения не обнаружены ошибки, то в каждой подпапке создается папка PDF, где в них будут располагаться сгенерированные PDF-документы.

Сначала я хотел положить все формы в один вордовский файл и обновлять поля через VBA, но быстро от этой затеи отказался из-за разных типов полей в формах (об этом – далее).

Реализовать задуманное через Python, как я видел, можно посредством вызова функции Word или LibreOffice. Однако, проблемы возникли и тут. При запуске, Word сильно капризничал и каждый раз хотел права на просмотр папок и редактирование файлов, тогда как LibreOffice – нет. Пытался также сделать вызов Word в «тихом» режиме без запуска GUI, но мой скрипт сломался. И на данный момент я решил полностью остановиться на LibreOffice. Буду благодарен, если знающие специалисты подскажут как в будущих итерациях отказаться от этой зависимости и использовать только open-source библиотеки для Python.

Технические грабли, по которым я прошелся

При первых тестах и пробах уже вырисовывался контур этой архитектуры. Она была понятной и простой, не требовала значительного времени и усердной верстки. Буквально за 4-6 часов я размечал и тестировал 12 шаблонов, тогда как на верстку одного документа у меня уходило по несколько суток.

Итак, технически, формат docx – это обычный zip-архив с XML внутри. Если вы когда-нибудь смотрели на древо веб-страницы в DevTools, то структура вордовского документа покажется знакомой. Те же вложенные теги, те же атрибуты, только namespace другой. Библиотека python-docx предназначенная для создания, чтения, редактирования вордовских файлов и позволяет работать с ними напрямую, не открывая Word вообще.

Скрипт при запуске читает мастер-файл, собирает все ContentControl-поля и их значения в словарь (по аналогии с объектами в JavaScript), где ключ – это идентификатор поля, а значение – то, что вы туда вписали. Дальше он обходит все подпапки, находит размеченные вордовские файлы и в каждом из них заменяет поля с совпадающими идентификаторами на нужный текст. После этого запускается LibreOffice (без GUI, просто прыгающая иконка) и генерируются PDF. Пока не дошел до способа, чтобы приложение вообще не запускалось, а работало только через консольные команды.

Не сказать, что все обошлось без ошибок и проблем. Word хранит текст внутри XML весьма своеобразно. Простая фраза [company_name] может быть разбита на несколько отдельных XML-элементов, каждый со своим форматированием. В структуре XML-файла вордовского документа текст внутри абзаца (<w:p>) разбивается на так называемые «прогоны» (runs) – элементы <w:r>.

Это примерно, как если бы текст в теге <p> был разбит на десяток <span> без видимой причины. Поэтому простая замена строки не работала. Чтобы корректно обновить данные, было решено собирать текст всего абзаца воедино, выполнять замену и перезаписывать содержимое, предварительно очищая структуру от лишних «прогонов».

Когда разобрался с обычным текстом, пришел черед нестандартных ситуаций. Например, некоторые государственные формы содержат таблицы, где каждая буква пишется в отдельную клетку. Поле «наименование организации» это 34 клетки подряд, каждая отдельная ячейка в XML. Размечать такое через ContentControl – это сизифов труд. Нужно было искать другое решение.

Для таких форм я ввёл дополнительный файл конфигурации имя_файла_map.json. Простой JSON, где для каждого поля указывается в какие таблицы и ячейки писать символы. Скрипт читает значение из мастер-файла и последовательно вписывает каждый символ в соответствующую ячейку. Чтобы не высчитывать индексы ячеек вручную, была разработана утилита, которая генерирует размеченную версию документа. Суть заключалась в том, что в каждой пустой ячейке красным мелким шрифтом пишется её индекс. Открываешь размеченный документ в Word, смотришь нужные координаты и прописываешь их в map-файл.

В итоге получилось три типа полей, с которым скпт умеет работать:

1. ContentControl для стандартных форм и простой разметки;

2. Побуквенное заполнение для нестандартных форм;

3. Гибридный вариант, сочетающий оба подхода.

Отдельно пришлось повозиться с датами. В государственных формах дата рождения – восемь клеток (две под число, две под месяц, четыре под год). Для некоторых ячеек под год выделено не четыре клетки, а две. Поэтому в map-файле для дат есть отдельная секция, где явно указывается какие ячейки под что. Скрипт берёт дату из мастер-файла в формате ДД.ММ.ГГГГ, разбивает её и раскладывает по нужным индексам.

Была и ещё одна нетривиальная проблема. Это когда одно ContentControl-поле находится внутри другого, такое случается если копировать и вставлять поля в Word. Визуально всё выглядит нормально, но при открытии сгенерированного файла Word выдавал предупреждение о повреждённом содержимом. XML был синтаксически валидным, но семантически нет, потому что вложенные поля – это неподдерживаемая конструкция. Пришлось добавить предварительную обработку, чтобы перед заполнением скрипт разворачивал все вложенные поля, заменяя их на простой текст.

Про форматирование стоит сказать отдельно. При заполнении некоторых форм я придерживаюсь единообразия: заглавные буквы, жирный шрифт и конкретный размер. Если в мастер-файле мы пишем как обычно (первая буква заглавная, а остальные строчными), то он так и переносится в другие формы. Захардкодить это в скрипте было бы неправильно, потому что в разных документах требования разные. Поэтому в map-файле появилась секция _format где для каждого поля можно указать свои параметры (upper переводит текст в верхний регистр, bold делает жирным, size задаёт размер шрифта, align выравнивание). Если форматирование явно не указано в map-файле, то применяются дефолтные значения. Работает одинаково и для побуквенных ячеек и для ContentControl-полей.

{ "_comment": "Маппинг для Ходатайства РР ВКС", "_format": { "inn": { "size": 8 }, "okato": { "size": 8 }, "passissue": { "upper": true, "bold": true, "size": 9, "align": "center" }, "polis_issued": { "upper": true, "size": 9 }," } }, "_dates": { "ogrn_date": { "day": [[13, 15], [13, 16]], "month": [[13, 17], [13, 18]], "year": [[0, 0], [0, 0], [13, 19], [13, 20]] } }, "inn": [[11, 1]], "ogrn": [[13, 1]], "okato": [[11, 12, true]], "company_phone": [[20, 1]] }

Ещё одна проблема, которую я не сразу предвидел: количество ячеек в форме не всегда совпадает с длиной текста. Поле ОКАТО это одиннадцать символов, а ячеек под него десять – скорее всего при разработке формы просто не посчитали. Первое время это решалось вручную и было неудобно. В итоге в формат записи map-файла добавился третий параметр (булев). Если стоит true и символов больше, чем ячеек, скрипт идёт с конца строки и добавляет последний символ в крайнюю ячейку. Выглядит это так: [11, 1, true] – таблица 11, начиная с ячейки 1, с переносом остатка в последнюю клетку. Скрипт берёт строку, нарезает её кусками нужной длины и раскладывает по ячейкам.

Причём это не мое решение проблемы – это требование инспектора уполномоченного органа. Некоторые коллеги пошли другим путём и просто добавили лишнюю ячейку в таблицу, чтобы влезли все символы. Казалось бы логично, но их документы признали недействительными – форма не совпадала с утверждённым регламентом. Бюрократия есть бюрократия.

Реализацию скрипта я полностью отдал искусственному интеллекту (решил проверить на деле Claude Code). В процессе дебага и разработки нужно было лишь корректировать его и направлять в нужно русло. Конечно, задумка не доведена до идеала, но с ним моя команда уже сэкономила уйму времени и снизила вероятность человеческой ошибки при заполнении документов.

Что получилось и куда дальше

Хочется более унифицированного и масштабируемого решения, а не дублирования шаблонов и мастер-файла в каждый новый проект. В будущих планах отказаться от мастер-файла. Например, перейти на работу с библиотекой python-docx-template, которая умеет подставлять данные прямо в шаблоны на основе переменных. Или, что ещё лучше, сделать простое SPA-приложение, где можно создавать проекты, вбивать реквизиты сторон, выбирать нужные документы из каталога и одним кликом генерировать их. По сути, довести текущую идею до полноценного конструктора документов.

Но когда я начал об этом думать, быстро понял, что автоматизация заполнения форм – это только вершина айсберга. Да, мы научились делать массово нужные нам документы, но что происходит с ними дальше? Они либо уходят в архив на локальном диске, либо распечатываются и подшиваются в папки. А если через месяц нужно найти конкретный договор или проверить, не истёк ли срок действия доверенности? Без нормальной системы учёта начинается тот самый ад с Excel-табличками, который мы все так любим.

Поэтому следующим логичным шагом вижу не просто улучшение генератора, а создание полноценной системы учёта договоров и документооборота. Представьте: цифровой реестр договоров с удобными тегами и категориями, чтобы за пару кликов находить всё, что связано с конкретным клиентом или судебным процессом. Хранилище скан-копий с шифрованием, контроль версий документов (как в Git), автоматические напоминания о дедлайнах, шаблонизация и даже OCR с NLP-анализом текста, адаптированным под российское законодательство.

Пока что мои коллеги ведут документооборот по старинке: нумерация в Excel, а сканы просто лежат в папках с названиями вроде «договоры_2025». Если нужно что-то найти – начинается перебор. Хотелось бы, чтобы отечественная юриспруденция не отставала от технологий и предлагала удобные инструменты как для небольших команд, так и для крупных фирм. Короче, планов много. Начну, наверное, с прототипа на python-docx-template, а дальше видно будет.

Вывод

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

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

И вот тут я упираюсь в главную проблему. На данный момент для небольших юридических команд и юристов-предпринимателей практически нет готовых инструментов, которые закрывали бы повседневные потребности. Либо это монструозный 1С:Документооборот, рассчитанный на большой отдел, либо самописные Excel-таблицы, которые рано или поздно начинают сыпаться. Золотой середины, к сожалению, почти нет.

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