Persetujuan Manusia dalam Otomatisasi AI - Beri Jeda Sebelum Side Effect

Aplikasi AI yang menyusun email dan aplikasi yang mengirim email mungkin memakai model yang sama, tetapi keduanya tidak membawa jenis kewenangan yang sama. Yang pertama menghasilkan usulan. Yang kedua mengubah dunia di luar aplikasi. Di titik mana tepatnya seseorang perlu diminta menyetujui perubahan itu?

“Tetap libatkan manusia” terdengar seperti jawaban, tetapi bagian-bagian sulitnya masih belum jelas. Tindakan mana yang harus dijeda? Apa yang dilihat pemeriksa? Apa yang terjadi jika target atau jumlah berubah setelah persetujuan? Bisakah model menghindari prompt konfirmasi melalui tool lain? Dialog konfirmasi dapat berubah menjadi formalitas, bukan kontrol, jika aplikasi tidak dapat menjawab pertanyaan-pertanyaan tersebut.

Artikel ini menyusun pola desain praktis untuk otomatisasi AI skala kecil. Ini adalah sintesis dari panduan keamanan dan manajemen risiko, bukan standar universal: pisahkan usulan dari eksekusi, klasifikasikan tindakan berdasarkan konsekuensinya, ikat persetujuan pada satu usulan yang persis, lalu biarkan kode aplikasi biasa menegakkan batas tersebut.

Approval berada di luar model

Tool mengubah output model menjadi kemampuan. Tool dapat mengambil data, tetapi juga dapat mengirim pesan, mengubah record, menerbitkan halaman, melakukan pembelian, atau menghapus file. OWASP GenAI Security Project memisahkan tiga penyebab excessive agency: fungsi yang terlalu luas, permission yang terlalu besar, dan otonomi yang berlebihan. Approval manusia menangani sebagian masalah otonomi. Approval tidak menghapus dua masalah lainnya.

Pembedaan ini penting karena model bukanlah layanan authorization. Model dapat mengusulkan send_message, menjelaskan mengapa pemanggilan itu tampak tepat, atau bahkan mengklasifikasikannya sebagai risiko rendah. Aplikasi tetap harus memutuskan apakah pengguna yang terautentikasi boleh mengirim ke penerima tersebut, apakah operasi itu memerlukan approval, dan apakah parameter yang disetujui adalah parameter yang akhirnya dieksekusi.

Karena itu, OWASP menyarankan agar authorization ditegakkan di downstream system, bukan mengandalkan LLM untuk memutuskan apakah tindakan diizinkan. Panduan membangun agent dari OpenAI menyampaikan hal yang sejalan: guardrail perlu dilapisi dengan authentication, authorization, access control yang ketat, dan keamanan perangkat lunak standar. Approval adalah satu lapisan dalam susunan itu, bukan pengganti seluruh susunannya.

Jeda berdasarkan konsekuensi, bukan sekadar karena ada tool

Meminta konfirmasi untuk setiap pemanggilan belum tentu lebih aman. Jika pemeriksa harus menyetujui puluhan operasi baca yang tidak berbahaya, permintaan yang benar-benar penting dapat berubah menjadi satu tombol lagi dalam antrean panjang. Titik awal yang lebih berguna adalah mengklasifikasikan tindakan melalui beberapa pertanyaan:

• Apakah tindakan hanya membaca atau menimbulkan side effect? Mencari dokumen publik berbeda dengan menerbitkan dokumen.
• Apakah efeknya dapat dibalik? Menyimpan draft privat berbeda dengan mengirimkannya ke mailing list; memindahkan file ke trash yang dapat dipulihkan berbeda dengan menghapusnya secara permanen.
• Seberapa luas cakupannya? Mengedit satu record berbeda dengan mengubah semua record yang cocok.
• Kewenangan apa yang digunakan? Tool yang terbatas pada draft milik satu pengguna berbeda dengan credential administratif bersama.
• Apa yang dapat terekspos atau berpindah? Suatu pemanggilan dapat membocorkan data atau mengikat uang meskipun tidak terlihat destruktif.

Ini adalah taksonomi praktis, bukan daftar yang ditetapkan oleh satu standar. Generative AI Profile dari NIST menyatakan bahwa susunan oversight mungkin perlu berbeda menurut konteks dan risiko. Panduan OpenAI juga menyarankan penilaian tool berdasarkan faktor seperti akses baca atau tulis, reversibilitas, permission akun, dan dampak finansial. Untuk aplikasi kecil, faktor-faktor itu dapat menghasilkan kebijakan sederhana: izinkan operasi baca yang sempit, jalankan otomatis penulisan berisiko rendah yang dapat dibalik, dan berhenti sebelum efek yang eksternal, sensitif, luas, mahal, privileged, atau tidak dapat dibalik.

