Bir AI malzeme listesi yalnızca iki soruyu yanıtlayabiliyorsa faydalıdır: dağıtımdan önce ne beyan edilmişti ve bir karar, olay ya da denetim gerçekleştiğinde gerçekte ne çalışıyordu? Her ikisini de yanıtlayamayan geçerli bir JSON dosyası, envanter tiyatrosundan ibarettir.
Pratik tasarım, eşleştirilmiş bir envanterdir. Derleme veya tedarik sırasında standartlara dayalı bir kayıt oluşturun, canlı sistemi çalışma zamanında gözlemleyin, her alan için kanıtı koruyun ve ikisini karşılaştırın. Kritik bir model, veri kümesi, çalışma zamanı, API, ajan aracı veya lisans çözümlenmemişse sürümü engelleyin.
Okuyucu seviyesi: İleri. Bu kılavuz, model destekli sistemleri işleten mühendisler, güvenlik ekipleri, platform sahipleri ve teknik yönetişim liderleri içindir.
İçindekiler
Bir AI malzeme listesi neleri yanıtlamalıdır
AI malzeme listesi, genellikle AIBOM veya AI BOM olarak kısaltılır; bir AI sisteminin arkasındaki bileşenlerin ve kanıtların makine tarafından okunabilir envanteridir. Geleneksel bir yazılım malzeme listesini paketlerin ve kütüphanelerin ötesine taşır.
Envanter, bir inceleyicinin şu soruları yanıtlamasını sağlamalıdır:
CycloneDX, AI/ML-BOM yeteneğini modelleri, veri kümelerini, yapılandırmaları, köken bilgilerini ve bağımlılıkları temsil etmenin bir yolu olarak tanımlar. SPDX 3.0.1 de AI profili tanımlar. Bunlar birlikte çalışabilir veri modelleridir; eksik kanıtın kendisinin yerine geçmezler.
Bir model card daha dar bir soruyu yanıtlar: bu model ne yapmak üzere tasarlanmıştır, nasıl değerlendirildi ve nerede başarısız olabilir? Orijinal Model Cards makalesi, amaçlanan kullanım, değerlendirme koşulları ve ilgili gruplar arasındaki performansı kapsayan dokümantasyon önermiştir. Bir data card, veri kümesinin kökenini, toplanmasını ve etiketlenmesini, amaçlanan kullanımını ve sonraki performansı şekillendiren kararları belgeler; Data Cards makalesi, 20'den fazla dağıtımdan elde edilen dersleri raporlar.
İkisini de koruyun. Bir model card veya data card insan bağlamı sağlar. AIBOM ise bu belgeleri sürümlenmiş bir sistem envanterine bağlar.
Geçerli AIBOM dosyaları neden hâlâ zayıf kanıt içerebilir
Temmuz 2026 tarihli bir çalışma bu ayrımı geniş ölçekte test etti. Yazarlar 2.942.466 herkese açık Hugging Face model kaydından oluşan bir anlık görüntü topladı, 100'den fazla indirmeye sahip 97.940 modeli korudu ve OWASP AIBOM Generator ile CycloneDX AIBOM'ları oluşturdu. 100 yapıttan oluşan bir örneği generator raporlarına göre kontrol ettiler ve ardından tüm kümede alanların bulunma oranını ölçtüler.
Raporlanan ortalama bütünlük puanı 100 üzerinden 54,31 idi. Gerekli yapısal alanlar oluşturulan yapıtların %100'ünde mevcuttu. Model card dokümantasyonu ortalama %19,51 seviyesindeydi.
Önemli sonuç bu farktır. Dosya yapısal olarak geçerli olabilir, ancak bir karar için gereken bilgiler eksik olabilir.
Alan düzeyindeki sonuçlar daha çarpıcıydı:
| Oluşturulan AIBOM'daki alan | Mevcut |
|---|---|
| --- | ---: |
| Lisans | %73,14 |
| Veri kümesi | %39,35 |
| Hyperparameter'lar | %25,40 |
| Teknik sınırlamalar | %16,74 |
| Güvenlik riski değerlendirmesi | %9,76 |
| Anlamlı açıklama | %0,22 |
| Enerji tüketimi | %0,02 |
Açıklama alanı neredeyse her yapıtta görünüyordu, ancak 97.940 açıklamanın yalnızca 211'i yer tutucu metnin ötesinde bilgi içeriyordu. Yalnızca şema varlığı kontrolü yapan bir sistem, diğer açıklamaları da tamamlanmış sayardı.
Yazarların ölçtüğü: Filtrelenmiş herkese açık bir Hugging Face anlık görüntüsünden oluşturulan AIBOM'larda alan ve kategori kapsamı.
Çıkardıkları sonuç: Model card ve harici referans dokümantasyonu, zayıf ve daha güçlü yapıtlar arasındaki farkın büyük bölümünü oluşturuyor.
Ortaya koymadıkları: Herhangi bir modelin güvenli, adil, performanslı, hukuken kullanılabilir veya belirli bir dağıtım için uygun olup olmadığı.
Yazarlar ayrıca sonuçlarının Hugging Face API'sine, generator'ın çıkarma mantığına ve 100 veya daha az indirmeye sahip modelleri dışlayan bir anlık görüntüye bağlı olduğu konusunda uyarıyor. Özel registry'ler, erişim kısıtlı modeller, diğer barındırma platformları ve depolardaki sonraki değişiklikler farklı görünebilir. Sonuçları anlamsal doğrulamayı destekler. Evrensel bir puan eşiği belirlemez.
Derleme zamanı envanteri ve çalışma zamanı envanteri farklı sorunları çözer
Derleme zamanı AIBOM'u niyeti kaydeder. Çalışma zamanı envanteri gözlemi kaydeder.
| Soru | Derleme zamanı kanıtı | Çalışma zamanı kanıtı |
|---|---|---|
| --- | --- | --- |
| Hangi model gönderilmeli? | Lockfile, manifest, tedarik kaydı, model özeti | Yüklenen model ID'si, endpoint, image özeti, serving yapılandırması |
| Hangi veriler kullanılabilir olmalı? | Eğitim ve değerlendirme beyanları, onaylı retrieval kaynakları | Bağlı vector store'lar, mount edilmiş veri kümeleri, canlı veri servisleri |
| Bir ajan hangi araçları çağırabilir? | Araç registry'si, politika, beyan edilmiş MCP sunucuları ve API'ler | Keşfedilen endpoint'ler, etkin entegrasyonlar, gözlemlenen yapılandırma |
| Inference'ı hangi yazılım destekliyor? | Paket ve container SBOM'u | Çalışan image, runtime, driver'lar, accelerator'lar |
| Hangi kısıtlamalar geçerli? | Lisans, model card, data card, sözleşme referansı | Mevcut sağlayıcı, bölge, rota, politika sürümü |
| Onaylanan sistem drift yaşadı mı? | Karşılaştırma için baseline | Baseline ile karşılaştırılacak kanıt |
Yalnızca derleme zamanı kanıtına güvenmek; acil değişiklikleri, shadow deployment'ları, değişebilir tag'leri, sağlayıcı yönlendirmesini ve yapılandırma drift'ini kaçırır. Yalnızca çalışma zamanı gözlemi ise onaylanmış amacı, lisansı, eğitim kökenini veya değerlendirme sınırını bilmeden bir süreç adı ya da endpoint görebilir.
Google, çalışma zamanı tarafını incelemek üzere 14 Temmuz 2026'da k8s-aibom'u open source olarak yayımladı. Controller, Kubernetes workload ve pod durumunu izler, detection rule'ları uygular ve CycloneDX 1.6 ML-BOM belgeleri üretir. Belgelenen kapsamı inference runtime'larını, agent framework'lerini, vector database'lerini, training job'larını ve evaluation harness'larını içerir. Privileged bir DaemonSet veya kernel erişimi olmadan çalışır.
Proje yararlı bir mimari noktayı ortaya koyuyor: derleme zamanı ve çalışma zamanı AIBOM'ları birbirini tamamlar. Ancak bu yazılım henüz erken aşamadadır. Repository, v1.0'ı alpha olarak ve kritik olmayan gözlem kullanım senaryoları için uygun olarak etiketliyor. Hosted bir image veya Helm repository sunmuyor ve mevcut `NoopVerifier` bir kimliği kriptografik olarak doğrulanmış şeklinde işaretleyemiyor.
Bir NVIDIA AICR maintainer'ı, k8s-aibom'un çalışma zamanı gözlemlerini AICR deployment niyeti ve imzalı attestation'larla bağlayacak bir k8s-aibom ve AICR entegrasyonu önerdi. Yazar, amacı bir ekibin dağıttığı şeyin sistemin çalıştırdığı şey olduğunu gösteren kanıt olarak tanımlıyor. Issue'ya bağlı bir implementation, assignee veya milestone bulunmuyor. Bunu resmi bir roadmap veya tamamlanmış tasarım olarak değil, uygulayıcı önerisi olarak değerlendirin.
Tek bir yeni controller'ı evrensel bir ürün önerisine dönüştürmeyin. Şu modeli kullanın: beyan edilmiş durumu gözlemlenen durumla eşleştirin, kanıtı koruyun ve belirsizliği görünür kılın.
_Faydalı bir AI malzeme listesi, derleme niyetini çalışma zamanı kanıtına, anlamsal kontrollere ve sürümlenmiş bir karara bağlar._
Kaydetmeye değer yedi katman
Kesin şema, standardınıza ve dağıtımınıza bağlıdır. Aşağıdaki katmanlar, üretim envanteri için pratik bir minimum oluşturur.
1. Model kimliği
Sağlayıcıyı, model ailesini, değişmez revizyonu veya özeti, formatı, temel modeli, adapter'ları, quantization'ı, tokenizer'ı ve serving rotasını kaydedin. `support-model` gibi kullanıcı dostu bir alias insanlar için yararlıdır, ancak izlenebilirlik için yetersizdir.
Harici bir API için sağlayıcının kararlı model tanımlayıcısını ve onu seçen gateway rotasını kaydedin. Sağlayıcı bir alias'ın arkasındaki modeli sessizce güncelleyebiliyorsa, kesinlik uydurmak yerine revizyonu çözümlenmemiş olarak etiketleyin.
2. Veri ve retrieval bağımlılıkları
Bilgi mevcut olduğunda beyan edilmiş eğitim, fine-tuning, değerlendirme ve calibration veri kümelerini kaydedin. Bir RAG sistemi için kaynak koleksiyonlarını, embedding modelini, chunking sürümünü, vector-store servisini, erişim politikasını ve güncellik sınırını ekleyin.
Veri kümesi tanımlayıcılarını, sürümlerini, hash'lerini, sözleşmelerini veya kontrollü katalog referanslarını saklayın. Ham müşteri kayıtlarını veya özel eğitim örneklerini AIBOM'a kopyalamayın.
Ekipler Next.js ve AI ajanlarıyla özel veri sistemleri oluşturduğunda→, şema sürümü, migration sınırı ve bağlı servisler model yapıtı olmasalar bile sistem bağlamına aittir.
3. Runtime ve yazılım
AI envanterini normal SBOM'a bağlayın. Container özetini, inference engine'ini, framework'ü, ilgili kütüphaneleri, driver ve accelerator sınıfını ve model davranışını değiştirebilecek yapılandırmayı kaydedin.
Bu önemlidir çünkü aynı ağırlıklar tokenizer, attention backend'i, quantization yolu veya serving engine'i değiştikten sonra farklı davranabilir. Daha fazla AI token'ının compute faturasını neden değiştirdiğine→ ilişkin analiz, bir dağıtım kaydının yalnızca model adını değil, runtime bütçesini ve yapılandırmasını da içermesi gerektiğini gösterir.
4. Araçlar, API'ler ve ajan izinleri
Şirketin herhangi bir yerinde kurulu olan her aracı değil, bir ajanın erişebileceği araçları listeleyin. Model gateway'lerini, MCP sunucularını, browser veya code-execution araçlarını, harici API'leri ve her eylemi yöneten politika referansını dahil edin.
Envanter yetkilendirmeyi uygulamaz. Bunu deterministik kontrollerle eşleştirin. AI ajanı izinleri→ hakkındaki makale, bir modelin kendini sınırlamasının neden bir erişim kontrolü sınırı olmadığını açıklar.
5. Değerlendirme ve çalışma sınırları
Onay için kullanılan kesin değerlendirme kümesine, evaluator sürümüne, eşiklere, tarihe ve koşullara referans verin. Bilinen hata modlarını, amaçlanan ve hariç tutulan kullanımları, fallback davranışını, monitoring sahibini ve kararın son geçerlilik tarihini kaydedin.
Test kimliği olmadan “değerlendirmeyi geçti” yazmayın. Değişmiş bir modelin değişmemiş bir sonuç dizesiyle temsil edilmesi zayıf kanıttır.
6. Haklar, politika ve köken
Model ve veri kümesi lisanslarını, kullanım kısıtlamalarını, yeniden dağıtım koşullarını, kaynak repository'lerini, model card'ları, data card'ları, makaleleri, onayları ve attestation'ları kaydedin. Kaynak erişim kontrollüyse referansları ve hash'leri saklayın.
Bu katman incelemeyi destekler. Hukuki bir soruya karar vermez. Eksik veya çelişkili hak bilgileri, bu karardan sorumlu kişiye yönlendirilmelidir.
7. Sahiplik ve yaşam döngüsü
Her kaydın bir sahibi, sistem amacı, ortamı, oluşturulma zamanı, gözlem zamanı, yerini aldığı sürüm ve saklama kuralı olmalıdır. Sahiplik olmadan envanter, terk edilmiş gerçeklerin arşivine dönüşür.
Yeniden dağıtımlardan bağımsız kalan kararlı bir sistem ID'si ekleyin. Sürümlenmiş bir AIBOM, neyin değiştiğinin, bunu kimin kabul ettiğinin ve hangi kanıtın kararı desteklediğinin geçmişini göstermelidir.
Her olguyu beyan edilmiş, çıkarılmış, doğrulanmış veya çözümlenmemiş olarak etiketleyin
Bir AIBOM, alan düzeyinde kanıt durumunu taşımalıdır. Tüm belge için tek bir etiket kullanmak çok fazla şeyi gizler.
İlk üç etiket farklı kanıt güçlerini tanımlar. “Beyan edilmiş”, “doğrulanmış”ın daha zayıf yazımı değildir. Eğitim verileri için bir sağlayıcı beyanı mevcut tek kaynak olabilirken, bir image özeti mekanik olarak doğrulanabilir.
k8s-aibom projesi şu anda `declared`, `inferred` ve `unresolved` durumlarını, öznitelikler için kanıt konumlarıyla birlikte uyguluyor. README, kriptografik `verified` durumunu mevcut bir özellik olarak iddia etmek yerine roadmap'e koyuyor. Bu dürüstlüğü kendi sisteminizde de koruyun.
Kavramsal bir kayıt şöyle görünebilir:
{ "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" ] }
Bu, tasarım amaçlı bir taslaktır; CycloneDX veya SPDX ile uyumlu bir belge değildir. Gerçek yapıt için seçtiğiniz standardın şemasını ve validator'ını kullanın.
Yeniden üretilebilir bir AIBOM iş akışı
Adım 1: sistem sınırını tanımlayın
Kapsamdaki uygulamayı, ortamları, sahipleri ve kullanıcıya dönük kararları adlandırın. Envanterin tek bir model endpoint'ini, bir ajan iş akışını veya eksiksiz bir ürünü kapsayıp kapsamadığına karar verin.
“Her şey AI” gibi bir sınır test edilemez. “Üretimdeki support agent ve yanıtını veya eylemlerini değiştirebilecek her servis” test edilebilir.
Adım 2: derleme ve tedarik kanıtını toplayın
Normal SBOM'u oluşturun, model ve veri kümesi tanımlayıcılarını çözümleyin, değişmez özetleri yakalayın ve model card'ları, data card'ları, lisansları, değerlendirmeleri ve onayları bağlayın.
OWASP AIBOM Generator, Hugging Face metadata'sını CycloneDX 1.6'ya çıkarabilir ve eksik alanları raporlayabilir. Çıktısını başlangıç envanteri olarak değerlendirin. Geniş ölçekli çalışma, otomatik doldurulan bir alanın bile içerik kontrolüne ihtiyaç duyduğunu gösteriyor.
Adım 3: standart bir belge üretin
Tüketicilerinizin ayrıştırabileceği bir format seçin. CycloneDX, bir AI/ML-BOM yeteneği ve bir uygulama kılavuzu sunar. SPDX 3, AI ve dataset profillerini sağlar.
Format seçimi, alıcı sistemleri, politika motorunu, attestation pipeline'ını ve müşteri gereksinimlerini izlemelidir. Gerçek bir tüketici her ikisine de ihtiyaç duymuyorsa iki formatı birlikte sürdürmekten kaçının.
Adım 4: otomasyonun bilemeyeceği bilgileri zenginleştirin
Amaçlanan kullanımı, sınırlamaları, veri kümesi kökenini, değerlendirme koşullarını, hakları ve risk kararlarını doldurmaları için sahipler atayın. Alan kritik bir kararsa “N/A”, “standard model” veya kopyalanmış pazarlama metni gibi yer tutucuları reddedin.
Bilinmeyen değerler için açık bir neden isteyin. “Sağlayıcı eğitim verilerini açıklamıyor” ifadesi, boş bir diziden daha iyi kanıttır; çünkü eksik işi mevcut olmayan bilgiden ayırır.
Adım 5: canlı dağıtımı gözlemleyin
Çalışma zamanı model ID'lerini, image özetlerini, endpoint'leri, bağlı store'ları, ajan araçlarını ve yapılandırmayı mevcut en az ayrıcalıklı mekanizmayla toplayın. Kubernetes'te bu, API'yi izleyen bir controller olabilir. Yönetilen bir API stack'inde ise gateway yapılandırması, deployment manifest'leri, sağlayıcı yanıtları ve audit log'ları olabilir.
Tarayıcı yalnızca bir dizeyle eşleştiyse çalışma zamanı doğrulaması iddiasında bulunmayın. Bunu çıkarılmış olarak işaretleyin ve eşleşen kanıtı koruyun.
Adım 6: sözdizimini, anlamı ve drift'i doğrulayın
Üç ayrı kontrol çalıştırın:
İlk kontrol otomatiktir. İkincisi alan kurallarına ve bazı alanlar için insan incelemesine ihtiyaç duyar. Üçüncüsü sürümlenmiş kayıtlar ve kararlı bir karşılaştırma sınırı gerektirir.
Adım 7: imzalayın, saklayın, karşılaştırın ve süresini doldurun
Yapıtı hash'leyin, derlemeye veya dağıtıma bağlayın, append-only ya da kontrollü bir kanıt sisteminde saklayın ve insan tarafından okunabilir bir diff üretin. AIBoMGen, eğitim sırasında model ve ortam yakalamayı hash'ler, imzalar ve in-toto attestation'larıyla birleştiren bir araştırma prototipidir.
İmzalar, oluşturulduktan sonra bütünlüğü korur. Eksik veya yanlış bir beyanı doğru hâle getirmez.
Bir son kullanma veya inceleme tarihi belirleyin. Geçen çeyreğe ait kusursuz bir envanter, bugün değişken olan üretim sistemini açıklamaz.
Envanteri bir sürüm kapısına dönüştürün
Envanter, bir kararı değiştirdiğinde faydalı olur. Sürüm penceresinden önce politikayı tanımlayın.
| Koşul | Varsayılan eylem | Gerekçe |
|---|---|---|
| --- | --- | --- |
| Kritik model veya runtime kimliği çözümlenmemiş | Engelle | Dağıtılan bileşen izlenemiyor |
| Runtime, beyan edilmemiş bir model, API, araç veya data store içeriyor | Engelle ve araştır | Onaylanan sınır drift yaşadı |
| Model revizyonu değişti ancak değerlendirme referansı değişmedi | Engelle | Onay kanıtı adayı kapsamıyor |
| Gerekli lisans veya kullanım kısıtlaması eksik | Sorumlu incelemesine yönlendir; politika gerektiriyorsa engelle | Haklar erişilebilirlikten çıkarılamaz |
| Sezgisel çıkarım bir beyanla çelişiyor | Kanıtı engelle veya karantinaya al | En az bir kaynak yanlış veya güncel değil |
| Kritik olmayan açıklama ayrıntıdan yoksun | Süre sınırlı bir düzeltme işi oluştur | Eksik, hizmeti durdurmayı gerektirmeyebilir |
| AIBOM yalnızca gözlem zamanı değiştiği için değişti | İzin ver | Maddi bir sistem drift'i oluşmadı |
Önem derecesini sisteme göre ayarlayın. Bir yazma yardımcısı ile tıbbi karar aracının aynı evrensel eşiği paylaşmaması gerekir.
Dört operasyonel ölçümü takip edin:
Doldurulan alanların sayısını optimize etmeyin. Bu, bütünlük çalışmasının ortaya çıkardığı hatayı yeniden üretir.
Aynı sistem ilkesi code-agent etkinliği ve altyapısı→ analizinde de görülür: model yeteneği, dağıtılan sistemin yalnızca bir parçasıdır. Kullanıcıların gerçekte aldığı şeyi runtime, araçlar, yönlendirme ve operasyonel kontroller belirler.
Gizli bilgileri ve kişisel verileri dışarıda tutun
Bir AIBOM'un mühendislik, güvenlik, denetçiler, müşteriler ve otomatik sistemler arasında dolaşması muhtemeldir. Ona bir sır deposu değil, envanter olarak davranın.
Şunları dahil etmeyin:
Sırları, değeri dahil etmeden secret-manager yolu veya mantıksal tanımlayıcıyla referanslayın. Hassas veri kümelerine yönetilen bir katalog ID'si, sürüm, sınıflandırma, sahip ve bütünlük hash'i üzerinden referans verin. Metadata'sı bile hassassa eksiksiz yapıta erişim kontrolü uygulayın.
Bir AIBOM neyi kanıtlayamaz
Bir AI malzeme listesi izlenebilirliği geliştirir. Şunları kanıtlamaz:
Temmuz ayındaki bütünlük çalışması model kalitesini değil, dokümantasyon kapsamını ölçer. k8s-aibom repository'si de çıktısının uyumluluğu sertifikalandırmadığını açıkça belirtir. Her iki sınırlama da önemlidir.
AIBOM'u bir karardan incelenebilir kanıta giden bir harita olarak kullanın. Onu değerlendirme, yetkilendirme, monitoring, olay müdahalesi, gizlilik kontrolleri ve sorumlu incelemeyle eşleştirin. Harita, hangi sistemi değerlendirdiklerini her inceleyiciye gösterdiği için bu süreçleri hızlandırır.
Sık sorulan sorular
AI malzeme listesi nedir?
AI malzeme listesi, bir AI sisteminin arkasındaki modellerin, veri kümelerinin, yazılımların, runtime'ların, araçların, köken bilgilerinin, kısıtlamaların ve kanıtların makine tarafından okunabilir envanteridir. Faydalı bir AIBOM, değişmez sürümleri, sahipleri, çözümlenmemiş olguları ve onaylanan durum ile canlı durum arasındaki değişiklikleri tanımlar.
AI BOM, SBOM ile aynı şey midir?
Hayır. SBOM, yazılım bileşenlerini ve bağımlılıklarını envanterler. AI BOM ise bu yazılım envanterini model, veri kümesi, adapter, değerlendirme, amaçlanan kullanım, sınırlamalar ve çalışma zamanı rotaları gibi AI'ya özgü bileşenlere bağlar. Üretim AI sistemi genellikle her ikisine de ihtiyaç duyar.
AIBOM için CycloneDX mi yoksa SPDX mi kullanmalıyım?
Alt sistemlerinizin ve kanıt tüketicilerinizin desteklediği formatı kullanın. CycloneDX belgelenmiş bir AI/ML-BOM yeteneğine sahiptir; SPDX 3 ise AI ve dataset profillerine sahiptir. Önce tek bir canonical formatı doğrulayın. İkinci formatı yalnızca bir politika, müşteri veya entegrasyon gerektiriyorsa ekleyin.