Формулировка «искусственный интеллект в управлении ИТ-активами» сегодня встречается все чаще, но за ней скрывается очень разное: от аккуратной автоматизации рутины до обещаний, которые не выдерживают первого же пилота. Ниже — практический разбор: какие задачи ИИ в ITAM уже решает на реальных данных, где заканчивается реальная польза и начинаются маркетинговые обещания и как должна быть устроена система, чтобы ИИ приносил пользу, а не создавал новый источник недостоверности.
У крупной организации данные об ИТ-активах почти никогда не отсутствуют. Проблема в другом: они разбросаны по десяткам источников — discovery, виртуализация, CMDB, учетные системы, заявки, средства ИБ — и в каждом описаны по-своему. Один и тот же продукт называется тремя разными способами, серверы задвоены, у актива нет владельца, характеристики в двух системах не совпадают.
Именно поэтому запрос на ИИ в ITAM вообще возник. Ручная нормализация справочников и сверка источников не масштабируются: человек физически не успевает приводить к единому виду сотни тысяч записей и ловить расхождения. Это и есть та зона, где ИИ действительно уместен — не «умное управление активами вообще», а конкретная работа с грязными, неоднозначными данными.
Есть четыре задачи, где ИИ дает измеримую пользу уже сегодня, потому что все они о распознавании и сопоставлении.
Классификация активов и ПО. Входное описание вида «айфон 15 128 черный» модель приводит к нормализованной номенклатурной позиции: производитель, модель, тип актива, обязательные атрибуты. Там, где жесткого правила недостаточно — нестандартное описание, неизвестная модель, смешанный язык — подключается языковая модель few-shot.
Сопоставление сущностей и поиск дублей. ИИ находит, что «одно и то же» в разных источниках записано по-разному, и предлагает кандидатов на объединение. Это снимает главную головную боль консолидации — задвоенные активы, из-за которых любая отчетность и любой расчет эффекта оказываются кривыми.
Извлечение характеристик. Из неструктурированных описаний модель вытаскивает значимые атрибуты и раскладывает их по нужным полям — вместо ручного разбора наименований оператором.
Проверка данных на расхождения. Система подсвечивает записи, которые выбиваются из общей картины: неправдоподобные значения и расхождения между тем, что заявлено в учете, и тем, что обнаружено в сети (discovery). Это не «сам все исправил», а «покажи человеку, где смотреть».
Стоит рассмотреть и обратную сторону — формулировки, которые на пилоте важно проверять особенно внимательно.
● «ИИ заменяет ITAM». Это не так. ИИ закрывает распознавание и сопоставление данных. Это узкий, хоть и важный слой. Учет жизненного цикла, связи активов, лицензионные права, финансы, процессы — это по-прежнему система и люди.
● «Самоуправляемый учет». Автономное автозаполнение на грязных данных — это способ быстро и незаметно испортить справочник. Чем увереннее система заполняет все сама, тем меньше ей можно доверять.
● «ИИ принимает решения». В управлении активами цена ошибки — неверная закупка, ложное списание, сорванный аудит. Решение должно оставаться за человеком и правилами, а не за вероятностной моделью.
● «Черный ящик, который просто работает». Если нельзя объяснить, почему актив классифицирован так, а не иначе, результат невозможно проверить, а значит, и защитить перед ИБ или аудитом.
Рабочий ИИ в ITAM — это слоеная схема, где каждый слой обрабатывает то, что не смог предыдущий, а самый дорогой инструмент подключается последним:
● Жесткие правила — регистр, единицы, аббревиатуры, стоп-слова.
● Справочники — производитель, модель, тип актива из эталонного каталога НСИ.
● Шаблоны типов — обязательные атрибуты и формат наименования для каждого класса активов.
● LLM / few-shot — только то, что не разобрали правила и справочники: нестандартные описания, неизвестные модели, смешанный язык.
● ИИ-ассистент — уточняющие вопросы, кандидаты, объяснение принятого решения.
Поверх слоев — три вещи, которые превращают «ИИ-фичу» в промышленный инструмент.
Порог доверия: модель оценивает свою уверенность, и при низком значении результат не применяется автоматически, а уходит оператору как задача.
Fallback: при недоступности языковой модели система не встает, а продолжает работать на правилах и справочниках.
Аудит: каждое решение, принятое моделью, журналируется — входные данные, результат, уровень доверия, принятое действие.
Отдельно — контур безопасности, без которого ИИ в enterprise просто не пустят: закрытая изолированная среда, маскирование чувствительных полей до передачи в модель, ролевой доступ к ИИ-функциям, явная политика о том, какие категории данных вообще разрешено отдавать в модели ИИ и гибкое размещение модели (on-premise или private cloud) под требования ИБ заказчика.
Самое интересное начинается за пределами разовой нормализации — это направление, в котором развивается продукт, а не уже закрытая задача. Найти ошибку — полдела. Ценность выше, когда система не просто исправляет отдельную запись, а предлагает правило нормализации или контроля, объясняет его логику и передает человеку на подтверждение. Принятое правило дальше работает детерминированно и воспроизводимо — то есть ИИ помогает создавать и развивать правила, а промышленный контроль остается управляемым и предсказуемым.
Это и есть здоровая модель: ИИ и детерминированные правила не конкурируют, а усиливают друг друга. Языковая модель берет на себя неоднозначность и разнообразие входных данных, а правила и справочники обеспечивают стабильность и проверяемость результата.
ИИ в ITAM работает, но ровно там, где он и должен: на распознавании, сопоставлении и поиске расхождений в грязных данных. Он ускоряет то, что раньше делали руками, и подсвечивает то, что человек не успел бы заметить. Чего он не делает: не заменяет систему учета, не управляет активами сам и не принимает решений без контроля. Практический критерий, по которому стоит оценивать любое «ИИ в ITAM»: можно ли объяснить и проверить каждое его действие, и остается ли последнее слово за человеком. Если да — это инструмент. Если «оно само все решает» — это маркетинг.
Заменит ли ИИ специалистов по учету ИТ-активов?
Нет. ИИ снимает рутину — нормализацию, поиск дублей, разбор описаний — и высвобождает людей для задач, где нужны решения и контекст. Ответственность за решения остается за человеком.
Можно ли доверять автозаполнению атрибутов на основе ИИ?
Только с порогом доверия. При высокой уверенности модели результат можно применять, при низкой — он должен уходить оператору на проверку. Автозаполнение «на все подряд» без оценки уверенности быстро загрязняет справочник.
Безопасно ли пускать ИИ во внутренний контур с данными об инфраструктуре?
Да, если контур закрытый: изолированная среда, маскирование чувствительных полей до передачи в модель, ролевой доступ, явная политика по категориям данных и размещение модели on-premise или в private cloud. Тогда чувствительные сведения не покидают периметр.
Чем ИИ-нормализация отличается от обычных правил?
Правила надежны, но не справляются с разнообразием входных данных, нестандартными описаниями и неизвестными моделями. ИИ закрывает именно эту зону, а затем помогает превратить найденную закономерность в новое правило. Лучшая схема — не «или-или», а сочетание того и другого.