WRNOTE: Risiko AI yang Berbeda Perlu Kendali yang Berbeda

Jawaban salah, data bocor, dan perubahan pola kerja tidak selesai dengan satu tombol guardrail.

Sebut kegagalannya sebelum memilih obat

Sebuah asisten layanan fiktif memberikan jadwal kunjungan yang keliru. Sebagian jadwal sumber memang sudah tidak berlaku. Pada kasus lain, sumbernya benar tetapi jawaban model menambahkan waktu yang tidak ada. Di tempat lain lagi, petugas yang tidak berhak justru dapat melihat data pelanggan.

Ketiganya dapat disebut masalah AI, tetapi penyebab dan kendalinya berbeda. Meminta tim menambah guardrail tanpa menjelaskan kegagalan dapat membuat biaya bertambah sementara akar masalah tetap ada. Mulai dari kejadian yang mungkin terjadi, siapa terdampak, dan bagaimana hal itu dapat terjadi.

Diagram orisinal. Skenario fiktif untuk pembelajaran.

Bedakan data buruk, hallucination, dan drift

Data quality problem terjadi ketika sumber tidak layak untuk tugasnya, misalnya jadwal usang atau identitas pelanggan tertukar. Perbaikannya dapat memerlukan pemilik data, aturan pembaruan, validasi, dan penandaan sumber. Mengganti model saja tidak memperbarui jadwal.

Hallucination adalah keluaran yang tampak masuk akal tetapi salah atau tidak didukung sumber. Pengambilan sumber yang relevan, pengujian jawaban, pemeriksaan fakta, dan pilihan untuk tidak menjawab dapat membantu mengurangi risikonya. RAG tidak menjamin jawaban benar, terutama bila sumber salah atau model salah menggunakan sumber.

Drift berkaitan dengan perubahan yang membuat perilaku atau kinerja sistem tidak lagi sesuai kondisi yang dinilai. Pola permintaan, data, atau hubungan antara input dan hasil dapat berubah. Karena itu, bandingkan mutu dari waktu ke waktu dan periksa penyebabnya. Tidak semua penurunan kinerja berarti model harus dilatih ulang; masalah bisa berada pada data, integrasi, atau proses kerja.

Bias dapat masuk sebelum model digunakan

Bias tidak hanya muncul pada jawaban akhir. Cara memilih data, memberi label, mendefinisikan keberhasilan, merancang layanan, dan menggunakan hasil dapat menimbulkan perbedaan dampak. Dalam contoh layanan, menguji hanya pesan formal dapat membuat tim tidak melihat kesulitan pelanggan dengan bentuk bahasa lain.

Periksa contoh penggunaan yang cukup mewakili, hasil pada kelompok yang relevan, serta akibat salah arah atau penolakan. Libatkan orang yang memahami konteks dan pihak terdampak. Satu angka akurasi gabungan dapat menyembunyikan perbedaan pengalaman.

Kontrol perlu sesuai sumber masalah. Menambah data belum tentu membantu jika label atau definisi targetnya keliru. Pemeriksaan manusia juga tidak otomatis menghilangkan bias; orang yang memeriksa perlu panduan, informasi, dan cara meninjau keputusan yang dipersoalkan.

Konten, hak penggunaan, dan akses memerlukan batas berbeda

Keluaran berbahaya memerlukan pengujian serta pembatasan sesuai konteks penggunaan. Risiko hak kekayaan intelektual memerlukan pemeriksaan hak memakai sumber, ketentuan lisensi atau kontrak, dan cara keluaran akan digunakan. Teks yang dihasilkan AI tidak otomatis bebas dipublikasikan tanpa penilaian.

Kebocoran informasi memerlukan kontrol akses pada sumber dan aplikasi, pembatasan data yang diproses, serta pemeriksaan jalur keluaran. Dokumen yang masuk sistem tidak boleh menjadi tersedia untuk semua pengguna hanya karena model dapat membacanya.

Prompt injection adalah upaya membuat sistem mengikuti instruksi dari masukan yang tidak semestinya mengendalikan tindakan. Pertahanan perlu berlapis: pisahkan isi sumber dari otoritas tindakan, batasi hak alat, periksa keluaran sebelum dipakai oleh sistem lain, dan minta persetujuan yang sesuai untuk tindakan penting. Satu pesan instruksi di prompt tidak dapat menjadi satu-satunya perlindungan. Daftar OWASP membantu mengenali risiko aplikasi LLM, bukan sertifikat bahwa aplikasi sudah aman.

Risk register perlu menjelaskan hubungan sebab dan kontrol

Untuk setiap risiko, catat kejadian, penyebab yang masuk akal, pihak terdampak, kemungkinan, dan besar dampak. Tambahkan kontrol pencegahan, cara mendeteksi, penanggung jawab, serta respons bila kontrol gagal. Pisahkan risiko sebelum kontrol dari risiko yang masih tersisa sesudahnya.

Contoh fiktifnya: jadwal usang dapat membuat pelanggan datang pada waktu salah. Pemilik data bertugas memperbarui sumber; pengujian memeriksa kesesuaian tanggal; petugas menahan konfirmasi bila sumber tidak cukup jelas. Jika kesalahan terlanjur terkirim, perlu koreksi layanan dan penanganan pelanggan, bukan hanya revisi prompt.

Prioritas mempertimbangkan dampak dan kemungkinan, dengan bukti serta ketidakpastian yang dicatat. Kejadian jarang dengan dampak besar tidak boleh hilang hanya karena mudah dikalahkan oleh rata-rata. Jangan membuat skor risiko tampak lebih presisi daripada data yang mendasarinya.

Monitoring harus berakhir pada tindakan

Pantau kesehatan aplikasi, mutu AI, dan hasil bisnis. Respons yang cepat tidak membuktikan jadwalnya benar. Jawaban yang akurat pada sampel kecil juga tidak membuktikan akses data seluruh sistem sudah tepat. Pilih ukuran sesuai risiko yang sedang dikendalikan.

Hubungkan sinyal dengan ambang dan tindakan yang disetujui: siapa memeriksa, kapan proses dialihkan ke manusia, kapan fitur ditahan, serta bagaimana pulih. Periksa kembali setelah perubahan model, prompt, sumber, hak akses, atau konteks penggunaan. Umpan balik pengguna dapat menemukan masalah yang tidak muncul pada tes awal.

Simpan bukti yang diperlukan dengan perlindungan data, akses terbatas, dan masa simpan yang sesuai. Lalu uji apakah kontrol bekerja pada kegagalan yang dituju. Tujuannya bukan memiliki daftar risiko paling panjang, melainkan mengetahui risiko penting, mengurangi paparan, dan mampu bertindak ketika sistem tidak bekerja sebagaimana mestinya.