Kenapa Pilot AI Agent Gagal Bawa ke Produksi

Demo yang jalan di laptop biasanya bukan masalah. Yang bikin pilot mati adalah fase setelah demo: ketika sistem harus menghadapi data kotor, permintaan yang tidak ada di skenario, dan orang yang tidak sabar menunggu jawaban.

Angka yang sering dikutip soal kegagalan ini memang keras. Riset MIT NANDA, “The GenAI Divide: State of AI in Business 2025” (Juli 2025), menyimpulkan sekitar 95% inisiatif AI generatif di perusahaan tidak menghasilkan dampak terukur ke laba, dengan metode 153 respons survei, 52 wawancara organisasi, dan lebih dari 300 inisiatif publik yang ditinjau. Laporan yang sama menyoroti akar masalahnya: kesenjangan antara cara perusahaan belajar dan cara mereka mengimplementasikan.

Artikel ini bukan soal angkanya. Artikel ini soal pola yang berulang: lima hal yang sama, yang kalau lo lihat di minggu pertama sebuah pilot, hampir pasti pilot itu akan berakhir sebagai slide.

TL;DR

• Kegagalan pilot jarang soal model. Biasanya soal workflow, kepemilikan, dan ukuran sukses.
• Pilot yang tidak menyentuh proses kerja nyata tidak akan pernah punya angka. Kalau tidak ada angka, tidak ada keputusan lanjut.
• Ukuran sukses yang benar bukan “jawaban terlihat bagus”, tapi waktu per tugas, tingkat penyelesaian, dan biaya per hasil.
• Tiga syarat minimum sebelum produksi: data bisa diakses tanpa izin khusus, ada jalur rollback, dan ada yang memantau biaya per hari.
• Berhenti itu keputusan yang sah. Yang tidak sah adalah membiarkan pilot menggantung enam bulan tanpa keputusan.

Akar masalahnya: belajar dan implementasi berjalan di dua jalur berbeda

Temuan yang paling sering dikutip dari laporan itu adalah kesenjangan antara cara orang belajar memakai AI (jalur pribadi, cepat, informal) dan cara organisasi mengimplementasikannya (proyek, anggaran, komite). Individu di lantai kerja sudah memakai AI untuk menyelesaikan pekerjaan mereka minggu ini, sementara proyek resmi masih di tahap penyusunan ruang lingkup.

Akibatnya dua hal terjadi sekaligus:

• Pilot resmi dibangun untuk skenario yang tidak pernah jadi pekerjaan harian siapa pun, jadi tidak ada yang memakai.
• Pemakaian nyata tumbuh di luar pengawasan, jadi tidak ada yang bisa mengukur dampaknya.

Kalau lo melihat dua gejala ini di organisasi lo, masalahnya bukan teknis.

Lima pola kegagalan yang berulang

1. Pilot dibangun untuk demo, bukan untuk tugas yang punya jam kerja

Skenario demo biasanya: unggah dokumen, tanya, jawaban muncul. Skenario nyata biasanya: dokumen datang dalam PDF hasil scan, setengah tabelnya hilang, dan pertanyaannya ambigu. Tim yang membangun untuk demo akan menemukan semua kasus sulit di minggu pertama produksi, satu per satu, tanpa waktu.

2. Tidak ada pemilik yang memegang angka

Kalau ditanya “siapa yang bertanggung jawab kalau agent ini menghemat 40 jam sebulan atau tidak”, dan jawabannya kosong, pilot itu tidak punya tujuan yang bisa gagal. Yang tidak bisa gagal juga tidak bisa berhasil.

3. Ukuran suksesnya kabur

“Terlihat membantu” bukan metrik. Metrik yang bisa dipakai: waktu penyelesaian per tiket, persentase tugas selesai tanpa eskalasi, jumlah eskalasi per 100 percakapan, dan biaya per percakapan. Semua itu bisa dihitung sebelum pilot dimulai, bukan sesudah.

4. Data ada, tapi tidak bisa diakses

Ini penyebab yang paling sering gue temui di lapangan dan paling jarang masuk slide. Datanya ada di spreadsheet pribadi, di grup WhatsApp, di aplikasi lama yang tidak punya API. Agent tanpa akses data hanya jadi chatbot yang jawabannya sopan tapi tidak berguna.

5. Tidak ada jalur dari pilot ke produksi

Pilot biasanya berjalan di mesin satu orang, dengan kredensial pribadi, tanpa logging, tanpa pemantauan biaya. Ketika pilot dianggap berhasil, tidak ada satu pun komponen yang bisa dipindahkan ke produksi tanpa dibangun ulang. Jadi proyeknya berhenti di situ, bukan karena gagal, tapi karena tidak ada jembatan.

