Sebelum Menerapkan Agen AI, Tanyakan Dulu Satu Hal Sepele: Ada Berapa Versi Data Pelanggan Anda?
Laporan salah hitung, cukup diselesaikan sekali rapat; agen AI memegang data pelanggan yang salah lalu menjalankan tindakan, itu benar-benar bisa menimbulkan insiden. Sebuah survei 2026 terhadap seribu eksekutif C-level global menunjukkan pengelolaan data sudah melampaui biaya dan talenta menjadi tantangan terbesar penerapan AI. Tulisan ini membahas dasar-dasar data apa yang harus dibenahi sebelum agen mulai bekerja.
Wakil direktur penjualan sebuah pabrik mesin, dalam rapat demo asisten AI mengajukan pertanyaan yang sangat sederhana: "Tahun lalu kita bertransaksi berapa dengan Maju Jaya?"
Sistem mengembalikan sebuah angka. Sang wakil direktur mengerutkan dahi: "Salah, angka ini terlalu kecil."
Belakangan ketahuan, di ERP ada tiga entri pelanggan "Maju Jaya", "PT Maju Jaya", dan "Maju Jaya Tbk", dengan pesanan tersebar di tiga nomor berbeda. AI tak salah, ia dengan jujur menjumlahkan nilai entri "Maju Jaya" saja dan memberitahukannya. Yang salah adalah datanya.
Kesimpulan rapat demo itu adalah "AI belum matang". Menurut saya kesimpulan ini diambil terlalu cepat.
Latar Belakang
Sebuah survei 2026 terhadap 1.000 eksekutif C-level global memberi angka yang sangat menarik: pengelolaan data sudah menjadi tantangan terbesar penerapan AI, mencapai 51%, melampaui biaya dan talenta.
Ini sangat berbeda dari narasi dua tahun lalu. Pada 2023 dan 2024 yang dikhawatirkan semua orang adalah "tak menemukan orang yang bisa AI" dan "GPU terlalu mahal". Dua tahun berlalu, model jadi murah, alat jadi enak dipakai, lalu semua orang menemukan tempat tersangkut ada lebih di depan—data tak bisa dikeluarkan, tak bisa dicocokkan, tak ada yang berani menjaminnya.
Pada periode yang sama, perubahan lain mendorong keseriusan hal ini naik satu tingkat: AI berubah dari "menjawab pertanyaan" menjadi "menjalankan tindakan".
Ini beda hakiki. Dulu AI memberi Anda ringkasan, salah pun Anda sendiri akan menemukannya. Kini agen langsung membuka order di CRM, membuat pelanggan di ERP, mengirim surel ke pelanggan—salah berarti sudah terjadi, dan Anda hanya bisa membereskannya setelahnya.
Fokus Kali Ini
Agar agen aman bekerja, ada tiga dasar data yang tak bisa dihindari:
- Manajemen data master (MDM): memastikan pelanggan, produk, pemasok yang sama adalah satu entri yang sama di semua sistem. Ini paling dasar, dan paling sering dilewati.
- Resolusi entitas (entity resolution): menilai apakah "Budi Santoso", "Bapak Budi Santoso", "BUDI SANTOSO" adalah orang yang sama, dan harus bisa menjelaskan mengapa. Keterjelasan bukan nilai tambah di industri yang diatur ketat, melainkan syarat wajib.
- Silsilah data dan tata kelola akses: data ini dari mana, siapa yang pernah mengubahnya, kolom mana yang bisa dilihat agen. Tanpa lapisan ini, saat terjadi masalah Anda bahkan tak bisa menelusurinya.
Analisis Dampak Pasar
Bagi pengguna Indonesia: yang paling langsung dirasakan pekerja kantoran biasa adalah asisten AI "bicara sangat percaya diri tetapi jawabannya salah". Reaksi kebanyakan orang adalah tak percaya, lalu tak memakainya. Ini sebenarnya reaksi rasional—asisten yang bisa mengarang angka lebih berbahaya daripada tak ada asisten.
Untuk menilai apakah asisten AI perusahaan Anda layak dipercaya, ada cara uji yang sangat sederhana: tanyakan padanya satu pertanyaan yang jawabannya Anda tahu sendiri. Jika ini pun dijawab salah, maka saat ia menjawab pertanyaan yang Anda tak tahu, atas dasar apa Anda mempercayainya?
Bagi penerapan perusahaan: kondisi data perusahaan di Indonesia punya beberapa masalah khas.
Pertama adalah tumpang tindih generasi sistem. Banyak perusahaan sekaligus punya ERP yang berjalan lima belas tahun, CRM yang diterapkan lima tahun lalu, dan alat cloud yang dipasang tahun lalu, dan ketiga sistem punya definisi "pelanggan" yang sama sekali berbeda—ERP pakai nomor pajak, CRM pakai nama perusahaan, alat pemasaran pakai Email. Untuk menyatukan satu orang, aturan pemetaan di tengahnya tak ada yang bisa menjelaskannya.
Kedua adalah anak-anak perusahaan grup berjalan sendiri-sendiri. Pelanggan yang sama membuka akun terpisah di tiga anak perusahaan, masing-masing menegosiasikan harga sendiri, dan di tingkat grup sama sekali tak terlihat "pelanggan ini menyumbang berapa total". Hal ini sebelum menerapkan AI hanya membuat laporan tak enak dilihat, setelah menerapkan berubah menjadi agen memberi penawaran yang salah.
Ketiga adalah masalah varian nama. Ada tidaknya "PT", singkatan atau nama lengkap, pakai nama Inggris atau lokal, tambah tidaknya "Indonesia"—masalah yang tak ada di dunia Barat ini adalah keseharian di sini. Inilah sebabnya langsung memakai alat resolusi entitas Eropa-Amerika kerap hasilnya tak sesuai harapan, jadi wajib diuji dengan data sendiri.
Alat yang menangani lapisan ini di pasaran tak sedikit: Reltio menempuh jalur real-time dan AI agen, Semarchy mengunggulkan disiplin DataOps, Profisee terikat erat ekosistem Microsoft, CluedIn memakai basis data graf dan menagih pakai-baru-bayar untuk menurunkan ambang. Yang khusus menangani pencocokan itu sendiri ada Senzing dan Data Ladder. Pertanyaan pertama pemilihan bukan perbandingan fungsi, melainkan "cocok tidak dengan tumpukan data yang sudah ada".
Bagi developer: jika Anda membuat agen AI internal perusahaan, ada satu prinsip desain yang menurut saya wajib dipatuhi: setiap data yang dibaca agen harus bisa menjawab "ini dari mana".
Dalam praktik ini berarti beberapa hal. Konten yang dikembalikan alat ke model harus membawa penanda sumber; tiap tindakan penulisan agen harus meninggalkan jejak lengkap; dan yang terpenting—ketika data berkonflik (pelanggan yang sama punya dua batas kredit berbeda), agen harus berhenti dan bertanya ke manusia, bukan memilih sendiri satu.
Desain ini membuat agen tampak "lebih bodoh", karena ia akan sering berkata "saya menemukan dua data yang tak konsisten, mohon konfirmasi". Tetapi kebodohan seperti ini benar. Agen yang menebak sendiri, itulah risiko sejatinya.
Tren Perkembangan ke Depan
Saya mengamati dua arah.
Pertama, MDM yang semula dipandang urusan internal IT, sedang berubah menjadi prasyarat AI. Dulu yang tersulit dari proyek MDM adalah meyakinkan bos mengapa harus mengeluarkan uang untuk hal yang tak terlihat; kini alasannya berubah menjadi "agen memakai data salah akan menimbulkan insiden", dan argumen ini jauh lebih kuat.
Kedua, alat itu sendiri bertransformasi menuju "menyediakan konteks yang tertata bagi agen". Keluaran MDM tradisional adalah catatan emas untuk dilihat manusia, kini keluarannya adalah layanan data untuk dipanggil agen. Peralihan ini akan mendefinisikan ulang pasar ini, sekaligus membuat sekelompok alat lama yang hanya melakukan pemrosesan batch tersingkir.
Namun saya perlu menyiram sedikit air dingin: alat tak bisa memecahkan masalah tata kelola. "Data pelanggan mengacu pada versi siapa", "definisi kolom siapa yang menentukan", "salah siapa yang bertanggung jawab"—ketiga pertanyaan ini adalah politik organisasi, bukan fungsi perangkat lunak. Membeli platform tetapi tak punya peran tata kelola data berwewenang nyata, proyeknya akan berubah menjadi rapat koordinasi antarbagian yang tak ada habisnya. Inilah penyebab paling umum kegagalan proyek MDM, tak berubah selama dua puluh tahun.
Ringkasan dan Ulasan TheAI Academy
Kembali ke contoh pabrik mesin di pembuka. Yang mereka lakukan belakangan sangat sederhana: menghabiskan enam minggu, melakukan deduplikasi dan normalisasi data master pelanggan di ERP sekali, menetapkan aturan "nomor pajak adalah penanda unik", dan menunjuk bagian keuangan sebagai pemilik data master pelanggan.
Demo sekali lagi, angkanya benar.
Ulasan: sukses-gagal proyek AI, delapan puluh persen ditentukan sebelum Anda membuka model. Pastikan dulu data pelanggan Anda hanya punya satu versi, baru bicara model mana yang dipakai.
Saran konkret bagi pembaca Indonesia, saya sebut tiga hal yang bisa dimulai minggu depan:
Pertama, lakukan "uji tanya-jawab sendiri". Pilih lima pertanyaan operasi yang jawaban benarnya Anda tahu sendiri, tanyakan ke alat AI perusahaan atau langsung query basis data. Yang dijawab salah, itulah celah data Anda. Hal ini tak butuh anggaran, satu sore selesai.
Kedua, tunjuk dulu "sumber kebenaran tunggal", baru bicara membeli alat. Data pelanggan mengacu pada ERP atau CRM? Data produk mengacu pada siapa? Keputusan ini tak butuh uang, tetapi merupakan prasyarat semua hal setelahnya. Jika tak bisa memutuskan, membeli sistem apa pun percuma.
Ketiga, cakupannya harus kecil. Jangan membuka proyek "tata kelola data se-perusahaan", itu pasti mengerjakan tiga tahun lalu tak selesai. Pilih satu bidang data yang paling sering dipakai agen (biasanya pelanggan), tiga bulan buat versi bersihnya, pakai ia untuk membuktikan nilai, baru diperluas ke luar.
Bacaan lanjutan: Observabilitas dan Tata Kelola Agen AI di situs membahas cara memantau agen setelah tayang, yang justru menyambung dengan "sebelum tayang" di tulisan ini; Siapa yang Memvalidasi Kode Hasil AI adalah versi logika sama di sisi pengembangan.
Sumber
- McKinsey: The State of AI (Global Survey)
- Gartner Magic Quadrant for Master Data Management Solutions (dimuat ulang situs resmi tiap vendor)
- Keterangan survei resmi Semarchy
Disusun dari informasi publik; angka tiap survei mengacu pada laporan aslinya.
Pertanyaan yang Sering Diajukan
Apa itu manajemen data master (MDM)? Apa bedanya dengan gudang data?
Gudang data memecahkan "memusatkan data untuk dianalisis", MDM memecahkan "apakah pelanggan yang sama di lima sistem itu benar-benar orang yang sama". Yang pertama untuk analisis, yang kedua untuk operasi. Anda bisa punya gudang data yang sangat indah, tetapi data master pelanggan berantakan—kedua hal ini tak saling menyelesaikan.
Apakah UKM juga perlu melakukannya?
Perlu, tetapi skalanya sama sekali berbeda. Cara UKM bukan membeli satu platform MDM, melainkan lakukan dulu dua hal: tunjuk satu sistem sebagai "sumber kebenaran tunggal data pelanggan", dan tetapkan siapa yang berhak menambah dan mengubah data pelanggan. Dua hal ini tak butuh uang, tetapi bisa mencegah delapan puluh persen kekacauan data.
Apa yang terjadi jika agen AI membaca data salah? Apa skenario terburuknya?
Yang paling khas adalah pelanggan ganda: agen menilai ini pelanggan baru, membuka akun kedua, menerbitkan kontrak kedua, mengirim surel selamat datang kedua. Yang lebih serius adalah mencampur data dua pelanggan bernama sama—mengirim penawaran salah, mengungkap catatan transaksi keliru, dan di keuangan serta medis ini insiden tingkat wajib lapor.
Harus mulai dari bidang data yang mana?
Mulai dari yang paling sering dipakai AI, biasanya pelanggan atau produk. Jangan mengerjakan semua bidang sekaligus, itu proyek tiga tahun. Pilih satu yang cakupannya jelas dan titik masalahnya gamblang (misalnya "data pelanggan yang diquery agen penjualan"), tiga bulan buat satu versi bersih, baru diperluas ke luar.