Bahasa Indonesia
Penjelasan Tinjauan Keamanan AI

Turn this article into takeaways for your work.
Each assistant summarizes the article only for you and suggests best practices for your work.
Tinjauan keamanan AI adalah pemeriksaan formal yang dijalankan pembeli enterprise terhadap produk AI milik vendor sebelum produk itu diizinkan menyentuh data perusahaan. Prosesnya dimulai seperti tinjauan vendor perangkat lunak biasa: kuesioner, sertifikasi, pertanyaan arsitektur, ketentuan kontrak. Kemudian ditambahkan lapisan pertanyaan kedua tentang risiko yang hanya ada karena produk tersebut memuat sebuah model, seperti prompt injection, kebocoran informasi sensitif, dan perangkat lunak yang mengambil tindakan atas nama pengguna.
Bagi startup AI, tinjauan ini sering kali menjadi titik di mana deal yang tampak pasti melambat selama berminggu-minggu. Namun prosesnya juga dapat diprediksi. Kerangka kerja yang digunakan peninjau bersifat publik, pertanyaannya berulang dari satu pembeli ke pembeli lain, dan sebagian besar pekerjaannya adalah menyiapkan bukti sebelum ada yang memintanya. Halaman ini menjelaskan apa itu tinjauan tersebut, perbedaannya dengan tinjauan SaaS standar, kerangka kerja yang mendasarinya, tahap-tahap yang dilaluinya, dan apa yang perlu disiapkan.
Apa Itu Tinjauan Keamanan AI
Tinjauan keamanan adalah proses due diligence dari sisi pembeli. Tim keamanan, risiko, atau TI pembeli memutuskan apakah produk vendor dapat digunakan dengan data pembeli, dan dengan syarat apa. Hasilnya biasanya berupa persetujuan, persetujuan bersyarat dengan perbaikan yang diwajibkan, atau penolakan.
Dua hal membuatnya berbeda dari percakapan penjualan pada umumnya. Audiensnya adalah pemilik risiko, bukan orang yang menginginkan produk tersebut. Dan buktinya harus tertulis, karena peninjau harus mempertanggungjawabkan keputusannya kepada orang lain di kemudian hari.
Dalam penjualan AI, tinjauan ini jarang berdiri sendiri. Prosesnya berjalan bersamaan dengan tinjauan hukum atas ketentuan data dan, semakin sering, pemeriksaan terpisah terhadap tata kelola AI. Lihat komite pembelian AI untuk mengetahui siapa yang duduk di seberang meja dan mengapa tim keamanan cenderung memegang hak veto.
Perbedaannya dengan Tinjauan SaaS Standar
Tinjauan keamanan SaaS standar menanyakan apakah vendor melindungi data dan menjalankan operasi yang disiplin. Tinjauan AI menanyakan semua itu, lalu menanyakan apakah lapisan model menimbulkan cara baru untuk kehilangan data, dimanipulasi, atau menimbulkan kerugian. Dasarnya tetap berlaku; lapisan AI merupakan tambahan.

