Lewati ke isi

AI & Otomasi

Human-in-the-Loop Agar Otomasi AI Tetap Terkontrol

Rancang titik persetujuan, ambang keyakinan, sampel tinjauan, dan jalur eskalasi agar otomasi AI aman untuk refund, pesan keluar, dan perubahan data.

Terbit 5 menit baca

Jawaban singkat

Human-in-the-loop berarti menaruh manusia di titik keputusan yang berisiko dalam alur otomasi AI. Caranya: langkah persetujuan untuk aksi yang sulit dibatalkan, ambang keyakinan untuk memilah kasus, tinjauan sampel untuk yang lolos otomatis, dan jalur eskalasi yang jelas.

Daftar isi
  1. Petakan dulu risiko tiap aksi
  2. Empat alat kontrol yang bisa dipadukan
  3. Bagaimana penerapannya di tiga kasus umum?
  4. Menjaga agar manusia tidak sekadar menekan tombol setuju
  5. Ringkasan

Seorang pelanggan menulis email panjang dengan nada marah, menyebut pesanannya rusak, dan meminta uang kembali. Agen AI di sistemmu membaca email itu, menyimpulkan permintaannya sah, lalu memproses refund penuh. Belakangan ketahuan bahwa pesanan yang dimaksud sudah pernah dikembalikan bulan lalu. Tidak ada yang sempat memeriksa, karena alurnya memang dirancang tanpa pemeriksaan.

Kejadian seperti ini bukan karena AI-nya buruk, melainkan karena desainnya memberi wewenang terlalu luas. Human-in-the-loop adalah prinsip desain yang menaruh manusia tepat di titik keputusan yang berisiko, sementara bagian lain tetap berjalan otomatis. Tujuannya bukan memperlambat semuanya, tetapi memastikan kesalahan yang mahal tertahan sebelum terjadi.

Petakan dulu risiko tiap aksi

Langkah pertama adalah membedakan aksi berdasarkan akibatnya bila salah. Ukuran yang paling berguna ada dua: seberapa besar kerugiannya, dan seberapa mudah dibatalkan.

Menyusun draf balasan, memberi label pada tiket, atau merangkum dokumen adalah aksi berisiko rendah. Kalau salah, mudah diperbaiki dan tidak ada pihak luar yang terdampak. Mengirim pesan ke pelanggan sudah satu tingkat lebih tinggi, karena pesan yang terkirim tidak bisa ditarik. Mengeluarkan uang, menghapus data, atau mengubah catatan keuangan berada di tingkat tertinggi.

Dari pemetaan ini muncul aturan sederhana: makin sulit dibatalkan sebuah aksi, makin besar kemungkinan ia butuh persetujuan manusia.

Cara praktis membuat peta ini adalah menuliskan semua aksi yang bisa dilakukan alur atau agen dalam satu daftar, lalu memberi setiap aksi satu dari tiga label: boleh otomatis, otomatis dengan tinjauan berkala, atau wajib disetujui. Libatkan pemilik proses saat memberi label, karena merekalah yang tahu kesalahan mana yang paling merepotkan. Daftar ini juga menjadi dokumen yang berguna saat ada audit atau pergantian staf, sebab siapa pun bisa melihat batas wewenang sistem tanpa membaca konfigurasi teknisnya.

Empat alat kontrol yang bisa dipadukan

Langkah persetujuan. Alur berhenti sebelum aksi penting dan menunggu seseorang menyetujui atau menolak. Persetujuan bisa dikirim lewat email, chat tim, atau dasbor. Banyak alat otomasi sudah menyediakan fitur ini. Halaman harga n8n, misalnya, per 4 November 2026 mencantumkan fitur persetujuan manusia untuk pemanggilan alat oleh agen, dan pengantarnya ada di apa itu n8n. Supaya tidak jadi hambatan, pesan persetujuan harus memuat semua yang dibutuhkan penyetuju: ringkasan kasus, aksi yang diusulkan, alasan AI, dan tautan ke data asli.

