Юрист получил договор, спецификацию и письмо с последними правками. Срок поставки указан в основном тексте, порядок оплаты — в приложении, а в письме контрагент просит считать другую редакцию окончательной. Запрос «найди риски в договоре» не определяет даже состав документов, которые надо проверить. От этого зависит все, что появится в ответе.
ИИ для анализа договоров полезен, когда компания может сформулировать требования к результату: какие условия проверить, с чем их сравнить и как показать замечание юристу. Здесь разберем подготовку такой проверки. Ее итог — перечень отклонений с основаниями и неразрешенных вопросов, по которому специалист продолжает работу с договором.
Сначала определите, какой комплект проверяется
Договор редко заканчивается одним файлом. У него бывают приложения, спецификации, дополнительные соглашения и документы, на которые ссылается основной текст. До анализа составляют перечень входящих материалов. Для каждого сохраняют название, редакцию, источник получения и связь с остальными файлами. При нехватке приложения проверка связанных условий остается незавершенной.
Слово «финальный» в имени файла не определяет действующую редакцию. Нужен установленный компанией способ выбрать версию для проверки: указание ответственного, статус в системе документооборота или другая принятая процедура. Программа может обнаружить несколько похожих файлов и показать различия. Выбирать между ними по собственной догадке она не должна.
Порядок применения документов также требует исходного правила. Если приложение меняет условие основного текста, система должна показать оба положения и основание, по которому предлагается их сопоставить. Когда основание не установлено или формулировки противоречат друг другу, вопрос передают юристу. Нельзя назначить всем приложениям одинаковый приоритет только из-за их типа.
Полезный результат этого этапа — карточка комплекта. В ней видно, какие документы приняты в проверку, какие исключены как старые, какие упомянуты, но отсутствуют. Юрист подтверждает состав один раз и затем работает с определенной редакцией. Отчет без такой карточки сложно воспроизвести: при следующем запуске набор файлов может оказаться другим.
Правило компании нужно превратить в проверяемый вопрос
Формулировка «проверить договор на риски» слишком широка. Она не говорит, какие положения приемлемы для вашей компании, какие требуют отдельного согласования и какие должны присутствовать обязательно. Составьте правила для одного вида договора и одной роли компании. Требования к договору, где компания покупатель, могут отличаться от требований к ее же договору с заказчиком.
Для каждого правила нужны область применения, искомое условие, допустимый вариант, исключения и ответственный за решение. Источником может быть утвержденный шаблон, внутренняя политика или письменное требование владельца процесса. Модель извлекает положения из документов и сопоставляет их с этим основанием. Если основания нет, она не должна придумывать корпоративную позицию.
Не каждое правило применяется ко всем документам выбранного вида. Условие может зависеть от предмета договора, суммы или роли подразделения. Для пропущенной проверки сохраняют причину неприменимости и данные, на которых она основана. Иначе ошибка в определении типа договора выключит нужные проверки, а итоговый отчет покажет отсутствие замечаний без объяснения, почему часть требований не рассматривалась.
Учебный пример внутреннего правила: компания рассматривает аванс выше установленного ею предела только после согласования с финансовым директором. Проверка должна найти размер аванса, определить базу расчета, сравнить с пределом и указать нужное согласование. Это пример устройства правила, а не юридическая норма и не рекомендация по размеру аванса.
Условия часто устроены сложнее одного числа. Оплата может зависеть от приемки, предоставления документов или отдельного уведомления. В таком случае извлекают всю зависимость: действие, событие начала срока, длительность и необходимые подтверждения. Совпадение числа в двух договорах не означает, что обязательства по срокам одинаковы.
Начните с правил, по которым юристы способны согласовать ожидаемый результат на примерах. Если два специалиста расходятся во мнении, сохраните расхождение и уточните критерий. Обучать систему на взаимоисключающих ответах бессмысленно: любой из них будет казаться ошибкой одной из сторон. Неразрешенный профессиональный вопрос должен оставаться видимым.
Правила версионируют отдельно от договоров. Компания меняет допустимые условия, а старые отчеты должны сохранять прежнее основание проверки. В карточке результата фиксируют редакцию документа и редакцию набора правил. Тогда можно объяснить, почему одинаковая формулировка раньше проходила проверку, а после изменения политики требует согласования.
Поиск подходящего фрагмента не доказывает полноту проверки
Система поиска по документам получает вопрос, находит подходящие фрагменты и передает их языковой модели для ответа. Такой подход называют RAG — генерацией с опорой на найденные материалы. Для вопроса о конкретном условии он удобен. Для проверки всех требований требуется дополнительно установить, какие части комплекта действительно были просмотрены.
Предположим, поиск нашел порядок оплаты в основном договоре. Исключение может находиться в спецификации, а уточнение срока — в сноске таблицы. Ответ по одному найденному абзацу будет неполным, даже если модель пересказала его без ошибок. Поэтому для каждого правила задают область проверки и собирают связанные положения из всего принятого комплекта.
Отсутствие найденного фрагмента имеет несколько причин. Условие действительно может отсутствовать, документ может быть плохо распознан, а поиск — не найти нужную формулировку. Эти исходы нельзя объединять в сообщение «условия нет». Для такого вывода нужны подтвержденный состав документов и выполненная проверка предусмотренных разделов; иначе результат остается непроверенным.
Отдельная проблема — таблицы и сканы. Потерянный заголовок столбца меняет смысл числа, а нераспознанная строка может содержать исключение. До смыслового анализа проверяют качество извлечения текста и связи между ячейками. Этот этап подробно описан в статье об автоматической обработке документов; юридическая проверка начинается с уже читаемого материала.
В нашем проекте поиска по корпоративным документам система работает с Word, Excel, презентациями и PDF, показывает источники и учитывает роли пользователей. Это опыт подготовки поиска и проверяемого ответа. Проект не описывает автоматическую экспертизу договора по юридическим правилам, поэтому его показатели нельзя переносить на полноту такой проверки.
При проектировании полезно разделить задачи. Поиск помогает собрать связанные положения; извлечение заполняет поля; обычный код проверяет форматы и сравнивает значения; языковая модель разбирает формулировки. Выбор между поиском по документам и дообучением не отменяет ни одного из этих требований к полноте и происхождению результата.
У замечания должны быть пункт, правило и статус
Юристу нужен результат, который можно проверить без повторного чтения всего договора. Каждое замечание связывают с конкретным положением, внутренним правилом и объяснением расхождения. Ссылка должна открывать ту редакцию, по которой сделан вывод. Если интерфейс открывает последнюю версию файла, замечание может указывать уже на другой текст.
- Соответствует — нужное условие найдено и прошло определенную проверку по указанному правилу.
- Отклонение — условие найдено, но отличается от требования; показано, в чем именно.
- Условие не найдено — предусмотренная область проверки просмотрена, обязательного положения в ней не обнаружено.
- Не проверено — не хватает документа, качества распознавания, ясного правила или однозначного толкования.
Статус «соответствует» относится только к конкретному правилу. Если проверка оплаты пройдена, это ничего не говорит о приемке, ответственности или составе приложений. В общей карточке должны быть видны все правила, включая неприменимые и непроверенные. Зеленый итоговый значок без расшифровки скрывает границы выполненной работы.
Формулировку замечания лучше делать предметной: какое условие найдено, какого требует политика, что надо уточнить. Общая оценка «высокий риск» без основания не помогает согласованию. Уровень важности выводят из правил компании; модель не должна сама определять, какой коммерческий риск бизнес обязан считать допустимым.
Если система предлагает новую редакцию пункта, она показывает исходный текст, предложенную замену и правило, ради которого нужна правка. Замена может изменить связанные положения, поэтому ее проверяют в контексте комплекта. Автоматическая вставка фразы без повторного анализа зависимостей способна устранить одно расхождение и создать другое.
Представим учебный комплект: основная часть предусматривает оплату после приемки, а спецификация содержит аванс до начала работ. Система должна показать связанные положения вместе, а затем применить правило компании для такого сочетания. Два отдельных пересказа пунктов оставляют всю работу юристу. Если правило не определяет этот случай, правильный результат — вопрос специалисту с обоими источниками, а не выбранный моделью вариант оплаты.
Новая редакция требует проверки смысла изменений
Сравнение файлов показывает вставки и удаления, но не всегда отвечает, что изменилось в обязательствах. Контрагент может перенести положение в другой раздел, заменить ссылку на приложение или изменить условие начала срока. Системе нужно сопоставить соответствующие положения, сохранить текстовую разницу и повторить затронутые проверки по правилам компании.
Не ограничивайтесь абзацами, которые различаются посимвольно. Изменение определения термина способно затронуть несколько неизмененных пунктов. Новая спецификация меняет предмет проверки даже при прежнем основном файле. Для важных зависимостей заранее определяют, какие правила надо выполнить повторно при изменении документа или поля.
После получения новой версии прежнее согласование нельзя автоматически переносить на весь комплект. Полезно показать специалисту, какие замечания остались, какие исчезли и какие возникли впервые. Решение по неизмененному вопросу можно сохранить в истории, но основание для этого должно быть явным. Иначе незаметная правка пройдет под отметкой, которую юрист поставил раньше.
В переписке может появиться просьба согласовать условие, которого еще нет в файле. Система выделяет такое расхождение как вопрос, а не подменяет им текст договора. Как компания учитывает письма при согласовании, определяет ее процедура. Для автоматизации важно сохранить оба источника и не приписать документу еще не внесенную редакцию.
Доступ к договорам и правилам проверяют раздельно
Пользователь может иметь право проверить свой договор, но не просматривать договоры другого подразделения. Поиск связанных материалов должен соблюдать те же ограничения, что и система хранения. Отдельно определяют доступ к внутренним правилам и согласованиям: некоторые комментарии содержат коммерческие условия или сведения, которые нельзя показывать внешнему участнику процесса.
Содержимое договора нельзя считать инструкцией для программы. В файле может оказаться текст, предлагающий изменить порядок проверки, пропустить пункт или обратиться к постороннему источнику. Система обрабатывает его как материал договора. Полномочия, состав инструментов и правила доступа задаются вне загруженных документов и не меняются по содержащимся в них указаниям.
Перед отправкой замечаний контрагенту нужен отдельный шаг. Внутренний отчет может содержать предел уступки, причину исключения или комментарий финансового директора. Внешнее письмо формируют из разрешенных замечаний и проверяют перед отправкой. Совпадение темы письма с договором не делает все материалы внутреннего согласования подходящими для передачи наружу.
Хранение исходных файлов, результатов распознавания и журналов также входит в проект. Для каждого вида данных определяют место, срок и ответственного за доступ. Если компания выбирает собственный контур, в нем должны оставаться все предусмотренные компоненты обработки, включая извлечение текста и диагностические журналы. Одного локального сервера с моделью для этого недостаточно.
Как измерить полноту проверки и нагрузку на юриста
Для оценки соберите договоры, по которым специалисты подготовили эталонные замечания и отметили применимые правила. Включите разные формулировки одинакового условия, противоречивые приложения, отсутствующие документы и исправленные редакции. Часть комплекта оставьте вне настройки. Проверка на тех же примерах, по которым писали инструкции, покажет лишь то, что команда научилась обрабатывать эти примеры.
Считайте отдельно пропущенные отклонения и необоснованные замечания. Первый показатель связан с полнотой контроля, второй — с дополнительной нагрузкой юристов. Средний процент правильных ответов может скрывать редкое, но существенное упущение. Результаты нужно видеть по видам правил и по сложности комплекта, особенно если приложения обрабатываются иначе, чем основной текст.
Полезен отдельный набор с отсутствующими условиями. Найти явно написанное ограничение проще, чем установить, что нужного положения нет. На этих примерах проверяют, не выдает ли система проблему распознавания за отсутствие условия и не достраивает ли привычный пункт по шаблону. Вывод должен опираться на проверенные документы, а не на ожидание типового содержания.
Юрист оценивает и удобство результата: открывается ли источник, понятна ли причина замечания, можно ли быстро исправить ложное срабатывание. Время на подготовку первого отчета без времени на его проверку мало что говорит об экономии. Измеряйте весь путь до заключения специалиста, включая повторные версии и исправления, которые потребовал машинный разбор.
Решение по замечанию храните с причиной: ошибка извлечения, неверное применение правила, согласованное исключение или изменение самой политики. Исключение для конкретного контрагента не должно автоматически превращаться в разрешение для будущих договоров. Сохраненная классификация помогает разбирать повторные ошибки и обновлять правила адресно, не ослабляя контроль только потому, что специалисты часто отклоняют однотипные сообщения.
Общие проверки прав, отказов и качества ответа описаны в статье о приемке ИИ-ассистента. Для договоров к ним добавляется покрытие правил по полному комплекту. Сценарий нельзя считать проверенным, если система уверенно пишет замечания к одному файлу, но теряет приложение или не пересматривает результат после изменения редакции.
Начните с одного вида договора и согласованного набора правил
Хорошая граница первого запуска — договоры одного вида с повторяющимися требованиями и понятным владельцем правил. Со стороны компании нужны юрист, представитель подразделения, которое заключает договоры, и администратор системы хранения. Юрист определяет критерии, бизнес объясняет допустимые исключения, администратор помогает собрать версии и настроить доступ.
Сначала система готовит отчет рядом с обычной проверкой. Специалист фиксирует полезные замечания, пропуски и лишние срабатывания. По этим данным уточняют правила и обработку документов. Увеличивать число видов договоров стоит после того, как результат по первому виду воспроизводится на новых комплектах и не требует постоянного восстановления потерянного контекста.
Для предварительного разбора подготовьте обезличенный комплект с приложениями, внутренние требования и пример замечаний юриста. На диагностике LLM-решения для договорной работы мы сопоставим требования с доступными документами и определим состав прототипа. Вы получите перечень проверок, которые можно формализовать, и вопросов, для которых пока не хватает правила или исходного материала.
Стоимость зависит от состава комплекта, качества исходных файлов и интеграции с согласованием. Наш пакет прототипа начинается от 600 тыс. ₽ и рассчитан на один сценарий, одну интеграцию и срок до двух недель. Это ориентир для ограниченной проверки гипотезы; сроки доступа к архиву и подготовки правил нужно согласовать до старта, чтобы они не подменили собой работу прототипа.