Human-in-the-Loop di Website: Kapan Agent Harus Berhenti dan Meminta Konfirmasi

Jam sudah mendekati lima sore. Bayangkan seorang operations manager meminta AI agent mengecek lima software subscription yang jarang dipakai timnya. Tugas awalnya sederhana: cari plan, lihat tanggal renewal, bandingkan penggunaan, lalu rekomendasikan mana yang layak dihentikan.

Agent membuka dashboard satu per satu. Tiga menit kemudian ia menemukan tombol “Cancel subscription”.

“Kalau memang nggak kepakai, cancel aja,” kata seorang anggota tim.

Finance manager yang duduk di sebelahnya langsung menyela, “Sebentar. Rekomendasikan boleh. Klik cancel jangan otomatis.”

Percakapan pendek itu menangkap problem besar Agentic Web: kapan software boleh bergerak sendiri, dan kapan keputusan harus kembali ke manusia?

Human-in-the-loop atau HITL sering dijelaskan terlalu sederhana sebagai “minta approval sebelum action”. Padahal kalau setiap klik harus dikonfirmasi, automation kehilangan manfaat. Sebaliknya, kalau semua keputusan diserahkan ke model, kita membuat sistem yang cepat tetapi berpotensi terlalu berani.

Desain yang sehat berada di tengah: agent diberi ruang untuk mengerjakan bagian yang rutin, reversible, dan rendah risiko, lalu wajib berhenti ketika action mulai mempunyai konsekuensi material.

Bukan semua klik punya bobot yang sama

Membuka halaman pricing dan menghapus akun perusahaan jelas bukan kelas tindakan yang sama.

Mencari jadwal kosong berbeda dengan mengirim undangan ke 200 orang.

Mengisi draft form berbeda dengan menekan tombol submit.

Menambahkan produk ke cart berbeda dengan menyelesaikan pembayaran.

Karena itu, website yang ingin usable untuk agent perlu memikirkan risk classification pada action surface. Kita tidak harus menunggu ada satu standar universal “agent-ready”. Yang dibutuhkan lebih basic: sistem tahu tindakan apa yang aman dieksekusi otomatis, apa yang butuh checkpoint, dan apa yang memang harus human-only.

Secara praktis, action bisa dibagi menjadi tiga kelompok.

Pertama, low-impact dan reversible. Misalnya membuka tab, memilih filter, menyortir hasil, memasukkan preferensi pencarian, atau membuat draft yang belum dikirim. Banyak tindakan seperti ini masuk akal dilakukan agent tanpa approval berulang.

Kedua, consequential tetapi masih bisa dikendalikan. Contohnya mengirim email, membuat booking, mengubah alamat pengiriman, mengajukan request, membatalkan layanan, atau mengubah permission. Agent dapat menyiapkan langkahnya, tetapi manusia idealnya melihat ringkasan sebelum eksekusi.

Ketiga, high-risk atau sangat sulit dibatalkan. Pembayaran besar, transfer dana, tanda tangan kontrak, penghapusan permanen, perubahan akses administrator, pengungkapan data sensitif, atau tindakan yang menciptakan kewajiban hukum seharusnya mempunyai guardrail lebih keras.

OWASP dalam guidance keamanan agentic juga menempatkan human approval sebagai salah satu kontrol penting untuk tindakan sensitif. OpenAI pun menjelaskan bahwa agent di Atlas dapat berhenti pada konteks sensitif tertentu agar pengguna memperhatikan tindakan yang akan dilakukan. Intinya sama: autonomy tidak boleh berarti absence of control.

Konfirmasi yang bagus bukan sekadar modal “Are you sure?”

Banyak website sebenarnya sudah mempunyai confirmation dialog. Masalahnya, sebagian hanya kosmetik.

“Apakah Anda yakin?”

Yakin tentang apa?

Kalau manusia sendiri perlu membaca ulang halaman sebelumnya untuk memahami akibatnya, agent juga tidak mendapat boundary yang jelas.

Checkpoint yang kuat harus menjelaskan minimal lima hal.

Apa tindakan yang akan dilakukan.

Terhadap objek siapa atau apa.

Data apa yang akan dikirim atau diubah.

Konsekuensi utamanya.

Apakah tindakan bisa dibatalkan.

Misalnya, dibanding tombol:

“Continue”

lebih jelas jika website menampilkan:

“Batalkan paket Enterprise untuk Workspace ABC. Akses tetap aktif sampai 31 Agustus 2026. Setelah tanggal itu, 43 seat akan dinonaktifkan. Data tidak langsung dihapus. Konfirmasi pembatalan?”

