Machine Unlearning คืออะไร SMEs ต้องรู้ไว้ก่อนใช้ AI เก็บข้อมูลลูกค้า

Machine Unlearning คือเทคนิคที่ทำให้โมเดล AI “ลืม” ข้อมูลส่วนบุคคลของลูกค้าได้จริงโดยไม่ต้องเทรนโมเดลใหม่ทั้งระบบ เป็นคำตอบของปัญหาที่ว่า PDPA ให้สิทธิลูกค้าขอลบข้อมูล แต่เมื่อข้อมูลถูกใช้สอน AI ไปแล้ว การลบแค่ฐานข้อมูลไม่ได้ช่วยให้ร่องรอยในตัวโมเดลหายไป สำหรับ SME ไทยที่เริ่มใช้ AI วิเคราะห์ลูกค้า เทรนโมเดลแนะนำสินค้า หรือใช้ระบบ ERP ที่มีฟีเจอร์ AI การเข้าใจแนวคิดนี้ช่วยให้ตอบสนองคำขอลบข้อมูลโดยไม่ต้องปิดระบบ รอการเทรนใหม่หลายสัปดาห์ และยังลดความเสี่ยงถูกปรับหรือเสียชื่อเสียงเมื่อลูกค้าตรวจพบว่าข้อมูลตัวเองยังถูกใช้อยู่

Machine Unlearning คืออะไร และทำงานกับ AI ที่เทรนเสร็จแล้วอย่างไร

เมื่อเราฝึกโมเดล AI ให้รู้จักลูกค้า ระบบจะแปลงข้อมูลดิบเป็น “น้ำหนัก” หรือ weight ภายในโครงข่ายประสาทเทียม ตัวเลขเหล่านี้รวมเอาความสัมพันธ์เชิงสถิติของข้อมูลทั้งหมด ตั้งแต่เพศ อายุ พฤติกรรมซื้อสินค้า ไปจนถึงช่วงเวลาที่ลูกค้ามักเปิดอีเมล ข้อมูลที่ต้องการลบจึงไม่เหลือเป็นแถวในตารางให้กด delete ได้ง่าย ๆ แต่มันถูกกระจายอยู่ในค่าพารามิเตอร์จำนวนมาก

Machine Unlearning จึงไม่ได้ลบไฟล์ แต่เป็นการปรับค่าพารามิเตอร์ของโมเดลให้ผลลัพธ์ใกล้เคียงกับโมเดลที่เทรนจากชุดข้อมูลที่เหลือโดยไม่มีข้อมูลของบุคคลนั้น เทคนิคมีหลายรูปแบบ ตั้งแต่การปรับโมเดลด้วยการเพิ่ม loss ในส่วนของข้อมูลที่ต้องการลบเพื่อให้โมเดลจำรายละเอียดนั้นไม่ได้อีกต่อไป การแบ่งข้อมูลเทรนเป็นกลุ่มย่อยแล้วเทรนเฉพาะกลุ่มที่เกี่ยวข้องกับข้อมูลที่ถูกลบ หรือการใช้ influence function เพื่อประมาณว่าข้อมูลแต่ละแถวมีอิทธิพลต่อโมเดลอย่างไรแล้วลบอิทธิพลนั้นออก

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

PDPA กับ AI: ทำไมสิทธิขอลบข้อมูลถึงไม่จบแค่ในฐานข้อมูล

พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 ให้สิทธิเจ้าของข้อมูลขอให้ผู้ควบคุมข้อมูลลบ ทำลาย หรือทำให้ข้อมูลเป็นข้อมูลที่ไม่สามารถระบุตัวบุคคลได้ภายใต้เงื่อนไขบางประการ แต่เมื่อข้อมูลถูกใช้เป็นชุดเทรน AI ร่องรอยของข้อมูลไม่ได้อยู่แค่ใน database อีกต่อไป มันอาจอยู่ในความจำของโมเดลในรูปแบบที่มนุษย์อ่านไม่เห็น

ยกตัวอย่าง ลูกค้าคนหนึ่งเคยซื้อสินค้าประเภทอาหารเสริมสำหรับคนตั้งครรภ์และขอให้ร้านลบประวัติการสั่งซื้อทั้งหมด หากร้านลบเฉพาะตาราง orders แต่โมเดลแนะนำสินค้ายังเรียนรู้ว่าลูกค้ากลุ่มอายุและพื้นที่ใดมีแนวโน้มซื้อสินค้านั้นสูง ลูกค้าอาจยังได้รับโฆษณาหรืออีเมลที่ทำให้คนอื่นเดาเหตุผลได้ ข้อมูลสุขภาพหรือข้อมูลชีวภาพบางอย่างอาจจัดเป็นข้อมูลอ่อนไหว การปล่อยให้โมเดลส่งต่อความรู้นี้จึงไม่ใช่แค่ความผิดพลาดทางเทคนิค แต่เป็นความเสี่ยงทางกฎหมายและชื่อเสียง

