AI bill of materials корисний лише тоді, коли може відповісти на два запитання: що було задекларовано до розгортання і що насправді працювало, коли відбулося ухвалення рішення, інцидент або аудит. Дійсний JSON-файл, який не може відповісти на обидва запитання, є лише імітацією інвентаризації.
Практичний дизайн — це парний інвентар. Створюйте запис на основі стандартів під час збірки або закупівлі, спостерігайте за системою в роботі під час виконання, зберігайте докази для кожного поля та порівнюйте ці два записи. Блокуйте реліз, якщо критична модель, набір даних, runtime, API, інструмент агента або ліцензія залишаються невизначеними.
Рівень читача: просунутий. Цей посібник призначений для інженерів, команд безпеки, власників платформ і керівників технічного управління, які експлуатують системи на основі моделей.
Зміст
На які запитання має відповідати AI bill of materials
AI bill of materials, який зазвичай скорочують до AIBOM або AI BOM, — це машиночитаний інвентар компонентів і доказів, що лежать в основі AI-системи. Він розширює звичайний software bill of materials за межі пакетів і бібліотек.
Інвентар має дозволяти рецензенту відповісти на такі запитання:
CycloneDX описує можливості AI/ML-BOM як спосіб представлення моделей, наборів даних, конфігурацій, походження та залежностей. SPDX 3.0.1 також визначає AI-профіль для специфічних AI-метаданих. Це сумісні моделі даних, а не заміна відсутнім доказам.
Model card відповідає на вужче запитання: для чого призначена ця модель, як її оцінювали та де вона може помилятися? Оригінальна стаття Model Cards запропонувала документацію, що охоплює призначене використання, умови оцінювання та продуктивність для відповідних груп. Data card документує походження набору даних, його збирання й анотацію, призначене використання та рішення, що формують подальшу продуктивність; у статті Data Cards описано висновки з понад 20 розгортань.
Використовуйте обидва документи. Model card або data card надає людський контекст. AIBOM пов’язує ці документи з версійованим інвентарем системи.
Чому дійсні файли AIBOM все одно можуть містити слабкі докази
Дослідження, опубліковане в липні 2026 року, перевірило цю відмінність у великому масштабі. Автори зібрали знімок 2 942 466 публічних записів моделей Hugging Face, залишили 97 940 моделей із понад 100 завантаженнями та створили CycloneDX AIBOM за допомогою OWASP AIBOM Generator. Вони перевірили вибірку зі 100 артефактів за звітами генератора, а потім виміряли наявність полів у всьому наборі.
Повідомлений середній показник повноти становив 54,31 зі 100. Обов’язкові структурні поля були присутні у 100% згенерованих артефактів. Документація model card у середньому становила 19,51%.
Саме цей розрив є важливим результатом. Файл може бути структурно дійсним, але містити недостатньо інформації для ухвалення рішення.
Результати на рівні полів були ще виразнішими:
| Поле у згенерованому AIBOM | Наявність |
|---|---|
| --- | ---: |
| Ліцензія | 73,14% |
| Набір даних | 39,35% |
| Hyperparameters | 25,40% |
| Технічні обмеження | 16,74% |
| Оцінювання ризиків безпеки | 9,76% |
| Змістовний опис | 0,22% |
| Споживання енергії | 0,02% |
Поле опису було присутнє майже в кожному артефакті, але лише 211 із 97 940 описів містили інформацію, що виходила за межі тексту-заповнювача. Перевірка наявності полів у схемі зарахувала б решту описів як повні.
Що виміряли автори: охоплення полів і категорій в AIBOM, згенерованих із відфільтрованого публічного знімка Hugging Face.
Що вони вивели: документація model card і зовнішні посилання значною мірою визначають різницю між слабшими та сильнішими артефактами.
Чого вони не встановили: чи була якась модель безпечною, справедливою, продуктивною, юридично придатною або відповідною для конкретного розгортання.
Автори також попереджають, що їхні результати залежать від Hugging Face API, логіки вилучення генератора та знімка, який виключає моделі зі 100 або меншою кількістю завантажень. Приватні реєстри, моделі з обмеженим доступом, інші платформи хостингу та подальші зміни репозиторіїв можуть мати інший вигляд. Їхній результат підтверджує потребу в семантичній перевірці. Він не встановлює універсальний поріг оцінки.
Інвентар під час збірки та інвентар під час виконання розв’язують різні проблеми
AIBOM під час збірки фіксує намір. Інвентар під час виконання фіксує спостереження.
| Запитання | Докази під час збірки | Докази під час виконання |
|---|---|---|
| --- | --- | --- |
| Яка модель має бути випущена? | Lockfile, manifest, запис закупівлі, digest моделі | Завантажений ID моделі, endpoint, digest image, конфігурація обслуговування |
| Які дані мають бути доступними? | Декларації навчання та оцінювання, затверджені джерела retrieval | Підключені vector store, змонтовані набори даних, робочі data service |
| Які інструменти може викликати агент? | Реєстр інструментів, політика, задекларовані MCP server та API | Виявлені endpoint, активні інтеграції, спостережувана конфігурація |
| Яке програмне забезпечення підтримує inference? | SBOM пакетів і container | Запущений image, runtime, драйвери, accelerator |
| Які обмеження застосовуються? | Ліцензія, model card, data card, посилання на контракт | Поточний provider, регіон, маршрут, версія політики |
| Чи відбулося відхилення затвердженої системи? | Базова лінія для порівняння | Докази для порівняння з базовою лінією |
Одних доказів під час збірки недостатньо: вони не виявляють аварійні зміни, тіньові розгортання, змінні теги, перенаправлення provider або дрейф конфігурації. Одне лише спостереження під час виконання може виявити назву процесу або endpoint, але не знати його затвердженого призначення, ліцензії, походження навчальних даних або меж оцінювання.
Google відкрив код k8s-aibom 14 липня 2026 року, щоб дослідити сторону runtime. Controller відстежує стан Kubernetes workload і pod, застосовує правила виявлення та створює документи CycloneDX 1.6 ML-BOM. Задокументоване охоплення включає inference runtime, agent framework, vector database, training job та evaluation harness. Він працює без привілейованого DaemonSet або доступу до kernel.
Проєкт демонструє важливий архітектурний принцип: AIBOM під час збірки та виконання доповнюють одне одного. Водночас це раннє програмне забезпечення. Репозиторій позначає v1.0 як alpha і придатний для некритичних сценаріїв спостереження. Він не постачає hosted image або Helm repository, а його поточний `NoopVerifier` не може позначити ідентичність як криптографічно перевірену.
Супроводжувач NVIDIA AICR запропонував інтеграцію k8s-aibom та AICR, яка поєднала б спостереження k8s-aibom під час виконання з наміром розгортання AICR і підписаними атестаціями. Автор описує мету як доказ того, що розгорнула команда, і є тим, що працює в системі. Issue не має пов’язаної реалізації, відповідального або milestone. Розглядайте її як пропозицію практиків, а не офіційну дорожню карту чи завершений дизайн.
Не перетворюйте один новий controller на універсальну рекомендацію щодо продукту. Використовуйте такий принцип: поєднуйте задекларований стан зі спостережуваним, зберігайте докази та робіть невизначеність видимою.
_Корисний AI bill of materials поєднує намір під час збірки з доказами під час виконання, семантичними перевірками та версійованим рішенням._
Сім рівнів, які варто записувати
Точна схема залежить від вашого стандарту та розгортання. Наведені нижче рівні формують практичний мінімум для production-інвентарю.
1. Ідентичність моделі
Записуйте постачальника, сімейство моделей, незмінну ревізію або digest, формат, базову модель, adapters, quantization, tokenizer і маршрут обслуговування. Зручний для людей alias на кшталт `support-model` корисний, але недостатній для відстежуваності.
Для зовнішнього API записуйте стабільний ідентифікатор моделі provider і маршрут gateway, який її вибрав. Якщо provider може непомітно оновлювати модель за alias, позначайте ревізію як невирішену, а не вигадуйте точність.
2. Залежності даних і retrieval
Записуйте задекларовані набори даних для навчання, fine-tuning, оцінювання та калібрування, якщо така інформація існує. Для RAG-системи додайте вихідні колекції, embedding model, версію chunking, сервіс vector store, політику доступу та межу актуальності.
Зберігайте ідентифікатори наборів даних, версії, хеші, контракти або контрольовані посилання на каталог. Не копіюйте необроблені записи клієнтів або приватні приклади навчання в AIBOM.
Коли команда створює custom data systems with Next.js and AI agents→, версія схеми, межа міграції та підключені сервіси належать до контексту системи, навіть якщо вони не є артефактами моделі.
3. Runtime і програмне забезпечення
Пов’яжіть AI-інвентар зі звичайним SBOM. Записуйте digest container, inference engine, framework, відповідні бібліотеки, клас драйвера й accelerator, а також конфігурацію, яка може змінювати поведінку моделі.
Це важливо, оскільки однакові ваги можуть поводитися по-різному після зміни tokenizer, attention backend, шляху quantization або serving engine. Аналіз того, чому більша кількість AI tokens змінює рахунок за compute→, показує, чому запис розгортання має містити бюджет runtime і конфігурацію, а не лише назву моделі.
4. Інструменти, API та дозволи агентів
Перелічуйте інструменти, до яких може дістатися агент, а не кожен інструмент, встановлений десь у компанії. Додавайте model gateway, MCP server, інструменти браузера або виконання коду, зовнішні API та посилання на політику, що регулює кожну дію.
Інвентаризація не забезпечує авторизацію. Поєднуйте її з детермінованими засобами контролю. У статті про AI agent permissions→ пояснюється, чому самоконтроль моделі не є межею контролю доступу.
5. Оцінювання та операційні обмеження
Посилайтеся на точний evaluation set, версію evaluator, пороги, дату та умови, використані для затвердження. Записуйте відомі режими відмови, призначене та виключене використання, резервну поведінку, відповідального за моніторинг і дату завершення чинності рішення.
Не пишіть «оцінювання пройдено» без ідентифікатора тесту. Змінена модель із незмінним рядком результату є слабким доказом.
6. Права, політика та походження
Записуйте ліцензії моделей і наборів даних, обмеження використання, умови розповсюдження, вихідні репозиторії, model card, data card, статті, затвердження та атестації. Зберігайте посилання й хеші, якщо джерело контролюється доступом.
Цей рівень підтримує перевірку. Він не вирішує юридичне питання. Відсутня або суперечлива інформація про права має передаватися особі, відповідальній за це рішення.
7. Власність і життєвий цикл
Кожен запис потребує власника, призначення системи, середовища, часу створення, часу спостереження, версії, яку він замінив, і правила зберігання. Без власника інвентар перетворюється на архів покинутих фактів.
Додавайте стабільний ID системи, який зберігається після повторних розгортань. Версійований AIBOM має показувати історію змін, того, хто їх прийняв, і докази, що підтримали це рішення.
Позначайте кожен факт як задекларований, виведений, перевірений або невирішений
AIBOM має містити статус доказу на рівні поля. Одна позначка для всього документа приховує надто багато.
Перші три позначки описують різну силу доказів. «Задекларований» — це не слабший варіант написання «перевірений». Декларація постачальника може бути єдиним доступним джерелом інформації про навчальні дані, тоді як digest image можна перевірити механічно.
Проєкт k8s-aibom наразі реалізує `declared`, `inferred` і `unresolved`, а також локатори доказів для атрибутів. У README криптографічний статус `verified` зазначено як майбутню функцію, а не як уже доступну. Зберігайте таку саму чесність у власній системі.
Концептуальний запис може виглядати так:
{ "system_id": "customer-support-prod", "component": { "type": "machine-learning-model", "name": "provider/model-family", "version": "immutable-revision", "hashes": ["sha256:..."] }, "evidence": { "status": "verified", "source": "signed-build-attestation", "observed_at": "2026-07-29T08:00:00Z" }, "depends_on": [ "runtime:inference-engine@version", "dataset:retrieval-corpus@revision", "api:model-gateway@policy-version" ] }
Це ескіз дизайну, а не документ, що відповідає CycloneDX або SPDX. Для реального артефакту використовуйте схему й validator обраного стандарту.
Відтворюваний робочий процес AIBOM
Крок 1: визначте межі системи
Назвіть застосунок, середовища, власників і рішення, орієнтовані на користувача, що входять до сфери. Вирішіть, чи охоплює інвентар один endpoint моделі, workflow агента або повний продукт.
Межу на кшталт «весь AI» неможливо перевірити. «Production support agent і кожен сервіс, який може змінити його відповідь або дії» — можливо.
Крок 2: зберіть докази збірки та закупівлі
Створіть звичайний SBOM, розв’яжіть ідентифікатори моделей і наборів даних, зафіксуйте незмінні digest та додайте посилання на model card, data card, ліцензії, оцінювання й затвердження.
OWASP AIBOM Generator може вилучати метадані Hugging Face у CycloneDX 1.6 і повідомляти про відсутні поля. Розглядайте його результат як початковий інвентар. Масштабне дослідження показує, чому автоматично заповнене поле все одно потребує перевірки змісту.
Крок 3: створіть стандартний документ
Оберіть формат, який можуть аналізувати ваші споживачі. CycloneDX надає можливості AI/ML-BOM і посібник з реалізації. SPDX 3 надає профілі AI і dataset.
Вибір формату має залежати від систем-отримувачів, policy engine, конвеєра атестацій і вимог клієнтів. Не підтримуйте два формати, якщо обидва не потрібні реальному споживачу.
Крок 4: доповніть те, чого автоматизація не може знати
Призначте власників, які заповнять призначене використання, обмеження, походження наборів даних, умови оцінювання, права та рішення щодо ризиків. Відхиляйте заповнювачі на кшталт «N/A», «стандартна модель» або скопійований маркетинговий текст, якщо поле є критичним для рішення.
Вимагайте чіткої причини для невідомих значень. «Постачальник не розкриває навчальні дані» є кращим доказом, ніж порожній масив, оскільки відрізняє невиконану роботу від недоступної інформації.
Крок 5: спостерігайте за робочим розгортанням
Збирайте ID моделей під час виконання, digest image, endpoint, підключені сховища, інструменти агентів і конфігурацію через найменш привілейований доступний механізм. У Kubernetes це може бути controller, що стежить за API. У керованому API-стеку це можуть бути конфігурація gateway, маніфести розгортання, відповіді provider та audit log.
Не заявляйте про runtime verification, якщо scanner лише зіставив рядок. Позначте це як inferred і збережіть доказ зіставлення.
Крок 6: перевірте синтаксис, семантику та дрейф
Виконайте три окремі перевірки:
Перша перевірка автоматизована. Друга потребує доменних правил і, для деяких полів, людського перегляду. Третя потребує версійованих записів і стабільної межі порівняння.
Крок 7: підпишіть, збережіть, порівняйте та встановіть термін дії
Хешуйте артефакт, прив’яжіть його до збірки або розгортання, зберігайте в системі доказів лише для додавання або контрольованій системі та створюйте зрозуміле для людини порівняння. AIBoMGen — один із дослідницьких прототипів, що поєднує захоплення моделі та середовища з хешами, підписами й in-toto attestations під час навчання.
Підписи захищають цілісність після створення. Вони не роблять неповну або неправдиву декларацію істинною.
Встановіть термін дії або дату перегляду. Ідеальний інвентар за минулий квартал не описує змінну production-систему сьогодні.
Перетворіть інвентар на шлюз релізу
Інвентар стає корисним, коли змінює рішення. Визначте політику до початку релізного вікна.
| Умова | Дія за замовчуванням | Причина |
|---|---|---|
| --- | --- | --- |
| Ідентичність критичної моделі або runtime невирішена | Блокувати | Розгорнутий компонент неможливо відстежити |
| Runtime містить незадекларовану модель, API, інструмент або сховище даних | Заблокувати та розслідувати | Затверджена межа змінилася |
| Ревізія моделі змінилася, але посилання на оцінювання — ні | Блокувати | Докази затвердження не охоплюють кандидата |
| Відсутня обов’язкова ліцензія або обмеження використання | Передати на відповідальний перегляд; блокувати, якщо цього вимагає політика | Права не можна вивести з доступності |
| Евристичний висновок суперечить декларації | Блокувати або ізолювати доказ | Принаймні одне джерело є неправильним або застарілим |
| У некритичному описі бракує деталей | Створити обмежене в часі завдання на виправлення | Прогалина може не виправдовувати зупинку сервісу |
| AIBOM змінився лише через зміну часу спостереження | Дозволити | Матеріального дрейфу системи не відбулося |
Налаштовуйте критичність відповідно до системи. Помічник для написання текстів і інструмент для медичних рішень не повинні мати один універсальний поріг.
Відстежуйте чотири операційні показники:
Не оптимізуйте кількість заповнених полів. Це відтворить саме ту проблему, яку виявило дослідження повноти.
Той самий системний принцип проявляється в аналізі активності code-agent та інфраструктури→: можливості моделі — лише одна частина розгорнутої системи. Runtime, інструменти, маршрутизація та операційні засоби контролю визначають, що насправді отримують користувачі.
Не додавайте секрети та персональні дані
AIBOM, імовірно, циркулюватиме серед інженерів, команд безпеки, аудиторів, клієнтів і автоматизованих систем. Розглядайте його як інвентар, а не сховище секретів.
Не додавайте:
Посилайтеся на секрети через шлях у secret manager або логічний ідентифікатор, не додаючи значення. Посилайтеся на чутливі набори даних через керований ID каталогу, версію, класифікацію, власника та хеш цілісності. Застосовуйте контроль доступу до повного артефакту, якщо навіть його метадані є чутливими.
Чого AIBOM не може довести
AI bill of materials покращує відстежуваність. Він не доводить:
Дослідження повноти за липень вимірює охоплення документацією, а не якість моделі. Репозиторій k8s-aibom прямо зазначає, що його результат не сертифікує відповідність. Обидва обмеження важливі.
Використовуйте AIBOM як карту від рішення до доказів, які можна перевірити. Поєднуйте його з оцінюванням, авторизацією, моніторингом, реагуванням на інциденти, засобами захисту приватності та відповідальним переглядом. Карта пришвидшує ці процеси, оскільки повідомляє кожному рецензенту, яку саме систему він оцінює.
Поширені запитання
Що таке AI bill of materials?
AI bill of materials — це машиночитаний інвентар моделей, наборів даних, програмного забезпечення, runtime, інструментів, походження, обмежень і доказів, що лежать в основі AI-системи. Корисний AIBOM визначає незмінні версії, власників, невирішені факти та зміни між затвердженим і робочим станом.
Чи є AI BOM тим самим, що й SBOM?
Ні. SBOM інвентаризує програмні компоненти та залежності. AI BOM пов’язує цей програмний інвентар зі специфічними для AI компонентами, такими як моделі, набори даних, adapters, оцінювання, призначене використання, обмеження та runtime-маршрути. Production AI-системі зазвичай потрібні обидва.
Чи варто використовувати CycloneDX або SPDX для AIBOM?
Використовуйте формат, який підтримують ваші downstream-інструменти та споживачі доказів. CycloneDX має задокументовані можливості AI/ML-BOM; SPDX 3 має профілі AI та dataset. Спочатку перевірте один канонічний формат. Додавайте другий лише тоді, коли цього потребує політика, клієнт або інтеграція.