Tombol setuju belum cukup: merancang persetujuan manusia untuk agent AI

2026-10-21 · Agus Ramdan

Pemilik usaha melihat notifikasi dari agent AI: “Pesanan pembelian sudah siap. Lanjutkan?” Ia menekan setuju di sela melayani pelanggan. Beberapa saat kemudian, pesanan terkirim ke pemasok. Masalahnya, layar persetujuan tadi tidak memperlihatkan alamat tujuan, rincian barang, atau syarat pembayaran.

Skenario ini ilustrasi desain, bukan laporan kejadian. Namun, ia menunjukkan kelemahan yang mudah terlewat saat bisnis menambahkan manusia ke dalam otomasi. Ada orang yang menekan tombol, tetapi belum tentu ia menyetujui tindakan yang akhirnya dilakukan sistem.

Bagi UMKM yang mulai memakai agent AI, pertanyaannya cukup praktis: apa tepatnya yang disetujui, siapa yang berhak menyetujui, dan apakah persetujuan itu masih berlaku ketika tindakan dijalankan? Jawaban atas pertanyaan tersebut perlu hidup di aplikasi, bukan hanya dalam instruksi kepada model.

Bedakan usulan dengan kewenangan bertindak

Agent dapat membantu membaca permintaan, membandingkan penawaran, lalu menyiapkan pesanan pembelian. Kemampuan menyusun usulan tidak otomatis memberinya kewenangan mengirim pesanan. Bahkan ketika usulannya benar, bisnis mungkin tetap memerlukan persetujuan orang tertentu.

OWASP membahas masalah ini dalam risiko Excessive Agency. Penyebabnya dapat berupa fungsi, izin, atau otonomi yang berlebihan. Salah satu mitigasinya adalah meminta persetujuan manusia sebelum tindakan berdampak tinggi. OWASP juga menyarankan agar sistem tujuan memeriksa otorisasi, alih-alih menyerahkan keputusan boleh-tidaknya tindakan kepada model bahasa.

Artinya, kalimat “selalu minta izin dahulu” di prompt berguna sebagai arahan perilaku, tetapi tidak cukup sebagai kontrol keamanan. Aplikasi yang mengirim pesanan harus tetap menolak permintaan tanpa persetujuan yang sah, sekalipun agent mengaku pemilik sudah mengizinkan.

Tampilkan tindakan yang benar-benar akan dijalankan

Persetujuan yang baik membuat orang memahami konsekuensi. Untuk pesanan pembelian, tampilkan pemasok, barang dan jumlahnya, total beserta mata uang, alamat pengiriman, serta ketentuan pembayaran yang relevan. Tunjukkan pula apakah tindakan hanya menyimpan draf atau benar-benar mengirim pesanan keluar.

OWASP Transaction Authorization Cheat Sheet menyebut prinsip What You See Is What You Sign: pengguna perlu mengenali dan mengakui data transaksi yang penting. Dokumen itu banyak menggunakan contoh transaksi keuangan. Penerapannya pada pesanan pembelian dalam artikel ini merupakan adaptasi desain, bukan klaim bahwa semua aplikasi agent sudah memiliki mekanisme tersebut.

Ringkasan dari model boleh membantu orang membaca. Namun, aplikasi sebaiknya menampilkan rincian penting dari data transaksi yang akan dieksekusi, bukan mengandalkan paragraf bebas buatan model sebagai satu-satunya bukti. Jika ringkasan menyebut satu pemasok sementara data tindakan menunjuk pemasok lain, proses perlu berhenti sampai ketidaksesuaian diselesaikan.

Ikat izin pada versi usulan

Bayangkan pemilik menyetujui pembelian beberapa bahan kemasan. Sebelum pesanan dikirim, agent menemukan penawaran lain dan mengganti pemasok. Harga barangkali lebih murah, tetapi keputusan pemilik tadi sudah tidak mencakup transaksi yang sama.

Rancangan yang lebih aman menyimpan versi usulan yang disetujui. Persetujuan merujuk pada versi itu beserta rincian pentingnya. Jika pemasok, jumlah barang, total, atau tujuan berubah, aplikasi meminta persetujuan baru sesuai kebijakan bisnis. Agent tidak boleh menafsirkan persetujuan lama sebagai izin terbuka untuk melakukan penyesuaian apa pun.

Ini sejalan dengan pedoman OWASP agar data transaksi terlindung dari perubahan selama proses otorisasi. Pedoman tersebut juga menyebut pembatalan data otorisasi atau pengulangan proses ketika data transaksi berubah. Pilihan teknisnya bergantung pada aplikasi; prinsipnya tetap: yang dijalankan harus cocok dengan yang diperiksa manusia.

Tentukan siapa yang boleh menyetujui