| Area | Tinjauan SaaS standar | Tambahan untuk produk AI |
|---|---|---|
| Penanganan data | Enkripsi, kontrol akses, retensi, sub-pemroses | Apakah data pelanggan digunakan untuk pelatihan, apa yang dikirim ke penyedia model pihak ketiga, apakah prompt dan output dicatat |
| Keamanan aplikasi | Kerentanan web, autentikasi, uji penetrasi | Prompt injection, penanganan output model yang tidak aman, pengujian perilaku model terhadap input adversarial |
| Pihak ketiga | Penyedia cloud dan sub-pemroses | Penyedia model, bobot model open-source, dataset, plugin, dan alat yang dapat dipanggil model |
| Perilaku | Perangkat lunak melakukan apa yang tertulis dalam kode | Output bervariasi; peninjau menginginkan hasil evaluasi dan guardrail |
| Izin | Peran pengguna dan least privilege | Apa yang dapat dilakukan model atau agent secara mandiri, dan apa yang memerlukan persetujuan manusia |
| Jaminan | SOC 2, ISO 27001 | Sama, ditambah keselarasan dengan kerangka kerja manajemen atau risiko AI |
Baris perilaku adalah yang paling sering diremehkan para founder. Perangkat lunak konvensional bersifat deterministik, sehingga peninjau dapat menalar dari desainnya. Output model tidak tetap, sehingga peninjau meminta bukti pengujian sebagai gantinya. Hal ini terkait dengan pekerjaan evaluasi dalam mengapa demo lebih penting untuk produk AI.
Dasar: Kuesioner dan Sertifikasi
Sebelum pertanyaan khusus AI, sebagian besar tinjauan memeriksa hal-hal dasar yang sama.
Kuesioner keamanan. Pembeli sering mengirimkan kuesioner standar, atau kuesioner buatan mereka sendiri. Dua format standar yang banyak digunakan adalah kuesioner SIG (Standardized Information Gathering) dari Shared Assessments dan CAIQ dari Cloud Security Alliance. Halaman Cloud Controls Matrix milik CSA menggambarkan CCM sebagai meta-framework kontrol keamanan khusus cloud yang dipetakan ke standar-standar terkemuka, dan mendistribusikan CAIQ bersamanya, termasuk versi STAR Level 1 untuk diajukan ke CSA STAR Registry. Menjawab kuesioner yang sama berulang kali adalah pemborosan, sehingga startup yang memiliki satu CAIQ atau SIG yang lengkap dan mutakhir dapat menggunakan ulang sebagian besar isinya.
SOC 2. Laporan SOC 2 adalah pemeriksaan independen atas kontrol sebuah organisasi penyedia layanan. Halaman SOC suite milik AICPA mencantumkan lima area yang terkait dengan layanan tersebut: keamanan, ketersediaan, integritas pemrosesan, kerahasiaan, dan privasi. Laporan yang mencakup periode tertentu adalah artefak tunggal yang paling sering diminta peninjau enterprise.
ISO/IEC 27001. Standar internasional untuk manajemen keamanan informasi adalah permintaan umum lainnya, terutama dari pembeli di luar Amerika Serikat.
SOC 2 atau ISO 27001 tidak menjawab pertanyaan AI. Keduanya memberi tahu peninjau bahwa organisasi Anda menjalankan proses yang terkendali, yang merupakan tiket masuknya. Jika Anda belum memilikinya, sampaikan dengan jujur, berikan jadwal Anda, dan bersiaplah menjawab pertanyaan dasarnya secara langsung. Startup tahap awal sering lolos tinjauan dengan jawaban tertulis yang jelas dan roadmap yang terdefinisi, tetapi hal itu mempersempit pembeli yang bersedia mengambil risikonya.
Risiko Khusus AI yang Dicari Peninjau
Peninjau tidak menciptakan kategori risiko AI dari nol. Sebagian besar mengandalkan OWASP Top 10 for LLM Applications, yang diterbitkan oleh OWASP GenAI Security Project. Edisi 2025 mencantumkan sepuluh risiko:

- Prompt Injection
- Pengungkapan Informasi Sensitif
- Rantai Pasok
- Peracunan Data dan Model
- Penanganan Output yang Tidak Tepat
- Agensi Berlebihan
- Kebocoran System Prompt
- Kelemahan Vektor dan Embedding
- Misinformasi
- Konsumsi Tanpa Batas
Lima di antaranya muncul di hampir setiap tinjauan.
Prompt injection. Teks yang memanipulasi model agar mengabaikan instruksinya. Teks ini dapat datang langsung dari pengguna atau secara tidak langsung melalui konten yang dibaca model, seperti dokumen, halaman web, atau email. Pertanyaan peninjau adalah apa yang dapat dipaksakan penyerang agar dilakukan atau diungkapkan produk Anda, dan batasan apa yang ada jika model berhasil dikelabui.
Pengungkapan informasi sensitif. Dapatkah produk mengekspos data satu pelanggan kepada pelanggan lain, atau mengungkapkan data rahasia dalam output atau log? Di sinilah isolasi tenant, kontrol akses pada retrieval, dan praktik pencatatan log diperiksa.
Rantai pasok. Produk Anda kemungkinan bergantung pada model pihak ketiga, komponen open-source, dataset, dan mungkin plugin. Peninjau ingin tahu yang mana saja, siapa yang memperbaruinya, dan apa yang terjadi ketika penyedia mengubah ketentuan atau mengalami insiden.
Penanganan output yang tidak tepat. Output model adalah input tak tepercaya bagi bagian lain dari sistem Anda. Jika output itu diteruskan ke database, browser, atau shell tanpa validasi, output tersebut menjadi jalur injeksi. Model yang menulis perintah yang kemudian dijalankan seseorang adalah contoh klasiknya.
Agensi berlebihan. OWASP mendefinisikannya sebagai kerentanan yang memungkinkan tindakan merugikan terjadi sebagai respons terhadap output model yang tidak terduga, ambigu, atau dimanipulasi. OWASP mencantumkan tiga penyebab: fungsionalitas berlebihan, izin berlebihan, dan otonomi berlebihan. Untuk produk agent, ini sering menjadi pertanyaan utama, karena produk tersebut bertindak, bukan sekadar menjawab. Untuk sudut pandang khusus agent, lihat keamanan AI agent.
Kerangka Kerja yang Dikutip Peninjau
Empat nama muncul dalam kuesioner dan dokumen kebijakan. Mengetahui apa masing-masing itu, dan apa yang bukan, mencegah Anda membuat klaim berlebihan.
| Kerangka kerja | Apa itu | Cara peninjau menggunakannya | Dapat disertifikasi? |
|---|---|---|---|
| OWASP Top 10 for LLM Applications | Daftar risiko teratas untuk aplikasi LLM dan AI generatif | Daftar periksa skenario serangan untuk diuji dan ditanyakan | Tidak |
| NIST AI RMF dan Generative AI Profile-nya | Kerangka kerja sukarela untuk mengelola risiko AI, ditambah profil pendamping untuk AI generatif | Kosakata tata kelola dan cara menyusun jawaban terkait risiko | Tidak |
| ISO/IEC 42001 | Standar untuk sistem manajemen AI | Sinyal bahwa tata kelola AI dijalankan sebagai proses yang terkelola | Ya, melalui audit |
| MITRE ATLAS | Basis pengetahuan tentang taktik dan teknik penyerang terhadap sistem AI | Pemodelan ancaman dan perencanaan red team | Tidak |
NIST AI RMF. NIST menyatakan bahwa AI RMF 1.0, yang dirilis pada 26 Januari 2023, ditujukan untuk penggunaan sukarela guna meningkatkan cara organisasi membangun keterpercayaan ke dalam desain, pengembangan, penggunaan, dan evaluasi AI. NIST merilis Generative AI Profile (NIST-AI-600-1) pada 26 Juli 2024. Menurut profil itu sendiri, sebuah profil adalah implementasi fungsi-fungsi kerangka kerja untuk konteks tertentu, dan profil ini mendefinisikan risiko yang baru muncul atau diperburuk oleh AI generatif, lalu menyarankan tindakan untuk mengatur, memetakan, mengukur, dan mengelolanya. Tidak ada istilah "bersertifikasi NIST." Katakan "selaras dengan" hanya jika Anda benar-benar telah memetakan praktik Anda.
ISO/IEC 42001. Standar ini menetapkan persyaratan untuk membangun, menerapkan, memelihara, dan terus meningkatkan sistem manajemen AI, serta berlaku untuk organisasi mana pun yang mengembangkan, menyediakan, atau menggunakan produk atau layanan berbasis AI. Standar ini diterbitkan pada 18 Desember 2023. Karena merupakan standar sistem manajemen, sertifikasi berarti seorang auditor telah menilai proses Anda. Sertifikasi ini bukan jaminan bahwa output model tertentu aman, dan saat ini belum diwajibkan untuk sebagian besar tinjauan. Bagi startup, standar ini menjadi pembeda ketika Anda menjual kepada pembeli yang memintanya.
MITRE ATLAS. Dimodelkan berdasarkan matriks ATT&CK milik MITRE, ATLAS mengorganisasikan cara penyerang menyerang sistem berbasis AI. Tim keamanan menggunakannya untuk membangun model ancaman dan skenario red team. Startup jarang diminta untuk "patuh ATLAS," tetapi mengutipnya dalam model ancaman Anda menunjukkan bahwa pekerjaannya telah dilakukan.
Tahap-Tahap Tinjauan
Proses setiap pembeli berbeda, tetapi sebagian besar mengikuti alur yang sama.
- Penerimaan. Tim pengadaan atau keamanan pembeli membuka permintaan vendor, mengklasifikasikan data yang terlibat, dan memutuskan seberapa dalam tinjauannya. Produk yang menyentuh data pribadi pelanggan atau terhubung ke sistem inti mendapat tinjauan lebih dalam dibanding produk yang mengolah konten publik.
- Pertukaran dokumen. Anda mengirimkan apa yang Anda miliki: ringkasan keamanan, laporan SOC 2 atau ISO, kuesioner yang telah diisi, ketentuan pemrosesan data, daftar sub-pemroses, diagram arsitektur.
- Kuesioner dan klarifikasi. Peninjau memeriksa jawaban dan mengirimkan pertanyaan lanjutan. Pertanyaan khusus AI biasanya muncul di sini: pelatihan dengan data pelanggan, penyedia model, guardrail, pencatatan log.
- Pendalaman teknis. Untuk penerapan berisiko lebih tinggi, ada panggilan dengan engineer keamanan pembeli. Mereka mungkin meminta untuk melihat arsitektur, isolasi tenant, cara prompt dan alat ditangani, serta hasil pengujian.
- Pengujian, jika diwajibkan. Sebagian pembeli menjalankan atau meminta uji penetrasi, atau meminta bukti pengujian adversarial pada lapisan model.
- Keputusan risiko dan remediasi. Peninjau menyetujui, menyetujui dengan syarat, atau menolak. Syarat sering kali menjadi komitmen kontrak atau rencana remediasi dengan tenggat waktu.
- Kontrak dan tinjauan ulang. Temuan dimasukkan ke dalam perjanjian. Banyak pembeli meninjau ulang secara berkala atau ketika terjadi perubahan material, seperti penyedia model baru atau fitur otonom baru.
Biaya waktunya nyata, dan itulah sebabnya paket bukti menjadi penting. Bagaimana hasilnya terhubung dengan ketentuan deal dibahas dalam dari uji coba AI ke kontrak.
Bukti yang Perlu Disiapkan Startup AI
Peninjau bergerak lebih cepat ketika jawaban sudah tertulis. Pendekatan praktisnya adalah paket kepercayaan tetap yang selalu diperbarui dan dapat Anda kirimkan saat diminta.

