AI-агент предварительной проверки договоров: фильтр перед оплатой юриста

У наших клиентов до 50 РМ штатного юриста почти никогда нет, а договор аренды, поставки или услуг нужно подписать сегодня, а не через три дня, когда освободится внешний юрист. Мы собрали AI-агента, который за 3-5 минут вычитывает присланный PDF, находит формальные риск-точки со ссылкой на конкретный пункт и говорит прямым текстом: можно подписывать, или сначала — к юристу. Ниже — как это устроено технически, без воды.

Почему договор нужно проверить за минуты, а не за три дня

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

В итоге директор либо подписывает вслепую, полагаясь на то, что «типовой договор — он и есть типовой», либо теряет сделку из-за задержки. Оба варианта плохие. При этом 80-90% присланных договоров по нашей практике — действительно типовые, без скрытых ловушек, и юристу там смотреть особо нечего. Проблема не в том, что некому проверить договор, а в том, что нет дешёвого и быстрого способа отделить эти 80-90% спокойных случаев от 10-20%, где реально нужен юрист с полной ставкой внимания.

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

Что мы строим: workflow, а не автономный AI-агент со своим циклом

Здесь важно точно назвать вещи. Задача «прочитать документ, найти риск-точки по чек-листу, вернуть структурированный отчёт» — это классическая задача уровня workflow, а не полноценный автономный агент с собственным циклом принятия решений и набором инструментов, которые он вызывает по своему усмотрению. Мы сознательно не разворачивали под это ни отдельную агентную инфраструктуру, ни цикл «модель сама решает, что делать дальше» — вся оркестровка (принять файл, вызвать модель, разобрать ответ, посчитать риск-скор, отправить результат) написана нашим кодом, а модель делает один точный вызов на один договор.

Технически это один запрос к Messages API (POST /v1/messages) на модели claude-sonnet-5: договор передаётся как PDF-документ в теле запроса, модель обязана вернуть результат через принудительный вызов инструмента (forced tool_choice) — это гарантирует, что на выходе всегда строго структурированный JSON с найденными рисками, а не свободный текст, который потом пришлось бы парсить регулярками.

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

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

Модель: Claude Sonnet 5 по умолчанию, Claude Opus 4.8 — для сделок с высокой ценой ошибки

Для основного потока договоров мы используем claude-sonnet-5 — контекстное окно 1 млн токенов (типовой договор аренды на 8-12 страниц занимает от силы 2-3% этого окна), нативная поддержка PDF без предварительного OCR-конвейера, приемлемая цена за токен. Для договоров с высокой ценой ошибки — сумма сделки выше внутреннего порога клиента, договор на нетиповых условиях, залог или поручительство — мы переключаем модель на claude-opus-4-8: та же схема запроса, просто выше глубина рассуждения при том же формате ответа.

Мы не используем claude-fable-5 для этой задачи: он требует обязательного 30-дневного хранения данных на стороне Anthropic без возможности отказаться, а для части клиентов (см. раздел про 152-ФЗ ниже) это неприемлемо по условиям договора на обработку данных. Sonnet 5 и Opus 4.8 в этом смысле дают больше гибкости.

Пайплайн от PDF до отчёта: как устроен один вызов

Договор попадает к нам как PDF — вложение письма, файл из формы на сайте или документ, прикреплённый к задаче в Planfix. Мы передаём его в запросе как document-блок с base64-содержимым и включённым режимом цитирования (citations: {"enabled": true}) — это значит, что каждое найденное нарушение модель обязана привязать к конкретному месту в тексте, а не сформулировать риск «из головы». Ограничения по PDF стандартные для API: до 32 МБ на запрос и до 600 страниц документа — для договора любого типового размера это с большим запасом.

Принудительный tool_choice здесь важен по другой причине: у Claude есть отдельный параметр output_config.format для строгого JSON-вывода по схеме, но он несовместим с включёнными цитатами — запрос с обоими параметрами вернёт ошибку 400. Forced tool use даёт то же самое гарантированно валидное поле tool_use.input, но одновременно с текстовыми блоками, которые несут цитаты (cited_text, document_title, номер страницы через page_location). Поэтому в этой задаче мы используем именно инструмент, а не json_schema-формат.

