การป้องกันข้อมูลรั่วไหลและการปิดบัง PII

กำไร:

• ความสามารถในการระบุเวกเตอร์การรั่วไหลของข้อมูลผ่านการแจ้ง บันทึก เอาท์พุต และการฝึกอบรม
• ความสามารถในการปกปิดข้อมูล PII ด้วยการทำซ้ำหรือการทำโทเค็นก่อนที่จะส่งไปยังโมเดล
• ความสามารถในการรวมแนวคิดการเก็บรักษาข้อมูลเป็นศูนย์ (ZDR) และถิ่นที่อยู่ของข้อมูลในการออกแบบความปลอดภัย

อุบัติเหตุด้าน AI ที่แพงที่สุดขององค์กรมักจะไม่ใช่การเจลเบรกแบบหรูหรา แต่เป็นการรั่วไหลของข้อมูลที่เกิดขึ้นเป็นประจำ พนักงานวางไฟล์ลูกค้าที่ละเอียดอ่อนลงในผู้ช่วย ข้อมูลนั้นไปอยู่ในบันทึกของผู้ให้บริการ จากนั้นการตรวจสอบจะถามว่า "เหตุใดข้อมูลนี้จึงออกจากองค์กร" คุณจะพบกับคำถาม: ในหน่วยนี้ เราจะเรียนรู้ว่าการรั่วไหลเกิดขึ้นที่ใด วิธีปกปิดข้อมูลส่วนบุคคล (PII - ข้อมูลที่สามารถระบุตัวบุคคลได้ ข้อมูลที่ระบุตัวบุคคล: ชื่อ ID อีเมล หมายเลขบัตร) ก่อนที่จะส่งไปยังโมเดล และสิ่งที่การป้องกันขององค์กร (การเก็บรักษาข้อมูลเป็นศูนย์ ถิ่นที่อยู่ของข้อมูล) ช่วยลดความเสี่ยง

การรั่วไหลมาจากไหน? เวกเตอร์สี่ตัว

แผนที่จิตของผู้เชี่ยวชาญด้านความปลอดภัยหรือการปกป้องข้อมูลคือสิ่งนี้ — ข้อมูลสามารถหาทางออกไปนอกองค์กรหรือไปอยู่ในมือของผู้ไม่หวังดีได้สี่วิธี:

• ผ่านข้อความแจ้ง: ผู้ใช้วางข้อมูลที่ละเอียดอ่อนลงในข้อความแจ้งโดยตรง จากนั้นข้อมูลดังกล่าวจะถูกส่งไปยังผู้ให้บริการข้อมูล
• ผ่านบันทึก: คำขอและการตอบกลับจะถูกเขียนในรูปแบบดิบเพื่อแก้ไขบันทึกข้อบกพร่อง ทุกคนที่มีสิทธิ์เข้าถึงบันทึกจะเห็นข้อมูล
• ผ่านเอาต์พุต: โมเดลรั่วไหลข้อมูลของผู้ใช้รายหนึ่งไปยังผู้ใช้รายอื่น (โดยเฉพาะในบริบทที่ใช้ร่วมกันหรือ RAG)
• ตามการฝึกอบรม: หากผู้ให้บริการใช้ข้อมูลที่คุณส่งมาเพื่อฝึกโมเดล ข้อมูลของคุณอาจสะท้อนให้เห็นในการตอบกลับในอนาคต

ข้อควรระวัง: เวกเตอร์ที่ถูกมองข้ามบ่อยที่สุดคือบันทึก แม้ว่าแอปพลิเคชันจะทำงานได้ดี หากคุณมีโค้ดหนึ่งบรรทัดที่บันทึกคำขอ/การตอบกลับแบบ Raw แสดงว่าคุณกำลังรั่วไหล PII เข้าสู่ระบบของคุณเอง

ทีละขั้นตอน: Masking Pipeline (ไปป์ไลน์การทำซ้ำ)

