ИИ для анализа договоров: пошаговый workflow для юриста

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

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

Почему проверка «одним запросом» не работает

Если попросить модель «проверить договор и найти риски», она вернёт список. Список будет по существу верным и при этом неполным — по трём причинам.

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

Workflow из восьми шагов

1. 1

   Подготовить документ

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

2. 2

   Определить тип договора и свою сторону

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

3. 3

   Задать критерии проверки

   6–10 позиций, соответствующих типу договора и практике фирмы. Это ваш стандарт, а не выбор модели.

4. 4

   Получить структурированный разбор

   Таблица: пункт, цитата, суть риска, степень, предлагаемая правка. Привязка к цитате превращает проверку в сверку.

5. 5

   Проверить отсутствующие условия

   Отдельный запрос по чек-листу: какие из перечисленных условий в договоре не урегулированы. Это шаг, который чаще всего пропускают.

6. 6

   Сверить со стандартом фирмы

   Сравнение с эталонной редакцией или playbook: где отклонение допустимо, где требует согласования, где неприемлемо.

7. 7

   Сформировать вопросы клиенту

   Часть условий нельзя оценить без бизнес-контекста. Список вопросов — самостоятельный результат работы.

8. 8

   Провести проверку юристом и подготовить правки

   Финальная редакция, аргументация позиции, приоритезация правок на обязательные и желательные.

Шаг 3 и 4 на практике: промпт для разбора

Роль: юрист по коммерческим договорам, представляешь интересы заказчика.

Контекст: приложен договор подряда на строительно-монтажные работы. Заказчик — производственная компания. Сроки критичны: объект должен быть введён в эксплуатацию к фиксированной дате. Подрядчик предложил свою форму.

Задача: разобрать договор по критериям ниже.

Критерии:
1. Сроки: порядок исчисления, основания продления, последствия просрочки.
2. Изменение объёма и цены: кто инициирует, как согласуется, что происходит при недостижении согласия.
3. Приёмка: этапы, сроки подписания, последствия немотивированного уклонения.
4. Гарантийные обязательства: срок, объём, порядок предъявления.
5. Ответственность: пределы, исключения, соотношение неустойки и убытков.
6. Односторонний отказ: основания у каждой стороны, симметрия, расчёты при отказе.
7. Обеспечение исполнения.
8. Разрешение споров и применимое право.

Формат: таблица с колонками — критерий, пункт договора, цитата (дословно), суть риска для заказчика, степень риска (высокая / средняя / низкая), предлагаемая формулировка правки.

Ограничения:
— Работай только с текстом приложенного документа.
— Не ссылайся на нормы права и судебную практику.
— Цитаты приводи дословно, без пересказа.
— Если формулировка допускает несколько толкований, вынеси это отдельной строкой и укажи оба толкования.
— Не оценивай коммерческую целесообразность цены.

Шаг 5: проверка того, чего в договоре нет

Это отдельный запрос, а не часть предыдущего. Смешивание двух задач в одном промпте стабильно ухудшает результат по обеим.

Задача: определить, какие из перечисленных условий в приложенном договоре подряда НЕ урегулированы или урегулированы неполно.

Перечень для проверки:
1. Порядок передачи строительной площадки и последствия задержки передачи.
2. Ответственность за сохранность материалов на площадке.
3. Порядок привлечения субподрядчиков и согласование их кандидатур.
4. Скрытые работы: порядок освидетельствования и фиксации.
5. Порядок консервации объекта при приостановке.
6. Распределение рисков при обнаружении обстоятельств, не учтённых в проектной документации.
7. Порядок исправления недостатков в гарантийный период и сроки реагирования.
8. Условие о запрете уступки прав по договору.
9. Порядок обмена юридически значимыми сообщениями и адреса.
10. Условие о конфиденциальности.

Формат ответа: для каждого пункта — один из трёх статусов: «урегулировано» (с указанием пункта договора), «урегулировано частично» (с указанием пункта и того, чего не хватает), «не урегулировано».

Ограничение: не предлагай формулировки, только диагностика.

Шаг 6: сравнение со стандартом фирмы

Если у фирмы есть эталонные редакции или playbook с допустимыми отклонениями, сравнение с ними даёт больше, чем абстрактная оценка рисков: оно сразу отвечает на вопрос «можно ли это подписать без согласования».

Что менять в зависимости от типа договора

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

Что ИИ пропускает системно

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

Чего не делать

Сколько времени это экономит на самом деле

Честный ответ: экономия возникает не на первом договоре, а начиная примерно с десятого — когда чек-листы и промпты уже отлажены. На единичном сложном договоре ИИ экономит меньше, чем кажется, потому что проверка результата занимает сопоставимое время.

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

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

Где узкое место на самом деле

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

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

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

Источники

• Magesh V. и др. «Hallucination-Free? Assessing the Reliability of Leading AI Legal Research Tools», Stanford RegLab, 2024 — публикация
• American Bar Association, Formal Opinion 512, 2024 — требования к компетентности и проверке результатов ИИ