LLM уже умеют читать таможенные документы. Как превратить это в управляемый процесс?

Да, мы знаем, что сотрудники отделов ВЭД и таможенного оформления уже используют ChatGPT, Claude, YandexGPT и другие LLM как персональных помощников для работы с документами. Загружают инвойсы, упаковочные листы, контракты и другие файлы, просят извлечь нужные данные, перевести описания товаров или заполнить рабочую таблицу. Таким способом экономить время на рутинной обработке документов сегодня уже никого особенно не удивить.

Для одного специалиста это вполне рабочий сценарий. Специалист сам загружает документы, формулирует промпт, получает результат и при необходимости перепроверяет его перед дальнейшей работой.

Вопросы начинаются тогда, когда такой подход нужно распространить на всю команду и превратить из персонального инструмента в регулярный бизнес-процесс.

Как сделать так, чтобы все сотрудники обрабатывали документы по единым правилам? Как проверить, из какого документа и фрагмента модель получила конкретное значение? Что делать, если Invoice, Packing List и Contract противоречат друг другу? Как отличить данные, найденные непосредственно в документах, от расчетов или предположений модели? Как контролировать использование разных LLM и расходы на токены, когда через них ежедневно проходят сотни документов? И, главное, должен ли специалист после работы AI по-прежнему вручную перепроверять весь результат?

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

Проблема промышленной автоматизации начинается там, где ответ LLM нужно превратить в воспроизводимый, проверяемый и управляемый результат, который можно безопасно использовать дальше в бизнес-процессе.

Современные мультимодальные модели уже способны выполнять значительную часть работы, которая еще несколько лет назад требовала отдельных OCR- и NLP-компонентов.

Например, LLM может:

• прочитать PDF или скан;
• извлечь данные из инвойсов и транспортных листов;
• понять структуру таблицы;
• перевести товарные описания;
• преобразовать информацию в заданный табличный формат;
• выполнить часть сопоставлений между несколькими документами.

Сценарий с загрузкой документов в ChatGPT или Claude и автоматическим заполнением Excel вполне рабочий. Но именно здесь проходит граница между использованием LLM как персонального инструмента и автоматизацией бизнес-процесса.

Если итоговый Excel все равно необходимо полностью перепроверить вручную, выяснить происхождение сомнительных значений и затем переносить информацию дальше, LLM ускоряет работу специалиста, но сам процесс всё еще остаётся ручным.

В таможенном оформлении разные данные имеют принципиально разный уровень надежности. Например, номер Invoice обычно прямо указан в документе. Его можно извлечь практически без изменений.

Но описание товара для таможенной декларации может собираться из нескольких источников: инвойса, технической спецификации, каталога производителя, сертификата и внутренних справочников.

Другие значения могут быть рассчитаны системой. Например, итоговое количество товара может представлять собой сумму нескольких строк инвойсов. А еще, финальный код ТН ВЭД вообще может требовать отдельной классификации и экспертной проверки.

Если все эти данные просто оказываются в соседних ячейках Excel, специалисту сложно понять, каким значениям можно доверять автоматически, а какие требуют внимания.

Поэтому в управляемом процессе данные полезно разделять хотя бы на три категории:

1. EXTRACTED – значение непосредственно найдено в документе.
2. CALCULATED – значение рассчитано системой на основании подтвержденных исходных данных.
3. ENRICHED – значение получено из каталога, справочника, истории поставок или другого дополнительного источника.

Но одной такой маркировки недостаточно. Следующий уровень – возможность доказать происхождение каждого значения.

1. Для каждого значения должно быть понятно, откуда оно появилось

Для автоматически заполненного поля желательно знать:

• из какого документа оно получено;
• с какой страницы;
• из какого фрагмента документа;
• было значение извлечено, рассчитано или дополнено из внешнего источника;
• какие проверки оно прошло.

Такой подход часто называют provenance – происхождением данных.

Он особенно важен там, где ошибка обнаруживается не сразу.

Рассмотрим простой пример. Недостаточно получить значение: Quantity: 256

Для промышленного процесса полезнее хранить примерно такую структуру:

Quantity: 256
Source: Invoice 849337
Lines: 14 + 15
Method: EXTRACTED / aggregated
Validation: соответствует Packing List
Status: OK

Представим, что специалист видит в итоговой спецификации количество 256 шт и сомневается в нем. В обычном LLM-чате ему придется вернуться к исходным документам, заново искать нужные строки и разбираться, почему модель получила именно такой результат.

В управляемой системе пользователь может сразу увидеть источник значения и логику его получения.

Для работы с таможенными документами недостаточно знать ответ модели. Важно иметь возможность быстро проверить, почему система получила именно этот ответ.

2. Проверять нужно не только документы, но и связи между ними

Реальная поставка редко представлена одним PDF. Комплект обычно включает в себя множество документов:

• Инвойс (Invoice);
• Транспортный лист (Packing list);
• Договор (Contract);
• Транспортный документ;
• Сертификат (Certificate);
• Транзитная декларация (Transit declaration);
• дополнительные спецификации и технические документы.

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

Например:

• Количество в инвойсе совпадает с количеством в транспортном листе?
• Общий вес товаров из транспортного листа соответствует транспортному документу?
• Номер контракта, указанный в инвойсе, совпадает с загруженным договоре?
• Страна происхождения одинакова в разных документах?
• Совпадают ли правила купли-продажи или инкотермс?
• присутствует ли конкретный артикул в загруженном сертификате?
• согласуются ли указанные в документах HS / CN / ТН ВЭД коды?

Именно здесь появляется существенная дополнительная ценность по сравнению с персональным сценарием в LLMl. Предположим, LLM правильно извлек из инвойса условие поставки FCA, а из Договора – EXW. По отдельности оба результата распознаны верно.

Проблема становится видна только после междокументной проверки.

Поэтому промышленный процесс должен работать не по принципу:

«Прочитай шесть PDF и выдай мне таблицу».

А скорее по принципу:

«Извлеки факты из каждого источника, свяжи их между собой и проверь выполнение заданных бизнес-правил».

3. Хорошая система должна уметь сказать: «я не знаю»

Это одно из наиболее важных отличий управляемой автоматизации от простого запроса к LLM.

Рассмотрим транспортный лист.

На одной смешанной паллете находятся два разных SKU. Для паллеты указан общий вес нетто и общий вес брутто, но веса каждого SKU отдельно нет.

Теоретически модель может попытаться распределить вес пропорционально количеству единиц товара. Но для этого требуется предположение: что единица первого SKU весит столько же, сколько единица второго.

Если такого подтверждения в документах нет, система не должна делать этот расчет только ради заполнения ячейки. Правильный результат в такой ситуации – Status: MISSING

Если транспортный лист содержит только общий вес смешанной паллеты, вес отдельного SKU определить на основании имеющихся документов невозможно.

Required: Detailed Packing List / SKU-level Weight Breakdown.

Это важное изменение логики.

Цель автоматизации – не добиться 100% заполненных ячеек любой ценой, а показать, каких данных и почему не хватает.

То же относится к конфликтам.

Если инвойс содержит одни инкотермс, а договор – другие, модель не должна самостоятельно решать, что договор «обычно надежнее», и выбрать его значение.

Результатом должен стать статус: CONFLICT (требуется подтверждение специалиста).

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

4. Human-in-the-loop должен означать работу с исключениями

Фраза «финальное решение принимает человек» сама по себе еще мало говорит об уровне автоматизации.

Если после обработки документов специалист все равно должен проверить каждую строку, открыть каждый PDF и самостоятельно сверить все значения, мы просто добавили новый инструмент перед существующим ручным процессом.

Более интересная модель – exception-based HITL.

Представим комплект документов с 300 товарными строками.

После автоматического извлечения и проверок система распределила их так:

• 255 – OK
• 28 – REVIEW
• 10 – MISSING
• 7 – CONFLICT

Поэтому задача специалиста – не повторно проверить все 300 строк, а всего лишь 45 исключений.

Главная задача HITL в таком подходе – заменить повторную ручную проверку всего комплекта документов работой только с исключениями.

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

5. Недостаточно сообщить, что данных нет. Нужно объяснить, чего именно не хватает

Статус MISSING тоже можно сделать значительно полезнее. Система не должна ограничиваться сообщением: «Поле Net Weight не заполнено».

Она может определить причину и подсказать, какой источник необходим для продолжения процесса.

Например: Нет веса отдельного SKU

Причина: Packing List содержит только общий вес mixed pallet.

Необходимый документ: Detailed Packing List / SKU-level Weight Specification.

Другой пример: Недостаточно данных для полного описания товара

Причина: Инвойс содержит только артикул и краткое коммерческое название.

Необходимый источник: Manufacturer Catalogue / Datasheet / Technical Specification.

Еще один сценарий: Не найден подтверждающий разрешительный документ

Причина: загруженный сертификат не содержит соответствующий артикул.

Необходимо: Certificate / Declaration of Conformity, распространяющийся на данный товар.

Отсюда возникает логичное направление дальнейшего развития системы – условный Missing Documents Engine.

На основании обнаруженных пробелов и бизнес-правил workflow может не просто сигнализировать о незаполненном поле, а объяснять, какого подтверждения не хватает.

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

Но для повторяющихся сценариев конкретной организации значительную часть такой логики можно формализовать.

В одном из реализованных нами проектов система получает три основных типа документов:

• Инвойсы;
• Транспортные листы;
• Таможенные инвойсы.

Из них необходимо собрать большую товарную таблицу.

Среди извлекаемых данных, такие:

• Артикул;
• Наименование товара;
• Производитель;
• Страна;
• Торговая марка;
• Состав;
• Размер;
• Цвет;
• Количество;
• Цена за штуку;
• EAN;
• код ТН ВЭД.

