AIBOM для ИИ-продукта: покупатель может узнать, на какой модели и данных его собрали
Команда CodeScoring разобрала AIBOM, опись модели, данных и сервисов внутри ИИ-продукта, которую с появлением поддержки моделей в стандартах CycloneDX и SPDX можно собирать в машиночитаемом виде.

С июня 2023 года модель можно записать в тот же документ, где перечислены библиотеки продукта. Покупатель ИИ-сервиса может узнать, из какой исходной модели и на каких данных его собрали.
Раньше разработчики вели SBOM (Software Bill of Materials, перечень программных компонентов): список библиотек, их версий и связей. Модели машинного обучения в такую опись не попадали, хотя у дообученной модели есть «родитель», данные и история преобразований. Как это теперь описывают, объяснила команда CodeScoring, которая делает решение для композиционного анализа ПО (SCA, автоматическая проверка чужого кода внутри продукта на уязвимости и лицензии).
Откуда в описи ПО взялись модели и данные?
Стандарты появились раньше моделей:
- SPDX описывает состав ПО, лицензии и связи между компонентами. Спецификацию начали готовить в 2010 году, версия 1.0 вышла в 2011-м.
- CycloneDX развивался с упором на безопасность. Первая версия вышла в 2018 году.
Параллельно специалисты по машинному обучению думали о происхождении данных. В марте 2018 года вышла работа Datasheets for Datasets: авторы предложили прикладывать к набору данных описание состава, происхождения и обработки. Осенью того же года появилось исследование Model Cards for Model Reporting с идеей карточки модели, то есть паспорта с назначением, результатами проверки и ограничениями.
Два подхода сошлись в июне 2023 года, когда CycloneDX 1.5 добавил поддержку MLBOM. В апреле 2024 года в SPDX 3.0 появились профили для ИИ и датасетов (наборов данных для обучения).
Чем MLBOM отличается от AIBOM?
MLBOM (Machine Learning Bill of Materials) описывает саму модель. В него входят сведения о базовой модели, датасетах, преобразованиях, программном окружении и условиях использования.
AIBOM (AI Bill of Materials) охватывает всю ИИ-систему. Сюда попадают обращения к внешнему API (каналу, через который программа отправляет запросы чужому сервису), поиск по базе документов, системный промпт (скрытая инструкция, которую модель получает перед каждым запросом), подключённые инструменты и ИИ-агенты (программы, которые сами выполняют цепочки действий).
Граница размыта, и источник говорит об этом прямо. Генератор OWASP AIBOM Generator собирает документ по данным о моделях с Hugging Face (площадки, где выкладывают открытые модели), то есть по сути делает MLBOM. В документации CycloneDX оба понятия рассматриваются вместе.
Что понадобится для первого AIBOM?
- Список всех мест, где ваш продукт обращается к ИИ.
- Карточки используемых моделей. На Hugging Face это README с описанием и метаданными.
- Записи о дообучении (обучении модели на ваших данных под узкую задачу) и других изменениях модели.
- Формат: CycloneDX версии 1.5 и новее или SPDX 3.0.
- Несколько часов на небольшой проект.
Как собрать AIBOM по шагам?
- Перечислите все ИИ-элементы продукта: модели, внешние API, базы документов, системные промпты, инструменты, агентные сценарии.
- Для каждой модели запишите исходную модель, её версию и ревизию. Под одним именем могут распространяться разные варианты.
- Укажите датасеты, на которых модель дообучали.
- Опишите преобразования. Если вы уменьшали точность весов (числовых параметров модели), чтобы запускать её на слабом железе, это тоже фиксируется.
- Перенесите сведения из карточки модели в структурированный вид. В CycloneDX для этого есть объект modelCard внутри компонента типа machine-learning-model.
- Для моделей с Hugging Face попробуйте OWASP AIBOM Generator. Для систем с агентами посмотрите документацию Cisco AIBOM: этот инструмент учитывает агентов и MCP-серверы (способ подключать к ИИ внешние инструменты).
Черновик описи можно подготовить с помощью нейросети, а потом проверить вручную:
Вот описание моего ИИ-сервиса: [описание]. Составь таблицу:
компонент, тип (модель, API, база документов, системный промпт,
инструмент), версия, источник, данные для дообучения,
преобразования. Где сведений нет, пиши «не указано».
Условный пример по схеме из источника. Команда взяла открытую модель, дообучила её на своих данных и уменьшила точность весов. В MLBOM появляется связка из четырёх элементов: исходная модель с версией, датасет, запись о дообучении, запись об уменьшении точности. Если поставщик исходной модели сообщит об уязвимости, по описи будет видно, касается ли она вашего варианта.
Новички верят названию документа: по слову «AIBOM» нельзя понять, что внутри. Вторая ошибка: записать модель без ревизии, хотя для повторного запуска нужны те же веса и настройки, что у оригинала. Третья: забыть системный промпт и внешние API, которые формально не модель, но влияют на ответы.
Кому AIBOM нужен прямо сейчас и что делать?
Автору Дзена, который заказывает чат-бота или ассистента для канала, стоит попросить у подрядчика список моделей и сервисов внутри. Так вы узнаете, чьи данные и чьи условия использования стоят за вашим продуктом.
Маркетологу, который подключает ИИ к рассылкам или поддержке, опись упростит разговор с юристами о лицензиях и происхождении данных.
Предпринимателю в РФ и СНГ стоит включать в перечень и российские модели. Из доступных в РФ вариантов это YandexGPT и GigaChat: если сервис обращается к ним через API, это строка в AIBOM, как и любая зарубежная модель.
На мой взгляд, начинать стоит с простой таблицы, а не с формата CycloneDX: сначала честно перечислить всё, к чему обращается продукт. Я бы не надеялся на полную автоматизацию. Генераторы берут сведения из карточек моделей, а то, что команда сделала с моделью у себя, знает только она. Кто записывает это сразу, через год найдёт источник ошибки за минуты, а не за недели.
Разберитесь с нейросетями без программиста
На dzen.guru объясняем, как выбирать и применять ИИ-инструменты в работе автора и бизнеса.
Перейти на dzen.guru
Основатель dzen.guru. Эксперт по монетизации и продвижению на Дзен. Автор курса «Старт на Дзен 2026».
Читайте также

Чек-лист из 5 пунктов показывает, что такое ИИ-агент: работу доказывает запись в системе
Иван Крутько из «Софтлайн Решений» на фоне ажиотажа вокруг ИИ-агентов предложил чек-лист приёмки прототипа из пяти пунктов, где работу агента подтверждает…

Код инди-игры пишет ИИ-агент, а ошибки ловят скрипты: автору остаётся играть
Автор стратегии Age of Poleis, отдавший написание кода ИИ-агенту, описал два случая из проекта, где автоматические проверки ловят ошибки агента без участия…

Архитектурный дрифт лечится спекой: ИИ-агент соблюдает правила в 9 случаях из 10
Автор, ведущий разработку целиком через ИИ-агентов, показал трёхшаговый способ остановить в своих проектах архитектурный дрифт, старую проблему программистов,…
Комментарии