Knowledge base perusahaan sering mencampur informasi yang diperlukan untuk menjawab pertanyaan dengan identitas yang sebenarnya tidak perlu dibuka. Sebuah tiket dapat memuat langkah penyelesaian yang bermanfaat sekaligus nama pelanggan, nomor telepon, dan rincian komersial. Penyamaran data RAG perlu menjaga kegunaan konteks sambil membatasi data yang diteruskan ke indeks, model, jawaban, dan log.
Panduan ini ditujukan kepada AI product owner, data steward, serta tim keamanan yang menyiapkan pencarian pengetahuan bisnis. Masking bukan pengganti kontrol akses dan tidak menjamin anonimitas. Jika tugas memerlukan identitas asli, tentukan siapa yang berhak membukanya melalui sistem sumber; jangan otomatis memberikan tabel pemetaan kepada model.
Bedakan Penghapusan, Masking, dan Pseudonim
Penghapusan atau redaction menghilangkan bagian sensitif dari salinan yang diproses. Masking menyembunyikan sebagian nilai, misalnya beberapa digit nomor akun. Pseudonim mengganti identitas dengan token yang dapat ditautkan kembali melalui pemetaan terpisah. Istilah dan implementasinya perlu disepakati agar tim tidak menyebut data “anonim” hanya karena namanya diganti.
Konteks lain masih dapat mengungkap identitas: jabatan tunggal, lokasi kecil, tanggal kejadian, atau kombinasi nilai transaksi. Karena itu, keputusan penyamaran harus melihat isi dokumen dan tujuan penggunaannya. Mengganti nama tetapi mempertahankan seluruh petunjuk unik belum tentu mengurangi risiko dengan memadai.
Petakan Jalur Data sebelum Membuat Indeks
Daftarkan sumber dokumen, proses ekstraksi, pembentukan potongan teks, embedding, vector store, pencarian, prompt, keluaran, cache, log, dan ekspor analitik. Tentukan pada setiap titik apakah data mentah masuk, siapa yang dapat membacanya, dan berapa lama disimpan. Memeriksa jawaban akhir saja terlambat bila identitas sudah tersalin ke indeks atau log observability.
RAG membantu model mengambil konteks dari sumber yang dipilih. RAG bukan agent secara otomatis; pencarian dan pembentukan jawaban dapat berjalan dalam alur tetap. Jika agent memilih alat dan sumber secara dinamis, jalur datanya justru perlu dipetakan lebih luas. Evaluasi hak akses dokumen RAG membahas batas izin; artikel ini memusatkan perhatian pada transformasi isi yang diteruskan.
Tentukan Kebijakan per Jenis Informasi
- Identitas langsung: nama, kontak, nomor identitas, serta nomor akun yang tidak diperlukan untuk tugas.
- Rahasia bisnis: harga khusus, margin, klausul pelanggan, dan informasi pengadaan yang dibatasi.
- Petunjuk tidak langsung: lokasi, jabatan, tanggal, serta kombinasi atribut yang terlalu spesifik.
- Rahasia teknis: token akses, kunci, kata sandi, dan rincian koneksi yang tidak seharusnya masuk knowledge base.
Pemilik data menetapkan tindakan: buang, generalisasi, tokenisasi, atau pertahankan dengan pembatasan. Kebijakan harus menyebut tujuan dan pengguna sasaran. Tim support mungkin memerlukan gejala teknis dan urutan perbaikan tanpa harga kontrak; account manager yang berwenang dapat memiliki kebutuhan berbeda melalui jalur sumber yang terlindungi.
Rancang Pipeline Penyamaran yang Dapat Diuji
Deteksi sebelum Pemotongan Dokumen
Periksa data sensitif sebelum teks dipecah menjadi chunk. Jika pola nomor terpotong di dua chunk, detektor yang hanya membaca satu potongan dapat melewatkannya. Gabungkan aturan deterministik untuk format yang dikenal dengan deteksi kontekstual yang dievaluasi. Hasil yang meragukan masuk review, bukan dianggap aman.
Pertahankan Hubungan yang Memang Dibutuhkan
Jika dua paragraf membahas pelanggan yang sama, token konsisten dapat membantu mempertahankan relasi. Namun konsistensi token lintas seluruh perusahaan juga meningkatkan kemampuan menghubungkan dokumen. Pilih ruang lingkup token sesuai kebutuhan, misalnya per kasus atau per koleksi, dan uji apakah penelusuran lintas konteks membuka informasi yang tidak semestinya.
Pisahkan Pemetaan dari Konteks Model
Simpan tabel pemetaan pada penyimpanan terpisah dengan hak akses yang sempit. Jangan memasukkannya ke vector store yang sama atau menambahkan alat pembuka identitas kepada semua pengguna. Jika pembukaan identitas diizinkan, jalankan melalui pemeriksaan kewenangan, tujuan, dan pencatatan audit; persetujuan tidak boleh berasal dari teks dokumen yang ditemukan.
Periksa Keluaran dan Jejak Operasional
Tambahkan pemeriksaan pada jawaban, log aplikasi, trace alat, cache, dan ekspor uji. Sistem bisa menyamarkan prompt tetapi mencatat masukan mentah pada jalur debug. Daftar komponen harus diperiksa bersama tim operasi. Desain lokal maupun cloud tetap memerlukan pembatasan akses; lokasi server saja bukan bukti privasi menyeluruh.
Ilustrasi: Pengetahuan Keluhan Tanpa Nama Pelanggan
Ini contoh sintetis, bukan data atau proyek pelanggan Layana. Dokumen awal berbunyi: “Rina dari Alfa melaporkan barang kurang; lakukan pemeriksaan bukti penerimaan.” Salinan untuk pencarian mengganti Rina menjadi PERSON_01 dan Alfa menjadi CUSTOMER_07, lalu mempertahankan gejala serta langkah pemeriksaan. Pertanyaan tentang prosedur dapat dijawab tanpa menyebut identitas.
Jika pertanyaannya “siapa pelanggan yang mengeluh”, aplikasi harus memeriksa tujuan dan izin melalui sistem sumber. Jangan menyuruh model menebak dari konteks lainnya. Contoh tersebut juga perlu diuji dengan nama yang salah eja, teks hasil OCR, lampiran tabel, dan identitas di nama file agar kebijakan tidak hanya bekerja pada satu kalimat rapi.
Ukur Kebocoran dan Hilangnya Kegunaan Bersamaan
Buat dataset uji sintetis dengan penanda identitas yang diketahui. Hitung data sensitif yang lolos per kategori, konteks yang tersamarkan berlebihan, ketepatan retrieval, kualitas jawaban, serta kebutuhan koreksi reviewer. Pisahkan pengujian detektor dari pengujian seluruh pipeline. Detektor yang baik tidak menutup risiko cache atau log yang salah konfigurasi.
Uji pengguna dengan hak akses berbeda serta pertanyaan yang mencoba menghubungkan beberapa dokumen. Lakukan pemeriksaan manual pada contoh gagal dan ambang yang disepakati pemilik risiko. Ukuran sampel dan cakupan harus dilaporkan; tidak ditemukannya kebocoran dalam pilot tidak membuktikan bahwa sistem mustahil membocorkan data.
OWASP membahas risiko pengungkapan informasi sensitif dan pentingnya pembatasan akses serta sumber data. Pembatasan di system prompt saja dapat tidak dipatuhi dan bukan pengganti kontrol aplikasi. Bila dokumen sumber diperbarui atau dicabut, selaraskan salinan yang telah disamarkan dengan mekanisme pembaruan knowledge base.
Siapkan Review Alur Data RAG
Mulai dengan satu koleksi dokumen, kebijakan klasifikasi, contoh pertanyaan, dan diagram aliran data yang tersedia. Layanan AI dan Machine Learning Layana menjadi jalur diskusi untuk kebutuhan RAG dan integrasinya. Petakan kebutuhan penyamaran bersama Layana sebelum menyepakati desain, lingkup pilot, dan bukti penerimaan. Hindari membawa dokumen sensitif mentah sebelum saluran dan kewenangan pemrosesan ditetapkan.