ИИшники

Практика ИИ

Письмо поставщика не должно управлять закупочным агентом

MIT Technology Review описал исследование о путанице ролей в языковых моделях: текст из одного контекста может восприниматься как инструкция с другим уровнем полномочий.

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

Редакция ИИшниковРедакционное обновление 15.09.2026 · не новая дата события

Коротко

  • Исследование обсуждается по доступным фрагментам статьи, без заявления о полной проверке работы.
  • Письмо поставщика — материал для извлечения условий, а не источник разрешений.
  • Права на оплату и изменение справочника держат вне текстового ответа модели.
AI-контроль поставщиков: как заранее ловить срывы сроков и рост себестоимости

Что именно сообщило издание

В доступном тексте MIT Technology Review исследователи связывают уязвимость с механизмом определения источника инструкций. Издание описывает атаки, при которых модель путает пользовательский текст с инструкциями иной роли, и приводит название chain-of-thought forgery.

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

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

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

Отделите коммерческие условия от управления

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

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

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

Ограничения должны работать за пределами модели

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

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

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

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

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

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

Что останется после проверки

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

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

Источники и границы разбора

  1. Доступные фрагменты публикацииMIT Technology Review: уязвимость моделей из-за путаницы ролей30 июля 2026, дата в адресе архивного источника

    Повторно прочитаны доступные веб-фрагменты: раздел Role play и описание chain-of-thought forgery. Заявление о полной защищённости атрибутировано исследователям; первичная работа не проверена.

Механизм атаки изложен по доступным фрагментам MIT Technology Review. Проверки закупочного помощника предложены редакцией и не доказывают полной безопасности. Первоначальная дата страницы сохранена.

Проверить границы обработки предложений

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

Обсудить задачу