ITAMforLLM-5. Управление ИТ-активами в эпоху ИИ: эволюция ITAM под специфику ИИ-решений

Всем привет! Меня зовут Дмитрий Крупенин, я создаю внутренние и B2B ИТ-решения. Специализируюсь на цифровых продуктах для внутреннего использования в корпорациях. 

Сейчас очень активно развиваются продукты и решения с использованием ИИ, однако не всегда удается легко посчитать экономику таких проектов, если мы говорим о необходимости развертывания этих решений внутри. Это может быть необходимо для крупных компаний (особенно банков и биг.теха), где законодательно нельзя отдавать персональные и корпоративные данные в облачные модели ЛЛМ. Хочется разобраться, как посчитать совокупную стоимость владения таким проектом, с учетом инфраструктуры, модели, данных для обучения ^[1] и т.д. Так как это потребовало довольно объемного изучения предметной области – пришлось разбить материал на несколько статей:

• • Статья 1: “Специализированное оборудование”. Исследовательская статья, как эволюционировали решения для ИИ и почему. LLM-1. Специализированные решения для ИИ-кластеров ^[2]

  • Статья 2: “Архитектура ИИ-инфраструктуры: от GPU-кластеров до облачных решений” Комплексный обзор современных подходов к построению инфраструктуры для ИИ. LLM-2. Архитектура ИИ-инфраструктуры: от GPU-кластеров до облачных решений ^[3]

  • Статья 3: “Total Cost of Ownership (TCO) для ИИ-проектов: полная методология расчета”. Комплексная методология оценки совокупной стоимости владения ИИ-решениями. LLM-3. Total Cost of Ownership (TCO) для ИИ-проектов: полная методология расчет ^[4]а

  • Статья 4: “Аллокация затрат на ИИ: модели распределения и тарификации” Разработка справедливых моделей распределения затрат на ИИ-ресурсы. LLM-4. Аллокация затрат на ИИ-кластер: методология расчета ^[5]

  • Статья 5: “Управление ИТ-активами в эпоху ИИ: эволюция ^[6] ITAM”. Адаптация практик управления ИТ-активами под специфику ИИ-решений.LLM-5. Управление ИТ-активами в эпоху ИИ: эволюция ITAM”. Адаптация практик управления ИТ-активами под специфику ИИ-решений [Вы здесь]

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

• кадровые компетенции и интеллектуальные активы, представляющие собой накопленные знания и опыт ^[7] специалистов; 

• финансовые ресурсы, характеризующиеся постоянной циркуляцией в процессе операционной деятельности; управленческие ресурсы, обеспечивающие координацию и контроль процессов; 

• информационные активы, включающие формализованные знания, документацию, базы данных и информационные системы; 

• материально-техническое обеспечение в виде ИТ-оборудования, включая серверы, рабочие станции, сетевую инфраструктуру и облачные вычислительные мощности; 

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

Без понимания что мы имеем, кто этим пользуется и где (в каком дата-центре, в какой серверной стойке, в каком офисе и тп.) находятся те или иные активы управлять ИТ очень сложно (мы тут говорим к крупном кровавом энтерпрайзе, где кол-во серверов исчисляется сотнями, тысячами, десятками тысяч). Т.е. под управлением ИТ-активами (ITAM) понимается набор взаимосвязанных процессов, нацеленных на решение вопросов учёта, финансового контроля и контрактных обязательств, связанных с ИТ-активами, на протяжении всего жизненного цикла – от закупки до вывода из эксплуатации. Простую и понятную инфографику про процессы ITAM и их эволюцию я когда-то давно делал тут: https://itam2.ru/blog/variantyi-razvitiya-proczessov-itam-infografika ^[8] и тут https://itam2.ru/blog/infografika-chto-takoe-itam ^[9] 

В современном контексте к перечню категорий ИТ-активов выше добавляются ИИ-активы – модели машинного обучения, датасеты, вычислительные ресурсы для обучения нейронных сетей, которые требуют специального подхода к управлению и учету в системе ITAM организации.

Что такое ИТ-актив в классическом понимании

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

Картинка взята с сайта https://itam2.ru/blog/edinoe-informaczionnoe-prostranstvo-dlya-upravleniya-it-aktivami-otkryivayushhiesya-vozmozhnosti-i-problemyi ^[10] 

Жизненный цикл ИТ-актива: от потребности к утилизации

Жизненный цикл физического ИТ-актива, будь то персональный компьютер или серверное оборудование, начинается с момента возникновения потребности ^[11] в нем и заканчивается полной утилизацией.

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

