Юрист нашёл в договоре 32 проблемы, AI — 41. Разбираю, кто что пропустил

Как детекторы на основе судебной практики довели AI-анализатор до 41 находки при 0 ложных срабатываний. Как анализ работы юриста превратился в 23 новых проверки. И почему юрист до сих пор незаменим — но уже в другом.

Контекст

Это третья статья про Legal Parser — AI-анализатор договоров для российского рынка.

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

С тех пор произошло два существенных изменения:

1. Новая модель: вместо Claude Opus 4.5 теперь использую Claude Opus 4.6 — свежая модель Anthropic с улучшенным reasoning и расширенным контекстным окном.

2. Детекторы v2: 23 новых детектора и расширения существующих, содержащие более 200 правил на основе судебной практики — проверки на ограничение ответственности, заверения сторон (R&W), индексацию цен, порядок уведомлений, переход рисков, условия расторжения, гарантийные обязательства и другие условия, отсутствие которых регулярно становится причиной споров в арбитраже. Часть проверок создана по результатам анализа работы юриста на реальном договоре. Дополнительно исправлен системный баг в regex-паттернах, который мешал детекторам срабатывать на реальном юридическом тексте.

Всего в системе сейчас 36 проверок обязательных условий, 57 паттернов универсальных ловушек и тематические детекторы для 31 типа договора.

Но числа сами по себе ничего не значат. Нужен был бенчмарк. Настоящий — не «прогнал через 5 кейсов с VC», а сравнение с живым юристом на одном и том же документе.

Эксперимент

Взял реальный договор поставки фармацевтической продукции (ЛС, БАД, медизделия) между двумя ООО. Специфика: фарма — это лицензии, холодовая цепь, МДЛП, остаточные сроки годности. Не самый простой тип договора.

Этот договор предоставил читатель Хабра — вместе с комментариями юриста (37 замечаний + правки в tracked changes). Огромное ему спасибо!

Затем прогнал тот же документ через 10 конфигураций:

• Claude Opus 4.6 + детекторы v2 — текущая версия сервиса

• Claude Opus 4.6 + детекторы v1 — предыдущая версия

• Claude Opus 4.5 + детекторы v1

• Claude Opus 4.6 raw — чат, без детекторов, только промпт

• Claude Opus 4.5 raw — API, без детекторов

• YandexGPT + детекторы v2

• YandexGPT + детекторы v1

• GPT 5.2 Pro (OpenAI, raw)

• DeepSeek R1/V3 (raw)

• Gemini 3 (Google, raw)

Один договор, один промпт, честное сравнение. YandexGPT тестировал только с детекторами — без них модель на таких задачах работает слишком слабо, результат непоказателен.

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

Результаты

41 vs 32 — AI обнаруживает на 28% больше проблем, чем юрист. Но главное не количество, а состав: пересечение, уникальные находки с каждой стороны и — что критически важно — ноль ложных срабатываний.

Между v1 (28 находок) и v2 (41 находка) — один цикл обратной связи: анализ работы юриста, новые проверки, исправления багов. +46% прирост.

Детальное сопоставление: AI vs юрист

Проблему считаю «совпадением», если AI и юрист нашли одно и то же — неважно, совпала ли severity. «Частичное» — нашли, но AI видит только часть того, что видит юрист (или наоборот).

Пересечение — 23 из ~48 уникальных проблем (48%). AI и юрист дополняют друг друга!

Что нашли об�� (20 + 3 частичных)

Ядро пересечения — 20 проблем, которые трудно пропустить при внимательном анализе:

• 100% предоплата без обеспечения — юрист и AI единогласно: CRITICAL. При 100% предоплате покупатель полностью зависит от добросовестности поставщика. AI дополнительно выделил отдельный аспект: право на возврат денежными средствами, а не только зачётом — что важно при отсутствии новых заказов.

• Конфликт между пунктами: срок подачи претензии 1 день vs срок явки представителя 3 дня — физически невозможно подать претензию и дождаться представителя для совместной проверки.

• Подписание ТН = отсутствие претензий — подписав товарную накладную, покупатель формально подтверждает отсутствие претензий по качеству. Юрист оценил как CRITICAL, AI — как HIGH. AI также нашёл cross-reference: формулировка в абзаце о просрочке Поставщика позволяет ему же требовать убытки — первый настоящий cross-reference от AI.

• Нет cap на неустойку — неустойка может расти неограниченно. AI разделил на два отдельных флага (за просрочку оплаты и за просрочку поставки), юрист объединил в один. Оба подхода корректны.

• Документы качества по запросу — сертификаты должны предоставляться при поставке, а не «если попросите».

• Убытки при расторжении — формулировка «убытки при расторжении» без оговорки «по вине» означает, что убытки можно взыскать с инициатора расторжения, даже если он расторгает из-за нарушений другой стороны. Ранее это была уникальная находка юриста — закрыта новым детектором termination.

