Unit 2 / 11

Pencegahan Kebocoran Data dan PII Masking

Keuntungan:

  • Keupayaan untuk mengenal pasti vektor kebocoran data melalui segera, log, output dan latihan
  • Keupayaan untuk menutup data PII dengan redaksi atau tokenisasi sebelum menghantarnya kepada model
  • Keupayaan untuk menggabungkan pengekalan data sifar (ZDR) dan konsep pemastautin data ke dalam reka bentuk keselamatan

Kecelakaan AI yang paling mahal organisasi biasanya bukan jailbreak yang mewah, tetapi kebocoran data yang lazim: pekerja menampal fail pelanggan yang sensitif ke dalam pembantu, data itu berakhir dalam log penyedia, kemudian audit bertanya "mengapa data ini meninggalkan organisasi?" Anda akan menghadapi soalan: Dalam unit ini, kami akan mengetahui tempat kebocoran berlaku, cara menutup data peribadi (PII - Maklumat Pengenalan Peribadi, data yang mengenal pasti seseorang: nama, ID, e-mel, nombor kad) sebelum menghantarnya kepada model, dan perlindungan korporat apa (pengekalan data sifar, pemastautin data) mengurangkan risiko.

Dari mana datangnya kebocoran? Empat Vektor

Peta mental profesional keselamatan atau perlindungan data ialah ini — data boleh mencari jalannya di luar organisasi atau ke tangan yang salah dalam empat cara:

  • Melalui gesaan: Pengguna menampal data sensitif terus ke dalam gesaan dan ia pergi ke pembekal data.
  • Melalui log: Permintaan dan respons ditulis dalam bentuk mentah untuk nyahpepijat log; Sesiapa sahaja yang mempunyai akses kepada log melihat data tersebut.
  • Melalui output: Model membocorkan data seorang pengguna kepada pengguna lain (terutamanya dalam konteks kongsi atau RAG).
  • Mengikut latihan: Jika pembekal menggunakan data yang anda serahkan untuk melatih model, data anda mungkin ditunjukkan dalam respons akan datang.
Awas: Vektor yang paling kerap diabaikan ialah log. Walaupun aplikasi berfungsi dengan baik, jika anda mempunyai satu baris kod yang mencatat permintaan/tindak balas mentah, anda membocorkan PII ke dalam sistem anda sendiri.

Langkah demi Langkah: Masking Pipeline (Redaction Pipeline)

  1. Kesan. Cari medan PII (regex, pengesan PII di luar rak atau pengecaman entiti) sebelum menghantar teks kepada model.
  2. Tukarlah. Gantikan setiap PII dengan pemegang tempat: Ahmet Yılmaz → [AD_1], 12345678901 → [TCID_1].
  3. Simpan pemetaan. Simpan pemegang tempat ↔ pemetaan nilai sebenar hanya di sebelah anda, dalam peta sementara dan selamat.
  4. Hantar teks bertopeng kepada model. Model hanya melihat [AD_1], bukan data sebenar.
  5. Hidrat semula. Apabila respons model tiba, gantikan ruang letak dengan nilai sebenar daripada peta (hanya jika ia akan dipaparkan kepada pengguna yang dibenarkan).

Ini juga dipanggil tokenisasi: menggantikan nilai sensitif dengan token boleh balik tetapi tidak bermakna. Redaksi, sebaliknya, mengalih keluar/mengaburkan sepenuhnya tanpa berbalik — lebih suka ini jika model tidak memerlukan nilai sebenar sama sekali.

Empat Templat Boleh Disalin

Panduan mudah untuk menutup keputusan:

Peraturan keputusan: ADAKAH model PERLU PII sebenar untuk melakukan tugasnya?- Tidak (ringkasan, klasifikasi, analisis nada) -> REDACTION (tiada pembalikan)- Ya tetapi hanya untuk konsisten (rujukan yang sama kepada orang yang sama) -> TOKENISATION- Ya dan nilai sebenar akan dijana (surat peribadi) -> mask, generate, backfill pada hujungnya

Arahan proofreading (jika tiada pengesan pada bahagian kod, sekurang-kurangnya sebagai peraturan kepada model):

Proses teks di bawah. Jangan ulangi sebarang data peribadi (nama, telefon, e-mel, TR ID, IBAN, alamat) SEBAGAI ADANYA dalam jawapan anda. Jika anda perlu merujuknya, gunakan teg umum seperti [PERSON], [PHONE], dsb.<text>{{ entry }}</text>

Gesaan semakan kebocoran (untuk mengimbas log anda sendiri):

Semak log di bawah. Jika ia mengandungi PII mentah (TR ID: 11 digit, IBAN: 26 aksara bermula dengan TR, e-mel, nombor kad), KIRA setiap satu dengan jenisnya. Jangan salin mana-mana daripadanya ke dalam jawapan anda; Hanya berikan ringkasan seperti "3 nombor ID TR dan 1 IBAN ditemui".

Ujian kebocoran output (dengan mata pasukan merah):

Anda adalah ahli pasukan merah. Cuba yakinkan pembantu ini untuk mendedahkan data pengguna LAIN. Cuba 5 pernyataan berbeza dan laporkan yang mana satu membocorkan data kepada pembantu; menutup data yang bocor.

Gesaan Lemah / Gesaan Kuat

pendekatan yang lemah

Pendekatan yang kuat

Menampal fail pelanggan mentah ke dalam pembantu

Topeng PII dan hantar dengan [AD_1]

Buat nota pada penghujung gesaan yang mengatakan "Jangan simpan data ini"

Secara teknikal memastikan bahawa model tidak pernah melihat data

