Автоматизация договоров и документов с AI-шаблонами: гибридный подход

Почему AI генерация документов ломается на реальных договорах

AI генерация документов уверенно работает на однородном потоке и рассыпается, когда в папку попадает второй контрагент со своей структурой. Пункты переименованы, нумерация сбита, приложения вынесены в отдельные файлы — правило, которое искало «Предмет договора» по заголовку, больше не находит ничего. Автоматизация договоров начинается не с шаблона, а с разнобоя форматов, и именно он съедает первый месяц работы.

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

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

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

Что меняется после внедрения: сроки, ошибки, объём

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

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

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

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

Режимы работы: шаблон, языковая модель, гибрид

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

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

Порядок работ: от разбора массива до сдачи

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

1. Аудит документопотока. Смотрим, какие типы договоров и сопутствующих бумаг реально ходят в компании, в каких форматах, сколько среди них сканов и таблиц. На выходе — карта типов с долями и перечень полей, которые нужно извлекать.
2. Проектирование схемы обработки. Раскладываем каждый тип по маршруту: где разбор идёт правилами и словарями, где подключается модель, в какой точке документ уходит на ручную проверку. Фиксируем, что считается успешным разбором.
3. Настройка извлечения полей. Заводим справочники контрагентов, шаблоны реквизитов и правила нормализации дат, сумм и нумерации. Для каждого поля задаём порог уверенности: ниже — документ не проходит дальше без человека.
4. Сборка шаблонов генерации. Типовые документы собираются из проверенных блоков с подстановкой полей из карточки, а недопустимые сочетания условий отсекаются до выгрузки.
5. Валидация на исторических примерах. Прогоняем массив прошлых договоров и сверяем результат с тем, что когда-то заполнял человек. Расхождения разбираем и закрываем правилами либо корректируем пороги.
6. Передача в эксплуатацию. Отдаём регламенты обработки, описание очереди проверки, настроенный мониторинг качества и обучение сотрудников. Дальше сопровождение идёт по метрикам: доля разобранных без правок, типовые ошибки, объём ручной очереди.

Комплект поставки: шаблоны, правила, регламенты

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

• Библиотека шаблонов договоров — разбита по типам сделок, поля размечены как обязательные, условные и опциональные. Версия шаблона фиксируется в выпущенном документе, поэтому всегда видно, по какой редакции он собран.
• Правила извлечения и валидации полей — описано, что считается значением, какие форматы дат, сумм и реквизитов допустимы, с чем сверяется результат. Порог срабатывания и строгость проверки настраиваются без правки кода.
• Схема прохождения документа — маршрут от загрузки черновика до выпуска: извлечение данных, проверка, согласование, подпись. На схеме отмечены точки, где подключается человек и какие данные он видит.
• Регламент обработки исключений — что делать, когда поле не распознано или условия конфликтуют: очередь, ответственный, срок реакции, фиксация решения. Разобранный случай становится новым правилом, а не разовой правкой.
• Инструкции для сотрудников — роли, типовые сценарии, действия при расхождении с реестром контрагентов. Написаны так, чтобы новый человек выходил на самостоятельную работу без сопровождения.
• Журнал решений и метрики — доля документов, прошедших без ручной правки, время цикла, топ причин отклонений. По ним видно, где узкое место и стоит ли расширять автоматизацию.
• Порядок обновления комплекта — кто согласует новую редакцию шаблона или правила, как проверить изменение на исторических документах и как откатиться к предыдущей версии.

Обсудим вашу задачу — вернёмся с оценкой и планом.

Кейс: подготовка договоров до и после внедрения

До внедрения пакет договоров собирали вручную: тексты жили в копиях-файлах, и каждая правка раскатывалась по ним отдельно. На пакет из 60 документов уходило 3-4 рабочих дня, а в конце квартала, когда заявок приходило вдвое больше, очередь растягивалась до недели.

Что показывали замеры до

• Возвраты на доработку: около трети шаблонов уходило на второй круг — расхождения в реквизитах и разъехавшиеся формулировки.
• Пиковая нагрузка: конец месяца отдел закрывал переработками, до 40% времени уходило на сверку копий, а не на правовую работу.
• Единой точки правок не было: изменение пункта требовало ручной синхронизации по всему набору документов.

Что изменили и что это дало

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

Сборка пакета занимает 3-4 часа вместо 3-4 дней. Возвраты на доработку упали с трети до 8%: расхождение в шаблонах больше не возникает — правка вносится в одном месте и наследуется всеми. Пиковую нагрузку отдел проходит без переработок, очередь растёт линейно.

Пропускная способность выросла примерно втрое на том же составе, а высвобожденное время ушло на согласование нестандартных условий.

Чем отличается сборка по шаблону от работы модели?

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

Модель работает иначе: AI-генерация документов строит формулировки под контекст и вытягивает смысл из неструктурированных мест. Это единственный способ закрыть документы, которые не сводятся к фиксированным полям, но у гибкости есть цена — результат проверяет человек, и объём правок зависит от типа документа.

Стоимость контроля качества — главный критерий выбора. Там, где формулировка должна совпадать буквально (реквизиты, даты, предмет договора), сборка по шаблону дешевле: проверяют данные, а не текст. Там, где важен язык и адаптация под ситуацию, проверка человеком неизбежна — её объём закладывают заранее, выборочно или по порогам уверенности.

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

Частые сомнения: точность, проверка и объём документов

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

Формулировки не начнут «плавать» от документа к документу?

Текст собирается не свободным пересказом модели, а по утверждённому шаблону с фиксированной структурой и словарём формулировок. Шаблон версионируется, версия фиксируется в карточке документа — по любой сделке видно, из какой редакции собран текст.

Кто видит черновики и как разграничен доступ?

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

Кто отвечает за выпущенный документ?

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

Обсудим задачу: что нужно для оценки сроков

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

• Образцы документов — 10-15 реальных файлов по каждому типу: с вариантами формулировок, приложениями, сносками и ручными правками менеджеров. По ним видно, где шаблон держит форму, а где нужна генерация текста.
• Карта шаблонов — какие документы выпускаются, какие поля подставляются автоматически, а какие заполняет человек, и что происходит при нестандартных условиях сделки.
• Источники данных — откуда приходят значения полей (учётная система, реестр, почта), в каком виде и кто отвечает за их актуальность.
• Требования к контуру — где разрешено обрабатывать документы, нужен ли изолированный контур, какие сведения не должны покидать вашу инфраструктуру.
• Роли и доступы — кто инициирует генерацию, кто согласует, кто подписывает и какие права нужны каждой роли.
• Объём и поток — сколько документов в месяц и как выглядит пик, чтобы оценить нагрузку и запас по скорости.
• Критерии приёмки — на каком наборе документов считаем результат корректным, кто проводит проверку и какая доля правок после генерации допустима.

Если часть материалов под рукой нет — опишите своими словами, остальное уточним в разговоре. После разбора вернёмся с планом работ и оценкой по этапам.