• Дата оплаты на корр. счёт — деньги считаются полученными с момента зачисления на корреспондентский, а не расчётный счёт. Задержка может составить 1-3 дня — и формально это просрочка покупателя. Ранее тоже находка юриста — закрыта детектором payment-terms.

Три частичных совпадения — AI нашёл суть, но юрист видит шире:

• Нет срока возврата предоплаты — AI выделяет отдельно от 100% предоплаты (что правильно), юрист объединяет.

• Момент получения претензии — AI ссылается на ст. 165.1 ГК. Юрист шире: «регистрация претензии» — неясный термин + почта нереалистична.

• Порядок уведомлений — AI проверяет по чеклисту. Юрист конкретнее: порядок электронной почты + каналы связи.

Что нашёл AI, а юрист — нет (18)

18 проблем, которые юрист не отметил. Разделю на четыре категории.

Отраслевая экспертиза (5)

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

• МДЛП (Честный знак) не упоминается. Маркировка лекарств обязательна с 2020 года (ФЗ-425). Кто загружает данные в систему? Кто отвечает за расхождения? Договор молчит.

• Холодовая цепь без регламента. Для термолабильных ЛС обязательно соблюдение температурного режима при хранении и перевозке. Кто обеспечивает, кто контролирует, что при нарушении? Не указано.

• Остаточный срок годности. Отраслевой стандарт — 60-80% на момент приёмки. Без условия поставщик вправе привезти товар с 2 месяцами из 24.

• Отзыв серий. Нет процедуры при recall производителя — кто уведомляет, кто несёт расходы.

• Скрытый брак: 30 дней vs 2 года. Договор ограничивает 30 днями. Ст. 477 ГК даёт 2 года.

Структурные проблемы (3)

• Порядок приёмки не описан. Кто вскрывает, кто фиксирует, в чьём присутствии составляется акт.

• Аннулирование заказа. Покупатель может аннулировать, но последствия не прописаны.

• НДС не указана ставка. Для ЛС — 10%, для прочего — 20%. При смешанной поставке разница существенна.

Чеклист-детекторы (10)

Автоматические проверки, которые не нашла ни одна модель без детекторов:

Эти 10 проверок работают для любой LLM. Даже YandexGPT, который сам нашёл 4 проблемы, с детекторами v2 получил те же дополнительные пункты. Это платформенный эффект — фундамент качества, не зависящий от мощности модели.

Что нашёл юрист, а AI — нет (7)

С детекторами v1 (28 находок) юрист лидировал с ~20 уникальными находками. После доработки детекторов до v2 осталось 7 — и каждая из них показывает границу текущих возможностей системы.

Cross-reference: сопоставление разделов (3)

Ст. 312 ГК — риск передачи ненадлежащему лицу (CRITICAL). Договор ссылается на ст. 312 ГК РФ и даёт Поставщику право (но не обязанность) запросить подтве��ждение полномочий представителя Покупателя. По закону, если должник (Поставщик при передаче товара) не потребовал проверки — он несёт риск последствий передачи ненадлежащему лицу. Юрист увидел в этом сочетании конкретный риск. Система пока не делает cross-reference между текстом договора и нормами закона — это следующий шаг.

ТН не фиксирует условия / цена в счёте vs ТН. Товарная накладная и счёт могут содержать разные цены. Юрист видит потенциальный конфликт документов — система анализирует один загруженный документ, multi-document анализ пока не реализован.

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

Бизнес-моделирование (4)

«Наличие на складе» = право на отказ. Поставка «при наличии товара на складе» — формулировка, которая де-факто делает обязательство поставщика факультативным. Юрист моделирует ситуацию: «заказ согласован, а товара нет — и поставщик формально прав». В текущей версии система не моделирует бизнес-сценарии — она работает с текстом, а не с последствиями.

Неявка представителя — нет последствий. Совместная приёмка предусмотрена, но что если представитель не придёт? Юрист задаёт вопрос «а что будет?» и не находит ответа в договоре. Система проверяет наличие процедуры, но пока не моделирует сценарий её нарушения.

Привязка оплаты к партии. При нескольких заказах деньги «плавают» — какой платёж к какой партии (ст. 319.1 ГК). Бухгалтерский нюанс, который требует знания реального документооборота.

Срыв поставки — нет иных последствий. Если поставщик вообще не поставил (не просрочил, а не поставил) — в договоре нет права на замещающую сделку. Юрист видит сценарий, который в тексте отсутствует — система пока анализирует то, что написано, а не то, что забыли написать.

Почему эти 7 — не провал AI

