PII redaction

PII redaction คือการไล่หาข้อมูลที่ระบุตัวบุคคลในข้อความ แล้วลบ ปิดบัง หรือแทนที่ด้วยค่าอื่น ก่อนที่ข้อความนั้นจะถูกส่งออกไปข้างนอก PII ย่อจาก Personally Identifiable Information ครอบคลุมตั้งแต่ชื่อ เบอร์โทร อีเมล ที่อยู่ ไปจนถึงเลขบัตรประชาชนและเลขบัญชีธนาคาร ในงาน AI ปลายทางที่ว่าคือข้อความที่เราส่งเข้า model นั่นเอง แนวคิดของมันตรงไปตรงมาคือถ้าองค์กรอยากให้ AI ช่วยสรุปเรื่องร้องเรียนของลูกค้าทั้งกอง AI ไม่จำเป็นต้องรู้ว่าลูกค้าชื่ออะไรและอยู่บ้านเลขที่เท่าไร เอกสารของ Azure Language อธิบายบริการ PII detection ของตัวเองว่ารับข้อความเข้าไปแล้วคืนออกมาเป็นรายการ entity พร้อม confidence score และข้อความฉบับที่ redact แล้ว โดยแยกเป็นสามแบบตามรูปของข้อมูล คือ Text PII สำหรับข้อความสดที่ตอบกลับทันที Conversation PII สำหรับบทสนทนาที่มีการสลับ turn และ Document-based PII สำหรับไฟล์ .pdf .docx .txt ที่ต้องการผลลัพธ์เป็นเอกสารที่ยังคงรูปเดิม

วิธีปิดบังมีหลายระดับและเลือกได้ว่าจะเหลือร่องรอยไว้แค่ไหน เอกสาร de-identification ของ Google Cloud Sensitive Data Protection ระบุวิธีไว้หลายแบบ ตั้งแต่ masking ที่แทนตัวอักษรด้วยสัญลักษณ์ การลบทิ้งทั้งค่า การแทนด้วยข้อความที่เรากำหนดเอง การ hash แบบ SHA-256 การเลื่อนวันที่แบบสุ่มโดยยังรักษาลำดับก่อนหลังไว้ ไปจนถึง tokenization ที่แทนค่าเดิมด้วย token ฝั่ง amazon-bedrock ทำเรื่องนี้เป็นนโยบายหนึ่งในชั้น guardrails ชื่อ sensitive information filter ซึ่งตั้งได้ว่าเจอแล้วจะ BLOCK ทั้งข้อความไปเลย หรือ ANONYMIZE คือแทนค่าด้วยชื่อประเภทอย่าง {NAME} และ {EMAIL} ตั้งแยกกันได้ระหว่างขาเข้าที่เป็นคำสั่งของผู้ใช้กับขาออกที่เป็นคำตอบของ model และเติม regex ของตัวเองสำหรับรหัสภายในองค์กรได้อีกชั้น

สิ่งที่ต้องเข้าใจให้ตรงกันคือทั้งหมดนี้เป็นการเดาจากบริบท ไม่ใช่การจับคู่แบบตายตัว เอกสารของ AWS เรียกตัวกรองนี้ตรงไปตรงมาว่า "a probabilistic machine learning (ML) based solution that is context-dependent" และย้ำว่าถ้าส่งเข้าไปแค่คำสั้นๆ ที่ไม่มีบริบทรอบข้าง ความแม่นยำจะแย่ลง ตัวอย่างของ Microsoft ในเรื่องเดียวกันคือตัวเลขสิบหลักลอยๆ ก็เป็นแค่ตัวเลข ระบบจะรู้ว่าเป็นเบอร์โทรก็ต่อเมื่อมีประโยคแวดล้อมบอก ปุ่มหลักที่ใช้ปรับความไวในฝั่ง Google และ Azure จึงเป็นการตั้งเกณฑ์ความมั่นใจ Google ให้เลือก likelihood ห้าระดับตั้งแต่ VERY_UNLIKELY ถึง VERY_LIKELY โดยค่าเริ่มต้นอยู่ที่ POSSIBLE และอธิบายไว้ว่าตั้งเกณฑ์สูงขึ้นจะได้ false positive น้อยลงแต่ก็จะตัดของจริงทิ้งมากขึ้นตามไปด้วย ส่วน Azure ใช้หลักเดียวกันผ่านการปรับ threshold ของ confidence score พร้อมเตือนว่าค่าเดียวกันไม่ได้ให้ผลเหมือนกันในทุกประเภท entity จึงต้องทดสอบกับข้อมูลจริงที่จะเจอบน production เสมอ

