Карточка роли ИИ-сотрудника: как задать работу и момент передачи человеку

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

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

1. Назовите результат, а не настроение

Начните с одного предложения: «Агент принимает такие-то входы и создаёт такой-то проверяемый результат». Например: «Классифицирует входящее обращение, находит подтверждённый ответ в базе знаний, готовит ответ и создаёт заявку, если вопрос требует специалиста». Здесь видны вход, работа и выход.

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

2. Опишите зону ответственности

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

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

3. Зафиксируйте источники истины

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

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

4. Выдайте минимальные разрешения

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

В AiHummer агент имеет структурированный профиль, модель и навыки; изменения версионируются. Права административной поверхности и scoped-ключи позволяют ограничивать доступ. Однако наличие механизма не создаёт политику автоматически: конкретные роли, инструменты, учётные данные и возможности тарифа нужно настроить.

5. Сформулируйте триггеры эскалации

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

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

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

6. Опишите возврат управления

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

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

7. Проверьте карточку сценариями

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

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

Шаблон карточки

• Название и владелец роли.
• Бизнес-процесс и входящие типы запросов.
• Проверяемый результат.
• Канонические источники и их приоритет.
• Разрешённые операции чтения.
• Разрешённые операции записи.
• Действия только через одобрение.
• Явные запреты.
• Триггеры эскалации.
• Адресат, канал и контекст передачи.
• Правило возврата управления.
• Набор тестовых сценариев и дата пересмотра.

Назначьте владельца карточки

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

На пересмотре сравнивайте карточку с реальными журналами. Какие запросы чаще всего выходили за роль? Где человек возвращал задачу агенту? Какие источники устарели? Какие права не использовались и могут быть сняты? Изменение оформляйте новой версией и прогоняйте старый тестовый набор вместе с новыми случаями. Так карточка остаётся живым контрактом, а не обещанием, которое никто не проверяет. Полезный признак зрелости — возможность объяснить любое разрешение конкретным сценарием и удалить его, если сценарий исчез.

Источники и честные ограничения

См. официальные страницы «Агенты и персоны», «Гейты одобрения» и «RBAC и scoped API-ключи». Конкретная доступность RBAC, расширенного аудита, обязательных одобрений, каналов и интеграций зависит от тарифа и конфигурации. Карточка не заменяет настройку доступов и не гарантирует качество без тестов и актуальных источников.

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