Model kecerdasan buatan generatif dapat membantu menjawab pertanyaan, merangkum dokumen, menulis kode, dan menjalankan alur kerja otomatis. Namun, pengujian fungsional biasa tidak cukup untuk menilai semua risikonya. Sistem AI dapat memberikan jawaban salah dengan nada meyakinkan, mengikuti instruksi yang tidak semestinya, membocorkan informasi dari konteks, atau berperilaku berbeda ketika dipakai melalui antarmuka dan integrasi nyata. Untuk memperluas evaluasi risiko, bandingkan dengan panduan keamanan dan kontrol akses AI Gateway dan kerangka manajemen risiko AI dari NIST.
AI red teaming adalah penilaian terencana yang menguji bagaimana sistem AI menghadapi input, konteks, pengguna, integrasi, dan kondisi operasional yang berisiko. Tujuannya bukan sekadar membuat model gagal, melainkan menemukan kelemahan yang bisa dibuktikan, menilai dampaknya, dan mengubah temuan itu menjadi perbaikan serta pengujian ulang. Aktivitas harus dilakukan dengan otorisasi yang jelas, ruang lingkup terukur, dan data uji yang aman.
Apa yang Diuji dalam AI Red Teaming?
Pengujian AI sebaiknya mencakup keseluruhan produk, bukan model saja. Risiko dapat muncul dari instruksi sistem, data yang diberikan pengguna, retrieval-augmented generation (RAG), tool yang dapat dipanggil model, kontrol akses aplikasi, penyimpanan log, atau cara output dipakai untuk mengambil keputusan.
- Perilaku model: konsistensi, ketepatan, penolakan terhadap permintaan di luar kebijakan, dan kecenderungan menghasilkan klaim yang tidak didukung.
- Lapisan aplikasi: validasi input, pemisahan instruksi dan data, sanitasi output, autentikasi, serta pemeriksaan izin sebelum tool dijalankan.
- Data dan retrieval: apakah dokumen yang tidak berhak dilihat pengguna dapat masuk ke konteks, apakah sumber dikutip dengan benar, dan apakah data sensitif muncul dalam respons.
- Integrasi dan tool: apakah model dapat meminta tindakan yang tidak diizinkan, melewati pembatasan bisnis, atau melakukan operasi tanpa konfirmasi yang diperlukan.
- Operasi dan pemantauan: batas biaya, rate limit, logging, penanganan insiden, versi model, serta kemampuan menghentikan alur yang bermasalah.
Pembagian ini membantu tim menghindari kesalahan umum: menyalahkan model atas kelemahan yang sebenarnya berasal dari aplikasi, atau menganggap model aman karena lolos dari sekumpulan prompt uji yang sempit.
AI Red Teaming Berbeda dari Pengujian Fungsional
Pengujian fungsional memeriksa apakah fitur bekerja pada skenario yang direncanakan. Red teaming menanyakan bagaimana fitur gagal ketika input tidak terduga, konteks bertentangan, pengguna berusaha melewati pembatasan, atau dependensi tidak tersedia. Pengujian adversarial perlu melengkapi test case biasa, bukan menggantikannya.
Hasil model dapat bersifat probabilistik dan berubah akibat versi model, system prompt, konfigurasi sampling, dokumen retrieval, maupun perubahan aplikasi. Karena itu, satu hasil buruk tidak selalu membuktikan kelemahan yang dapat direproduksi, sedangkan satu hasil baik tidak membuktikan sistem selalu aman. Simpan konfigurasi, versi, input uji, output, bukti, dan kondisi pengulangan agar temuan dapat diverifikasi.
Tetapkan Tujuan, Batas, dan Aturan Pengujian
Sebelum mulai, buat aturan tertulis yang menyebutkan sistem yang boleh diuji, akun dan lingkungan yang digunakan, jenis data yang boleh diproses, teknik yang diizinkan, batas beban, periode pengujian, dan kontak untuk menghentikan aktivitas. Hindari menggunakan data pelanggan sungguhan apabila data sintetis dapat menjawab pertanyaan yang sama.
Tetapkan pula apa yang berada di luar ruang lingkup, seperti mengakses sistem pihak ketiga, mengirim pesan eksternal, mengubah data produksi, atau menjalankan tindakan berbiaya. Jika aplikasi dapat memanggil alat—misalnya mengirim email, mengubah tiket, atau mengakses database—mulailah dengan tool tiruan atau lingkungan staging. Tindakan yang dapat berdampak pada orang atau sistem nyata memerlukan izin dan pengamanan tambahan.
Rancang Skenario Berdasarkan Risiko
1. Prompt injection dan konflik instruksi
Uji apakah sistem dapat membedakan instruksi berotoritas dari teks tidak tepercaya yang berasal dari dokumen, halaman web, email, atau masukan pengguna. Dalam aplikasi RAG, konten yang diambil dari sumber eksternal harus diperlakukan sebagai data, bukan otomatis sebagai instruksi. Periksa apakah aplikasi tetap menegakkan aturan akses dan kebijakan meskipun teks dalam dokumen mencoba mengubah perilaku model.
2. Kebocoran data dan batas antar-pengguna
Gunakan akun dan data sintetis yang sengaja diberi label berbeda untuk memverifikasi isolasi. Pastikan pencarian, ringkasan, cache, riwayat percakapan, dan tool tidak mencampur data dari pengguna atau tenant lain. Periksa juga log serta pesan kesalahan, sebab informasi sensitif dapat bocor melalui saluran selain jawaban utama.
3. Output tidak akurat atau tidak berdasar
Siapkan pertanyaan yang memiliki jawaban terverifikasi, pertanyaan yang jawabannya tidak ada dalam sumber, dan pertanyaan dengan informasi yang saling bertentangan. Ukur apakah sistem mengutip sumber yang relevan, membedakan fakta dari inferensi, dan menyatakan ketidakpastian saat bukti tidak cukup. Untuk tugas berisiko tinggi, tambahkan verifikasi manusia atau pemeriksaan terprogram.
4. Penyalahgunaan tool dan tindakan eksternal
Periksa setiap tool berdasarkan hak minimum. Model tidak seharusnya menjadi satu-satunya pengambil keputusan untuk otorisasi. Validasi izin di server untuk setiap panggilan, batasi parameter, gunakan allowlist, dan minta konfirmasi untuk tindakan yang sensitif atau tidak dapat dibatalkan. Uji juga apakah sistem menolak parameter yang tidak valid serta mengatasi timeout dan respons tool yang salah bentuk.
5. Penolakan yang terlalu luas atau terlalu sempit
Pastikan kontrol keselamatan menolak permintaan yang memang tidak diizinkan tanpa memblokir kebutuhan sah yang seharusnya dapat dibantu. Nilai kedua sisi: risiko jawaban berbahaya dan kegagalan layanan yang tidak perlu. Catat alasan keputusan secara konsisten agar perubahan kebijakan tidak hanya diukur dengan jumlah penolakan.
6. Ketahanan operasional dan biaya
Dengan batas yang disetujui, uji input terlalu panjang, permintaan berulang, dependensi yang gagal, dan respons tool yang lambat. Pastikan rate limit, batas token, timeout, circuit breaker, dan penanganan error berjalan sesuai rancangan. Jangan menjalankan stress test ke layanan produksi tanpa persetujuan eksplisit dan batas beban.
Alur Kerja Red Teaming yang Dapat Diulang
- Inventarisasi sistem. Dokumentasikan model, prompt, sumber data, tool, alur autentikasi, dan keputusan yang dipengaruhi output AI.
- Modelkan ancaman. Identifikasi aset, aktor, batas kepercayaan, konsekuensi, dan cara kegagalan mungkin terjadi.
- Prioritaskan skenario. Dahulukan risiko dengan dampak tinggi dan kemungkinan yang masuk akal, bukan sekadar skenario yang terlihat dramatis.
- Susun test case. Gunakan input yang dapat diulang, kondisi keberhasilan/kegagalan yang jelas, dan data sintetis bila mungkin.
- Jalankan pengujian secara terkendali. Rekam konfigurasi, hasil, bukti, waktu, dan penyimpangan dari rencana.
- Validasi temuan. Ulangi skenario, pastikan dampak nyata, pisahkan penyebab model dari penyebab aplikasi, dan hapus data sensitif dari bukti yang dibagikan.
- Perbaiki dan uji ulang. Terapkan kontrol, buat regression test, lalu pastikan perbaikan tidak menghasilkan kegagalan baru.
- Laporkan residual risk. Catat risiko yang belum terselesaikan, pemiliknya, mitigasi sementara, dan keputusan penerimaan risiko.
Cara Menilai Tingkat Keparahan
Gunakan skala yang konsisten. Pertimbangkan dampak pada kerahasiaan, integritas, ketersediaan, keselamatan pengguna, kepatuhan, dan biaya. Nilai juga prasyarat serangan, keterulangan, jangkauan pengguna, apakah kontrol lain dapat menghentikannya, dan apakah tindakan nyata berhasil dilakukan.
Contohnya, respons yang salah tetapi tidak berdampak pada keputusan mungkin berbeda tingkatnya dari kebocoran dokumen pribadi melalui RAG atau tool yang melakukan tindakan tanpa izin. Jangan menetapkan severity hanya karena output model tampak mengejutkan; kaitkan temuan dengan dampak yang terukur dan bukti yang dapat diverifikasi.
Metrik dan Bukti yang Perlu Dicatat
- Persentase skenario yang gagal dan yang berhasil ditangani dengan benar.
- Jumlah temuan yang direproduksi, tingkat keparahan, dan waktu hingga mitigasi.
- Tingkat kebocoran data atau pelanggaran izin pada skenario uji yang dirancang.
- Kualitas jawaban: relevansi, akurasi, dukungan sumber, dan ketepatan menyatakan ketidakpastian.
- Jumlah tindakan tool yang diblokir atau dijalankan sesuai izin.
- Biaya, latensi, timeout, serta kestabilan setelah pembatasan diterapkan.
Metrik harus dibaca bersama konteksnya. Tingkat keberhasilan serangan dari satu set prompt bukan ukuran keamanan universal. Test set perlu diperbarui ketika model, prompt, data, integrasi, atau kebijakan berubah. Hindari mengoptimalkan sistem hanya untuk lulus benchmark tetap yang sudah dikenal tim pengembang.
Mitigasi: Jangan Bergantung pada Prompt Saja
Instruksi sistem dapat membantu mengarahkan perilaku, tetapi tidak menggantikan kontrol keamanan di aplikasi. Terapkan pemeriksaan otorisasi pada server, minimalkan data yang dikirim ke model, pisahkan konteks tiap pengguna, validasi keluaran sebelum digunakan, batasi kemampuan tool, dan minta persetujuan manusia untuk tindakan sensitif. Untuk data retrieval, gunakan izin dokumen dan filter tenant sebelum konten masuk ke prompt.
Tambahkan logging yang bermanfaat bagi audit tanpa merekam informasi lebih banyak dari yang diperlukan. Terapkan retensi terbatas, kontrol akses, redaksi rahasia, dan prosedur respons insiden. Ketika ditemukan masalah serius, siapkan mekanisme untuk menonaktifkan tool tertentu atau mengalihkan sistem ke mode aman sementara penyebab diperbaiki.
Kesimpulan
AI red teaming membantu tim memahami bagaimana sistem AI dapat gagal dalam penggunaan nyata, mulai dari perilaku model hingga data, tool, dan operasi. Proses yang baik menggunakan ruang lingkup resmi, skenario berbasis risiko, bukti yang dapat direproduksi, penilaian dampak, dan regression test setelah mitigasi. Hasilnya bukan sertifikat bahwa AI sepenuhnya aman, melainkan informasi yang lebih baik untuk mengurangi risiko dan mengelola risiko yang tersisa.
Bacaan lanjutan: OWASP GenAI Red Teaming Guide dan OWASP AI Testing Guide. Gunakan panduan tersebut bersama konteks, kebijakan, dan kebutuhan risiko organisasi.