Sekarang manusia punya konteks. Agent juga punya state yang jauh lebih eksplisit.

Untuk transaksi, ringkas harga final, pajak, biaya tambahan, penerima, dan metode pembayaran sebelum tombol terakhir.

Untuk komunikasi, tampilkan penerima, subject, attachment, dan apakah pesan akan dikirim sekarang atau dijadwalkan.

Untuk perubahan permission, tampilkan siapa yang mendapat akses baru dan level aksesnya.

Action summary bukan dekorasi. Itu bagian dari safety architecture.

Jangan menyamakan “model yakin” dengan “action aman”

Di sinilah banyak desain agentic tergelincir.

Model mungkin sangat yakin bahwa user ingin melakukan sesuatu. Tetapi confidence model bukan policy.

Misalkan user berkata, “Bereskan semua akun yang sudah tidak dipakai.”

Agent menemukan satu akun dengan login terakhir enam bulan lalu. Secara probabilistik, mungkin akun itu memang tidak aktif. Tetapi ternyata akun tersebut adalah break-glass admin account untuk keadaan darurat.

Model tidak boleh membuat kebijakan keamanan dari tebakan.

Sistem deterministik harus tetap memegang constraint penting: role, permission, spending limit, data classification, approval requirement, allowed action, dan escalation rule.

Agent boleh mengusulkan.

Agent boleh menjelaskan.

Agent boleh menyiapkan draft.

Tetapi authorization harus berasal dari policy yang jelas, bukan dari kemampuan model merasionalisasi tindakannya sendiri.

Human-in-the-loop juga bukan obat untuk semua risiko

Ada anggapan bahwa selama manusia diminta approval, sistem otomatis aman.

Tidak sesederhana itu.

Bayangkan agent membaca halaman eksternal yang mengandung instruksi berbahaya. Instruksi tersebut mencoba memengaruhi agent agar mengubah tindakan, lalu menampilkan alasan yang terdengar meyakinkan kepada user.

Kalau approval screen hanya mengulang teks yang dihasilkan agent atau halaman itu, manusia bisa diarahkan untuk menyetujui sesuatu yang tidak ia pahami.

OWASP bahkan membahas risiko ketika mekanisme HITL sendiri dapat dimanipulasi atau “ditempa”. Karena itu approval surface sebaiknya berasal dari trusted application layer, bukan dari konten tidak tepercaya yang baru saja dibaca model.

Dengan kata lain, jangan bertanya:

“Agent mengatakan tindakan ini aman. Setuju?”

Tampilkan fakta yang berasal dari sistem:

Action: transfer dana.

Nominal: Rp25.000.000.

Tujuan: rekening X.

Sumber: rekening Y.

Permission: user approval required.

Status: belum dieksekusi.

Data seperti itu membuat approval lebih grounded.

Kapan agent seharusnya berhenti?

Tidak semua organisasi punya risk matrix yang sama, tetapi beberapa trigger cukup universal.

Agent harus cenderung berhenti ketika ada perubahan dari read menjadi write.

Saat akan mengirim sesuatu ke pihak luar.

Saat action memindahkan uang atau menciptakan biaya.

Saat data sensitif akan dibagikan.

Saat permission, authentication, atau security setting berubah.

Saat tindakan sulit di-undo.

Saat user intent ambigu.

Saat halaman memberi informasi yang saling bertentangan.

Saat target action berubah di tengah workflow.

Saat ada warning yang belum dipahami.

Saat sistem tidak bisa memverifikasi state setelah action.

Saat scope yang diminta lebih luas daripada authorization awal.

Ini bukan berarti semua kondisi selalu memerlukan pop-up. Sebagian bisa ditangani dengan policy engine. Tetapi high-impact ambiguity seharusnya tidak diloloskan hanya karena model ingin menyelesaikan task.

Konfirmasi terlalu sering juga berbahaya

Ada sisi lain yang sering luput: confirmation fatigue.

Kalau agent meminta approval setiap beberapa detik, user akan belajar menekan “Yes” tanpa membaca.

“Boleh buka halaman ini?”

“Yes.”

“Boleh isi nama?”

“Yes.”

“Boleh pilih tanggal?”

“Yes.”

“Boleh lanjut?”

“Yes.”

“Boleh kirim data finansial ke pihak ketiga?”

User yang sudah autopilot bisa menekan “Yes” lagi.

Ini pattern yang buruk.

