บทนำ
ข่าวที่หลายองค์กรควรจับตาไม่ใช่แค่เรื่อง “ฐานข้อมูลเงา” ของ SCHUFA ในเยอรมนี แต่คือคำถามที่อยู่ข้างใต้ว่า ถ้าบริษัทบอกว่าลบข้อมูลแล้ว แต่ยังเก็บข้อมูลชุดนั้นไว้เพื่อทดสอบโมเดลหรือระบบหลังบ้าน ถือว่าลบจริงหรือยัง เมื่อวันที่ 26 สิงหาคม 2026 องค์กรด้านสิทธิข้อมูล noyb ส่งหนังสือเตือนทางกฎหมายต่อ SCHUFA และเตรียมเดินหน้าขอคำสั่งศาล โดยกล่าวหาว่าบริษัทยังคงเก็บข้อมูลประวัติของผู้บริโภคจำนวนมาก และไม่ได้เปิดเผยข้อมูลประวัติเหล่านั้นเมื่อเจ้าของข้อมูลใช้สิทธิขอเข้าถึงข้อมูลตาม GDPR
สิ่งที่เกิดขึ้นจริง
จุดเริ่มต้นของเรื่องมาจากการรายงานร่วมของ NDR และ Süddeutsche Zeitung ในเดือนกรกฎาคม 2026 ซึ่งพบว่า SCHUFA มีข้อมูลประวัติของผู้บริโภคจำนวนมากนอกเหนือจากข้อมูลที่ใช้ในระบบปัจจุบัน โดยข้อมูลที่กล่าวถึงมีทั้งประวัติสินเชื่อ บัตรเครดิต หนี้ และข้อมูลทางการเงินในอดีต
SCHUFA ไม่ได้ปฏิเสธว่ามีข้อมูลประวัติ แต่บริษัทอธิบายว่าข้อมูลดังกล่าวอยู่ในส่วนจัดเก็บแยกจากระบบที่ใช้ประเมินเครดิตในปัจจุบัน และมีเหตุผลด้านการตรวจสอบ การปฏิบัติตามข้อกำหนด การควบคุมคุณภาพ และการพัฒนาระบบคะแนนเครดิต โดยบริษัทระบุว่าข้อมูลประวัติบางส่วนสามารถนำมาใช้สร้างคะแนนย้อนหลังเพื่อทดสอบคุณภาพของโมเดลใหม่กับลูกค้าบางประเภทได้
นี่คือจุดที่ข้อพิพาทเปลี่ยนจากเรื่อง “บริษัทเก็บข้อมูลเก่า” ไปเป็นเรื่องที่ใหญ่กว่า เพราะ noyb มองว่าหากข้อมูลยังถูกเก็บและถูกนำไปใช้ในการประมวลผล ข้อมูลนั้นอาจไม่ได้หายไปตามความหมายของคำว่า “ลบ” และหากข้อมูลดังกล่าวยังอยู่ในระบบ เจ้าของข้อมูลก็ควรมีสิทธิรับรู้และเข้าถึงข้อมูลตามกฎหมายที่เกี่ยวข้อง
อีกประเด็นที่สำคัญคือสิทธิในการขอสำเนาข้อมูลตาม Article 15 GDPR โดยศาลยุติธรรมแห่งสหภาพยุโรปเคยวางหลักว่าการให้ “สำเนา” ข้อมูลต้องเป็นการทำให้เจ้าของข้อมูลได้รับข้อมูลส่วนบุคคลที่เกี่ยวข้องอย่างครบถ้วนและเข้าใจได้ ไม่ใช่เพียงสรุปเฉพาะข้อมูลบางส่วนที่องค์กรเห็นว่าสำคัญ
noyb ระบุว่ามีผู้ที่อาจได้รับผลกระทบถึงประมาณ 69 ล้านคน และเปิดรายชื่อสำหรับผู้ที่อาจเข้าร่วมการดำเนินคดีเรียกค่าเสียหายในอนาคต โดยอ้างว่ามีคำขอเข้าถึงข้อมูลจำนวนมากที่อาจได้รับข้อมูลไม่ครบถ้วน ตัวเลขเหล่านี้ยังเป็นข้อกล่าวอ้างของ noyb และไม่ควรถูกตีความว่าเป็นคำพิพากษาว่า SCHUFA กระทำผิดแล้ว
ทำไมเรื่องนี้ถึงสำคัญกับธุรกิจไทยมากกว่าที่คิด
บริษัทไทยจำนวนมากอาจมองว่าคดี SCHUFA เป็นเรื่องของบริษัทเครดิตในยุโรป แต่โครงสร้างปัญหานี้จริงๆ แล้วอยู่ใกล้กับธุรกิจไทยมาก โดยเฉพาะองค์กรที่ทำ Data Analytics, AI, Fraud Detection, Customer Scoring หรือระบบคาดการณ์ต่างๆ
ลองนึกภาพง่ายๆ ว่า บริษัทประกาศว่า “ข้อมูลชุดนี้หมดอายุและลบแล้ว” แต่ทีม Data Science ยังเก็บสำเนาเอาไว้ใน Data Lake เพื่อใช้ Backtesting ทีม IT เก็บ Snapshot ไว้เพื่อ Disaster Recovery และทีม Product มีข้อมูลอีกชุดหนึ่งเพื่อทดสอบโมเดลเวอร์ชันใหม่ เมื่อฝ่าย Privacy ได้รับคำขอจากเจ้าของข้อมูล ก็ส่งข้อมูลเฉพาะจากระบบ Production แล้วแจ้งว่าไม่มีข้อมูลอื่นที่เกี่ยวข้อง
ในมุมธุรกิจ ระบบอาจดูเหมือนทำงานปกติ แต่ในมุมการกำกับข้อมูล คำถามจะเกิดขึ้นทันทีว่า ข้อมูลที่ยังอยู่ใน Archive, Backup หรือระบบทดสอบนั้นถูกลบจริงหรือไม่ และองค์กรยังถือว่ากำลังประมวลผลข้อมูลนั้นอยู่หรือไม่
ปัญหายิ่งชัดเมื่อข้อมูลเก่าถูกนำไปใช้เพื่อพัฒนาโมเดล เพราะองค์กรอาจไม่ได้เปิดเผยข้อมูลดิบให้ลูกค้าหรือคู่ค้า แต่กลับนำข้อมูลดังกล่าวไปคำนวณเป็น Score, Prediction หรือ Model Output แล้วส่งผลลัพธ์ไปยังบุคคลที่สาม กรณี SCHUFA จึงมีคุณค่ามากในฐานะบทเรียนว่า “เราไม่ได้ส่งข้อมูลดิบ” ไม่ได้ทำให้คำถามด้าน Privacy หายไปโดยอัตโนมัติ
สำหรับบริษัทไทยที่อยู่ภายใต้ PDPA ประเด็นสำคัญจึงไม่ใช่แค่การกำหนด Retention Period บนเอกสาร Privacy Policy แต่ต้องตอบให้ได้ว่า เมื่อถึงวันครบกำหนด ข้อมูลถูกลบจากทุกระบบที่ยังนำไปใช้ได้จริงหรือไม่ และมีหลักฐานอะไรยืนยันเรื่องนี้
อีกจุดที่ควรจับตาคือคำขอใช้สิทธิ เจ้าของข้อมูลไม่จำเป็นต้องรู้ชื่อฐานข้อมูลภายในขององค์กร หากองค์กรมีข้อมูลของเขาอยู่ในระบบ Archive หรือระบบทดสอบ แต่ทีมตอบ Subject Access Request โดยดึงเฉพาะข้อมูลจาก Production ก็อาจเกิดช่องว่างระหว่าง “ข้อมูลที่องค์กรมีจริง” กับ “ข้อมูลที่องค์กรเปิดเผยให้เจ้าของข้อมูลเห็น”
นี่เป็นความเสี่ยงเชิงระบบ ไม่ใช่แค่ความผิดพลาดของเจ้าหน้าที่ Privacy คนเดียว เพราะต้นเหตุอาจเริ่มตั้งแต่การออกแบบ Data Architecture ที่ไม่ได้แยกให้ชัดเจนว่าอะไรคือข้อมูลที่ใช้ปฏิบัติงาน อะไรคือข้อมูลที่เก็บเพื่อ Audit และอะไรคือข้อมูลที่ยังนำไปใช้เพื่อ Model Validation
กรณี SCHUFA จึงควรถูกอ่านในฐานะคำเตือนสำหรับทุกองค์กรที่มี Data Lifecycle ซับซ้อน โดยเฉพาะองค์กรที่ใช้ AI ว่า การเก็บข้อมูลเพื่อ “ทดสอบ” อาจยังเป็นการใช้ข้อมูล ไม่ใช่พื้นที่ปลอดภัยที่อยู่นอกระบบ Privacy โดยอัตโนมัติ
สิ่งที่ควรทำต่อ
- ทำ Data Discovery ให้ครบทั้ง Production และ Non-Production
ตรวจว่าข้อมูลส่วนบุคคลอยู่ที่ไหนบ้าง รวมถึง Data Lake, Archive, Backup, Sandbox, Test Environment และระบบของ Vendor - แยกคำว่า “ลบ” ออกจากคำว่า “ซ่อน”
ตรวจว่าเมื่อครบ Retention Period แล้ว ข้อมูลถูกลบจริง หรือเพียงถูกนำออกจากหน้าจอผู้ใช้งาน - ตรวจเส้นทางของ Historical Data
ระบุว่าข้อมูลเก่าถูกนำไปใช้กับ Analytics, AI Training, Backtesting, Quality Assurance หรือ Model Validation หรือไม่ - ทดสอบกระบวนการตอบคำขอใช้สิทธิจริง
ลองจำลองคำขอเข้าถึงข้อมูล แล้วตรวจว่าระบบสามารถค้นหา Historical Data ที่ยังอยู่และยังถูกประมวลผลได้ครบหรือไม่ - ให้ Privacy, Legal, IT และ Data Science ตรวจ Retention ร่วมกัน
Retention ไม่ควรเป็นเรื่องของฝ่ายกฎหมายเพียงฝ่ายเดียว เพราะข้อมูลอาจยังถูกเก็บหรือใช้ในระบบที่ทีมกฎหมายไม่ได้เห็น
แหล่งอ้างอิง
PPC Land — “SCHUFA faces injunction over shadow database on 69 million consumers”
noyb — European Centre for Digital Rights — “Shadow database scandal: noyb sends SCHUFA cease-and-desist letter; interest list for class action opened”
NDR — รายงานกรณี SCHUFA และข้อมูลประวัติของผู้บริโภคที่ถูกเก็บไว้เป็นเวลานาน
ศาลยุติธรรมแห่งสหภาพยุโรป (CJEU) — คดี C-487/21 ว่าด้วยสิทธิในการได้รับสำเนาข้อมูลตาม Article 15 GDPR
ลิงก์ต้นฉบับ PPC Land: อ่านบทความต้นฉบับจาก PPC Land
