Kapan AI Agent Harus Menunggu Persetujuan Manusia

Terlalu sedikit approval membuka risiko. Terlalu banyak approval mengubah manusia menjadi mesin klik yang akhirnya tidak benar-benar memeriksa.

Kalau manusia harus menyetujui setiap pencarian, setiap klasifikasi, dan setiap perubahan format, otomatisasi kehilangan banyak manfaatnya. Sebaliknya, agent yang bebas mengeksekusi semua action dapat membawa risiko yang terlalu besar, terutama saat output menyentuh pihak eksternal, data penting, transaksi, atau informasi sensitif.

Desain yang lebih praktis bukan mencari titik tengah secara asal. Biarkan persiapan yang aman berjalan, lalu kembalikan tanggung jawab ke manusia tepat sebelum tindakan yang membawa konsekuensi nyata.

Approval Bukan Hiasan di Akhir Flow

Tombol approve sering ditambahkan setelah workflow selesai dirancang. Agent melakukan semua pekerjaan, lalu manusia menerima satu kotak output dengan pilihan approve atau reject.

Masalahnya, reviewer belum tentu mendapat informasi yang cukup. Dari mana datanya? Apa yang berubah? Ke siapa pesan akan dikirim? Field mana yang pasti dan mana yang masih asumsi? Action apa yang langsung terjadi setelah tombol ditekan?

Approval yang meaningful perlu dirancang bersama action-nya. Checkpoint harus muncul ketika manusia masih punya kesempatan memahami dan mengubah keputusan, bukan setelah konsekuensinya berjalan.

Untuk setiap checkpoint, tampilkan setidaknya:

• sumber yang digunakan;
• draft atau perubahan yang akan dilakukan;
• target action;
• informasi yang tidak lengkap atau bertentangan;
• dan apa yang terjadi setelah approval.

Reviewer tidak perlu melihat seluruh log teknis. Ia perlu melihat context yang cukup untuk mengambil tanggung jawab.

Action yang Layak Mendapat Approval

Tidak ada satu peta checkpoint yang identik untuk semua organisasi. Risiko, aturan, dan tanggung jawab tiap tim berbeda. Namun, beberapa kategori action layak menjadi starting point.

Mengirim pesan ke pihak eksternal

Email ke pelanggan, pesan ke partner, atau broadcast ke community membawa nama organisasi. Salah tone, penerima, angka, atau status dapat menciptakan masalah yang tidak selesai hanya dengan menghapus draft.

Agent dapat menyiapkan pesan dan penerima yang dituju. Manusia memeriksa payload sebelum send.

Mempublikasikan konten

Drafting dan publishing adalah dua permission berbeda. Agent boleh membantu riset, membuat outline, dan menyusun copy. Publish mengubah draft menjadi komunikasi publik, jadi banyak tim akan memilih checkpoint sebelum action ini.

Mengubah atau menghapus data penting

Memperbarui status task mungkin berisiko rendah di satu workflow dan critical di workflow lain. Mengubah data pelanggan, menghapus file, membatalkan event, atau menimpa record utama perlu dinilai berdasarkan dampak dan kemampuan recovery.

Kalau perubahan sulit di-undo atau memengaruhi sistem lain, approval makin penting.

Membuat transaksi atau komitmen

Pembelian, refund, booking, persetujuan biaya, atau komitmen jadwal membawa konsekuensi finansial dan operasional. Agent dapat mengumpulkan informasi serta membuat rekomendasi, tetapi authority final perlu jelas.

Memakai informasi sensitif

Data personal, finansial, kontrak, atau informasi internal tidak seharusnya dipakai hanya karena technically accessible. Approval dapat menjadi salah satu lapisan kontrol, meski bukan pengganti permission dan kebijakan data yang benar.

Pekerjaan yang Bisa Berjalan Tanpa Menunggu

Human-in-the-loop tidak berarti human-in-every-step.

Pekerjaan seperti membaca sumber yang memang diizinkan, mengelompokkan informasi, membuat draft, memeriksa format, dan menandai missing fields sering dapat berjalan tanpa approval per langkah. Action ini bersifat preparation dan belum mengirim dampak keluar.

Misalnya, Meeting Operations Agent membaca notes, memisahkan keputusan dari action items, lalu membuat preview untuk Telegram. Manusia tidak perlu menyetujui setiap baris saat ekstraksi. Checkpoint lebih berguna setelah draft lengkap, sebelum pesan benar-benar dikirim.

Pola ini membuat agent mengerjakan pekerjaan mekanis, sementara manusia masuk saat pertimbangan dan tanggung jawab dibutuhkan.