| Bukti | Yang dijawab | Catatan |
|---|---|---|
| Laporan SOC 2 atau sertifikat ISO 27001 | Apakah kontrol keamanan dasar telah diverifikasi secara independen? | Jika belum selesai, roadmap bertanggal |
| Kuesioner standar yang telah diisi (CAIQ atau SIG) | Pertanyaan dasar yang umum | Gunakan ulang untuk berbagai pembeli |
| Diagram arsitektur dan alur data | Ke mana data mengalir, termasuk ke penyedia model | Tandai setiap pihak ketiga yang melihat data pelanggan |
| Pernyataan penanganan data | Penggunaan untuk pelatihan, retensi, penghapusan, residensi | Nyatakan dengan jelas apakah data pelanggan melatih model apa pun |
| Daftar sub-pemroses dan penyedia model | Eksposur rantai pasok | Sertakan proses pemberitahuan perubahan |
| Model ancaman yang merujuk risiko LLM OWASP | Bagaimana lapisan AI dianalisis | Petakan setiap risiko ke sebuah kontrol |
| Hasil pengujian adversarial dan evaluasi | Apakah model berperilaku baik di bawah tekanan | Sertakan metode dan kegagalan, bukan hanya yang lolos |
| Desain izin dan persetujuan agent | Apa yang dapat dilakukan produk tanpa seseorang | Least privilege, kredensial dengan cakupan terbatas, langkah persetujuan |
| Proses respons insiden dan pengungkapan | Apa yang terjadi ketika ada masalah | Sertakan waktu pemberitahuan |
| Kebijakan tata kelola AI | Bagaimana risiko AI dimiliki di dalam perusahaan | Selaras dengan NIST AI RMF atau ISO 42001 jika sudah dipetakan |
Tulis jawaban agar tahan terhadap pemeriksaan cermat. Klaim seperti "kami terlindungi dari prompt injection" mengundang pertanyaan lanjutan yang tidak dapat Anda penuhi, karena tidak ada vendor yang dapat menjanjikannya. Klaim seperti "konten tak tepercaya diperlakukan sebagai data, pemanggilan alat dibatasi pada cakupan ini, dan tindakan berdampak tinggi memerlukan persetujuan" memberi peninjau sesuatu yang spesifik untuk diperiksa. Disiplin yang sama dalam mendukung setiap klaim dengan bukti juga terdapat dalam menjual AI kepada pembeli yang skeptis.
Kesalahan Umum
- Mengklaim kepatuhan secara berlebihan. Menyebut "patuh NIST" atau "bersertifikasi ISO 42001" padahal keduanya tidak benar adalah cara tercepat kehilangan kredibilitas dan menimbulkan eksposur hukum.
- Tidak mengenal rantai pasok sendiri. Jika Anda tidak dapat menyebutkan penyedia model mana yang melihat data pelanggan, tinjauan akan macet.
- Mengabaikan izin agent. Memberi agent kredensial yang luas karena praktis adalah persis apa yang digambarkan oleh agensi berlebihan.
- Menyembunyikan batasan. Peninjau jauh lebih menghargai "ini adalah batasan yang diketahui dan inilah kontrolnya" daripada sikap diam. Untuk sudut pandang kepatuhan pada agent, lihat kepatuhan AI agent.
Fakta Utama
- Dasar ditambah lapisan AI: tinjauan keamanan AI menjalankan pemeriksaan vendor standar (kuesioner, SOC 2 atau ISO 27001, ketentuan data), lalu menambahkan risiko khusus model.
- Daftar OWASP: OWASP Top 10 for LLM Applications edisi 2025 menyebutkan sepuluh risiko, dari Prompt Injection hingga Konsumsi Tanpa Batas.
- Agensi berlebihan memiliki tiga penyebab: OWASP mencantumkan fungsionalitas berlebihan, izin berlebihan, dan otonomi berlebihan.
- NIST AI RMF bersifat sukarela: NIST merilis AI RMF 1.0 pada 26 Januari 2023 dan Generative AI Profile pada 26 Juli 2024. Keduanya bukan sertifikasi.
- ISO/IEC 42001 dapat disertifikasi: diterbitkan pada 18 Desember 2023, standar ini menetapkan persyaratan untuk sistem manajemen AI.
- SOC 2 mencakup lima area: menurut AICPA, yaitu keamanan, ketersediaan, integritas pemrosesan, kerahasiaan, dan privasi.
- Kuesioner yang dapat digunakan ulang tersedia: CSA mendistribusikan CAIQ bersama Cloud Controls Matrix-nya, termasuk versi STAR Level 1.
Bacaan Terkait
- Pertanyaan privasi data yang diajukan pembeli AI
- Kepercayaan dan evaluasi sebagai aset penjualan
- Apa itu kebijakan AI yang bertanggung jawab?
- Menjual AI kepada pembeli yang skeptis
- Komite pembelian AI
- Dari uji coba AI ke kontrak
- Mengapa demo lebih penting untuk produk AI
- Keamanan AI agent
- Kepatuhan AI agent

Co-Founder & COO