Kalau proyek AI gagal, orang paling gampang menyalahkan model.
“Modelnya kurang pintar.”
“Accuracy-nya belum cukup.”
“Harus pakai model yang lebih besar.”
“Coba ganti vendor.”
Kadang memang benar.
Tapi di banyak perusahaan, model bukan bottleneck utama.
Data-nya berantakan.
Process-nya nggak jelas.
Owner-nya abu-abu.
Approval chain absurd.
Knowledge base stale.
User tidak percaya.
System tidak terintegrasi.
Lalu semua masalah itu dibungkus menjadi satu diagnosis: AI-nya gagal.
Pada 2026, enterprise AI sudah makin mature. Vendor besar mendorong agent yang bisa bekerja lintas aplikasi, membaca data internal, dan melakukan action. NIST juga menekankan bahwa utility AI agent sangat bergantung pada kemampuan berinteraksi dengan external systems dan internal data secara reliable serta interoperable.
Kalimat itu penting.
Agent sepintar apa pun tidak bisa membantu kalau data yang dibaca salah atau workflow yang dimasuki memang kacau.
Misalnya perusahaan mau AI untuk customer service.
Demo kelihatan bagus.
User tanya status order.
AI jawab.
Masuk production, masalah muncul.
Order status ada di dua system.
Satu update real-time.
Satu delay empat jam.
Policy refund ada tiga versi.
FAQ lama masih terindeks.
CRM punya customer ID duplicate.
Agent membaca semuanya.
Lalu customer dapat jawaban salah.
Apakah model bodoh?
Belum tentu.
Sistem perusahaan sendiri tidak punya satu versi kebenaran.
AI hanya mengekspos kekacauan yang sebelumnya ditutup oleh pengalaman staf.
Manusia customer service mungkin tahu secara informal, “kalau data di system A beda sama B, percaya yang B.”
AI tidak tahu rule itu kecuali dibuat explicit.
Ini contoh kenapa knowledge tacit menjadi masalah.
Banyak perusahaan berjalan karena pegawai senior tahu workaround.
“Kalau vendor X, pakai form lama.”
“Kalau customer enterprise, jangan ikuti SOP ini.”
“Kalau invoice tipe itu, approval-nya langsung ke finance manager.”
Rule hidup di kepala orang.
Bukan system.
Ketika AI masuk, tacit knowledge harus diubah jadi process yang bisa dibaca.
Kalau tidak, agent terlihat gagal padahal organisasi belum pernah benar-benar mendokumentasikan cara kerja sendiri.
Data quality adalah layer pertama.
Nama customer tidak konsisten.
Tanggal berbeda format.
Field kosong.
Status tidak pernah ditutup.
Dokumen duplicate.
File final bernama FINAL_v7_baru_fix2.
Semua ini klasik.
AI tidak membuatnya hilang.
Justru AI membuat dirty data bergerak lebih cepat.
Kalau model summarization membaca lima policy yang saling bertentangan, output-nya bisa terlihat rapi tapi salah.
Kalau recommendation engine membaca inventory yang tidak akurat, rekomendasi juga salah.
Kalau agent procurement menggunakan supplier master duplicate, action bisa keliru.
Garbage in, garbage out masih berlaku.
Hanya sekarang garbage out terdengar jauh lebih meyakinkan.
Layer kedua adalah process clarity.
Banyak proyek AI dimulai dari pertanyaan, “apa yang bisa kita otomatisasi?”
Lebih baik mulai dari, “sebenarnya process kita sekarang bagaimana?”
Step.
Input.
Decision.
Exception.
Approval.
Output.
Owner.
SLA.
Kalau process tidak bisa digambar dengan jelas, agent sulit masuk.
AI bukan magician yang menyelesaikan ambiguity organisasi.
Kalau dua departemen punya rule berbeda untuk kasus sama, model akan menerima contradiction.
Kalau approval tidak jelas, agent tidak tahu kapan harus stop.
Kalau ownership tidak jelas, error tidak ada yang bertanggung jawab.
Process mapping sebelum automation punya ROI besar.
Kadang setelah dipetakan, perusahaan sadar AI bahkan tidak perlu.
Ada step yang cukup dihapus.
Ada form duplicate.
Ada approval yang sudah tidak relevan.
Ada data entry yang bisa diselesaikan rule-based automation.
AI seharusnya masuk setelah process dibersihkan.
Bukan digunakan untuk membuat process buruk berjalan lebih cepat.
Layer ketiga adalah integration.
Pilot sering menggunakan CSV.
Production menggunakan ERP, CRM, ticketing, email, database, dan legacy system.
Di sinilah banyak project mati.
Model bisa menjawab.
Tapi tidak bisa mendapatkan data yang tepat.
Atau connector cuma read, padahal workflow butuh write.
Atau write access terlalu luas.
Atau API rate limit.
Atau data latency.
Atau field mapping berubah.
Integration engineering sering lebih berat daripada prompt engineering.
Ini alasan enterprise AI 2026 makin bicara tentang interoperability.
NIST bahkan memasukkan interoperable agent ecosystem sebagai salah satu fokus AI Agent Standards Initiative.
Karena model tanpa akses ke sistem nyata hanya jadi advisor.
Untuk membuat value operasional, AI harus masuk workflow.
Layer keempat adalah measurement.
Banyak project AI diluncurkan tanpa baseline.
“Tujuannya meningkatkan produktivitas.”
Produktivitas apa?
Waktu per task?
Throughput?
Error rate?
Cycle time?
Cost?
Customer satisfaction?
Kalau tidak jelas, keberhasilan jadi subjektif.
Satu tim bilang bagus.
Tim lain bilang biasa.
Management melihat demo.
Finance melihat invoice.
Tidak ada bahasa bersama.
Project harus punya unit of work.
Misalnya satu invoice.
Satu ticket.
Satu request.
Satu claim.
Satu lead.
Satu purchase requisition.
Kemudian ukur sebelum dan sesudah.
Berapa menit?
Berapa error?
Berapa human touch?
Berapa cost?
Berapa escalation?
Kalau semua tidak diukur, AI mudah jadi theatre.
Layer kelima adalah exception.
Happy path selalu mudah.
Data lengkap.
Request jelas.
Policy sesuai.
User normal.
Masalah enterprise hidup di exception.
Invoice tanpa PO.
Customer marah.
Supplier baru.
Contract clause aneh.
File corrupt.
Nama tidak match.
Approval owner cuti.
System down.
AI project perlu mendesain exception dari awal.
Apa yang terjadi ketika model tidak yakin?
Escalate?
Masuk queue?
Minta data tambahan?
Berhenti?
Jangan memaksa AI menjawab semua.
Abstention adalah fitur.
System yang tahu kapan menyerah sering lebih aman daripada model yang selalu memberi output.
Layer keenam adalah ownership.
Siapa business owner?
Bukan siapa vendor.
Bukan siapa data scientist.
Siapa orang yang bertanggung jawab terhadap outcome?
Kalau AI dipakai di procurement, procurement harus punya owner.
Kalau HR, HR.
Kalau customer service, service.
IT membantu platform dan security.
Business owner menentukan process.
Tanpa owner, project jadi orphan setelah pilot.
Vendor pergi.
Consultant selesai.
Team internal bingung siapa maintain prompt dan data.
Tiga bulan kemudian quality turun.
Orang bilang AI-nya jelek.
Padahal lifecycle tidak pernah didesain.
Layer ketujuh adalah change management.
User tidak otomatis memakai tool hanya karena tersedia.
Ada staff yang takut.
Ada yang skeptis.
Ada yang terlalu percaya.
Ada yang merasa workflow baru lebih ribet.
Pilot harus melibatkan user nyata.
Bukan hanya manager dan IT.
Orang yang melakukan pekerjaan tahu bagian yang annoying.
Mereka tahu exception.
Mereka tahu shortcut.
Mereka juga paling cepat melihat kalau AI recommendation tidak masuk akal.
Feedback mereka harus masuk desain.
Kalau user terus override recommendation, jangan langsung anggap resistance.
Mungkin model memang salah.
Atau process tidak cocok.
Track reason.
Learning datang dari override.
Layer kedelapan adalah trust.
AI project bisa technically bagus tapi gagal karena user tidak percaya.
Kenapa tidak percaya?
Sering karena output tidak punya source.
Atau pernah salah sekali pada kasus penting.
Atau tidak jelas data apa yang dipakai.
Atau tidak bisa menjelaskan action.
Trust perlu dibangun.
Mulai read-only.
Tampilkan source.
Beri preview.
Beri undo.
Beri confidence jika meaningful.
Gradually tambah autonomy.
Jangan langsung memberi agent tombol delete, send, dan approve.
Trust adalah hasil pengalaman.
Bukan slide governance.
Layer kesembilan adalah data freshness.
Knowledge base yang benar hari ini bisa salah enam bulan lagi.
Policy berubah.
Harga berubah.
Organization berubah.
Employee pindah.
Product discontinued.
Kalau retrieval system tidak punya owner dan update process, AI akan menampilkan informasi lama dengan bahasa baru.
Ini berbahaya.
Knowledge governance harus punya timestamp.
Owner.
Source.
Version.
Expiry.
AI project sebenarnya sering menjadi knowledge management project.
Model hanya interface.
Layer kesepuluh adalah economics.
Kadang model terbaik terlalu mahal untuk task.
Atau agent memakai terlalu banyak step.
Atau context terlalu besar.
Atau human review tetap tinggi.
Project technically berhasil tetapi financially tidak masuk akal.
OpenAI pada 2026 bahkan mendorong enterprise mengukur useful work per dollar ketika agentic workflows berkembang.
Ini framing yang bagus.
Jangan ukur token.
Ukur pekerjaan selesai.
Kalau satu task manual Rp50.000 dan AI jadi Rp60.000 setelah review, buat apa?
Kalau AI jadi Rp15.000 dengan quality sama, baru menarik.
Model choice datang setelah economics.
Tidak semua task butuh frontier model.
Classification sederhana mungkin cukup model kecil.
Complex reasoning baru pakai model kuat.
Routing bisa menghemat cost.
Layer kesebelas adalah security.
Kadang project dihentikan bukan karena kualitas.
Security tidak approve.
Agent perlu akses data sensitif.
Vendor tidak bisa menjelaskan retention.
Connector terlalu luas.
Prompt injection risk.
Identity tidak jelas.
Audit log kurang.
Ini bukan “security menghambat innovation”.
Ini tanda architecture belum production-ready.
Security harus masuk desain awal.
Kalau baru dipanggil seminggu sebelum launch, project terlambat.
Layer kedua belas adalah testing.
Prompt yang bekerja hari ini belum tentu sama setelah model update.
Data juga berubah.
Workflow berubah.
Perusahaan perlu regression test.
Set kasus nyata.
Known answer.
Edge case.
Adversarial.
Sensitive.
Setiap perubahan besar diuji.
AI production lebih dekat ke software engineering daripada experimentation.
Jangan mengandalkan vibes.
“Kayaknya sekarang lebih bagus.”
Tidak cukup.
Ada angka.
Ada test.
Ada threshold.
Di Jakarta, banyak perusahaan punya architecture yang campur.
Cloud modern.
Legacy on-prem.
Spreadsheet manual.
WhatsApp informal.
Email.
ERP.
CRM.
AI bisa membantu menjembatani.
Tapi jangan pura-pura integration sederhana.
Kadang proyek paling penting justru bukan upgrade model.
Merapikan master data.
Membuat API.
Menentukan source of truth.
Memotong approval.
Mendokumentasikan SOP.
Ini pekerjaan boring.
Tapi boring work sering menghasilkan ROI lebih besar daripada mengganti model.
Ada satu tes sederhana sebelum menyalahkan AI.
Kalau manusia baru masuk ke process ini tanpa pengalaman, apakah dia bisa bekerja hanya dari data dan SOP yang tersedia?
Kalau jawabannya tidak, jangan heran AI juga struggle.
Manusia mungkin bertahan karena bisa bertanya ke senior.
AI perlu jalur escalation yang setara.
Perusahaan juga perlu sadar bahwa AI kadang mengungkap problem organisasi yang sebelumnya hidden.
Ini sebenarnya benefit.
Kalau AI sering gagal karena policy conflict, berarti policy memang conflict.
Kalau agent tidak tahu data mana benar, berarti data governance lemah.
Kalau automation berhenti karena approval tidak jelas, berarti process design buruk.
Jangan selalu patch model.
Perbaiki akar.
Model bagus penting.
Tapi enterprise value jarang datang dari model sendirian.
Value datang dari kombinasi model, data, process, integration, user, dan governance.
Kalau salah satu lemah, project goyah.
Jadi ketika AI project gagal, jangan langsung buka benchmark leaderboard.
Buka workflow map.
Buka data quality report.
Buka integration log.
Buka override reason.
Buka KPI.
Bisa jadi modelnya sudah cukup pintar.
Yang belum siap justru perusahaan di sekelilingnya.
Bacaan terkait
Artikel ini berada dalam Industry Intelligence dan mengikuti metodologi editorial Undercover.id. Format terkait tersedia di Reports dan analisis mendalam.