В компанию приходит счет в PDF. Сотрудник открывает письмо, находит поставщика, сумму, номер договора и срок оплаты, затем переносит данные в учетную систему и отправляет документ на согласование. Другая форма счета или нечеткий скан снова требуют ручной работы.
ИИ может взять на себя часть этого маршрута. Серверная система принимает файл, извлекает текст и структуру, определяет тип документа, находит нужные реквизиты, проверяет их по правилам и готовит запись для внутренней системы. Сотрудник подключается там, где результат требует подтверждения или документ выходит за известный сценарий.
Где работает ИИ
В корпоративном проекте ИИ для документов обычно работает как отдельный программный сервис или модуль информационной системы. У него есть входящий канал, очередь файлов, набор обработчиков, модель, правила проверки, журнал и интеграции. Пользователь может видеть только итоговую карточку документа, хотя на сервере проходит несколько последовательных этапов.
Источниками служат почта, папка обмена, сканер, личный кабинет, ЭДО, CRM, ERP или форма загрузки. Система получает сам файл и доступный контекст: отправителя, заказ, контрагента, тип процесса и права пользователя. Контекст помогает выбрать правильный сценарий обработки.
Такой модуль можно включить в систему электронного документооборота или связать с существующей архитектурой компании. СЭД управляет карточками, маршрутами, версиями и сроками. ИИ добавляет распознавание, классификацию, извлечение и смысловой анализ содержимого.
Чтение документа
Первый этап - перевод документа в данные, доступные для дальнейшей обработки. Для скана или фотографии используется оптическое распознавание текста, OCR. Система определяет символы, строки, абзацы, таблицы, поля формы и координаты элементов на странице.
Для электронного PDF текст иногда уже находится внутри файла. Однако одного извлечения символов мало. Нужно сохранить структуру: где заголовок, где таблица, какие значения образуют пару «поле - значение», к какой строке относится сумма и на какой странице продолжается раздел.
Качество исходника влияет на результат. Размытый кадр, перекос, тень, низкое разрешение, рукописная пометка и сложная таблица повышают риск ошибки. Поэтому система сохраняет уровень уверенности распознавания и может направить сомнительную страницу на проверку.
Тип и реквизиты
После чтения система определяет тип документа. Это может быть счет, договор, акт, заявка, письмо, накладная, технический паспорт или внутренний отчет. Классификация задает следующий обработчик и набор ожидаемых полей.
Из счета нужны поставщик, ИНН, номер, дата, сумма, НДС, договор и срок оплаты. Из договора - стороны, предмет, сумма, срок действия, порядок оплаты и условия расторжения. Из акта - период, состав работ, сумма и связь с договором. Состав полей проектируется под процесс компании.
Результат извлечения должен иметь структуру, пригодную для записи в базу: название поля, значение, страница, фрагмент источника и уверенность модели. Тогда сотрудник может открыть карточку и сразу увидеть, откуда взялось значение. Это особенно полезно при спорной сумме, дате или реквизите.
Документы с устойчивым шаблоном часто обрабатываются по разметке и правилам. Для меняющихся форм применяют модели понимания документов и языковые модели. В обоих случаях качество проверяют на реальном наборе файлов компании, включая неудобные и редкие варианты.
Проверка данных
Извлеченное значение еще не готово к автоматической записи. Сначала его сверяют с правилами и данными других систем. ИНН должен иметь допустимый формат, сумма по строкам должна сходиться с итогом, поставщик - находиться в справочнике, номер договора - относиться к этому контрагенту.
Проверки удобно разделять на три уровня:
- формат - дата, номер, валюта, обязательные поля и структура значения;
- связи - контрагент, договор, заказ, заявка, подразделение и ответственный;
- правила процесса - лимит, срок, дубликат, расхождение суммы и необходимость дополнительного согласования.
При высокой уверенности и успешных проверках система готовит карточку автоматически. Спорные поля выделяются для сотрудника. Такой маршрут сохраняет скорость на типовых документах и контроль там, где ошибка влияет на оплату, обязательства или учет.
Ручная проверка тоже дает данные для улучшения. Исправления показывают, какие формы распознаются хуже, какие поля названы неоднозначно и где требуется новый шаблон, правило или пример для модели.
Поиск и вопросы
Извлечение реквизитов отвечает на вопрос «какие данные находятся в документе». Для вопросов по содержанию нужен другой сценарий. Пользователь может попросить найти условия расторжения, сравнить две редакции, собрать обязательства сторон или показать документы по конкретному оборудованию.
Для поиска по внутренним материалам применяется RAG-система. Она индексирует документы и метаданные, находит подходящие фрагменты, передает их языковой модели и возвращает ответ с указанием источников. Документы остаются источником фактов, а модель формулирует связный ответ по найденному контексту.
Качество такого поиска зависит от структуры архива. Версии, даты, тип документа, владелец, проект и права доступа должны сохраняться вместе с текстом. Иначе система может смешать действующий договор с архивной редакцией или показать документ другого подразделения.
Сводка и сравнение тоже требуют проверяемости. Пользователь должен иметь возможность открыть страницу и фрагмент, на которых основан вывод. Для юридических, финансовых и технических материалов ссылка на источник часто важнее красивой формулировки ответа.
Действия в системах
После распознавания и анализа возникает практический вопрос: что делать с результатом. Система может создать черновик карточки счета, заполнить данные договора, поставить задачу, выбрать маршрут согласования, проверить статус заказа или подготовить ответ на входящее письмо.
Для связи ИИ-ассистента с внутренними системами подходит управляемый MCP-сервер. Он предоставляет модели только разрешенные инструменты: найти контрагента, проверить договор, создать черновик, получить статус или отправить документ на согласование. Сервер проверяет роль пользователя и записывает вызов в журнал.
Значимые операции подтверждаются человеком. Ассистент показывает, какие поля распознаны, что будет создано и в какой системе произойдет изменение. После подтверждения сервер выполняет действие и сохраняет результат. Такой порядок оставляет ответственность понятной.
MCP нужен для работы модели с функциями и данными. RAG нужен для поиска по содержанию документов. Извлечение реквизитов превращает файл в структурированную запись. Эти механизмы могут работать вместе, но решают разные задачи.
Четыре сценария
Практическую задачу удобно начинать с одного из четырех сценариев.
Ввод реквизитов
Система принимает однотипные документы, извлекает заданные поля, проверяет их и готовит запись для ERP, CRM или СЭД. Эффект измеряется временем обработки, долей автоматически заполненных полей и количеством исправлений.
Маршрутизация
Классификатор определяет тип, тему, подразделение и срочность документа. Затем система назначает маршрут, ответственного и срок. Этот сценарий полезен для входящих писем, заявок, претензий и комплектов документов.
Поиск и анализ
Сотрудники задают вопросы по договорам, инструкциям, отчетам и техническим материалам. Система ищет источники, готовит сводку и показывает подтверждающие фрагменты.
Подготовка действий
ИИ формирует черновик карточки, задачи, письма или заявки на основе документа. Пользователь проверяет результат и подтверждает передачу в рабочую систему.
Права и хранение
Документная система работает с коммерческими условиями, персональными данными, финансами и технической информацией. Права нужно применять на каждом этапе: при получении файла, извлечении данных, поиске, показе ответа и выполнении действия.
Файл, распознанный текст, структурированные поля и индекс могут храниться на серверах компании или в выбранной инфраструктуре в России. Архитектура зависит от требований к данным, используемых моделей и интеграций. Для чувствительных сценариев применяют локальные компоненты и маскирование отдельных полей.
В журнале сохраняются источник документа, версия обработчика, извлеченные значения, исправления, пользователь, запрос к модели и выполненное действие. По журналу можно восстановить путь результата и понять причину ошибки.
Как начать проект
Начало проекта - один тип документов и один полезный результат. Например, счета поставщиков с подготовкой карточки на согласование. Для выбранного процесса собирают реальные файлы, определяют обязательные поля, правила проверки, допустимые ошибки и роли сотрудников.
Дальше готовится эталонный набор: документ, правильная классификация, ожидаемые поля и решение по каждому спорному случаю. На нем сравнивают качество распознавания и извлечения. Отдельно проверяют плохие сканы, новые формы, многостраничные файлы, таблицы и документы с пропущенными реквизитами.
После пилота модуль связывают с действующей системой. Для специальных маршрутов, локального размещения и нестандартных интеграций может потребоваться разработка программного обеспечения под архитектуру компании. Затем сценарий расширяют на новые типы документов и действия.
Практический результат
Полезная система обработки документов дает проверяемый результат: файл получил тип, реквизиты попали в карточку, сомнительные поля отмечены, источник сохранен, права соблюдены, а следующий шаг подготовлен в нужной системе.
Обсуждение задачи стоит начинать с одного документа и его текущего пути. Кто получает файл, какие данные переносит, что проверяет, где принимает решение и куда записывает результат. Эта последовательность показывает, где нужен OCR, где классификатор, где RAG, где MCP-инструмент и где остается подтверждение сотрудника.