PDPA ไม่ได้ระบุคำว่า Machine Unlearning ไว้ตรง ๆ แต่มันคือหลักฐานเชิงเทคนิคที่แสดงว่าผู้ควบคุมข้อมูล “ทำในสิ่งที่กฎหมายต้องการได้จริง” การมีเพียงนโยบายความเป็นส่วนตัวสวยหรูแต่ตอบคำร้องลบข้อมูลไม่ได้จะกลายเป็นจุดอ่อนเมื่อหน่วยงานกำกับดูแลสอบทาน หรือเมื่อลูกค้าฟ้องเรียกค่าเสียหาย

Machine Unlearning กับ Full Retraining ต่างกันอย่างไร

Full Retraining คือวิธีที่ “ถูกต้องที่สุด” เพราะคุณเทรนโมเดลใหม่จากศูนย์ด้วยชุดข้อมูลที่เหลือทั้งหมดหลังลบข้อมูลออก เป็นหลักฐานที่หาจุดผิดยากที่สุด แต่ต้นทุนคือเวลา พลังงาน และค่าทีมงานเทคนิค หากโมเดลของ SME เทรนด้วยข้อมูลหลักหมื่นรายการและลูกค้าขอลบเดือนละ 2-3 ราย การเทรนใหม่ทุกครั้งก็เหมือนจ่ายค่าโดยสารเรือทั้งลำเพื่อขนของชิ้นเดียว

Machine Unlearning พยายามเลียนแบบผลลัพธ์ของ Full Retraining โดยใช้ทรัพยากรน้อยกว่า เช่น ปรับโมเดลเดิมต่ออีกไม่กี่รอบด้วยข้อมูลที่เหลือ หรือใช้สถาปัตยกรรมแบบหน่วยย่อยเพื่อให้ลบเฉพาะส่วนที่เกี่ยวข้อง ในงานวิจัยบางชุดระบุว่าประหยัดเวลาได้มากเมื่อเทียบกับ retraining ทั้งโมเดล แต่ผู้ให้บริการระบุว่าประสิทธิภาพจริงขึ้นกับขนาดข้อมูลและโครงสร้างโมเดล การเลือกวิธีใดวิธีหนึ่งต้องพิจารณาว่าธุรกิจต้องตอบคำขอลบภายในกี่วัน ข้อมูลที่จะลบเป็นข้อมูลอ่อนไหวหรือไม่ และโมเดลนั้นเปิดต่อลูกค้าหรือใช้ภายในเท่านั้น

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

กรณีตัวอย่างที่ SME ไทยพบจริง: ร้านค้า โรงแรม และโรงงาน

สมมติว่าร้านค้าออนไลน์ขายเสื้อผ้าแฟชันใช้โมเดลแนะนำสินค้าจากประวัติการเลือกสินค้า ลูกค้าคนหนึ่งยกเลิกบัญชีและขอใช้สิทธิตาม PDPA เพราะไม่ต้องการให้ร้านใช้ประวัติการสั่งซื้อเพื่อทำการตลาดอีก หลังลบฐานข้อมูลแล้ว โมเดลแนะนำสินค้าอาจยังมี “รหัสแทนตัวตน” ของลูกค้าอยู่ในชั้น embedding หากระบบไม่ทำ Machine Unlearning ลูกค้าอาจยังเห็นแบนเนอร์สินค้าที่เคยค้นหาเมื่อใช้เบราว์เซอร์เดิมผ่านคุกกี้หรือข้อมูลอื่นที่เชื่อมโยงได้

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

ฝั่งโรงงานผลิตชิ้นส่วนที่ใช้ระบบ HR เทรนโมเดลทำนายการลาออกของพนักงาน โมเดลอาจฝังข้อมูลเงินเดือน อายุงาน และวันลาป่วยของพนักงานแต่ละคน เมื่อพนักงานลาออกและยื่นคำขอลบข้อมูลส่วนบุคคลตาม PDPA ผู้ประกอบการต้องพิจารณาว่ายังมีฐานกฎหมายให้เก็บข้อมูลได้หรือไม่ หากไม่มี ข้อมูลนั้นต้องหลุดออกจากทั้งระบบ HR และโมเดลด้วย ไม่เช่นนั้นเวลาตรวจสอบภายในจะเจอ “ผี” ของพนักงานเดิมในคะแนนความเสี่ยงของพนักงานใหม่

แนวทางเริ่มต้นสำหรับ SME ไทยที่อยากใช้ AI อย่างปลอดภัย

ขั้นแรกคือรู้ให้ชัดว่าโมเดลตัวไหนเทรนด้วยข้อมูลส่วนบุคคลอะไร ระบบ CRM ที่เก็บประวัติลูกค้าเพียงอย่างเดียวไม่ใช่ปัญหาใหญ่ แต่ถ้านำข้อมูลนั้นไปทำ customer segmentation model หรือเทรน chatbot ส่วนตัว โมเดลเหล่านั้นต้องอยู่ในแผน PDPA ด้วย

