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

Входящие заказы часто приходят в письмах, вложенных таблицах, PDF и сообщениях менеджеров. Сотруднику приходится переносить контрагента, позиции, количество, цену, адрес и срок поставки в ERP или CRM. Это повторяемая работа, но ошибка в одном поле может привести к неверному счёту, остаткам или отгрузке.

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

OWASP относит недостаточную проверку вывода модели перед передачей его другим компонентам к рискам improper output handling. Практический смысл для заказов прост: результат генерации нельзя напрямую подставлять в привилегированный вызов ERP. Его нужно считать недоверенным вводом, как данные из внешней формы.

Рабочая схема: извлечение отдельно, запись отдельно

Разделите процесс на четыре шага.

1. **Получить документ и сохранить происхождение.** Сервис принимает письмо или вложение, фиксирует отправителя, время, идентификатор письма и хеш файла. Файл хранится в защищённом контуре компании; модели передаётся только необходимый текст. Если документ содержит персональные или коммерчески чувствительные сведения, отдельно решите, где выполняется распознавание и какие поля можно отправлять во внешний API.
2. **Сформировать черновик.** Модель извлекает только разрешённые поля и возвращает объект фиксированной структуры: клиент, ИНН или внутренний ID, позиции, артикулы, количества, валюта, адрес, желаемая дата и ссылки на фрагменты-основания. Для неизвестного значения задаётся null, а не догадка. Сам текст заказа считается данными, не источником новых инструкций для агента.
3. **Проверить детерминированно.** Код валидирует JSON Schema, типы и обязательные поля, проверяет клиента и артикулы по справочникам, пересчитывает суммы, сравнивает валюту и допустимые пределы, а также ищет дубликат по устойчивому ключу заказа. Проверка схемы подтверждает форму и типы, но не истинность значения — эти проверки отдельные.
4. **Показать сотруднику и записать через ограниченный адаптер.** Интерфейс показывает исходный фрагмент рядом с каждым значением, подсвечивает расхождения и позволяет исправить черновик. Только после явного подтверждения адаптер вызывает API ERP. Модель не получает пароль или универсальную возможность выполнять произвольные операции.

Такой дизайн отделяет вероятностную часть от бизнес-правил. Модель предлагает интерпретацию; код решает, допустима ли она; сотрудник утверждает исключения; учётная система получает только проверенную команду.

Что именно проверять

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

  • **Идентичность клиента.** Сопоставляйте по внутреннему идентификатору и подтверждённым реквизитам, а не только по похожему названию. Если найдено несколько кандидатов, направляйте заказ на уточнение.
  • **Номенклатура.** Сверяйте артикул, единицу измерения и статус позиции с мастер-данными. Не разрешайте модели самостоятельно создавать новую карточку товара.
  • **Количество и цена.** Проверяйте числовой диапазон, валюту, скидки и арифметику. Модель может переписать число, но расчёт суммы выполняет код.
  • **Сроки и адрес.** Сравнивайте запрошенную дату с рабочим календарём и правилами доставки. Не подменяйте отсутствующую дату «разумным предположением».
  • **Основание каждого поля.** Храните цитату или координаты страницы, откуда значение извлечено. Если подтверждающего фрагмента нет, поле требует ручного ввода.
  • **Повторная доставка.** Используйте внешний ID письма или хеш нормализованного заказа как ключ идемпотентности, чтобы повторная обработка после сетевого сбоя не создавала второй заказ.

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

Доступы, ошибки и журнал

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

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

Сбои разделите на понятные категории: модель не ответила; документ не прочитан; схема нарушена; справочник не нашёл позицию; сотрудник отклонил черновик; ERP недоступна. Повторять безопасно можно чтение или запрос к модели. Запись в ERP повторяйте только с тем же ключом идемпотентности и после проверки статуса предыдущего вызова. Иначе тайм-аут может закончиться дублем.

Как измерить пилот без самообмана

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

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

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

Полезно сравнить два режима на одной выборке: обычную ручную обработку и подготовку черновика ИИ с проверкой. Это оценка конкретного процесса, а не обещание универсальной производительности модели.

Ограничения и следующий шаг

Схема не устраняет ошибки модели и не гарантирует защиту от prompt injection. Текст во вложении может содержать вредоносные инструкции; поэтому они не должны расширять права интеграции, а окончательные проверки выполняются кодом вне модели. Ручное подтверждение тоже не панацея: интерфейс должен показывать источник данных, а не просить сотрудника механически нажать «ОК».

Для первого эксперимента выберите один частый и относительно низкорисковый тип заказа, выгрузите 50–100 обезличенных исторических примеров, составьте словарь обязательных полей и правил, затем прогоните их в режиме без записи в ERP. Число примеров — рабочая стартовая рекомендация, не статистическая гарантия. Перейдите к созданию черновиков только после проверки ошибок на реальных документах и согласования прав доступа.

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