• Затем наступает фаза управления и изменений. Она начинается с постановки ИТ-актива на учет по факту его реального появления в компании (физически привезли сервер или отгрузили ключи лицензий ПО). Этап охватывает весь период эксплуатации актива, в течение которого выполняются все необходимые изменения конфигурации, проводится техническое обслуживание, устанавливаются обновления и патчи безопасности, и ведется непрерывный мониторинг производительности. 

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

На протяжении всего жизненного цикла данные об активе хранятся в системе управления (ITAM), обеспечивая полную отчетность, контроль затрат и соответствие нормативным требованиям. На каждом этапе жизненного цикла необходимо уделять внимание ^[12] тем самым аспектам управления ИТ-активами: физическому, контрактному и финансовому.

Примечание: картинка взята с сайта http://itam2.ru ^[13] 

ИИ-активы имеют свои особенности, по сравнению с более привычными нам компьютерами, ноутбуками и серверами. Давайте углубимся в детали.

Что такое ИИ-актив

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

Эволюция управления ИТ-активами и место ИИ-активов в системе ITAM

1.1 Концептуальные основания управления ИТ-активами

Управление ИТ-активами (ITAM – IT Asset Management) исторически развивалось как набор инструментов и процессов для отслеживания, контроля и оптимизации физического и программного обеспечения организации. Традиционная модель ITAM охватывала аппаратные активы (серверы, рабочие станции, устройства хранения) и программные лицензии, отслеживая их жизненный цикл от планирования закупки до вывода из эксплуатации. Однако появление облачных технологий, масштабное внедрение платформ машинного обучения и развитие генеративного искусственного интеллекта ^[14] потребовали переосмысления подходов к управлению активами.​

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

1.2 Структура ИИ-активов в рамках ITAM

В рамках системы управления ИТ-активами ИИ-активы могут быть организованы в две основные категории: управление аппаратными активами (HAM) и управление программными активами (SAM). Однако ИИ-активы, в отличие от традиционных ПО и оборудования, требуют введения дополнительной категории – управление данными и моделями как интеллектуальной собственностью (DAM – Data and Model Asset Management).​

Структура ИИ-активов включает:

• Модели машинного обучения – обученные нейронные сети, трансформеры и другие алгоритмические структуры, готовые к использованию в production-среде.​

• Датасеты – структурированные наборы данных, используемые для обучения, валидации и тестирования моделей.​

• Вычислительные ресурсы – облачные и on-premise инфраструктуры с поддержкой GPU/TPU для обучения и инференса моделей.​

• Программное обеспечение и инструменты – фреймворки, библиотеки и платформы (TensorFlow, PyTorch, Hugging Face, MLflow), используемые в разработке ИИ-решений.

Каждый из этих компонентов имеет собственный жизненный цикл, требует различного подхода к оценке стоимости, и подпадает под разные правовые режимы.

Датасеты как ИТ-активы: правовой статус, классификация и оценка

2.1 Правовая природа датасетов в российском законодательстве

Датасет – это структурированный набор данных, который используется для обучения, проверки и тестирования моделей машинного обучения. С точки зрения ^[15] права, датасет может рассматриваться как база данных, которая охраняется в России авторским правом или смежным правом. Согласно Указу Президента Российской Федерации от 10 октября 2019 г. № 490 «О развитии искусственного интеллекта в Российской Федерации», датасет определяется как упорядоченный набор данных, представленный в цифровой форме, который подлежит обработке и хранению с использованием вычислительных ресурсов.​

В подавляющем большинстве случаев в России датасет охраняется смежным правом, а не авторским. Это обусловлено несколькими факторами. Во-первых, для датасетов приоритетное значение имеют сами данные, включенные в них, а не уникальная структура расположения. Во-вторых, в отечественном законодательстве действует презумпция, что любой датасет, содержащий более 10 тысяч элементов, охраняется смежным правом. Это означает, что права составителя датасета защищены от несанкционированного копирования на основе смежных прав, которые признаются за производителем базы данных.​

Смежные права предоставляют производителю (составителю) датасета право контролировать воспроизведение и распространение его работы, а также получать вознаграждение за использование. Однако, в отличие от авторского права, смежные права существуют независимо от творческого характера содержимого – они защищают усилия, вложенные в сбор, систематизацию и организацию данных.​

2.2 Классификация датасетов с учетом их использования

Датасеты могут быть классифицированы по нескольким признакам, значимым для целей управления ИТ-активами:

По происхождению данных:

• Первичные датасеты – данные, собранные непосредственно из исходных источников (сенсоры, анкеты, камеры, логи систем).​

• Вторичные датасеты – производные от первичных (переводы, резюме, аннотации, размеченные данные).​

• Третичные датасеты – созданные уже самими ИИ-моделями, когда генерации используются как новые примеры для обучения.​

По функциональному назначению в ML-процессе:

• Обучающие датасеты (training set) – используются для накопления опыта моделью.​

