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

Юрист, сотрудник договорного отдела или операционист обрабатывает постоянный поток типовых документов. Он сверяет договоры с шаблоном фирмы и требованиями законодательства, извлекает поля для учетной системы, проверяет реквизиты контрагентов по государственным реестрам (например по единому государственному реестру юридических лиц, ЕГРЮЛ). При потоке от 200 документов в месяц на эту работу уходит, по нашей оценке, 30-60% рабочего времени специалиста.

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

Классическая система электронного документооборота обычно хранит документы и ведет согласование, а извлечение данных остается ручным. Поля из договора или накладной в учетную систему по-прежнему переносит человек. Некоторые современные системы документооборота добавляют модули извлечения данных (кейс российского разработчика систем документооборота Directum в разделе о публичных кейсах ниже), но такой модуль обычно привязан к системе документооборота своего вендора. Мы строим извлечение данных поверх распространенных систем документооборота, которые уже стоят у заказчиков, поэтому заказчику не нужно менять систему или ждать, пока модуль появится у его вендора.

Мы решили сфокусироваться на восьми отраслях с устоявшимися операционными процессами и большим документопотоком. Это банки, страхование, профессиональные услуги, ритейл, поставщики облачного ПО для бизнеса (B2B SaaS), логистика, девелопмент и пищевая промышленность. На этой странице мы разбираем пять направлений в четырех из них - в страховании, логистике, девелопменте и профессиональных услугах. В профессиональных услугах направления два. Первое - работа с договорами и нормативной базой в юридических и аудиторских фирмах. Второе - анализ финансовой отчетности клиентов в аудите. Обработка документов здесь дает измеримый результат уже на пилоте (время обработки и точность извлечения полей). Задачи банков, ритейла, B2B SaaS и пищевой промышленности разбираем на диагностике. По каждому направлению ниже мы описываем сам документопоток, а подробный разбор с отраслевыми деталями вынесен на страницу отрасли со ссылкой рядом.

Договоры и внутренняя нормативная база в профессиональных услугах

Основная работа здесь - это поток по клиентским договорам. Он сверяет договоры с шаблоном фирмы и требованиями законодательства и извлекает поля для учетной системы. Этот поток дает измеримый результат по времени обработки договора и точности извлечения полей. Ограничение здесь в размещении клиентских данных. Адвокатская и аудиторская тайна обычно исключают их обработку в публичном облаке (обычных облачных сервисах без аттестации по требованиям безопасности информации), поэтому под клиентские договоры нужен закрытый контур. У адвокатских фирм это серверы самой фирмы (on-premise), а у аудиторских мы допускаем также российское облако, прошедшее аттестацию по требованиям безопасности информации. Подходящий контур мы согласуем с фирмой на диагностике с учетом требований тайны. Вторая часть - это поиск по внутренней нормативной базе фирмы на LLM (подход RAG). Такой поиск не работает с клиентскими данными и не задевает ни адвокатскую, ни аудиторскую тайну, поэтому мы запускаем его стартовым шагом, пока согласованный контур готовится к работе (подготовка на стороне фирмы обычно занимает, по нашему опыту, несколько недель). Юрист или аудитор задает вопрос на естественном языке и получает ответ со ссылкой на конкретный пункт регламента или методики фирмы вместо ручного поиска по документам. Пилот по клиентским договорам начинается уже в готовом контуре, и на этом потоке мы замеряем время обработки и точность извлечения полей.

Как это направление устроено в профессиональных услугах, разобрано на странице ИИ для профессиональных услуг.

Пакеты документов страхователей

При оформлении полисов и урегулировании убытков страховщику приходят пакеты документов страхователей. Это паспорта, медицинские справки, извещения о ДТП и учредительные документы юридических лиц. Поток извлекает из них данные для оформления полиса или урегулирования убытков, сверяет их с данными заявления страхователя и проверяет комплектность пакета. Так оформление полиса и урегулирование убытков, как правило, не ждут ручного разбора пакета, а ошибок ввода становится меньше. Такие пакеты обычно содержат персональные данные физических лиц, поэтому обрабатываются и хранятся на серверах в России. Медицинские справки (например по добровольному медицинскому страхованию) вдобавок защищены врачебной тайной, поэтому их обработка целиком идет внутри ИТ-инфраструктуры страховщика.

Публичные кейсы и цифры по страхованию - на странице ИИ для страховых компаний.

Транспортные накладные и документы внешнеэкономической деятельности (ВЭД) в логистике

