AI Salah Menyebut Harga, Alamat, atau Layanan: Sumber Masalahnya Bisa Berbeda

Seorang calon pelanggan bertanya ke AI tentang sebuah klinik.

“Berapa harga treatment A?”

Jawabannya Rp750 ribu.

Website resmi menunjukkan Rp950 ribu.

Di hari yang sama, orang lain bertanya alamat cabang terdekat. AI memberi alamat yang memang pernah benar, tetapi cabang itu sudah pindah. Pertanyaan ketiga lebih aneh: AI mengatakan klinik menyediakan layanan yang sebenarnya tidak pernah ditawarkan.

Tiga jawaban salah.

Kelihatannya satu kategori: hallucination.

Untuk operasi AI trust, jangan berhenti di label itu.

Harga salah, alamat salah, dan layanan salah bisa lahir dari mekanisme yang berbeda. Kalau root cause berbeda tetapi treatment kita sama, correction program mudah salah sasaran.

“Perbaiki schema” bukan jawaban universal.

“Tambah artikel” juga bukan.

Yang dibutuhkan adalah diagnosis per claim.

Mulai dengan membedakan false, stale, dan unsupported

Tiga istilah ini sering dicampur.

False berarti informasi salah terhadap kondisi yang sedang ditanyakan.

Stale berarti informasi dulu benar, sekarang tidak lagi.

Unsupported berarti jawaban membuat klaim yang tidak punya evidence yang dapat ditemukan atau diverifikasi.

Contoh:

Harga Rp750 ribu pernah berlaku sampai Februari 2026, lalu naik menjadi Rp950 ribu. Jika AI menyebut Rp750 ribu sebagai harga saat ini pada Agustus 2026, problem utamanya stale information.

Alamat cabang lama juga stale jika cabang memang pernah berada di sana.

Tetapi kalau AI menyebut layanan “operasi laser X” yang tidak pernah disediakan, itu bisa berupa confabulation, entity confusion, inference yang terlalu jauh, atau retrieval dari sumber pihak ketiga yang salah.

Ketiganya tetap perlu dikoreksi.

Tetapi correction path berbeda.

Kasus harga: cari time-sensitive source

Harga punya volatilitas tinggi.

Sumber masalah yang umum:

landing page promosi lama masih indexed,
marketplace belum diperbarui,
PDF price list lama masih publik,
post media sosial lama muncul tanpa konteks tanggal,
affiliate menyalin harga,
structured data tidak sinkron,
product feed terlambat,
cache atau index belum merefleksikan perubahan,
AI menggunakan sumber lama yang masih terlihat kredibel.

Google mendukung informasi price dan availability pada product structured data dan merchant listing. Ini berguna untuk menyatakan data secara machine-readable, tetapi bukan alasan untuk menganggap schema otomatis menyelesaikan semua jalur AI.

Kalau harga berubah cepat, organisasi perlu source of truth yang jelas.

Satu prinsip sederhana:

Harga current harus punya halaman current.

Jangan mengandalkan post promosi lama sebagai sumber utama.

Untuk produk dengan dynamic pricing, jangan menulis angka statis di lima tempat kalau semuanya tidak punya sinkronisasi.

Kalau harga bersyarat, tulis kondisi.

“Mulai dari RpX” tidak sama dengan “harga RpX”.

“RpX untuk member” tidak sama dengan harga umum.

“Promo sampai 31 Agustus” harus punya tanggal.

Semakin eksplisit kondisi, semakin kecil ruang salah interpretasi.

Kasus alamat: entity dan location problem

Alamat terlihat sederhana sampai sebuah brand punya banyak cabang.

Head office.
Registered office.
Store.
Clinic.
Warehouse.
Pickup point.
Temporary booth.
Old branch.
New branch.

Semua bisa muncul di web.

AI bertanya, “alamat brand X”, lalu harus memilih mana yang dimaksud.

Jika website sendiri tidak jelas, ambiguity meningkat.

Google LocalBusiness structured data, misalnya, memungkinkan organisasi menyatakan informasi lokasi, jam, dan detail bisnis lokal. Again, itu sebuah mekanisme representasi data, bukan jaminan jawaban AI.

Diagnosis alamat harus memeriksa:

Apakah alamat lama masih tampil di halaman aktif?
Apakah redirect dari halaman cabang lama menjelaskan perpindahan?
Apakah Google Business Profile sudah benar?
Apakah footer masih menyimpan alamat lama?
Apakah schema dan visible content sinkron?
Apakah directory pihak ketiga punya data usang?
Apakah artikel media lama diberi tanggal yang jelas?
Apakah nama cabang baru sama sehingga mesin menganggapnya lokasi yang sama?

Kalau pindah, jangan hanya menghapus.

Buat transition signal.

“Cabang X pindah dari alamat A ke alamat B sejak 10 Juni 2026.”

Kalimat ini membantu manusia dan mesin memahami relationship between old and new state.

Kasus layanan: ontology dan scope problem

Layanan salah lebih tricky.

Misalnya firma konsultan menawarkan:

tax compliance,
tax advisory,
transfer pricing.

AI kemudian menyebut “legal representation in court”.

Kenapa?

Bisa karena:

kompetitor dengan nama mirip menyediakan itu,
direktori mengklasifikasikan kategori secara terlalu luas,
artikel pihak ketiga menggeneralisasi jenis bisnis,
model menginferensikan layanan berdasarkan kategori,
brand pernah menulis konten edukasi tentang topik tersebut sehingga dianggap menawarkan jasa,
atau sumber lama memang pernah mencantumkan service yang sekarang discontinued.

Ini bukan masalah harga.

Ini entity-service relationship.

Untuk memperbaikinya, organisasi perlu menyatakan scope.

“Kami menyediakan A, B, C.”

Sama pentingnya:

“Kami tidak menyediakan D.”

Exclusion sering dianggap tidak marketing-friendly, padahal sangat berguna untuk trust.

Website institusional yang matang berani mengatakan batas.

Klinik bisa membedakan tindakan tersedia dan tidak tersedia.
Konsultan bisa menjelaskan ruang lingkup.
SaaS bisa menulis feature available, beta, deprecated.
Marketplace bisa membedakan seller dan platform responsibility.

AI trust tidak hanya dibangun dengan mengatakan “kami bisa”.

Kadang dibangun dengan “ini bukan bagian layanan kami”.

Jangan langsung menyimpulkan modelnya salah

Ini bagian yang kadang bikin tim tidak nyaman.

Ketika AI memberi jawaban salah, screenshot itu belum menjelaskan root cause.

OpenAI menjelaskan hallucination sebagai plausible but false statements dan menekankan bahwa masalah ini masih ada pada model bahasa. NIST juga menempatkan confabulation sebagai risiko GenAI.

Jadi model-level error memang nyata.

Tetapi screenshot tidak otomatis membuktikan jawaban salah berasal dari model tanpa source conflict.

Lakukan forensic check.

Pertanyaan yang perlu ditanya:

Apakah jawaban menampilkan citation?
Jika ya, source apa?
Apakah source itu benar saat ini?
Apakah source itu salah membaca brand?
Apakah ada source lain yang lebih baru?
Apakah prompt menyebut lokasi atau waktu?
Apakah jawabannya berubah ketika ditanya “berdasarkan website resmi terbaru”?
Apakah platform sedang menggunakan web retrieval?
Apakah error konsisten di beberapa percobaan?
Apakah error muncul di model lain?
Apakah nama entity ambigu?

Ini bukan untuk membela AI.

Ini untuk menemukan titik perbaikan.

Buat severity berdasarkan consequence

Tidak semua salah informasi perlu diperlakukan sebagai incident dengan level sama.

Salah warna logo tidak sama dengan salah dosis obat.

Salah jam buka tidak sama dengan salah status izin.

Salah harga Rp10 ribu mungkin annoying.
Salah harga kontrak B2B miliaran bisa memengaruhi procurement.

Kita bisa memakai severity model sederhana.

Low:
deskripsi minor, tagline, detail non-operasional.

Medium:
jam, cabang, fitur, product variant, policy yang memengaruhi experience.

High:
harga, availability kritis, legal status, kesehatan, keuangan, keamanan, eligibility, credential, compliance.

Critical:
klaim yang jika dipercaya bisa menyebabkan kerugian serius, tindakan medis yang salah, keputusan finansial berbahaya, atau pelanggaran hukum.

Model ini bukan standar resmi.

Ini governance tool.

Tujuannya menentukan response time.

Harga e-commerce mungkin perlu correction hari yang sama.

