AI-извлечение данных из договоров: система для юристов

Извлечение данных из договоров: где ломается ручная проверка

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

Отсюда типовые ошибки в реквизитах договора: перепутанный номер, дата в формате контрагента, ИНН или банковские реквизиты из предыдущей версии. Нестандартные условия — штраф за просрочку уведомления, автопролонгация, право на односторонний отказ — не попадают в сводку, потому что выглядят как обычный абзац.

Цена — не только срок проверки пакета договоров, растянутый на недели. Сводку по массиву собрать нечем: данные лежат в тексте, а не в таблице, и каждое уточнение к договору требует повторного чтения. Хуже, что проверка не воспроизводится — следующий юрист пройдёт тот же путь заново и получит другую выборку. Итог — пропущенный платёж или сгоревшее окно на возражение.

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

Что даёт система: сроки, полнота, устранённые ошибки

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

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

Итог: поток договоров разбирается за смену, полнота подтверждается выборкой, спорное видит человек. Сканы и нестандартные редакции обрабатываем на входе, персональные данные в договорах — в рамках 152-ФЗ.

Варианты построения: облачный сервис, закрытый контур, гибрид

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

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

Как схема меняется со временем

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

Как проходит внедрение: от аудита массива до передачи

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

1. Аудит договорного массива. Выгружаем представительную выборку и классифицируем по видам: поставка, подряд, услуги, лицензия, аренда. Фиксируем, какие поля нужны юристам в работе. На выходе — карта типов и частот, она задаёт приоритеты.
2. Схема сущностей. Описываем поля, типы, обязательность, связи между договором и приложениями. Заводим справочники контрагентов и видов договоров, чтобы значения не расползались дублями.
3. Настройка правил разбора. Шаблонные блоки закрываем правилами, нестандартные формулировки — моделью. Каждое значение получает ссылку на фрагмент текста: юрист видит основание, а не готовый ответ.
4. Проверка на контрольной выборке договоров. Прогоняем документы, которых не было в настройке, и считаем точность отдельно по каждому полю. Поля ниже согласованного порога возвращаются на доработку, а не растворяются в общей метрике.
5. Дообучение модели на правках. Правки юристов становятся разметкой: спорные формулировки заказчика попадают в обучение, и точность растёт на его шаблонах, а не на абстрактном наборе.
6. Передача регламентов. Отдаём инструкции для юристов, описание полей и порогов, порядок обновления правил и разбора ошибок. Сопровождаем первые прогоны на живом потоке.

Дальше цикл повторяется только на новых типах договоров — привычные идут без ручной правки.

Что юрист получает на руки: реестр договоров и правила разбора

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

• Реестр договоров — таблица или база со связанными сущностями: контрагент, предмет, срок, порядок оплаты, пролонгация, ответственный юрист. У каждого значения ссылка на исходный файл и страницу.
• Набор правил разбора — какие типы документов и поля обрабатываются автоматически, где правило опирается на формулировку, где на структуру раздела, что делать при смене шаблона контрагента.
• Схема интеграции с учётной системой — куда уходят согласованные данные, при каком событии, что происходит при расхождении с уже существующей карточкой.
• Инструкция для юристов — на 2-3 страницы: как внести договор, как посмотреть источник значения, как пометить ошибку и куда она уходит дальше.
• Порядок ручной проверки — при какой уверенности модели поле уходит человеку, кто разбирает спорный случай, как фиксируется решение и попадает ли оно в правила.
• Документация по разбору — типовые ошибки и как их снять правкой правил, а не переобучением модели.
• Тестовый набор — обезличенные договоры с эталонной разметкой, чтобы после правки правил прогнать регресс и увидеть, что старое не сломалось.

Кейс: как сократили ручной разбор массива соглашений

Как было

Юридический отдел производственной компании накопил около 4 000 соглашений: основные договоры, допсоглашения и приложения, часть — сканы разного качества. Юристы открывали каждый документ и переносили в таблицу стороны, сроки, порядок оплаты, штрафные оговорки и условия расторжения — 20–40 минут на документ, с паузами на текущие задачи. Условие в приложении нередко меняло пункт основного текста, и в таблицу попадал вариант, которого в договоре нет.

Что изменили и что стало

Собрали конвейер: распознавание сканов (сложные — через ABBYY с отдельной проверкой), разметка по типам документов, извлечение полей по согласованной схеме. Для каждого значения сохраняется ссылка на фрагмент-источник — юрист открывает страницу и видит, откуда взято поле, вместо того чтобы верить таблице на слово. Если уверенность ниже порога, поле уходит в ручную сверку, а не «додумывается»; реквизиты сторон дополнительно сверяются со справочником, поэтому расхождения в написании названий всплывают сразу.

Проверка документа сократилась до 2–3 минут: юрист подтверждает извлечённое, а не ищет его. Доля полей, принятых без правок, — 92%, пропущенных связанных оговорок — меньше 1% против 6–8% при ручном разборе. Массив разобрали за три недели вместо четырёх месяцев, а выборка по условиям расторжения строится за минуты вместо дня.

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

Что делать, если договоры уже разложены по разным системам?

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

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

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

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

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

Частые технические сомнения перед стартом

Большинство вопросов перед стартом — инженерные, а не юридические. Ниже — те, что чаще всего всплывают на технических встречах: как система ведёт себя на плохих сканах, что делает с нестандартными приложениями, учитывает ли правки юристов, как проверяется качество до запуска и кто имеет доступ к документам.

А нестандартные приложения, таблицы, допсоглашения?

Тело договора и приложения обрабатываются отдельными проходами, чтобы структура одного не ломала разбор другого. Схема полей описывается декларативно: новое поле или новый тип приложения добавляется настройкой, без переписывания логики разбора. Разделы, которые не удалось разобрать уверенно, помечаются как непокрытые — юрист видит, что осталось вне автоматизации.

Система учитывает правки юристов в интерфейсе?

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

Как проверяется качество до запуска и кто видит документы?

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

Обсудим задачу и вернёмся с оценкой и планом

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

Что полезно прислать на старте и уточнить вместе:

• 2-3 обезличенных договора разных типов — по ним видно структуру, разброс формулировок и то, какие поля реально нужно доставать;
• перечень полей: стороны, сроки, предмет, суммы, условия расторжения, штрафы — с пометкой, где допустимо ручное подтверждение;
• примерный объём корпуса и частоту поступления новых файлов;
• источники: почта, сетевая папка, сканы, файлы с электронной подписью, смежные системы;
• текущий процесс проверки и то, какие ошибки критичны, а какие терпимы;
• требования к доступам, хранению и разграничению прав сотрудников.

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