บทนำ
ลองนึกภาพบริษัทแห่งหนึ่งกำลังสร้าง AI ของตัวเอง ทีม Data บอกว่า “ข้อมูลอยู่บนอินเทอร์เน็ต ใครก็เข้าได้” ทีม AI จึงทำ Web Scraping ดึงข้อมูลจำนวนมหาศาลเข้า Dataset แล้วนำไปฝึกโมเดล ทุกอย่างดูเหมือนเป็นเรื่องของเทคโนโลยี
แต่คำถามที่ฝ่ายกฎหมายอาจถามภายหลังคือ
“ข้อมูลชุดนี้มาจากไหน และตอนเอามา คุณมีเหตุผลทางกฎหมายอะไร?”
นี่คือเหตุผลที่ข่าวล่าสุดจาก European Data Protection Board หรือ EDPB น่าสนใจกว่าการเป็นเพียง Guideline ของยุโรป
เมื่อวันที่ 8 กรกฎาคม 2569 EDPB รับรองแนวทางเกี่ยวกับการทำ Anonymisation และ Web Scraping ในบริบทของ Generative AI โดยแนวทาง Web Scraping ยังเปิดรับความคิดเห็นสาธารณะจนถึง 30 ตุลาคม 2569 ดังนั้น ณ ตอนนี้ควรมองเป็นกรอบแนวทางที่อยู่ระหว่างกระบวนการรับฟังความเห็น ไม่ใช่กฎหมายใหม่ที่มีผลใช้บังคับในไทย
และสำหรับธุรกิจไทย สิ่งที่น่าสนใจที่สุดอาจไม่ใช่ “ยุโรปกำลังจะควบคุม AI อย่างไร”
แต่คือ ยุโรปกำลังบอกองค์กรว่า ก่อนจะเอาข้อมูลไปสร้าง AI ต้องรู้ก่อนว่าข้อมูลนั้นมาจากไหน และยังเป็นข้อมูลส่วนบุคคลอยู่หรือไม่
EDPB กำลังวาง “ด่านตรวจ” ให้ข้อมูลก่อนเข้าสู่ AI
EDPB ระบุว่า Web Scraping ที่เกี่ยวข้องกับการเก็บ จัดเก็บ จัดระเบียบ หรือเรียกใช้ข้อมูลส่วนบุคคล อยู่ภายใต้ GDPR แม้ข้อมูลนั้นจะถูกเผยแพร่ไว้บนเว็บไซต์ก็ตาม นี่เป็นจุดที่ธุรกิจต้องแยกให้ออกระหว่าง
“ข้อมูลเปิดให้คนเห็น” กับ “องค์กรมีสิทธิ์นำข้อมูลนั้นไปใช้ทุกวัตถุประสงค์” สองเรื่องนี้ไม่ใช่เรื่องเดียวกัน แนวทางของ EDPB ให้ความสำคัญกับหลายเรื่อง เช่น
- วัตถุประสงค์ของการนำข้อมูลไปใช้
- ความโปร่งใสต่อเจ้าของข้อมูล
- ฐานทางกฎหมายสำหรับการประมวลผล
- การลดการเก็บข้อมูลที่ไม่จำเป็น
- ความถูกต้องของข้อมูล
- การจัดการข้อมูลอ่อนไหว
- การเก็บหลักฐานเกี่ยวกับแหล่งที่มาและกระบวนการของข้อมูล
โดย EDPB ยังแนะนำให้ผู้ทำ Web Scraping ใช้แหล่งข้อมูลที่น่าเชื่อถือ บันทึกช่วงเวลาที่ดึงข้อมูล และตรวจสอบความถูกต้องก่อนนำข้อมูลไปใช้ฝึก AI
อีกเรื่องที่สำคัญ คือ “Anonymised” หรือ ข้อมูลนิรนาม ไม่ใช่แค่ลบชื่อ
ในแนวทาง Anonymisation นั้น ทาง EDPB ได้เสนอกรอบตรวจสอบ 3 เรื่อง ได้แก่
- บุคคลยังสามารถถูกแยกออกจากคนอื่นในชุดข้อมูลได้หรือไม่
- สามารถนำข้อมูลหลายชุดมาเชื่อมโยงจนกลับไปหาบุคคลได้หรือไม่
- สามารถอนุมานข้อมูลเกี่ยวกับบุคคลจากข้อมูลที่เหลืออยู่ได้หรือไม่
หากไม่ผ่านเกณฑ์เหล่านี้ ก็ไม่ควรรีบสรุปว่าข้อมูลกลายเป็น “ข้อมูลนิรนาม” แล้ว
“ลบชื่อออก ไม่ได้แปลว่าลบตัวบุคคลออกจากข้อมูล”
ผลกระทบต่อธุรกิจในประเทศไทย: ปัญหาจริงอาจไม่ใช่ AI แต่คือ “Data Lineage”
ถ้าบริษัทไทยสร้าง AI โดยใช้ข้อมูลของตัวเองทั้งหมด ความเสี่ยงส่วนหนึ่งยังสามารถจัดการผ่านกระบวนการภายในได้
แต่ทันทีที่บริษัทเริ่มใช้ข้อมูลจากภายนอก เช่น เว็บไซต์ Social Media เว็บรีวิว เว็บบอร์ด ข่าว หรือข้อมูลที่ซื้อจากผู้ให้บริการภายนอก โจทย์จะเปลี่ยนทันที
เพราะฝ่าย AI อาจเห็นเพียงว่า
Source → Dataset → Model
แต่ฝ่ายกฎหมายต้องการเห็นละเอียดกว่านั้นว่า
ข้อมูลมาจากไหน → ดึงเมื่อไร → ดึงด้วยวิธีอะไร → มีข้อมูลส่วนบุคคลอะไรปะปน → ใช้ฐานอะไร → ใช้เพื่อวัตถุประสงค์อะไร → ผ่านการคัดกรองอย่างไร → ใครอนุมัติ → ส่งต่อให้ใคร → ใช้ใน Model ไหน
นี่เรียกว่า Data Lineage ในภาษาง่ายๆ คือ “ประวัติการเดินทางของข้อมูล” และนี่คือจุดที่แนวทางของ EDPB น่าสนใจสำหรับไทย
แม้ Guideline ของ EDPB จะไม่ใช่กฎหมายไทย และไม่ได้ทำให้บริษัทไทยต้องปฏิบัติตาม GDPR โดยอัตโนมัติ แต่กรอบคิดนี้สามารถใช้เป็น Benchmark ในการออกแบบ AI Governance ได้ โดยเฉพาะบริษัทที่มีลูกค้าในยุโรป หรือ ประมวลผลข้อมูลของบุคคลใน EU
ที่สำคัญกว่านั้น คือ บริษัทไทยไม่ควรรอให้เกิดปัญหาแล้วค่อยย้อนกลับไปถามว่า “Dataset นี้เอามาจากไหน” เพราะเมื่อข้อมูลถูกใช้ฝึก Model ไปแล้ว การย้อนหาแหล่งที่มาอาจทำได้ยากกว่าตอนที่ข้อมูลยังอยู่หน้าประตู
“AI Governance ที่ดี ไม่ได้เริ่มตอน Model ตอบผิด แต่เริ่มตอนองค์กรตัดสินใจว่า ข้อมูลชุดไหนมีสิทธิ์นำไปฝึก Model ได้”
สำหรับองค์กรขนาดใหญ่ เรื่องนี้จึงไม่ควรเป็นงานของ DPO หรือฝ่ายกฎหมายเพียงฝ่ายเดียว ควรเกี่ยวข้องกับอย่างน้อย Data Team, AI/Engineering, Security, Procurement, Legal และ Business Owner
โดยเฉพาะ Procurement เพราะถ้าองค์กรซื้อ Dataset จาก Vendor แล้ว Vendor ตอบเพียงว่า “เป็นข้อมูลสาธารณะ” คำตอบนั้นไม่ควรจบกระบวนการตรวจสอบ
คำถามต่อไปควรเป็นว่า
ข้อมูลมาจากไหน? เก็บอย่างไร? มีสิทธิ์ใช้เพื่ออะไร? มีข้อมูลส่วนบุคคลหรือข้อมูลอ่อนไหวปะปนหรือไม่? และ Vendor มีหลักฐานอะไรยืนยันเรื่องเหล่านี้?
นี่คือการเปลี่ยนจาก “ซื้อข้อมูลเพื่อสร้าง AI” ไปเป็น “ซื้อข้อมูลพร้อมหลักฐานการกำกับดูแล”
สิ่งที่ควรทำต่อ
- ทำบัญชีแหล่งข้อมูลที่ AI ใช้อยู่ — ระบุว่า Dataset แต่ละชุดมาจากเว็บไซต์ Vendor API Social Media หรือแหล่งใด
- เพิ่ม Source + Timestamp ให้ Dataset — เก็บหลักฐานว่าองค์กรได้ข้อมูลมาจากไหนและเมื่อใด
- แยกข้อมูลส่วนบุคคลออกจากข้อมูลทั่วไป — อย่าถือว่าข้อมูลที่เผยแพร่สาธารณะเป็นข้อมูลที่ใช้ได้โดยไม่มีข้อจำกัด
- ตรวจข้อมูลอ่อนไหวก่อนเข้า Training Pipeline — เพราะ EDPB ระบุว่าการประมวลผลข้อมูลประเภทพิเศษต้องมีทั้งฐานทางกฎหมายและเงื่อนไขเพิ่มเติมที่เกี่ยวข้อง
- กำหนดผู้อนุมัติก่อนนำ Dataset เข้า AI — ให้มีคนรับผิดชอบคำถามว่า “ข้อมูลชุดนี้เข้า Model ได้หรือไม่ และเพราะอะไร”
มุมมองผู้เชี่ยวชาญ
“ผมมองว่าเรื่องนี้ไม่ใช่แค่เรื่อง Web Scraping แต่เป็นเรื่องว่า องค์กรรู้จักข้อมูลของตัวเองดีแค่ไหน เพราะถ้าเราตอบไม่ได้ว่าข้อมูล AI มาจากไหน ต่อให้ Model เก่งแค่ไหน ฝ่ายกฎหมายก็อธิบายแทนเราไม่ได้”
อีกประเด็นที่ผมคิดว่าสำคัญมาก คือ อย่ารอให้กฎหมายไทยเขียนออกมาเหมือนยุโรปแล้วค่อยเริ่มทำ
องค์กรสามารถใช้แนวทางแบบนี้เป็นมาตรฐานภายในก่อนได้เลย โดยเฉพาะการเก็บ Source, วันที่ดึงข้อมูล, วัตถุประสงค์, การตรวจข้อมูลส่วนบุคคล และผู้อนุมัติ เพราะสุดท้ายแล้ว AI ที่ดีไม่ได้มีแค่เรื่อง “ตอบเก่ง”
แต่ต้องตอบได้ด้วยว่า “ข้อมูลที่ทำให้มันเก่ง มาจากไหน”
แหล่งอ้างอิง
European Data Protection Board (EDPB) — EDPB sheds light on anonymisation and web scraping for generative AI and adopts final version of guidelines on blockchain, 8 July 2026.
อ่านต้นฉบับจาก European Data Protection Board
European Data Protection Board (EDPB) — Guidelines 03/2026 on web scraping in the context of generative AI — เปิดรับความคิดเห็นถึง 30 October 2026.
อ่านหน้า Public Consultation ของ EDPB
