AI-анализ договоров: сверка с эталонным шаблоном и поиск рискованных формулировок
Первичный разбор договора: извлечение ключевых полей, сравнение с эталонным шаблоном по пунктам, выделение рискованных формулировок с пояснением. С 1-2 часов чтения до отчёта за минуты.
- Масштаб
- PDF и DOCX, отчёт по пунктам
- Этап
- В проде
- Сдан
- апрель 2026
TL;DR. Ручная сверка входящего договора с эталонным шаблоном отнимала 1-2 часа юриста на документ. Система парсит PDF или DOCX, извлекает ключевые поля, сравнивает с шаблоном по пунктам и выделяет формулировки повышенного риска — ответственность, сроки, штрафы — с пояснением, почему пункт рискованный.
Ситуация: где уходит время юриста
Входящий договор от контрагента приходит в чужой редакции. Чтобы понять, что в нём поменяли относительно собственного шаблона, юрист читает документ целиком: сверяет структуру, ищет добавленные и удалённые пункты, отмечает формулировки, которые смещают ответственность.
На один договор уходило 1-2 часа. При потоке документов первичный разбор становился узким местом: юрист тратил основное время не на решение, а на вычитку.
Задача
- Автоматизировать первичный разбор договора — до того, как за него берётся человек.
- Показывать отличия от эталонного шаблона по пунктам, а не «в целом».
- Отдельно помечать формулировки повышенного риска с объяснением причины.
- Оставлять решение за юристом: система готовит материал, а не выносит вердикт.
Что сделали
Пайплайн принимает договор в PDF или DOCX. Документ парсится с сохранением структуры пунктов — это принципиально: сравнение идёт по пунктам, а не по сплошному тексту.
Из документа извлекаются ключевые поля: стороны, предмет, сроки, суммы, порядок оплаты, ответственность, порядок расторжения. Извлечённая структура сопоставляется с эталонным шаблоном компании — система показывает, какие пункты добавлены, какие удалены, какие переписаны.
Поверх сравнения работает языковая модель: она размечает пункты с повышенным риском по категориям — ответственность, сроки, штрафные санкции — и объясняет формулировкой, в чём именно риск. На выходе — структурированный отчёт по договору, с которым юрист начинает работу уже от размеченных мест.
Результат
- Первичный разбор договора — с 1-2 часов ручного чтения до предварительного отчёта за минуты.
- Юрист начинает работу с размеченных пунктов, а не с первой страницы.
- Отличия от эталонного шаблона видны списком, включая тихие правки в середине документа.
- Решение остаётся за человеком: система готовит материал и объясняет разметку, но не подменяет юридическую оценку.
Ключевые технические решения
- Парсинг с сохранением структуры пунктов. Договор разбирается не как сплошной текст, а как дерево пунктов. Без этого сравнение с шаблоном даёт шум: перенос абзаца читается как изменение содержания.
- Сравнение с шаблоном отдельно от LLM-разметки. Отличия от эталона вычисляются детерминированно. Языковая модель отвечает только за оценку риска и пояснение — так расхождения в структуре нельзя списать на галлюцинацию модели.
- Категории риска, а не общий балл. Ответственность, сроки и штрафы разнесены по категориям: юристу нужно знать, где именно смещён баланс, а не насколько договор «плохой» одним числом.
- Пояснение к каждой пометке. Пункт без объяснения бесполезен — его всё равно придётся перечитывать. Модель формулирует, что конкретно в тексте создаёт риск.
Частые вопросы
Система заменяет юриста?
Нет. Она закрывает первичный разбор — извлечение полей, сверку со своим шаблоном и разметку рискованных пунктов. Юридическую оценку и решение выносит человек, просто начинает он не с чистого листа, а с размеченного документа.
Какие форматы договоров поддерживаются?
PDF и DOCX, включая сканы и документы со сложной вёрсткой — парсинг вытаскивает структуру пунктов, а не только текстовый слой.
Можно ли использовать свой шаблон договора?
Да, эталонный шаблон — вход системы. Сравнение идёт против того документа, который компания считает своей нормой, а не против абстрактного образца.
Данные договоров уходят во внешние сервисы?
Зависит от контура. Разбор можно собрать на локальном инференсе — так же, как в проектах со звонками, где записи не покидают серверы заказчика. Это решается на этапе аудита, до начала работ.
Что было бы дальше
Естественное продолжение — накопление статистики по контрагентам: какие правки в шаблон вносит каждый из них регулярно, где компания систематически уступает. Дальше — связка с проверкой контрагента по ИНН, чтобы к разбору договора сразу прикладывалось заключение по компании-подписанту.
Если разбор договоров стал узким местом — обсудим за 30 минут.
Стек
- Python
- LlamaCloud
- LLM API
- парсинг PDF/DOCX
- структурированный отчёт