Логистической и экспедиторской компании транспортные накладные обычно приходят двумя путями. Бумажные накладные поступают сканами и фотографиями, а часть контрагентов передает электронные накладные. Поток извлекает поля накладной (отправитель, получатель, груз, вес, маршрут) и сверяет их с заказом в учетной системе. У компаний с ВЭД к накладным добавляются международные товарно-транспортные накладные (CMR) и инвойсы (счета на оплату поставки), поэтому для них поток также проверяет комплектность пакета документов ВЭД, классифицирует товар по коду товарной номенклатуры внешнеэкономической деятельности (ТНВЭД) и сверяет контрагентов с санкционными списками США и Евросоюза. Окончательное решение по коду ТНВЭД остается за декларантом заказчика (сотрудником, который подает таможенную декларацию). С 1 сентября 2026 года электронные транспортные накладные становятся обязательными (федеральный закон 140-ФЗ). Но извлечение данных нужно и после перехода. Часть документов приходит от контрагентов и из международных перевозок в прежних форматах, а данные электронных накладных все равно нужно сверять с заказом в учетной системе по бизнес-правилам.

Публичные кейсы, цифры масштаба документопотока и полная механика перехода на электронные накладные - на странице ИИ для логистических компаний.

Договоры долевого участия и договоры с подрядчиками в девелопменте

В девелопменте документный поток решает две задачи. Первая задача - это проверка договоров долевого участия (ДДУ) на соответствие закону о долевом строительстве (214-ФЗ) и требованиям банков, где открыты счета эскроу (на этих счетах деньги дольщиков хранятся до сдачи дома). LLM проходит договор по этим требованиям, помечает места возможных нарушений и сопровождает каждую пометку цитатой из договора, а окончательное решение по помеченным местам принимает юрист застройщика. Ошибка в таком договоре может обернуться возвратом договора из банка на доработку или задержкой регистрации сделки. Вторая задача - это извлечение полей из договоров с подрядчиками, чтобы сократить ручной ввод в учетную систему. Потребность в автоматизации обеих задач растет, когда увеличивается число ДДУ, когда застройщик переходит в другой банк со счетами эскроу и получает новые формы договоров или когда расширяется круг подрядчиков.

Публичные кейсы по девелопменту - на странице ИИ для девелоперов.

Финансовая отчетность клиентов в аудиторских фирмах

LLM извлекает показатели из комплекта отчетности проверяемой компании (клиента аудиторской фирмы), сравнивает их с прошлыми периодами, помечает отклонения и готовит черновик заключения, указывая источник каждого числа. Аудитор проверяет и подписывает заключение, потому что этого требуют закон об аудиторской деятельности (307-ФЗ) и стандарты аудита. Данные клиентов здесь защищены аудиторской тайной по тому же закону, поэтому обработка отчетности идет на серверах фирмы или в российском облаке, прошедшем аттестацию по требованиям безопасности информации.

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

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

1. Диагностика. Бесплатно. Разбираем задачу заказчика, данные (примеры реальных документов и выгрузки из учетной системы) и ограничения (по безопасности и контуру размещения данных, по интеграциям с информационными системами заказчика). Оцениваем документопоток по представленным примерам, затем выбираем вариант технического решения, который быстрее всего дает экономию (ее мы считаем в сэкономленных часах сотрудников).
2. Аудит документопотока перед пилотом. Оценку документопотока, которую диагностика дала на примерах, проверяем и уточняем уже на полном объеме документов заказчика. Смотрим, как на реальном потоке выглядят доля сканов, типовость структуры документов и покрытие документов бизнес-правилами. Так мы снимаем причину, из-за которой такие проекты на рынке, по нашим наблюдениям, часто проваливаются, а именно разработку технического решения без оценки реального потока. Прототип технического решения, настроенный только на представленных заказчиком примерах (обычно они чище реального потока), извлекает данные из реального потока с точностью, по нашим наблюдениям, около 65% и обычно оказывается бесполезным в работе.
3. Пилот. Идет от 8 до 14 недель, начинаем с одного-двух типов документов. Собираем работающий документный поток на ограниченном объеме документов и замеряем результат, сравнивая его с исходным значением метрики.
4. Внедрение и сопровождение. Выводим поток в продакшен, интегрируем с информационными системами заказчика, настраиваем контроль качества извлечения данных и подключаем новые типы документов и правила проверки. Масштабирование обсуждаем после того, как метрика пилота подтверждена.

Результат пилота отслеживаем по следующим показателям, а основную метрику пилота выбираем из этого набора на диагностике:

• Сокращение времени обработки одного документа. Ориентир - это планка в два-четыре раза из раздела о кейсах (примерно половина от лучшего результата среди внедрений).
• Доля документов, которые прошли обработку без ручного вмешательства.
• Точность извлечения полей, которые переносятся в учетную систему.

От заказчика для пилота нужно следующее:

• Специалист, который утвердит бизнес-правила проверки извлеченных данных и будет отвечать за актуальность этих правил. Без такого специалиста качество обработки обычно падает, как только меняются формы документов.
• Доступ к учетной системе через программный интерфейс (API), чтобы записывать извлеченные данные автоматически.
• Примеры документов каждого типа, на которых настраивается извлечение данных (на пилоте мы затем проверяем его уже на реальном потоке).