Ambang keyakinan. Minta model atau langkah validasi memberi nilai keyakinan atau kategori, lalu tetapkan batasnya. Kasus yang jelas dan bernilai kecil boleh lolos otomatis. Kasus yang meragukan atau bernilai besar diteruskan ke manusia. Perlu dicatat, nilai keyakinan yang dilaporkan model bahasa tidak selalu bisa diandalkan sebagai probabilitas. Gabungkan dengan aturan yang bisa dicek pasti, misalnya nominal, riwayat pelanggan, atau kecocokan data.

Tinjauan sampel. Kasus yang lolos otomatis tidak boleh dibiarkan begitu saja. Ambil sebagian secara acak secara berkala, misalnya setiap minggu, lalu periksa apakah keputusannya benar. Dari sini kamu tahu apakah ambang perlu diperketat atau justru bisa dilonggarkan.

Jalur eskalasi. Tentukan siapa yang menerima kasus yang tidak bisa diputuskan, berapa lama batas waktunya, dan apa yang terjadi bila tidak ada jawaban. Persetujuan yang menggantung tanpa pemilik adalah kegagalan desain. Pilihan default yang aman biasanya "jangan lakukan aksi", bukan "lakukan".

Bagaimana penerapannya di tiga kasus umum?

KasusBoleh otomatis bilaWajib manusia bilaYang ditinjau berkala
RefundNominal kecil, pesanan terverifikasi, belum pernah direfundNominal besar, riwayat janggal, data tidak cocokSampel refund otomatis dan alasannya
Pesan keluar ke pelangganTemplate baku, misalnya konfirmasi pesananIsi buatan AI yang menyentuh harga, janji, atau keluhanSampel pesan terkirim dan balasan pelanggan
Perubahan dataMenambah catatan atau labelMenghapus, menimpa, atau mengubah data keuanganLog perubahan dan selisih data

Pada refund, aturan pasti bekerja lebih baik daripada penilaian model. Biarkan AI membaca email dan merangkum klaim, tetapi keputusan otomatis hanya boleh untuk kasus yang memenuhi syarat yang bisa dicek di sistem: pesanan ada, nominal di bawah batas, dan belum pernah ada pengembalian. Selebihnya masuk antrean persetujuan.

Pada pesan keluar, pola yang paling aman adalah AI menulis draf dan manusia menekan tombol kirim. Setelah beberapa waktu, jenis pesan yang terbukti konsisten bisa dilepas ke jalur otomatis, sementara topik sensitif tetap melewati manusia. Bila balasan AI bersumber dari dokumen internal, akurasi sumbernya juga perlu dijaga, seperti dibahas di chatbot AI dari dokumen perusahaan.

Pada perubahan data, bedakan antara menambah dan mengubah. Menambah catatan relatif aman. Menimpa atau menghapus data sebaiknya selalu melalui persetujuan, dan setiap perubahan dicatat di log beserta nilai sebelumnya agar bisa dikembalikan.

Menjaga agar manusia tidak sekadar menekan tombol setuju

Ada jebakan yang sering muncul setelah beberapa minggu: penyetuju mulai menyetujui semua permintaan tanpa membaca, karena hampir semuanya memang benar. Kontrolnya ada, tetapi tidak lagi berfungsi.

Beberapa cara mengatasinya. Kurangi jumlah permintaan persetujuan dengan ambang yang tepat, sehingga yang sampai ke manusia memang kasus yang layak dipikirkan. Tampilkan informasi yang membuat keputusan cepat dan benar, bukan sekadar tombol. Catat siapa menyetujui apa, dan masukkan keputusan yang ternyata keliru ke bahan evaluasi. Penolakan dan koreksi dari manusia adalah data berharga untuk memperbaiki prompt dan aturan.

Desain seperti ini juga menjawab salah satu penyebab umum kegagalan proyek agen, yaitu otonomi yang diberikan terlalu cepat, sebagaimana diulas di kenapa proyek AI agent sering gagal. Untuk memilih bagian proses yang cocok dikerjakan aturan, API, atau AI, lihat RPA vs AI agent.

Ringkasan

Human-in-the-loop bukan tanda kurang percaya pada AI, melainkan cara membagi kerja secara masuk akal: mesin menangani volume, manusia menangani risiko. Mulailah dengan persetujuan di semua aksi yang sulit dibatalkan, ukur hasilnya lewat tinjauan sampel, lalu longgarkan pelan-pelan hanya di bagian yang terbukti konsisten.

Baca juga