Но извлечение полей – только начало процесса. Далее данные преобразуются в единую русскоязычную спецификацию по правилам клиента.

В ней объединяются и нормализуются сведения о товаре: состав и материалы, размеры, производитель и его адрес, GTIN и EAN, количество грузовых мест, стоимость, внутренние идентификаторы и другие необходимые характеристики.

То есть задача состоит уже не в том, чтобы просто превратить PDF в JSON или Excel.

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

Мы не видим дальнейшую цепочку процессов клиента после формирования этой спецификации, поэтому некорректно утверждать, какие именно следующие операции там полностью автоматизированы.

Но сам пример хорошо показывает границу между извлечением данных и промышленным воркфлоу:

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

Работа с коммерческой LLM	Промышленный AI-workflow
Сотрудник самостоятельно загружает документы	Документы автоматически попадают в единый процесс
Каждый может использовать собственный prompt	Действуют единые бизнес-правила
Модель возвращает готовый ответ	Для каждого значения хранится источник
Ответ необходимо перепроверять	До человека выполняются автоматические проверки
Неопределенность может быть скрыта внутри ответа	REVIEW / MISSING / CONFLICT выделяются явно
Сотрудник проверяет весь результат	HITL сосредоточен на исключениях
Результат вручную переносится дальше	Формируется структурированный output для следующей системы
Исправления сотрудников остаются разрозненными	Историю, правила и принятые решения можно централизованно накапливать

Это не означает, что второй вариант всегда лучше. Разница заключается прежде всего в масштабе и требованиях к процессу. А также зависит от стоимости AI-решения и его окупаемости для клиента.

Стоимость тоже становится заметным фактором, когда команда регулярно пользуется AI-инструментами.

Если одну и ту же операцию ежедневно выполняют, например, 8–10 специалистов, компания уже оплачивает не один персональный инструмент, а целый набор пользовательских подписок.

При корпоративном workflow появляется возможность централизованно выбирать модели, управлять количеством запросов и использовать API непосредственно для конкретной операции, не обязательно предоставляя каждому сотруднику максимальный AI-тариф.

Но было бы неправильно утверждать, что собственная система автоматически окажется дешевле.

У нее есть стоимость разработки, интеграций, инфраструктуры и дальнейшей эксплуатации.

Поэтому экономика – лишь один из факторов.

Обычно более важные причины перехода к корпоративной системе выглядят так:

1. контроль;
2. воспроизводимость;
3. автоматические проверки;
4. управляемый HITL;
5. интеграции;
6. аудитный след;
7. централизованное управление правилами;
8. и только затем оптимизация стоимости.

Автоматизация ради автоматизации не имеет смысла. Во многих случаях обычный ChatGPT или Claude действительно может оказаться оптимальным решением.

Особенно, если:

• документов немного;
• с ними работают один-два специалиста;
• задача возникает нерегулярно;
• итог легко проверить;
• нет сложных интеграций;
• нет необходимости заставлять всю команду работать по одинаковым правилам.

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

Ситуация меняется, когда:

• документов становится много;
• обработка выполняется ежедневно;
• с документами работает команда;
• одни и те же проверки повторяются из раза в раз;
• существуют фиксированные правила обработки;
• цена ошибки высока;
• значительная часть результата LLM все равно перепроверяется человеком;
• полученные данные необходимо передавать дальше в ERP, систему подготовки ДТ или другой внутренний контур.

Именно здесь персональный AI-инструмент начинает превращаться в инфраструктурную задачу.

Упрощенно архитектуру такого решения можно представить следующим образом:

В такой архитектуре LLM не принимает на себя весь процесс. Она становится мощным инструментом чтения и интерпретации документов внутри более контролируемой системы.

Бизнес-правила определяют, что можно принять автоматически. Cross-document validation проверяет согласованность данных. Статусы показывают уровень уверенности. HITL позволяет специалисту сосредоточиться на действительно неоднозначных ситуациях.

Задача не состоит в том, чтобы полностью исключить человека или автоматически формировать и подавать ДТ без контроля специалиста. Цель намного практичнее: максимально сократить объем данных, который специалисту необходимо искать и перепроверять вручную.

IT компаниям уже не нужно доказывать, что LLM способен прочитать инвойс, разобраться в таблице или заполнить заданную форму. Современные модели делают это достаточно хорошо, чтобы таможенные специалисты начали самостоятельно использовать их в ежедневной работе.

Следующая задача бизнеса сложнее. Нужно сделать результат воспроизводимым и проверяемым.

Для этого необходимо знать источник каждого значения, разделять извлеченные, рассчитанные и дополненные данные, автоматически сверять документы между собой, явно показывать неопределенность и не позволять модели самостоятельно скрывать конфликты.

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

Именно это превращает персональный AI-инструмент сотрудника в промышленную автоматизацию.