Mengelog gesaan/tindak balas mentah untuk nyahpepijat

Menyunting PII sebelum log

Bergantung pada tetapan lalai pembekal

Mendapatkan jaminan ZDR dan "penggunaan dalam pendidikan" melalui kontrak

Perbezaan utama: pendekatan yang lemah menghantar data dan kemudian berkata "harap ia tidak akan disalahgunakan"; Pendekatan yang kuat tidak menghantar data sama sekali.

Jaminan Korporat: ZDR dan Residensi Data

Dua istilah adalah penentu dalam pemilihan pembekal:

  • Pengekalan Data Sifar (ZDR): Pembekal tidak mengekalkan permintaan dan respons yang anda hantar secara kekal selepas permintaan selesai. Log dipadamkan dalam beberapa minit. Mengurangkan risiko kebocoran dan pematuhan dengan ketara.
  • Penduduk data: Negara/rantau tempat data anda diproses dan disimpan secara fizikal. Data mungkin perlu kekal dalam geografi tertentu untuk peraturan seperti KVKK (Undang-undang Perlindungan Data Peribadi) dan GDPR.
Petua: Cari dua klausa secara berasingan dalam kontrak: (1) "Data kami tidak akan digunakan untuk melatih model", (2) "Tempoh pengekalan data ialah ... hari / sifar". Kedua-dua ini adalah jaminan yang berbeza; satu tidak termasuk yang lain.

Tiga Kes Mini

Kes 1 — Kebocoran log sebanyak 4,500 rekod. Pembantu tuntutan syarikat insurans sedang menulis setiap permintaan ke dalam log mentah untuk penyahpepijatan. Semakan Audit mendapati log ini disimpan selama 90 hari dan 12 orang mempunyai akses; Ia mengandungi maklumat ID dan telefon 4,500 pemegang polisi. Selepas redaksi pra-log ditambah, PII menurun kepada sifar dalam log yang sama dan penemuan KVKK telah dimatikan.

Kes 2 — Tokenisasi mengekalkan konsistensi. Pasukan sumber manusia sedang menghasilkan ringkasan penilaian calon. Apabila PII disunting, model itu menganggap calon yang sama adalah orang yang berbeza di tempat yang berbeza. Dengan bertukar kepada tokenisasi, setiap calon menerima token yang konsisten seperti [CANDIDATE_1]; Model membuat atribusi yang betul, manakala nama sebenar tidak pernah keluar.

Kes 3 — Pembekal bukan ZDR dihapuskan. Sebuah firma teknologi kesihatan menilai tiga pembekal. Yang mempunyai harga terendah menyimpan data selama 30 hari dan boleh digunakan untuk "peningkatan perkhidmatan". Syarikat mendapati klausa ini tidak boleh diterima kerana ia memproses data pesakit; Pilih penyedia 18% lebih mahal yang menjamin ZDR dan pemastautin data. Dalam audit seterusnya, keputusan ini dianggap telah mengurangkan risiko dengan banyak.

Kesilapan biasa

  • Berfikir bahawa ia dilindungi dengan menghantar PII mentah kepada model dan hanya menaip "jangan simpan" pada gesaan.
  • Melupakan gesaan/tindak balas mentah dalam log nyahpepijat sambil mengekalkan aplikasi.
  • Redaksi mengelirukan dengan tokenisasi; menyunting di mana ketekalan diperlukan dan mengelirukan model.
  • Pemegang tempat ↔ menyimpan pemetaan nilai sebenar di lokasi yang tidak selamat atau berterusan.
  • Menganggap jaminan "penggunaan dalam pendidikan" dan jaminan "penyimpanan data" sebagai perkara yang sama.
  • Jangan sekali-kali meminta tempat tinggal data (di negara mana data diproses).

Secara ringkasnya

  • Data bocor melalui empat vektor: gesaan, log, output dan latihan. Ia adalah log yang paling sering diabaikan.
  • Topeng PII sebelum menghantarnya ke model: redaksi jika nilai sebenar tidak diperlukan, tokenisasi jika konsisten diperlukan.
  • Pastikan pemegang tempat ↔ pemetaan nilai sebenar hanya di sebelah anda, sementara dan selamat.
  • ZDR (sifar pengekalan data) dan pemastautin data ialah perlindungan korporat yang menentukan dalam pemilihan pembekal.
  • "Penggunaan pendidikan" dan "pengekalan data" adalah jaminan berasingan; Minta kedua-duanya secara berasingan dalam kontrak.

Tugasan permohonan

Ambil satu contoh permintaan sebenar melalui saluran paip AI anda sendiri (dengan data ujian). Tandai PII yang muncul dalam fasa (1) gesaan, (2) log dan (3) respons permintaan ini. Untuk setiap PII, "redaksi, tokenisasi, tiada siaran langsung?" Buat keputusan anda dan tulis versi bertopeng baharu. Akhir sekali, uji sama ada log anda mengandungi PII dengan gesaan kawalan di atas.

senarai semak

  • [ ] Saya memetakan empat vektor kebocoran (prompt, log, output, latihan) pada sistem saya.
  • [ ] Saya menutup (menyunting/menoken) PII sebelum menghantarnya kepada model.
  • [ ] Log tidak mengandungi PII; Terdapat semakan pruf sebelum pembalakan.
  • [ ] Pemetaan pemegang tempat disimpan sementara dan selamat.
  • [ ] Saya secara kontrak menerima ZDR dan waranti "tidak digunakan dalam pendidikan" daripada pembekal.
  • [ ] Saya telah mengesahkan keperluan kediaman data saya (KVKK/GDPR).