Beberapa tindakan sebaiknya sama sekali tidak tersedia, bukan hanya diletakkan di balik prompt. Jika otomatisasi hanya perlu merangkum email, jangan berikan kemampuan mengirim atau menghapus email pada tool-nya. Jika hanya perlu memperbarui satu jenis record, tool SQL atau shell tanpa batas jauh lebih luas daripada kebutuhan tugas. Menghilangkan kekuatan yang tidak diperlukan lebih kuat daripada berulang kali meminta seseorang menyetujui penggunaan kekuatan tersebut.

Buat usulan yang benar-benar bisa diperiksa

Pemeriksa tidak dapat memberi persetujuan yang bermakna terhadap kata “lanjutkan”. Antarmuka perlu menjelaskan side effect yang diusulkan dalam bentuk yang dapat diperiksa manusia. Bergantung pada operasinya, informasi itu dapat mencakup:

• tindakan serta akun atau identitas yang akan menjalankannya;
• target, seperti penerima, repository, path file, record, atau channel publikasi;
• parameter material, seperti isi pesan, patch, jumlah, permission, atau mode penghapusan;
• cakupan yang diperkirakan dan apakah hasilnya dapat dibalik;
• konteks sumber yang relevan dan konten tidak tepercaya yang memengaruhi usulan;
• batasnya: hal-hal yang tidak diizinkan oleh approval ini.

Spesifikasi tool Model Context Protocol memberi contoh konkret ke arah ini. Spesifikasi tersebut menyarankan indikator yang jelas ketika tool dipanggil, konfirmasi untuk operasi, dan penayangan input tool sebelum pemanggilan sensitif. Spesifikasi itu juga menyatakan bahwa protokol tidak mewajibkan satu model interaksi tertentu. Dengan kata lain, menyediakan mekanisme tool call tidak otomatis menghasilkan pengalaman pemeriksaan yang tepercaya.

Preview sebaiknya mengutamakan efek, bukan penalaran model. Untuk email, tampilkan penerima sebenarnya, subjek, isi, dan lampiran. Untuk perubahan kode, tampilkan repository, branch, dan diff. Untuk publikasi, tampilkan judul final, tujuan, visibility, dan konten. Paragraf yang terdengar yakin tentang alasan suatu tindakan masuk akal bukan pengganti byte dan tujuan yang akan berubah.

Ikat tombol “setujui” pada satu tindakan yang persis

Berikut inferensi engineering yang menjadi inti artikel ini: approval sebaiknya merujuk pada usulan yang immutable, atau setidaknya terlindungi integritasnya. Usulan mendapat identifier dan merekam data tindakan yang material. Pemeriksa menyetujui identifier tersebut. Executor kemudian memakai usulan yang sama, bukan menerima sekumpulan argumen baru yang kembali dihasilkan model.

Tanpa ikatan ini, antarmuka dapat menampilkan satu penerima sementara request eksekusi berisi penerima lain. Model dapat merevisi draft setelah pemeriksaan, proses background dapat mengubah record, atau race condition biasa dapat membuat preview kedaluwarsa. Masalah ini bukan sesuatu yang khas “AI”; ini adalah celah yang sudah dikenal antara memeriksa sesuatu dan menggunakannya.

State machine kecil membuat batas tersebut terlihat:

proposed -> pending_review -> approved -> executing -> completed
                           \-> rejected
                           \-> expired
                                          \-> failed

Perubahan material membuat usulan baru dan memerlukan approval baru. Approval yang masih pending memiliki masa berlaku. Usulan yang disetujui dikonsumsi satu kali, atau eksekusinya dibuat idempotent ketika retry diperlukan. Mekanismenya dapat berupa serialisasi canonical beserta cryptographic digest, row database berversi yang tidak dapat diedit setelah pemeriksaan, atau desain lain yang sesuai dengan threat model aplikasi. Sumber-sumber artikel ini tidak menetapkan satu format penyimpanan; invariant-nya yang penting: tindakan yang diperiksa dan tindakan yang dieksekusi tidak boleh diam-diam berbeda.

Periksa ulang kewenangan saat eksekusi