• Валидационные датасеты (validation set) – применяются для контроля переобучения и настройки гиперпараметров (чтобы выбрать лучшую модель и для анализа ошибок).​

• Тестовые датасеты (test set) – используются для итоговой проверки способности модели к обобщению (решению задачи для которой она создана).​

• Приемочный – для оценки качества в критичных для бизнеса ситуациях.

По уровню обработки:

• Сырые датасеты – неструктурированные, неочищенные данные непосредственно из источников.​

• Обработанные датасеты – очищенные, нормализованные и размеченные данные, готовые к использованию.​

По правовому статусу и условиям использования:

• Открытые датасеты (Open Source) – лицензированы под открытыми лицензиями (CC0, CC-BY, CC-BY-SA), доступные публично без ограничений или с минимальными обязательствами.​

• Коммерческие датасеты – предоставляются с ограничениями на использование, требуют оплаты или лицензионного соглашения.​

• Внутренние корпоративные датасеты – собственность организации, содержащие конфиденциальную информацию.​

2.3 Оценка стоимости датасетов

Оценка стоимости датасета как актива представляет собой одну из наиболее сложных задач в управлении ИИ-активами. Самый простой способ – мы купили датасет за Х денег – тут все понятно. А что если мы собрали его сами и/или хотим его продавать? Стоимость датасета определяется не только объемом данных, но и их качеством, релевантностью для конкретной задачи, и потенциалом к генерированию экономической выгоды.

Методы оценки стоимости датасетов:

• Подход на основе затрат – рассчитывает стоимость как сумму расходов, понесенных на сбор, обработку, разметку и хранение данных. Эта методика наиболее объективна, но не отражает реальную стоимость датасета на рынке.​

• Подход на основе рыночной стоимости – ориентируется на цены открытых платформ (Kaggle, Zenodo, Google Dataset Search), где осуществляются сделки с датасетами. Однако такие данные ограничены и не всегда репрезентативны.​

• Подход на основе доходов – оценивает датасет по его способности генерировать прибыль. В этом случае стоимость рассчитывается как дисконтированная стоимость будущих денежных потоков, которые датасет способен принести организации. Это наиболее сложный, но и наиболее точный метод для стратегических активов.​

• Подход на основе качества данных – использует метрики качества (полнота, точность, согласованность, актуальность) и связывает их с экономическими результатами. Например, если улучшение качества датасета на 10% приводит к увеличению точности модели на 2% и росту выручки на 5%, можно рассчитать стоимость этого улучшения.​

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

3. Договоры и лицензии для датасетов и моделей ИИ

3.1 Типология лицензий для датасетов

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

Открытые лицензии (Open Source):

Датасеты, распространяемые под открытыми лицензиями, представляют собой объекты, чьи права распространяются на основе специальных лицензионных соглашений. Наиболее распространенные типы:

• Creative Commons Zero (CC0) – автор полностью отказывается от прав, позволяя любое использование без ограничений. Это наиболее либеральная лицензия.​

• Creative Commons Attribution (CC-BY) – разрешает использование при условии указания автора. Требует атрибуции, но не накладывает ограничений на коммерческое использование.​

• Creative Commons Attribution-ShareAlike (CC-BY-SA) – требует указания автора и распространения производных работ на той же лицензии. Это означает, что если вы создадите датасет на основе CC-BY-SA датасета, ваш новый датасет также должен быть распространен на условиях CC-BY-SA.​

• GNU GPL (General Public License) – лицензия, требующая открытия исходного кода любых программ, разработанных с использованием GPL-лицензированного кода или данных. Использование GPL-лицензированных датасетов в коммерческих целях может быть затруднено.​

Условия лицензий для коммерческого использования:

Компании часто заключают лицензионные договоры для получения исключительного или неисключительного права на использование датасетов. В таких договорах стороны определяют:

• Способы использования (обучение моделей, исследовательские цели, коммерческое применение).​

• Запреты на использование (например, запрет на переработку датасета без разрешения).​

• Сроки действия лицензии (бессрочные или ограниченные по времени).​

• Размеры и порядок выплаты роялти или платежей.​

3.2 Условия использования моделей ИИ

Лицензирование LLaMA и других открытых моделей: Примечательный случай – лицензия LLaMA от Meta. Хотя условия лицензирования LLaMA в целом разрешающие, из них есть важные исключения. Крупные предприятия с более чем 700 миллионами пользователей в месяц (такие как Google) требуют явного разрешения Meta для использования модели. Дополнительно лицензия запрещает использование LLaMA для улучшения других языковых моделей, что ограничивает возможности компаний по разработке собственных моделей на основе LLaMA.​

Ограничения на использование закрытых моделей:

Модели, разработанные коммерческими компаниями (OpenAI GPT-3.5/4, Anthropic Claude, Google Gemini), предоставляются через API или облачные платформы с определенными условиями использования. Условия, как правило, включают:

• Запреты на использование моделей для обучения конкурирующих моделей.​

• Ограничения на объем запросов (rate limiting).​

• Требования соответствия политикам по контенту и использованию.​

• Сохранение прав OpenAI и других разработчиков на сгенерированный контент или ограничение прав пользователя.​

3.3 Авторские права на результаты работы ИИ-моделей

Один из наиболее спорных вопросов – авторские права на контент, созданный ИИ-моделями. В России авторское право не содержит специальных правил для контента, сгенерированного с помощью ИИ. Согласно общим положениям части 4 ГК РФ, автором произведения признается физическое лицо, создавшее произведение.​

В судебной практике уже имели место прецеденты. Суд признал права автора на изображение, сгенерированное нейросетью, при условии, что человек доказал, что он сначала создал исходную 3D-модель, а нейросеть использовал только для финальной обработки. Это означает, что авторские права на ИИ-контент признаются при доказательстве значительного творческого вклада человека, использующего ИИ только как инструмент.​

4. Вычислительные ресурсы как ИИ-активы

4.1 Классификация вычислительных ресурсов в облачных моделях

Вычислительные ресурсы, необходимые для обучения и инференса ИИ-моделей, представляют собой значительный компонент расходов на ИИ-проекты. Они могут быть классифицированы по способу развертывания:

On-Premise инфраструктура (мы детально рассматривали этот вариант в прошлых статьях, когда говорили о ТСО и аллокации затрат):

• Выделенные серверы с GPU/TPU, располагаемые на территории организации.

• Полный контроль над данными и инфраструктурой, но высокие капитальные затраты и затраты на содержание.​

Облачные модели предоставления (IaaS, PaaS, SaaS):

• Infrastructure as a Service (IaaS) – предоставление виртуализованных физических серверов и хранилищ. Клиент арендует вычислительные мощности и управляет ПО, ОС и данными самостоятельно.​

• Platform as a Service (PaaS) – предоставление готовых платформ и инструментов для разработки, хранения и анализа данных. Клиент минимально настраивает платформу и концентрируется на разработке моделей.​

• Software as a Service (SaaS) – предоставление полностью готовых приложений, требующих минимум настройки со стороны пользователя.​

Для ИИ-проектов наиболее распространены IaaS (например, облачные серверы с GPU) и PaaS (например, ML Inference сервисы, Jupyter notebook платформы).​

4.2 Модели тарификации облачных вычислений

За использованные ресурсы (Pay-as-You-Go):

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

• Аренда видеокарт по часам/минутам​

• Вычисления по количеству юнитов (где юнит – это определенная конфигурация, например с 1x GPU карты NVIDIA A100)

• Рабочие места в SaaS-платформах.​

За заранее зарезервированные ресурсы (Reserved Instances):

Облачные провайдеры предлагают скидки (20-40%) при долгосрочном резервировании ресурсов (1 год, 3 года). Такая модель экономична для организаций с предсказуемыми и стабильными нагрузками.​

5. MLOps и управление жизненным циклом ИИ-активов

5.1 Жизненный цикл ИИ-модели в контексте ITAM

MLOps (Machine Learning Operations) – это набор практик, методологий и философии, направленных на автоматизацию всего жизненного цикла машинного обучения. В контексте управления ИТ-активами MLOps представляет собой систему контроля и оптимизации ИИ-активов, аналогичную DevOps для традиционного ПО.​

Жизненный цикл ИИ-активов представляет собой циклический процесс, который начинается с планирования и сбора данных, проходит через этапы обучения, валидации, развертывания и мониторинга, и завершается либо выводом активов из эксплуатации, либо их переобучением и адаптацией. В отличие от традиционного жизненного цикла программного обеспечения, жизненный цикл ИИ-активов характеризуется непрерывностью и итеративностью, так как модели должны постоянно адаптироваться к изменяющимся данным и условиям окружающей среды.​

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

Этапы жизненного цикла ИИ-модели:

• Фаза проекта

  • 1. Планирование и подготовка – определение целей, требуемых данных, выбор инфраструктуры.​ Закупочные процедуры при необходимости

  • 2. Сбор и подготовка данных (Data Preparation) – сбор сырых данных, их очистка, нормализация, разметка, создание датасетов для обучения, валидации и тестирования.​

  • 3. Разработка и обучение (Development & Training) – разработка архитектуры модели, обучение на датасетах, подбор гиперпараметров.​

  • 4. Валидация и тестирование (Validation & Testing) – оценка качества модели, анализ ошибок, сравнение с базовыми моделями.​

