RAG Data Leak: Dokumen Internal Bisa Bocor Lewat Chatbot AI

Banyak perusahaan kini memasang chatbot AI yang "pintar" karena menjawab dari dokumen internal: kontrak, kebijakan HR, SOP, sampai data pelanggan. Tekniknya disebut RAG (Retrieval-Augmented Generation) — model mengambil potongan dokumen yang relevan, lalu merangkainya menjadi jawaban. Masalahnya: sistem retrieval umumnya tidak tahu siapa yang bertanya. Akibatnya, dokumen yang hanya boleh dibaca tim tertentu bisa ikut terambil dan dijawab ke orang yang tidak berhak. Ini yang disebut RAG data leak, dan artikel ini menjelaskan kenapa terjadi serta cara mencegahnya.

Kenapa RAG bisa "bocor" padahal bukan diserang?

RAG data leak sering terjadi bukan karena serangan, tapi karena desain yang tidak memisahkan hak akses di level data. Alurnya kurang lebih begini:

1. Tim memasukkan semua dokumen (termasuk yang sensitif) ke satu basis pengetahuan agar chatbot makin berguna.
2. Saat user bertanya, sistem mencari potongan dokumen yang paling mirip pertanyaan — tanpa memeriksa apakah user berhak membaca dokumen itu.
3. Model menjawab dari potongan tersebut. Dokumen internal yang sensitif pun keluar sebagai jawaban biasa.

Contoh nyata dalam keseharian

• Chatbot HR: karyawan bertanya "berapa kisaran gaji level senior?" — sistem mengambil potongan dari dokumen penggajian internal yang seharusnya hanya untuk tim HR, lalu menjawab dengan angka nyata.
• Chatbot customer support: pelanggan bertanya tentang kebijakan diskon internal atau margin — jawaban diambil dari SOP rahasia perusahaan, bukan dari halaman publik.
• Chatbot legal/kontrak: pihak eksternal bertanya soal syarat kontrak tertentu, dan sistem merangkum dari dokumen kontrak yang hanya boleh dibaca divisi legal.

Dalam semua kasus di atas, tidak ada peretasan. User hanya bertanya dengan kata-kata yang cocok dengan isi dokumen sensitif — dan sistem dengan patuh menjawab.

Bedanya dengan prompt injection

Jangan tertukar dengan indirect prompt injection (di mana penyerang menyisipkan instruksi jahat di dokumen agar model bertindak di luar batas). RAG data leak tidak butuh instruksi jahat — cukup pertanyaan polos yang secara tidak sengaja cocok dengan dokumen sensitif. Keduanya sama-sama berbahaya, tapi akar masalahnya berbeda: injection menyerang instruksi, data leak menyerang kontrol akses data.

Cara mencegah (5 lapisan)

1. Klasifikasi dokumen sejak awal: tandai tingkat sensitivitas (publik / internal / rahasia) sebelum dokumen masuk ke basis pengetahuan.
2. Filter hak akses saat retrieval: sistem harus tahu peran user (mis. dari token login) dan hanya mencari di dokumen yang boleh dia baca — bukan menyaring setelah jawaban jadi.
3. Pisahkan index berdasarkan sensitivitas: jangan campur dokumen publik dan rahasia dalam satu vector store. Index terpisah + routing berdasarkan peran lebih aman daripada satu kolam besar.
4. Jangan pernah memasukkan data yang tidak boleh keluar: aturan praktis — kalau dokumen tidak boleh dilihat semua karyawan, pertimbangkan ulang apakah perlu masuk chatbot.
5. Validasi & audit jawaban: catat dokumen sumber mana yang dipakai menjawab (citation), dan audit log retrieval untuk mendeteksi pola mencurigakan (mis. satu user sering memicu dokumen di luar perannya).

Prinsip di balik semuanya: retrieval harus menghormati hak akses yang sama seperti saat user membuka file di sistem internal. Kalau user tidak bisa membuka file di folder, dia juga tidak boleh mendapat isinya lewat chatbot.

Bagaimana mengujinya?

RAG data leak bisa diuji dengan red-team khusus RAG: buat skenario "cross-user isolation" — user dengan peran terbatas mencoba memancing dokumen di luar haknya (bertanya langsung, menyamar sebagai peran lain, meminta ringkasan dokumen tertentu, dan variasi kata-kata lain). Jika sistem menjawab dari dokumen terlarang, itu temuan. Di AISG, pengujian lapisan RAG mencakup retrieval leakage, cross-user data isolation, dan citation fabrication — hasilnya dilaporkan sebagai temuan yang bisa ditindaklanjuti, bukan sekadar peringatan umum.

Kesimpulan

RAG membuat chatbot berguna, tapi juga mengaburkan batas akses yang selama ini dijaga folder dan permission file. Data leak terjadi bukan karena model "nakal", melainkan karena sistem retrieval memperlakukan semua dokumen sama. Solusinya ada di desain: klasifikasi dokumen, filter hak akses di retrieval, index terpisah, dan pengujian isolasi antar-pengguna secara rutin. Chatbot yang aman bukan yang paling pintar menjawab — tapi yang tahu kapan harus menolak menjawab.