Ограничители ИИ чат-бота: чего он не должен делать никогда

Сказать, сделать, пообещать — три разных разрешения

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

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

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

Разрешения на чтение: что бот может видеть

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

• Сначала личность: бот может читать только собственную карточку клиента и только после того, как личность подтверждена по заданному вами стандарту. «Он назвал номер в чате» подтверждением личности не является.
• Ограничения на уровне полей: статус заказа — не то же, что платёжные данные, а факт существования аккаунта — не то же, что его содержимое. Решайте по полям, а не по таблицам.
• Никогда не раскрывайте данные других клиентов через агрегированные ответы. «Сколько человек это заказали?» — невинный на вид вопрос с протекающим ответом.
• Внутренний материал должен быть помечен как внутренний. Логика цен, заметки о марже, политики эскалации и условия поставщиков регулярно попадают в базу знаний просто потому, что лежали в той же папке.
• Считайте, что любое чтение может повторить недоброжелатель. Если ответ показывает, есть ли номер телефона в вашей системе, это инструмент перебора.

Разрешения на запись: что бот может менять

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

1. 1Перечисляйте действия поштучно, а не категориями«Может управлять заказами» — не разрешение, а приглашение. «Может создать заявку на обратный звонок» и «может перенести дату доставки на более позднюю в рамках политики» — разрешения.
2. 2Разрушительные действия требуют человекаОтмена, возврат, удаление, закрытие аккаунта. Бот может собрать всё необходимое и подготовить; кнопку нажимает человек. Одно это правило снимает большую часть риска инцидента почти без ущерба для клиентского опыта.
3. 3Ограничивайте каждый параметрЕсли бот может переносить запись, задайте, насколько вперёд, сколько раз и в какие часы. Действие с неограниченным параметром — это то, которое найдут.
4. 4Логируйте каждое действие вместе с разговоромНе только что оно произошло, но и какой разговор его вызвал. Без этого разобрать спорное действие невозможно.
5. 5Каждое действие либо обратимо, либо требует утвержденияЕсли его нельзя отменить и оно не требует человека, вы приняли риск, с которым никто явно не соглашался.

Обещания: на что бот может брать обязательства

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

• Цены: бот может называть опубликованные цены и не должен вычислять неопубликованную, применять скидку или подтверждать, что цена сохранится.
• Скидки и исключения: никогда, без исключений. Это самое частое место, где автоматизация наносит коммерческий ущерб.
• Доставка и сроки: только опубликованные окна. Придуманное из общих соображений «должно прийти к пятнице» — обещание, которого курьер не давал.
• Наличие: только из живых данных, никогда из проиндексированного документа. Утверждения об остатках устаревают быстрее любого другого факта.
• Исходы: бот не должен обещать, что жалоба будет решена определённым образом, что возврат одобрят или что позвонит конкретный человек.
• Всё юридическое и регуляторное: ни обещания, ни толкования, ни заверения.

Вызовы инструментов и внешние системы

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

• Заведите список разрешённых адресов. Бот, способный вызвать произвольный адрес, переданный во время работы, может быть направлен в вашу внутреннюю сеть.
• Никогда не позволяйте содержимому разговора определять адрес назначения. Сообщение клиента — недоверенный ввод; относитесь к нему так на каждой границе.
• Ограничивайте доступы ровно тем, что нужно действию, и никогда не давайте универсальный админский токен.
• Явно задайте поведение при таймауте. Когда живой запрос не проходит, бот должен сказать, что не смог проверить, а не откатиться к правдоподобной догадке.
• Ограничивайте частоту по разговору и по клиенту, чтобы один разговор не превратился в генератор нагрузки на ваши же системы.
• Считайте всё, что вернул инструмент, данными, а не инструкцией. Карточка, в поле которой лежит текст, указывающий боту следующий шаг, — это реальная атака.

Кто что утверждает

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

1. 1Владелец материала утверждает, что бот может говоритьГраницы зоны, темы вне зоны, формулировки фолбэков.
2. 2Владелец системы утверждает, что бот может делатьКаждое действие, каждую границу параметра, каждый объём доступа и сопутствующее логирование.
3. 3Коммерция или юристы утверждают, что бот может обещатьФормулировки о ценах, язык о доставке, работу с жалобами и всё, что может стать обязательством.
4. 4Пересматривайте при каждом изменении возможностейНовый канал, новая интеграция, новое действие, новый рынок. У разрешений, выданных для пилота, есть привычка доживать до продакшена непересмотренными.

Как ограничители устроены в Vexvon

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

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

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

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

Частые вопросы

1. 1Что такое ограничители ИИ чат-бота?Правила, определяющие, что бот может говорить, что делать и что обещать. Это три отдельных разрешения с тремя разными владельцами, и последнее отсутствует чаще всего.
2. 2Должен ли чат-бот вообще совершать действия?Да — ограниченные и обратимые: запись, создание лида, обновление предпочтения. Разрушительные действия вроде отмены, возврата и удаления бот должен подготавливать, а выполнять человек.
3. 3Какое разрешение самое опасное?Неограниченный доступ на запись, описанный категорией, а не действием. «Может управлять заказами» — не разрешение, а приглашение выяснить, что в это входит.
4. 4Может ли бот предложить скидку?Он не должен иметь такой возможности никогда. Скидки и исключения — самый частый способ, которым разговорная автоматизация наносит коммерческий ущерб, и выманить их у бота, которому позволено пробовать, крайне легко.
5. 5Как защищать вызовы инструментов?Список разрешённых адресов, запрет на выбор адреса содержимым разговора, узкие доступы, заданное поведение при таймауте, ограничение частоты по разговору и отношение к выводу инструмента как к данным, а не инструкции.
6. 6Кто должен утверждать разрешения?Три группы: владелец материала — что говорит, владелец системы — что делает, коммерция или юристы — что обещает. Назовите их в документе.

Напишите три списка на этой неделе

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