Pilot yang selamat beda di satu hal

Pilot yang berhasil biasanya mulai dari satu tugas yang sempit, punya angka sebelum-sesudah, dan pemilik yang jelas. Bukan dari “kami akan menerapkan AI di seluruh perusahaan”.

Ciri lain yang konsisten: mereka memasang pembatas biaya dan pembatas akses di hari pertama, bukan setelah ada insiden. Agent yang bisa memanggil tool apa pun tanpa batas bukan keunggulan, itu utang.

Checklist lima langkah dari pilot ke produksi

1. Pilih satu tugas dengan angka baseline. Contoh: menjawab pertanyaan stok dari 40 pesan per hari, rata-rata 3 menit per jawaban. Baseline ini yang nanti dibandingkan.
2. Tentukan definisi selesai. Tugas dianggap selesai kalau jawaban keluar tanpa eskalasi ke manusia dan tidak dikoreksi dalam 24 jam. Tanpa definisi ini, evaluasi akan debat selera.
3. Pasang observability sebelum menambah fitur. Catat minimal: input, output, tool yang dipanggil, waktu, biaya, dan hasil akhirnya benar atau salah. Kalau tidak punya log, lo tidak punya data untuk memperbaiki apa pun.
4. Batasi radius kegagalan. Agent hanya boleh menyentuh data yang memang perlu, dengan kredensial terpisah, dan setiap aksi yang tidak bisa dibatalkan wajib butuh persetujuan manusia.
5. Jalankan seminggu penuh, lalu putuskan. Lanjut, perbaiki satu hal, atau berhenti. Tiga pilihan itu saja. Yang dilarang adalah “dibiarkan jalan dulu”.

Ukuran sukses yang benar, dan yang menyesatkan

Metrik	Berguna?	Kenapa
Akurasi jawaban di set uji	Berguna, dengan syarat	Set ujinya harus dari pertanyaan nyata, bukan yang dibuat tim
Waktu per tugas	Sangat berguna	Ini yang dibayar bisnis
Persentase tugas selesai tanpa eskalasi	Sangat berguna	Mengukur otonomi, bukan kepintaran
Biaya per tugas selesai	Sangat berguna	Menggabungkan model, infra, dan waktu manusia
Jumlah percakapan	Menyesatkan	Ramai bukan berarti berguna
Skor kepuasan subjektif saja	Menyesatkan	Orang cenderung memuji demo

Satu catatan penting soal biaya. Biaya model biasanya bukan komponen terbesar. Dalam hitungan yang bisa lo ulang sendiri: satu balasan agent dengan 1.500 token input dan 300 token output di model bertarif Rp150 dan Rp300 per juta token berada di kisaran Rp0,32. Yang mahal justru biaya kanal, biaya integrasi, dan waktu orang yang merawatnya.

Kapan lo harus berhenti

Berhenti kalau salah satu dari ini terjadi setelah dua minggu berjalan:

• Tidak ada satu pun orang yang memakai agent itu secara sukarela.
• Angka baseline tidak bisa diukur karena datanya tidak pernah tersedia.
• Untuk mendapat hasil yang berguna, lo harus mengganti seluruh proses kerja tim, bukan cuma menambah satu langkah.

Berhenti lebih murah daripada pilot zombie. Tim yang menghabiskan enam bulan pada pilot tanpa keputusan kehilangan dua hal sekaligus: waktu, dan kepercayaan organisasi terhadap proyek AI berikutnya.

Kalau lo baru mulai minggu ini

Urutan yang paling tidak menyakitkan: ambil satu tugas yang menyita waktu satu orang minimal satu jam per hari, ukur baseline-nya selama tiga hari, lalu bangun versi paling sederhana yang menyentuh tugas itu. Bukan versi paling canggih.

Kalau lo masih memilih antara workflow otomatis biasa dan agent yang memutuskan sendiri, kapan pakai AI agent vs n8n membahas batasnya dengan contoh kerja nyata. Dan kalau pertanyaannya sudah soal biaya bulanan, hitung-hitungan biaya platform memecah komponennya satu per satu.

Kesimpulan

95% pilot gagal bukan karena modelnya kurang pintar. Pilot gagal karena dibangun untuk dilihat, bukan untuk dipakai, dan karena tidak ada angka yang bisa memutuskan nasibnya.

Yang bisa lo lakukan hari ini: tulis satu tugas, satu baseline, satu definisi selesai, dan satu nama pemilik. Empat baris itu lebih menentukan daripada pilihan model.