Playbook

Menulis Paket Keamanan untuk Fitur Kecerdasan Buatan

Tinjauan keamanan tidak gagal karena sistemnya berisiko. Ia gagal karena tidak ada yang bisa menjelaskan risikonya. Lima artefak dapat mengubah tinjauan tiga bulan menjadi dua minggu.

Apa yang sebenarnya diputuskan oleh reviewer

Sebuah tinjauan keamanan bukanlah penilaian tentang apakah sebuah model akurat. Ini adalah penilaian tentang apakah organisasi dapat menerima risiko, dan untuk membuat penilaian tersebut, seorang reviewer memerlukan empat hal: data apa yang disentuh oleh sistem, ke mana data tersebut pergi, siapa yang dapat melihat apa yang dihasilkannya, dan apa yang terjadi ketika sistem salah. Jika salah satu jawaban tersebut adalah paragraf yang memberikan rasa aman daripada sebuah artefak, maka tinjauan tersebut diperpanjang.

Tidak ada dari hal ini yang spesifik untuk AI. Alasan fitur AI ditinjau secara perlahan adalah karena tim jarang menghasilkan artefak-artefak ini, karena sistem tersebut dibangun untuk menunjukkan nilai daripada untuk dijelaskan.

Lima artefak

Sebuah alur data satu halaman. Setiap sistem sumber, batas yang dilintasi, apa yang ditransmisikan, dan apakah data tersebut disimpan. Sebutkan penyedia model sebagai pengolah data dan nyatakan secara eksplisit apakah prompt dan output disimpan atau digunakan untuk pelatihan, dengan mengutip istilah kontraktual daripada halaman pemasaran. Satu halaman ini dapat menyelesaikan sebagian besar pertanyaan hukum dan privasi dalam satu pertemuan.

Sebuah register risiko. Apa yang dapat dilakukan sistem dengan salah, kerusakan, mitigasi, dan residu. Dua kolom tabel. Seorang reviewer yang melihat "halusinasi, mitigasi dengan kutipan plus jalur penolakan dengan kepercayaan rendah, residu: pengguna masih dapat bertindak berdasarkan klaim yang tidak dikutip" dapat membuat keputusan. Seorang reviewer yang melihat "model ini dapat diandalkan" tidak dapat.

Sebuah demonstrasi izin. Model kontrol akses, di mana penegakan terjadi relatif terhadap pengambilan, dan cara untuk menunjukkan bahwa itu berfungsi. Jika penyaringan terjadi setelah pengambilan, katakanlah dan jelaskan mengapa kebocoran peringkat dapat diterima — atau perbaikilah. Reviewer sering mengajukan pertanyaan ini karena ini adalah pertanyaan dengan jawaban yang jelas dan dapat diperiksa.

Sebuah pernyataan retensi dan penghapusan. Berapa lama prompt, output, dan konteks yang diambil disimpan, di mana, dan bagaimana permintaan penghapusan dipenuhi. Termasuk log dan dataset evaluasi — dataset evaluasi yang dibangun dari data nyata sering kali merupakan salinan terlama dari konten pengguna di dalam bangunan.

Sebuah jalur insiden. Siapa yang dihubungi, apa yang dapat dimatikan, dan seberapa cepat. Sebuah sakelar kemampuan yang mematikan fitur tanpa deploy adalah jawaban terkuat yang tersedia dalam tinjauan, karena itu mengubah paparan terburuk menjadi jendela yang terikat.

Dua kebiasaan yang mempersingkat tinjauan

Tulis ini sebelum kode, bukan sebelum tinjauan. Alur data dan register risiko adalah dokumen desain; jika ditulis setelah implementasi, maka itu adalah arkeologi, dan akan bertentangan dengan implementasi di tempat-tempat yang diperiksa oleh reviewer.

Jawab dengan artefak, bukan dengan kepercayaan. Jika jawaban jujur atas pertanyaan adalah bahwa sistem dapat menghasilkan klaim yang tidak dapat diverifikasi dan mitigasinya adalah persyaratan kutipan yang belum ditegakkan, katakanlah dan berikan tanggalnya. Reviewer menyetujui mitigasi dengan tanggal lebih mudah daripada menyetujui adjektiva.

Apa yang harus dilakukan ketika jawabannya adalah tidak

Jika tinjauan memblokir fitur, pertanyaan yang berguna adalah kontrol spesifik apa yang dapat mengubah jawaban. Itu mengubah hasilnya menjadi sebuah pekerjaan yang terfokus daripada penolakan, dan biasanya ternyata salah satu dari lima artefak yang hilang daripada objeksi fundamental. Tim yang mengajukan pertanyaan ini mendapatkan tinjauan kedua dengan cepat; tim yang banding mendapatkan tinjauan yang lebih lambat.

Yang bisa Anda lakukan sekarang

  • Tuliskan apa yang meninggalkan batas jaringan sebelum menulis kode
  • Daftar risiko dengan mitigasi yang diberi nama lebih baik daripada jaminan
  • Demonstrasikan penerapan izin atas permintaan, bukan dalam diagram