Pakai Dua Pertanyaan untuk Menentukan Checkpoint

Saat memetakan flow, tanyakan dua hal untuk setiap action.

Pertama: seberapa besar konsekuensinya kalau action salah?

Kedua: seberapa mudah action tersebut dipulihkan?

Action dengan dampak rendah dan mudah di-undo dapat berjalan otomatis jika permission serta evaluation-nya jelas. Action dengan dampak tinggi atau sulit dibatalkan membutuhkan kontrol lebih ketat. Approval adalah salah satu kontrol yang bisa dipakai.

Contoh sederhana: membuat draft calendar event tidak sama dengan mengirim undangan ke peserta. Menulis update ke area preview tidak sama dengan mengubah record production. Membuat rekomendasi harga tidak sama dengan mengganti harga di checkout.

Perbedaan ini membantu tim menghindari binary thinking antara full manual dan full autonomous.

Tentukan Siapa yang Boleh Approve

Checkpoint tanpa owner hanya memindahkan bottleneck. Semua orang melihat notifikasi, tetapi tidak ada yang tahu siapa yang bertanggung jawab.

Tentukan role yang dapat memberi approval, fallback ketika owner tidak tersedia, dan batas waktu review jika memang dibutuhkan. Untuk action tertentu, approval dari pembuat workflow mungkin cukup. Untuk action lain, diperlukan pemilik data, finance, legal, atau owner komunikasi.

Jangan mengarang urgency jika bisnis tidak memiliki cutoff yang nyata. Kalau tidak ada SLA, sistem cukup menunjukkan status Menunggu approval. Jika ada deadline operasional, sumber deadline itu perlu jelas.

Approval juga harus terikat pada versi payload. Kalau draft berubah setelah disetujui, approval lama tidak otomatis berlaku untuk versi baru. Reviewer seharusnya menyetujui apa yang benar-benar akan dieksekusi.

Rancang Jalur Reject dan Edit

Workflow sering mendesain tombol approve dengan detail, lalu memperlakukan reject sebagai akhir yang kosong.

Padahal reject perlu punya next step. Apakah item kembali ke agent dengan feedback? Apakah manusia mengedit draft langsung? Apakah workflow berhenti dan membuat task untuk owner? Apakah sumber perlu diperbaiki dulu?

Status yang jelas membantu observability. Tim dapat membedakan output yang menunggu review, ditolak karena data kurang, direvisi, disetujui, atau gagal dieksekusi setelah approval.

Tanpa status ini, manusia bisa mengira agent tidak bekerja, padahal item sedang menunggu keputusan. Atau sebaliknya, tim mengira pesan sudah terkirim hanya karena draft sudah disetujui.

Approval Tidak Menggantikan Guardrail Lain

Human approval bukan alasan untuk memberi agent akses seluas mungkin. Reviewer bisa lelah, terburu-buru, atau melewatkan detail. Permission minimum tetap perlu. Input validation tetap perlu. Error handling dan evaluation juga tetap perlu.

Checkpoint bekerja paling baik saat blast radius sudah dibatasi. Agent hanya membaca sumber yang relevan, hanya menyiapkan action dalam scope, dan menampilkan uncertainty dengan jelas. Manusia kemudian memeriksa keputusan yang memang membutuhkan tanggung jawab.

Kalau agent bebas membaca seluruh data dan menyiapkan action apa saja, satu tombol approve menanggung terlalu banyak hal sekaligus.

Audit Workflow yang Sudah Ada

Ambil satu workflow dan tandai semua titik ketika data keluar, record berubah, uang bergerak, atau komitmen dibuat. Lalu periksa apakah manusia masuk terlalu awal, terlalu sering, terlalu terlambat, atau tidak mendapat context yang cukup.

Tujuannya bukan memaksimalkan jumlah approval. Tujuannya menempatkan approval di titik yang tepat.

Prinsip ini akan dipakai dalam workshop Building AI Employees saat merancang flow Meeting Operations Agent. Agent menyiapkan output, reviewer melihat preview, dan pengiriman ke Telegram hanya direncanakan berjalan setelah persetujuan.

Kalau lo mau belajar memetakan checkpoint dan guardrail-nya dalam workflow yang utuh, detail kelas tersedia di sini:

https://goakal.com/ai-builders-id/building-ai-employees

Automation yang sehat tidak menghilangkan manusia dari semua langkah. Ia menghemat perhatian manusia untuk checkpoint ketika judgment mereka benar-benar punya leverage.