Mengapa Pilot AI Perusahaan Macet Sebelum Produksi: Ini tentang Harness, Bukan Model

Model tidak pernah menjadi bagian yang sulit. Dari dalam pembangunan, produksi dimenangkan atau kalah di lapisan sekitarnya: retrieval, grounding, routing, dan evaluasi.

Setiap survei besar tentang AI perusahaan sekarang menggambarkan dinding yang sama: organisasi dapat mengakses model, menjalankan pilot, dan mendemo sesuatu yang mengesankan, dan kemudian hampir tidak ada yang mencapai produksi. Laporan tersebut menggambarkan kesenjangan dari luar, melalui eksekutif yang menjawab kuesioner. Ini adalah pandangan dari sisi lain: dari dalam pembangunan, di mana pilot baik mencapai produksi atau diam-diam mati.

Kesenjangan yang diukur semua orang

Angka-angka telah menjadi familiar. Laporan State of AI in the Enterprise dari Deloitte menemukan bahwa akses ke AI sekarang hampir universal, namun hanya sekitar seperempat organisasi yang mendapatkan 40% dari eksperimen mereka ke produksi, dan sekitar satu dari lima melaporkan tata kelola yang matang untuk agen otonom. Proyek NANDA dari MIT mengatakan lebih tegas: di seluruh ratusan penerapan, sebagian besar tidak menghasilkan pengembalian keuangan yang terukur. Gartner memperkirakan bahwa sebagian besar proyek AI generatif akan ditinggalkan setelah tahap proof-of-concept, dengan alasan kualitas data yang buruk, biaya yang meningkat, dan nilai bisnis yang tidak jelas.

Tumpuk temuan ini bersama-sama dan bentuk tunggal muncul. Bottleneck tidak ada di akses ke model yang mampu. Masalah itu sudah terpecahkan. Bottleneck ada di jarak antara model yang bekerja dalam demo dan sistem yang bekerja dalam produksi, setiap saat, untuk setiap pengguna, di bawah beban nyata, dengan konsekuensi nyata untuk kesalahan.

Catatan yang perlu dinyatakan secara jelas: banyak pilot tidak pernah dikirim karena alasan yang tidak terkait dengan rekayasa: tidak ada kasus bisnis nyata, tidak ada data yang dapat digunakan, tidak ada sponsor eksekutif, atau biaya total yang tidak dimodelkan. Biarkan itu terpisah. Yang mengikuti adalah tentang himpunan pilot yang besar dan frustrasi yang teknis nyata, demo yang meyakinkan, dan memiliki kasus penggunaan nyata di baliknya, dan masih macet di jalan menuju produksi. Untuk itu, faktor penentu hampir tidak pernah model.

Apa yang data survei tidak bisa katakan adalah apa yang sebenarnya menutup jarak itu. Jawaban itu tidak hidup dalam kuesioner. Ia hidup dalam keputusan rekayasa yang dibuat setelah demo mengesankan semua orang dan sebelum sistem dipercayakan dengan pelanggan nyata.

Polanya: perbaikan penentu hampir tidak pernah model

Di seluruh keterlibatan AI perusahaan yang bisa kita bicarakan, pola konsisten berlaku: ketika pilot yang macet akhirnya mencapai produksi, perubahan yang membawanya ke sana jarang merupakan model yang lebih baik. Ia adalah lapisan sekitar model: bagaimana informasi diperoleh dan ditanahkan, bagaimana output diperiksa sebelum mencapai pengguna, bagaimana pekerjaan diberi rute ke model yang tepat daripada yang paling kuat, dan bagaimana semuanya dievaluasi terus-menerus.