Bio founder lama mungkin bisa masuk maintenance cycle.

Catat source lineage

Saat error ditemukan, buat record.

Claim: “Treatment A Rp750 ribu.”
Observed answer: Rp750 ribu.
Current truth: Rp950 ribu.
Observed at: tanggal dan waktu.
Platform/model/surface: catat.
Citation shown: URL jika ada.
Possible stale source: promo Februari.
Official source: halaman harga current.
Severity: medium/high sesuai konteks.
Owner: commerce/marketing.
Action: update old page, deprecate promo, refresh feed, request correction bila tersedia.
Retest: jadwalkan.

Dengan record ini, tim berhenti berdebat abstrak.

“Kok AI salah?”

Berubah menjadi:

“Claim X masih salah pada tiga dari lima pengujian, dan dua jawaban menunjuk source lama.”

Itu operational.

Correction strategy per jenis masalah

Untuk stale price:

perbarui source of truth,
hapus atau tandai promo berakhir,
sinkronkan feed,
perbaiki structured data,
beri tanggal,
pastikan page lama tidak masquerade sebagai current offer.

Untuk wrong address:

sinkronkan location surfaces,
jelaskan perpindahan,
perbaiki official profile,
redirect bila perlu,
pertahankan historical context,
bedakan head office dan branch.

Untuk wrong service:

jelaskan service taxonomy,
tambahkan exclusions,
perbaiki category ambiguity,
hubungkan product/service dengan entity yang tepat,
cek source pihak ketiga yang salah,
hindari konten edukasi yang membuat offering terlihat ambigu.

Untuk pure unsupported hallucination:

perkuat canonical evidence,
uji query berulang,
bandingkan model/surface,
gunakan correction mechanism platform bila tersedia,
dan jangan menjanjikan perbaikan instan.

Fresh evidence tidak selalu langsung “menang”

Ini penting.

Internet tidak punya tombol global “replace old fact”.

Anda bisa memperbarui website hari ini, tetapi sumber lama tetap beredar.

Search engine perlu recrawl.

Platform AI punya arsitektur berbeda.

Model mungkin memakai retrieval, memory, training knowledge, atau kombinasi.

Source selection bisa berubah.

Karena itu correction harus diperlakukan sebagai process, bukan event.

Publish.
Propagate.
Retest.
Record.
Escalate.
Repeat jika perlu.

Jangan memanipulasi dengan membuat puluhan halaman duplikat yang mengulang claim sama.

Lebih baik punya sedikit sumber authoritative yang jelas, current, dan consistent.

Satu meja, tiga kesalahan

Kembali ke klinik tadi.

Harga salah disebabkan promo lama yang masih publik.

Alamat salah karena directory pihak ketiga belum diperbarui setelah cabang pindah.

Layanan salah ternyata tidak punya source sama sekali dan tidak reproducible ketika query diulang. Itu lebih dekat ke model confabulation.

Tiga error.

Tiga root cause.

Tiga correction path.

Kalau tim hanya berkata “AI hallucinate”, insight selesai terlalu cepat.

Kalau tim hanya berkata “SEO kita kurang”, juga salah.

AI trust membutuhkan kebiasaan yang lebih membosankan tetapi jauh lebih berguna: lihat claim, lihat waktu, lihat entity, lihat source, lihat consequence.

Harga adalah state.

Alamat adalah location.

Layanan adalah capability.

Masing-masing punya lifecycle sendiri.

Begitu organisasi memahami itu, program correction menjadi lebih presisi.

Satu tambahan yang sering terlewat adalah ownership perubahan. Kalau harga berubah karena commerce team, alamat berubah karena operations, dan service berubah karena product owner, masing-masing perubahan perlu trigger untuk memperbarui surface publik. Tanpa workflow itu, tim AI trust hanya menjadi pemadam kebakaran setelah error ditemukan. Lebih efisien jika perubahan fakta kritis otomatis memicu review terhadap website, feed, profile, directory, dan dokumen yang masih aktif.

Tujuannya bukan membuat AI tidak pernah salah.

Tujuannya membuat organisasi tahu ketika jawaban salah, tahu mengapa mungkin salah, tahu fakta yang benar, tahu siapa owner-nya, dan punya jalur koreksi yang bisa diuji.

Itu jauh lebih dekat ke trust engineering daripada sekadar mengeluh bahwa “AI ngarang lagi”.