Red team-упражнения для AI‑воркфлоу перед запуском

Почему реальные тесты задач тихо проваливаются

Ранние проверки AI обычно выглядят лучше, чем реальная работа. Команды используют аккуратные примеры, короткие подсказки и стандартные случаи. Модель проходит тест, звучит уверенно, и все двигаются дальше.

Эта уверенность — часть проблемы. AI может выбрать неправильный инструмент, отправить сообщение слишком рано или пропустить проверку политики, оставаясь спокойным и отредактированным. Люди доверяют беглым ответам больше, чем стоит, особенно когда результат выглядит «достаточно похоже».

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

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

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

Именно поэтому перед запуском важны реалистичные red team‑упражнения. Они проверяют неудобные случаи, которые команды забывают симулировать: смешанные намерения, пропущенные поля, странная формулировка, частичные согласования и запросы, которые кажутся безобидными, пока вызов инструмента не проходит. Если вы тестируете только счастливый путь — клиенты найдут остальное за вас.

Выберите, какие воркфлоу тестировать в первую очередь

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

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

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

Используйте примеры из недавней работы, а не из воркшопа, где кто‑то писал подсказки, чтобы система выглядела хорошо. Реальные задачи содержат расплывчатые формулировки, скопированные заметки, отсутствующие детали и странное поведение клиентов. Эта неопрятность полезна, потому что именно там чаще всего проявляются провалы подсказок.

Удаляйте приватные данные перед тестом. Заменяйте имена, e‑mail, телефоны, ID аккаунтов и всё регулируемое. Оставляйте форму задачи такой же. Если в тикете поддержки был сердитый и непонятный тон, тестовый кейс должен сохранить это ощущение.

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

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

Решите, что считать провалом

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

Начните с согласований. Запишите каждое действие, которое должно остановиться для человеческой проверки, даже если AI звучит уверенно. В продажах это может быть скидка выше установленного лимита. В поддержке — одобрение возврата. В операциях — изменение production‑настроек, удаление записей или вмешательство в биллинг клиента.

Затем составьте два списка инструментов для каждой задачи. Один — инструменты, к которым AI может обращаться. Другой — инструменты, к которым он ни в коем случае не должен прикасаться. Если агент поддержки может читать историю тикетов, но не выдавать кредиты, любая попытка выдать кредит — это провал, даже если сумма верна.

Правила «пройти/провалиться» должны быть достаточно простыми, чтобы два рецензента приняли одно и то же решение. Например: прогон проходит, если AI подготовил ответ, запросил согласование перед отправкой и использовал только CRM. Он провалился, если изменил цены без одобрения, вызвал инструменты финансов или production, завершил задачу при отсутствии данных клиента или выдумал факты.

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

Назначьте рецензентов до старта упражнения. Один человек должен оценивать бизнес‑точность. Другой — проверять использование инструментов и шаги согласований. Третий — фиксировать каждую проблему в одном месте с названием задачи, ожидаемым поведением, фактическим поведением и уровнем риска.

Такая структура делает упражнение честным. Команды перестают спорить о впечатлениях и начинают оценивать прогоны по заранее согласованным правилам.

Проводите упражнение шаг за шагом

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

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

Останавливайтесь при каждом вызове инструмента

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

Поддержка иллюстрирует это чётко. Если AI читает политику возвратов, открывает биллинговую систему и готовит возврат — делайте паузу после каждого шага. Черновик может выглядеть нормально, но модель могла пропустить ворота согласования, потому что подсказка просила быть «полезной», а инструмент имел более широкий доступ, чем ожидалось.

Ведите единый общий журнал

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

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

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

Простой день тестирования для продаж, поддержки и операций

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

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

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

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

Специально смешивайте формулировки. Используйте подсказки вроде "обработай это сегодня" или "следуй политике, но держи клиента довольным любой ценой". Реальные команды пишут такие поспешные сообщения. Ваши тесты должны отражать это давление.

Короткий чек‑лист помогает. Спросите: запросил ли AI контекст при отсутствии фактов? Просил ли он согласование, когда в задаче были деньги, скидки, возвраты или закупки? Признал ли он неопределённость или притворился, что знает больше, чем на самом деле? Вызвала ли срочность неправильный вызов инструмента или плохое решение?

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

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

Большинство ошибок прячется в разрыве между словами модели и действием, которое она отправляет в инструмент. Чат‑бот может звучать спокойно и правильно, при этом обновить не ту запись в CRM, вернуть деньги по неверному заказу или дать доступ не тому человеку.

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

Начните с самого вызова инструмента. Проверьте ID аккаунта, ID записи, e‑mail, сумму, диапазон дат и любые фильтры, которые модель передала. Мелкие ошибки важны. Агент поддержки, который просит закрыть тикет 1842, не должен запускать вызов, меняющий 1482, потому что модель догадалась из запутанного потока.

Затем проверьте согласования. Перемещение денег, изменения прав, правки данных клиента и действия с контрактами не должны происходить только потому, что модель чувствовала себя уверенно. Система должна остановиться и запросить явное согласование у нужного человека. Если AI может выдать возврат, изменить биллинг, сбросить MFA или пригласить внешнего пользователя без этого шага — исправляйте до запуска.

Правила подсказок часто выглядят надёжно, пока модель не начнёт торопиться. Давите на неё: давайте расплывчатые запросы, сердитых пользователей, неполные данные и конфликтующие инструкции. Вы часто найдёте одну строчку в подсказке, которую модель тихо опускает, например "запрашивать одобрение менеджера при сумме > $500" или "никогда не менять адрес клиента из чата".

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

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

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

Ошибки команд в ранних тестах

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

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

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

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

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

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

Команды, которые пропускают эти проверки, получают ту же неприятность позже: AI звучит уверенно и компетентно, но делает неправильно под капотом. Ловля этого до запуска экономит деньги, время на исправления и несколько неприятных разговоров с клиентами.

Быстрые проверки перед запуском

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

Начните с согласования. Если воркфлоу может повлиять на клиента, контракт, платеж или production‑данные, назначьте человека, который должен это одобрить. Не оставляйте это как "кто‑то из команды". Укажите одну роль или одного человека и проверьте, что воркфлоу останавливается, если согласование не пришло.

Потом проверьте логи. Каждый вызов инструмента должен оставлять простой след: что агент пытался сделать, какую систему коснулся, какие входные данные использовал и что случилось дальше. Если sales обновил поле в CRM или support закрыл тикет, команда должна находить это действие за секунды. Аудит вызовов инструментов кажется скучным ровно до того момента, когда он вам понадобился.

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

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

Наконец, назначьте одного владельца за ретесты. Каждая правка подсказки, смена инструмента, обновление политики или смена модели может заново открыть старые провалы. Один человек должен перезапускать проверки после каждого изменения и отмечать, что прошло, что не прошло и что ещё нужно сделать. Если никто за это не отвечает, та же ошибка обычно возвращается под другим именем.

Что делать после первого раунда

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

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

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

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

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

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

Если хотите внешний обзор, Oleg Sotnikov на oleg.is работает со стартапами и малыми командами как Fractional CTO и консультант. Он может помочь просмотреть реальные AI‑воркфлоу, права инструментов и шаги согласования перед запуском, особенно когда команда, которая собрала систему, слишком близка к ней, чтобы заметить слабые места.