Как автоматизировать согласование договора и не потерять версии

В «Как автоматизировать согласование договора и не потерять версии» меня меньше интересует процент распознавания сам по себе. Важнее, можно ли отделить уверенное поле от сомнительного и не провести ошибку дальше по учёту.

Файл «Договор_v12_финал_точнофинал.docx» — не шутка, а симптом. Обычно рядом существуют письмо юриста с оговорками, таблица финансового директора со сроками, комментарий контрагента в мессенджере и подписанный PDF, который никто не связал с исходной заявкой. Формально договор согласован. Фактически неизвестно, какая версия стала финальной и кто принял спорное условие.

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

Какой результат я считаю подтверждённым

Нужны четыре связанных контура. Первый хранит неизменяемые версии документа. Второй управляет статусами и маршрутами. Третий собирает комментарии и решения в привязке к конкретной версии и пункту. Четвёртый передаёт в учётную систему только документ с разрешённым финальным статусом.

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

Договор — это карточка, версии и решения

Здесь важнее не скорость, а проверяемость результата.

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

Эти уровни нельзя смешивать. Контрагент остаётся тем же, когда появляется новая редакция. Сумма может измениться только в версии. Виза руководителя относится к редакции и набору условий, которые он видел в момент решения. Такое разделение позволяет доказать путь документа без восстановления истории по почтовым цепочкам.

Минимальный набор данных для версии:

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

Статусы должны описывать состояние, а не настроение

Статус «на согласовании» почти бесполезен: он не говорит, у кого документ, что ожидается и можно ли редактировать файл. Рабочая модель разбивает путь на проверяемые состояния с разрешёнными переходами.

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

Как работать с версиями и комментариями

Комментарии следует привязывать к версии и, по возможности, к конкретному пункту. Формулировка «не согласовано» создаёт новую переписку; формулировка «пункт 4.2: заменить срок оплаты 60 дней на 30, владелец — финансовый директор» создаёт задачу. После загрузки новой редакции система показывает, какие замечания закрыты, какие остались и какие пункты изменились без связанного замечания.

Я бы здесь первым делом спросил: чем подтверждено это значение?

Сравнение версий должно различать технические и смысловые изменения. Перенос строки не требует повторной визы, а замена суммы, ответственности, срока или предмета — требует. Правила существенности зависят от типа договора. Для аренды важны одни поля, для поставки — другие, для обработки персональных данных — третьи.

AI полезен в трёх местах:

1. извлечь реквизиты и показать оператору фрагмент, откуда взято значение;
2. сопоставить пункты двух редакций и подготовить краткий список изменений;
3. найти отклонения от утверждённого шаблона или библиотеки оговорок.

Результат AI остаётся гипотезой. Сомнительное поле получает уровень уверенности и отправляется на точечную проверку. Модель не должна самостоятельно объявлять условие юридически безопасным или переносить визы на новую редакцию.

Владельцы, дедлайны и уведомления

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

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

Уведомление должно содержать действие, срок и ссылку на текущую версию. Сообщение «договор требует внимания» не помогает. Лучше: «До 16:00 проверьте изменение пункта 5.3 в версии 7; сумма ответственности выросла с 300 000 до 900 000 рублей».

Что связывает документ с учётной системой

Входом может быть заявка из CRM, портала или 1С. Оркестратор создаёт карточку и выдаёт договору постоянный идентификатор. Файл уходит в версионное хранилище, а не в произвольную папку. Сервис Document AI извлекает поля и координаты фрагментов. Правила проверяют комплектность и определяют маршрут. Workflow-движок управляет статусами, задачами, сроками и решениями.

Учётная система получает только проверенные данные. Для интеграции с 1С используют опубликованный контракт обмена — например, HTTP-сервис или REST-интерфейс, которые описаны в официальной документации платформы. Повторный запрос с тем же ключом не должен создавать второй договор или вторую запись. Если 1С временно недоступна, состояние остаётся «ожидает передачи», а не ошибочно меняется на «передан».

Журнал аудита фиксирует:

• кто создал и изменил карточку;
• какая версия файла была открыта при решении;
• какие значения извлёк AI и что исправил человек;
• какое правило определило маршрут;
• кто согласовал каждое исключение;
• что и когда передано во внешнюю систему.

Распознавание документа не равно бизнес-проверке

Google Document AI, Amazon Textract и Azure AI Document Intelligence умеют извлекать текст, таблицы и поля. Но распознанное число ещё не стало достоверным условием договора.

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

Чему учит кейс SanctifAI

В кейсе SanctifAI human-in-the-loop вынесен в отдельный этап автоматизированного процесса: задача получает исполнителя, решение возвращается в workflow и влияет на дальнейший маршрут. Для договоров это важнее конкретной платформы.

Подтверждение нельзя оставлять сообщением «посмотрите документ» в чате. Оно должно быть состоянием с объектом проверки, версией, исполнителем, сроком и результатом. Тогда процесс не теряет решение и может доказать, почему документ пошёл дальше.

Типовые сбои и безопасное восстановление

Виза относится к старой версии. После любого существенного изменения система сбрасывает затронутые согласования и показывает, что именно требуется проверить повторно.

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

AI неверно извлёк сумму или дату. Поле не проходит детерминированную проверку и попадает оператору вместе с исходным фрагментом. Низкая уверенность не блокирует весь договор, если можно проверить только одно поле.

Задача зависла у отсутствующего сотрудника. Таблица замещения и эскалация меняют исполнителя с сохранением истории. Простое письмо руководителю не считается передачей задачи.

Подписанный файл не совпадает с согласованным. Перед архивированием сравнивают контрольную сумму и ключевые условия. Несовпадение переводит договор в исключение.

Внешняя система не приняла запись. Ошибка интеграции сохраняется отдельно от статуса договора. Повторная передача использует тот же идемпотентный ключ.

Метрики процесса, а не количество уведомлений

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

План внедрения

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

Где обычно не хватает основания

Можно ли согласовывать договор в электронной почте?

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

Нужно ли хранить все версии?

Да, если версия участвовала в согласовании или была передана контрагенту. Технические промежуточные сохранения можно обрабатывать отдельно, но нельзя перезаписывать проверяемую редакцию.

Может ли AI самостоятельно согласовать типовой договор?

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

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

Переносить их в карточку как структурированное замечание с автором, пунктом и сроком. Иначе комментарий останется вне версии и не попадёт в проверку закрытия.

Что считать успешным пилотом?

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

Я бы завершил «Как автоматизировать согласование договора и не потерять версии» контрольной проверкой: источник виден, сомнительные поля выделены, статус понятен, а непроверенные данные не ушли дальше. Тогда процесс можно считать управляемым.

Источники и пределы вывода

Технические возможности извлечения документов сверены с документацией Google Cloud, AWS и Microsoft. Возможности интеграции — с официальными материалами платформы 1С:Предприятие. Подход к контролю AI-рисков сопоставлен с NIST AI RMF. Конкретные юридические полномочия, сроки хранения и виды электронной подписи определяются регламентами компании и применимым законодательством; статья не заменяет юридическую консультацию.