Как применять ИИ в документообороте без утечек — OCR, извлечение реквизитов, проверка, поиск и RAG для договоров, актов и сканов.
Договоры, акты, сканы писем и техническая документация редко лежат в одном понятном виде. Часть файлов приходит в PDF, часть — в виде сканов с печатями, таблицами и рукописными пометками. В договоре важен срок и порядок расторжения, в акте — реквизиты и позиции, в технической документации — версия, изменение и ссылка на исходную спецификацию.
ИИ здесь полезен, когда помогает превратить поток файлов в проверяемые данные. Распознать текст, найти нужный пункт, собрать реквизиты в таблицу, показать отличия между версиями, ответить по действующему регламенту со ссылкой на страницу документа. Но результат не появляется после загрузки папки в чат. Нужен процесс, в котором исходный файл, извлечённые поля, права доступа и ручная проверка связаны между собой.
Под «без утечек» стоит понимать управляемый маршрут данных, а не обещание абсолютной безопасности. Границы обработки определяют владелец процесса, юристы и служба информационной безопасности. Технология должна работать внутри этих границ, оставлять след операций и давать человеку возможность проверить результат по первоисточнику.
Сначала разделите три разные задачи
Фраза «нужно внедрить ИИ для документов» обычно объединяет три задачи с разной стоимостью, архитектурой и уровнем риска.
| Задача | Что происходит | Где нужен человек |
|---|---|---|
| Разовый разбор файла | Нужно быстро выделить пункты договора, реквизиты акта или отличия двух редакций | Проверяет итог и принимает решение |
| Повторяемая обработка | Каждый день или месяц поступают документы одного типа с понятным результатом | Настраивает правила, разбирает исключения |
| База знаний компании | Сотрудники регулярно задают вопросы по большому массиву регламентов, инструкций и договоров | Контролирует источники, версии и доступ к ответам |
Разовый разбор подходит для предварительной работы. Например, юрист получает несколько договоров аренды и просит собрать в таблицу сроки, порядок расторжения, штрафы и ограничения доступа. ИИ может подготовить черновик сравнения. Юрист открывает исходные пункты, сверяет формулировки и принимает решение сам. Здесь не нужно строить сложную платформу. Нужны согласованный контур обработки, ясная постановка задачи и обязательная проверка.
Повторяемая обработка начинается там, где один и тот же тип документа приходит регулярно. Это могут быть акты, счета, входящие обращения, типовые договоры, протоколы совещаний, паспорта оборудования. Одной удачной подсказки для большой языковой модели здесь недостаточно. Понадобятся схема полей, правила проверки, перечень исключений, маршрут согласования и журнал исправлений. Промт постепенно становится частью регламента. В него добавляют реальные пограничные случаи, по которым эксперт уже принял решение.
Корпоративная база знаний нужна, когда сотрудники ежедневно ищут ответы в сотнях или тысячах документов. Например, инженер уточняет действующую редакцию инструкции, служба поддержки ищет процедуру по коду ошибки, закупки проверяют условия типового договора. В этом случае появляется RAG — механизм, при котором модель сначала получает подходящие фрагменты из подготовленной базы, затем отвечает с опорой на них. Это тот самый умный библиотекарь, который сначала находит документ, а уже потом помогает с ответом.
RAG не нужен для каждого файла. Если задача сводится к извлечению десяти реквизитов из акта, надёжнее собрать структурированную запись, проверить её правилами и передать в нужную систему. Векторная база в таком процессе создаст лишний слой, который сложнее объяснять, поддерживать и аудировать.
Маршрут документа начинается раньше OCR
OCR переводит изображение в текст, но работа с документом начинается до распознавания. Сначала организация должна понимать, что именно попадает в обработку, кто отвечает за файл и куда можно передавать его содержимое.
Для каждого документа полезно завести карточку с идентификатором, источником поступления, типом, владельцем процесса, уровнем доступа, датой загрузки и контрольной суммой исходного файла. Контрольная сумма помогает доказать, что на проверку передавали именно тот файл, который затем использовали в работе. Если файл заменили, система должна создать новую версию, а не тихо перезаписать старую.
Отдельный шаг — классификация данных. Договор может содержать персональные данные, коммерческие условия, банковские реквизиты и сведения ограниченного доступа. Сканы технических паспортов могут включать серийные номера и схемы объектов. Передача таких документов во внешний сервис не должна становиться решением отдельного сотрудника в момент загрузки файла.
Персональные данные требуют отдельной оценки основания, цели, состава обрабатываемых сведений, состава получателей и допустимого контура. Общие требования к обработке закреплены в официальном тексте Федерального закона № 152-ФЗ. Практический вывод простой — юридическую и ИБ-оценку проводят до запуска потока, а не после первого инцидента.
Обезличивание может снизить риск, но не заменяет классификацию. Замена ФИО на «Сотрудник 1» полезна для учебного примера или теста промта. При этом сочетание должности, объекта, дат, сумм и редких обстоятельств иногда всё равно позволяет определить человека или контрагента. Таблицу соответствия псевдонимов и исходных значений нужно хранить отдельно, доступ к ней ограничивать, а необходимость такого хранения отдельно обосновывать.
OCR превращает страницу в материал для дальнейшей работы
У PDF бывают два принципиально разных состояния. В первом текст уже существует внутри файла и его можно извлечь напрямую. Во втором перед нами изображение страницы, иногда снятое на телефон, с перекосом, печатью, подписью и плохо читаемой таблицей. Во втором случае нужен OCR.
Хороший процесс распознавания сохраняет не только текст, но и связь текста с оригиналом. Для каждого извлечённого фрагмента полезно хранить номер страницы, координаты блока и ссылку на исходный файл. Тогда проверяющий не ищет пункт договора по всему документу. Он сразу видит страницу и место, откуда система взяла срок, сумму или реквизит.
Ошибки OCR редко выглядят драматично. Именно поэтому они опасны. Буква «О» превращается в ноль, «1» — в «I», запятая меняет сумму, знак минуса пропадает, номер приложения считывается с ошибкой. В технической документации ошибка в единице измерения или обозначении детали может быть существеннее, чем целый абзац обычного текста.
Поэтому качество проверяют по типам полей, а не по общему впечатлению. Для даты важно совпадение всех цифр. Для ИНН и номера договора — контроль длины и формата. Для таблицы спецификации — сохранность строк, столбцов, единиц измерения и итогов. Для юридического пункта — полнота формулировки и ссылка на страницу. Один усреднённый процент точности мало что говорит о пригодности результата для конкретного процесса.
В учебной задаче это выглядит так. В организацию поступает скан акта. OCR выделяет номер, дату, стороны, позиции и итоговую сумму. Система сверяет арифметику строк, формат реквизитов и наличие обязательных полей. Если сумма в строках не совпадает с итогом или текст около подписи читается плохо, акт попадает в очередь ручной проверки. Автоматизация не скрывает сомнение, а делает его видимым.
После OCR нужна структура, а не пересказ
Большая языковая модель хорошо работает с текстом, но документу обычно нужен предсказуемый набор полей. Если попросить модель проанализировать договор, она подготовит содержательный пересказ. Если нужен рабочий процесс, требуется более строгий формат результата.
Для договора схема может включать стороны, предмет, срок действия, пролонгацию, порядок оплаты, условия изменения, основания расторжения, ответственность и ссылки на страницы. Для акта важны номер, дата, договор-основание, перечень работ или поставки, сумма, НДС, подписи и расхождения с первичными данными. Для технической документации понадобятся обозначение, версия, дата введения, статус утверждения, применимость, перечень изменений и связи с дочерними документами.
Каждое извлечённое значение стоит хранить вместе с четырьмя признаками.
- Значением поля и его форматом.
- Фрагментом исходного документа и номером страницы.
- Оценкой уверенности системы.
- Статусом проверки человеком.
Такой результат удобнее передавать в систему электронного документооборота, ERP, CRM или внутреннюю базу. Он также позволяет понять, где именно процесс ошибается. Если модель регулярно путает дату подписания с датой составления, исправляют правило выбора поля. Если OCR плохо читает сканы с печатью, дорабатывают предобработку изображения или маршрут исключений.
Для повторяемых задач полезен подробный системный промт. В нём фиксируют роль исполнителя, тип документа, допустимые источники, формат ответа, стоп-условия и правила эскалации. Важная часть такого промта — примеры реальных пограничных случаев, уже разобранных сотрудником. Когда один раз выяснилось, что определённый пункт договора относится к одностороннему расторжению, это решение добавляют в правило обработки, а не держат в голове у одного человека.
Промт при этом не должен заменять регламент. Регламент отвечает на вопрос, кто принимает решение и какие действия разрешены. Промт помогает системе увидеть нужные признаки и вернуть результат в нужном формате.
Проверка должна быть встроена в процесс
Самая частая ошибка при внедрении — считать, что ручная проверка равна человеку, который время от времени читает готовые ответы. Такая схема плохо масштабируется. Проверка должна быть определена заранее.
Первый уровень — автоматические проверки. Это контроль обязательных полей, форматов, арифметики, дублей, соответствия справочникам, сроков действия и связей между документами. Для актов можно сверять сумму позиций с итогом. Для договоров — проверять наличие приложения, на которое ссылается основной текст. Для технической документации — искать несоответствие версии в карточке и титульном листе.
Второй уровень — смысловая проверка. Здесь модель может отметить потенциально важные отличия между редакциями, необычную оговорку, отсутствие стандартного раздела или противоречие между пунктами. Результат должен быть сформулирован как сигнал для эксперта, а не как окончательное юридическое заключение. Модель может сказать, что в редакции обнаружена формулировка с возможным влиянием на порядок расторжения и показать два фрагмента. Оценку правового риска даёт сотрудник, уполномоченный её дать.
Третий уровень — выборочная или обязательная ручная проверка по риску. Документы с финансовыми последствиями, персональными данными, юридическими обязательствами, безопасностью производства или внешней отправкой требуют более строгого маршрута. Для низкорисковых полей можно использовать выборочный контроль. Для критичных полей нужен просмотр первоисточника до применения результата.
Это соответствует общему подходу к управлению рисками ИИ. В профиле NIST AI RMF для генеративного ИИ отдельно рассматриваются роли, ответственность, документация рисков и человеческий контроль. Это не нормативный акт для российской организации, но хорошая методологическая рамка для проектирования процесса.
Проверяющему нужно показать оригинал, извлечённое значение и причину, по которой система просит вмешательство. Кнопки «подтвердить», «исправить» и «отклонить» должны возвращать обратную связь в правила обработки. Тогда ручная работа не исчезает в переписке, а постепенно делает поток точнее.
Версия документа важнее красивого ответа
Отдельно стоит описать запретные действия. Система не должна самостоятельно подписывать, отправлять или удалять юридически значимые документы, менять карточку контрагента, публиковать техническую редакцию или открывать доступ к архиву. Для таких операций нужен отдельный маршрут с полномочиями сотрудника, подтверждением и журналом действия. Даже если модель уверенно предлагает правильный вариант, уверенность в формулировке не подтверждает ни достоверность источника, ни полномочия на действие. Полезное правило для настройки процесса простое. Чем сложнее отменить последствия ошибки, тем раньше в маршруте появляется человек и тем подробнее фиксируется основание решения.
У документа может быть одинаковое название и несколько разных редакций. Спецификация меняется после уведомления об изменении. Регламент переиздаётся. Приложение к договору корректирует цену или объём работ. Если система отвечает по архивной версии как по действующей, точный пересказ превращается в ошибку.
Минимальный набор метаданных для версии включает идентификатор документа, номер редакции, дату действия, статус, владельца, связь с предыдущей редакцией и контрольную сумму файла. Если документ отменён, он не должен попадать в обычную выдачу как актуальный. Архив может остаться доступным для уполномоченных пользователей, но с явной маркировкой статуса.
Ответ системы по документам должен содержать источник. В идеале пользователь видит название файла, версию, дату, страницу и цитируемый фрагмент. Для таблицы извлечённых полей это означает ссылку на первичный документ. Для RAG-ответа — перечень фрагментов, на которых основан вывод.
Полезно хранить и историю исправлений. Если оператор поменял значение, система фиксирует, кто это сделал, когда и почему. При аудите можно восстановить путь от скана до записи в системе. Без этого невозможно отличить ошибку OCR, ошибку правила, ошибку модели и осознанное решение сотрудника.
Где достаточно поиска и где действительно нужен RAG
Полнотекстовый поиск решает много задач без большой языковой модели. Он быстро находит документы по номеру, названию, дате, контрагенту, коду оборудования или точной фразе. Если сотрудник знает, что ищет, качественного поиска с фильтрами по типу, версии и доступу часто достаточно.
RAG нужен, когда вопрос формулируется человеческим языком и ответ приходится собирать из нескольких документов. Например, инженер ищет действующий порядок согласования изменений для конкретного типа оборудования. Или сотрудник поддержки хочет понять, какие действия описаны в нескольких регламентах и какая редакция имеет приоритет.
RAG оправдан, если соблюдены четыре условия.
- База документов регулярно используется несколькими сотрудниками.
- Документы классифицированы, очищены от дублей и снабжены метаданными.
- Система умеет учитывать права доступа до выдачи фрагментов.
- Каждый ответ показывает источник, версию и цитату.
Если хотя бы один пункт отсутствует, сначала стоит наладить каталог документов и поиск. Векторная база не исправит хаос в названиях файлов, дубли, отменённые редакции и неясные права доступа.
RAG также не является защитой от вредоносного содержания в документах. Документ может содержать текст, который пытается повлиять на модель, например просит игнорировать правила или раскрыть данные. OWASP отмечает, что RAG повышает релевантность ответов, но сам по себе не устраняет риск prompt injection. Это описано в OWASP LLM01 2025. Поэтому документы из внешнего контура нужно помечать по происхождению, проверять до индексации, а права доступа и действия модели ограничивать независимо от содержимого найденного фрагмента.
Подробно о том, как устроены векторная база и подготовка источников, можно прочитать в материале «Как научить нейросеть отвечать по документам компании — что такое RAG». Эта статья продолжает тему с другой стороны — как применять RAG только после того, как документы стали управляемыми источниками.
Защита строится вокруг маршрута данных
Безопасность документооборота не сводится к выбору одной модели. Важно знать весь путь файла. Где хранится оригинал, какая система выполняет OCR, какой сервис видит извлечённый текст, где работает большая языковая модель, куда сохраняется результат, кто видит журналы операций и как удаляются временные копии.
В рабочем контуре разумно разделить доступы. Пользователь может иметь право загрузить документ своего отдела, но не видеть документы соседнего подразделения. Сервис распознавания получает доступ только к очереди обработки, а не ко всему файловому хранилищу. Поисковый индекс должен фильтровать документы по правам до передачи фрагментов модели. Учётная запись интеграции не должна иметь разрешение удалять оригиналы или менять права пользователей.
Это практическое применение принципа минимальных привилегий. В NIST SP 800-53 он описан как предоставление пользователю или процессу только тех полномочий, которые необходимы для выполнения задачи. Для документооборота принцип особенно важен, потому что ошибка в интеграции способна открыть доступ к целому архиву, а не к одному файлу.
Логирование тоже требует осторожности. Журнал должен помогать расследовать инциденты и находить ошибки процесса, но не становиться второй неконтролируемой копией документов. Обычно достаточно фиксировать идентификатор файла, время, пользователя, сервис, действие, результат, версию правил и код причины отказа. Полный текст договора в техническом логе почти никогда не нужен.
До запуска стоит отдельно ответить на несколько вопросов. Какие категории документов допускаются в пилоте. Можно ли использовать внешний контур. Нужна ли локальная обработка или изолированный сегмент. Кто утверждает изменения промтов и правил. Как долго хранятся временные файлы. Что происходит при ошибке, недоступности сервиса или подозрении на утечку. Ответы фиксируют в проектном регламенте, а не в памяти у разработчика.
Запускайте с одного понятного потока
Лучший первый проект — не оцифровать весь архив, а взять один повторяемый процесс с владельцем и измеримым результатом. Например, извлечение реквизитов и строк из актов, поиск различий в редакциях технической документации или подготовка карточек входящих договоров для первичной проверки.
Пилот можно пройти в четыре шага.
- Описать входной документ, ожидаемый результат, владельца процесса, допустимый контур и правила остановки.
- Собрать репрезентативную выборку с качественными файлами, плохими сканами, разными версиями, таблицами и заведомо сложными случаями.
- Настроить OCR, схему извлечения, автоматические проверки и экран для ручной сверки с первоисточником.
- Запустить поток ограниченно, измерять ошибки по типам полей, дорабатывать правила и только затем подключать новые виды документов.
Метрика пилота должна быть связана с процессом. Подходят доля документов, прошедших без ручной доработки, время проверки, число ошибок по критичным полям, процент документов без найденного источника, количество обращений к архивной версии. Метрика «модель отвечает хорошо» ничего не объясняет и не помогает выбрать следующий шаг.
Сложную базу знаний стоит строить после такого пилота. Когда у организации уже есть карточки документов, права доступа, история версий и понятный процесс проверки, RAG становится логичным продолжением. До этого он будет дорогой оболочкой вокруг неразобранной папки.
Итог
ИИ в документообороте полезен там, где его работа оставляет проверяемый след. Исходный файл остаётся первоисточником. OCR делает текст доступным для обработки. Структурное извлечение превращает текст в поля. Правила и человек ловят ошибки. Поиск и RAG подключаются к уже подготовленным, версионным и разграниченным данным.
Подобрать корпоративную программу по ИИ для работы с документами можно на основе ваших процессов, типов документов и ограничений ИБ. На занятии команда разбирает обезличенные примеры, определяет точки ручной проверки и собирает первую рабочую схему обработки.