Если договор — скан без текстового слоя, Claude всё равно читает его: PDF-парсер модели работает и с изображением страницы, распознавая структуру и текст напрямую, без отдельного OCR-шага с нашей стороны. Качество распознавания на плохих сканах ожидаемо ниже, поэтому агент отдельно помечает такие страницы флагом «низкая уверенность в распознавании» — это не риск-точка договора, а сигнал, что стоит запросить более чистую копию.

Чек-лист рисков по типу договора

Мы не просим модель «найти всё подозрительное» — открытый промпт даёт нестабильные и плохо сравнимые между собой результаты. Вместо этого чек-лист риск-категорий формализован отдельно под каждый тип договора и зашит в схему инструмента как перечисляемый список (enum), а не в свободный текст системного промпта. Ниже — сокращённая версия того, что реально проверяется по трём самым частым типам договоров у наших клиентов.

Схема инструмента заставляет модель для каждой найденной риск-точки заполнить и категорию, и уровень серьёзности, и текстовую цитату из документа — это исключает ситуацию, когда агент пишет общими словами «есть риски по разделу 4» без указания, что именно там не так:

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

Как считаем риск-скор и пороги эскалации к юристу

Директору не нужен список из пятнадцати пунктов «риск средний, риск низкий» — нужен один понятный ответ: подписывать сейчас, или сначала показать юристу. Мы считаем риск-скор от 0 до 100 нашим кодом уже после ответа модели — не доверяем модели самой выставлять итоговую оценку, потому что консистентность скоринга между разными договорами и разными запусками важнее, чем гибкость формулировки модели. Каждой найденной риск-точке присваивается вес по категории и множитель по уровню серьёзности (низкая ×1, средняя ×2, высокая ×4), сумма нормируется в шкалу 0-100, отсутствующие обязательные пункты добавляют фиксированный штраф.

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

Пороги не заморожены раз и навсегда: раз в квартал мы выборочно сверяем часть автоматически одобренных договоров (риск-скор ниже 40) с тем, что бы сказал юрист, если бы посмотрел их вручную. Если на выборке начинают попадаться пропущенные риски — это сигнал поднять вес соответствующей категории или пересмотреть порог, а не повод обвинять модель: чек-лист и веса — это наша настройка, и она может устареть, если у клиента поменялась практика контрагентов.

Экономика: сколько стоит одна проверка и почему кэширование чек-листа решает всё

Системный промпт с полным чек-листом риск-категорий, примерами формулировок-ловушек и инструкциями по цитированию — это стабильный блок текста на 3-5 тысяч токенов, который не меняется от договора к договору. Мы помечаем его cache_control: {"type": "ephemeral"}, поэтому при частых проверках (несколько договоров в день у активного клиента) большая часть этого блока читается из кэша по цене примерно в 10 раз ниже полной — экономический эффект растёт с частотой использования, а не с размером конкретного договора.

Даже без учёта экономии от кэша одна проверка на Sonnet 5 по нашим оценкам обходится в единицы-десятки рублей за договор — это на два-три порядка дешевле часа работы внешнего юриста, который в Москве по нашей практике стоит от нескольких тысяч рублей за разовую вычитку типового договора. Экономика здесь не в том, чтобы вообще отказаться от юриста, а в том, чтобы платить ему только за те 10-20% договоров, где агент реально нашёл, за что зацепиться.

Отдельно это касается пересчёта калибровочного набора при обновлении чек-листа — например, когда мы добавляем новую риск-категорию по опыту очередного клиента и хотим прогнать её на всех уже пройденных договорах, чтобы проверить, не изменились ли риск-скоры задним числом. Такие пакетные прогоны не требуют мгновенного ответа, поэтому мы отправляем их через Batches API (POST /v1/messages/batches) — те же запросы, что и в боевом режиме, но со скидкой 50% и выполнением в течение суток, что для внутренней калибровки более чем достаточно.

Персональные данные, 152-ФЗ и где ответственность остаётся за человеком

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