องค์กรไทยที่ทำงานใต้ pdpa มักเอาเรื่องนี้มาใช้เป็นทางออกตรงกลาง ระหว่างการห้ามใช้ AI กับงานที่มีข้อมูลลูกค้าไปเลย ซึ่งจบลงที่พนักงานแอบไปใช้บัญชีส่วนตัวจนกลายเป็น shadow-ai กับการปล่อยให้ส่งข้อมูลจริงออกไปโดยไม่มีด่าน จุดที่คนไทยต้องเช็คก่อนใครคือภาษา หน้ารายการภาษาทางการของ Azure ระบุ Thai รหัส th ไว้ในตารางของ Text PII และ Document-based PII ขณะที่หน้าเดียวกันระบุว่า Conversation PII เวอร์ชัน GA รองรับแค่ English, French และ Spanish ฝั่ง Google มี infoType เฉพาะของไทยชื่อ THAILAND_NATIONAL_ID_NUMBER สำหรับบัตรประจำตัวประชาชน การมีชื่อไทยอยู่ในรายการเป็นคนละเรื่องกับการรับประกันว่าจับได้ครบ transparency note ของ Microsoft เขียนไว้ชัดว่าเกิดได้ทั้ง false positive และ false negative และในงาน redaction การพลาดแบบ false negative แปลตรงตัวว่าข้อมูลส่วนบุคคลรั่วออกไปแล้ว เอกสารเดียวกันจึงแนะนำให้วางขั้นตอน human-review ไว้ด้วย และให้เลี่ยงการ redact อัตโนมัติล้วนในงานที่ความพลาดทำให้คนถูกสวมรอยหรือเดือดร้อนจริง กับดักสุดท้ายที่คนลืมบ่อยคือการ mask ที่ชั้นทางออกไม่ได้แปลว่าค่าเดิมหายไปจากบ้านเราเอง เอกสารของ Amazon Bedrock ระบุว่าถ้าเปิด model invocation logging ไว้ ค่าในช่อง input ของ CloudWatch Logs จะเป็นคำขอต้นฉบับที่ยังไม่ถูกแก้เสมอ และค่า match ใน trace ที่ API คืนกลับมาก็เป็นค่า PII ตัวจริงไม่ใช่ค่าที่ mask แล้ว ซึ่งเขาออกแบบมาแบบนั้นตั้งใจ เท่ากับว่า audit-log ของระบบเราคืออีกที่ที่ต้องไปจัดการแยกต่างหาก

ตัวอย่างจากบทสนทนาจริง

หัวหน้าทีมบริการลูกค้า: ทีมกฎหมายไม่ให้เอาแชทลูกค้าไปให้ AI สรุป แต่ IT บอกว่าถ้าเปิด PII redaction ก่อนก็ผ่านได้ แปลว่าปลอดภัยแล้วใช่ไหมคะ

IT security: ช่วยลดความเสี่ยงได้เยอะครับ แต่ไม่ใช่ปุ่มที่กดครั้งเดียวแล้วจบ ตัวมันเดาจากบริบทว่าอะไรคือชื่อคนอะไรคือเบอร์ ถ้าลูกค้าพิมพ์เลขบัตรมาลอยๆ ไม่มีประโยคขยาย โอกาสหลุดมีจริง เราเลยต้องสุ่มตรวจผลที่ redact แล้วช่วงแรก

หัวหน้าทีมบริการลูกค้า: แล้วถ้ามันตัดเกินจนสรุปอ่านไม่รู้เรื่องล่ะคะ

IT security: นั่นคือเกณฑ์ตัวเดียวกันครับ ตั้งให้ไวขึ้นก็ตัดเกินบ่อยขึ้น ตั้งให้เข้มขึ้นก็หลุดบ่อยขึ้น ต้องปรับเกณฑ์กับข้อความจริงของเราเอง อีกอย่างที่ต้องทำพร้อมกันคือไปดู log ฝั่งเราด้วย เพราะบางระบบยังเก็บข้อความต้นฉบับก่อนปิดบังไว้อยู่

ระวังสับสนกับ

• dlp : DLP คือระบบสอดส่องและสกัดข้อมูลอ่อนไหวที่ระดับองค์กรทั้งอีเมล ไฟล์ และอุปกรณ์ปลายทาง เครื่องมือตระกูลนี้อย่าง microsoft-purview ตอบคำถามว่าข้อมูลกำลังจะออกไปทางไหน ส่วน PII redaction ทำงานที่ตัวข้อความคือแก้เนื้อความให้ไม่มีข้อมูลตัวบุคคลก่อนส่งต่อ องค์กรส่วนใหญ่ใช้ทั้งคู่คนละชั้นกัน
• zero-data-retention : เป็นคำมั่นของผู้ให้บริการว่าจะไม่เก็บข้อมูลไว้หลังประมวลผลเสร็จ แต่ตัวข้อมูลจริงก็ยังเดินทางออกจากองค์กรไปแล้วอยู่ดี ส่วน PII redaction เลือกที่จะไม่ส่งของจริงออกไปตั้งแต่แรก
• data-residency : ว่าด้วยเรื่องข้อมูลถูกเก็บและประมวลผลอยู่ในประเทศไหน ไม่ได้ตอบว่าเนื้อข้อความมีชื่อลูกค้าติดไปด้วยหรือเปล่า ย้ายที่เก็บมาไทยแล้วแต่ยังส่งเลขบัตรประชาชนดิบเข้าไป ก็ยังเป็นคนละปัญหาที่ต้องแก้อยู่ดี
• guardrails : guardrails เป็นชั้นกรองรวมที่ดูหลายเรื่องพร้อมกัน ทั้งเนื้อหาต้องห้าม หัวข้อที่องค์กรไม่อยากให้ตอบ และข้อมูลอ่อนไหว โดย PII redaction เป็นนโยบายย่อยหนึ่งอันที่เปิดใช้ในนั้นได้