Approval menyatakan bahwa pemeriksa tertentu menerima usulan tertentu pada waktu tertentu. Approval tidak membuktikan bahwa tindakan tersebut masih diizinkan. Role dapat berubah, sebuah record mungkin sudah ditutup, spending limit mungkin telah tercapai, atau target mungkin sudah tidak ada.

Karena itu, executor perlu mengautentikasi actor, mengevaluasi ulang authorization terkini, memvalidasi semua input, dan memeriksa business invariant tepat sebelum side effect terjadi. Executor perlu memakai downstream credential sesempit mungkin dan menjalankan tindakan dalam konteks pengguna bila memungkinkan. Kontrol ini mengikuti panduan least permission dan complete mediation dalam pembahasan excessive agency OWASP. Spesifikasi MCP juga mewajibkan server memvalidasi input tool dan menerapkan access control.

Pemisahan ini juga menutup jalan pintas yang menarik tetapi tidak aman: membiarkan model memanggil tool luas setelah boolean approved=true muncul dalam konteks percakapannya. Approval service dan executor, bukan percakapan, harus memiliki kendali atas transisi tersebut. Prompt injection, respons model, atau hasil tool yang baru tidak dapat memberikan permission kepada dirinya sendiri.

Simpan bukti tanpa mengubah log menjadi kebocoran baru

Lifecycle perlu meninggalkan bukti yang cukup untuk merekonstruksi kejadian: siapa yang meminta operasi, usulan mana yang ditampilkan, siapa yang menyetujui atau menolak, kapan usulan kedaluwarsa atau dieksekusi, versi kebijakan mana yang berlaku, serta hasil atau error yang muncul. NIST menyarankan peran oversight yang jelas, pemantauan dan dokumentasi override, serta proses pascadeployment untuk appeal, incident response, recovery, dan change management. MCP juga menyarankan pencatatan penggunaan tool untuk audit.

Lebih banyak log tidak otomatis lebih baik. Token, password, isi pesan privat, dan data pribadi yang tidak diperlukan tidak semestinya masuk ke audit record hanya karena sistem mampu menyimpannya. Log yang berguna dapat menyimpan identifier, digest, klasifikasi, timestamp, dan ringkasan yang sudah disunting, sementara payload sensitif ditempatkan di bawah aturan akses dan retensi terpisah.

Jalur kegagalan layak mendapat perhatian desain yang sama dengan approval. Apa yang terjadi setelah timeout? Bisakah pengguna membedakan “belum terkirim” dari “respons hilang setelah terkirim”? Bisakah dua pemeriksa mengeksekusi usulan yang sama dua kali? Dapatkah tindakan multi-step yang selesai sebagian dipulihkan? Pemeriksaan manusia tidak menjawab pertanyaan transaksi ini.

Klik manusia tetap merupakan kontrol yang bisa keliru

Seseorang dapat menyetujui tindakan yang salah, melewatkan detail pada preview yang tidak jelas, atau terbiasa menerima prompt. Untuk high-risk system yang termasuk dalam cakupannya, Article 14 EU AI Act menggambarkan betapa luas arti “human oversight”: overseer perlu dapat memahami kemampuan dan keterbatasan, mengenali performa yang tidak terduga, tetap waspada terhadap automation bias, menginterpretasikan output, mengabaikan atau membalikkan output, dan menghentikan sistem. Kewajiban hukum tersebut tidak berlaku pada setiap aplikasi AI kecil, dan aturan verifikasi dua orang yang sempit dalam Act itu bukan aturan umum untuk tool call biasa. Pelajaran yang berguna lebih sederhana: approval hanya bermakna ketika pemeriksa memiliki konteks, kompetensi, kewenangan, dan cara nyata untuk menolak.

Approval manusia juga tidak menetralkan konten berbahaya. Dokumen yang sudah diracuni masih dapat membentuk usulan; akun pemeriksa yang diambil alih masih dapat menyetujuinya; executor yang terlalu kuat masih dapat menimbulkan kerusakan berlebihan. Sandboxing, penanganan input dan output, rate limit, monitoring, tool yang sempit, dan recovery plan tetap relevan. Panduan pengembangan AI yang aman dari NCSC Inggris menempatkan risiko khusus AI di dalam lifecycle penuh secure design, development, deployment, operation, dan maintenance, bukan menganggap perilaku model sebagai seluruh masalah keamanan.

Tiga contoh batas yang nyata

Email

Model dapat mencari pesan dan membuat draft privat dengan kemampuan baca dan draft saja. Proses berhenti sebelum pengiriman. Pemeriksaan menampilkan setiap penerima, subjek dan isi yang persis, lampiran, serta akun pengirim. Approval merujuk pada draft yang sudah dibekukan; perubahan penerima membuatnya tidak berlaku. Layanan email tetap memeriksa bahwa pengguna boleh mengirim dari akun tersebut.

