ИИ-агенты в техподдержке выполняют действия сами и ломают логику тикета

С конца 1980-х, когда появились первые системы учёта заявок и первая версия ITIL, поддержка считает свою работу в тикетах. Обращение приходит, его назначают на исполнителя, закрывают и замеряют время. Прошло почти четыре десятилетия, и эта схема трескается: ИИ-агенты уже выполняют действия в нескольких системах сразу, разблокируют учётные записи, выдают доступы и перезапускают службы. Если заявку никто не берёт в работу, остаётся вопрос, чем тогда измерять поддержку. Его и разбирает Habr AI. Ниже изложена суть разбора и наши выводы из неё.

Почему тикет так долго был главной единицей

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

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

Что остаётся от заявки

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

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

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

Чем измерять поддержку

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

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

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

С чего начинать на практике

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

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

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