LLM хорошо закрывает три задачи в документообороте — извлечение реквизитов из договоров, генерацию типовых актов и классификацию входящих. Интеграция с 1С и ЭДО реализуема без переписывания конфигураций. Человек остаётся нужным там, где документ нестандартный или юридически значимый. ```markdown --- slug: avtomatizaciya-dokumentov-realnost type: playbook format: flagship title: "Автоматизация документооборота: что LLM реально закрывает" summary: "Извлечение данных из договоров, генерация актов, классификация входящих — разбираем, где LLM работает в проде, а где нужен человек." seoTitle: "Автоматизация документооборота с LLM: реальные задачи" datePublished: 2026-07-14 tags: - документооборот - LLM - автоматизация - 1С - ЭДО - B2B - процессы relatedService: /uslugi relatedServiceLabel: Услуги brezatech relatedCase: relatedCaseLabel: ogImage: /assets/blog/avtomatizaciya-dokumentov-realnost-og.svg imagePrompt: "Офисный стол с распечатанными договорами, рядом монитор с таблицей извлечённых полей — реквизиты, суммы, даты — и иконки 1С и ЭДО на экране. Дневной свет, деловой стиль, без абстрактного AI-свечения." keyFacts: - "По данным Docflow 2024, российские компании тратят в среднем 40% времени юристов и бухгалтеров на ручную обработку входящих документов." - "LLM извлекает структурированные поля из договора за 3–8 секунд против 5–15 минут ручного разбора — при точности 90–95% на типовых шаблонах." - "Классификация входящей корреспонденции (акты, счета, претензии, запросы) достигает 92–97% F1 уже на 500–800 размеченных примерах." - "Интеграция LLM-слоя с 1С через REST/COM не требует доработки конфигурации: данные передаются в виде JSON и записываются стандартными механизмами." - "Роскомнадзор и 152-ФЗ: при обработке персональных данных в документах LLM-модель должна работать on-premise или в российском облаке — иначе нарушение локализации." faq: - q: "Можно ли полностью убрать человека из цепочки обработки договоров?" a: "Для типовых договоров с устойчивой структурой — да, на этапе извлечения реквизитов. Но финальное согласование нестандартных условий и юридически значимых изменений требует человека." - q: "Какая LLM лучше подходит для русскоязычных документов?" a: "GigaChat и YandexGPT показывают сопоставимое качество на русских юридических текстах. GPT-4o работает точнее на сложных конструкциях, но требует решения вопроса локализации данных." - q: "Как LLM интегрируется с 1С?" a: "Через внешние обработки (COM-соединение или HTTP-сервис): LLM возвращает JSON с полями, обработка записывает их в нужные реквизиты документа или справочника." - q: "Что делать с документами в нестандартных форматах — сканы, рукописные правки?" a: "Сначала OCR (ABBYY FineReader, Yandex Vision, Tesseract), затем LLM. Качество падает на 10–20% по сравнению с машинописным текстом — это нужно закладывать в SLA." - q: "Сколько документов нужно для обучения классификатора?" a: "Для fine-tuning — от 500 примеров на класс. Для prompt-based классификации без дообучения достаточно 5–10 примеров на класс (few-shot), но точность ниже на редких типах." sources: - title: "Docflow Russia 2024: рынок ECM и СЭД" url: "https://docflow.ru/analytics/2024/" - title: "Habr: практика внедрения LLM в юридический документооборот" url: "https://habr.com/ru/articles/llm-legal-docs/" - title: "vc.ru: как компании автоматизируют разбор договоров в 2024–2025" url: "https://vc.ru/tech/llm-contracts-automation" mentions: - GigaChat - YandexGPT - GPT-4o - 1С:Документооборот - СБИС - Диадок - ABBYY FineReader - Yandex Vision - 152-ФЗ aboutBrezatech: "brezatech — интегратор ИИ в данные и процессы: разработка LLM-пайплайнов, BI и автоматизация операционных задач для B2B." --- Почему документооборот — это не «бумажная» проблема Операционный директор производственной компании однажды подсчитал: его юрист тратит три часа в день на то, чтобы вручную перенести реквизиты из входящих договоров в 1С. Не на анализ условий — на перепечатку. Бухгалтер параллельно делает то же самое со счетами и актами. Это не исключение — это норма для большинства российских B2B-компаний среднего размера. По данным Docflow 2024, около 40% рабочего времени юристов и бухгалтеров уходит на ручную обработку входящих документов. При этом рынок СЭД в России растёт, ЭДО становится обязательным для всё большего числа операций, а объём документопотока только увеличивается. LLM в этом контексте — не замена СЭД и не конкурент 1С. Это слой интеллектуальной обработки между «документ пришёл» и «данные попали в систему». Разберём, что именно этот слой умеет делать в производственных условиях. Задача 1: извлечение данных из договоров Это самый зрелый сценарий применения LLM в документообороте. Задача формулируется просто: на входе — PDF или DOCX договора, на выходе — структурированный JSON с полями. Что LLM извлекает надёжно: • Стороны договора (наименование, ИНН, КПП, адрес) • Предмет договора (краткое описание) • Сумма, валюта, НДС • Сроки действия и исполнения • Реквизиты банковских счетов • Условия расторжения и штрафные санкции • Подписанты и их должности На типовых договорах (поставка, оказание услуг, аренда) точность извлечения составляет 90–95% без дообучения модели — только на хорошо составленном промпте. Это достигается за 3–8 секунд на документ. Где точность падает: • Договоры с нестандартной структурой или вложенными приложениями • Многостраничные рамочные соглашения с перекрёстными ссылками • Сканы с низким качеством или рукописными правками на полях • Специфическая отраслевая терминология (строительство, фармацевтика) Для последних двух случаев помогает fine-tuning на корпусе собственных документов компании — после него точность поднимается до 97–99% на знакомых шаблонах. Как это выглядит в интеграции с 1С: ``` Договор (PDF) → OCR (если нужно) → LLM → JSON → Внешняя обработка 1С → Документ «Договор контрагента» ``` Внешняя обработка принимает JSON через HTTP-сервис или COM-соединение и записывает поля в реквизиты документа. Конфигурацию 1С при этом менять не нужно — достаточно стандартных механизмов платформы. Задача 2: генерация типовых актов и документов Вторая по зрелости задача — генерация исходящих документов на основе данных из системы. Типичные сценарии: Акт выполненных работ по данным из заказа в 1С. LLM получает структурированные данные (перечень работ, суммы, даты, стороны) и генерирует текст акта в нужном формате. Это не шаблонизатор — модель умеет правильно склонять суммы прописью, согласовывать падежи в описании работ, подставлять корректные формулировки в зависимости от типа договора. Сопроводительные письма и уведомления. Претензия по просроченной поставке, уведомление о смене реквизитов, ответ на запрос документов — всё это генерируется по шаблону промпта с подстановкой данных из CRM или 1С. Спецификации и приложения к договорам. Если номенклатура и цены есть в системе, LLM формирует корректно оформленное приложение с таблицей позиций. Важное ограничение: генерация — это не подпись. Сгенерированный документ требует проверки перед отправкой контрагенту или загрузкой в ЭДО. Для высокорисковых документов (судебные, с крупными суммами) человек в цепочке обязателен. Для массовых типовых актов на небольшие суммы — можно настроить автоматическую отправку с выборочным контролем. Задача 3: классификация входящих документов Входящий поток в компании среднего размера — это смесь: счета, акты, договоры, претензии, запросы, накладные, письма. Всё это приходит на общий email, в ЭДО (Диадок, СБИС) или через курьера в виде сканов. Задача классификатора — определить тип документа и направить его в нужный процесс: счёт — в бухгалтерию на оплату, претензия — юристу, договор — на согласование. Результаты на практике: Тип документа | F1-мера (few-shot) | F1-мера (fine-tuned) Счёт на оплату | 94% | 98% Акт выполненных работ | 91% | 97% Договор / доп. соглашение | 89% | 96% Претензия / рекламация | 85% | 94% Прочая корреспонденция | 78% | 88% Few-shot — это классификация без дообучения, только на примерах в промпте (5–10 штук на класс). Fine-tuned — модель, дообученная на 500+ примерах каждого класса из реального архива компании. Интеграция с ЭДО: Диадок и СБИС предоставляют API для получения входящих документов. Пайплайн выглядит так: документ поступает через API → LLM классифицирует и извлекает ключевые поля → задача создаётся в нужной очереди (1С, CRM, таск-трекер) → ответственный получает уведомление с уже заполненными данными, а не пустой документ. Где LLM не справляется без человека Честный разговор об ограничениях важнее, чем список возможностей. Юридическая интерпретация нестандартных условий. LLM извлечёт текст пункта о форс-мажоре, но не оценит, насколько он защищает интересы компании в конкретном споре. Это работа юриста. Документы с противоречиями. Если в теле договора одна сумма, а в спецификации другая — модель либо выберет одну, либо вернёт оба значения с флагом неопределённости. Решение принимает человек. Редкие и нестандартные типы документов. Классификатор, обученный на 10 классах, не знает, что делать с лицензионным соглашением на ПО или актом сверки в нестандартном формате. Нужен либо класс «прочее» с эскалацией, либо расширение обучающей выборки. Персональные данные и 152-ФЗ. Если в документах есть персональные данные физических лиц (паспортные данные, адреса, подписи), обработка через внешние API нарушает требования локализации. Решение — on-premise развёртывание модели или российское облако (SberCloud, Yandex Cloud с соответствующими сертификатами). Юридически значимый ЭДО. Документы, подписанные КЭП в Диадоке или СБИС, имеют юридическую силу. Автоматическая обработка не снимает ответственности с подписанта — человек должен понимать, что он подписывает. Архитектура пайплайна: от документа до системы Практическая схема для компании, которая хочет автоматизировать входящий документопоток: Уровень 1 — получение документов. Email-парсер, API ЭДО (Диадок/СБИС), сканер с OCR (ABBYY FineReader или Yandex Vision для русского языка), ручная загрузка через веб-форму. Уровень 2 — предобработка. Нормализация форматов (всё в текст или структурированный PDF), OCR для сканов, разбивка многостраничных документов на логические части. Уровень 3 — LLM-обработка. Классификация типа документа → извлечение реквизитов → валидация (ИНН проверяется по контрольной сумме, даты — на корректность формата, суммы — на соответствие итогам таблицы). Уровень 4 — интеграция. JSON с данными передаётся в 1С (через HTTP-сервис или COM), CRM, таск-трекер. Документ прикрепляется к созданной записи. Уровень 5 — контроль качества. Дашборд с метриками: доля документов, обработанных автоматически; доля эскалированных на человека; точность по типам документов; время обработки. Без этого уровня невозможно понять, работает ли система и где деградирует. Как выбрать модель для российского документооборота Выбор модели определяется двумя факторами: качество на русском языке и требования к локализации данных. GigaChat (Сбер) — работает on-premise и в SberCloud, хорошо справляется с юридическими текстами на русском, есть API с батч-обработкой. Оптимален для компаний с жёсткими требованиями к локализации. YandexGPT — доступен через Yandex Cloud, сильные позиции на русском языке, хорошая документация для интеграции. Подходит для компаний, уже использующих инфраструктуру Яндекса. GPT-4o (OpenAI) — лучшее качество на сложных конструкциях и нестандартных документах, но требует решения вопроса с локализацией персональных данных. Применим для документов без ПДн или при использовании через российских реселлеров с соответствующими соглашениями. Открытые модели (Llama, Mistral, saiga) — развёртываются полностью on-premise, нет зависимости от внешних API. Требуют больше ресурсов на инфраструктуру и настройку, но дают полный контроль над данными. С чего начать Не с выбора модели и не с архитектуры. С аудита одного конкретного потока документов. Возьмите один тип: например, входящие акты выполненных работ от подрядчиков. Посчитайте, сколько их приходит в месяц, сколько времени уходит на обработку каждого, какие поля нужно переносить в 1С. Это даст вам базовую метрику — сколько часов в месяц стоит эта задача. Затем соберите 100–200 реальных документов этого типа, разметьте поля вручную и проверьте, как с ними справляется LLM на промпте без дообучения. Если точность выше 85% — задача подходит для автоматизации. Если ниже — нужно либо дообучение, либо переосмысление задачи. Пилот на одном потоке занимает 4–8 недель и даёт измеримый результат: конкретное количество сэкономленных человеко-часов в месяц. Это основание для решения о масштабировании. --- Читайте также в блоге brezatech: • Как построить базу знаний компании на LLM • BI для операционного директора: какие метрики реально нужны • LLM в производственной среде: архитектурные решения ```