Короткий ответ
#День, которого не было в календаре
Спросите у своей команды, когда ИИ-помощник в вашем продукте перестал быть чат-ботом. Обычно никто не может назвать дату, потому что решения в этот день никто не принимал. Была задача в трекере: «дать агенту доступ к статусам заказов, чтобы он не переспрашивал».
Хронология почти всегда одна и та же. Сначала агент подсказывает операторам формулировки, и его ошибка видна человеку до того, как её кто-то получит. Потом ему разрешают читать данные, чтобы ответы были точнее. Потом менять статус, чтобы не дёргать оператора. Потом отправлять письмо самому, потому что оператор всё равно только нажимал кнопку. Каждый шаг экономит время и выглядит как продолжение предыдущего.
Но эти шаги не однородны. Между вторым и третьим находится граница, после которой ошибка модели перестаёт быть текстом и становится событием в вашей системе. Эту границу переходят не решением, а подключением инструмента, поэтому её никто не замечает.
#Пять ступеней
Полезно разложить права агента по ступеням и увидеть, что растёт не его ум, а цена одной ошибки.
Высота это не сложность задачи, а то, какая часть ошибки переживёт её обнаружение.
| Ступень | Худшая единичная ошибка | Что должно быть до подключения |
|---|---|---|
| Советует человеку | Оператор отправил неточный ответ | Ничего особенного: ошибку видит человек до отправки |
| Читает данные | Показал одному клиенту сведения другого | Права на объект разговора, а не на таблицу; лимит на число записей |
| Меняет запись | Поменял статус, тариф или адрес доставки не тому | Журнал изменений с прежним значением и способ вернуть его обратно |
| Отправляет наружу | Письмо ушло не тому или с чужими данными внутри | Перепроверка факта другим способом, задержка или подтверждение |
| Делает необратимое | Возврат, удаление, изменение прав, публикация | Обязательное подтверждение, лимит суммы и заранее написанная компенсирующая операция |
Обратите внимание, что в третьей колонке нет ни одного пункта про модель. Всё, что там перечислено, делается в вашем приложении и остаётся верным при смене модели на любую другую.
#Четыре глагола
Разговор про права агента становится решаемым, когда его сводят к четырём глаголам. Для каждого подключённого инструмента ответьте, что агент через него может читать, менять, отправлять и удалять. Не «что он делает в нашем сценарии», а что технически позволяет доступ.
Разница между этими двумя вопросами и есть весь риск. Сценарий описывает намерение, доступ описывает возможность. Ошибается и обманывается модель внутри возможности, а не внутри намерения.
Агент поддержки получил доступ к CRM, чтобы видеть историю обращений клиента. В задаче так и написано: только чтение истории. Через API этот же токен позволяет читать всю базу контактов, выгружать её постранично и менять поля сделки, потому что роль в CRM была одна, «менеджер», и другой не нашлось.
Ни один человек не собирался давать агенту базу контактов. Её дал ответ на вопрос «какую роль ему выдать», принятый за двадцать секунд в конце пятницы.
#Почему список растёт сам
У этой темы есть неприятное свойство: она не стоит на месте, пока вы её не трогаете. Права агента добавляются по одному, каждый раз по уважительной причине, и почти всегда кем-то, кто не обязан думать о последствиях за пределами своей задачи.
Расходуется при этом не бюджет, а три других вещи. Во-первых, знание о том, что агент умеет: оно перестаёт быть у кого-то целиком примерно на пятом инструменте. Во-вторых, обратимость: каждое новое право с некоторой вероятностью необратимо, и компенсирующие операции никто не пишет заранее. В-третьих, время до обнаружения: чем больше действий совершается без человека, тем позже человек узнаёт, что одно из них было не тем.
Через три месяца это выглядит так: инструментов стало вдвое больше, список нигде не записан, а у токена агента те же права, что были выданы в первый день, потому что менять их никто не просил. Через год к этому добавляется то, что первых участников разговора в компании уже нет. Ответ на вопрос «что наш агент может сделать с базой клиентов» становится исследованием на несколько дней.
Дешёвый способ этого избежать один и он скучный: список прав пересматривается вместе с изменением интеграций, а не по расписанию. Любое подключение это повод перечитать таблицу из четырёх глаголов, и это занимает минуты, пока таблица существует.
#Инвентаризация на неделю
Это работа не на квартал. Список инструментов у любого агента короткий, обычно от трёх до десяти. Возьмите таблицу с четырьмя глаголами и заполните её по каждому. Там, где вы не знаете ответа, поставьте вопрос и спросите разработчика: это и есть самая ценная часть упражнения.
По каждому подключённому инструменту
Отвечайте по тому, что позволяет доступ, а не по тому, что задумано в сценарии.
- Что агент может прочитать через этот инструмент в худшем случае и сколько это записей? Ответ «всё, что видит роль» означает, что объём чтения равен базе.
- Что он может изменить и остаётся ли запись о прежнем значении? Без прежнего значения откат превращается в реконструкцию по памяти.
- Что он может отправить за пределы компании и куда именно? Отправка единственное действие, которое нельзя отменить никаким способом.
- Что он может удалить или сделать необратимым, включая деньги и права? Эти действия должны требовать подтверждения, и подтверждение должно показывать последствия.
- Под какими учётными данными он это делает и есть ли у них срок? Общий административный токен делает ответы на предыдущие вопросы максимально широкими.
- Кто и через сколько минут узнает, что агент сделал что-то не то? Время незамеченности умножает любую ошибку.
Заполненная таблица полезна сама по себе, даже если вы ничего не станете менять. Она превращает вопрос «мы нормально настроили ИИ?» в список конкретных решений, каждое из которых можно принять за один вечер.
Держать её стоит там же, где описание системы, а не в отдельном документе про ИИ. Права агента это часть картины интеграций: он такой же участник обмена данными, как платёжный провайдер или сервис рассылки, только с большей свободой в выборе действия. Отдельный документ живёт до первого отпуска его автора, а список интеграций читают при каждом изменении.
#Почему это решение владельца
Возражение звучит так: это же техническая деталь, зачем этим заниматься владельцу. Затем, что подключение инструмента меняет не техническую характеристику, а то, что компания может потерять за одну ночь. Это тот же класс решений, что выдача права подписи или доступа к расчётному счёту, и он не становится техническим от того, что оформляется строкой в конфигурации.
Первый шаг занимает час и не требует ничьего разрешения. Выпишите инструменты, которые уже подключены, и по каждому ответьте на четыре глагола так далеко, как знаете сами. Остальное отправьте разработчику одним сообщением. Через день у вас будет документ, которого раньше не существовало, и он же будет ответом на вопрос корпоративного клиента, когда тот его задаст.
Практически достаточно одного правила: новый инструмент у агента подключается решением, а не задачей. Решение занимает пять минут и состоит из ответа на четыре глагола, названия худшего единичного случая и ответа на вопрос, кто узнает об ошибке и через сколько. Если этот разговор не проходит за пять минут, значит, нужен не разговор длиннее, а инструмент с более узкими правами.
#Что обычно происходит
Это же просто чат-бот, он только отвечает клиентам.
Вместо этого Посмотрите перечень инструментов, а не описание задачи. Если среди них есть отправка письма и изменение заказа, это исполнитель, и оценивать его надо как исполнителя.
Проверили на хороших сценариях, всё отвечает правильно.
Вместо этого Проверяйте на плохих: неоднозначная просьба, противоречивое сообщение, текст с инструкцией внутри, клиент с двумя похожими заказами. Класс риска проверяется худшим случаем, а не средним.
Права выдали по существующей роли, потому что другой не было.
Вместо этого Роль человека почти всегда шире, чем нужно агенту, и содержит массовые операции. Заведите отдельную учётную запись с правами ровно на сценарий и со сроком жизни.
Решили, что человек в цикле закрывает вопрос.
Вместо этого Человек в цикле работает, пока у него есть время смотреть. Считайте число подтверждений в час и показывайте в них последствия, а не вопрос «продолжить?».
#Чего это не гарантирует
Чего это не делает
- Инвентаризация не делает агента умнее и не уменьшает вероятность ошибки.
- Она не защищает от инъекции инструкций: агент по-прежнему читает текст, который ему присылают.
- Она не заменяет мониторинг. Список прав это статика, а инцидент происходит во времени.
- Заполненная таблица устаревает при каждом новом подключении, поэтому её пересматривают вместе с изменением интеграций.
- Она не отвечает на вопрос, нужен ли агенту этот инструмент вообще. Иногда та же задача решается обычным кодом, без модели и без прав, и это лучший из доступных ответов.
- Остаточный риск остаётся. Цель в том, чтобы вы знали его размер заранее.
Назовите дату, когда ваш ИИ-помощник получил первое право на изменение данных, и посчитайте, сколько инструментов у него появилось после. Кто в компании держит этот список целиком?