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.

Три источника данных. Сами договоры (PDF/DOCX), переписка по согласованиям (email-треды) и учётные системы (СЭД, ERP и т.п.). Каждый — со своим экстрактором, который приводит вход к одной нормализованной форме.

Нормализованный контекст договора. Стороны, предмет, цена, гарантии, ответственность, сроки, applicable law — собирается из всех трёх веток в единое представление.

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

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

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

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

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

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

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

§ d Архитектура решения Что внутри

Архитектура: три источника, единый контекст, всё локально.

Договор живёт не в одном файле. Параллельно нужны его сам текст, переписка по согласованиям и данные из учётных систем. Три ингестные ветки приводят всё к нормализованному контексту, дальше линейный пайплайн: сверка с эталонами → карточки замечаний → UI юриста. Всё внутри on-prem-периметра, без внешних API.

ON-PREM ПЕРИМЕТР · ЛОКАЛЬНЫЕ МОДЕЛИ · БЕЗ ВНЕШНИХ API ИСТОЧНИКИ текст договора PDF · DOCX переписка по согласованиям email-треды учётные системы EDMS · ERP · … ЭКСТРАКТОРЫ экстрактор договора стороны · цена · ответственность · сроки · применимое право LLM экстрактор переписки согласования · контрпредложения · правки · временные метки LLM structured ingestor детерминированные поля · ссылки · данные контрагентов нормализованный контекст договора единое представление со всех трёх источников comparator сверка с эталонами · корпоративными политиками · правилами LLM карточки замечаний цитата → объяснение → правило → критичность LLM UI юриста · 3-7 приоритетных замечаний ОБЩИЕ СЕРВИСЫ каталог правил эталоны · DEC log · политика критичности расширяет команда заказчика ВСПОМОГАТЕЛЬНЫЕ МОДУЛИ revision diff сравнение редакций между раундами eval suite регрессионные тесты между релизами ─── красные стрелки = поток данных – – – пунктир = использование сервиса ▮ LLM = шаг использует локальную LLM (on-prem)

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

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

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