Документы и ИИ: что автоматизируется уже сейчас, а где ИИ не нужен

Частая и дорогая ошибка в проектах «ИИ для документов» — распознавать то, что уже распознано. Электронный УПД из ЭДО — это XML-файл, в котором ИНН, суммы и строки уже лежат в своих полях. Его нужно разобрать и сверить, и никакая модель не сделает это точнее простого разбора. Языковая модель нужна там, где структуры нет: в сканах, фото, письмах и договорах. Но и там она занимает один шаг процесса, а вокруг него стоят проверки, которые от модели не зависят.

Сначала посмотрите, в каком виде приходят документы

С 1 апреля 2025 года электронные счета-фактуры и УПД составляются только по одному формату — версии 5.03 из приказа ФНС от 19.12.2023 № ЕД-7-26/970@ (откроется в новой вкладке). ИНН и КПП сторон, номер и дата, строки с количеством, ценой, ставкой и суммой НДС размечены в нём тегами. С 1 января 2026 года утратили силу (откроется в новой вкладке) и отдельные электронные форматы ТОРГ-12 и акта (приказы ФНС ММВ-7-10/551@ и 552@), так что формализованный поток сводится к УПД. Накладную и акт по-прежнему можно оформить на бумаге или неформализованным электронным документом, а детали обмена стоит сверить с условиями своего оператора ЭДО.

Электронных счетов-фактур уже большинство: по данным ФНС, их доля выросла с 9% в 2020 году до 64% в 2025-м. Для каждого такого документа задача — интеграция: забрать XML у оператора, разобрать, сверить с заказом и справочниками и создать документ в учёте. Это работа для скрипта и настройки обмена, то есть для автоматизации процессов, а не для ИИ.

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

Весь путь входящего документа выглядит так. Языковая модель занимает в нём один шаг из пяти, а главный шаг — проверки правилами.

1. Источникиз ЭДО — сразу разбор XML
2. Распознаваниесканы, фото, PDF
3. Проверки правилами (главный шаг)ИНН, счёт по БИК, суммы
4. Очередь человекусомнения, пропуски, выборка
5. Запись в 1Спосле подтверждения

Затем снова к первому шагу: ошибки — в эталонный набор

Настоящая боль — сопоставить названия поставщика с вашими

Даже идеальный XML не снимает главную ручную работу. В нём записано, как товар называет поставщик, а в вашей 1С он называется иначе. 1С-ЭДО умеет отражать входящий УПД в учёте автоматически, но если наименование не сопоставлено с вашей номенклатурой, документ ждёт в разделе «Сопоставить», пока человек не укажет соответствие. Соответствие запоминается отдельно по каждому поставщику, поэтому работа не кончается: новые поставщики и новые позиции приносят её снова.

Здесь модель уместна, но в роли подсказки. Допустим, поставщик пишет «Бумага офисная А4 80 г/м², 500 л.», а у вас позиция называется «Бумага А4, пачка». Поиск по совпадению слов такую пару находит плохо: общих слов мало. Модель смысловых векторов (эмбеддингов) сравнивает смысл, а не буквы, и поднимает нужную позицию в начало списка кандидатов. Система предлагает, человек подтверждает, 1С запоминает, и следующий УПД от этого поставщика пройдёт без вопросов.

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

Где ИИ действительно нужен

Модель нужна там, где у документа нет структуры и правило не сформулировать: сканы и фото с телефона, PDF без текстового слоя, письма, в которых заказ, претензия и вопрос о сроках написаны своими словами, и договоры.

Сортировка входящих — что это за документ, от кого он и кому его передать — по сути классификация, и здесь у моделей сильная сторона. В исследовании, опубликованном в PNAS в 2023 году (откроется в новой вкладке), ChatGPT (GPT-3.5) без дообучения и без примеров размечал 6 183 текста по темам и позициям в среднем примерно на 25 процентных пунктов точнее, чем исполнители с краудсорсинговой площадки, и примерно в 30 раз дешевле. Это сравнение с разовыми исполнителями, а не с вашим бухгалтером, поэтому точность на ваших письмах меряют на ваших письмах.