Обратите внимание на типы: cross-reference (3) и бизнес-моделирование (4). Ни одна из оставшихся находок юриста — не «пропущенная формулировка в тексте». Это задачи другого класса: сопоставление нескольких документов между собой и с нормами закона, моделирование сценариев «а что если…», анализ того, чего в договоре нет. В текущей версии системы этого нет — но направление понятное: cross-reference с нормами закона, multi-document вход, промпты на моделирование сценариев.

Для сравнения: с детекторами v1 юрист лидировал по ~20 пунктам, включая находки вроде «корр. счёт», «убытки при расторжении без вины», «момент получения претензии» — всё это система теперь ловит. Осталось то, что выходит за рамки анализа одного документа.

Три находки, которые не увидел никто

Claude Opus 4.6 с детекторами обнаружил 3 проблемы, которые не нашёл ни юрист, ни одна из 9 других конфигураций.

🔴 Срок возврата предоплаты — CRITICAL

Покупатель вносит 100% предоплату. Юрист это отметил как риск — правильно. Но в договоре нет срока, в который поставщик обязан вернуть предоплату при неисполнении. Это отдельная проблема, и её не увидел никто, кроме Claude 4.6.

Без конкретного срока возврат может растянуться на месяцы. Покупателю придётся направлять претензию, ждать ответа, идти в суд. Всё это время деньги у поставщика.

В арбитражной практике отсутствие срока возврата предоплаты — одна из самых частых причин споров по договорам поставки. Суды применяют ст. 314 ГК РФ (7 дней с момента предъявления требования), но до суда ещё нужно дойти — а это время и деньги.

🔗 Cross-reference: компенсация транспорта

Пункт 4 описывает условия доставки, пункт 5 — штрафные санкции при срыве. Модель сопоставила два раздела и обнаружила: формулировка в абзаце о просрочке Поставщика позволяет ему же требовать убытки за транспортные расходы. Первый настоящий cross-reference от AI.

Это задача, с которой LLM с длинным контекстным окном справляется хорошо: модель «видит» весь документ одновременно, а не читает последовательно, как человек.

🔍 Двусмысленность формулировки

Формулировка про убытки допускает прочтение, при котором поставщик обязан возместить убытки покупателю даже при собственной (поставщика) просрочке. Вероятно, это ошибка составителя, но в суде такая двусмысленность будет толковаться по ст. 431 ГК РФ — «буквальное значение слов и выражений». И не факт, что в пользу поставщика.

Прогресс: v1 → v2

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

Ключевая метрика — «только юрист»: с ~20 до 7. Это не подгонка под конкретный договор — это закрытие паттернов, которые встречаются в тысячах договоров. Оставшиеся 7 — cross-reference и бизнес-моделирование, принципиально другой класс задач.

Детекторы v2: что нового

Как устроены детекторы

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

Пример. Юрист нашёл «поставка при наличии на складе» — формулировку, которая делает обязательство поставщика условным. Я создал детектор conditional-obligation, который ищет:

• «при наличии на складе / в наличии»

• «в зависимости от наличия»

• «при условии наличия ресурсов»

• «при наличии технической возможности»

• «по мере производства / изготовления / готовности»

Это не пять строчек под конкретный договор. Это паттерн условного обязательства, который встречается в договорах поставки, подряда, IT-разработки, услуг. Везде, где исполнитель может спрятать за формулировкой право не исполнять.

Что добавлено

Сравнение моделей: детекторы решают

Одна и та же модель с детекторами и без:

Raw-модель — 23 находки. С детекторами v2 — 41, на 78% больше. При этом ложные срабатывания: 1 в v1 → 0 в v2.

Для YandexGPT:

Модель слабая — сама нашла ~4 проблемы. Но детекторы добавили 9 гарантированных проверок и убрали 2 ложных срабатывания. Детекторы компенсируют слабость модели.

Opus 4.6 vs Opus 4.5

Разница не только в количестве. Opus 4.6 показал качественно новые возможности: cross-reference между пунктами, обнаружение двусмысленностей, более точная калибровка severity.

GPT 5.2 Pro: 11 находок за 36 минут

GPT 5.2 Pro нашла 11 проблем — нормально для raw-модели, на уровне DeepSeek (10).

Но главная проблема — время: 36 минут на один запрос. Для сервиса, который обещает результат за пару минут, это неприемлемо. Claude Opus 4.6 + детекторы обрабатывает тот же договор за ~2 минуты.

Gemini 3

4 проблемы из 41. Две HIGH, две MEDIUM. Модель, очевидно, не предназначена для задач юридического анализа русскоязычных документов.

Ложные срабатывания: стабильный ноль

При росте с 28 до 41 находки — ни одного нового ложного срабатывания. Для юридического анализа один false positive может дискредитировать весь отчёт. Ноль FP при 41 находке — принципиальный результат.