• Фаза использования

  • 5. Развертывание (Deployment) – загрузка модели в production-среду, интеграция с бизнес-приложениями.​

  • 6. Мониторинг и оценка (Monitoring & Evaluation) – отслеживание производительности модели, выявление дрейфа данных и концепции, регистрация аномалий.​

  • 7. Переобучение и адаптация (Retraining & Adaptation) – периодическое или автоматическое переобучение модели на новых данных при обнаружении снижения качества.​

  • 8. Вывод из использования (Decommissioning) – удаление модели, архивирование данных, документирование причин прекращения использования.​

5.1.1 Первый этап ЖЦ – планирование и подготовка

Совпадает с ЖЦ обычного ИТ-актива. Мы планируем, производим закупки (при необходимости), еще никаких материальных или нематериальных объектов в периметре компании не существует, есть только потребность.

5.1.2 Сбор и подготовка данных

Второй этап жизненного цикла ИИ-активов начинается с систематического сбора и подготовки данных (если мы не купили готовый датасет на прошлом этапе). Этот процесс включает несколько критических шагов:​

• Сбор сырых данных – данные поступают из различных источников: сенсоры, логи систем, пользовательские взаимодействия, внешние API. Качество собираемых данных напрямую влияет на все последующие этапы, поэтому необходимо тщательно отбирать источники и проверять полноту данных.​

• Разметка и аннотирование – для задач с учителем (supervised learning) сырые данные должны быть размечены. Разметка превращает сырые данные в обучающие примеры, готовые для использования моделью. Процесс разметки часто требует участия людей и может включать несколько уровней проверки: первичная разметка, независимая валидация, арбитраж. Качество разметки контролируется через согласованность между разметчиками и проверку на эталонных примерах.​

• Очистка и нормализация – к этапу относятся валидация релевантности, удаление дубликатов, устранение выбросов, исправление систематических ошибок, заполнение пропусков. Этап очистки критически важен, так как даже небольшое количество шумных или ошибочных примеров может значительно снизить качество обучения.​

• Создание датасетов – подготовленные данные разделяются на три категории: обучающий набор (training set, обычно 60-80% данных), валидационный набор (validation set, 10-20%) и тестовый набор (test set, 10-20%). Такое разделение позволяет корректно оценивать способность модели к обобщению на новых, невидимых ранее данных.​

5.1.3 Выбор архитектуры и обучение модели

После подготовки данных начинается этап выбора архитектуры и обучения модели. Решение об архитектуре зависит от типа задачи: для изображений обычно используются сверточные нейронные сети (CNN) или трансформеры, для текста – трансформеры и их производные, для табличных данных – градиентный бустинг или небольшие нейронные сети.​ ​

5.1.4 Валидация и тестирование моделей

После обучения модель проходит два уровня проверки: валидацию (на валидационном наборе) и тестирование (на тестовом наборе). Эти наборы были отложены на начальном этапе подготовки данных и не использовались при обучении, что позволяет корректно оценить способность модели к обобщению.​

Критерии успешной валидации:

• Модель демонстрирует приемлемую производительность на валидационном наборе.

• Нет явных признаков переобучения (значительное различие между ошибкой ^[16] на обучающем и валидационном наборах).

• Модель удовлетворяет бизнес-требованиям по точности и скорости.

Дополнительные проверки: кроме основных метрик качества, проводятся специализированные тесты: синтетические примеры для проверки граничных случаев, эталонные примеры (benchmarks) для сравнения с другими моделями, проверки на некорректных входных данных.​

5.1.5 Развертывание в production

Успешно пройдя тестирование, модель готова к развертыванию в production среду. Этот процесс включает:​

• Контейнеризация и упаковка – модель упаковывается в контейнер (Docker), который содержит код модели, все зависимости, библиотеки, базовые образы и runtime-скрипты. Это обеспечивает консистентность и воспроизводимость развертывания.​

• Создание API и микросервисов – вокруг модели развивается инфраструктура, включающая API для приема запросов, очереди сообщений для асинхронной обработки, кэширование результатов, ограничение частоты запросов (rate limiting), логирование, и настройку алертов.​

• Многоуровневое развертывание – развертывание проходит через несколько окружений: разработка (development), тестирование (testing), предпроизводство (staging), производство (production). На каждом уровне проверяются совместимость зависимостей и корректность конвейера подготовки входных данных.​

• Документирование и версионирование – все компоненты системы (код, конфигурации, артефакты обучения) версионируются в системе контроля версий (Git), что позволяет отследить историю изменений и при необходимости откатиться на предыдущую версию.​

Данный этап ЖЦ ИИ-актива продолжается до момента старта инференса и перевода ИИ-актива в следующий статус “мониторинг”. Инференс – это процесс, когда обученная модель получает входные данные и выдает предсказание. В отличие от обучения, во время инференса параметры модели не изменяются – сеть лишь применяет накопленные параметры к новому примеру. Однако для обеспечения быстрого, надежного и недорогого инференса требуется специальная подготовка инфраструктуры.​