Kami menyebut ini sebagai lapisan harness. Sebuah agen, dalam istilah praktis, adalah model dengan akses ke alat, dan harness adalah segala sesuatu yang mengatur bagaimana model tersebut memperoleh konteks, menggunakan alat tersebut, dan diadakan untuk bertanggung jawab atas apa yang dihasilkannya: retrieval, grounding, routing, guardrails, dan evaluasi. Komponen-komponen ini tidak bekerja dalam isolasi. Anda harus menggabungkannya, secara sengaja, untuk kasus penggunaan tertentu. Disiplin gabungan ini adalah apa yang kita sebut sebagai pengharnessan agen, dan inilah tempat kesiapan produksi sebenarnya dimenangkan atau kalah.

Ini membingkai perangkap proof-of-concept. Tim-tim macet karena mereka terus mengoptimalkan bagian yang sudah bekerja. Mereka menukar model yang lebih baru, merekayasa ulang prompt, dan menunggu rilis frontier berikutnya, sementara titik kegagalan nyata duduk satu lapis keluar, di bagian sistem yang demo tidak menekankan.

Grounding, bukan model yang lebih pintar, adalah apa yang membuat agen cukup aman untuk dikirim

Pertimbangkan sebuah asisten rekomendasi dan konsultasi yang kami bangun di sektor asuransi, domain di mana jawaban yang salah dengan percaya diri bukanlah kesalahan tetapi kewajiban. Insting pertama dalam kasus seperti ini adalah mencapai model yang paling mampu dan menganggap kemampuan membeli keamanan. Ia tidak. Model yang lebih fasih menghasilkan halusinasi yang lebih meyakinkan, yang dalam konteks yang diatur adalah lebih buruk, bukan lebih baik.

Apa yang membuat sistem itu bisa dikirim adalah harness: desain retrieval yang menarik hanya dari sumber yang dikelola, aman, dan diperiksa; grounding yang memverifikasi klaim yang dihasilkan melawan sumber tersebut sebelum mencapai pengguna; dan langkah verifikasi yang lebih suka abstain daripada mengklaim sesuatu yang tidak didukung. Hasilnya adalah pengurangan halusinasi yang terukur sebesar 80 hingga 90 persen dibandingkan dengan baseline LLM-only, dengan akurasi grounding di atas 95 persen, sementara mempertahankan latensi P95 di bawah dua detik, sehingga lapisan keamanan tidak pernah membuat sistem terasa lambat.

Pelajaran yang tidak terduga bagi siapa pun yang masih menganggap keamanan dengan pilihan model: lapisan grounding dan verifikasi adalah tata kelola. Dokumen kebijakan dan komite persetujuan penting, tetapi mereka tidak menghentikan model dari mengarang fakta pada saat inferensi. Harness retrieval dan verifikasi melakukannya. Dalam penerapan kami, lapisan teknis grounding adalah mekanisme tata kelola yang sebenarnya: tempat di mana “AI tidak boleh membuat sesuatu” berhenti menjadi prinsip dan menjadi sifat yang ditegakkan dari sistem.

Routing model, bukan pemilihan model, adalah tempat biaya AI diputuskan

Tempat kedua pilot mati adalah tinjauan anggaran. Sebuah sistem dapat bekerja dengan indah dan masih dibatalkan ketika ekonomi per-token, dikalikan melintasi ribuan pengguna dan puluhan kasus penggunaan, berubah menjadi masalah total biaya kepemilikan yang tidak dimodelkan sebelumnya.

Di sini juga, insting untuk memilih model yang kuat dan mengarahkan semuanya melalui itu adalah kesalahan. Sebagian besar beban kerja perusahaan adalah campuran: sebagian besar permintaan adalah rutin, dan sebagian kecil adalah benar-benar sulit. Mengirimkan setiap permintaan ke model frontier berarti membayar harga frontier untuk pekerjaan triase yang model yang lebih kecil dan lebih murah dapat menangani dengan baik.

Dalam migrasi yang kami jalankan dari API LLM pihak ketiga ke Amazon Bedrock , keuntungan datang dari merekayasa ulang lapisan model daripada menukar model. Mengarahkan setiap tugas ke tingkat model yang sesuai, dikombinasikan dengan kontrol biaya dan tata kelola asli Bedrock, menghasilkan pengurangan biaya infrastruktur AI sebesar 42 persen dan generasi konten yang patuh 60 persen lebih cepat, tanpa membangun ulang aplikasi.

