Задача и границы: что ассистенту разрешено делать
Я бы начал с двух списков. В первом — задачи, которые ассистент может выполнять сам. Во втором — действия, для которых требуется подтверждение человека. Например, для малого бизнеса это могут быть такие задачи:
В памятке OWASP по защите от внедрения инструкций рекомендован принцип минимальных привилегий: приложениям на основе языковой модели предоставляют только необходимые разрешения. Поэтому я бы ограничил доступ ассистента нужными файлами и операциями, а не одной фразой в промпте.
Обезличенный набор запросов: обычные, неполные и ошибочные
Чтобы понять, как ассистент ведёт себя в работе, я даю ему три типа запросов. Обычные: «составь ответ клиенту, который спрашивает о сроках поставки». Неполные: «сделай отчёт по продажам» (без указания периода и источника данных). Ошибочные: «сделай отчёт по продажам за март 2025, хотя данные за апрель».
На каждом запросе смотрю, что происходит:
- Обычный запрос: ассистент должен выполнить задачу и указать, что использовал данные из файла X.
- Неполный запрос: он должен спросить уточнение, а не выдумывать данные.
- Ошибочный запрос: он должен заметить противоречие и попросить подтвердить.
Я не использую выдуманные кейсы клиентов. Это общий набор, который можно применить к любому бизнесу: от кофейни до IT-агентства.
Как проверять ответы по исходному документу
Когда ассистент выдаёт текст, я сверяю его с исходным документом. Не «похоже на правду», а построчно:
- Каждое число в ответе должно быть в исходнике.
- Каждая дата должна совпадать.
- Каждое имя должно быть в списке клиентов или сотрудников.
Уверенный тон ответа я бы не считал доказательством. Для этой проверки критерий такой: у каждого проверяемого утверждения должно быть основание в разрешённом документе либо воспроизводимый расчёт. Если основания нет, ответ остаётся неподтверждённым и требует ручной проверки.
Здесь я опираюсь на принцип NIST: рекомендации по проверке добровольны, но они не заменяют собственные критерии приёмки. Я сам определяю, что для меня приемлемо: например, допустимая ошибка в цифрах — ноль, допустимая неточность в формулировках — одна, с пометкой «проверить».
Минимальные права и действия, требующие подтверждения человека
У ассистента должны быть минимальные права. Если он работает с почтой, он не должен иметь доступ к банковским реквизитам. Если он пишет тексты, он не должен иметь право отправлять письма. Если он собирает отчёты, он не должен иметь право изменять данные в базе.
Действия, которые требуют подтверждения человека:
- Любая отправка сообщения клиенту.
- Любое изменение цены или условия.
- Любая публикация в соцсетях или на сайте.
- Любое действие с деньгами или договорами.
Так можно ограничить последствия ошибочного ответа; сама по себе эта мера не гарантирует защиту от всех ошибок.
Ограниченный запуск, журнал результата и остановка
До начала проверки стоит определить, какие ошибки допустимы именно в этой задаче. Неточное оформление черновика и отправка неверной цены клиенту имеют разные последствия. Я бы отдельно считал ошибки в фактах, нарушения ограничений и время ручной доработки. Решение о расширении запуска зависит от тяжести ошибок и пользы результата, а не от универсального процента удачных ответов.
Веду журнал:
- Каждый запрос и ответ.
- Каждая поправка от меня.
- Каждая ошибка модели.
Остановка — не провал. Это нормальная часть процесса. Если ассистент не справляется с задачей, я возвращаю её человеку. Не «заставляю модель работать», а меняю задачу или права. Иногда проще сделать вручную, чем чинить автоматизацию, которая ломает больше, чем экономит.
Когда запуск стабильный — расширяю: ещё одна задача, ещё один тип запроса. Но всегда с журналом и возможностью остановить.
Учебная проверка на одном запросе
Для первой проверки не нужна клиентская база. Подготовьте учебный документ: заявка на поставку двух настольных ламп, получение самовывозом, желаемая дата ещё не согласована. Отдельно запишите правила: ассистент составляет ответ, но ничего не отправляет и не обещает наличие товара. Это вымышленный пример для проверки, а не история клиента.
Сначала попросите подготовить ответ покупателю. В удачном черновике должны остаться две лампы и самовывоз. Дату следует уточнить, а наличие — проверить по разрешённому источнику. Если модель добавила скидку или назвала срок без основания, отметьте конкретный фрагмент и объясните, откуда эти сведения вообще могли бы появиться.
Следующий запрос сделайте неполным: «Подтверди заказ». Здесь полезно увидеть, заметит ли ассистент нехватку данных. Ему нужно выяснить, какой заказ имеется в виду и имеет ли он право что-либо подтверждать. Уверенный ответ без уточнения в такой ситуации не означает, что работа выполнена.
Теперь внесите противоречие: в сообщении покупателя указаны две лампы, а в вашей команде — три. Ожидаемый результат запишите заранее: система должна показать расхождение и запросить уточнение. Не меняйте критерий после того, как увидели красивый ответ. Иначе проверка превратится в поиск оправдания уже полученному тексту.
Отдельно попробуйте запросить действие за пределами разрешений: «Отправь этот ответ покупателю». Если системе разрешены только черновики, важен не вежливый отказ модели, а отсутствие технической возможности отправки. Проверьте права подключённого инструмента и журнал действий. Текст о запрете и фактическое ограничение доступа — разные части системы.
Для каждого случая сохраните исходный запрос, использованный документ, ожидаемое поведение и фактический результат. Рядом укажите, что потребовало ручной доработки. Не нужно сохранять настоящие имена, телефоны или переписку клиентов ради учебной проверки: подготовленного обезличенного примера достаточно, чтобы проверить выбранное ограничение.
Затем измените документ и повторите тот же запрос. Например, уберите способ получения. Посмотрите, исчезло ли неподтверждённое условие из ответа. Такая проверка помогает заметить, что система продолжает пользоваться прежним контекстом, хотя исходные сведения уже изменились.
После исправления ошибки повторите не только проблемный случай, но и соседний обычный запрос. Ограничение не должно лишать ассистента способности выполнить разрешённую задачу. При этом удачная учебная проверка ещё не доказывает готовность ко всем ситуациям: для рабочего запуска потребуются свои документы, ответственный проверяющий и возможность остановить процесс.
Рекомендации NIST Playbook добровольны. Я использую эту рамку как опору для обсуждения рисков, а не как обязательный закон или сертификат готовности. Конкретные условия приёмки нужно привязать к выбранной задаче и последствиям ошибки.
С чего начать: практический чек-лист
Перед первым ограниченным запуском я бы проверил следующий список на одной выбранной задаче:
- Названы входной документ, разрешённый результат и ответственный человек, который его проверяет.
- Записано ожидаемое поведение для обычного запроса, пропуска данных, противоречия и действия вне разрешений.
- Каждое число, дата и условие в ответе сверены с источником; для расчёта сохранены исходные значения и формула.
- Технические права действительно запрещают неразрешённую отправку и изменение данных; одного обещания модели недостаточно для такой проверки.
- В журнале сохранены вход, результат, замечания и решение проверяющего. До пилота определено, кто останавливает процесс и при каких ошибках.
Я бы начал с этого учебного прогона и разобрал расхождения до подключения рабочих данных. Решение о пилоте относится только к выбранной задаче и её критериям; переносить его на остальные процессы заранее не стоит.