С развитием генеративного ИИ юристы получили то, о чём ещё недавно можно было только мечтать: помощника, который за секунды готовит проект претензии, структурирует исковое заявление, предлагает редакцию пункта договора, делает резюме судебного акта, составляет хронологию событий, объясняет риски сделки и помогает найти слабые места в позиции оппонента.
Но чем глубже ИИ входит в юридическую практику, тем заметнее становится новая, на первый взгляд «техническая», но на деле очень серьёзная проблема: ИИ научился писать текст, но юридическая работа живёт не просто в тексте, а в документе.
Юристу нужен не поток абзацев в браузере. Ему нужен файл Word. С нормальными стилями. С правильной нумерацией. С таблицами. С реквизитами. С колонтитулами. С оглавлением. С режимом исправлений. С комментариями. С сохранёнными сносками, ссылками, закладками, приложениями и форматированием.
Именно здесь начинается разрыв между «ИИ написал хороший текст» и «юрист получил готовый рабочий документ».
1. Юридический документ — это не просто текст
В обычном чате текст выглядит достаточно убедительно. Заголовки выделены, списки аккуратные, абзацы читаемые. Но чаще всего это markdown, HTML, простой текст или внутренняя разметка интерфейса. Как только юрист копирует такой результат в Microsoft Word, начинаются знакомые проблемы:
- появляются лишние звёздочки;
- заголовки превращаются в обычный текст;
- списки ломаются;
- нумерация становится ручной;
- отступы «плывут»;
- таблицы вставляются криво;
- сноски не являются настоящими сносками;
- кавычки, тире и пробелы требуют вычитки;
- структура документа не соответствует шаблону бюро;
- вместо режима исправлений появляется просто новый текст.
В результате юрист вроде бы сэкономил время на подготовке содержания, но потом тратит его на техническую доводку: чистит вставку, приводит документ к корпоративному стилю, восстанавливает нумерацию, переносит фрагменты, чинит таблицы и вручную делает то, что «умный» инструмент пока не сделал.
Для юридической профессии это особенно болезненно. В юридическом документе формат — это не украшение. Он влияет на восприятие позиции, удобство проверки, возможность ссылаться на пункты, качество согласования, пригодность документа для подачи в суд или отправки контрагенту.
Договор с неправильной нумерацией пунктов — это риск. Исковое заявление с криво вставленной таблицей расчёта — это риск. Документ без сохранённых правок и комментариев — это риск для командной работы. Потерянная сноска, сбитая ссылка на приложение или испорченный колонтитул могут стать не эстетической, а профессиональной проблемой.
2. Почему DOCX так трудно «просто поддержать»
Со стороны кажется: если ИИ может написать текст, почему он не может сразу сделать нормальный DOCX?
Проблема в том, что DOCX — это не простой текстовый файл. Это сложный контейнер. Технически DOCX относится к семейству Office Open XML: документ упакован как набор XML-частей и связанных ресурсов. Стандарт ECMA-376 описывает Office Open XML как систему словарей, представления документа и упаковки документа, а ISO/IEC 29500 описывает семейство XML-схем для word-processing, spreadsheets и presentations.
Если открыть DOCX как архив, внутри будут отдельные части для основного текста, стилей, нумерации, отношений, медиафайлов, комментариев, сносок, колонтитулов, настроек документа и других элементов. Microsoft в документации по WordprocessingML прямо показывает, что DOCX-пакет состоит из частей, которые можно увидеть, переименовав .docx в .zip.
Для человека Word скрывает эту сложность. Он показывает лист бумаги, ленту инструментов и привычные кнопки. Но для программы документ — это множество взаимосвязанных XML-структур. Ошибка в одной части может привести к тому, что Word откроет файл с предупреждением, потеряет элемент, «починит» документ сам или испортит форматирование.
Поэтому «сделать ИИ, который редактирует DOCX» — это не то же самое, что «сделать ИИ, который возвращает текст».
3. Главный конфликт: ИИ мыслит абзацами, Word мыслит структурой
Большие языковые модели хорошо работают с содержанием. Они умеют переформулировать, сокращать, расширять, находить противоречия, предлагать структуру. Но юридический DOCX живёт не только на уровне смысла.
В документе есть несколько уровней:
- логический уровень: разделы, пункты, приложения, определения, условия;
- текстовый уровень: конкретные формулировки;
- визуальный уровень: шрифты, отступы, интервалы, выравнивание;
- служебный уровень: стили, закладки, ссылки, поля, нумерация;
- редакционный уровень: комментарии, исправления, авторы правок, история согласования;
- технический уровень: OOXML-части, связи, совместимость, валидность пакета.
ИИ может уверенно сказать: «заменим этот пункт на более точный». Но система должна понять, как именно заменить его в DOCX:
- оставить ли стиль абзаца;
- сохранить ли номер пункта;
- попадёт ли изменение в track changes;
- нужно ли обновить оглавление;
- что делать с комментарием, привязанным к удаляемому фрагменту;
- не сломается ли ссылка на этот пункт;
- как отразить удаление и вставку в OOXML;
- как проверить, что Word откроет файл корректно.
Это и есть центральная проблема ИИ-редактирования документов: модель предлагает смысловую правку, но документ требует структурной, форматной и юридически безопасной операции.
4. Что уже появляется на рынке
Сейчас можно выделить несколько направлений.
4.1. ИИ внутри Word
Самый очевидный путь — не вытаскивать юриста из Word, а встроить ИИ прямо в Word.
Пример — Claude for Word. В официальной справке Anthropic он описан как Word-надстройка для профессионалов, работающих с документами, включая legal review, financial memo drafting и iterative editing. Заявлены возможности задавать вопросы по документу с цитируемыми ссылками на разделы, редактировать выбранный текст с сохранением окружающих стилей, нумерации и форматирования, использовать tracked changes и работать с комментариями.
Более широкий вариант — Claude for Microsoft 365. В Microsoft Marketplace он описан как надстройка для Excel, PowerPoint и Word: в Word изменения попадают как tracked changes, в PowerPoint используется slide master, а в Excel учитываются формулы и ячейки.
Это важный сигнал рынка: серьёзные игроки понимают, что недостаточно дать юристу текст в чате. Нужно работать внутри исходной среды, где живёт документ.
Но такой подход не закрывает всю проблему. Во-первых, это завязка на экосистему Microsoft 365. Во-вторых, возможности надстроек ограничены API, политиками безопасности, правами организации и тем, насколько глубоко инструмент умеет работать с конкретными элементами Word. В-третьих, для многих LegalTech-продуктов ИИ должен работать не только в открытом Word-документе, но и в файловом менеджере, CRM, судебном модуле, системе массового взыскания, базе шаблонов, облачном архиве или локальном хранилище дела.
4.2. ИИ с генерацией DOCX «на выходе»
Другой путь — пользователь общается с ИИ в браузере или приложении, а система генерирует DOCX-файл. Это удобно для первичного создания документа: иск, претензия, договор, заключение, письмо.
Но здесь есть ограничение: создать новый относительно простой DOCX легче, чем корректно отредактировать существующий сложный документ. Новый документ можно построить по шаблону. А вот существующий файл может содержать нестандартные стили, таблицы, комментарии, старые правки, вложенные списки, поля, колонтитулы, изображения, подписи, перекрёстные ссылки и элементы, которые библиотека не поддерживает полностью.
В юридической практике чаще нужно не просто «создать с нуля», а бережно изменить уже существующий документ, сохранив всё остальное.
4.3. Конвертация Markdown/HTML в DOCX
Многие простые решения идут через конвертацию: ИИ пишет markdown или HTML, затем это превращается в DOCX.
Это хороший путь для черновиков, писем, простых заключений и внутренних заметок. Но он плохо подходит для сложных юридических документов, где важны фирменные стили, стабильная нумерация, режим исправлений, комментарии, сноски, cross-references и точное соответствие шаблону.
Markdown знает заголовки, списки, таблицы и ссылки. Но он не знает полноценную модель Word-документа. Он не знает, что пункт 4.2 договора должен быть связан со стилем ContractClauseLevel2, что комментарий партнёра должен остаться привязанным к конкретному слову, что удаление должно быть оформлено как w:del, а вставка — как w:ins.
Поэтому конвертация — это полезный, но ограниченный компромисс.
4.4. Прямое редактирование OOXML
Самый мощный путь — работать прямо с OOXML. Microsoft поддерживает Open XML SDK, который упрощает манипулирование Open XML packages и schema elements. Но даже Microsoft в примере для Word Add-ins рекомендует сначала использовать Word API, а OOXML применять там, где нужного API не хватает.
Это показательная рекомендация: OOXML даёт огромную силу, но требует осторожности.
Microsoft-образец по get/edit/set OOXML демонстрирует работу с форматированным текстом, изображениями, WordArt, drawing shapes, content controls, таблицами, SmartArt и диаграммами; там же прямо сказано, что OOXML coercion позволяет взаимодействовать почти с любым типом содержимого, которое пользователь может вставить в Word.
Для ИИ это одновременно возможность и опасность. Возможность — потому что можно делать почти всё. Опасность — потому что модель не должна «на глаз» писать сложный XML. Ей нужны специализированные инструменты, валидаторы, операции высокого уровня и цикл проверки результата.
5. Новое направление: инструменты для документных агентов
В 2025–2026 годах заметно усилилось направление, где DOCX редактирует не сам чат напрямую, а агент через специальные инструменты.
Например, OfficeCLI заявляет себя как open-source, single binary, no Office installation, no dependencies инструмент, предназначенный для того, чтобы AI agents могли читать, редактировать и автоматизировать Word, Excel и PowerPoint. Важная заявленная идея — встроенный agent-friendly rendering engine, позволяющий рендерить .docx, .xlsx, .pptx в HTML или PNG и замыкать цикл «render → look → fix» без установленного Office.
Это очень важная мысль. Для ИИ недостаточно «сохранить файл». Агент должен увидеть или проверить, что получилось. Иначе он может формально создать валидный DOCX, который визуально непригоден: съехали таблицы, заголовок перешёл на другую страницу, нумерация стала странной, подпись оказалась оторвана от блока, расчёт распался.
Другой пример — Office-Word-MCP-Server, который реализует MCP-сервер для создания, чтения и изменения Word-документов, выступая мостом между AI assistants и Microsoft Word documents. В описании заявлены операции создания документов, извлечения текста, анализа структуры, просмотра свойств, копирования, объединения и конвертации в PDF.
Есть и более специализированные проекты. docx-redline-js описывает себя как host-independent OOXML reconciliation engine для .docx с track changes; он конвертирует AI-generated или programmatic edits в валидный OOXML с w:ins / w:del, который Word показывает как настоящие tracked changes.
Проект docx-editor предлагает плагин для Claude Code, чтобы ИИ не манипулировал OOXML вручную, а вызывал более простые методы вроде doc.replace() или doc.add_comment(), что авторы прямо позиционируют как более быстрый и менее ошибочный подход.
Существуют и библиотеки общего назначения, например unioffice для Go, которая заявляет чтение, запись и редактирование DOCX, XLSX и PPTX, включая форматирование, изображения, таблицы и конвертацию Word в PDF.
Всё это показывает: рынок движется от «ИИ пишет текст» к «ИИ управляет документом через инструменты».
6. Почему юридическим продуктам нельзя ограничиться обычным чатом
Для обычного пользователя достаточно, чтобы ИИ написал красивый текст. Для юриста этого мало.
Юридический ИИ должен уметь работать как минимум с тремя слоями:
- Содержание. Что написать, какие доводы привести, какие нормы указать, какие риски раскрыть.
- Структура. Где это находится в документе, какой это раздел, пункт, подпункт, приложение, таблица, сноска.
- Редакционная форма. Как это внести: заменить текст, предложить правку, оставить комментарий, сделать tracked changes, сохранить старую редакцию, показать diff.
Если ИИ работает только с содержанием, юрист получает хороший черновик, но не рабочий документ. Если ИИ работает со структурой, но не умеет сохранять форматирование, он ломает документ. Если ИИ умеет форматировать, но не показывает изменения как юридически проверяемые правки, он становится опасным для согласования.
Поэтому для юридической сферы особенно важна не просто генерация DOCX, а бережное редактирование существующего DOCX.
7. Типовые ошибки ИИ при работе с DOCX
Можно выделить несколько классов ошибок.
7.1. Потеря форматирования
ИИ заменил текст, но абзац потерял стиль. В договоре исчезло выделение определения. В иске заголовок стал обычным абзацем. В заключении таблица превратилась в простой текст.
7.2. Поломка нумерации
Юридические документы часто завязаны на многоуровневую нумерацию. Если ИИ вставляет пункт вручную, вместо настоящей нумерации Word, дальнейшие ссылки становятся ненадёжными.
7.3. Разрушение режима исправлений
Для юридического согласования важно, чтобы изменения были видны как tracked changes. Просто заменить старый текст новым — недостаточно. Нужно, чтобы юрист, партнёр, клиент или контрагент мог принять или отклонить каждое изменение.
7.4. Потеря комментариев
Комментарии часто содержат смысл согласования: «проверить судебную практику», «согласовать с клиентом», «оставить только для версии ответчика». Если ИИ удаляет фрагмент вместе с комментарием или переносит текст без комментария, теряется часть работы команды.
7.5. Повреждение таблиц
В юридических документах таблицы часто используются для расчётов, перечня объектов недвижимости, задолженности, судебных расходов, платежей, периодов просрочки. Неправильное объединение ячеек, потеря ширины колонок или превращение таблицы в текст может сделать документ непригодным.
7.6. Скрытые технические повреждения
Файл может выглядеть нормально, но внутри оказаться повреждённым: битые relationships, лишние namespace, некорректные ссылки на стили, несогласованные элементы нумерации. Word иногда «лечит» такие файлы сам, но для юридического документооборота это плохая основа.
8. Какой архитектурный подход кажется правильным
Перспективный подход — не заставлять языковую модель напрямую редактировать DOCX как XML, а построить многоуровневую систему.
Уровень 1. Модель понимает задачу
Юрист пишет: «Сделай пункт о подсудности более выгодным для исполнителя и внеси изменения в режиме правок».
ИИ должен понять юридическую задачу, найти релевантный пункт, предложить новую редакцию и объяснить смысл изменения.
Уровень 2. Документный инструмент выполняет операцию
Не модель руками пишет OOXML, а специализированный слой выполняет команду:
- найти диапазон;
- заменить текст;
- сохранить стиль;
- оформить удаление и вставку как tracked changes;
- сохранить комментарии;
- обновить структуру.
Уровень 3. Валидатор проверяет файл
После операции система проверяет, что DOCX технически валиден, что нужные части пакета не повреждены, что документ открывается, что стили и нумерация не разрушены.
Уровень 4. Рендеринг показывает результат
Следующий обязательный шаг — визуальная проверка. Именно поэтому подход OfficeCLI с циклом «render → look → fix» концептуально важен: агент должен иметь возможность не только создать файл, но и увидеть результат в HTML/PNG или ином представлении.
Уровень 5. Юрист принимает изменения
Финальное решение остаётся за человеком. Даже Anthropic в справке по Claude for Word прямо указывает, что beta-функция не рекомендуется для финальных клиентских материалов, судебных подач или audit-critical documents без человеческой проверки; отдельно подчёркивается необходимость проверки tracked changes и сохранения human oversight.
Для юридической практики это не формальность. ИИ может помочь, но ответственность за документ несёт юрист.
9. Особый риск: prompt injection внутри документов
Когда ИИ начинает читать и редактировать документы, возникает не только технический, но и безопасностный риск.
Anthropic в документации Claude for Word прямо предупреждает о prompt injection attacks: вредоносные инструкции могут быть спрятаны в содержимом документа, комментариях, tracked changes, headers или footers, чтобы модель восприняла их как легитимные команды пользователя.
Для юридической практики это особенно важно. Юрист постоянно получает документы от внешних лиц: контрагентов, процессуальных оппонентов, клиентов, судов, консультантов. Если ИИ-агент имеет доступ к документу и может его редактировать, отправлять данные или вызывать внешние инструменты, скрытая инструкция внутри файла становится потенциальной атакой.
Следовательно, юридический DOCX-агент должен различать:
- текст документа как объект анализа;
- команды пользователя;
- комментарии третьих лиц;
- служебные инструкции системы;
- потенциально вредоносные скрытые указания.
Это ещё один аргумент против наивного подхода «просто дай ИИ доступ к Word».
10. Что нужно именно LegalTech-продукту
Для юридических приложений правильная цель — не «сделать мини-Word». Это слишком сложно и почти всегда приведёт к плохой копии Word.
Более разумная цель — создать документный слой для ИИ, который умеет выполнять юридически значимые операции с DOCX:
- анализировать документ без разрушения структуры;
- извлекать текст вместе с картой разделов, пунктов, таблиц, комментариев и сносок;
- предлагать правки с привязкой к конкретным местам;
- вносить изменения через tracked changes;
- добавлять комментарии;
- сохранять стили и нумерацию;
- работать с шаблонами бюро;
- проверять результат;
- делать визуальный diff;
- откатывать изменения;
- не трогать неподдерживаемые элементы;
- сохранять сложные части документа при частичном редактировании.
Особенно важен принцип: если система не умеет редактировать элемент, она должна его сохранить, а не разрушить.
Для юридических документов это критично. Пусть ИИ не умеет редактировать сложный SmartArt, встроенный объект или нестандартное поле. Но он не должен уничтожить их при сохранении файла.
11. Практическая классификация решений
Можно предложить такую классификацию зрелости ИИ-работы с DOCX.
Уровень 0. Текст в чате
ИИ выдаёт текст. Юрист копирует его в Word и форматирует вручную. Это самый распространённый сценарий сейчас.
Уровень 1. Генерация простого DOCX
ИИ создаёт новый файл с базовыми заголовками, абзацами и таблицами. Подходит для черновиков, но не решает проблему редактирования сложных документов.
Уровень 2. DOCX по шаблону
Система заполняет заранее подготовленный шаблон: договор, иск, доверенность, претензия. Это уже полезно для юридической автоматизации, но требует хорошей шаблонной модели.
Уровень 3. Точечное редактирование существующего DOCX
ИИ умеет найти фрагмент и заменить его, сохранив стили, нумерацию и структуру. Это минимальный уровень для серьёзного юридического применения.
Уровень 4. Редактирование с tracked changes и комментариями
Все изменения вносятся как настоящие правки Word, а замечания — как настоящие комментарии. Именно этот уровень нужен для договорной работы, согласования процессуальных документов и внутреннего контроля качества.
Уровень 5. Агентный документный цикл
ИИ анализирует документ, планирует изменения, применяет их инструментами, валидирует OOXML, рендерит результат, сравнивает «до/после» и предлагает юристу принять изменения. Это уже не «чат», а полноценный документный агент.
12. Вывод: следующий этап LegalTech — не генерация текста, а управление документом
ИИ уже умеет помогать юристу с содержанием. Но юридическая работа не заканчивается содержанием. Она заканчивается документом, который можно отправить клиенту, контрагенту, суду, нотариусу, бухгалтерии или коллеге.
Поэтому главный вызов ближайших лет — не просто научить ИИ писать юридические тексты. Главный вызов — научить ИИ бережно работать с юридическими документами как с полноценными структурными объектами.
DOCX сложен. OOXML сложен. Word-форматирование сложно. Режим исправлений, комментарии, таблицы, стили, нумерация и колонтитулы — это не второстепенные детали, а часть профессионального юридического результата.
Сейчас рынок уже движется в эту сторону: появляются Word-надстройки вроде Claude for Word, инструменты для Microsoft 365, CLI и MCP-серверы для офисных документов, библиотеки для redlines и документные плагины для агентов. Но проблема ещё далека от окончательного решения.
Настоящий LegalTech-прорыв произойдёт тогда, когда ИИ будет не просто писать:
«Вот улучшенная редакция договора».
А сможет сказать:
«Я нашёл спорный пункт, предложил новую редакцию, внёс её в режиме исправлений, сохранил стиль и нумерацию, оставил комментарий с объяснением риска, проверил DOCX на валидность, отрендерил результат и показал вам изменения для принятия».
Именно такой ИИ нужен юристам: не только умный собеседник, а аккуратный, надёжный и проверяемый помощник по работе с документами.