Автоматизация договоров с AI: заполнение, проверка рисков и согласование

Коротко

• Автоматизация договоров состоит из четырёх независимых кусков: данные → сборка документа → проверка рисков → согласование и подпись. Их можно внедрять по отдельности, и первый обычно даёт больше всего эффекта.
• Заполнение — это не задача для AI. Подстановка реквизитов, сумм и сроков должна быть детерминированной: шаблон + данные из CRM. Нейросеть тут только добавит непредсказуемость.
• AI силён на входящих чужих договорах. Он сравнивает текст с вашим плейбуком (сводом позиций компании) и выдаёт список отклонений: что написано, чем это грозит, какая формулировка вам подходит.
• AI не выносит вердикт «можно подписывать». Он готовит материал для решения. Решение принимает юрист или руководитель, и это фиксируется в логе.
• Типичный эффект при 60 договорах в месяц — с ~31 часа ручной работы до ~9, но главная выгода не в часах, а в сроке цикла: с 4–5 дней до 1–2.
• Порог окупаемости честный: до 30 договоров в месяц AI не нужен, хватит нормального шаблона и чек-листа.

Где на самом деле теряется время

Разберём типичный поток в компании на 20–60 человек — производство, услуги, дистрибуция, неважно.

Менеджер закрыл сделку и берёт договор «как в прошлый раз»: открывает папку, находит документ похожего клиента, меняет название, ИНН, сумму. В половине случаев где-то остаётся старое: срок оплаты от предыдущего клиента, приложение с не тем перечнем работ, реквизиты банка, который сменился в прошлом квартале.

Дальше документ уходит юристу или руководителю. Тот правит в Word, отправляет обратно. Появляется Договор_Ромашка_фин.docx, потом Договор_Ромашка_фин2.docx, потом Договор_Ромашка_фин2_прав_ДК.docx. Кто-то отправляет клиенту не ту версию.

Клиент присылает свой протокол разногласий или, что хуже, свой договор на 18 страниц. Его нужно вычитать. Вычитывает человек, который сегодня занят, — значит, послезавтра.

Итог: сделка закрыта в понедельник, счёт выставлен в следующий четверг. Деньги в кассе появляются на неделю позже, чем могли бы, и так по каждой сделке.

Обратите внимание, где именно потери. Не в наборе текста. В сверке данных, версионности и ожидании человека. Автоматизировать нужно это, а не «написание договоров нейросетью».

Как выглядит рабочая схема

Разложу на четыре слоя. Их можно строить по очереди — каждый работает сам по себе.

Слой 1. Данные о контрагенте

Реквизиты не должны вводиться руками дважды. По ИНН подтягивается всё остальное — название, ОГРН, адрес, руководитель, статус в реестре — через сервисы вроде Dadata или официальные API ФНС. Это не AI, это обычная интеграция, и она же ловит первые риски: контрагент в процессе ликвидации, адрес массовой регистрации, директор дисквалифицирован, компании три недели от роду.

В связке с CRM (Битрикс24, amoCRM, что у вас стоит) карточка сделки становится источником правды: предмет, сумма, срок, условия оплаты. Если данных не хватает — система не собирает документ, а возвращает менеджеру список недостающих полей.

Это самый скучный слой и самый доходный. Больше половины ошибок в договорах — это не юридические ошибки, а несведённые данные.

Слой 2. Сборка документа

Здесь работает шаблонизатор, а не языковая модель. Технически — docx-шаблон с плейсхолдерами (python-docx / docxtpl, Carbone, Google Docs API — вариантов много). На входе JSON с данными, на выходе готовый файл с правильной нумерацией, приложениями и спецификацией.

Ключевое правило: у шаблона есть версия и владелец. Не «папка с договорами на общем диске», а конкретный файл, у которого известно, кто и когда его менял. Иначе через полгода в компании снова будет пять шаблонов подряда.

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

Слой 3. Проверка рисков — здесь AI действительно нужен

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

Основа — плейбук. Это письменный свод позиций компании по каждому существенному пункту. Не философия, а конкретика:

• аванс — не менее 50%, при постоплате срок не более 10 рабочих дней;
• ответственность исполнителя ограничена суммой договора;
• неустойка не выше 0,1% в день;
• односторонний отказ заказчика — только с оплатой фактически выполненного;
• подсудность — по месту нахождения исполнителя;
• срок приёмки — 5 рабочих дней, дальше молчаливая приёмка;
• эксклюзив, штрафы за переманивание, безусловные гарантии — красная зона, всегда к юристу.

Для каждого пункта — три уровня: «приемлемо», «обсуждаемо», «стоп». И желательно готовая формулировка, которой вы отвечаете.

AI-агент читает присланный договор и сопоставляет его с плейбуком. Выход выглядит примерно так:

> п. 7.3 — Ответственность. Уровень: стоп. > В тексте: ответственность Исполнителя не ограничена, включая упущенную выгоду. > Отклонение от плейбука: п. 4 (ответственность в пределах суммы договора). > Предлагаемая правка (формулировка №12 из библиотеки): «Совокупная ответственность Исполнителя ограничена суммой, фактически оплаченной Заказчиком по настоящему Договору».

> п. 5.2 — Срок оплаты. Уровень: обсуждаемо. > В тексте: 45 календарных дней с момента подписания акта. > Плейбук: не более 10 рабочих дней. Финансовое влияние — кассовый разрыв ~1,5 месяца на сумму договора.

Дальше — три вещи, которые отличают рабочую систему от демо:

1. Модель обязана цитировать исходный текст пункта. Если она не смогла процитировать — она не нашла пункт, а не «пункта нет».
2. Модель не ссылается на статьи законов самостоятельно. Юридическая квалификация — задача юриста. AI отвечает на вопрос «что здесь написано и чем это отличается от нашей позиции», а не «что говорит закон».
3. Есть отдельная проверка на пропуски: чего в договоре нет вообще — порядка приёмки, форс-мажора, конфиденциальности, порядка расторжения. Отсутствующий пункт опаснее плохого, потому что его никто не замечает.

Из наблюдений: на 18-страничном договоре сетевого заказчика ручная вычитка занимает 40–50 минут. Машинный разбор — 3–4 минуты, после чего человек тратит 10–15 минут на 5–7 спорных пунктов, потому что смотрит уже прицельно, а не читает всё подряд.

Слой 4. Согласование, подпись, сроки

Маршрут согласования — не переписка. Это конечный автомат: кто согласует, в каком порядке, что происходит при молчании больше двух дней.

Практично собирать его в Telegram, если компания там живёт: бот присылает согласующему карточку с суммой, контрагентом, отчётом по рискам и двумя кнопками — «согласовано» / «есть замечания». Замечания пишутся туда же и падают в общий тред по договору. Никаких фин2_прав.

Дальше — подписание через ЭДО (Диадок, СБИС, Контур.Сайн) и обратная запись в CRM: статус, дата, ссылка на подписанный файл.

И последнее, что почти всегда забывают: реестр договоров со сроками. Дата окончания, автопролонгация, дедлайн оплаты, срок гарантии. Система напоминает за 30 дней. Это не про AI совсем, но по деньгам часто перевешивает всё остальное — особенно в аренде, подписках и рамочных поставках.

Если хочется понять общую логику, чем такой агент отличается от чат-бота — есть отдельный разбор: что такое AI-агент для бизнеса.

Сколько это экономит

Считать надо по своим цифрам, но покажу структуру расчёта на реальном по порядку величин примере: компания, 60 договоров в месяц, из них 45 по своему шаблону и 15 входящих чужих.

Было:

Стало:

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

Считать честнее по двум другим метрикам:

Срок цикла. От «сделка закрыта» до «договор подписан». В описанном случае было 4–5 рабочих дней, стало 1–2. Для компании со средним чеком 400 тыс. и 60 договорами это сдвиг всей выручки месяца примерно на неделю вперёд — вопрос не прибыли, а кассы, но кассовый разрыв обычно болит сильнее.

Цена пропущенного пункта. Один договор с неограниченной ответственностью или сроком оплаты 60 дней стоит дороже, чем вся автоматизация. Здесь эффект нельзя посчитать заранее — но можно посчитать назад: поднимите договоры за последний год и найдите те, где условия оказались хуже ваших стандартных. Обычно находится 3–8 штук, и это и есть обоснование бюджета.

Когда не надо. Если у вас 10–15 договоров в месяц и все по одному шаблону — не заказывайте AI. Сделайте нормальный шаблон в Google Docs с формой на входе и чек-лист на одну страницу. Порог, где автоматизация начинает окупаться, — примерно от 30–40 договоров в месяц или от 10 входящих чужих. Как оценивать процесс до внедрения, разбирали здесь: как понять, что процесс пора автоматизировать.

Риски и что с ними делать

Модель придумывает формулировки. Худший сценарий: AI пишет пункт, который звучит юридически, но означает не то. Лечится ограничением — модель не генерирует текст пунктов, а выбирает из библиотеки утверждённых формулировок. Свободный текст допустим только в комментарии для человека, не в самом договоре.

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

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

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

Автоматическое подписание. Не делайте. КЭП ставит человек. Всегда. Даже если сумма маленькая и контрагент постоянный.

Притупление внимания. Самый недооценённый риск. Когда система три месяца подряд пишет «критичных отклонений не найдено», человек перестаёт читать. Поэтому отчёт не должен содержать фразы «можно подписывать». Формат должен быть списком: «проверено 14 пунктов, отклонений 2, не найдено в договоре 3 обязательных раздела». Пусть вердикт остаётся действием человека — это не формальность, а то, что удерживает внимание.

