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

Основатель хочет сказать «в понедельник». И не может, потому что внутри сидит неоформленное сомнение. Не про качество ответов, с ответами всё хорошо. Про то, что произойдёт, когда этот же агент встретит не подготовленный пример, а живого раздражённого человека в три часа ночи.

Сомнение правильное, но его нечем проверить. Читать код основатель не умеет, а спрашивать «вы всё предусмотрели?» бессмысленно: ответ будет «да», причём искренний.

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

Если агента вам не пишет своя команда, а продаёт внешний поставщик, разговор строится иначе, и о нём я писал отдельно в статье про проверку поставщика ИИ-агента. Здесь речь о своих людях и своём продукте.

Демонстрация показывает лучший день агента

Любая демонстрация это показ удачного случая. Её готовили. Данные выбрали чистые, сценарий отрепетировали, неудобный вопрос не задавали.

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

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

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

«Доступ к CRM» это не один доступ, а четыре

Главный приём в этом разговоре простой. Никогда не принимайте ответ «у агента есть доступ к CRM» целиком. Разберите его на четыре отдельных вопроса.

Это четыре разные вещи с четырьмя разными последствиями.

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

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

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

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

Что он читает и что он меняет

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

1. Какие записи агент читает и по какому правилу он их выбирает?

Хорошо. Названы таблица, конкретные поля и правило отбора.

Тревожно. «У него есть доступ к базе.»

2. Может ли он увидеть данные, которые для его задачи не нужны?

Хорошо. «Может, вот эти. Закрыть их стоит два дня, вот план.»

Тревожно. «Он их всё равно не использует.»

3. Какие действия он выполняет сам, без человека?

Хорошо. Короткий список глаголов, каждый с примером.

Тревожно. «Он просто работает с заявками.»

4. Какие из этих действий нельзя отменить?

Хорошо. Названы два или три, и объяснено, почему именно они.

Тревожно. «Всё можно откатить.» Отправленное письмо откатить нельзя.

5. Что он делает, когда не уверен?

Хорошо. Останавливается и передаёт человеку, вот порог.

Тревожно. «Он всегда что-то отвечает.»

Что уходит наружу и под какими правами

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

6. На какие внешние адреса уходят данные?

Хорошо. Список получателей, короткий и названный поимённо.

Тревожно. «Только к модели.» Почти никогда не только.

7. Что именно уходит, одно поле или вся карточка?

Хорошо. Показывают состав запроса на экране.

Тревожно. «Ну, контекст задачи.»

8. Под какой учётной записью агент ходит в нашу систему?

Хорошо. Отдельная служебная запись со своей ролью.

Тревожно. «Под моей.» Это встречается чаще, чем кажется.

9. Что эта учётная запись может, кроме нужного?

Хорошо. Открывают список прав и читают вслух.

Тревожно. «У неё полные права, чтобы не упираться.»

10. Где лежат ключи и кто их может прочитать?

Хорошо. В хранилище секретов, доступ у двух человек.

Тревожно. «В настройках проекта.» Или «в коде, но репозиторий закрытый».

Кто подтверждает, что агент помнит и что он слушает

Третья группа про границу между машиной и человеком. Самая частая ошибка выглядит безобидно: подтверждение есть, но оно показывается после действия. Человек видит сообщение «возврат оформлен» и нажимает «понятно». Это не подтверждение, это уведомление.

11. Что человек подтверждает перед выполнением?

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

Тревожно. «Оператор всё видит в ленте.»

12. В какой момент он это видит, до действия или после?

Хорошо. До, и без подтверждения действие не уходит.

Тревожно. «Сразу после, в уведомлении.»

13. Что агент помнит между разговорами и как долго?

Хорошо. Названы срок хранения и то, что именно сохраняется.

Тревожно. «Он помнит всё, так лучше отвечает.»

14. Может ли кусок одного разговора попасть в ответ другому клиенту?

Хорошо. «Не может, потому что вот это разделение. Мы проверяли так.»

Тревожно. «Теоретически нет.»

15. Что он делает, если в письме клиента написана команда для него самого?

Хорошо. «Пробовали, вот что получилось, вот что после этого закрыли.»

Тревожно. «Он не настолько глупый.»

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

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

16. Что записано в журнале и можно ли по нему восстановить один случай целиком?

Хорошо. Видно вход, решение, действие, результат и время.

Тревожно. «Логи есть, разработчик посмотрит.»

17. Какие стоят пределы, сколько действий в час и на какую сумму?

Хорошо. Числа. Любые разумные числа лучше их отсутствия.

Тревожно. «Пределов нет, нагрузка небольшая.»

18. Что мы проверяли, кроме сценариев успеха?

Хорошо. Список неудобных случаев и что после них поменяли.

Тревожно. «Тестировали на реальных обращениях, всё хорошо.»

19. Как выключить агента за минуту, не выключая продукт?

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

Тревожно. «Откатим релиз.» Это не минута.

20. Кто отвечает за этого агента, по имени?

Хорошо. Названо имя, и этот человек в комнате кивает.

Тревожно. «Команда поддержки продукта.» У отдела не бывает телефона в три часа ночи.

Просите не рассказ, а показ

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

Поэтому три просьбы вместо двадцати вопросов, если времени совсем мало.

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

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

Как не потратить этот разговор впустую

Три способа провести двадцать минут и не узнать ничего.

Обсуждать модель. Самый частый способ. Какая версия, какой промпт, как настроили, сравнивали ли с другой. Это увлекательный разговор, в нём легко провести час, и он почти ничего не говорит о рисках. Модель отвечает за качество текста. Права, пределы и журнал отвечают за последствия.
Не спросить, куда уходят данные. Внутри компании этот вопрос почему-то кажется неуместным: свои же люди, своя система. Но именно здесь чаще всего обнаруживается, что наружу уезжает больше, чем нужно, и никто этого не решал специально.
Удовлетвориться уверенным тоном. Хороший разработчик звучит убедительно, когда знает, и звучит так же убедительно, когда уверен, что знает. Отличить одно от другого можно только по конкретности: числа, имена полей, названия ролей, экраны. Если на пятом вопросе подряд ответ состоит из общих слов, дело не в вашем непонимании.

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

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

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

Двадцать вопросов команде до того, как агент получит реальные права