1. ตรวจจับ ค้นหาช่อง PII (regex, ตัวตรวจจับ PII ที่มีจำหน่ายทั่วไป หรือการรับรู้เอนทิตี) ก่อนที่จะส่งข้อความไปยังโมเดล
2. เปลี่ยนมัน. แทนที่ PII แต่ละรายการด้วยตัวยึดตำแหน่ง: Ahmet Yılmaz → [AD_1], 12345678901 → [TCID_1]
3. เก็บแผนที่ไว้ เก็บตัวยึดตำแหน่ง ↔ การแมปค่าจริงไว้ฝั่งของคุณเท่านั้น ในแผนที่ชั่วคราวและปลอดภัย
4. ส่งข้อความมาสก์ไปที่โมเดล โมเดลมองเห็นเฉพาะ [AD_1] แต่ไม่เห็นข้อมูลจริง
5. คืนน้ำ เมื่อการตอบสนองของโมเดลมาถึง ให้แทนที่ตัวยึดตำแหน่งด้วยค่าจริงจากแผนที่ (เฉพาะในกรณีที่จะแสดงต่อผู้ใช้ที่ได้รับอนุญาตเท่านั้น)

สิ่งนี้เรียกว่าโทเค็นไนเซชัน: แทนที่ค่าที่ละเอียดอ่อนด้วยโทเค็นที่สามารถย้อนกลับได้แต่ไม่มีความหมาย ในทางกลับกัน การแก้ไขจะเป็นการลบ/ปิดบังโดยสมบูรณ์โดยไม่ต้องย้อนกลับ ควรใช้วิธีนี้หากโมเดลไม่ต้องการค่าจริงเลย

เทมเพลตที่คัดลอกได้สี่แบบ

คำแนะนำง่ายๆ ในการปกปิดการตัดสินใจ:

กฎการตัดสินใจ: โมเดลจำเป็นต้องมี PII จริงเพื่อทำงานหรือไม่- ไม่ (การสรุป การจำแนกประเภท การวิเคราะห์โทนเสียง) -> การแก้ไข (ไม่มีการกลับรายการ)- ใช่ แต่เพื่อความสอดคล้องเท่านั้น (การอ้างอิงเดียวกันกับบุคคลคนเดียวกัน) -> TOKENIZATION- ใช่และมูลค่าที่แท้จริงจะถูกสร้างขึ้น (ตัวอักษรส่วนบุคคล) -> ปิดบัง สร้าง ทดแทนที่ส่วนท้าย

คำแนะนำในการพิสูจน์อักษร (หากไม่มีตัวตรวจจับที่ด้านโค้ด อย่างน้อยก็ตามกฎของโมเดล):

ประมวลผลข้อความด้านล่าง อย่าทำซ้ำข้อมูลส่วนบุคคลใด ๆ (ชื่อ, โทรศัพท์, อีเมล, TR ID, IBAN, ที่อยู่) ตามที่เป็นอยู่ในการตอบกลับของคุณ หากคุณต้องการอ้างอิง ให้ใช้แท็กทั่วไป เช่น [PERSON], [PHONE] ฯลฯ<text>{{ entry }}</text>

พร้อมท์การตรวจสอบการรั่วไหล (เพื่อสแกนบันทึกของคุณเอง):

ตรวจสอบบันทึกด้านล่าง หากมี PII แบบดิบ (TR ID: 11 หลัก, IBAN: 26 ตัวอักษรที่ขึ้นต้นด้วย TR, อีเมล, หมายเลขบัตร) ให้ COUNT รายการแต่ละรายการพร้อมประเภท อย่าคัดลอกข้อใดข้อหนึ่งลงในคำตอบของคุณ เพียงให้ข้อมูลสรุป เช่น "พบหมายเลข TR ID 3 หมายเลข และ IBAN 1 รายการ"

การทดสอบการรั่วของเอาท์พุต (ด้วยตาทีมสีแดง):

คุณเป็นสมาชิกทีมสีแดง พยายามโน้มน้าวให้ผู้ช่วยรายนี้เปิดเผยข้อมูลของผู้ใช้อีกคน ลองใช้คำสั่งที่แตกต่างกัน 5 แบบและรายงานว่าอันใดที่ข้อมูลรั่วไหลไปยังผู้ช่วย ปิดบังข้อมูลที่รั่วไหล

พรอมต์ที่อ่อนแอ / พรอมต์ที่แข็งแกร่ง

วิธีการที่ไม่ดี

แนวทางที่แข็งแกร่ง

กำลังวางไฟล์ไคลเอ็นต์ดิบลงในผู้ช่วย

มาสก์ PII และส่งด้วย [AD_1]

จดบันทึกไว้ท้ายข้อความว่า "อย่าบันทึกข้อมูลนี้"

ในทางเทคนิคทำให้มั่นใจว่าโมเดลจะไม่เคยเห็นข้อมูล