Техническая заметка: tracked changes

Интересный нюанс, который повлиял на результаты. Юрист внёс правки в Word через режим отслеживания изменений: пеня за невывоз товара была изменена с 1%/день без cap на 0,1%/день, cap 2%.

Разные инструменты читают документ по-разному:

• python-docx (raw-модели через чат) — видит базовый текст: 1%/день. Флагует как CRITICAL.

• pandoc (сервис Legal Parser) — видит финальную версию: 0,1%/день + cap 2%. Это уже приемлемое условие.

Вывод: способ извлечения текста из документа влияет на результаты анализа. Если ваш инструмент не умеет корректно обрабатывать tracked changes — он анализирует не тот документ, который будет подписан.

Что все это значит для практики

Не замена юриста, но уже ближе

Юрист нашёл 7 вещей, которые не нашла ни одна из 10 конфигураций. Все 7 �� cross-reference между документами или бизнес-моделирование. Это задачи, требующие юридического мышления: «а что произойдёт, если…», «а как этот пункт соотносится вот с тем…».

Но граница сдвинулась. Из ~20 уникальных находок юриста осталось 7. Все текстовые паттерны — закрыты. Все проверки, которые можно формализовать — формализованы.

Инструмент для юристов

Это инструмент первичного скрининга, полезный самим юристам. Юрист всё равно будет вычитывать договор целиком — но с готовым списком из 41 потенциальной проблемы он не пропустит то, что мог бы не заметить.

Если бы у юриста был скрининг с 41 пунктом до начала работы — 20 из 23 совпадений уже были бы перед глазами, а время можно потратить на cross-reference и бизнес-логику — то, в чём человек сильнее.

Для малого бизнеса и частных лиц

Не у каждого ИП или физлица есть юрист в штате. Договор аренды, поставки, оказания услуг — подписывают, не читая, или читают, но не понимают последствий.

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

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

Детекторы как платформа

Все проверки из v2 работают одинаково для Claude и YandexGPT. Это платформенный эффект: при смене модели или появлении новой — детекторы продолжают работать. YandexGPT сам нашёл ~4 проблемы, с детекторами — 13. Детекторы утраивают результат слабой модели, хотя до сильной (Claude raw = 23) всё ещё далеко.

Техническая сводка

Что изменилось в системе с момента второй статьи:

Архитектура — двухслойная детекция:

Документ → Извлечение текста → Классификация темы
                                       ↓
                           ┌───────────┴───────────┐
                           ↓                       ↓
                    Слой 1: LLM              Слой 2: Детекторы
                    (32 промпта)             (36 обязательных + 57 ловушек)
                           ↓                       ↓
                           └───────────┬───────────┘
                                       ↓
                               Дедупликация
                               (5 уровней)
                                       ↓
                                Итоговый отчёт

Выводы

1. AI обогнал юриста по количеству (41 vs 32), но юрист незаменим по глубине. AI лидирует в регуляторных, checklist- и отраслевых проверках. Юрист — в cross-reference и бизнес-моделировании. Пересечение — 48%.

2. Детекторы — фундамент качества, независимый от модели. Проверки работают одинаково для Claude и YandexGPT. Детекторы утраивают результат слабой модели (4→13) и почти удваивают сильную (23→41).

3. Обратная связь от юриста → +46% находок за одну итерацию. Новые проверки + исправление бага = с 28 до 41, при 0 FP. Каждый реальный кейс улучшает систему для всех следующих.

4. Граница AI сдвинулась. Из ~20 уникальных находок юриста осталось 7. Все текстовые паттерны — закрыты. Оставшееся — cross-reference и бизнес-сценарии, задачи следующего поколения системы.

5. Claude Opus 4.6 находит то, что не видит никто — включая юриста. Три уникальных находки, одна — CRITICAL. Первый cross-reference от AI.

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

7. Время работы — часть качества. GPT 5.2 Pro — 36 минут. Claude 4.6 + детекторы — ~2 минуты. Для продукта — разница между «можно» и «нельзя».

По следам комментариев

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

• РКН: уведомил Роскомнадзор о том, что являюсь оператором персональных данных. Политика обработки ПД актуализирована.

• Документация проекта: навёл порядок — публичная оферта, условия использования, политика конфиденциальности приведены в соответствие.

Аргументированные комментарии только приветствуются. Если система обработала ваш договор плохо — отправьте его (можно обезличенный) на sales@legalparser.ru. Мне важно видеть реальные кейсы, на которых система ошибается. Как показал этот эксперимент — один реальный разбор с юристом дал значительный прирост к качеству анализа договоров системой.

Попробовать: legalparser.ru — 2 бесплатных анализа при регистрации.

Предыдущие статьи: Часть 1 — модульные промпты, Часть 2 — добавил Claude.