5.1.6 Мониторинг производительности и качества

Одним из наиболее критичных аспектов управления ИИ-активами в production является мониторинг их производительности. Системы мониторинга должны отслеживать три группы сигналов:​

Метрики качества:

• Офлайн-метрики, рассчитываемые на регулярно собираемых размеченных порциях новых данных.​

• Онлайн прокси-показатели, такие как клики пользователей, количество отказов, оценки удовлетворенности.​

• Изменение основных бизнес-метрик (конверсия, выручка, затраты).

Метрики производительности:

• Задержка инференса (latency).​

• Пропускная способность (throughput).​

• Загруженность ускорителей (GPU utilization).

Метрики стабильности:

• Количество ошибок сервиса.​

• Доля таймаутов запросов.​

• Поведение ^[17] очередей запросов.​

Все эти панели мониторинга позволяют быстро замечать деградации производительности и определять, где именно произошел сбой.​

5.1.7 Переобучение и адаптация (Retraining & Adaptation) – периодическое или автоматическое переобучение модели на новых данных при обнаружении снижения качества.​

Дрейф данных (Data Drift) и дрейф концепции (Concept Drift)

По мере того как модель работает в production, входные данные и их распределение могут меняться. Это явление называется дрейфом данных (data drift) или ковариантным дрейфом. Дрейф данных происходит, когда распределение входных признаков (X) в production отличается от распределения, на котором обучалась модель.​

Более коварным явлением является дрейф концепции (concept drift), когда меняется сама взаимосвязь между признаками и целевой переменной. Например, модель, предсказывающая спрос на зимние шины, учитывает температуру и осадки. После запуска агрессивной рекламной кампании потребительское поведение ^[18] меняется, хотя погодные данные остаются прежними – это и есть дрейф концепции.​ Оба типа дрейфа приводят к снижению качества предсказаний и требуют соответствующих действий.​ Для обнаружения дрейфа концепции необходимо посмотреть на условное распределение истинных и спрогнозированных целевых значений по конкретному набору входных признаков. Если модель начала делать заметно больше ошибок на свежих данных при сохранении прежнего распределения входов, это указывает на дрейф концепции.​ Если обнаружен существенный дрейф ИИ-актив переходит в следующий этап жизненного цикла – переобучение.

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

Источники технического долга (некоторые для иллюстрации):

• CACE (Change Anything Change Everything) – в ML работает принцип, что изменение любого компонента может повлиять на все остальные компоненты. Это делает запутанность связей между компонентами системы серьезной проблемой.​

• Устаревшие признаки – со временем признаки, полезные при обучении, становятся нерелевантны для реальных вычислений, но продолжают присутствовать в коде.​

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

Во время устранения тех долга или переобучения ИИ-актив находится в этом статусе ЖЦ – “Переобучение и адаптация (Retraining & Adaptation)”.​

5.1.8 Вывод ИИ-активов из эксплуатации

Жизненный цикл ИИ-активов может завершиться выводом из эксплуатации по различным причинам:​

• Истечение срока полезного использования – модель была обучена на данных, которые существенно устарели, и переобучение перестало помогать.​

• Появление лучшей модели – новая архитектура или подход показывает значительное улучшение качества.​

• Изменение бизнес-требований – компания перестала использовать тот сервис, для которого была разработана модель.​

• Требования регуляции и безопасности – модель может содержать уязвимости или не соответствовать требованиям конфиденциальности данных.​

• Наличие обучающих данных – если в модели остались элементы обучающих данных (при определенных условиях обучения), это может потребовать удаления модели.​

• Требования к защите данных – необходимость соблюдения требований законодательства о защите персональных данных может потребовать удаления модели и связанных данных.​

Этап включает решение судьбы данных, которые больше не используются системой ИИ:​

• Безопасное удаление – критичные данные (персональные, конфиденциальные) должны быть полностью и неотвратимо удалены.​

• Архивирование – менее критичные данные могут быть архивированы для целей аудита или исторического анализа.​

• Перепрофилирование – некоторые данные могут быть переиспользованы для других целей или систем.​

• Сохранение для аудита – определенные категории данных должны быть сохранены для целей аудита, например, данные журналирования для подтверждения соответствия нормативным требованиям.​

Этап включает прекращение обработки данных и утилизацию компонентов системы:​

• Прекращение обработки данных – система прекращает получение новых входных данных и выдачу предсказаний.​

• Утилизация компонентов – удаление или архивирование компонентов целевой среды, на которые не распространяется вывод данных из эксплуатации.​