Publikasi

Riset, penyusunan outline, dan penyimpanan revisi yang belum dipublikasikan dapat berjalan di workspace terbatas. Proses berhenti pada transisi menuju URL publik. Usulan memuat versi konten final, judul, tujuan, visibility, dan waktu terjadwal. Approval atas satu content digest tidak dapat menerbitkan penulisan ulang yang muncul belakangan. Kebijakan deployment terpisah tetap dapat menolak translation, thumbnail, atau quality gate yang belum ada.

File

Pembacaan dari project tree yang diizinkan dapat berjalan otomatis. Penghapusan menampilkan canonical path, jumlah, cakupan total, dan apakah pemulihan tersedia. Executor menolak path di luar root yang diizinkan dan memeriksanya kembali setelah link di-resolve. Untuk data yang sangat berharga, desain yang lebih baik mungkin tidak menyediakan tool permanent delete sama sekali: pindahkan data ke quarantine dan biarkan proses retensi terpisah menghapusnya nanti.

Contoh-contoh ini berbagi pola, bukan threshold universal. Jeda yang bernilai berada tepat sebelum batas yang menimbulkan konsekuensi, dan manusia memeriksa efek yang akan melewati batas itu.

Kapan tidak perlu membangun agent untuk tugas tersebut

Arsitektur approval dapat membuat otomatisasi lebih terkendali, tetapi juga dapat menjadi tanda bahwa otomatisasinya terlalu rumit. Artikel engineering tentang agent dari Anthropic menyarankan memulai dengan solusi paling sederhana dan membedakan workflow dengan jalur kode yang telah ditentukan dari sistem tempat model mengarahkan penggunaan tool secara dinamis. OpenAI juga menyebut bahwa solusi deterministic mungkin sudah cukup ketika tugas tidak memerlukan model untuk menangani ambiguitas.

Jika langkah dan kebijakannya sudah diketahui, kode aplikasi biasa dapat mengumpulkan input, memvalidasinya, menampilkan preview, dan mengeksekusinya setelah konfirmasi. Model dapat membantu menyusun konten tanpa mengendalikan transaksi. Jika suatu konsekuensi tidak dapat diterima, sulit diperiksa, atau mustahil dipulihkan, jawaban yang tepat mungkin membiarkan kemampuan itu tetap berada di luar otomatisasi.

Kesimpulan

Langkah approval yang berguna bukan pertanyaan dekoratif yang diajukan model. Ia adalah batas yang ditegakkan aplikasi dan menjawab empat hal dengan jelas: siapa yang boleh menyetujui, tindakan persis mana yang diperiksa, berapa lama approval tetap berlaku, dan kode apa yang boleh dieksekusi setelahnya.

Batas tersebut bekerja paling baik bersama tool yang lebih sempit, credential dengan least privilege, pemeriksaan authorization terkini, preview yang cermat, audit record, dan jalur recovery. Batas itu tetap bergantung pada manusia yang bisa keliru dan tidak dapat mengubah operasi yang tidak dapat diterima menjadi aman. Karena itu, pertanyaan desain yang jujur bukan sekadar “Apakah ada manusia di dalam loop?” Pertanyaannya adalah “Apa yang benar-benar dapat dilihat, ditolak, dihentikan, dan diikat oleh orang ini pada tindakan yang kemudian dijalankan?”

References

1. National Institute of Standards and Technology, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1, Juli 2024. Diakses 26 Oktober 2026.
2. OWASP GenAI Security Project, LLM06:2025 Excessive Agency, edisi 2025. Diakses 26 Oktober 2026.
3. Model Context Protocol, Tools - Specification 2025-06-18, 18 Juni 2025. Diakses 26 Oktober 2026.
4. UK National Cyber Security Centre, Guidelines for Secure AI System Development, versi 1.0, 27 November 2023. Diakses 26 Oktober 2026.
5. OpenAI, A Practical Guide to Building AI Agents, 15 Januari 2026. Diakses 26 Oktober 2026.
6. Erik S. dan Barry Zhang, Anthropic, Building Effective Agents, 19 Desember 2024. Diakses 26 Oktober 2026.
7. European Parliament dan Council of the European Union, Regulation (EU) 2024/1689, Article 14: Human Oversight, Official Journal, 12 Juli 2024. Diakses 26 Oktober 2026.