ขั้นที่สองคือออกแบบกระบวนการเมื่อมีคำขอลบ ควรมีแบบฟอร์มรับคำขอ ตรวจสอบตัวตนผู้ขอ และบันทึกเวลาที่ได้รับคำขอ จากนั้นแยกเส้นทางว่าข้อมูลอยู่ในส่วนใด หากเป็นฐานข้อมูลก็ลบ หากเป็นโมเดล AI ที่ใช้งานสำคัญก็ต้องตัดสินใจใช้ unlearning หรือ retraining ตามความเสี่ยง

ขั้นที่สามคือเลือกผู้ให้บริการซอฟต์แวร์อย่างระมัดระวัง อย่าซื้อระบบ ERP หรือ CRM ที่มีฟีเจอร์ AI เพียงเพราะโฆษณาว่ารองรับ PDPA ให้ถามข้อกำหนดลงในสัญญา ว่าหากมีลูกค้าขอลบข้อมูล ระบบจะจัดการโมเดลที่เทรนด้วยข้อมูลนั้นอย่างไร มี SLA กี่วัน มีบันทึกการดำเนินการให้ตรวจสอบหรือไม่ และค่าใช้จ่ายอยู่ในการดูแลประจำปีหรือคิดเพิ่ม

สิ่งที่ต้องระวัง: ต้นทุน เวลา และการพิสูจน์ว่า “ลบจริงแล้ว”

Machine Unlearning ไม่ใช่ปุ่มมหัศจรรย์ที่กดแล้วจบเสมอไปในราคาถูก บางวิธีต้องเก็บ checkpoint ของโมเดลหลายเวอร์ชัน หรือต้องเทรน model ย่อยหลายตัวตั้งแต่แรกเพื่อให้พร้อมลบได้เร็ว ต้นทุนเหล่านี้อาจสูงกว่าการเทรนใหม่เป็นรอบในธุรกิจขนาดเล็กที่มีข้อมูลปริมาณไม่มาก จึงควรเปรียบเทียบกับ Full Retraining ในรอบอัปเดตปกติของโมเดลก่อนตัดสินใจ

อีกเรื่องที่ SME มองข้ามคือ “หลักฐาน” PDPA ต้องการหลักฐานว่าผู้ควบคุมข้อมูลดำเนินการตามคำขอ ไม่ใช่แค่คำบอกว่าโมเดลลืมแล้ว ดังนั้นควรเก็บบันทึกเวอร์ชันโมเดลก่อนลบและหลังลบ รายการข้อมูลที่ลบ ชื่อผู้สั่งการ และผลการทดสอบการโจมตีแบบ Membership Inference ที่ยืนยันว่าโมเดลไม่สามารถระบุได้ว่าข้อมูลรายนั้นเคยอยู่ในชุดฝึก

การตรวจสอบแบบนี้ช่วยให้ธุรกิจมีหลักฐานในวันที่ลูกค้าร้องเรียนหรือหน่วยงานกำกับดูแลสอบถาม และช่วยให้ผู้บริหารมั่นใจว่า AI ไม่ได้กลายเป็นคลังข้อมูลลับที่ผิด PDPA ซ่อนอยู่หลังระบบแนะนำสินค้า

สรุป: ตัดสินใจอย่างไรให้ AI กับ PDPA อยู่ด้วยกันได้

SME ไทยไม่จำเป็นต้องกลายเป็นนักวิจัย Machine Unlearning เพื่อใช้งานจริง แต่ต้องเริ่มตั้งคำถามกับผู้พัฒนาระบบและผู้ให้บริการคลาวด์ที่ตัวเองใช้อยู่ ทุกโมเดล AI ที่เทรนด้วยข้อมูลลูกค้า ควรมีแผนชัดเจนว่าจะทำอย่างไรเมื่อลูกค้าขอใช้สิทธิลบข้อมูล หากแผนนั้นบอกว่า “ลบในดาต้าเบสแล้ว” เพียงอย่างเดียว อาจไม่เพียงพอในยุคที่ความทรงจำของ AI ซ่อนอยู่ในน้ำหนักนับล้านค่า

ธุรกิจที่เตรียมพร้อมทั้งนโยบาย เทคโนโลยี และหลักฐานการตรวจสอบจะได้เปรียบสองทาง ทางแรกคือปฏิบัติตาม PDPA โดยไม่ต้องหยุดระบบเพื่อรีเทรนโมเดลบ่อย ๆ ทางที่สองคือสร้างความน่าเชื่อถือกับลูกค้าที่เริ่มตระหนักว่าข้อมูลของตัวเองไม่ได้หายไปแค่กดปุ่ม delete ซึ่งเป็นสินทรัพย์ระยะยาวที่สำคัญกว่าการประหยัดค่าใช้จ่ายด้าน IT ในช่วงสั้น