Case05 / 05 · Contract Review
ClientNDA · полностью локальный контур
DomainLegal · on-prem · local LLM

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

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

on-prem local LLM contract review evals rules engine agentic pipeline
§ a Контекст Чем дело

Сотни договоров в год. Каждое незамеченное условие — потенциальные потери на сотни тысяч.

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

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

Задача — автоматическая сверка с понятными замечаниями для юриста и аудируемыми правилами.

  • a.Сверка с эталонами и корпоративными политиками.
  • b.Кроме оценки — конкретные места с цитатами.
  • c.Аудируемость: каждое замечание со ссылкой на правило.
  • d.Полностью локальный контур — никаких внешних API.
§ b Что мы сделали Под капотом

Извлечение структуры + сверка с эталонами + reasoning + расширяемый каталог правил.

Извлечение и нормализация текста договора с разметкой по структуре: стороны, предмет, цена, гарантии, ответственность, сроки, applicable law.

Сверка с эталонами: что должно быть, чего не должно, что должно быть в конкретной формулировке.

Карточка замечания для юриста: цитата → объяснение → ссылка на правило / эталон → severity.

Версионирование редакций. Сравнение редакций между раундами правок: что изменилось и кто.

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

Под капотом — наш собственный двухчастный процесс с зафиксированными критериями приёмки и явными точками выхода на каждой стадии. Подробнее в § Process.

§ c Результат Что вышло
Result
Часы → минуты на стандартных классах договоров. Юрист видит 3–7 ключевых замечаний, а не «прочитайте 30 страниц». Каталог правил — теперь аудируемый артефакт. Меньше пропусков критичных условий — ожидаемая экономия на цикле.

Скриншоты не публикуем — заказчик не дал согласия на детали интерфейса.

§ d Под капотом — наш процесс Process

Двухчастный процесс с точками приёмки.

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

Phase 1 · Analysis
Разбираемся, какую бизнес-задачу решаем и где границы риска.
  • a.Сбор контекста: цель, стейкхолдеры, ограничения, цена ошибки.
  • b.Карта домена и описание flow — на языке заказчика.
  • c.Критерии приёмки и метрики, по которым бизнес поймёт, что работает.
  • d.Фиксация решений и допущений — чтобы потом не было «мы думали иначе».
  • e.Код не пишем, пока это не готово.
Phase 2 · Engineering
Делаем под зафиксированные критерии — с управляемым риском.
  • a.Стек подбираем под продуктовые и бизнес-требования, а не наоборот.
  • b.Сначала PoC на самом рискованном — до больших вложений.
  • c.Upfront-план разбит на стадии — после каждой можно остановить или развернуть.
  • d.Eval'ы для бизнес-стейкхолдеров: качество видно в понятных вам цифрах.
  • e.Эти же eval'ы остаются у команды как инструмент развития системы.
Точки приёмки
scope
критерии
PoC
MVP
прод

Другие кейсы.

Похожая задача?
Напишите.

Опишите кратко, что у вас. Дальше — в переписке: понимаем контекст, оцениваем границы и договариваемся о PoC за дни–недели.