Обсуждая на учебном курсе «VAP: Применение ИИ в ITSM и ESM» вопрос о причинах провала пилотных проектов по внедрению ИИ, мы заметили, что дело бывает не в плохой модели, а в неправильно выбранных инструментах под решаемую задачу. В дополнение к этой темы, думаю будет любопытно ознакомиться с мнением Иэна Кокса (Ian Cox) — основателя и генерального директора консалтинговой компании, специализирующейся на ITSM-инструментах.
Пилотные проекты ИИ-агентов для управления ИТ-услугами ITSM, которые впечатляют на демонстрации, а затем останавливаются в промышленной эксплуатации, обычно проваливаются не из-за модели. Причина — в данных, на которых она работает. И это проблема компетенций, а не технического долга.
Почему пилоты ИИ-агентов часто не доходят до успеха в продуктиве
Сегодня в корпоративном ИТ снова и снова повторяется один и тот же сценарий. Команда запускает ИИ-агента для ITSM в своей платформе. На демо всё выглядит впечатляюще: агент классифицирует инциденты, отвечает на вопросы, выполняет запросы без участия человека. Руководство довольно, бюджет одобрен.
Но где-то между пилотом и промышленной эксплуатацией решение постепенно теряет доверие. ИИ-агент начинает уверенно ошибаться в реальных ситуациях. Сотрудники возвращаются к прежнему способу работы. Проект не столько официально закрывают, сколько тихо перестают использовать.
Почему проблема не в ИИ-модели
Когда это происходит, первой реакцией обычно становится обвинение модели. Но проблема не в ней.
ИИ-агент для ITSM настолько хорош, насколько хороши данные, на основе которых он рассуждает. В большинстве организаций этим данным — CMDB, реестрам активов, картам сервисов — нельзя полностью доверять.
Если направить даже очень сильного агента на CMDB, которая заполнена лишь наполовину, содержит дубли конфигурационных единиц (КЕ) и не имеет необходимых связей между ними, результат будет предсказуемым: агент начнёт быстрее масштабировать неверные решения, причём с незаслуженной уверенностью автоматизированной системы.
Что на практике означает «данным нельзя доверять»
Важно конкретизировать, что именно означает ненадёжность данных.
У вендоров принято рассматривает качество данных через три ключевых аспекта, каждый из которых напрямую связан с последствиями для бизнеса.
Три составляющие качества данных CMDB
Полнота.
Присутствуют ли нужные конфигурационные единицы, назначены ли владельцы, описаны ли отношения между объектами? Пробелы здесь создают слепые зоны при анализе влияния изменений и инцидентов.
Соответствие требованиям.
Соответствуют ли записи стандартам данных: заполнены ли обязательные поля, соблюдается ли Common Service Data Model CSDM, правильно ли настроены правила идентификации и сверки? Недостатки здесь приводят к дрейфу данных и появлению дублей.
Корректность.
Актуальны ли данные, устранены ли дубли, можно ли им доверять? Недостатки в этой области объясняют, почему команды обходят CMDB стороной, вместо того чтобы использовать её в работе.
ИИ-агент, который работает с данными, слабыми хотя бы по одному из этих направлений, — это не инструмент повышения производительности. Это риск с дружелюбным интерфейсом.
Почему это дефицит компетенций, а не технический долг
Вот что часто удивляет: исправление ситуации почти никогда не требует внедрения новых технологий.
Практически во всех проблемных случаях, которые я вижу, ITSM-платформа вполне работоспособна, а лицензии уже оплачены. Не хватает другого — внутренней дисциплины и компетенций для качественного управления данными средствами самой платформы:
- настройки сверки и согласования, чтобы Discovery не создавал дубликаты;
- полноценного картирования зависимостей, чтобы связи между компонентами действительно существовали;
- выравнивания с CSDM, чтобы модель данных имела единый и понятный смысл;
- регулярного управления качеством данных, чтобы улучшения сохранялись со временем.
Это не технический долг. Это дефицит навыков. Различие критически важно, потому что способы решения противоположны. Технический долг предполагает: «демонтировать и начать заново». Дефицит компетенций означает: «у вас уже есть почти всё необходимое, но вы не используете платформу так, как она должна использоваться».
Четыре шага к ИИ-агентам, которым доверяют
Это хорошая новость для тех, чей пилот ИИ-агента в ITSM разочаровал. Не нужно ждать более совершенной модели и не нужно менять платформу. Нужно довести качество данных, на которых работает агент, до уровня, которому действительно доверяют ваши команды.
После этого появляются и измеримые результаты. Автор наблюдал, как на очищенных данных агент для сортировки отклонял или решал примерно 20% обращений при успешности выполнения задач около 94%. Не потому, что использовалась уникальная модель — это была модель того же класса, что и в других местах, — а потому, что данным, на которых она основана, можно было доверять.
Вот рекомендуемая последовательность действий.
- Сначала стабилизируйте данные, затем расширяйте область применения.
Очистите конкретный фрагмент CMDB, с которым работает агент: классы КЕ и сервисы в его зоне ответственности. Узкоспециализированный агент на достоверных данных лучше широкого агента на ненадёжных данных. - Оставьте людям принятие решений.
Пусть агент выполняет повторяемую, массовую работу, а люди отвечают за исключения и управленческие решения. Так агент ITSM постепенно обретает автономность: доверие предоставляют поэтапно, а ранние ошибки разрушают его быстрее, чем ранние успехи укрепляют. - Жёстко ограничьте охват.
Сначала добейтесь качественного выполнения одной задачи и только затем расширяйте функциональность. Агенты ИИ, которые проваливаются в продуктиве, нередко были теми, кто произвел фурор на демонстрации именно потому, что от них требовалось слишком много. - Управляйте точностью как ключевой метрикой.
Измеряйте долю успешного выполнения задач агентом ИИ ITSM так же, как измеряли бы показатели любой критически важной системы, и быстро корректируйте отклонения. CMDB сильна настолько, насколько сильна её самая слабая составляющая; ИИ-агент мгновенно наследует эту слабость.
Лучшие данные дают лучшие результаты ИИ-агента
В этом нет ничего экзотического — и именно в этом суть. Организации, которые получают реальную выгоду от ИИ в 2026 году, не обладают эксклюзивным доступом к более качественным моделям. Сегодня у всех примерно одинаковый доступ к моделям. Преимущество получают те, кто выполнил неброскую, но необходимую работу: сначала сделал данные достоверными.
Конкурентное преимущество незаметно переместилось от алгоритма к данным, лежащим в его основе. А значит — к набору навыков, которые многие команды пропустили, сосредоточившись на покупке и внедрении ITSM-платформы.
Сначала готовность к ИИ, потом новые покупки
Если пилот вашего ИИ-агента для ITSM выглядел блестяще, но затем остановился, не спешите искать новую технологию. Проблема почти наверняка находится в CMDB. И решение почти наверняка заключается в развитии или привлечении нужных компетенций, а не в покупке нового продукта.
Устраните пробел в навыках и тот ИИ-агент, который у вас уже есть, начнёт выполнять то, что обещал на демонстрации.
Оригинал статьи здесь.
