An Inventaris AI adalah katalog yang terus diperbarui dari setiap aset AI yang berjalan di seluruh organisasi Anda — model, titik akhir berbasis AI, kumpulan data, asisten pengkodean AI, server MCP, dan dependensi AI — beserta hubungan, risiko, dan pemilik yang menghubungkannya. Dalam konteks keamanan, ini tidak ada hubungannya dengan manajemen gudang atau inventaris stok; di sini, "Inventaris AI" Sederhananya, ini berarti mengetahui secara pasti AI apa yang Anda jalankan, di mana letaknya, dan apa yang dapat dijangkaunya.
Seiring dengan meluasnya AI di setiap tahap pengembangan perangkat lunak, mulai dari pembuatan kode di IDE hingga agen otonom yang beroperasi di dalamnya CI/CD pipelineJadi, pertanyaannya bukan lagi apakah AI hadir di lingkungan Anda. Yang terpenting adalah apakah Anda bisa melihatnya. Panduan ini menjelaskan apa itu inventaris AI, dan bagaimana kaitannya dengan... AI-BOM dan SBOMmengapa bayangan AI telah menjadi masalah keamanan, dan bagaimana praktik tersebut berkaitan dengan hal tersebut. UU AI UE, NIST AI RMF ke ISO / IEC 42001.
Takeaway kunci
- Inventaris AI mencatat setiap model, dataset, agen, server MCP, dan alat pengkodean AI di seluruh siklus hidup perangkat lunak Anda, bukan hanya yang disetujui oleh TI.
- Bayangan AIAI yang diadopsi tanpa tata kelola, kini menjadi norma, bukan pengecualian: dalam sebuah survei tahun 2026 terhadap para pemimpin keamanan, hanya 19% organisasi melaporkan memiliki visibilitas penuh tentang di mana dan bagaimana AI digunakan..
- An AI-BOM (Daftar Komponen AI) adalah hasil siap audit dari inventaris AI: penerus era AI dari SBOM.
- Regulasi akan segera hadir. Undang-Undang AI Uni Eropa, NIST AI RMF, dan ISO/IEC 42001 pada dasarnya mewajibkan Anda untuk mengetahui AI apa yang Anda operasikan.
- Inventarisasi hanyalah titik awal; nilai sebenarnya berasal dari penilaian risiko dan tindakan terhadap sejumlah kecil aset yang benar-benar penting.
Apa itu inventaris AI?
Inventarisasi AI adalah praktik menemukan, mengkatalogkan, dan terus memantau setiap aset AI yang beroperasi di seluruh siklus pengembangan perangkat lunak Anda, serta risiko yang terkait dengan masing-masing aset tersebut. Inventarisasi lengkap menjawab tiga pertanyaan untuk setiap aset: apa itu, di mana ia berjalan, dan apa yang dapat diaksesnya?
Cakupan tersebut lebih luas dari yang diperkirakan sebagian besar tim. Inventaris AI yang bermakna harus mencakup:
- Model: setiap model bahasa besar dan model dasar yang digunakan di seluruh pengembangan dan produksi, dengan versi, lokasi, dan tingkat kepercayaan deteksi.
- Dataset: data pelatihan, kumpulan data pengambilan, dan penyimpanan vektor, termasuk paparan terhadap konteks yang terkontaminasi dan kebocoran data.
- AgenSistem otonom yang melakukan tindakan di lingkungan Anda, seperti membuka pull requests, menginstal dependensi, atau mengubah infrastruktur.
- server MCP: Protokol Konteks Model server yang menghubungkan asisten AI ke alat eksternal, API, dan sumber data.
- Alat dan asisten pengkodean AI: co-pilot dan integrasi IDE yang menghasilkan kode, menyarankan dependensi dan berinteraksi dengan repositori.
- Kerangka kerja AI: LangChain, LangGraph, server agen, dan lapisan orkestrasi lainnya yang menghubungkan model ke alat dan data.
- Hubungan antar aset: hubungan antara model, agen, server, kumpulan data, dan rahasia yang terkait dengannya. Grafik hubungan membuat risiko terlihat dalam konteks, bukan sebagai daftar datar.
Inventaris AI vs inventaris aset AI vs BOM AI, dan bagaimana perbedaannya dari SBOM
Istilah-istilah ini digunakan secara longgar, jadi ada baiknya untuk bersiap-siap.cise. “Inventaris AI” dan “inventaris aset AI” menggambarkan hal yang sama.: Katalog aset AI dan risikonya yang terus berkembang. Sebuah AI-BOM adalah artefak yang dapat diekspor yang dihasilkan oleh inventaris.: daftar bahan baku yang dapat dibaca mesin yang dapat Anda berikan kepada auditor atau enterprise pembeli.
Cara paling mudah untuk memahami AI-BOM adalah dengan analogi terhadap... SBOM:
| SBOM | AI-BOM | |
|---|---|---|
| Katalog | Ketergantungan perangkat lunak sumber terbuka dan pihak ketiga | Aset khusus AI: models, datasets, agents, MCP servers, AI coding tools |
| Dasar risiko | Tingkat keparahan CVE | Vektor serangan khusus AI (injeksi cepat, MCP yang tidak aman, agensi yang berlebihan) ditambah asal usul dan paparan data. |
| Penggerak utama | Transparansi rantai pasokan | Tata kelola AI, keamanan, dan kepatuhan terhadap peraturan |
Seiring dengan semakin terintegrasinya AI di berbagai bidang SDLC, AI-BOM menjadi semakin mendasar seperti halnya SBOM, dan para pemimpin keamanan semakin sering menerima permintaan dari auditor dan enterprise tim pengadaan untuk artefak ini.
Mengapa inventaris AI penting sekarang?
Tiga faktor telah mengubah inventaris berbasis AI dari sesuatu yang hanya pelengkap menjadi prioritas.
- Pertama, AI menulis kode yang tidak aman dalam skala besar. Penelitian independen secara konsisten menemukan bahwa sebagian besar kode yang dihasilkan AI mengandung kerentanan. Studi asli NYU/Copilot oleh Pearce dkk. menemukan sekitar 40% dari program yang dihasilkan mengandung kelemahan keamanan., dan pengujian skala besar yang lebih baru menunjukkan hal yang sama: analisis Veracode tahun 2025 di lebih dari 100 model hanya menemukan 55% kode yang dihasilkan AI aman.Jika Anda tidak tahu asisten mana yang menghasilkan kode di sistem Anda pipelineJadi, Anda tidak dapat mengendalikan risiko tersebut.
- Kedua, rantai pasokan perangkat lunak telah menjadi permukaan serangan AI. Pada bulan September 2025, Shai Hulud, worm npm pertama yang dapat menyebar sendiri, mengubah mesin pengembang menjadi mekanisme distribusi, menyebar ke ratusan paket. Pada Maret 2026, penyerang berhasil membobol sistem tersebut. aksioma, sebuah paket dengan kira-kira 100 juta unduhan mingguan, menerbitkan versi yang telah disusupi yang menyebarkan trojan akses jarak jauh. Serangan seperti ini tepat mengenai lapisan di antara AppSec tradisional dan perangkat pengamanan titik akhir: lapisan yang dirancang untuk diungkap oleh inventaris AI.
- Ketiga, rahasia dan kredensial bocor melalui AI. Laporan GitGuardian berjudul State of Secrets Sprawl 2026 menyatakan bahwa Kebocoran rahasia layanan AI meningkat 81% dari tahun ke tahun., dan yang dibantu AI commits leak secretdengan tingkat sekitar dua kali lipat dari tingkat dasar. Setiap model, agen, atau server MCP yang tidak terdokumentasi merupakan jalur potensial untuk mendapatkan kredensial.
Keamanan aplikasi tradisional berhenti di repositori dan tidak memahami apa itu model. Alat endpoint memantau sistem operasi tetapi tidak memahami paket, server MCP, atau asisten AI. Kesenjangan di antara mereka adalah tempat risiko AI menumpuk, dan inventarisasi adalah langkah pertama untuk menutupnya.
Di mana AI bersembunyi: AI bayangan di seluruh SDLC
Bayangan AI Setiap sistem AI yang diadopsi tanpa persetujuan atau tata kelola formal adalah: copilot yang diaktifkan oleh pengembang minggu lalu, server MCP yang berjalan di laptop, model yang diambil langsung dari pusat publik ke dalam proyek sampingan. Ini bukan kasus khusus. Dalam survei tahun 2026 terhadap lebih dari 400 pemimpin keamanan, hanya Sebanyak 19% melaporkan memiliki visibilitas penuh tentang di mana dan bagaimana AI digunakan. di seluruh organisasi mereka, sementara sebagian besar sudah menggunakan atau menguji coba asisten pengkodean AI.
AI bayangan yang paling sulit ditemukan adalah AI di dalam siklus hidup perangkat lunak, karena jarang muncul di konsol cloud:
- Model dan pustaka AI dimasukkan ke dalam repositori sebagai dependensi.
- Asisten pengkodean AI dikonfigurasi per pengembang, per IDE.
- Server MCP dan berkas aturan berjalan secara lokal pada titik akhir pengembang.
- Alur kerja agenik mulai terbuka secara diam-diam. pull requests atau menginstal paket.
Inilah mengapa penemuan berbasis cloud saja tidak cukup. Inventaris AI yang benar-benar lengkap harus menjangkau kode dan lingkungan pengembangan (laptop pengembang, repositori, dll.). pipeline), bukan hanya cloud produksi.
Apa saja yang termasuk dalam AI-BOM?
AI-BOM yang siap diaudit mengubah inventaris Anda menjadi sesuatu yang dapat Anda buktikan. Minimal, AI-BOM harus mencakup:
- Semua aset AI: model, kumpulan data, agen, server MCP, alat pengkodean AI.
- Jenis aset, lokasi, dan tingkat kepercayaan deteksi untuk masing-masing aset.
- Asal usul dan ketergantungan (dari mana model atau komponen tersebut berasal).
- Tingkat risiko per aset, berdasarkan vektor serangan khusus AI.
- Pemetaan regulasi ke UU AI Uni Eropa, NIST AI RMF, dan ISO/IEC 42001.
- Format yang dapat diekspor dan dibaca mesin untuk auditor dan pelanggan.
Organisasi yang mampu menghasilkan AI-BOM (Bill of Materials) sesuai permintaan akan memiliki keunggulan nyata dalam hal kepatuhan dan kepercayaan seiring dengan semakin matangnya kewajiban audit AI.
Inventarisasi dan kepatuhan AI: Undang-Undang AI Uni Eropa, NIST AI RMF, dan ISO/IEC 42001
Tak satu pun dari kerangka kerja utama menyebutkan "inventaris AI" sebagai salah satu poinnya, tetapi masing-masing kerangka kerja tersebut pada dasarnya mustahil dipenuhi tanpa itu. Anda tidak dapat mendokumentasikan, mengklasifikasikan, atau mengatur sistem AI yang tidak dapat Anda lihat.
| Kerangka | Mengapa inventarisasi diperlukan? |
|---|---|
| UU AI UE | Sistem berisiko tinggi memiliki kewajiban dokumentasi dan registrasi, dan Article 50 memperkenalkan kewajiban transparansi. Untuk memenuhinya, diperlukan pengetahuan tentang sistem AI apa yang Anda jalankan dan bagaimana sistem tersebut diklasifikasikan. |
| NIST AI RMF | The Map fungsi dan Govern 1.6 menyerukan penggunaan sistem AI untuk inventarisasi dan pemetaan sebagai dasar pengelolaan risiko mereka. |
| ISO / IEC 42001 | Sistem manajemen AI standard Hal ini mengharuskan pemeliharaan inventaris sistem AI sebagai kontrol inti. |
Catatan tentang waktu pelaksanaan: peluncuran Undang-Undang AI Uni Eropa direvisi oleh perjanjian "Digital Omnibus" Mei 2026, yang menunda sebagian besar kewajiban berisiko tinggi hingga Desember 2027, sementara beberapa tonggak penting 2 Agustus 2026 tetap berlaku (kewajiban transparansi, kewenangan sanksi GPAI). Anggap tanggal pastinya sebagai target yang terus berubah dan konfirmasikan dengan sumber utama Uni Eropa. Namun, arah perkembangannya jelas, dan inventarisasi adalah prasyarat untuk semuanya.
Cara membangun dan memelihara inventaris berbasis AI.
Membangun inventaris bukan hanya tentang audit sekali saja, tetapi lebih tentang membangun proses berkelanjutan, karena aset AI terus berubah: model baru diadopsi, agen baru dikerahkan, server MCP baru dikonfigurasi, seringkali tanpa persetujuan.
Pendekatan praktis:
- Temukan secara otomatis di seluruh kode, proses build, dan cloud. Lembar kerja manual akan usang dalam hitungan hari. Proses penemuan harus berjalan terus menerus dan menjangkau hingga ke dalam SDLC, bukan hanya waktu eksekusi.
- Klasifikasikan dan petakan hubungan. Jenis catatan, lokasi, asal usul, dan yang terpenting, bagaimana setiap aset terhubung dengan aset lain dan dengan rahasia.
- Nilai risiko dalam konteksnya. Daftar ratusan temuan yang datar tidak membantu siapa pun; prioritaskan berdasarkan apa yang benar-benar dapat dijangkau, dimanfaatkan, dan penting bagi bisnis.
- Tetapkan kepemilikan. Setiap aset membutuhkan pemilik yang bertanggung jawab.
- Pertahankan agar tetap aktif dan dapat diekspor. Pertahankan sebagai inventaris berkelanjutan yang dapat menghasilkan AI-BOM sesuai permintaan.
Hal yang perlu diperhatikan dalam perangkat lunak inventaris berbasis AI.
Jika Anda sedang mengevaluasi perangkat lunak, berikut adalah kemampuan yang membedakan perangkat lunak inventaris berbasis AI yang sesungguhnya dari daftar statis:
- Memahami jenis aset khusus AI (model, agen, server MCP, kumpulan data), bukan hanya paket dan pustaka.
- Menjangkau ke dalam SDLC, menemukan AI dalam kode dan pada titik akhir pengembang, tidak hanya di cloud.
- Hubungan peta, bukan hanya aset individual, sehingga risiko terlihat dalam konteksnya.
- Mengevaluasi risiko berdasarkan vektor serangan khusus AI. (injeksi cepat, MCP yang tidak aman, agensi yang berlebihan), bukan hanya tingkat keparahan CVE.
- Berjalan terus menerus, menangkap AI baru saat muncul.
- Menghasilkan AI-BOM yang siap diaudit. yang memuaskan baik auditor maupun enterprise pengadaan.
- Menghubungkan inventaris dengan penegakan hukum, sehingga Anda dapat menindaklanjuti apa yang Anda temukan.
Dari inventaris ke tindakan: mengamankan apa yang Anda temukan
Penemuan adalah langkah pertama; langkah kedua adalah memahami aset mana yang membawa risiko nyata, karena sebagian besar sebenarnya tidak. Tujuannya adalah untuk beralih dari ribuan temuan mentah ke segelintir temuan yang benar-benar dapat membahayakan sistem, data, atau operasi: yaitu temuan yang sedang digunakan, menerima input yang tidak tepercaya, secara realistis dapat dieksploitasi, memiliki akses sensitif, dan memengaruhi produksi atau aset yang diatur.
Di sinilah Manajemen Postur Keamanan AI (AI-SPM) mencakup: melakukan inventarisasi, menilai risiko di sepanjang jalur serangan AI, memetakannya ke regulasi, dan menghasilkan AI-BOM. Ini juga merupakan titik temu antara inventarisasi dan penegakan hukum: memblokir dependensi berbahaya sebelum diinstal, menolak server dan model MCP yang tidak disetujui, dan mengisolasi titik akhir yang disusupi sebelum insiden menyebar.
At XygeniInilah model yang kami bangun: inventaris AI berkelanjutan dan AI-BOM melalui AI-SPM, deteksi malware yang menangkap paket berbahaya sebelum tanda tangan ada.MEW, Peringatan Dini Malware), dan penegakan kebijakan di titik akhir pengembang melalui Xygeni Shield. Deteksi diselaraskan dengan OWASP Top 10 untuk Aplikasi LLM, OWASP Top 10 untuk Aplikasi Agentik, dan OWASP MCP Top 10. Namun, apa pun pendekatan yang Anda pilih, prinsipnya tetap berlaku: Anda tidak dapat mengamankan apa yang tidak dapat Anda lihat, dan inventaris berbasis AI adalah tempat visibilitas dimulai.
Pertanyaan Umum Demo Slot
Apa perbedaan AI-BOM dengan SBOM?
An SBOM Mengkatalogkan ketergantungan perangkat lunak sumber terbuka dan pihak ketiga, yang diberi skor berdasarkan tingkat keparahan CVE. AI-BOM mengkatalogkan aset khusus AI (model, agen, server MCP, kumpulan data) dengan penilaian risiko khusus AI dan pemetaan peraturan. Seiring AI menyebar ke seluruh dunia... SDLC, AI-BOM menjadi semakin mendasar seperti halnya SBOM.
Apa itu AI bayangan dan bagaimana cara saya mendeteksinya?
Shadow AI adalah AI apa pun yang diadopsi tanpa persetujuan atau tata kelola formal: copilot yang diaktifkan, server MCP lokal, model yang diambil dari hub publik. Anda menemukannya dengan inventaris otomatis berkelanjutan yang menjangkau kode dan pembangunan. pipelinedan titik akhir pengembang, bukan hanya cloud produksi tempat sebagian besar AI bayangan tidak pernah muncul.
Apakah Undang-Undang AI Uni Eropa mewajibkan inventarisasi AI?
Undang-Undang AI Uni Eropa tidak secara eksplisit menyebutkan "inventaris AI", tetapi kewajiban dokumentasi, klasifikasi, dan registrasi untuk sistem berisiko tinggi tidak mungkin dipenuhi tanpa inventaris tersebut. Hal yang sama berlaku untuk NIST AI RMF (Fungsi Peta, Tata Kelola 1.6) dan ISO/IEC 42001, yang mensyaratkan pemeliharaan inventaris sistem AI.
Apa itu AI-SPM?
Manajemen Postur Keamanan AI (AI-SPM) adalah praktik terus-menerus menemukan aset AI, menilai risikonya sepanjang jalur serangan AI, memetakannya ke regulasi, dan menghasilkan AI-BOM. Ini memperluas pemikiran manajemen postur (yang dikenal dari CSPM dan DSPM) ke aset dan vektor serangan khusus AI.
Seberapa sering inventaris AI perlu diperbarui?
Secara terus-menerus. Aset AI berubah setiap hari seiring tim mengadopsi model baru, menerapkan agen baru, dan mengkonfigurasi server MCP baru, biasanya tanpa persetujuan formal. Pemindaian pada satu titik waktu akan usang dalam beberapa hari, sehingga perangkat lunak inventaris AI yang efektif berjalan sebagai proses berkelanjutan, bukan sebagai audit sekali saja.
Bagaimana cara saya menginventarisasi AI yang digunakan dalam kode sumber?
Menginventarisasi AI dalam kode berarti mendeteksi model dan pustaka AI yang ditarik sebagai dependensi, asisten pengkodean AI yang dikonfigurasi per pengembang, dan server MCP atau file aturan yang berjalan secara lokal. Ini membutuhkan penemuan yang beroperasi di dalam SDLC (repositori, membangun) pipelines dan titik akhir pengembang) daripada hanya di konsol cloud.




