Belakangan ini, ketika membaca artikel terkait AI, ungkapan "human-in-the-loop" (HITL, manusia dalam loop) sering muncul. Konsep ini berangkat dari prinsip "AI bisa salah, jadi manusia harus memverifikasi", tapi ternyata struktur ini mudah sekali runtuh. Saya telah menyusunnya. Mari kita mulai

Dari mana istilah ini berasal

Awalnya adalah istilah teknik penerbangan dan militer. Ketika sistem pertahanan pesawat dan rudal menjadi terlalu kompleks dan terotomatisasi, ungkapan ini merujuk pada "manusia yang bisa menghentikan secara darurat".

Kasus paling terkenal adalah Stanislav Petrov pada tahun 1983. Sistem pertahanan udara otomatis Soviet mengeluarkan peringatan "peluncuran rudal nuklir AS terdeteksi", tetapi Petrov "menilai bahwa ini kemungkinan besar adalah kesalahan sistem" dan tidak melaporkan ke atas. Ternyata memang positif palsu, dan Petrov berperan dengan baik sebagai manusia dalam loop dan mencegah perang nuklir.

Sejak 1990-an, konsep ini diserap ke dalam bidang AI dan machine learning menjadi istilah standar untuk "struktur di mana manusia terlibat dalam keputusan sistem AI".

Istilah serupa - in / on / out

Sekeluarga tapi bermakna berbeda:

Industri semakin sering menggunakan istilah human-on-the-loop, tapi lembaga etika seperti Carnegie Council mengkritik ini sebagai "manipulasi istilah oleh para pembuat kebijakan yang ingin menjauhkan manusia lebih jauh dari sistem".

Masalah Inti - 4 Pola di Mana HITL Mudah Runtuh

1. Automation Bias (Bias Otomasi)

Fenomena yang konsisten dikonfirmasi dalam penelitian psikologi. "Kecenderungan lebih mempercayai rekomendasi ketika AI memberikannya". Hasil eksperimen aktual:

• Rekomendasi identik yang diberi label "disediakan oleh AI" diterima manusia dengan lebih baik

• Di lingkungan HITL (pengguna dapat memantau dan menyesuaikan rekomendasi), preferensi algoritma meningkat 7 poin persentase (makalah akademis PLOS One / NCBI, N=292)

• Hasil: human-in-the-loop itu sendiri dapat menurunkan kualitas pengambilan keputusan

Dengan kata lain, bahkan ketika manusia terlibat, karena mereka lebih mempercayai jawaban AI, peninjauan menjadi hanya formalitas.

2. Rubber-Stamp Oversight (Pengawasan Stempel Karet)

Pola di mana manusia hanya memberikan persetujuan formal tanpa meninjau substansi. EU AI Act Pasal 14 menyebutnya sebagai "oversight facade (topeng pengawasan)". Pengawasan menjadi teater jika salah satu dari lima kondisi ini terlewat:

• Waktu peninjauan tidak cukup (beberapa detik per kasus)

• Tidak ada akses ke cara kerja sistem

• Kurangnya kompetensi domain peninjau

• Tidak ada perlindungan institusional untuk pendapat berlawanan

• Tidak ada wewenang override yang nyata

Jika tidak semua lima syarat terpenuhi, itu menjadi struktur yang hanya memindahkan tanggung jawab ke manusia.

3. Normalization of Deviance (Normalisasi Penyimpangan)

Konsep yang ditonjolkan Simon Willison. Ketika AI secara berulang menangani sesuatu dengan baik, manusia semakin tidak meninjau:

"Saya menemukan diri saya sendiri tidak lagi meninjau setiap baris karena Claude Code menangani dengan baik."

Ini adalah versi dimensi waktu dari automation bias. Bukan sekali percaya yang salah, tetapi kepercayaan yang terakumulasi merusak postur peninjauan itu sendiri. Siapa pun yang menggunakan agen coding AI akan menghadapi jebakan ini.

4. Loss of Situation Awareness (Kehilangan Kesadaran Situasi)

Fenomena di mana manusia tidak memahami keadaan sistem saat ini saat mengawasi sistem kompleks. Ini adalah pola lama dalam penelitian kecelakaan penerbangan, dan muncul persis sama dengan agen coding AI.

Ketika agen memodifikasi beberapa file secara bersamaan, manusia tidak bisa mengikuti "keadaan basis kode saat ini". Mungkin tidak terlihat ketika berjalan lancar, tetapi saat ada kesalahan, tidak bisa melacak dari mana kesalahan itu dimulai.

Aspek Baru di Era LLM

Pengjelasan Tanggung Jawab yang Jelas

Ungkapan Simon Willison:

"Komputer tidak bisa bertanggung jawab. Itu adalah pekerjaan Anda sebagai manusia dalam loop. Claude tidak akan dipecat karena PR Anda yang buggy."

Secara hukum, LLM itu sendiri bukan subjek tanggung jawab, jadi tanggung jawab output jatuh ke manusia. "AI yang menulis kode dengan buruk" bukan alasan.