• Сохранение системных логов – логи системы (не модели), такие как логи операций и ошибок, могут быть сохранены для целей аудита и исторического анализа.​

• Документирование – причины вывода из эксплуатации, дата, статус архивирования и другие метаданные должны быть задокументированы.​

Архивирование ИИ-активов: Перед полным удалением модель, датасеты и все связанные артефакты должны быть архивированы:​

• Сохранение модели – полная архивация весов модели, архитектуры, конфигурации обучения.​

• Сохранение данных – архивация обучающего, валидационного и тестового датасетов, а также информации об их версиях.​

• Документация – сохранение всей документации (Model Cards, Dataset Cards, тестовые результаты, метаданные).​

• Воспроизводимость – возможность восстановления модели из архива должна быть гарантирована путем сохранения всех зависимостей и конфигураций.​

Условия восстанавливаемости:

• Все компоненты сохранены в версионной системе контроля версий.​

• Сохранены конфигурации и гиперпараметры обучения.​

• Задокументирована среда выполнения (Python версия, версии библиотек).​

• Сохранены артефакты обучения (логи, метрики, контрольные точки модели).​

Цикличность и непрерывность жизненного цикла

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

Управление жизненным циклом ИИ-активов – это комплексная задача, требующая координации между многими компонентами системы и постоянного внимания к качеству данных, производительности модели и требованиям регуляции. От сбора данных и обучения через мониторинг и адаптацию к потенциальному выводу из эксплуатации, каждый этап требует специальных подходов и инструментов. Внедрение автоматизации, версионирования и надежного мониторинга позволяет организациям максимизировать ценность ИИ-активов и минимизировать риски их использования.

5.2 Документирование моделей и датасетов

Надлежащее документирование ИИ-активов – критически важный аспект управления ими. В индустрии сложились определенные стандарты, такие как Model Cards и Dataset Cards.​

Model Cards – подробные документы, содержащие информацию о модели, включая:

• Описание задачи и целей использования.​

• Архитектура модели, препроцессинг, компоненты.​

• Требования к входным данным и описание выходов.​

• Метрики производительности и результаты тестирования.​

• Известные ограничения и проблемы.​

• История изменений и версионирование.​

Dataset Cards – документация датасетов, содержащая:

• Описание источников данных и процесса сбора.​

• Информацию о разметчиках и процессе разметки.​

• Описательные статистики и примеры данных.​

• Известные проблемы и ограничения датасета.​

• Информацию о версионировании датасета.​

Документация должна быть версионирована, автоматически обновляться при изменении данных или модели, и быть доступной для всех заинтересованных сторон.​

5.3 Управление версиями ИИ-активов

Версионирование является ключевым элементом MLOps, позволяющим воспроизводить результаты и отслеживать изменения. Необходимо версионировать:​

• Код моделей – каждое изменение архитектуры или алгоритма должно быть зафиксировано в системе контроля версий (Git).​

• Датасеты – необходимо отслеживать, какие версии датасетов использовались для обучения конкретных версий моделей.​

• Гиперпараметры и конфигурации – параметры, использованные при обучении модели, должны быть сохранены и версионированы.​

• Модели – каждая обученная модель должна иметь уникальный идентификатор и метаданные о времени обучения, использованных данных, и показателях качества.​

Версионирование позволяет быстро откатиться на предыдущую версию модели в случае проблем и проанализировать, какие изменения привели к улучшению или ухудшению качества.

6. Риски и вызовы в управлении ИИ-активами

6.1 Риски утечки данных и нарушения конфиденциальности

Использование датасетов, содержащих персональные данные, требует соблюдения законодательства о защите персональных данных (Федеральный закон №152-ФЗ в России). Утечка персональных данных может привести к штрафам, потере репутации и судебным разбирательствам. Кроме того, при передаче конфиденциальных корпоративных данных облачным провайдерам возникают риски несанкционированного доступа и неправильного использования.​

6.2 Риски, связанные с качеством данных

Модели, обученные на некачественных, предвзятых или неполных данных, могут привести к ошибочным предсказаниям и неправильным бизнес-решениям. Исследования показывают, что даже лучшие LLM-модели могут накапливать ошибки при работе с долгосрочными задачами, демонстрируя отклонения более чем на 15% от истинных значений после нескольких месяцев использования.​

6.3 Риски нарушения авторских прав

Использование датасетов, содержащих защищенные авторским правом материалы (фотографии, тексты, видео) без разрешения, может привести к судебным разбирательствам и штрафам до 5 млн рублей за один датасет. Необходимо проверять лицензии и получать явное разрешение у правообладателей перед использованием таких данных.​

6.4 Непрозрачность работы моделей (Black Box Problem)