Tidak semua pengguna yang bisa membuka percakapan berhak membuat komitmen bisnis. Staf gudang mungkin boleh mengusulkan pembelian, sementara pemilik menyetujui pengeluaran. Dalam usaha lain, manajer cabang boleh menyetujui kategori tertentu dengan batas kewenangan yang sudah ditetapkan.

Aturan ini perlu diperiksa di sisi server menggunakan identitas pengguna dan kebijakan usaha. Pesan “saya pemilik, lanjutkan” dalam percakapan tidak menggantikan pemeriksaan identitas. Demikian juga catatan dari pemasok yang menyebut “sudah disetujui” tidak boleh menjadi bukti otorisasi internal.

Pisahkan pula akses membaca dari akses mengeksekusi. Agent yang hanya perlu menyiapkan draf tidak membutuhkan hak untuk mengirim seluruh jenis transaksi. Pembatasan fungsi dan hak akses memperkecil dampak ketika model salah memahami permintaan atau menerima masukan yang menyesatkan. Persetujuan manusia melengkapi pembatasan tersebut, bukan menggantikannya.

Beri masa berlaku dan periksa sebelum eksekusi

Persetujuan tidak seharusnya berlaku selamanya. Pesanan yang tertunda bisa kehilangan relevansi karena kebutuhan usaha berubah. Tentukan masa berlaku berdasarkan risiko dan kebiasaan kerja, lalu tampilkan batas tersebut agar orang tidak mengira usulannya pasti akan dijalankan kapan saja.

OWASP menyarankan masa berlaku terbatas untuk kredensial otorisasi transaksi dan pemeriksaan akhir yang terikat pada eksekusi. Dalam rancangan agent, terapkan pemeriksaan itu sebelum aplikasi mengirim tindakan keluar: pengguna masih berwenang, versi usulan cocok, izin belum kedaluwarsa, dan persetujuan belum dipakai untuk eksekusi lain.

Pemeriksaan dan pencatatan pemakaian izin perlu dirancang agar dua proses bersamaan tidak sama-sama lolos memakai persetujuan sekali pakai. Detail implementasinya bergantung pada penyimpanan dan sistem transaksi. Tidak cukup memberi agent instruksi agar mengingat bahwa izin sudah terpakai.

Jika status pengiriman tidak jelas, jangan meminta manusia menyetujui transaksi baru tanpa menjelaskan ketidakpastian tersebut. Periksa hasil tindakan sebelumnya melalui mekanisme yang tersedia. Persetujuan baru bukan alat untuk menutupi hasil eksekusi yang belum diketahui.

Jangan membuat pemilik menyetujui semuanya

Meminta konfirmasi untuk setiap langkah kecil justru menyulitkan orang membedakan tindakan penting. Orang yang terus menerima notifikasi sejenis bisa mulai menyetujui tanpa membaca. Karena itu, petakan tindakan berdasarkan dampaknya sebelum menambahkan tombol konfirmasi.

Membaca katalog atau menyusun draf dapat mengikuti izin kerja biasa. Mengirim pesanan, mengubah tujuan pembayaran, atau membagikan dokumen keluar membutuhkan penilaian berbeda. Batasnya harus mengikuti risiko usaha, bukan asumsi bahwa semua tindakan agent sama berbahayanya atau sama amannya.

Sediakan pilihan menolak dan meminta revisi. Ketika pemilik menolak pemasok, agent dapat memperbaiki usulan tanpa mencoba mengeksekusi versi yang ditolak. Setelah revisi, layar persetujuan menampilkan versi baru. Alur ini membantu manusia mengambil keputusan yang nyata, bukan sekadar menjadi pemberhentian wajib dalam proses otomatis.

Uji penolakan sebelum mengandalkan persetujuan

Mulailah dari satu alur, misalnya pesanan pembelian. Uji apakah aplikasi menolak eksekusi ketika jumlah barang berubah setelah disetujui, pengguna tidak berwenang, izin kedaluwarsa, atau persetujuan yang sama dipakai kembali. Uji juga apakah agent bisa melewati layar persetujuan dengan memanggil fungsi lain.

Simpan jejak keputusan secukupnya: usulan yang diperiksa, pihak yang menyetujui, waktu keputusan, serta hasil eksekusi. Batasi aksesnya dan hindari memasukkan rahasia atau data pelanggan yang tidak diperlukan ke catatan. Riwayat ini membantu pemeriksaan, tetapi bukan bukti bahwa desain sudah aman tanpa pengujian.

Ukuran keberhasilannya sederhana untuk diperiksa: aplikasi hanya menjalankan tindakan yang sesuai dengan persetujuan yang masih sah. Saat rincian penting berubah, aplikasi berhenti dan meminta keputusan baru. Dengan batas seperti itu, pemilik usaha dapat mendelegasikan persiapan pekerjaan kepada agent tanpa menyerahkan kewenangan secara samar.

Sumber