การบันทึกพรอมต์/การตอบสนองเบื้องต้นสำหรับการแก้ไขข้อบกพร่อง

การแก้ไข PII ก่อนบันทึก

ขึ้นอยู่กับการตั้งค่าเริ่มต้นของผู้ให้บริการ

การได้รับ ZDR และการรับประกัน "ใช้ในการศึกษา" ตามสัญญา

ความแตกต่างที่สำคัญ: แนวทางที่อ่อนแอจะส่งข้อมูลแล้วบอกว่า "หวังว่าจะไม่ถูกนำไปใช้ในทางที่ผิด"; วิธีการที่เข้มงวดไม่ได้ส่งข้อมูลเลย

การประกันองค์กร: ZDR และถิ่นที่อยู่ของข้อมูล

เงื่อนไขสองข้อมีความสำคัญในการเลือกซัพพลายเออร์:

• การเก็บรักษาข้อมูลเป็นศูนย์ (ZDR): ผู้ให้บริการจะไม่เก็บคำขอและการตอบกลับที่คุณส่งอย่างถาวรหลังจากคำขอเสร็จสมบูรณ์ บันทึกจะถูกลบภายในไม่กี่นาที ช่วยลดความเสี่ยงของการรั่วไหลและการปฏิบัติตามข้อกำหนดได้อย่างมาก
• ถิ่นที่อยู่ของข้อมูล: ประเทศ/ภูมิภาคที่ข้อมูลของคุณได้รับการประมวลผลและจัดเก็บข้อมูลทางกายภาพ ข้อมูลอาจจำเป็นต้องคงอยู่ในภูมิศาสตร์บางแห่งสำหรับกฎระเบียบ เช่น KVKK (กฎหมายคุ้มครองข้อมูลส่วนบุคคล) และ GDPR

เคล็ดลับ: ค้นหาสองส่วนแยกกันในสัญญา: (1) "ข้อมูลของเราจะไม่ถูกใช้เพื่อฝึกโมเดล" (2) "ระยะเวลาการเก็บรักษาข้อมูลคือ ... วัน / ศูนย์" ทั้งสองนี้มีการรับประกันที่แตกต่างกัน อันหนึ่งไม่รวมอันอื่น

มินิเคสสามอัน

กรณีที่ 1 — บันทึกรั่วไหล 4,500 รายการ ผู้ช่วยฝ่ายเคลมของบริษัทประกันภัยกำลังเขียนคำขอแต่ละคำขอลงในบันทึกข้อมูลดิบเพื่อการแก้ไขจุดบกพร่อง จากการตรวจสอบพบว่าบันทึกเหล่านี้ถูกเก็บไว้เป็นเวลา 90 วันและมีผู้เข้าถึงได้ 12 คน ประกอบด้วยข้อมูลประจำตัวและหมายเลขโทรศัพท์ของผู้ถือกรมธรรม์จำนวน 4,500 ราย หลังจากเพิ่มการแก้ไขบันทึกล่วงหน้าแล้ว PII จะลดลงเหลือศูนย์ในบันทึกเดียวกันและการค้นหา KVKK ถูกปิด

กรณีที่ 2 — Tokenization รักษาความสม่ำเสมอ ทีมงานทรัพยากรบุคคลกำลังจัดทำสรุปการประเมินผู้สมัคร เมื่อแก้ไข PII แล้ว โมเดลจะคิดว่าผู้สมัครคนเดียวกันเป็นคนละคนในที่ต่างกัน เมื่อเปลี่ยนมาใช้โทเค็น ผู้สมัครแต่ละคนจะได้รับโทเค็นที่สอดคล้องกัน เช่น [CANDIDATE_1]; โมเดลดังกล่าวระบุแหล่งที่มาได้ถูกต้อง ในขณะที่ชื่อจริงไม่เคยปรากฏออกมา

กรณีที่ 3 — ผู้ให้บริการที่ไม่ใช่ ZDR ถูกกำจัด บริษัทเทคโนโลยีด้านสุขภาพแห่งหนึ่งประเมินผู้ให้บริการสามราย อันที่มีราคาต่ำที่สุดจะเก็บข้อมูลไว้เป็นเวลา 30 วันและสามารถนำไปใช้เพื่อ “การปรับปรุงบริการ” บริษัทพบว่าข้อนี้ไม่สามารถยอมรับได้เนื่องจากมีการประมวลผลข้อมูลผู้ป่วย เลือกผู้ให้บริการที่มีราคาแพงกว่า 18% ที่รับประกัน ZDR และถิ่นที่อยู่ของข้อมูล ในการตรวจสอบครั้งต่อไป การตัดสินใจครั้งนี้ถือว่าช่วยลดความเสี่ยงได้อย่างมาก