С договорами модель полезна как сверщик: сравнить присланный проект с вашим шаблоном и чек-листом, найти изменённый срок оплаты, новую неустойку, пропавший пункт о приёмке. Решение принимает юрист, а модель избавляет его от чтения двадцати страниц в поисках трёх отличий. Поиск по архиву договоров обычными словами («у каких поставщиков отсрочка больше 30 дней») — отдельная задача, о ней в статье о дообучении и поиске по документам.

Почему «точность 98%» ничего не обещает

Точность распознавания обычно называют для одного поля, а принимаете вы документ целиком. Ошибки складываются. Если в документе шесть ключевых полей — ИНН, КПП, номер, дата, сумма, расчётный счёт — и каждое извлекается верно в 98% случаев, документ без единой ошибки получится с вероятностью 0,98⁶ ≈ 88,6%. Это 114 документов с ошибкой на каждую тысячу. Даже при 99,5% на поле таких останется 30 из тысячи.

• 95% на поле735 шт.
• 98% на поле886 шт.
• 99% на поле941 шт.
• 99,5% на поле970 шт.

Расчёт: точность на одно поле в шестой степени × 1000. Поля: ИНН, КПП, номер, дата, сумма, расчётный счёт

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

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

Качество входа решает не меньше модели. Документация движка Tesseract прямо пишет, что он лучше всего работает на изображениях от 300 DPI (откроется в новой вкладке), а встроенная бинаризация плохо справляется с неравномерно тёмным фоном. Тень от руки на фото, съёмка под углом и печать поверх ИНН портят результат любой системы. Простое правило для своих сотрудников — сканировать, а не фотографировать, и в 300 DPI — нередко даёт больше, чем смена модели.

Проверки, которые не зависят от модели

У классического распознавания ошибка обычно заметна: в поле ИНН оказываются буквы или мусор. Модели, которые читают изображение целиком, ошибаются иначе. На бенчмарке KIE-HVQA (NeurIPS 2025) (откроется в новой вкладке) с повреждёнными удостоверениями и счетами мультимодальные модели там, где фрагмент не читается, опирались на языковые шаблоны и дописывали правдоподобный текст, вместо того чтобы признать, что его не видно. Такая ошибка выглядит как нормальный ИНН, на глаз её не поймать, а сама модель своей неуверенности не замечает.

Значит, каждое извлечённое поле проходит проверки, где ошибаться нечему — это арифметика и сверка:

• Контрольное число ИНН. У 10-значного ИНН организации первые девять цифр умножают на веса 2, 4, 10, 3, 5, 9, 4, 6, 8 и складывают. Сумму делят на 11, остаток — ещё раз на 10, и результат должен совпасть с десятой цифрой. Для ИНН 7707083893 сумма равна 267, остаток от деления на 11 — 3, последняя цифра — тоже 3. У 12-значного ИНН предпринимателя две контрольные цифры со своими весами.
• Ключ расчётного счёта. Девятая цифра счёта — контрольная, она считается вместе с БИК. Для счёта в банке к 20 цифрам слева дописывают последние три цифры БИК, 23 цифры умножают на веса 7, 1, 3 по кругу, и сумма произведений должна делиться на 10. Порядок расчёта ключа (откроется в новой вкладке) Банк России разъяснил ещё в 1996 году. Ошибка в любой одной цифре счёта или последних трёх цифрах БИК меняет сумму, и проверка её ловит.
• Сверка сторон. ИНН покупателя должен совпасть с вашим. Контрольное число не ловит перестановку поставщика и покупателя — оба ИНН корректны, — а это правило ловит сразу.
• Сверка со справочником. Контрагент есть в справочнике 1С, и его расчётный счёт совпадает с известным. Новый счёт у старого поставщика — повод показать документ человеку при любой уверенности распознавания: именно так подменяют реквизиты в поддельных счетах, и модель честно извлечёт поддельный номер.
• Арифметика. Сумма строк равна итогу, НДС соответствует ставке и базе. Считает код, а не модель.

Вторая причина держать модель в узких рамках — безопасность. Входящий документ написал посторонний человек, и всё, что в нём есть, попадает в запрос к модели. Greshake и соавторы (2023) (откроется в новой вкладке) показали на реальных приложениях, что инструкции, спрятанные в извлекаемых данных — веб-страницах, письмах, документах, — способны управлять поведением модели. В PDF с текстовым слоем это может быть белый текст на белом фоне: человек его не видит, а модель, которой передали текстовый слой, читает. Поэтому модель распознавания только возвращает поля по заданной схеме. У неё нет инструментов, она ничего не записывает и никому не отправляет, а её ответ проходит те же проверки, что и любые входные данные.