Отдельно фиксируем в договоре с клиентом на обработку данных: срок хранения данных на стороне Anthropic по умолчанию — 30 дней, если явно не согласован иной режим (для части клиентов с повышенными требованиями к конфиденциальности мы обсуждаем это отдельно на этапе внедрения, до передачи первого договора). Полный необезличенный текст документа остаётся внутри контура клиента и нашего сервера — в модель уходит только та версия, где чувствительные персональные поля заменены плейсхолдерами.

И главное разграничение ответственности, которое мы проговариваем на старте с каждым клиентом: агент не даёт юридическую консультацию и не заменяет юриста. Каждый отчёт агента подписан пометкой «предварительный автоматический анализ, не является юридическим заключением» — это фильтр, который решает, стоит ли платить за час юриста на конкретный договор, а не инструмент, который сам принимает решение подписывать или нет. Финальное решение по договорам среднего и высокого риск-скора — всегда за человеком.

Служебные логи самого запроса (не текст договора, а метаданные — время вызова, риск-скор, модель, длительность) мы храним у себя не дольше 30 дней и используем только для разбора инцидентов и расчёта той самой квартальной сверки порогов из предыдущего раздела; после истечения срока они удаляются по регламенту, как и в остальных наших AI-конвейерах.

Внедрение у клиента: неделя от брифинга до первого автоматического отчёта

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

1. День 1-2. Собираем у клиента 10-15 уже подписанных или уже проверенных юристом договоров тех типов, что реально приходят в работу (аренда, поставка, услуги) — это калибровочный набор, на котором сверяем решения агента с тем, что уже сказал человек.
2. День 2-3. Настраиваем канал приёма договора: чаще всего это либо пересылка письма на выделенный адрес с разбором вложения, либо загрузка через простую веб-форму, либо (реже) документ, который клиент сам прикрепляет к задаче в Planfix.
3. День 3-4. Калибруем веса риск-категорий и пороги эскалации под калибровочный набор — если на договорах, которые юрист уже пометил как «подписывать можно», агент выдаёт скор 70+, значит веса завышены и их нужно снизить, и наоборот.
4. День 4-5. Пилот на реальном потоке параллельно с обычным процессом — юрист по-прежнему смотрит все договоры, но мы сравниваем его решения с решениями агента и донастраиваем пороги.
5. С конца недели. Агент выходит на боевой режим: низкий и средний риск идут директору с пометкой агента, высокий риск и вся ответственность выше внутреннего порога клиента — сразу к юристу с приложенным отчётом.

Стоимость и сроки внедрения зависят от того, сколько типов договоров нужно покрыть чек-листом и насколько нестандартна практика конкретного клиента — но сама техническая часть (вызов API, скоринг, маршрутизация в Planfix и почту) у нас уже готова и переиспользуется между клиентами, донастраивается только чек-лист и веса.

Частые вопросы

Может ли этот агент полностью заменить юриста?

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

Что если договор — плохо отсканированная копия без текстового слоя?

Claude читает PDF и как изображение страницы, без отдельного OCR-шага с нашей стороны, и в большинстве случаев справляется даже со сканами среднего качества. Но если распознавание неуверенное, агент отдельно помечает это флагом «низкая уверенность в распознавании» в отчёте — не как риск договора, а как сигнал запросить у контрагента более чистую копию перед тем, как доверять результату проверки.

Как чек-лист подстраивается под специфику конкретного клиента?

На этапе внедрения мы калибруем веса риск-категорий и пороги эскалации на 10-15 уже проверенных юристом договорах клиента — это занимает несколько дней и делается один раз. Если у клиента есть нетиповые условия работы (например, специфика конкретной отрасли или нестандартные формы договоров), соответствующие риск-категории добавляются в чек-лист отдельно под него.

Хранится ли текст договора на стороне Anthropic после проверки?

По умолчанию срок хранения данных на API Anthropic — 30 дней, если для организации не согласован иной режим. Перед отправкой мы маскируем персональные данные физлиц (паспортные данные, домашние адреса) — они не нужны для оценки договорных рисков и в модель не попадают. Условия хранения и обработки фиксируются отдельно в договоре с клиентом на обработку данных до передачи первого документа.

Сколько стоит внедрение и сколько занимает по времени?

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