Checkpoint harus jarang tetapi bermakna. Manusia perlu merasakan bahwa ketika sistem berhenti, memang ada sesuatu yang patut diperiksa.

Desainnya bisa memakai progressive autonomy.

Action rutin berjalan otomatis.

Action baru atau lebih sensitif memberi preview.

Action dengan dampak tinggi membutuhkan explicit confirmation.

Action terlarang berhenti total.

Dengan pola seperti ini, human attention dipakai ketika nilai perhatian memang tinggi.

Preview sebelum execute jauh lebih berguna daripada penyesalan setelah execute

Salah satu pola paling sehat untuk agentic workflow adalah:

plan,

preview,

authorize,

execute,

receipt.

Agent terlebih dahulu menyusun apa yang hendak dilakukan.

Website atau aplikasi menampilkan consequence yang relevan.

User memberi izin.

Action dieksekusi.

Sistem mengembalikan bukti hasil.

Receipt terakhir ini penting.

Kalau agent memesan hotel, user perlu tahu booking benar-benar berhasil, bukan sekadar “agent sudah mengklik tombol”.

Kalau agent mengubah alamat, tampilkan alamat baru dan waktu perubahan.

Kalau agent mengirim proposal, tampilkan siapa penerimanya dan status terkirim.

Agentic UX tanpa post-action state akan menciptakan ketidakpastian baru.

Apakah sudah terjadi?

Apakah gagal?

Apakah terduplikasi?

Apakah masih pending?

Manusia butuh jawaban. Mesin juga.

Tim produk, security, legal, dan marketing harus duduk di meja yang sama

Human-in-the-loop bukan hanya problem UX designer.

Tim product perlu menentukan flow.

Engineering perlu memastikan state dan authorization konsisten.

Security perlu menentukan risk boundary dan privilege.

Legal atau compliance perlu mengidentifikasi tindakan yang menimbulkan kewajiban.

Marketing perlu memastikan CTA dan copy tidak ambigu.

Customer service perlu tahu apa yang terjadi ketika automation gagal.

Ini salah satu perubahan penting di Agentic Web. Sebuah tombol tidak lagi sekadar elemen conversion.

Tombol adalah potential action endpoint.

Kalau labelnya ambigu, konsekuensinya tidak jelas, dan tidak ada confirmation boundary, masalahnya bukan hanya conversion rate. Ia menjadi masalah operational clarity.

Uji dengan skenario yang sengaja tidak nyaman

Jangan hanya mengetes happy path.

Coba berikan agent situasi seperti:

user berubah pikiran di langkah terakhir,

harga berubah setelah agent memilih opsi,

session login expired,

stok habis setelah item masuk cart,

dua tombol punya label yang mirip,

agent menemukan instruksi konflik di halaman,

user meminta “hapus semuanya” tanpa memperjelas scope,

approval diberikan untuk satu item tetapi workflow mencoba memproses sepuluh,

atau sistem mengembalikan success message yang ambigu.

Lalu lihat apakah agent berhenti pada tempat yang benar.

Tujuan pengujian bukan membuat agent selalu berhenti.

Tujuannya memastikan ia tahu kapan tidak boleh melanjutkan.

HITL yang bagus bukan tanda automation gagal

Ada kecenderungan menganggap agent paling canggih adalah agent yang bisa menyelesaikan semuanya tanpa manusia.

Untuk demo, itu memang terlihat keren.

Untuk operasi nyata, definisinya berbeda.

Agent yang matang bukan agent yang tidak pernah meminta bantuan. Agent yang matang adalah agent yang dapat membedakan pekerjaan rutin dari keputusan yang membutuhkan authority manusia.

Kadang value terbesar AI adalah mengerjakan 95 persen pekerjaan lalu menyerahkan 5 persen keputusan yang benar-benar penting dalam bentuk yang sangat jelas.

Manusia tidak perlu memindahkan data, membuka lima tab, atau mengulang field yang sama.

Manusia cukup memutuskan:

“Ya, lakukan.”

“Tidak, batalkan.”

“Atur ulang.”

“Ini di luar scope.”

Di situlah human-in-the-loop menjadi desain yang sehat.

Bukan rem darurat yang ditempel belakangan, melainkan batas wewenang yang dirancang sejak awal.

Agentic Web akan semakin kuat ketika mesin bisa melakukan lebih banyak hal. Justru karena itu, website dan aplikasi perlu semakin jelas tentang satu hal yang sangat manusiawi: kapan keputusan belum boleh diambil tanpa kita.