Очередь на проверку: три повода показать документ человеку

Человек смотрит не каждый документ, а только те, по которым есть повод. Поводов три:

1. Низкая уверенность. Движок распознавания пометил символы ключевого поля как сомнительные, или два независимых прочтения поля разошлись — например, текстовый слой PDF и ответ модели.
2. Поле не найдено или не прошло правило. Нет КПП у организации, не сошлось контрольное число, сумма строк не равна итогу, счёт поставщика не совпал со справочником.
3. Случайная выборка. Несколько процентов документов, которые прошли все проверки и были приняты автоматически.

Третий повод кажется лишним, но без него вы не знаете главного — сколько ошибок проходит незамеченными. Первые два ловят то, что система сама сочла подозрительным, а правдоподобная ошибка модели подозрений не вызывает. Допустим, при 1 000 документах в месяц вы смотрите 3% принятых — около 30 в месяц и около 90 за квартал. Если среди 90 случайных документов нет ни одной ошибки, реальная доля ошибок с 95-процентной уверенностью ниже 3,3% (правило трёх: 3 / 90). Чтобы так же уверенно сказать «меньше 1%», нужно 300 проверенных документов без единой ошибки. Найденная ошибка — повод разобраться, какая проверка её пропустила, и добавить новую.

Без случайной выборки вы знаете только о тех ошибках, которые система заметила сама.

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

Сколько это стоит и когда окупается

Плата за модель невелика. Допустим, распознанный текст страницы вместе с инструкцией занимает 1 700 токенов, а ответ в JSON — 300. По прайсам Yandex AI Studio (откроется в новой вкладке) и GigaChat API (откроется в новой вкладке) на октябрь 2026 года (с НДС) такая страница стоит около 1,6 ₽ в YandexGPT Pro 5.1, 1,0 ₽ в GigaChat Pro, 0,43 ₽ в открытой Qwen3.6 35B в Yandex AI Studio и 0,13 ₽ в GigaChat Lite. Распознавание печатного текста в Yandex Vision (откроется в новой вкладке) добавляет 0,13 ₽ за страницу, распознавание таблиц — 1,22 ₽. На одну и ту же страницу разные модели тратят разное число токенов, поэтому эти цифры показывают порядок, а не смету.

Для типовой первички есть готовый вариант без проекта — сервис «1С:Распознавание первичных документов» (откроется в новой вкладке). По рекомендованным ценам на октябрь 2026 года пакеты стоят от 600 ₽ за 100 страниц до 3 млн ₽ за миллион, то есть 3–6 ₽ за страницу без НДС, действуют 12 месяцев и приобретаются через партнёров 1С или портал 1С:ИТС. Если ваши документы — обычные счета и акты, а 1С уже стоит, начинать разумно с него. Своё решение оправдано, когда документы нетиповые, нужна своя логика проверок и маршрутов или документы разбирают не в 1С, а, например, в CRM.

Кроме цены выбор провайдера определяют данные. В счетах от ИП стоит ФИО предпринимателя, в договорах — подписанты, иногда паспортные данные. Это персональные данные, и при отправке документов в облачную модель нужно поручение обработки по ч. 3 ст. 6 152-ФЗ и условия, при которых провайдер не хранит запросы и не использует их для улучшения моделей. В Yandex AI Studio, например, данные запросов по умолчанию сохраняются, и логирование нужно отключать (откроется в новой вкладке) явно, заголовком в каждом запросе. Что ещё проверить у провайдера, разобрано в статье про ИИ через API.

Отсюда порядок действий. Сначала объём и минуты на документ, потом технология. Всё, что приходит через ЭДО, забирают разбором XML. Реквизиты и суммы проверяют формулами. Модель ставят только на сканы, письма и договоры, только вместе с очередью проверки и только после пилота на одном потоке документов, где минуты замерены до и после. Если на пилоте проверка занимает почти столько же, сколько ручной ввод, выгоды нет: это главный критерий из статьи о том, где ИИ окупается.