Когда письмо начинает командовать ИИ: что проверить в обработке заявок

8 декабря 2025 года британский Национальный центр кибербезопасности (NCSC) опубликовал разбор подмены инструкций для языковых моделей, известной как prompt injection. Авторы объясняют риск: внешнее содержимое может повлиять на действия приложения, если оно обрабатывается вместе с управляющими указаниями. Для автоматизации заявок это вопрос о том, какие решения разрешено принимать по тексту входящего письма.

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

Откуда взялась команда

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

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

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

Как проверить границу на безопасном примере

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

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

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

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

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

Первоисточник: NCSC, разбор риска подмены инструкций для языковых моделей, 8 декабря 2025 года

Источник: pro-automatization.ru