บทนำ
ลองนึกภาพบริษัทหนึ่งมีข้อมูลลูกค้าอยู่ 5 ระบบ
CRM รู้ประวัติการซื้อ
Call Center รู้ปัญหาที่ลูกค้าเคยร้องเรียน
ระบบสมาชิกเห็นพฤติกรรมการใช้บริการ
ฝ่ายการเงินเห็นธุรกรรม
และ AI Agent ตัวใหม่สามารถค้นข้อมูลจากทุกระบบ
แต่ทั้ง 5 ระบบใช้เลขหรือรหัสเดียวกันเพื่อระบุตัวลูกค้า คำถามคือ ถ้าไม่มี Hacker เลย ข้อมูลยังเสี่ยงหรือไม่? คำตอบคือ เสี่ยงได้
บทความของ Subhashis Banerjee ใน Tech Policy Press เมื่อวันที่ 14 สิงหาคม 2026 ใช้ระบบ Aadhaar ของอินเดียเป็นกรณีศึกษาเพื่อชี้ให้เห็นว่า การใช้ตัวระบุบุคคลแบบถาวรตัวเดียวในหลายบริบทสามารถทำให้ข้อมูลซึ่งเดิมแยกกันอยู่ถูกเชื่อมโยงเข้าหากันได้ง่ายขึ้น.
เรื่องนี้จึงไม่ใช่แค่ข่าวของอินเดีย แต่เป็นคำเตือนสำหรับทุกองค์กรที่กำลังสร้าง Data Platform, Digital ID หรือ AI Agent ในประเทศไทย
“ข้อมูลไม่จำเป็นต้องรั่ว ก็สร้างภาพชีวิตของคนได้ หากทุกระบบใช้กุญแจดอกเดียวกัน”
กรณีศึกษา Aadhaar สอนอะไรเรา?
Aadhaar เป็นระบบระบุตัวตนด้วยข้อมูลชีวมิติขนาดใหญ่ของอินเดีย และถูกนำไปใช้ประกอบบริการหลากหลาย ตั้งแต่สวัสดิการ การเงิน โทรคมนาคม ไปจนถึงภาษี
ประเด็นที่ Banerjee ตั้งคำถามไม่ใช่ว่า Digital ID ควรมีหรือไม่ แต่คือ การเลือก Architecture แบบใดตั้งแต่ต้น
หัวใจของข้อวิจารณ์อยู่ที่การใช้ identifier ถาวรตัวเดียวในหลายบริบท เพราะเมื่อธนาคาร ผู้ให้บริการโทรศัพท์ หน่วยงานรัฐ และระบบอื่นถือกุญแจอ้างอิงเดียวกัน การจับคู่ข้อมูลระหว่างระบบย่อมง่ายขึ้น นี่ต่างจากความเข้าใจเรื่อง Data Breach แบบทั่วไป เราเคยมองว่า Privacy Risk เกิดเมื่อใครสักคน “เข้าไปขโมยข้อมูล”
แต่ในโลก Data Architecture ความเสี่ยงอีกแบบคือ ระบบทำงานตามที่ออกแบบไว้ทุกอย่าง แต่ Architecture เปิดทางให้ข้อมูลถูกเชื่อมกันมากเกินความจำเป็น
ยืนยันตัวตนแล้ว ไม่ได้แปลว่าอนุญาตทุกอย่าง
อีกบทเรียนหนึ่งคือการแยก Authentication ออกจาก Authorization
Authentication ตอบว่า: “คุณคือใคร?”
Authorization ตอบว่า: “คุณอนุญาตให้ทำอะไร?”
สองคำถามนี้ไม่ใช่เรื่องเดียวกัน
Tech Policy Press ยกกรณีปี 2017 ซึ่งหน่วยงานของ Aadhaar ระงับสิทธิของ Airtel และ Airtel Payments Bank ในการตรวจสอบ Aadhaar หลังพบปัญหาเกี่ยวกับการใช้กระบวนการยืนยันตัวตนสำหรับ SIM ไปสัมพันธ์กับการเปิดบัญชีธนาคารที่ลูกค้าไม่ได้ร้องขอ โดยบทความระบุว่ามีบัญชีมากกว่า 3 ล้านบัญชีเกี่ยวข้องกับเหตุการณ์ดังกล่าว
ประเด็นสำคัญสำหรับองค์กรไทยจึงไม่ใช่เพียงว่า “มี consent หรือยัง” แต่ต้องถามว่า: Consent นั้นถูกผูกกับ Action ไหน? และระบบบังคับใช้ขอบเขตดังกล่าวจริงหรือไม่?
“ต่อให้เขียน Privacy Notice หรือ นโยบายความเป็นส่วนตัว ให้สวยหรูแค่ไหน ก็ไม่สามารถแก้ปัญหาเรื่องระบบที่ปล่อยให้คนเข้าถึงข้อมูลมากเกินไปตั้งแต่แรกได้ครับ”
จาก Data Minimization สู่ “Linkability Minimization”
เวลาพูดเรื่อง PDPA เรามักเริ่มด้วยคำถามว่า “เก็บข้อมูลมากเกินไปหรือไม่?” ซึ่งเป็นคำถามที่ถูกต้อง เพราะมาตรา 22 ของ PDPA กำหนดหลักว่าการเก็บรวบรวมข้อมูลส่วนบุคคลต้องอยู่เท่าที่จำเป็นภายใต้วัตถุประสงค์อันชอบด้วยกฎหมาย.
แต่โลกของระบบเชื่อมต่อกันต้องเพิ่มอีกหนึ่งคำถาม: “ข้อมูลที่เราเก็บไว้นั้น เชื่อมเข้าหากันง่ายเกินความจำเป็นหรือไม่?” สมมติบริษัทมี:
เลขบัตรประชาชน → CRM
เลขบัตรประชาชน → HR
เลขบัตรประชาชน → Loyalty
เลขบัตรประชาชน → Call Center
เลขบัตรประชาชน → Data Lake
เมื่อแต่ละระบบถือ common key เดียวกัน สิ่งที่เคยเป็นข้อมูลคนละวัตถุประสงค์สามารถถูก join เข้าหากันได้ง่ายมาก
องค์กรอาจมีสิทธิใช้ข้อมูลแต่ละระบบโดยชอบด้วยกฎหมายแยกกัน แต่ไม่ได้หมายความว่า การรวมข้อมูลทั้งหมดเข้าด้วยกันเพื่อวัตถุประสงค์ใหม่จะชอบด้วยกฎหมายโดยอัตโนมัติ
มาตรา 23 ของ PDPA ยังให้ความสำคัญกับการแจ้งวัตถุประสงค์ของการเก็บรวบรวมข้อมูล ซึ่งทำให้การเปลี่ยนบริบทหรือการนำข้อมูลไปใช้ต่อไม่ใช่เรื่องที่ควรถูกมองเป็นเพียงการเชื่อม API ทางเทคนิค.
ผลกระทบต่อธุรกิจในประเทศไทย
บทเรียนจาก Aadhaar สำคัญต่อธุรกิจไทยมากขึ้นในช่วงที่องค์กรกำลังเชื่อมระบบเดิมเข้ากับ Data Platform และ AI เพราะระบบใหม่มักไม่ได้สร้างข้อมูลใหม่ แต่เข้าไป เปิดประตูระหว่างฐานข้อมูลเดิม
ปัญหาแรกคือเรื่อง “การใช้รหัสลูกค้าเดียวเชื่อมกับทุกบริการ” บริษัทส่วนใหญ่อยากรู้ข้อมูลลูกค้าแบบครบทุกมุม เพื่อประโยชน์ทางธุรกิจ แต่ถ้าบริษัทใช้รหัสเดียวดึงข้อมูลจากทุกบริการมารวมกัน โดยไม่แยกแยะว่าเอาข้อมูลไปทำอะไรบ้าง ความง่ายในการวิเคราะห์ข้อมูลนี้ อาจกลายเป็นการรุกล้ำความเป็นส่วนตัว ของลูกค้าโดยไม่รู้ตัว
ปัญหาต่อมาคือ AI Agent ทุกวันนี้ไม่ได้ทำแค่อ่านข้อมูล แต่ “ลงมือทำแทนเราได้จริง” เช่น แก้เอกสาร, อนุมัติคำขอ, ส่งข้อความ หรือสั่งงานระบบอื่นความเสี่ยงใหญ่: ถ้าองค์กรคิดง่ายๆ แค่ว่า “ในเมื่อผู้ใช้ล็อกอินแล้ว AI จะทำอะไรใต้บัญชีนั้นก็ได้” นั่นคือการเปิดช่องโหว่ความปลอดภัยครั้งใหญ่ เพราะเป็นการให้สิทธิ์ทั้งหมดแก่ AI โดยไม่มีการตรวจสอบให้ดีก่อน
ปัญหาที่สามคือ Biometric Data หากองค์กรใช้ใบหน้า ลายนิ้วมือ หรือข้อมูลชีวภาพในการพิสูจน์ตัวตน ต้องระวังมากขึ้น เพราะ PDPA มาตรา 26 จัดข้อมูลชีวภาพไว้ในกลุ่มข้อมูลที่ได้รับการคุ้มครองเป็นพิเศษและมีเงื่อนไขในการประมวลผลสูงกว่าข้อมูลทั่วไป.
ปัญหาที่สี่คือ ความปลอดภัย (Cybersecurity) ไม่เท่ากับ ความเป็นส่วนตัว (Privacy) ถึงระบบจะแน่นหนา ป้องกันแฮกเกอร์ได้ 100% ก็ไม่ได้หมายความว่า เราใช้ข้อมูลถูกต้อง เพราะถ้าให้สิทธิ์คนเข้าถึงกว้างเกินไป หรือเอาข้อมูลไปเชื่อมโยงใช้ผิดวัตถุประสงค์ มันก็ยังเป็นการละเมิดความเป็นส่วนตัวอยู่ดี
PDPA กำหนดให้เราปรับมาตรการความปลอดภัยให้เหมาะกับความเสี่ยงอยู่เสมอ พอเทคโนโลยีเปลี่ยน ระบบก็ต้องเปลี่ยนตาม ด้วยเหตุนี้ ทีมดูแลความเป็นส่วนตัว ทีมความปลอดภัย และทีมวางระบบ เลยต้องคุยกันและทำงานไปพร้อมๆ กัน ไม่ใช่ต่างคนต่างทำฝั่งใครฝั่งมัน
ลืมงานเอกสารแบบเดิมไปได้เลย! ทำไมยุค AI ถึงต้องทำ PDPA ให้ลึกกว่านั้น ทีมกฎหมายควรเข้ามาช่วยดูตั้งแต่ช่วงวางแผนระบบ ก่อนที่ฝ่ายพัฒนาจะสรุปเรื่องการเก็บข้อมูล การระบุตัวตน และการให้สิทธิ์เข้าถึงเรียบร้อยแล้ว
ไม่จำเป็นต้องแก้ปัญหาด้วยวิธีเดียวกันเสมอไป
แนวทางหนึ่งที่บทความต้นทางเสนอคือการใช้ identifier หรือ token ที่ผูกกับบริบทและวัตถุประสงค์ แนวคิดง่ายมาก แทนที่จะให้ คนหนึ่งคน = identifier เดียวทุกระบบ อาจออกแบบเป็น คนหนึ่งคน → หลาย credential ตามบริบท เช่น
- ระบบธนาคารใช้ Token A
- ระบบสมาชิกใช้ Token B
- ระบบ Marketing ใช้ Token C
- ระบบ Partner ใช้ Token D
แต่ละฝ่ายจึงไม่จำเป็นต้องเห็น master identifier เดียวกัน
ะบบยืนยันตัวตนดิจิทัลในปัจจุบันเน้นการปกป้องข้อมูลของเราครับ เช่น ระบบ MOSIP จะมีฟีเจอร์สร้าง ‘ไอดีจำลอง’ เพื่อบังข้อมูลจริงไว้ ส่วนทางยุโรปก็กำลังทำแอปเก็บข้อมูลยืนยันตัวตนที่เน้นความปลอดภัย และจะดึงข้อมูลเราไปใช้แค่เท่าที่จำเป็นเท่านั้น
องค์กรยังไม่ต้องรีบเปลี่ยนไปใช้ Tokenization ทันที แต่ทีมออกแบบระบบควรประเมินได้ว่า ทำไมแต่ละระบบถึงจำเป็นต้องเห็นข้อมูลระบุตัวตนของจริง หากไม่มีเหตุผลรองรับ แสดงว่าระบบอาจอนุญาตให้เข้าถึงข้อมูลเกินความจำเป็น”
AI Agent ยิ่งทำให้เรื่องนี้สำคัญขึ้น
ใน Software แบบเดิม ผู้ใช้มักเป็นคนคลิกคำสั่งเอง แต่ AI Agent สามารถตัดสินใจเลือกเครื่องมือ เรียก API และดำเนินหลายขั้นตอนต่อเนื่องกัน ดังนั้น Model ที่ปลอดภัยกว่าไม่ควรเป็น: Login → AI ได้สิทธิทั้งหมดของ User แต่ควรเป็น: Identity → Purpose → Authorization → Action ทุก Action สำคัญควรตอบได้ว่า
- ใครกำลังร้องขอ
- ทำเพื่อวัตถุประสงค์อะไร
- ใช้ข้อมูลอะไร
- เรียกเครื่องมือใด
- มีสิทธิระดับไหน
- ต้องขออนุมัติเพิ่มหรือไม่
- มี Audit Trail หรือไม่
บทเรียนจากอดีตสอนให้รู้ว่า ในยุคที่ AI เก่งขึ้น ถึงแม้มันจะรู้จักตัวตนของเราดีแค่ไหน ก็ไม่ควรปล่อยให้มันตัดสินใจทำทุกอย่างแทนเราไปเสียหมด
ทำตามเพราะมีกฎสั่ง vs ทำตามเพราะระบบบังคับ
องค์กรแบบเดิมอาจเขียน Policy ว่า: “ห้ามนำข้อมูลจากระบบ A ไปใช้กับระบบ B โดยไม่ได้รับอนุญาต” นั่นคือ การมีกฎสั่ง แต่ Architecture ที่ดีกว่าอาจถามต่อว่า: “ทำอย่างไรให้ A กับ B เชื่อมกันไม่ได้โดยง่ายตั้งแต่แรก หากไม่มีเหตุผลและสิทธิที่ชัดเจน?” นี่คือ การทำตามเพราะระบบบังคับ
แต่ถ้าเราออกแบบระบบให้ป้องกันความเสี่ยงได้ตั้งแต่แรก ก็ย่อมดีกว่าการแค่ตั้งกฎว่า ‘ห้ามทำ
สิ่งที่ควรทำต่อ
1. ทำ Identifier Mapping
สำรวจว่าระบบ CRM, ERP, HR, Loyalty, Data Warehouse, Marketing และ AI ใช้อะไรเป็นกุญแจระบุตัวบุคคล โดยเฉพาะเลขบัตรประชาชน เบอร์โทร อีเมล และ customer ID
2. ตรวจ Cross-System Join
อย่าถามแค่ว่าใคร “เข้าถึงฐานข้อมูล” ได้ ให้ถามเพิ่มว่าใครสามารถ เชื่อมข้อมูลสองฐานเข้าด้วยกัน ได้ และเพื่อวัตถุประสงค์อะไร
3. แยก Authentication ออกจาก Authorization
การ Login, OTP, Face Scan หรือ Fingerprint ควรพิสูจน์ตัวตนเท่านั้น สิทธิในการทำ Transaction สำคัญควรถูกตรวจแยกตาม Action
4. ตรวจสิทธิของ AI Agent
ทำรายการว่า Agent แต่ละตัวอ่าน เขียน แก้ไข ส่ง หรืออนุมัติอะไรได้บ้าง และควรกำหนด Human Approval สำหรับกิจกรรมที่มีผลกระทบสูง
5. พิจารณา Purpose-bound Identifier
ระบบใหม่ควรถามตั้งแต่ Design Review ว่า Partner หรือ Subsystem จำเป็นต้องเห็น identifier ตัวจริงหรือสามารถใช้ token, pseudonymous ID หรือ identifier เฉพาะบริบทแทนได้
มุมมองผู้เชี่ยวชาญ
“หลายองค์กรคิดว่า PDPA เริ่มตอนเขียน Privacy Notice แต่ในความจริง ความเสี่ยงอาจเกิดก่อนหน้านั้นเป็นปี ตั้งแต่ทีม IT ตัดสินใจว่าจะใช้ ID อะไรเชื่อมฐานข้อมูล ถ้าออกแบบให้ทุกระบบ ถือกุญแจดอกเดียวกัน ต่อให้เอกสารถูกหมด เราก็ยังสร้างความเสี่ยงไว้ในระบบอยู่ดี”
— Phuwara Krobtaku —
LL.M. (IP & IT) | M.S. (IT) | เนติบัณฑิต & ทนายความ
แหล่งอ้างอิง
- Tech Policy Press — Subhashis Banerjee, “Aadhaar’s Success Story Deserves a Closer Look,” 14 August 2026
https://www.techpolicy.press/aadhaars-success-story-deserves-a-closer-look/
ต้นฉบับยืนยันประเด็น common identifier, authentication/authorization, Airtel และ purpose-bound identity. - พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 — ราชกิจจานุเบกษา
https://www.ratchakitcha.soc.go.th/DATA/PDF/2562/A/069/T_0052.PDF
มาตรา 22 ว่าด้วยการเก็บข้อมูลเท่าที่จำเป็น มาตรา 23 เรื่องวัตถุประสงค์ และมาตรา 26 เกี่ยวกับข้อมูลชีวภาพ. - ประกาศคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล เรื่องมาตรการรักษาความมั่นคงปลอดภัยของผู้ควบคุมข้อมูลส่วนบุคคล พ.ศ. 2565
กำหนดมาตรการเชิงองค์กรและเชิงเทคนิคตามความเสี่ยง และการทบทวนมาตรการเมื่อเทคโนโลยีเปลี่ยนแปลง. - MOSIP Documentation — Virtual ID Support
ใช้อ้างอิงว่าระบบ Digital Identity สามารถออกแบบให้รองรับ Virtual ID ได้จริง. - Regulation (EU) 2024/1183 — European Digital Identity Framework
กรอบของ EU กล่าวถึง privacy-preserving technologies, การลดการประมวลผลเกินจำเป็น และแนวคิด secure-by-design สำหรับ Digital Identity Wallet.
