С конца 1980-х, когда появились первые системы учета заявок и первая версия ITIL, главной единицей работы техподдержки остается тикет. Сейчас эту схему учета приходится пересматривать, потому что ИИ-агенты уже выполняют действия в нескольких системах сразу: разблокируют учетные записи, выдают доступы, перезапускают службы. Разбираемся, к чему это приводит, что остается от заявки, когда ее некому брать в работу, и чем тогда измерять поддержку.

Всем привет, это команда продукта SimpleOne ITSM. Сразу оговоримся: тикеты никуда не исчезнут, речь только о потоке типовых запросов, на который уходит большая часть времени первой линии. Такие заявки все чаще ведет сам ИИ-агент и записывает в них, что сделал.

Зачем поддержке тикет

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

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

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

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

Что меняется, когда запрос решает ИИ-агент

Если расписать по шагам типичный запрос, видно, сколько в нем ручной работы. Пользователь пишет: «не могу войти, пишет, что учетная запись заблокирована». Заявка регистрируется и попадает в очередь первой линии, дежурный берет ее в работу, заходит в консоль Active Directory, разблокирует учетную запись, сбрасывает пароль, сообщает временный и закрывает тикет. Каждый из этих шагов нужен потому, что в процессе участвует человек: ему передают задачу, и с него потом спрашивают результат.

Теперь представим, что тот же запрос обрабатывает ИИ-агент с доступом к AD. Он проверяет личность пользователя вторым фактором, находит учетную запись и видит, что ее заблокировала серия неудачных попыток входа. Агент проверяет, что попытки шли с устройства самого пользователя, разблокирует учетную запись, сбрасывает пароль, отправляет временный на канал, привязанный к учетной записи, и убеждается, что вход прошел. Если попытки шли с чужих устройств или адресов, агент ничего не разблокирует и передает обращение в службу ИБ.

Все шаги выполняет один исполнитель, передавать задачу никому не приходится, и очередь в этом сценарии не нужна. Сброс пароля без очереди давно умеют порталы самообслуживания (SSPR), но там пользователь сам выбирает действие в меню. Агент понимает запрос в свободной форме и сам решает, что делать, поэтому на этом примере видно, сколько ручной работы он забирает у первой линии и где может ошибиться. Тикет, вокруг которого тридцать лет строилась работа поддержки, для таких запросов перестает служить очередью, а именно для этого он и появился.

Gartner в пресс-релизе от марта 2025 года прогнозирует, что к 2029 году агентный ИИ будет без участия человека решать 80% типовых обращений в клиентской поддержке. Во внутренней поддержке у агента больше данных и доступов: каждый пользователь уже есть в каталоге учетных записей, а системы, в которых нужно действовать, принадлежат самой компании. Основной поток здесь составляют однотипные запросы: сброс пароля, доступ к сетевой папке, лицензия, добавление в рассылку. Но и ошибка обходится дороже: агент меняет пароли и права доступа в корпоративных системах, и одно неверное действие оставит сотрудника без доступа к работе или откроет ему чужие данные.

Крупные инциденты, изменения и все, что требует согласования, по-прежнему ведут люди, и для них заявка остается способом договориться о работе. Через очередь перестает проходить поток простых запросов, ради которого компании держат целую первую линию. Это учитывают и в ITIL: в 2026 году PeopleCert выпустила пятую версию фреймворка и отдельный модуль ITIL AI Governance о контроле над работой ИИ в сервисном управлении. 

К чему приводит работа без очереди

Тикет давал поддержке четыре вещи: ответственного за каждое решение; отчеты, в которых за закрытой заявкой стояла работа сотрудника; поток заявок, по которому видны массовые сбои; простые запросы, на которых учились новички. Пока ИИ-агент решает несколько десятков запросов в день, разницу почти не видно. Когда через него проходит большая часть типовых обращений, поддержка начинает терять все четыре.

1. Непонятно, кто отвечает за результат

Когда заявку закрывал дежурный, за каждым решением стоял конкретный сотрудник. У действия ИИ-агента такого человека нет: запрос обработал агент, сценарий настроил администратор, права выдала служба ИБ. В материале ISACA 2025 года это называют одной из главных проблем аудита агентного ИИ: если агент действует сам, неясно, кто отвечает за его решение.

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

2. Отчеты завышают долю автоматизации

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

3. Новичкам негде учиться

Именно на типовых заявках сотрудники первой линии разбирались в инфраструктуре компании, прежде чем перейти на вторую. Если такие запросы забирает агент, первая линия сокращается, и непонятно, где будущие инженеры второй линии получат опыт. Исследователи Стэнфорда в работе 2025 года по данным за США фиксируют относительное снижение занятости на 13% среди работников 22–25 лет в профессиях, наиболее подверженных влиянию ИИ. Сильнее всего спад там, где ИИ выполняет задачи вместо человека, а типовые заявки первой линии относятся как раз к таким задачам. 

Что считать тикетом и как следить за ИИ-агентом

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

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

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

1. ИИ ответил: дал инструкцию или ссылку на статью базы знаний. Пользователь получил консультацию, но решил ли он свою задачу, неизвестно.

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

3. Результат подтвержден: пользователь вошел в систему, папка открылась, сервис отвечает. Решенным можно считать только такое обращение.

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

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

• кто его инициировал: пользователь, событие мониторинга или другой агент;

• по каким данным агент выбрал объект, например учетную запись Петрова;

• что сделано, в какой системе и с какими правами;

• как проверили результат;

• как откатить действие, если результат оказался не тем.

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

Журнал помогает и с вопросом ответственности, если у агента правильно настроены права. Когда ИИ-агент работает под сервисной учеткой с правами администратора домена, в логах остается только «действовал svc_admin» без указания, по чьему запросу. Надежнее ограничить агента матрицей прав: сбрасывать пароль он может, менять членство в привилегированных группах нет, а для доступа к финансовым системам запрашивает согласование человека. Тогда по каждому действию видно, кто его запросил и кто разрешил.

Вести журнал удобнее там, где учитывается работа поддержки. Если записи о действии хранятся по отдельности в логах AD, мониторинга и Jira, то для метрик или расследования инцидента придется вручную сопоставлять события из трех систем по времени и имени учетной записи. В ITSM-платформе уже есть каталог услуг, CMDB, SLA и права, поэтому журнал действий ИИ-агента логично вести там же и связывать с записью об обращении. Копию журнала для расследований ИБ отправляют в SIEM.

В SimpleOne агенты собираются в конструкторе ИИ-агентов и действуют от имени пользователя, который запустил сессию, поэтому получить данные, недоступные этому пользователю, агент не может. Каждый шаг агента записывается в журнал платформы: администратор видит, какие инструменты агент вызвал, какие данные запросил и что получил в ответ. Подробнее об архитектуре и модели прав мы рассказали в статье на Хабре «Как мы встроили ИИ-агентов в платформу».

Резюме

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

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

А как вы учитываете работу ИИ-агентов в своей поддержке: заводите тикет на каждое обращение или считаете только то, что дошло до людей? Расскажите в комментариях.