Pada Februari 2024, tribunal sengketa sipil di British Columbia memerintahkan Air Canada membayar CAD 812 kepada seorang pelanggan. Pelanggan itu mengikuti saran chatbot maskapai untuk membeli tiket penuh lebih dulu, lalu mengajukan refund tarif duka dalam 90 hari. Kebijakan maskapai sendiri tidak mengizinkan pengajuan retroaktif (Moffatt v. Air Canada, 2024 BCCRT 149). Chatbot itu hanya menjawab pertanyaan. Agen yang sedang Anda evaluasi hari ini mungkin bisa menerbitkan refund atau menutup tiket sendiri, sehingga kesalahan fakta yang sama akan langsung menjadi transaksi.
Artikel ini membahas tiga hal. Pertama, kenapa retrieval-augmented generation (RAG) belum cukup untuk agen yang bertindak. Kedua, apa yang ditambahkan knowledge graph. Ketiga, apa yang perlu ditanyakan ke vendor sebelum agen diberi hak menulis ke sistem Anda.
MASALAH
Kenapa Agen Yang Sudah Memakai RAG Masih Salah Menyebut Fakta
RAG mengurangi kesalahan dan tidak menghapusnya. Retrieval mengambil potongan teks yang paling mirip dengan pertanyaan, dan kemiripan teks belum menjamin potongan itu benar, masih berlaku, atau lengkap untuk kasus yang sedang ditangani.
Buktinya sudah diukur. Peneliti Stanford RegLab dan HAI menguji alat riset hukum komersial yang dipasarkan dengan klaim bahwa RAG mencegah halusinasi. Hasilnya, Lexis+ AI memberi informasi keliru pada lebih dari 17 persen kueri uji, dan Westlaw AI-Assisted Research pada sekitar sepertiga kueri (Magesh dkk., 2024). Alat-alat itu jauh lebih baik daripada model umum tanpa retrieval. Meski begitu, kesalahannya masih terlalu sering untuk dibiarkan bertindak sendiri.
Di sistem perusahaan, kegagalannya biasanya jatuh ke salah satu dari empat pola. Pertama, versi: kebijakan refund tahun 2023 dan revisi tahun 2025 sama-sama ada di indeks, lalu potongan lama yang terambil karena kalimatnya lebih mirip dengan pertanyaan. Kedua, relasi: tier pelanggan ada di CRM, batas refund ada di PDF kebijakan, dan pengecualian ada di email persetujuan manajer. Retrieval membawa ketiga potongan itu tanpa hubungan di antaranya. Ketiga, ekstraksi: OCR salah membaca dokumen hasil pindai, satu digit nominal bergeser, atau metadata tanggal keliru, lalu retrieval dengan setia mengembalikan teks yang salah. Keempat, celah: ketika konteks yang diambil tidak memuat jawabannya, model tetap menulis kalimat yang terdengar meyakinkan.
MEKANISME
Apa Yang Ditambahkan Knowledge Graph Di Atas Retrieval
Knowledge graph menyimpan fakta sebagai entitas dan hubungan yang eksplisit, misalnya pelanggan, pesanan, produk, kebijakan, dan tanggal berlakunya. Dengan begitu agen menelusuri jawaban lewat jalur yang bisa diperiksa satu per satu. Retrieval teks tetap dipakai untuk konteks dan penjelasan, sementara graph menjawab pertanyaan yang hanya punya satu jawaban benar.
Ambil contoh pertanyaan “Apakah pesanan 4471 berhak refund?” Lewat graph, agen berjalan dari pesanan 4471 ke tanggal pembelian, lalu ke kategori produk, ke versi kebijakan refund yang berlaku pada tanggal itu, dan akhirnya ke batas hari dalam kebijakan tersebut. Setiap langkah adalah satu record dengan sumber yang tercatat. Kalau satu langkah kosong, misalnya kategori produk belum dipetakan, agen berhenti dan melaporkan data mana yang hilang. Perilaku itu bisa diuji, dan itulah yang Anda butuhkan sebelum agen menyentuh uang.
Knowledge graph juga punya batas yang perlu diakui. Graph hanya seakurat pipeline yang mengisinya, jadi kesalahan OCR yang masuk ke graph tetap menjadi kesalahan. Skemanya butuh waktu untuk dirancang, dan graph harus terus sinkron dengan ERP dan CRM yang datanya selalu berubah. Untuk pekerjaan terbuka seperti meringkas kontrak 80 halaman, manfaat graph kecil dan retrieval biasa sering sudah memadai. Graph paling berguna untuk keputusan yang bergantung pada aturan, versi, dan relasi antar record. Itu persis jenis keputusan yang diambil agen ketika menerbitkan refund atau menutup tiket.
RISIKO
Ketika Agen Bertindak, Satu Fakta Salah Menjadi Kewajiban Perusahaan
Begitu agen bisa menulis ke sistem, soal akurasi berubah menjadi soal tata kelola: siapa yang memverifikasi fakta sebelum tindakan dieksekusi, dan siapa yang menanggung akibatnya. Untuk pertanyaan kedua, tribunal dalam kasus Air Canada sudah menjawab: perusahaan.
Air Canada berargumen bahwa chatbot adalah entitas terpisah yang bertanggung jawab atas tindakannya sendiri. Tribunal menolak argumen itu. Menurut tribunal, chatbot hanyalah bagian dari situs web maskapai, sehingga perusahaan bertanggung jawab atas semua informasi di situs tersebut, baik dari halaman statis maupun dari chatbot.
Regulator di pasar yang Anda layani bergerak ke arah yang sama. Di Singapura, IMDA meluncurkan Model AI Governance Framework for Agentic AI pada 22 Januari 2026. Kerangka itu punya empat dimensi: membatasi risiko sejak awal, menjadikan manusia akuntabel secara bermakna, menerapkan kendali teknis, dan memampukan pengguna akhir untuk bertanggung jawab (Bird & Bird). Di Inggris, Data (Use and Access) Act 2025 menyisipkan Pasal 22C ke UK GDPR (Section 80). Pasal itu mewajibkan pengaman untuk keputusan signifikan yang sepenuhnya otomatis, yaitu informasi tentang keputusan, kesempatan menyampaikan keberatan, akses ke intervensi manusia, dan hak untuk menggugat keputusan. Penolakan refund kepada seorang individu bisa masuk kategori itu, dan tim hukum Anda yang perlu menilainya.
KENDALI
Tiga Lapis Kendali Sebelum Agen Boleh Menulis
Agen bisa bertindak dengan aman bila tiga lapis kendali bekerja bersamaan: fakta yang bisa ditelusuri, aturan bisnis yang dicek oleh kode, dan persetujuan manusia sebelum penulisan. Satu lapis saja tidak cukup, karena masing-masing menangkap jenis kesalahan yang berbeda.
Setiap Fakta Punya Sumber
Setiap angka dan status yang dipakai agen dalam keputusan harus menunjuk ke record atau dokumen asalnya, lengkap dengan versi dan tanggal. Dengan begitu peninjau bisa memeriksa dasar keputusan dalam hitungan detik, dan auditor bisa merekonstruksinya enam bulan kemudian.
Aturan Bisnis Dicek Oleh Kode
Batas refund, tier pelanggan, dan otorisasi nominal sebaiknya dievaluasi oleh kode deterministik yang membaca graph atau database. Model bahasa menyusun usulan beserta penjelasannya, lalu kode memutuskan apakah usulan itu lolos aturan.
Manusia Menyetujui Setiap Penulisan
Agen menyiapkan transaksi, lalu seorang petugas memeriksa sumber dan hasil pengecekan aturan sebelum menekan tombol komit. Gerbang ini harus menjadi bagian dari arsitektur sistem, sehingga tidak ada pengaturan yang bisa mematikannya ketika antrean sedang panjang.
EVALUASI VENDOR
Pertanyaan Untuk Vendor Sebelum Agen Menyentuh Sistem Produksi
Minta vendor menjawab enam pertanyaan berikut secara tertulis, dengan bukti dari data Anda sendiri. Jawaban yang hanya mengutip benchmark publik tidak memberi tahu apa pun tentang dokumen dan sistem Anda.
| Pertanyaan | Jawaban Yang Layak Diterima | Tanda Bahaya |
|---|---|---|
| Berapa tingkat kesalahan pada set uji dari data kami? | Angka terukur dari, misalnya, 200 pertanyaan yang jawabannya sudah diketahui | Hanya angka dari benchmark publik |
| Bagaimana agen menangani dua versi kebijakan yang bertentangan? | Versi dan tanggal berlaku disimpan sebagai data, dan agen memilih berdasarkan tanggal transaksi | “Model akan memilih yang paling relevan” |
| Apa yang terjadi bila data yang dibutuhkan tidak ditemukan? | Agen berhenti dan menyebut data yang hilang | Agen tetap memberi jawaban |
| Operasi tulis mana yang bisa dieksekusi tanpa persetujuan? | Tidak ada | Ada mode otonom yang bisa diaktifkan |
| Di mana dokumen, indeks, dan inferensi berjalan? | Di infrastruktur Anda, atau di instans single-tenant di region pilihan Anda | Endpoint pihak ketiga yang tidak disebutkan |
| Apa yang dicatat untuk setiap tindakan? | Usulan, sumber, hasil pengecekan aturan, penyetuju, dan waktu | Hanya log percakapan |
Jika vendor tidak bisa menunjukkan perilaku “berhenti dan melapor” dalam demo dengan data Anda, anggap kemampuan itu belum ada.
ARSA
Cara ARSA Membangun Agen Yang Diizinkan Bertindak
ARSA membangun sistem RAG privat dan alur kerja agen yang berjalan di infrastruktur pelanggan, dengan gerbang persetujuan manusia pada setiap operasi tulis. Agen menyiapkan transaksi, lalu seorang petugas mengomitnya. Gerbang itu tertanam di arsitektur, sehingga tidak bisa dimatikan lewat pengaturan.
Pipeline yang dibangun ARSA berjalan dari korpus dokumen ke embedding, lalu ke vector store lokal, model, gerbang persetujuan, dan akhirnya sistem tujuan. Sistem bisa ditempatkan on-premise, air-gapped, atau sebagai instans single-tenant di region pilihan Anda, dan tidak ada dokumen yang dikirim ke API eksternal. ARSA memakai model open-weight berlisensi permisif yang dipilih untuk tiap beban kerja. Konektor Model Context Protocol (MCP) menghubungkan agen ke ERP, CRM, sistem ticketing, dan sistem manajemen dokumen yang sudah Anda jalankan, termasuk bila model dan perangkat kerasnya tidak dipasok ARSA.
Untuk organisasi yang menginginkan sistem tertutup di rak sendiri, ada ARSA Sovereign, yang saat ini masih dalam tahap pilot. Prinsipnya sama: konektor ke Odoo, SAP, dan Zoho bersifat read-only secara default, setiap penulisan ke ERP menunggu persetujuan eksplisit, dan tidak ada mode tulis otonom yang bisa diaktifkan.
Halaman layanan ARSA tidak menjanjikan angka akurasi tertentu, dan Anda sebaiknya curiga pada vendor yang menjanjikan angka itu sebelum melihat data Anda. Apakah sebuah alur kerja membutuhkan knowledge graph di atas retrieval, atau retrieval biasa sudah cukup, adalah pertanyaan yang tepat untuk dibawa ke feasibility assessment. Ada tiga alasan umum untuk pindah dari API cloud: residensi data, biaya pada skala besar, dan risiko model dihentikan oleh vendornya. Bila tidak satu pun berlaku untuk Anda, ARSA akan mengatakan bahwa cloud tetap pilihan yang wajar. Untuk sisi residensi data pada integrasi agen, lihat juga pembahasan kami tentang integrasi AI agent dan lokalisasi data.
| Tahap | Mulai Dari | Durasi | Hasil |
|---|---|---|---|
| Feasibility assessment | $4,500 | 2 minggu | Diagnosis operasional, penilaian kelayakan teknis terhadap data dan infrastruktur Anda, model biaya |
| Pilot deployment | $20,000 | 8 minggu | Sistem yang berjalan pada lingkup terbatas |
| Production programme | $60,000 sampai $300,000+ | 12 minggu ke atas | Deployment penuh dengan integrasi |
Biaya feasibility assessment dipotong dari nilai proyek bila kontrak ditandatangani dalam 90 hari. Harga yang tercantum adalah harga daftar internasional dalam USD, dan invoice tersedia dalam USD atau EUR. Rincian semua tahap ada di halaman layanan ARSA.
FAQ
Pertanyaan Yang Sering Diajukan
Apakah RAG Menghilangkan Halusinasi Pada AI Agent?
Tidak. RAG menurunkan tingkat kesalahan, tetapi tidak menghapusnya. Studi Stanford tahun 2024 menemukan bahwa alat riset hukum berbasis RAG masih salah pada 17 persen hingga sekitar sepertiga kueri uji, karena retrieval bisa mengambil potongan yang usang, tidak lengkap, atau salah diekstrak.
Kapan Knowledge Graph Layak Ditambahkan Ke RAG?
Knowledge graph layak ditambahkan ketika keputusan agen bergantung pada relasi antar record, versi kebijakan, dan tanggal berlaku, seperti kelayakan refund atau eskalasi tiket. Untuk meringkas dokumen atau menjawab pertanyaan terbuka, retrieval biasa sering sudah cukup, dan biaya membangun serta merawat graph tidak sebanding dengan manfaatnya.
Apa Yang Harus Ditanyakan Ke Vendor Sebelum Agen Boleh Menerbitkan Refund?
Tanyakan tingkat kesalahan pada set uji dari data Anda, apa yang dilakukan agen ketika data tidak ditemukan, dan operasi tulis mana yang bisa berjalan tanpa persetujuan manusia. Jawaban yang aman untuk pertanyaan terakhir adalah “tidak ada”, karena perusahaan tetap menanggung akibat tindakan agen, seperti yang diputuskan dalam kasus Air Canada.
Bisakah RAG Dan Knowledge Graph Dijalankan On-Premises?
Bisa. Retrieval, indeks, graph, dan inferensi semuanya dapat berjalan di server milik Anda atau di jaringan air-gapped. ARSA membangun RAG privat dengan vector store lokal dan model open-weight, tanpa ada dokumen yang dikirim ke API eksternal.
Siapa Yang Bertanggung Jawab Jika AI Agent Mengambil Tindakan Yang Salah?
Organisasi yang menjalankan agen tetap bertanggung jawab. Tribunal di British Columbia memperlakukan chatbot Air Canada sebagai bagian dari situs web maskapai, dan kerangka agentic AI dari IMDA Singapura menegaskan bahwa manusia harus tetap akuntabel atas tindakan yang diambil agen.
Berapa Biaya Memulai Proyek AI Agent Dengan ARSA?
Proyek dimulai dengan feasibility assessment seharga $4,500 selama dua minggu, dan biaya ini dipotong dari nilai proyek bila kontrak ditandatangani dalam 90 hari. Pilot deployment mulai dari $20,000 untuk delapan minggu.
LANGKAH BERIKUTNYA
Uji Agen Anda Dengan Data Anda Sendiri
Sebelum agen diberi hak menulis ke sistem yang memindahkan uang atau menutup kasus pelanggan, Anda perlu tahu seberapa sering agen itu salah pada dokumen Anda dan apa yang terjadi ketika ia salah. Feasibility assessment ARSA menjawab kedua pertanyaan itu dalam dua minggu. Bila hasilnya menunjukkan proyek tidak layak, ARSA akan merekomendasikan untuk tidak membangunnya.
Pelajari LLM And AI Agent Development dari ARSA atau hubungi tim kami.