Коротко

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

Это не то же самое, что распознать текст. OCR может прочитать PDF. Агент должен понять, что именно нужно проверить и с чем сравнить. Для счёта это будут реквизиты, сумма, НДС, договор и дубль. Для договора — стороны, срок, оплата, приложение, рискованные пункты. Для акта — период, сумма, основание и соответствие договору.

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

Проверка документа начинается не с модели

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

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

В локальных компаниях добавляется ещё одна сложность: документ может прийти куда угодно. На почту. В WhatsApp. В Telegram. В Bitrix24. В папку на диске. Сканом, фото, Excel-файлом, архивом, пересланным сообщением. Поэтому агент должен не просто прочитать файл, а сохранить источник: откуда пришёл документ, кто прислал, когда, к какому контрагенту или задаче он относится.

Как выглядит рабочий pipeline

У проверки документов есть понятная последовательность. Её лучше проектировать как workflow, а не как чат.

1. Входящий документ. Файл попадает из почты, формы, папки, WhatsApp, Telegram, CRM, 1C или внутреннего портала. Агент сохраняет оригинал и метаданные: отправитель, канал, дата, связанная задача или контрагент.

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

3. Извлечение полей. Агент вытаскивает структуру: БИН/ИИН, наименование, реквизиты, сумма, валюта, НДС, дата, номер, период, договор, позиции, подписи, приложения, условия оплаты. Для договоров — срок, стороны, ответственность, расторжение, автопродление, подсудность, конфиденциальность, лимиты и нестандартные пункты.

4. Сравнение с источниками. Поля сверяются с 1C, реестром договоров, справочником контрагентов, правилами согласования, шаблонами юристов, банковской выпиской, CRM или папкой проекта. Там, где можно, проверка должна быть детерминированной: сумма совпала или нет, БИН совпал или нет, договор найден или нет.

5. Флаги риска. Агент не пишет «есть потенциальные проблемы». Он пишет конкретно: реквизиты отличаются от карточки контрагента; сумма акта выше договора; нет подписи; номер договора не найден; НДС указан странно; приложение отсутствует; банковский счёт новый; акт уже встречался; период закрыт.

6. Заметка для человека. Итог должен быть коротким. Что нормально, что не нормально, где источник, какое решение нужно. Если человек вынужден перечитывать весь документ заново, агент не сэкономил время.

7. Лог решения. Ответственный утверждает, исправляет, отклоняет или просит уточнение. Система сохраняет исходный документ, извлечённые поля, флаги, правки человека и финальное решение.

Это уже не чат-бот. Это AI-агент, встроенный в workflow: он работает с документом, состоянием, источниками и задачей.

Что агент может проверять

Для счетов и актов: БИН/ИИН, реквизиты, сумму, валюту, НДС, номер и дату, период, номер договора, дубли, подписи, приложение, соответствие позициям договора, превышение лимита, правильного согласующего.

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

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

Для HR-документов: ФИО, ИИН, должность, филиал, дата выхода, согласия, обязательные формы, соответствие вакансии и статусу кандидата. Финальное решение остаётся у HR.

Для логистики и склада: накладные, акты расхождений, фото повреждений, заявки на поставку, вес, количество, адрес, время доставки, номер заказа, совпадение с WMS или 1C.

Где нужны локальные правила

В западных статьях часто пишут про ERP, CLM и enterprise document management. У нас процесс чаще выглядит иначе: 1C, Excel, Bitrix24, почта, WhatsApp, Telegram, папки, согласование голосом и «скиньте акт ещё раз, я потерял». Это не хорошо и не плохо. Это реальность, под которую нужно проектировать.

Если документ пришёл в WhatsApp, агент должен сохранить его в нормальное место и связать с задачей. Если согласование произошло в Telegram, надо решить, можно ли считать это подтверждением или нужно продублировать его в системе. Если договор лежит в нескольких версиях, агент должен знать, какая версия подписана. Если данные есть в 1C, а в Excel менеджера сумма другая, нужно определить источник истины.

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

Человек в контуре: где ставить стоп

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

Агент может создать задачу, подготовить заметку, проставить теги, запросить недостающий файл. Но если он хочет изменить карточку контрагента, отправить юридический ответ, подготовить платёж, отметить договор как согласованный или записать данные в 1C, нужен reviewer.

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

Для сложных workflows можно использовать подход из интеграции GPT в рабочие системы: права, роли, логи, отдельные действия на чтение и запись, подтверждение перед изменением данных.

Как тестировать качество

Тестировать надо не «понравился ли ответ», а конкретные поля и решения.

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

Проверяйте отдельно:

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

Это ровно тот случай, где нужны evals для AI-проектов. После изменения модели, prompt, OCR или схемы прогоняйте тот же набор заново. Иначе можно улучшить красивые ответы и сломать проверку реквизитов.

Частые ошибки

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

Вторая ошибка — не различать обязательные и желательные поля. Отсутствие подписи и отсутствие комментария менеджера — разные риски. Агент должен понимать приоритет.

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

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

Пятая ошибка — запускать сразу все типы документов. Лучше один семейный процесс: счета и акты, договоры поставщиков, HR-пакеты или заявки на закупку. Когда он стабилен, расширяться.

С чего начать пилот

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

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

Третий вариант — пакет документов для согласования: закупка, подрядчик, новый поставщик, закрытие работ. Агент собирает все файлы в один обзор и показывает, чего не хватает.

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

FAQ

Может ли AI-агент проверять договоры?

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

Можно ли проверять документы из WhatsApp?

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

Нужно ли подключать 1C?

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

Что лучше для пилота: договоры или счета?

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

Как понять, что агент готов к production?

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

Итог

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

Начинать стоит с узкого процесса и реальных документов. Для первички и договоров — с AI для документов. Для сценариев, где нужно связать 1C, CRM, почту и чаты, — с интеграции GPT. Документы не терпят магии. Им нужна проверяемость.