Anda menghabiskan berminggu-minggu menyesuaikan chatbot berbasis AI hingga jawabannya akurat. Pemangku kepentingan menyetujui, lalu sistem diluncurkan. Tiga bulan kemudian, sistem tersebut salah dengan percaya diri pada sepertiga pertanyaan pengguna. Model tidak berubah, prompt pun tidak disentuh. Dunia bergerak: harga berubah, kebijakan diperbarui, spesifikasi produk dirilis versi baru, namun penyimpanan pengetahuan di belakangnya tidak ikut berubah.
Kegagalan ini bukan hipotetis. Ini menjadi mode kegagalan produksi paling umum pada AI enterprise saat ini. Sebagian besar tim data engineering belum memiliki alat yang tepat untuk mendeteksi masalah tersebut, terlepas dari cara sistem AI mengambil data.
Sebuah aplikasi AI tidak peduli apakah data diambil dari vector store, indeks dokumen, atau panggilan API. Mekanisme apa pun yang digunakan, pipeline retrieval standar tidak memeriksa apakah data yang disajikan masih benar. Dokumen harga yang sudah usang diambil dengan tingkat kepercayaan yang sama tinggi seperti dokumen terkini, karena sistem menilai relevansi atau ketersediaan, bukan kebenaran.
Kegagalan ini bersifat tidak terlihat secara desain. Data yang usang atau tidak lengkap tetap mendapat skor relevansi tinggi dan lolos setiap pemeriksaan yang dibangun untuk pipeline. Model menjawab dengan keyakinan penuh karena konteks yang diambil terlihat otoritatif. Semua dashboard tetap hijau, sistem terlihat berfungsi, padahal sebenarnya salah.
Tim yang mengalami kegagalan ini cenderung salah mendiagnosis masalah dua kali. Pertama, mereka menyalahkan model dan mencoba LLM lain atau mengubah prompt. Padahal masalah utama berada di lapisan data engineering. Kedua, mereka menyalahkan lapisan retrieval dan membeli solusi baru. Kedua respons ini mengabaikan akar masalah: monitoring yang dibangun hanya untuk memastikan pipeline berjalan, bukan untuk memverifikasi kebenaran data.
Data observability menjadi elemen yang hilang. Konsep ini sudah dikenal luas, namun implementasinya masih kurang diperhatikan. Metrik yang relevan bukan persentase, melainkan cakupan: berapa banyak dataset kritis yang memiliki lineage yang dapat di-query, bukan hanya tersimpan di kepala seseorang.
Dimensi yang perlu dibangun meliputi correctness, freshness, consistency, dan lineage. Correctness memastikan setiap record sesuai bentuk dan aturan yang diharapkan, seperti tipe field yang benar dan tidak ada nilai null yang tidak terduga. Freshness mengukur apakah data masih terkini relatif terhadap sumbernya, dengan SLA yang berbeda per dataset. Consistency memverifikasi fakta yang sama dibaca dengan cara yang sama di seluruh sistem penyimpanan. Lineage memungkinkan pelacakan asal output hingga ke sumber asli beserta setiap transformasi yang dilalui.
Selain keempat dimensi tersebut, dampak kegagalan data pada AI agents meluas ke hilangnya kepercayaan pengguna secara bertahap. Ketika jawaban yang salah terus muncul tanpa peringatan, tim pendukung menghadapi beban kerja tambahan untuk memperbaiki persepsi pelanggan. Selain itu, latar belakang evolusi pipeline data menunjukkan bahwa pola kegagalan serupa sudah terjadi bertahun-tahun sebelum RAG populer, yaitu ketika perubahan upstream tidak dikomunikasikan ke downstream.
Pada Senin pagi, pertanyaan diagnostik yang perlu diajukan bukan model mana yang dicoba berikutnya, melainkan apakah data yang mendasari sudah divalidasi terhadap standar konsumen, berapa usia konten tertua yang masih dilayani dengan kepercayaan tinggi, apakah dua potongan dari sumber yang sama bisa saling bertentangan, serta apakah asal data bisa dilacak jika ternyata salah. Kesenjangan ini terletak di pipeline antara sistem sumber dan apa yang dibaca agen, sehingga memerlukan perbaikan data engineering, bukan pergantian model.