Большинство ИИ-моделей работают как “черные ящики”, что затрудняет понимание того, как они приходят к конкретному решению. Это создает риски принятия неправильных бизнес-решений на основе рекомендаций модели без надлежащей проверки и верификации.​

7. Практические подходы к учету и управлению ИИ-активами в системе ITAM

7.1 Классификация ИИ-активов в бухгалтерском учете

ИИ-активы могут быть классифицированы как нематериальные активы (НМА) согласно положениям части 4 ГК РФ и ПБУ 14/2007. Критериями классификации НМА являются:​

• Отсутствие материальной формы – ИИ-активы являются цифровыми объектами.​

• Способность приносить доход – модели и датасеты генерируют экономическую выгоду.​

• Возможность отчуждения – ИИ-активы могут быть проданы или переданы третьим лицам.​

• Длительный период использования – ИИ-активы используются более года.​

В рамках классификации НМА ИИ-активы могут быть отнесены к следующим группам:

• Объекты авторского права и смежных прав – модели, датасеты, программный код.​

• Объекты патентного права – алгоритмы, если они патентованы.​

• Иные объекты НМА – ноу-хау, технологии обучения, процессы разработки.​

Для учета ИИ-активов рекомендуется использовать счет 04 “Нематериальные активы” в бухгалтерском учете. Первоначальная стоимость ИИ-активов определяется как сумма расходов на его разработку, приобретение или адаптацию.​

7.2 Учет расходов на разработку ИИ-активов

Расходы на разработку ИИ-активов включают:

• Расходы на оплату труда – заработная плата разработчиков, data scientists, аналитиков, задействованных в разработке.​

• Расходы на сбор и подготовку данных – затраты на сбор сырых данных, их очистку, нормализацию, разметку.​

• Расходы на облачные вычисления – затраты на аренду GPU, вычислительных ресурсов, хранилище данных.​

• Расходы на программное обеспечение и лицензии – покупка или аренда инструментов разработки, платформ MLOps.​

• Расходы на консультации и экспертизу – оплата консультантов, специалистов в области ИИ.​

Согласно принципам бухгалтерского учета, расходы на разработку ИИ-активов могут быть капитализированы (включены в стоимость актива) или учтены как текущие расходы, в зависимости от их характера и ожидаемой экономической выгоды.​

7.3 Амортизация ИИ-активов

Амортизация ИИ-активов представляет собой системное распределение их первоначальной стоимости по периодам использования. Для ИИ-активов требуется определение срока полезного использования, что является нетривиальной задачей, так как срок зависит от:

• Темпа устаревания алгоритмов – новые подходы в ИИ часто делают старые модели менее эффективными.​

• Изменения данных – если входные данные существенно изменяются, модель может потребовать переобучения или полной переработки.​

• Потребностей бизнеса – требования к функциональности или точности модели могут меняться, требуя адаптации.​

В практике рекомендуется использовать консервативный подход, устанавливая срок полезного использования ИИ-активов в диапазоне 3-5 лет, с возможностью пересмотра в зависимости от фактического состояния и актуальности модели.

8. Рекомендации по внедрению системы управления ИИ-активами

Организациям рекомендуется следовать следующим практикам при управлении ИИ-активами:

• Создать каталог ИИ-активов – вести централизованный реестр всех моделей, датасетов и вычислительных ресурсов, включая метаданные, версии, статусы, владельцев.​

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

• Автоматизировать мониторинг качества моделей – внедрить системы отслеживания производительности моделей в production, выявления дрейфа данных и концепции, автоматического переобучения.​

• Документировать модели и датасеты – использовать стандарты Model Cards и Dataset Cards для полной документации всех ИИ-активов.​

• Управлять версиями активов – вести полный контроль версий кода, датасетов, моделей и гиперпараметров.​

• Обеспечить безопасность и конфиденциальность – внедрить меры защиты данных, контроль доступа, шифрование, проверку соответствия требованиям регулирования.​

• Оценивать и переоценивать стоимость активов – регулярно пересчитывать стоимость ИИ-активов, учитывая их вклад в достижение бизнес-целей.​

• Планировать жизненный цикл активов – определить сроки использования моделей, условия переобучения и моменты вывода из использования.​

Заключение

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

Датасеты, как ключевые компоненты ИИ-активов, требуют четкого понимания их правового статуса (авторское право vs. смежные права), типологии лицензий (открытые vs. коммерческие), и методов оценки стоимости. Вычислительные ресурсы, необходимые для обучения и инференса моделей, требуют анализа различных моделей развертывания (on-premise vs. облако) и оптимизации затрат. Моделями машинного обучения необходимо управлять как через все этапы их жизненного цикла (разработка, валидация, развертывание, мониторинг, переобучение), так и обеспечивая надлежащую документацию, версионирование и контроль качества.

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