← Назад в «Платформизация» Платформы · Агенты · ESM · ИИ

Как единая платформа помогает эффективнее использовать агентов

Опубликовано: 2026-08-31T16:00:00 | Хабы: Платформы · Агенты · ESM · ИИ | Теги: агенты, платформа, itsm, автоматизация
Как единая платформа помогает эффективнее использовать агентов

Агент без платформы — это подсказка в вакууме: нет карточки обращения, нет CI, нет SLA и нет права «сделать шаг в процессе». Единая ESM-платформа как раз и даёт агенту контекст, границы и измеримый контур. Ниже — где это сокращает работу первой линии и где отдельный бот только добавляет шум.

Почему агент «рядом» слабее агента «внутри»

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

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

Поэтому модель либо отказывается помочь, либо отвечает уверенно и мимо. В единой платформе агент читает те же объекты, что и человек: обращение, услуга, актив, статья БЗ, задача. Подсказка появляется в карточке, а не во втором окне.

Что платформа даёт агенту

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

Каталог действий. Агенту разрешают не «всё, что умеет модель», а узкий список: предложить тему и услугу, собрать резюме, подтянуть статью, создать связанную задачу, пометить CI. Автозакрытие и смена SLA — только на whitelist и после правила, а не «потому что модель так решила».

База знаний как источник, а не как память модели. Черновик собирается из утверждённых статей и similar tickets. Ссылка на источник видна агенту. Нет статьи — нет автоответа, максимум эскалация человеку.

CMDB и зависимости. Маркировка инцидента, выбор группы, оценка blast radius опираются на связи сервиса и актива. Без CMDB агент классифицирует текст; с CMDB — ещё и контур влияния.

Один контур прав и аудита. Кто видел черновик, кто принял классификацию, какой ключ API дернул бота — в том же журнале, что и действия оператора. Отдельный SaaS-агент требует второй политики ИБ.

Где эффективность считается сразу

  1. Роутинг и классификация. Тема, услуга, приоритет, очередь. Диспетчер не разбирает поток вручную; агент предлагает, правило или человек подтверждает на старте пилота.
  2. Вход в контекст. Резюме длинной ленты, список уже проверенных гипотез, связанный CI. Минуты на «прочитать переписку» сжимаются, качество решения не обязано падать.
  3. L1 по покрытым услугам. Черновик из БЗ на массовых запросах (доступ, типовой сбой, стандартная заявка). Отправка — после агента, пока доля правок не станет низкой.
  4. Связанные работы. Инцидент → задача на изменение, пометка known error, черновик статьи после закрытия. Платформа держит объекты вместе, агент не «ходит» в Jira и wiki отдельно.

Пилот честно меряют не «процентом автоматизации», а минутами на обращение и долей перекладок по 4–5 услугам.

Что без платформы не заработает

  • Подтверждение в процессе. Модель предлагает, исполнитель жмёт «принять». Вне карточки это снова копипаст в тикет.
  • Песочница. Новый сценарий агента гоняют в Sandbox на масках данных, не на боевой очереди. Отдельный бот обычно сразу смотрит в прод или в пустую песочницу без CMDB.
  • Одинаковый UX. ITSM, HR, АХО — одна карточка, те же подсказки. Иначе для каждого контура свой агент и свой промпт.
  • Сквозная метрика. CSAT, CES, время до решения, доля принятых классификаций, доля черновиков без правок — на тех же обращениях. Связка систем собирает это ETL-ом.

Как внедрять, чтобы не получить второго диспетчера

Сначала платформа и процесс, потом агент — не наоборот.

  1. Зафиксировать услуги с понятным каталогом и БЗ.
  2. Включить агента на классификацию и резюме (низкая цена ошибки).
  3. Через две недели сравнить baseline: первая реакция, решение, перекладки, CSAT.
  4. Черновики ответов — только на услугах, где закрытия уже ссылаются на статьи.
  5. Автодействия — узкий класс, журнал, откат, владелец услуги.

Если агент переписывает больше половины черновика, это не «плохая модель», а дыра в БЗ или в форме запроса. Платформа это видно: нет статьи, нет поля, нет CI.

Итог

Единая платформа не «добавляет ИИ в ESM». Она делает агента участником того же контура, что и человек: объекты, права, знания, CMDB, SLA. Эффективность растёт на маршрутизации, контексте и шаблонных L1. Отдельный чат рядом с очередью экономит переписку в мессенджере и теряет процесс. Сначала одна модель данных и одно рабочее место — затем агенты на узком whitelist, с подтверждением и метриками на живых обращениях.