สารบัญ
- ทำไม EDPB Anonymisation จึงน่าสนใจสำหรับธุรกิจไทย
- ปัญหาจริงไม่ใช่ “มีชื่อหรือไม่มีชื่อ”
- 3 ด่านที่ข้อมูลต้องผ่าน
- AI ทำให้คำว่า “Anonymous” ยากขึ้น
- ผลกระทบต่อธุรกิจในประเทศไทย
- สิ่งที่ควรทำต่อ
- มุมมองผู้เชี่ยวชาญ
- แหล่งอ้างอิง
EDPB Anonymisation กำลังเปลี่ยนวิธีคิดเรื่อง “ข้อมูลนิรนาม”
EDPB Anonymisation กำลังทำให้เรื่องที่หลายองค์กรคิดว่าเป็นงานของฝ่าย IT หรือ Data Analyst กลายเป็นเรื่องที่ฝ่าย Legal, DPO, Security และผู้บริหารต้องเข้ามาคุยกันด้วย
European Data Protection Board หรือ EDPB รับรอง Guidelines 02/2026 on Anonymisation Version 1.0 และเปิดรับความคิดเห็นสาธารณะระหว่างวันที่ 8 กรกฎาคมถึง 30 ตุลาคม 2026 เอกสารนี้ต้องการทำให้คำว่า “ข้อมูลนิรนาม” มีวิธีตรวจสอบที่ชัดเจนขึ้น โดยเฉพาะในยุคที่ AI และเทคโนโลยีช่วยเชื่อมข้อมูลจากหลายแหล่งได้ง่ายกว่าเดิม
ประเด็นนี้ไม่ได้แปลว่าไทยต้องนำแนวทางของ EDPB มาใช้แทนกฎหมายไทยทันที แต่สำหรับองค์กรไทยที่ทำธุรกิจกับยุโรป ใช้หลัก GDPR เป็น benchmark หรือกำลังสร้างระบบ Data Governance แนวคิดนี้ควรถูกหยิบกลับมาตรวจสอบระบบตัวเองตั้งแต่ตอนนี้
ปัญหาจริงไม่ใช่ “มีชื่อหรือไม่มีชื่อ”
ลองนึกภาพว่าบริษัทมีข้อมูลลูกค้า 1 ล้านแถว
ทีม Data ลบชื่อ นามสกุล เบอร์โทรศัพท์ และอีเมลออก แล้วบอกว่า
“เรียบร้อยครับ เป็น Anonymous Data แล้ว”
ฟังดูสมเหตุสมผล
แต่ EDPB ถามคำถามที่ยากกว่านั้นว่า
“ยังมีทางทำให้คนหนึ่งคนแตกต่างจากคนอื่น และรู้ได้หรือไม่ว่าคนคนนั้นคือใคร?”
นี่คือหัวใจของแนวทางใหม่
EDPB อธิบายว่าข้อมูลสามารถยังเกี่ยวข้องกับบุคคลได้ แม้สิ่งที่เห็นบนหน้าจอจะเป็นข้อมูลรวม ข้อมูลของกลุ่ม หรือข้อมูลที่ไม่มีชื่อโดยตรงก็ตาม เพราะการรวม attribute หลายตัวเข้าด้วยกันอาจทำให้บุคคลหนึ่งคนโดดเด่นขึ้นมาได้
ตัวอย่างง่ายๆ คือ
“ผู้หญิง อายุ 42 ปี อยู่จังหวัด X”
อาจไม่เพียงพอสำหรับการรู้ว่าเป็นใคร
แต่ถ้าเปลี่ยนเป็น
“ผู้หญิง อายุ 42 ปี อยู่จังหวัด X ทำงานตำแหน่งเฉพาะ อยู่คอนโดแห่งหนึ่ง และเดินทางไปสถานที่เดิมทุกวัน”
ชุดข้อมูลเหล่านี้อาจรวมกันจนเหลือคนที่ตรงเงื่อนไขเพียงคนเดียว
EDPB ยกตัวอย่างในลักษณะเดียวกันว่า attribute หลายตัวที่แยกกันไม่สามารถชี้ไปยังคนใดคนหนึ่ง อาจกลายเป็นตัวระบุบุคคลได้เมื่อเอามารวมกัน
วิธีที่จะทำให้ข้อมูลจะทำให้ เป็น Anonymous ได้อย่างมั่นใจ
จุดเด่นของ EDPB Anonymisation คือการกำหนดกรอบทดสอบด้วย 3 เกณฑ์
1. No Record Isolation — อย่ามีข้อมูลที่โดดเด่นจนชี้ไปหาคนเดียว
ถ้าข้อมูลหนึ่งแถวมี combination ของข้อมูลที่ไม่เหมือนใคร ก็มีโอกาสถูกแยกออกจากกลุ่มได้
EDPB ระบุว่าข้อมูลระดับรายบุคคลที่มีข้อมูลหลายคอลัมน์และมีรายละเอียดสูง มีโอกาสเกิด uniqueness มากขึ้น
เช่น
- อายุ
- วันเกิด
- อาชีพ
- พิกัด
- ประวัติการซื้อ
- เวลาเข้าออก
แต่ละตัวอาจดูธรรมดา
ปัญหาเกิดขึ้นเมื่อทุกอย่างอยู่ในแถวเดียวกัน
2. No Linkage — เอาไปต่อกับฐานข้อมูลอื่นแล้วใช่คนเดิมหรือไม่
นี่คือจุดที่ธุรกิจมักประเมินต่ำไป
บริษัทอาจส่ง Dataset A ให้ Partner โดยไม่มีชื่อ แต่ Partner มี Dataset B เช่น ข้อมูลสมาชิก หรือข้อมูลจากเว็บไซต์
เมื่อเอาสองชุดมาชนกัน อาจเกิดการค้นพบว่าข้อมูลหลายรายการเป็นบุคคลเดียวกัน
EDPB เน้นว่าต้องมองถึงข้อมูลอื่นที่มีอยู่และอาจนำมาประกอบกันได้ ไม่ใช่มองเฉพาะ Dataset ที่อยู่ตรงหน้า
3. No Inference — อย่าให้ข้อมูลเปิดทางให้ “เดาเรื่องสำคัญของคนคนหนึ่ง”
จุดนี้น่าสนใจที่สุดสำหรับยุค AI
ข้อมูลอาจไม่ได้บอกชื่อคนเลย แต่ถ้าจากข้อมูลนั้นสามารถอนุมานข้อมูลเฉพาะตัวที่มีความหมายเกี่ยวกับบุคคลหนึ่งคนได้ ความเป็นนิรนามก็อาจมีปัญหา
EDPB ระบุว่าการ inference สามารถเกิดได้ทั้งจากข้อมูลรายบุคคลและข้อมูลแบบ aggregate และต้องดูว่าการอนุมานนั้นมีความเฉพาะเจาะจงและมีความหมายต่อสิทธิหรือประโยชน์ของบุคคลหรือไม่
EDPB Anonymisation กับ AI: จุดเสี่ยงที่องค์กรไทยไม่ควรมองข้าม
นี่คือส่วนที่น่าจับตาที่สุด
เพราะ EDPB ไม่ได้หยุดอยู่ที่ Database แบบเดิม
เอกสารยกตัวอย่างว่า AI models และ synthetic data ก็อาจเกิดการอนุมานข้อมูลเกี่ยวกับบุคคลได้ เมื่อผู้ใช้ป้อนข้อมูลเพิ่มเติมหรือใช้ prompt เพื่อพยายามดึงความสัมพันธ์บางอย่างจากข้อมูลเดิม
พูดง่ายๆ คือ
“เราไม่เห็นชื่อ ไม่ได้แปลว่า AI จะไม่มีทางรู้ว่าเป็นใคร”
ยิ่งองค์กรมีข้อมูลจำนวนมากเท่าไร โอกาสที่ข้อมูลต่างชุดจะสามารถเชื่อมโยงกันก็ยิ่งสำคัญขึ้น
ดังนั้นการบอกว่า
“เราเอาข้อมูลเข้า AI หลังจากลบ PII แล้ว”
อาจยังไม่ใช่คำตอบสุดท้าย
คำถามที่สำคัญกว่าคือ
AI ยังสามารถเรียนรู้ความสัมพันธ์หรืออนุมานข้อมูลเฉพาะบุคคลจากสิ่งที่เหลืออยู่ได้หรือไม่?
นี่เป็นเหตุผลที่แนวทาง EDPB ระบุให้พิจารณาความสามารถของเทคนิค re-identification ที่พัฒนาอยู่ตลอด รวมถึงวิธีที่ซับซ้อนซึ่งอาจใช้ AI agents และเทคนิคเชิงความน่าจะเป็นในการค้นหาความเชื่อมโยง
ผลกระทบต่อธุรกิจในประเทศไทย
สำหรับธุรกิจไทย ประเด็นนี้ไม่ควรถูกแปลว่า “ต้องทำตาม GDPR เพราะ EDPB ออก Guidelines ใหม่” เพราะ Guidelines นี้เป็นแนวทางภายใต้กรอบ GDPR และยังอยู่ในช่วง public consultation ไม่ใช่กฎหมายไทยโดยตรง
แต่สิ่งที่องค์กรไทยควรหยิบมาใช้คือ วิธีคิด
ภายใต้ PDPA ไทยเอง การทำให้ข้อมูลกลายเป็นข้อมูลที่ไม่สามารถระบุตัวบุคคลได้เป็นหนึ่งในแนวทางที่ถูกกล่าวถึงเมื่อข้อมูลไม่จำเป็นต้องเก็บต่อ และหน่วยงานภาครัฐไทยก็มีการระบุถึงการลบ ทำลาย หรือทำให้ข้อมูลไม่สามารถระบุตัวบุคคลได้ในนโยบายที่เกี่ยวข้องกับการจัดการข้อมูลส่วนบุคคล
ปัญหาจึงอยู่ที่องค์กรต้องสามารถตอบได้ว่า “ทำอย่างไรถึงมั่นใจว่าระบุตัวไม่ได้จริง”
ลองดูสถานการณ์ที่เกิดขึ้นได้จริงในไทย
บริษัท Retail อาจนำข้อมูลการซื้อมาใช้ทำ Customer Analytics แล้วตัดชื่อออก แต่ยังเก็บ ZIP code, อายุ, เวลา และรูปแบบการซื้อไว้ครบ
โรงพยาบาลอาจทำข้อมูลผู้ป่วยเป็นสถิติ แต่ถ้ากลุ่มย่อยเล็กมาก คนที่รู้ข้อมูลบริบทอยู่แล้วอาจเดาได้ว่าเป็นใคร
ฝ่าย HR อาจทำ Employee Survey แบบไม่ระบุชื่อ แต่ถ้าทีมมีเพียง 3 คน และผู้บริหารรู้ว่าคนไหนลางานหรือมีเหตุการณ์อะไรเกิดขึ้น ก็อาจอนุมานคำตอบของแต่ละคนได้
ขณะเดียวกันบริษัทจำนวนมากกำลังส่งข้อมูลเหล่านี้ต่อไปยัง Cloud, Analytics Vendor, AI Provider หรือระบบ BI อีกหลายชั้น
นั่นทำให้โจทย์ไม่ใช่แค่ “เราลบชื่อหรือยัง”
แต่ต้องกลายเป็น
“ใครมีข้อมูลอะไรเพิ่มอีกบ้าง และเมื่อเอามารวมกันแล้ว ยังระบุตัวบุคคลได้หรือไม่?”
นี่คือจุดที่แนวคิด EDPB สามารถช่วยยกระดับงาน PDPA ไทยจากการตรวจเอกสาร ไปสู่การตรวจ data reality หรือสิ่งที่เกิดขึ้นจริงในระบบ
อีกประเด็นที่ผู้บริหารควรระวังคือ ความเสี่ยงไม่ได้หยุดนิ่ง EDPB ระบุว่าความเป็นไปได้ในการ re-identification อาจเพิ่มขึ้นตามเทคโนโลยีใหม่และปริมาณข้อมูลภายนอกที่เพิ่มขึ้น ดังนั้น Dataset ที่เคยถูกมองว่า anonymous วันนี้ อาจต้องถูกประเมินใหม่ในอนาคต
พูดให้เห็นภาพที่สุดคือ
Anonymisation ไม่ใช่งานที่ทำครั้งเดียวแล้วจบ
และสำหรับองค์กรที่กำลังเร่งใช้ AI นี่อาจกลายเป็นส่วนหนึ่งของ AI Governance โดยตรง
สิ่งที่ควรทำต่อ
1. หยุดใช้คำว่า “Anonymous” โดยยังไม่มีหลักฐาน
สร้างขั้นตอนตรวจสอบว่า Dataset ผ่านการประเมินอะไรบ้าง ก่อนอนุมัติให้ใช้งานหรือส่งต่อ
2. ทดสอบข้อมูลแบบ “เอาไปชนกัน”
อย่าทดสอบเฉพาะ Dataset เดียว ให้ถามว่าเมื่อเอาไปจับคู่กับข้อมูลจาก CRM, Website, App, Public Data หรือ Vendor แล้วจะยังระบุใครได้หรือไม่
3. เพิ่ม AI เข้าไปใน Threat Model
ตรวจว่า Dataset ถูกนำไปใช้กับ AI model, RAG, Analytics หรือ Synthetic Data หรือไม่ และมีความเป็นไปได้ที่จะเกิด inference ต่อบุคคลหรือไม่
4. ทบทวน Dataset เก่าที่เคยบอกว่า “นิรนาม”
โดยเฉพาะข้อมูลที่สร้างไว้หลายปีก่อน เพราะเทคโนโลยีและข้อมูลภายนอกในปัจจุบันอาจทำให้ความเสี่ยงเปลี่ยนไป
5. ให้ DPO + IT + Data Team ประเมินร่วมกัน
เรื่องนี้ไม่ควรตกอยู่กับ Legal ฝ่ายเดียว เพราะคำตอบอยู่ทั้งในกฎหมาย สถาปัตยกรรมข้อมูล และความสามารถทางเทคนิคในการ re-identification
มุมมองผู้เชี่ยวชาญ
ประเด็นนี้ไม่ใช่ “ห้ามใช้ข้อมูล” แต่คือ “อย่าประกาศว่าข้อมูลนิรนามแล้วเพียงเพราะลบชื่อออก” เพราะโลกของ AI ทำให้ข้อมูลที่เหลืออยู่สามารถถูกเชื่อมและตีความใหม่ได้มากกว่าที่องค์กรคาดไว้
— Phuwara Krobtaku —
LL.M. (IP & IT) | M.S. (IT) | Thai Barrister & Attorney-at-Law
แหล่งอ้างอิง
European Data Protection Board (EDPB) — Guidelines 02/2026 on Anonymisation, Version 1.0 ซึ่งรับรองเมื่อ 7 กรกฎาคม 2026 และเปิดรับความคิดเห็นสาธารณะ
EDPB — Guidelines 02/2026 on Anonymisation
EDPB — Public Consultation on Guidelines 02/2026
สำหรับกฎหมายไทย สามารถตรวจตัวบท พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 และข้อมูลจากหน่วยงานภาครัฐที่เกี่ยวข้องประกอบการวิเคราะห์ได้
บทความนี้เป็นการสรุปข่าวและให้ข้อมูลทั่วไป ไม่ใช่คำแนะนำทางกฎหมาย
หากต้องการคำปรึกษาเฉพาะกรณีของธุรกิจคุณ ควรปรึกษาผู้เชี่ยวชาญ