Asimetri Beban Peninjauan

Diagnosis Richard Gill dari Xata:

"Asimetri AI memindahkan pekerjaan dari pengajun ke peninjau. Risiko bahwa insinyur senior menghabiskan waktu meninjau slop AI dan menurunkan produktivitas keseluruhan."

Prompt 3 baris menghasilkan PR → peninjau harus membaca 1.000 baris. Keseimbangan penulisan-peninjauan rusak.

Perubahan Substansial - Dari Coding ke Judgment

Matteo Collina (anggota Node.js Technical Steering Committee) menunjukkan alur yang sama dalam artikel "The Human in the Loop". Dia melaporkan bahwa karena AI menangani implementasi, dia bergeser ke peran meninjau semua perubahan. Dengan kata lain, esensi pekerjaan insinyur senior bergeser dari menulis ke menilai.

Persyaratan Hukum EU AI Act (Berlaku 2026)

Pasal 14 mewajibkan untuk sistem AI berisiko tinggi:

• Orang natural harus dapat memahami kapabilitas dan keterbatasan sistem

• Mempertahankan kesadaran tentang automation bias

• Mampu menginterpretasi output dengan benar

• Mampu menghentikan atau mengambil alih sistem

Otoritas regulasi mengevaluasi setelah faktanya: "Apakah pengawasan benar-benar mungkin". "Kami menulisnya dalam dokumen kebijakan" tidak akan berhasil. Badan regulasi seperti Bundesnetzagentur Jerman dan AESIA Spanyol akan memverifikasi setelah faktanya.

Jadi, apa yang harus dilakukan dalam praktik?

Ringkasan Berdasarkan Pola

Training-time vs Runtime

• Training-time HITL: RLHF, Constitutional AI - menggabungkan umpan balik manusia di tahap pelatihan

• Runtime HITL: pola di atas - keterlibatan manusia selama eksekusi

• Keduanya diperlukan. Satu saja tidak cukup

Keterbatasan dan Kritik

"Apakah manusia benar-benar lebih akurat" pertanyaan

• Adopsi HITL meningkatkan kepercayaan pengguna dan utilitas sistem, tapi akurasi keputusan dapat menurun (7 poin persentase automation bias experiment di atas)

• Peninjau manusia juga memiliki masalah kelelahan / bias / kurangnya konsistensi

• Dalam domain tertentu (beberapa pencitraan medis dll), AI saja lebih akurat daripada manusia saja

Risiko Ketergantungan

HITL dibuat dengan asumsi "manusia akan selalu ada":

• Ketika manusia lebih mempercayai jawaban AI, postur peninjauan melemah

• Ketika AI terlalu cepat, manusia tidak bisa mengikuti

• Akhirnya HITL dapat menjadi alat yang membuat keputusan tampak dibuat oleh manusia

Ringkasan

Human-in-the-Loop bukan gambaran sederhana seperti "AI membuat keputusan → manusia meninjau". Sebenarnya bekerja hanya ketika semua kondisi untuk peninjauan nyata terpenuhi:

• Waktu peninjauan cukup (tanpa tekanan otomasi)

• Operasi sistem dapat dipahami

• Peninjau memiliki kompetensi domain

• Perlindungan institusional untuk pendapat berlawanan

• Wewenang override yang nyata

Jika salah satu dari lima ini hilang, HITL adalah teater. Itu menjadi struktur yang hanya memindahkan tanggung jawab ke manusia, dan ketika automation bias dan normalization of deviance bergabung, mungkin lebih berbahaya daripada AI saja.

Jika Anda adalah pengguna agen coding AI, yang disebut vibe coder, ini adalah bagian untuk memeriksa ulang alur kerja Anda. "Apakah saya benar-benar meninjau, atau hanya menempel stempel" menjadi semakin penting di era ini.

Sumber

• IBM, "What Is Human In The Loop" (materi definisi primer)

• Carnegie Council, "Seven Myths of Using the Term Human on the Loop" (perbedaan in/on/out dan kritik)

• Stanislav Petrov 1983 kasus (dikutip dari Carnegie Council)

• Sele & Chugunova, "Putting a human in the loop: Increasing uptake, but decreasing accuracy" (PLOS One, 2024 / Max Planck Institute Research Paper No. 22-20) - eksperimen automation bias 7 pp

• EU AI Act Pasal 14 (persyaratan hukum)

• Maschinenrecht (Dr. Raphael Nagel), "Human in the Loop & Automation Bias: The Oversight Facade" (lima kondisi)

• Simon Willison, "Your job is to deliver code you have proven to work" (penjelasan tanggung jawab, normalisasi penyimpangan)

• Matteo Collina, "The Human in the Loop" (anggota Node.js TSC, adventures.nodeland.dev)

• Xata, "AI Codes, Humans Engineer" (asimetri beban peninjauan)

• Redis blog, "AI Human in the Loop: Production Oversight Patterns" (ringkasan pola praktis)