Версии плейбука. Плейбук меняется. Проверка, сделанная в марте по старому плейбуку, не равна проверке в сентябре. Храните версию плейбука и версию промпта рядом с результатом проверки. Иначе через год невозможно будет понять, почему договор прошёл.

Подробнее про этот класс ограничений — в материалах блога о надёжности и human-in-the-loop.

Как внедрять: четыре недели

Неделя 0. Инвентаризация. Соберите 40–50 реальных договоров за последний год и разложите на три корзины: ваш шаблон без правок, ваш шаблон с правками, чужой договор. Посчитайте, сколько в каждой. Это определит, что автоматизировать первым. Если 80% — свой шаблон, начинайте со слоя 1–2, AI пока не нужен.

Неделя 1. Плейбук. Сядьте с юристом и запишите 15–25 пунктов с тремя уровнями и готовыми формулировками. Это самая тяжёлая часть, и её нельзя делегировать подрядчику — позиции компании знает только компания. Плейбук полезен сам по себе, даже если дальше вы ничего не автоматизируете.

Неделя 2. Данные и сборка. Форма или карточка сделки → проверка ИНН → шаблон → готовый файл. Плюс маршрут согласования с уведомлениями. На этом этапе уже видно ускорение.

Неделя 3. AI-ревью на исторических данных. Прогоните через агента 20 договоров, по которым вы знаете правильный ответ — где были проблемы, а где нет. Считаем две вещи: сколько реальных проблем найдено и сколько ложных срабатываний. Если система кричит на всё подряд, ей перестанут верить за две недели. Настраивать нужно до пилота, а не в бою.

Неделя 4. Пилот на одном потоке. Не на всех договорах сразу — на одном типе, например входящие от поставщиков. Юрист параллельно проверяет вручную и сравнивает. Через 3–4 недели решаете, расширять или нет.

Чек-лист готовности

• Есть один актуальный шаблон каждого типа договора, и известно, кто его владелец.
• Реквизиты контрагентов лежат в CRM, а не в переписке.
• Плейбук написан и согласован с юристом.
• Есть библиотека утверждённых формулировок для правок.
• Понятно, кто согласует и в каком порядке, и что делать при молчании.
• Решён вопрос, где обрабатываются данные договоров.
• Настроены роли доступа и логирование.
• Назначен человек, который принимает финальное решение по каждому договору.

Если больше трёх пунктов не отмечено — начинать надо с них, а не с выбора модели.

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

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

Заменит ли это юриста? Нет, и цель другая. Меняется структура работы: юрист перестаёт вычитывать 18 страниц ради шести спорных пунктов и занимается только этими шестью. В компаниях без штатного юриста система не заменяет его, а помогает понять, когда его точно нужно привлечь.

Насколько точно AI находит риски? Зависит от плейбука, а не от модели. С подробным плейбуком на 20+ пунктов агент стабильно ловит формальные отклонения — сроки, суммы, ответственность, подсудность, штрафы. Хуже он справляется со смысловыми ловушками, спрятанными в связке нескольких пунктов и приложений. Поэтому измеряйте точность на своих исторических договорах до запуска.

Можно ли отправлять договоры во внешнюю нейросеть? Только после ответа на вопрос о персональных данных, коммерческой тайне и обязательствах по NDA перед контрагентом. Если поток чувствительный — обезличивайте текст перед отправкой либо разворачивайте модель в собственном или российском контуре. Это проектное решение, принимается до начала работ.

Нужна ли отдельная система или можно в CRM? Значительная часть делается в существующей CRM: карточка сделки, поля, шаблон, статусы, напоминания о сроках. Отдельный сервис нужен, когда добавляется AI-ревью, библиотека формулировок и сложные маршруты согласования с несколькими ветками.

Сколько стоит и за сколько окупается? Диапазон широкий и зависит от количества типов договоров и интеграций — обычно это 3–6 недель работы команды. Окупаемость считайте не по сэкономленным часам, а по сроку цикла (насколько раньше выставляется счёт) и по числу договоров за прошлый год, где вы согласились на условия хуже стандартных.

А если договоры у нас нетиповые, каждый свой? Тогда слой сборки почти не даст эффекта, а слой проверки даст максимум. Начинайте с плейбука и AI-ревью, шаблонизацию отложите.

Что делать дальше

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

Если хочешь понять, что автоматизировать у себя, — напиши Дмитрию в Telegram @dmkosik или опиши свой процесс для диагностики Paramiko: посмотрим на реальный поток договоров и скажем, где эффект будет, а где вы просто потратите бюджет.