การสร้างระบบ AI ภายในองค์กรเริ่มง่ายขึ้นมาก ทีมงานสามารถดึงหน้าเว็บไซต์ เอกสารภายใน คู่มือสินค้า บันทึกบริการลูกค้า หรือฐานความรู้จำนวนมากมาใส่ใน RAG และทดลอง Fine-tune ได้ภายในเวลาไม่นาน แต่ความเร็วในการนำข้อมูลเข้าไม่ได้แปลว่าข้อมูลนั้น มีสิทธิใช้ เหมาะกับวัตถุประสงค์ ถูกต้อง หรือปลอดภัยสำหรับ AI
คำว่า “ข้อมูลสาธารณะ” บอกเพียงว่าเข้าถึงได้ในบริบทหนึ่ง ไม่ได้ตอบว่าองค์กรควรเก็บซ้ำ ประมวลผลเชิงพาณิชย์ เชื่อมกับข้อมูลอื่น หรือใช้ฝึกโมเดลได้หรือไม่ และการลบชื่อกับอีเมลออกก็อาจยังเหลือรายละเอียดที่ทำให้แยก เชื่อมโยง หรืออนุมานกลับไปหาบุคคลได้
บทความนี้เสนอ Data Provenance Gate 8 ด่าน สำหรับผู้บริหาร เจ้าของข้อมูล ทีม AI, DPO, Legal, Security และ Procurement ใช้ร่วมกันก่อนอนุมัติข้อมูลเข้าสู่ Scrape, RAG, Fine-tune หรือ Evaluation Pipeline เป้าหมายไม่ใช่ทำให้ทุกโครงการช้าลง แต่ทำให้ทีมรู้ว่า “ข้อมูลชุดนี้มาจากไหน ใช้เพื่ออะไร ผ่านเงื่อนไขใด และต้องหยุดใช้เมื่อใด”
Executive Summary
- Publicly Accessible ไม่เท่ากับ Approved for AI Use; ต้องตรวจวัตถุประสงค์ สิทธิ ข้อกำหนดเว็บไซต์ และข้อมูลส่วนบุคคลแยกกัน
- Data Provenance ต้องตามเส้นทางตั้งแต่ Source → Collection → Transform → Dataset Version → Model/RAG Index → Output ไม่ใช่เก็บเพียง URL ต้นทาง
- แยก Anonymous, Pseudonymous และ Identifiable Data ให้ชัด การแทนชื่อด้วยรหัสยังอาจเป็นข้อมูลที่เชื่อมกลับได้
- ก่อนนำข้อมูลเข้า AI ควรมี Quarantine Zone, Data Card, Owner, Retention, Removal Path และหลักฐานอนุมัติ
- การตรวจความเป็นนิรนามควรทดสอบความเสี่ยงด้านการแยกระเบียน การเชื่อมโยง และการอนุมาน ไม่ใช่ดูเพียงว่ามีชื่อหรือไม่
- RAG ไม่ได้ยกเว้นเรื่องข้อมูล เพราะยังมีการเก็บ จัดทำดัชนี ค้นคืน แสดงผล และบันทึก Log
- KPI ต้องวัด Provenance Coverage, Rights Review, Sensitive Data Leakage, Removal SLA และ Dataset Drift ควบคู่กับ Accuracy
ทำไมประเด็นนี้สดใหม่ในปี 2026
European Data Protection Board หรือ EDPB เผยแพร่ Guidelines 03/2026 เมื่อ 8 กรกฎาคม 2026 เพื่อเปิดรับความคิดเห็นถึง 30 ตุลาคม 2026 แนวทางนี้กล่าวถึง Web Scraping สำหรับ Generative AI โดยตรง ทั้ง Legal Basis, Purpose Limitation, Transparency, Special Categories, Accuracy และ Data Minimisation
EDPB แนะนำให้เลือกแหล่งข้อมูลที่น่าเชื่อถือ บันทึกเวลาเก็บ และตรวจสอบข้อมูลก่อนใช้ฝึก AI ขณะเดียวกัน Guidelines 02/2026 on Anonymisation เสนอกรอบทดสอบ 3 ประเด็น ได้แก่ ไม่สามารถแยกระเบียนของบุคคล ไม่สามารถเชื่อมโยงข้อมูล และไม่สามารถอนุมานข้อมูลเกี่ยวกับบุคคลได้
ต้องอ่านสถานะเอกสารอย่างระมัดระวัง: ทั้งสองฉบับยังอยู่ในกระบวนการรับฟังความคิดเห็น ไม่ใช่มาตรฐานสากลที่มีผลกับทุกองค์กรไทยโดยอัตโนมัติ แต่เป็นสัญญาณเชิงกำกับดูแลที่มีประโยชน์ต่อการออกแบบ Control ส่วนการใช้ข้อมูลในประเทศไทยต้องประเมินตาม พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 กฎหมายเฉพาะ สัญญา และบริบทของหน่วยงาน โดยให้ DPO หรือที่ปรึกษากฎหมายพิจารณากรณีจริง
ในมิติ Governance ไทย ETDA เปิด AI Governance Week 2026 เมื่อ 29 มิถุนายน 2026 พร้อมผลักดัน AI EIA Playbook, Toolkits และ AI Red Teaming เพื่อเชื่อมหลักการสู่การปฏิบัติ ประเด็นสำคัญจึงไม่ใช่เพียง “มีนโยบายข้อมูล” แต่ต้องสร้างจุดตรวจที่ทีมทำตามได้ใน Pipeline จริง
4 ความเข้าใจผิดที่ทำให้ข้อมูลเสี่ยงเข้าสู่ AI
1. “ค้นเจอใน Google แปลว่าใช้ได้”
Search Engine ช่วยให้ค้นพบข้อมูล แต่ไม่ได้โอนสิทธิ เปลี่ยนวัตถุประสงค์เดิม หรือรับรองว่าข้อมูลถูกต้องและเป็นปัจจุบัน ต้องย้อนกลับไปดู Source, Terms, เจ้าของเนื้อหา และข้อจำกัดของข้อมูลแต่ละประเภท
2. “ลบชื่อแล้วเท่ากับ Anonymous”
ตำแหน่งงาน พื้นที่ เวลา เหตุการณ์เฉพาะ ประวัติธุรกรรม หรือข้อความอิสระอาจทำให้บุคคลถูกแยกจากกลุ่มและเชื่อมกับข้อมูลภายนอกได้ การแทนชื่อด้วยรหัสคือ Pseudonymisation หากยังมี Key หรือวิธีเชื่อมกลับ ไม่ควรเรียกว่า Anonymous
3. “ใช้ RAG จึงไม่ถือว่าใช้ข้อมูลฝึก AI”
RAG อาจไม่ปรับ Weight ของโมเดล แต่ยังสร้างสำเนา Chunk, Embedding, Index, Cache, Prompt และ Log พร้อมนำข้อมูลไปสร้างคำตอบ ความเสี่ยงจึงย้ายจาก Training ไปยัง Retrieval, Access Control, Output และ Retention ไม่ได้หายไป
4. “Vendor รับผิดชอบข้อมูลทั้งหมด”
Vendor อาจดูแล Infrastructure หรือ Model แต่หน่วยงานยังต้องรู้ว่าตนส่งข้อมูลใด ใครเข้าถึงได้ เก็บที่ใด นานเท่าใด ใช้ปรับปรุงบริการหรือไม่ และลบออกจากทุกสำเนาได้อย่างไร ขอบเขตความรับผิดชอบต้องปรากฏในสัญญาและการปฏิบัติจริง
Data Provenance Gate 8 ด่าน
ด่านที่ 1 — Purpose & Outcome: ระบุว่าจะใช้ข้อมูลทำอะไร
เขียนวัตถุประสงค์ให้เฉพาะ เช่น “สร้างระบบค้นคู่มือเครื่องจักรสำหรับช่างที่ได้รับสิทธิ” แทน “นำข้อมูลไปพัฒนา AI” ระบุผู้ใช้ ผลลัพธ์ การตัดสินใจที่เกี่ยวข้อง และสิ่งที่ AI ห้ามทำ หากวัตถุประสงค์กว้างเกินไปจะประเมินความจำเป็นและความเสี่ยงไม่ได้
ด่านที่ 2 — Source & Authority: รู้แหล่งและผู้มีอำนาจอนุมัติ
บันทึก Source URL หรือระบบต้นทาง เจ้าของข้อมูล ผู้เผยแพร่ วันที่เข้าถึง รุ่นเอกสาร เงื่อนไขการใช้ License, Robots/Access Rule, Contract และช่องทางติดต่อ อย่าใช้ชื่อโฟลเดอร์หรือคำว่า “ข้อมูลจากอินเทอร์เน็ต” แทนหลักฐานต้นทาง
ด่านที่ 3 — Data Classification: ตรวจข้อมูลบุคคลและข้อมูลสำคัญ
สแกนทั้ง Structured Field, Free Text, รูปภาพ เสียง Metadata และเอกสารแนบ แยกข้อมูลทั่วไป ข้อมูลส่วนบุคคล ข้อมูลที่มีความอ่อนไหว ความลับทางธุรกิจ ทรัพย์สินทางปัญญา และข้อมูลที่กระทบความมั่นคงหรือความปลอดภัย ให้ทีมงานกำหนดสิ่งที่ห้ามนำเข้าโดยเด็ดขาด
ด่านที่ 4 — Lawful Use & Rights Review: ตรวจฐานและข้อจำกัด
ให้เจ้าของข้อมูลร่วมกับ DPO/Legal ตรวจว่าองค์กรมีฐานหรืออำนาจใดสำหรับการเก็บ ใช้ เชื่อม และเปิดเผย รวมถึงต้องแจ้งบุคคลหรือรองรับสิทธิอย่างไร อย่าใช้ “ความยินยอม” เป็นคำตอบอัตโนมัติ และอย่าใช้ Legitimate Interest ของกรอบต่างประเทศแทนการวิเคราะห์กฎหมายไทย
EDPB Opinion 28/2024 ชี้ว่าการพิจารณาความเป็นนิรนาม ฐาน Legitimate Interest และผลของข้อมูลที่ถูกประมวลผลโดยไม่ชอบต้องประเมินตามกรณี แนวคิดที่นำมาใช้ได้คือเก็บเหตุผลและหลักฐาน ไม่ตัดสินจากป้ายกำกับสั้น ๆ
ด่านที่ 5 — Necessity & Minimisation: เก็บเท่าที่จำเป็น
ถามว่าต้องใช้ข้อมูลระดับบุคคลจริงหรือไม่ ลดช่วงเวลา ฟิลด์ ความละเอียด จำนวน Source และระยะเก็บได้หรือไม่ ตัวอย่างเช่น ระบบตอบนโยบายอาจใช้เอกสารที่อนุมัติแล้วโดยไม่ต้องใส่อีเมลสนทนา หรือระบบวิเคราะห์แนวโน้มอาจใช้ข้อมูลรวมแทนประวัติรายบุคคล
ด่านที่ 6 — Provenance Ledger: บันทึกทุกการเปลี่ยนผ่าน
กำหนด Dataset ID และ Version พร้อมบันทึกว่าใครเก็บ เมื่อใด ใช้ Tool ใด ตัดอะไรออก Deduplicate อย่างไร ใคร Label, QA หรืออนุมัติ เชื่อม Dataset Version กับ RAG Index, Model Version, Prompt และ Evaluation Set เพื่อให้ย้อนกลับได้เมื่อพบ Source ผิดหรือมีคำขอลบ
NCSC Secure AI Development Guidance แนะนำให้จัดทำเอกสารแหล่ง Training/Fine-tuning Data, ขอบเขต ข้อจำกัด Retention และ Failure Mode รวมถึงใช้ Data Card, Model Card และ Hash/Signature ตามความเหมาะสม
ด่านที่ 7 — De-identification & Attack Test: ทดสอบก่อนเรียกว่านิรนาม
แยกข้อมูลไปยัง Quarantine Zone แล้วทำ Masking, Generalisation, Aggregation, Suppression หรือเทคนิค Privacy-Enhancing ตามความเสี่ยง จากนั้นทดสอบ 3 เรื่อง: แยกคนหนึ่งออกจากกลุ่มได้หรือไม่ เชื่อมกับฐานอื่นได้หรือไม่ และอนุมานข้อมูลใหม่เกี่ยวกับบุคคลได้หรือไม่
การผ่านเทคนิคหนึ่งครั้งไม่ใช่สถานะถาวร เพราะข้อมูลภายนอกและความสามารถของเครื่องมือเปลี่ยนได้ ต้องบันทึก Threat Model, ผู้ทดสอบ วันที่ และเงื่อนไขที่ต้องทดสอบซ้ำ
ด่านที่ 8 — Lifecycle, Removal & Redress: ออกแบบวันสิ้นสุดตั้งแต่ต้น
กำหนด Retention, Review Date, Removal Trigger, Responsible Owner และวิธีลบจาก Raw File, Processed Dataset, Embedding, Cache, Backup และ Log ระบุช่องทางรับคำขอหรือข้อร้องเรียน พร้อมกระบวนการหยุด Source ที่ผิดและแก้คำตอบที่ได้รับผลกระทบ
หากลบข้อมูลจากคลังต้นฉบับแต่ยังอยู่ใน Vector Index หรือ Evaluation Set องค์กรยังปิดวงจรไม่ครบ การทดสอบ Removal จึงควรเป็นส่วนหนึ่งของ Acceptance Test ไม่ใช่รอเหตุจริง
สถาปัตยกรรมทำงานที่แนะนำ: 5 โซนก่อนข้อมูลถึง AI
- Discovery Zone: เก็บเพียงรายการ Source และ Metadata ยังไม่อนุญาตให้ AI Production ใช้
- Quarantine Zone: รับข้อมูลเข้าพื้นที่จำกัดสิทธิ สแกน Malware, PII, Secrets และคุณภาพ
- Approved Data Zone: เก็บเฉพาะ Dataset Version ที่ผ่าน 8 ด่าน มี Owner และ Expiry
- AI Use Zone: สร้าง Index, Fine-tune หรือ Test โดยผูกกับ Dataset ID และ Access Policy
- Evidence & Removal Zone: เก็บ Log การอนุมัติ Lineage, Evaluation, Incident และหลักฐานการลบ
โครงสร้างนี้ไม่จำเป็นต้องเป็นระบบราคาแพง องค์กรเริ่มจากทะเบียน Dataset, Storage แยกสิทธิ และ Approval Workflow ที่ตรวจสอบได้ก่อน แล้วค่อยเพิ่ม Automation เมื่อปริมาณข้อมูลสูงขึ้น
Template: AI Data Provenance Card
Dataset ID / Version / Owner: [ระบุ]
>
AI Use Case และ Purpose: [ระบุ]
>
Source / Publisher / Collection Date / Method: [ระบุ]
>
License, Terms, Contract, Authority: [ระบุ]
>
Personal, Sensitive, Confidential, IP Classification: [ระบุ]
>
Fields Removed / Transformed / Aggregated: [ระบุ]
>
Anonymisation or Pseudonymisation Test: [Isolation / Linkage / Inference]
>
Approved Uses / Prohibited Uses / User Groups: [ระบุ]
>
RAG Index / Model / Evaluation Set ที่เชื่อมโยง: [ระบุ]
>
Retention / Review / Removal Procedure / Evidence: [ระบุ]
แผน 30 วันสำหรับองค์กร
สัปดาห์ 1: Inventory และหยุด Blind Ingestion
- เลือก AI Use Case ที่ใช้ข้อมูลภายนอกหรือข้อมูลบุคคล 3–5 เรื่อง
- ระงับการนำ Source ใหม่เข้า Production จนมี Owner และ Purpose
- ทำรายการ Raw Data, Index, Fine-tune Set, Evaluation Set และ Log
สัปดาห์ 2: สร้าง Gate และ Data Card
- กำหนด 8 ด่าน ผู้อนุมัติ และ Risk Tier
- สร้าง Data Provenance Card กับ Source Register
- แยก Quarantine กับ Approved Data Zone และทบทวนสิทธิ
สัปดาห์ 3: ทดสอบความเป็นส่วนตัวและการลบ
- สแกน PII, Secrets, Special/Sensitive Data และ Metadata
- ทดสอบ Isolation, Linkage, Inference และ Output Leakage
- เลือกหนึ่ง Dataset แล้วซ้อมลบจากทุกสำเนาและ Index
สัปดาห์ 4: Pilot, Evidence และตัดสินใจ
- อนุมัติ Dataset รุ่นเล็กสำหรับ Use Case ความเสี่ยงต่ำถึงปานกลาง
- วัด Retrieval Quality, Citation, Leakage, Rights Issue และ Removal Time
- ตัดสินใจ Scale, Revise, Hold หรือ Stop พร้อม Risk Acceptance ที่มีผู้รับผิดชอบ
KPI ที่ควรอยู่บน Dashboard
- Provenance Coverage: สัดส่วน Dataset ที่ย้อนกลับถึง Source, Owner, Version และ Approval ได้
- Rights Review Coverage: สัดส่วน Source ที่ผ่านการตรวจสิทธิและข้อจำกัด
- Sensitive Data Detection Rate และ Leakage Incident ต่อจำนวน Query
- Stale Source Rate: สัดส่วนข้อมูลที่เกิน Review Date หรือไม่มี Timestamp
- Removal SLA: เวลาจากคำสั่งลบถึงยืนยันว่าลบครบทุกสำเนาและ Index
- Dataset Change Failure Rate: การอัปเดตที่ทำให้คุณภาพหรือ Guardrail ต่ำกว่าเกณฑ์
- Unapproved Source Blocked: จำนวน Source ที่ถูกหยุดก่อนเข้าสู่ Production
ตัวเลข “จำนวนเอกสารในฐานความรู้” ไม่ใช่ KPI ความสำเร็จ หากเพิ่มข้อมูลแล้วความถูกต้อง สิทธิ หรือความสามารถในการลบแย่ลง
คำถามที่ผู้บริหารถามบ่อย
ข้อมูลบนเว็บไซต์สาธารณะนำมาใช้กับ AI ได้เลยหรือไม่?
ไม่ควรสรุปเช่นนั้น ต้องตรวจวัตถุประสงค์ ข้อมูลส่วนบุคคล สิทธิ เงื่อนไขเว็บไซต์ ความถูกต้อง และกฎหมายที่เกี่ยวข้องเป็นรายกรณี การเข้าถึงได้ไม่ใช่หลักฐานว่าองค์กรได้รับอนุญาตสำหรับทุกการใช้
การทำ RAG ปลอดภัยกว่า Fine-tune เสมอหรือไม่?
RAG อาจลบหรืออัปเดต Source ได้ง่ายกว่าในบางสถาปัตยกรรม แต่ยังมีความเสี่ยงจาก Embedding, Access Control, Retrieval, Prompt, Output, Cache และ Log ความปลอดภัยขึ้นกับการออกแบบทั้งระบบ ไม่ใช่ชื่อเทคนิค
Pseudonymisation เท่ากับ Anonymisation หรือไม่?
ไม่เท่ากัน Pseudonymisation ลดการเชื่อมโยงโดยตรง แต่หากองค์กรหรือบุคคลอื่นยังมีวิธีเชื่อมกลับ ข้อมูลยังต้องได้รับการควบคุมตามความเสี่ยง อย่าใช้คำว่า Anonymous จนกว่าจะมีหลักฐานการทดสอบที่เหมาะสม
ถ้า Vendor บอกว่าไม่ใช้ข้อมูลฝึกโมเดล ถือว่าพอหรือไม่?
ยังต้องตรวจว่าข้อมูลถูกเก็บ ประมวลผล สำรอง บันทึก Log ส่งต่อ หรือใช้ปรับปรุงส่วนอื่นอย่างไร รวมถึงสถานที่ประมวลผล ระยะเก็บ Subprocessor และวิธีลบ คำว่า “ไม่ Train” ตอบเพียงส่วนหนึ่งของวงจรข้อมูล
บทความนี้ใช้แทนคำปรึกษากฎหมาย PDPA ได้หรือไม่?
ไม่ได้ กรอบ 8 ด่านเป็นเครื่องมือบริหารและออกแบบ Control เบื้องต้น องค์กรต้องให้ DPO, Legal และเจ้าของกระบวนการประเมินข้อเท็จจริง กฎหมายเฉพาะ สัญญา และผลกระทบของ Use Case จริง
บทสรุป: AI ที่เชื่อถือได้เริ่มจากข้อมูลที่อธิบายเส้นทางได้
Data Provenance ไม่ใช่งานเอกสารปลายโครงการ แต่เป็นความสามารถในการตอบว่า AI กำลังใช้ข้อมูลอะไร มาจากไหน เปลี่ยนอย่างไร ใครอนุมัติ และจะถอนออกอย่างไร เมื่อคำตอบเหล่านี้เชื่อมกับ Pipeline จริง องค์กรจะทดลอง AI ได้เร็วขึ้นโดยไม่ต้องเดาความเสี่ยงย้อนหลัง
หากองค์กรกำลังสร้าง RAG, AI Assistant หรือระบบวิเคราะห์ข้อมูล ทีม Top Growth Studio สามารถช่วยทำ AI Business Diagnostic, ออกแบบ Trusted AI และ PDPA Governance และวาง Enterprise AI Transformation Roadmap ที่เชื่อม Data, Workflow, Technology, Human Oversight และ Evidence เข้าด้วยกัน โดยเริ่มจาก Use Case และข้อจำกัดจริงขององค์กร