Perluas prinsip ini dan itu berkompound. Arsitektur “penasihat” bertingkat, model yang murah melakukan triase dan menangani sebagian besar permintaan, model frontier dicadangkan untuk kasus yang benar-benar membutuhkannya, mengubah routing dari penyelamatan satu kali menjadi penyelamatan struktural.

Polanya ini telah mengarahkan biaya AI perusahaan turun sebesar 60 hingga 80 persen untuk operasi agen, dan hingga 85 persen dalam beberapa penerapan. Poinnya bukanlah persentase utama; itu adalah bahwa biaya sistem AI ditentukan oleh arsitektur, bukan oleh model yang dipilih.

Mengapa ini tidak terlihat dalam data survei

Tidak ada yang muncul dengan jelas dalam survei, karena survei bertanya kepada eksekutif tentang hasil, bukan kepada insinyur tentang mekanisme. “Apakah pilot Anda mencapai produksi?” adalah pertanyaan ya/tidak yang dapat dijawab eksekutif. “Apa yang secara spesifik membawanya ke sana?” adalah pertanyaan yang hanya dapat dijawab oleh tim pembangunan, dan jawabannya hampir tidak pernah “kami menemukan model yang lebih baik.” Ia hampir selalu beberapa versi “kami memperbaiki lapisan sekitar model.”

Kesalahpahaman itu menjelaskan persistensi aneh dari perangkap proof-of-concept. Industri terus mendiagnosis masalah model dan membeli solusi model, sementara kendala sebenarnya duduk di retrieval, grounding, routing, dan evaluasi: pipa yang tidak glamor yang tidak ditunjukkan demo dan tidak diiklankan peluncuran model dasar.

Ia juga menjelaskan mengapa tata kelola dan kecepatan pengiriman tidaklah berlawanan seperti yang diasumsikan. Narasi umum mengobati tata kelola sebagai rem pada pengiriman. Dalam pengalaman kami, ia lebih dekat dengan kebalikannya: pekerjaan grounding dan verifikasi yang membuat sistem dapat diatur adalah pekerjaan yang sama yang membuatnya dapat dipercaya untuk ditempatkan di depan pengguna nyata. Dilakukan di lapisan harness, tata kelola bukanlah apa yang melambatkan pembangunan. Ia adalah apa yang membiarkan pembangunan dikirim.

Apa yang ini berarti jika pilot Anda macet

Jika Anda memiliki proyek AI generatif yang terjebak dalam purgatorium proof-of-concept, hal yang paling berguna yang dapat Anda lakukan adalah menolak dorongan untuk melihat model terlebih dahulu. Model adalah bagian yang paling mungkin sudah cukup baik. Lihatlah lapisan sekitarnya:

• Retrieval dan grounding: apakah sistem menjawab dari sumber yang dikelola dan diverifikasi, atau mengarang dari pelatihan?
• Verifikasi: apakah ada yang memeriksa output sebelum pengguna melihatnya, atau kepercayaan model langsung melalui?
• Routing: apakah setiap permintaan membayar harga frontier, atau apakah pekerjaan cocok dengan model yang paling murah yang dapat melakukannya dengan baik?
• Evaluasi: apakah kualitas diukur terus-menerus melawan benchmark Anda sendiri, atau apakah itu divalidasi sekali dalam demo dan tidak pernah lagi?

Organisasi yang melintasi dari pilot ke produksi pada 2026 bukanlah mereka yang memiliki akses ke model terbaik. Semua orang memiliki itu. Mereka adalah yang memahami bahwa model tidak pernah menjadi bagian yang sulit, dan yang memasukkan upaya rekayasa mereka ke dalam harness, di mana produksi sebenarnya dimenangkan.