Saya sudah duduk di cukup banyak post-mortem tahun ini untuk melihat satu pola yang seharusnya lebih banyak diketahui: hampir tidak ada proyek AI gagal yang saya kumpulkan pelajarannya yang penyebabnya adalah model yang kurang pintar. Penyebabnya adalah keputusan manajemen yang dibuat jauh sebelum model itu dipilih. Kalau inisiatif AI Anda macet atau diam-diam dihentikan di 2025, kemungkinan besar itu gagal sebagai proyek, bukan sebagai teknologi.
Ini adalah post-mortem gabungan dari pekerjaan lapangan saya sepanjang tahun ini, dianonimkan, diurutkan berdasarkan seberapa sering saya benar-benar melihat masing-masing pola kegagalan, bukan berdasarkan mana yang paling menarik untuk judul. Kesimpulannya saya taruh di depan, karena memang layak ada di depan: teknologi jarang jadi penghambat. Ketiadaan disiplin proyek yang biasa itulah masalahnya.
Pola kegagalan 1: tidak ada pemilik proses
Penyebab paling umum proyek AI macet adalah tidak adanya satu orang yang bertanggung jawab atas hasilnya. Sebuah jaringan ritel di Tangerang menjalankan pilot AI customer service selama empat bulan tanpa pemilik yang jelas, IT yang membangunnya, customer service yang diharapkan memakainya, dan tidak ada pihak yang merasa bertanggung jawab untuk melakukan tuning, melaporkan masalah, atau memutuskan kapan sistem itu siap diperluas. Proyek itu mati pelan-pelan karena diabaikan, bukan karena gagal secara teknis.
Cara mencegahnya: tunjuk satu orang sebelum proyek dimulai, dengan wewenang untuk mengambil keputusan tuning dan mandat yang jelas untuk melaporkan progres terhadap metrik yang sudah ditentukan. Kalau tidak ada yang bisa menjawab "siapa yang bertanggung jawab membuat ini lebih baik bulan depan," proyek itu sudah setengah jalan ke kuburan.
Pola kegagalan 2: data kotor, ketahuan belakangan
Beberapa proyek yang saya tinjau tahun ini membangun pilot yang menjanjikan di atas dataset sampel yang bersih, lalu begitu bertemu data produksi langsung berantakan, ada data pelanggan duplikat, kategorisasi produk yang tidak konsisten, field setengah terisi yang artinya berbeda-beda antar departemen. AI-nya tidak salah, ia hanya secara akurat merefleksikan kekacauan yang diberikan padanya.
Seorang klien perusahaan multifinance ingin sistem AI untuk mengkategorikan pengajuan kredit secara otomatis berdasarkan tingkat risiko, dan pilot-nya berjalan baik sampai bertemu data intake yang sesungguhnya, di mana field yang sama sudah dipakai secara tidak konsisten di tiga kantor cabang selama bertahun-tahun. Solusinya bukan model yang lebih baik, tapi tiga minggu pembersihan data yang seharusnya dilakukan sebelum proyek AI dimulai, bukan di tengah jalan.
Cara mencegahnya: audit dan bersihkan data produksi yang sesungguhnya sebelum membangun apa pun, bukan sampel, tapi data aslinya, termasuk kasus-kasus khusus dan inkonsistensi yang selama ini diam-diam disiasati oleh staf.
Pola kegagalan 3: scope tanpa batas
"Menangani customer support" bukan scope, itu aspirasi. Proyek yang gagal paling parah tahun ini adalah yang dimulai dengan mandat terbuka alih-alih tugas yang terbatas, sehingga tidak pernah bisa mendefinisikan apa artinya "berhasil," jadi tidak ada yang bisa memastikan proyek itu berhasil atau justru melenceng.
Ini pola kegagalan yang sama dengan yang saya jelaskan dari sisi teknis di AI Agent Frameworks: Memisahkan Hype dari Realita: agent yang berhasil punya tugas yang terbatas dan sedikit langkah yang bisa diverifikasi. Proyek yang gagal karena masalah scope hampir selalu bermula dari mandat eksekutif yang samar, bukan dari alur kerja yang spesifik dan terukur.
Cara mencegahnya: definisikan tugasnya cukup sempit sehingga Anda bisa menulis, dalam satu kalimat, input apa yang masuk dan output benar seperti apa yang diharapkan. Kalau Anda belum bisa menulis kalimat itu, Anda belum punya proyek, Anda baru punya ide.
Pola kegagalan 4: pilot yang dibangun untuk demo, bukan untuk produksi
Demo yang dioptimalkan untuk memukau ruangan adalah artefak yang berbeda dari sistem yang dibangun untuk bertahan menghadapi kasus tepi, input buruk, dan pengulangan kesepuluh dari tugas yang tadinya seru ditampilkan sekali. Beberapa proyek tahun ini terlihat sangat mengesankan di rapat pitching lalu berantakan dalam dua minggu pemakaian nyata, karena demonya diam-diam dikurasi untuk menghindari input yang sebenarnya bisa merusak sistem.
Cara mencegahnya: demokan dengan input nyata, berantakan, dan tidak difilter sejak hari pertama, bukan happy path yang sudah dikurasi. Kalau pilot itu tidak bisa bertahan menghadapi kasus buruk di ruangan tempat keputusan pendanaan dibuat, ia juga tidak akan bertahan di produksi.
Mengurutkan penyebab kegagalan berdasarkan frekuensi
| Peringkat | Penyebab kegagalan | Kategori akar masalah |
|---|---|---|
| 1 | Tidak ada pemilik proses yang jelas | Manajemen |
| 2 | Data produksi kotor atau tidak konsisten | Kesiapan data |
| 3 | Scope tanpa batas dan tidak terdefinisi | Definisi proyek |
| 4 | Pilot yang dioptimalkan untuk demo, gagal bertahan di produksi | Evaluasi |
| 5 | Keterbatasan kemampuan model | Teknologi |
Keterbatasan kemampuan model ada di urutan paling bawah, bukan karena itu tidak pernah terjadi, tapi karena pada saat sebuah tim benar-benar mencapai batas kemampuan yang sesungguhnya, sebagian besar proyek yang memang akan gagal karena alasan manajemen sudah lebih dulu gagal.
Mengukur, bukan menebak
Satu tema yang muncul di setiap proyek yang berhasil diselamatkan adalah, pada akhirnya seseorang memperkenalkan pengukuran nyata terhadap kualitas output, bukan sekadar "kelihatannya berfungsi," tapi rubrik yang terdefinisi dan diperiksa terhadap jawaban yang sudah diketahui benar. Saya sudah menulis lebih lanjut soal cara membangun disiplin itu di Cara Mengukur Apakah AI Agent Anda Bekerja dengan Baik, dan itu layak dibaca sebelum memulai inisiatif AI baru, bukan setelah post-mortem pertama.
Yang bisa langsung diterapkan
Hampir tidak ada proyek AI yang gagal tahun ini karena model tidak bisa menyelesaikan tugasnya. Mereka gagal karena tidak ada yang memiliki hasilnya, datanya lebih kotor dari yang diakui siapa pun, scope-nya tidak pernah dibatasi, atau pilot-nya dibangun untuk memukau, bukan untuk bertahan menghadapi kenyataan. Sebelum menyetujui inisiatif AI berikutnya, jawab empat pertanyaan ini dengan jujur, siapa yang memiliki ini, apakah data sesungguhnya sudah cukup bersih, bisakah Anda menyatakan tugasnya dalam satu kalimat, dan apakah pilot-nya sudah melihat input yang buruk sebelum Anda mendanainya. Kalau empat hal itu benar, teknologi, tahun ini maupun tahun depan, jarang jadi yang menenggelamkan proyek.