Автоматизация документооборота: что LLM реально закрывает

Почему сейчас — не хайп, а рабочий момент

По данным СберАналитика и ComNews (январь 2026), 39% российских компаний уже применяют ИИ-агентов в бизнес-процессах. Документооборот занимает первое место по частоте автоматизации — 70% внедрений. Это не случайно: документы — самый унифицированный тип корпоративных данных, и именно здесь LLM даёт измеримый эффект быстрее всего.

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

Карта зрелости: четыре задачи, честная оценка

Ниже — сводная таблица по четырём задачам документооборота. Уровень зрелости оценивается по шкале TRL (Technology Readiness Level), адаптированной для production-применения в РФ.

Главный вывод: не существует «LLM для документооборота» — существуют четыре разные задачи с разными архитектурами и разным уровнем допустимого риска.

Где LLM пока врёт: честный раздел

Это то, что редко пишут вендоры, но именно это определяет, выйдет ли пилот в прод.

Сверка числовых реквизитов. Даже топовые модели (GPT-4o, Claude 3.5, GigaChat Pro) допускают ошибки в числах при длинном контексте. Hallucination rate на реквизитах в production — 3–8% по данным Zylos Research (2026). Для договора на 50 млн ₽ это неприемлемо без дополнительного контроля.

Нетиповые договоры. LLM обучена на типовых паттернах. Договор с нестандартными условиями — например, каскадная система штрафов или условие о форс-мажоре с отсылкой к приложению №7 — с высокой вероятностью будет интерпретирован неверно или пропущен. Контур.Фокус фиксирует этот паттерн как системный.

Рукописные и смешанные документы. LLM работает с текстом. Без качественного OCR-слоя (Azure Document Intelligence, AWS Textract, или российские аналоги) качество деградирует до неприемлемого уровня. Пилотировать на сканах низкого разрешения — гарантированный провал.

Таблицы со сложной структурой. Объединённые ячейки, многоуровневые заголовки, перекрёстные ссылки между таблицами — стандартная проблема для спецификаций и смет. Здесь нужен специализированный Document AI (LlamaParse, Azure Form Recognizer), а не чистый LLM.

Матрица выбора контура для РФ

Ключевой вопрос перед любым пилотом: куда идут данные?

С 2025 года оборотная ответственность по 152-ФЗ составляет до 500 млн ₽ за повторное нарушение при трансграничной передаче ПДн. Это не абстрактный риск — это операционный вопрос для CFO и юридического департамента перед подписанием любого договора с LLM-провайдером.

Три контура на практике:

• Зарубежный API (OpenAI, Anthropic, Google) — быстро, дёшево, но только для документов без ПДн физлиц
• Российское облако (GigaChat API, YandexGPT) — соответствует 152-ФЗ без дополнительных мер, хуже справляется с нестандартными юридическими конструкциями
• On-prem open-weight (DeepSeek V3/R1, Mistral, LLaMA) — максимальная безопасность, высокий TCO на GPU, возможность файн-тюнинга на корпоративных шаблонах

Кейс: сверка договоров в телекоме

Телеком-оператор федерального уровня обрабатывал около 2 400 агентских договоров в месяц. Каждый договор проходил ручную сверку с типовой формой: юрист тратил в среднем 22 минуты на документ.

Архитектура: Azure Document Intelligence для извлечения структуры → детерминированная сверка ключевых полей (реквизиты, сроки, суммы) → LLM (GigaChat Pro, on-prem контур) для семантического анализа отклонений от типовой формы → флаг для юриста при обнаружении нестандартных условий.

Результаты через 3 месяца:

• Straight-through processing rate: 67% договоров прошли без ручного вмешательства (только типовые, без отклонений)
• Время обработки одного документа: с 22 минут до 4 минут в среднем (p95 — 11 минут для сложных случаев)
• Hallucination rate на eval-наборе из 200 документов: 2,1% на числовых полях — все случаи перехватывались детерминированным слоем
• Acceptance rate: 81% рекомендаций LLM по классификации отклонений приняты юристом без правок
• Стоимость одного документа снизилась на 58% с учётом TCO (токены + инфраструктура + поддержка промптов)

Ключевое решение, которое сделало пилот успешным: не заменять юриста, а убрать рутину. LLM флагирует отклонения, юрист принимает решение по флагам.

Чеклист: готов ли ваш процесс к LLM

Прежде чем запускать пилот, ответьте на эти вопросы:

• Объём: не менее 500 документов в месяц одного типа — иначе автоматизация не окупается
• Типизация: документы одного класса составляют не менее 70% потока — LLM деградирует на зоопарке форматов
• Качество входных данных: документы в цифровом виде или качественные сканы (300+ dpi) — без OCR-слоя пилот провалится
• Eval-набор: есть ли 100–200 размеченных документов с правильными ответами — без них нельзя измерить точность
• ПДн: определено ли, какие документы содержат персональные данные физлиц — это определяет выбор контура
• Интеграция: есть ли API или коннектор к вашей СЭД (Directum, ELMA365, Docsvision) или ERP (1С) — без этого результат останется в Jupyter Notebook
• Требования к точности: определён ли допустимый процент ошибок — для финансовых реквизитов это 0,1%, для классификации входящих — 3–5%
• Human-in-the-loop: есть ли процесс для случаев, когда LLM не уверена — без него автоматизация создаёт риски, а не снимает их
• Ответственный за промпты: кто будет поддерживать и обновлять промпты при изменении шаблонов документов
• Бюджет на eval-инфраструктуру: заложены ли ресурсы на разметку, тестирование и мониторинг в production

Если на 4 и более вопросов ответ «нет» — начните с подготовки данных, а не с выбора модели.

Антипаттерны: топ-5 ошибок

1. Запуск без eval-набора. Нет размеченных эталонов → нет измерения точности → нет доказательства ROI. Пилот выглядит как демо, а не как бизнес-кейс. Это причина №1, по которой проекты не получают бюджет на масштабирование.

2. ПДн в зарубежный API без маскировки. Договор с ФИО и паспортными данными контрагента-физлица, отправленный в ChatGPT или Claude — это трансграничная передача ПДн. С 2025 года штрафы по 152-ФЗ достигают 500 млн ₽. ИБ-служба должна быть в контуре принятия решений с первого дня.

3. LLM вместо юриста на финальной сверке. Галлюцинации на числах и датах — не баг конкретной модели, а системное свойство архитектуры трансформеров. Использовать LLM как единственного проверяющего на договорах с финансовыми обязательствами — значит принять на себя риск, который не покрывается никаким SLA провайдера.

4. Пилот на нетиповых документах. Рукописные акты, смешанные форматы, документы с низким качеством сканирования — худший выбор для первого пилота. Начинайте с самого типового и высокочастотного класса документов.

5. Игнорирование интеграционного барьера. По опыту внедрений в РФ, большинство пилотов не выходят в прод именно из-за отсутствия согласованного коннектора к 1С или СЭД. Это нужно решать параллельно с разработкой LLM-логики, а не после.

Метрики пилота: что измерять

Договоритесь о метриках до старта — иначе оценка результата будет субъективной:

• Straight-through processing rate (STP) — доля документов, прошедших без ручного вмешательства. Целевой показатель для типовых документов: 60–75% через 3 месяца
• Время обработки — среднее и p95 до и после. Фиксируйте оба значения: среднее скрывает хвостовые случаи
• Hallucination rate на eval-наборе — процент фактических ошибок в извлечённых полях. Порог для финансовых реквизитов: не выше 0,5%
• Acceptance rate — доля рекомендаций LLM, принятых сотрудником без правок. Ниже 70% — сигнал проблемы с качеством промптов или eval
• Стоимость одного документа — (токены × цена + инфраструктура + поддержка) / количество документов. Сравнивайте с текущей стоимостью ручной обработки
• Compliance-статус — доля документов, обработанных без передачи ПДн за периметр. Должна быть 100% для документов с персональными данными

Архитектурный выбор: когда что применять

Не существует универсальной архитектуры. Выбор зависит от задачи:

• Pure LLM — только для задач, где ошибка не критична: черновая классификация, генерация шаблонных писем, суммаризация для внутреннего использования
• OCR + LLM — базовая архитектура для извлечения из сканов и PDF. OCR даёт качественный текст, LLM — понимание контекста
• RAG + LLM — для генерации по корпоративным шаблонам и ответов на вопросы по базе регламентов. Снижает галлюцинации за счёт заземления на реальные документы
• Гибрид ML + правила + LLM — для сверки и высокоточного извлечения. Детерминированные правила перехватывают числовые ошибки LLM, ML-модель обрабатывает структуру, LLM анализирует семантику отклонений

Выбор «pure LLM» для задач высокоточного извлечения реквизитов — самая дорогостоящая ошибка архитектурного уровня.

Что делать прямо сейчас

Если вы дочитали до этого места и узнали свою ситуацию — вот практический порядок действий:

1. Выберите один класс документов с объёмом от 500 в месяц и минимальной вариативностью форматов
2. Разметьте 150–200 документов как eval-набор — это фундамент любого измеримого пилота
3. Определите, есть ли ПДн физлиц, и выберите контур размещения модели до написания первой строки кода
4. Согласуйте интеграцию с СЭД/ERP с ИТ и ИБ параллельно с разработкой LLM-логики
5. Зафиксируйте метрики успеха и порог для масштабирования до старта — это защищает и вас, и проект

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

Связанные материалы в блоге brezatech: статья о выборе архитектуры RAG для корпоративных баз знаний, разбор метрик BI-дашбордов для операционных процессов, гайд по интеграции LLM с 1С.