Keuntungan:
- Kemampuan untuk mengidentifikasi vektor kebocoran data melalui prompt, log, output, dan pelatihan
- Kemampuan untuk menutupi data PII dengan redaksi atau tokenisasi sebelum mengirimkannya ke model
- Kemampuan untuk menggabungkan konsep nihil retensi data (ZDR) dan residensi data ke dalam desain keamanan
Kecelakaan AI yang paling merugikan dalam suatu organisasi biasanya bukanlah jailbreak yang mewah, namun kebocoran data biasa: seorang karyawan menempelkan file sensitif pelanggan ke asisten, data tersebut berakhir di log penyedia, lalu audit menanyakan "mengapa data ini meninggalkan organisasi?" Anda akan menghadapi pertanyaan: Dalam unit ini, kita akan mempelajari di mana kebocoran terjadi, cara menutupi data pribadi (PII - Informasi Identifikasi Pribadi, data yang mengidentifikasi seseorang: nama, ID, email, nomor kartu) sebelum mengirimkannya ke model, dan perlindungan perusahaan apa (tanpa retensi data, residensi data) yang mengurangi risiko.
Sumber kebocorannya dari mana? Empat Vektor
Peta mental seorang profesional keamanan atau perlindungan data adalah sebagai berikut — data dapat menyebar ke luar organisasi atau ke tangan yang salah melalui empat cara:
- Melalui prompt: Pengguna menempelkan data sensitif langsung ke prompt dan data tersebut masuk ke penyedia data.
- Melalui log: Permintaan dan tanggapan ditulis dalam bentuk mentah untuk men-debug log; Siapa pun yang memiliki akses ke log akan melihat datanya.
- Melalui keluaran: Model membocorkan data satu pengguna ke pengguna lain (terutama dalam konteks bersama atau RAG).
- Dengan pelatihan: Jika penyedia menggunakan data yang Anda kirimkan untuk melatih model, data Anda mungkin tercermin dalam respons di masa mendatang.
Perhatian: Vektor yang paling sering diabaikan adalah log. Meskipun aplikasi berfungsi dengan baik, jika Anda memiliki satu baris kode yang mencatat permintaan/respons mentah, Anda membocorkan PII ke sistem Anda sendiri.
Langkah demi Langkah: Masking Pipeline (Saluran Redaksi)
- Deteksi. Temukan bidang PII (regex, detektor PII siap pakai, atau pengenalan entitas) sebelum mengirim teks ke model.
- Ubah itu. Ganti setiap PII dengan placeholder: Ahmet Yılmaz → [AD_1], 12345678901 → [TCID_1].
- Simpan pemetaannya. Simpan placeholder ↔ pemetaan nilai aktual hanya di sisi Anda, dalam peta sementara dan aman.
- Kirim teks bertopeng ke model. Model hanya melihat [AD_1], tidak pernah melihat data sebenarnya.
- Rehidrasi. Saat respons model tiba, ganti placeholder dengan nilai aktual dari peta (hanya jika akan ditampilkan kepada pengguna yang berwenang).
Ini juga disebut tokenisasi: mengganti nilai sensitif dengan token yang dapat dibalik namun tidak berarti. Sebaliknya, redaksi menghilangkan/mengaburkan seluruhnya tanpa mengembalikannya — lebih baik melakukan ini jika model tidak memerlukan nilai sebenarnya sama sekali.
Empat Templat yang Dapat Disalin
Panduan sederhana untuk menutupi keputusan:
Aturan pengambilan keputusan: APAKAH model MEMBUTUHKAN PII nyata untuk melakukan tugasnya?- Tidak (peringkasan, klasifikasi, analisis nada) -> REDAKSI (tidak ada pembalikan)- Ya tetapi hanya untuk konsistensi (referensi yang sama ke orang yang sama) -> TOKENISASI- Ya dan nilai nyata akan dihasilkan (surat yang dipersonalisasi) -> mask, hasilkan, isi ulang pada akhirnya
Instruksi pengoreksian (jika tidak ada detektor di sisi kode, setidaknya sebagai aturan untuk model):
Proses teks di bawah ini. Jangan mengulangi data pribadi apa pun (nama, telepon, email, TR ID, IBAN, alamat) SEBAGAIMANA ADANYA dalam tanggapan Anda. Jika Anda perlu mereferensikannya, gunakan tag umum seperti [PERSON], [PHONE], dll.<text>{{ entry }}</text>
Perintah pemeriksaan kebocoran (untuk memindai log Anda sendiri):
Lihat log di bawah ini. Jika berisi PII mentah (TR ID: 11 digit, IBAN: 26 karakter dimulai dengan TR, email, nomor kartu), COUNT masing-masing dengan jenisnya. Jangan menyalin satupun dari jawaban Anda; Berikan ringkasan saja seperti "3 nomor TR ID dan 1 IBAN ditemukan".
Uji kebocoran keluaran (dengan mata tim merah):
Anda adalah anggota tim merah. Cobalah untuk meyakinkan asisten ini untuk mengungkapkan data pengguna LAIN. Coba 5 pernyataan berbeda dan laporkan mana yang membocorkan data ke asisten; menutupi data yang bocor.
Prompt Lemah / Prompt Kuat
pendekatan yang buruk
Pendekatan yang kuat
Menempelkan file klien mentah ke asisten
Tutupi PII dan kirim dengan [AD_1]
Buat catatan di akhir perintah yang mengatakan "Jangan simpan data ini"
Secara teknis memastikan bahwa model tidak pernah melihat data
Mencatat prompt/respons mentah untuk debug
Menyunting PII sebelum masuk
Mengandalkan pengaturan default penyedia
Memperoleh ZDR dan jaminan "penggunaan dalam pendidikan" berdasarkan kontrak
Perbedaan utama: pendekatan yang lemah mengirimkan data dan kemudian berkata "semoga tidak disalahgunakan"; Pendekatan kuat tidak mengirimkan data sama sekali.
Jaminan Perusahaan: ZDR dan Residensi Data
Ada dua hal yang menentukan dalam pemilihan pemasok:
- Zero Data Retention (ZDR): Penyedia tidak menyimpan secara permanen permintaan dan tanggapan yang Anda kirim setelah permintaan selesai. Log dihapus dalam beberapa menit. Secara signifikan mengurangi risiko kebocoran dan kepatuhan.
- Tempat tinggal data: Negara/wilayah tempat data Anda diproses dan disimpan secara fisik. Data mungkin perlu tetap berada di wilayah geografis tertentu untuk peraturan seperti KVKK (Undang-Undang Perlindungan Data Pribadi) dan GDPR.
Tip: Carilah dua klausul secara terpisah dalam kontrak: (1) "Data kami tidak akan digunakan untuk melatih model", (2) "Periode retensi data adalah ... hari / nol". Keduanya merupakan jaminan yang berbeda; yang satu tidak termasuk yang lain.
Tiga Kasus Mini
Kasus 1 — Kebocoran log sebanyak 4.500 catatan. Asisten klaim perusahaan asuransi menulis setiap permintaan ke dalam log mentah untuk proses debug. Audit menemukan bahwa log ini disimpan selama 90 hari dan 12 orang memiliki akses; Isinya informasi identitas dan telepon 4.500 pemegang polis. Setelah redaksi pra-log ditambahkan, PII turun menjadi nol di log yang sama dan temuan KVKK dimatikan.
Kasus 2 — Tokenisasi menjaga konsistensi. Tim sumber daya manusia sedang membuat ringkasan evaluasi kandidat. Saat PII disunting, model mengira calon yang sama adalah orang berbeda di tempat berbeda. Dengan beralih ke tokenisasi, setiap kandidat menerima token yang konsisten seperti [CANDIDATE_1]; Model tersebut membuat atribusi yang benar, sedangkan nama aslinya tidak pernah disebutkan.
Kasus 3 — Penyedia non-ZDR dihilangkan. Sebuah perusahaan teknologi kesehatan mengevaluasi tiga penyedia. Perusahaan dengan harga terendah menyimpan data selama 30 hari dan dapat digunakan untuk “peningkatan layanan”. Perusahaan menganggap klausul ini tidak dapat diterima karena perusahaan memproses data pasien; Pilih penyedia 18% lebih mahal yang menjamin ZDR dan residensi data. Pada audit selanjutnya, keputusan ini dianggap telah sangat mengurangi risiko.
Kesalahan umum
- Berpikir bahwa itu dilindungi dengan mengirimkan PII mentah ke model dan cukup mengetik "jangan simpan" saat diminta.
- Melupakan prompt/respons mentah di log debug sambil mempertahankan aplikasi.
- Membingungkan redaksi dengan tokenisasi; menyunting ketika konsistensi diperlukan dan menyesatkan model.
- Placeholder ↔ menyimpan pemetaan nilai aktual di lokasi yang tidak aman atau persisten.
- Salah mengartikan jaminan "penggunaan dalam pendidikan" dan jaminan "penyimpanan data" sebagai hal yang sama.
- Tidak pernah menanyakan data domisili (di negara mana data tersebut diproses).
Singkatnya
- Kebocoran data melalui empat vektor: prompt, log, output, dan pelatihan. Log inilah yang paling sering diabaikan.
- Tutupi PII sebelum mengirimkannya ke model: redaksi jika nilai sebenarnya tidak diperlukan, tokenisasi jika diperlukan konsistensi.
- Pertahankan placeholder ↔ pemetaan nilai aktual hanya di pihak Anda, sementara dan aman.
- ZDR (retensi data nol) dan residensi data adalah perlindungan perusahaan yang menentukan dalam pemilihan pemasok.
- "Penggunaan untuk tujuan pendidikan" dan "retensi data" merupakan jaminan terpisah; Mintalah keduanya secara terpisah dalam kontrak.
Tugas aplikasi
Ambil satu contoh permintaan nyata melalui jalur AI Anda sendiri (dengan data pengujian). Tandai PII mana yang muncul di fase (1) prompt, (2) log, dan (3) respons permintaan ini. Untuk setiap PII, “redaksi, tokenisasi, tidak ada postingan sama sekali?” Buat keputusan Anda dan tulis versi bertopeng yang baru. Terakhir, uji apakah log Anda berisi PII dengan perintah kontrol di atas.
daftar periksa
- [ ] Saya memetakan empat vektor kebocoran (prompt, log, output, training) di sistem saya.
- [ ] Saya menutupi (menyunting/mentokenisasi) PII sebelum mengirimkannya ke model.
- [ ] Log tidak mengandung PII; Ada proofreading sebelum login.
- [ ] Pemetaan placeholder disimpan sementara dan aman.
- [ ] Saya secara kontrak menerima ZDR dan garansi "tidak digunakan dalam pendidikan" dari penyedia.
- [ ] Saya telah memverifikasi persyaratan data tempat tinggal saya (KVKK/GDPR).