ข้อผิดพลาดทั่วไป

• คิดว่าได้รับการป้องกันโดยการส่ง PII แบบดิบไปยังโมเดลและเพียงพิมพ์ "อย่าบันทึก" ที่พรอมต์
• ลืมพรอมต์/ตอบกลับดิบในบันทึกการแก้ไขข้อบกพร่องในขณะที่ดูแลรักษาแอปพลิเคชัน
• การสร้างความสับสนให้กับการเขียนโทเค็น การแก้ไขในส่วนที่จำเป็นต้องมีความสอดคล้องและทำให้โมเดลเข้าใจผิด
• ตัวยึดตำแหน่ง ↔ การจัดเก็บการแมปค่าจริงในตำแหน่งที่ไม่ปลอดภัยหรือถาวร
• เข้าใจผิดว่าการรับประกัน "การใช้ในการศึกษา" และการรับประกัน "การจัดเก็บข้อมูล" เป็นสิ่งเดียวกัน
• ไม่เคยขอถิ่นที่อยู่ของข้อมูล (ในประเทศที่ประมวลผลข้อมูล)

โดยสรุป

• ข้อมูลรั่วไหลผ่านเวกเตอร์สี่ตัว: พรอมต์ บันทึก เอาท์พุต และการฝึกอบรม เป็นท่อนไม้ที่ถูกมองข้ามบ่อยที่สุด
• มาสก์ PII ก่อนที่จะส่งไปยังโมเดล: การดำเนินการใหม่หากไม่ต้องการค่าจริง, การแปลงโทเค็นหากจำเป็นต้องมีความสอดคล้องกัน
• เก็บตัวยึดตำแหน่ง ↔ การแมปค่าจริงไว้ฝั่งของคุณเท่านั้น ชั่วคราวและปลอดภัย
• ZDR (การเก็บรักษาข้อมูลเป็นศูนย์) และถิ่นที่อยู่ของข้อมูลคือการปกป้ององค์กรที่เด็ดขาดในการคัดเลือกซัพพลายเออร์
• "การใช้งานด้านการศึกษา" และ "การเก็บรักษาข้อมูล" เป็นการรับประกันแยกต่างหาก ขอแยกทั้งสองอย่างในสัญญา

งานสมัคร

ใช้ตัวอย่างคำขอจริงเพียงตัวอย่างเดียวที่ดำเนินการผ่านไปป์ไลน์ AI ของคุณเอง (พร้อมข้อมูลทดสอบ) ทำเครื่องหมายว่า PII ใดที่ปรากฏใน (1) พรอมต์ (2) บันทึก และ (3) ขั้นตอนการตอบกลับของคำขอนี้ สำหรับ PII แต่ละรายการ “การทบทวน การสร้างโทเค็น ไม่มีการโพสต์เลย?” ตัดสินใจและเขียนเวอร์ชันมาสก์ใหม่ สุดท้าย ทดสอบว่าบันทึกของคุณมี PII ด้วยข้อความแจ้งการควบคุมด้านบนหรือไม่

รายการตรวจสอบ

• [ ] ฉันแมปเวกเตอร์การรั่วไหลทั้งสี่แบบ (พร้อมท์ บันทึก เอาท์พุต การฝึกอบรม) บนระบบของฉัน
• [ ] ฉันปกปิด (ทำซ้ำ/โทเค็น) PII ก่อนที่จะส่งไปยังโมเดล
• [ ] บันทึกไม่มี PII; มีการพิสูจน์อักษรก่อนเข้าสู่ระบบ
• [ ] การแมปตัวยึดตำแหน่งจะถูกจัดเก็บไว้ชั่วคราวและปลอดภัย
• [ ] ฉันได้รับ ZDR ตามสัญญาและการรับประกัน "การไม่ใช้งานเพื่อการศึกษา" จากผู้ให้บริการ
• [ ] ฉันได้ตรวจสอบข้อกำหนดด้านถิ่นที่อยู่ของข้อมูลแล้ว (KVKK/GDPR)