Name: ระดับองค์กร: Governance, การปฏิบัติตามกฎหมาย, Shadow AI และการป้องกัน Deepfake · หลักสูตร AI Security อย่างมืออาชีพ
Author: จักริน นพรุจนธาดา

3.1

โมดูล 3.1

กรอบ Governance และ Risk: NIST AI RMF, ISO/IEC 42001, MITRE ATLAS

วางโครงหลักของกติกาการดูแล AI (governance) ด้วยกรอบมาตรฐานสากลของจริง แล้วโยงเข้ากับ OWASP

👋 สำหรับผู้เริ่มต้น — อ่านตรงนี้ก่อน

💡

เปรียบง่าย ๆ: เหมือนกฎจราจรกลางสำหรับรถทุกคันบนถนน ก่อนใครจะขับ AI ออกไปได้ ต้องมีกติกาสากลว่าใครดูแลอะไร ตรงไหนอันตราย และจะจัดการยังไง

🎯

ทำไมต้องรู้: พอมีกรอบมาตรฐานจริงที่ทั่วโลกยอมรับ องค์กรก็รู้ว่าต้องตรวจอะไรบ้าง ไม่ต้องคิดเองมั่ว ลดความเสี่ยงที่ AI จะทำพลาดโดยไม่มีใครรับผิดชอบ

🎯 สิ่งที่คุณจะทำได้หลังเรียนโมดูลนี้

เล่าได้ว่ากรอบ NIST AI RMF 1.0 มีโครงยังไง (4 ขั้นตอน คือ GOVERN ดูแล, MAP รู้จัก, MEASURE วัดผล, MANAGE จัดการ) และส่วนเสริมสำหรับ AI สร้างเนื้อหา (NIST AI 600-1 Generative AI Profile) มีอะไรบ้าง
อธิบายได้ว่ามาตรฐาน ISO/IEC 42001:2023 คืออะไร ทำไมถึงเป็นมาตรฐานบริหารจัดการ AI (AIMS) ที่ขอใบรับรอง (certifiable) ได้จริง
ใช้คลังท่าโจมตี MITRE ATLAS มาช่วยคิดล่วงหน้าว่าอะไรจะโดนเล่นงานได้บ้าง (threat-modeling) เพื่อตั้งรับ แล้วโยงเข้ากับ OWASP LLM Top 10

เนื้อหา

โมดูลนี้จะพาวางโครงหลักของกติกาการดูแล AI ด้วยกรอบมาตรฐานของจริง เริ่มจาก NIST AI RMF 1.0 ซึ่งเป็นคู่มือจัดการความเสี่ยง AI ของหน่วยงานมาตรฐานสหรัฐฯ ใช้แบบสมัครใจ ออกมาเมื่อ ม.ค. 2023 แบ่งงานเป็น 4 ขั้นตอนหลัก คือ GOVERN (ดูแล), MAP (รู้จัก), MEASURE (วัดผล) และ MANAGE (จัดการ) ต่อมามีส่วนเสริมชื่อ NIST AI 600-1 Generative AI Profile ออกเมื่อ 26 ก.ค. 2024 ที่ทำมาสำหรับ AI สร้างเนื้อหา (GenAI) โดยเฉพาะ ชี้ให้เห็น 12 จุดเสี่ยง (เช่น การที่ AI แต่งเรื่องมั่ว, ความเป็นส่วนตัวของข้อมูล, ความปลอดภัยของข้อมูล, ความน่าเชื่อถือของข้อมูล, อคติที่เป็นอันตราย, ข้อมูลอาวุธร้ายแรงอย่าง CBRN, ความเสี่ยงจากชิ้นส่วนที่เอามาต่อกัน, การตั้งค่าให้คนกับ AI ทำงานร่วมกัน, ทรัพย์สินทางปัญญา และเนื้อหาที่ก่อความเสียหาย) พร้อมข้อแนะนำให้ทำกว่า 200 ข้อ จัดกลุ่มตาม 4 ขั้นตอนข้างต้น (ข้อควรรู้ เดิมทีตัวนี้ผูกกับคำสั่งฝ่ายบริหารสหรัฐฯ EO 14110 ซึ่งถูกยกเลิกไปแล้วต้นปี 2025 แต่ตัวกรอบทางเทคนิคยังใช้ได้แบบสมัครใจ) ถัดมา ISO/IEC 42001:2023 เป็นมาตรฐานสากลที่ขอใบรับรอง (certifiable) ได้จริง สำหรับระบบบริหารจัดการ AI (AI Management System หรือ AIMS) พูดง่าย ๆ ก็คือมันทำหน้าที่กับ AI แบบเดียวกับที่มาตรฐาน ISO/IEC 27001 ทำกับความปลอดภัยข้อมูล (infosec) และช่วงหลังถูกใช้เป็นหลักฐานพร้อมตรวจ (audit-ready) ในบริบท EU AI Act มากขึ้นเรื่อย ๆ สุดท้าย MITRE ATLAS เป็นคลังรวมกลยุทธ์และเทคนิคการโจมตีที่มุ่งเป้ามาที่ AI โดยเฉพาะ (เอาไว้อ้างอิงเพื่อคิดเชิงตั้งรับ) โครงมาจาก ATT&CK ตอนนี้อยู่ราวรุ่น v5.x (ปลายปี 2025) มีการเพิ่มเทคนิคใหม่ ๆ ของ GenAI และ AI ที่ทำงานเองอัตโนมัติ (agentic) เช่น การวางยาข้อมูลใน RAG (RAG poisoning) เอาไว้ช่วยจัดหมวดว่า "อะไรพังได้บ้าง" เพื่อเตรียมตั้งรับ

📖 คำศัพท์ในโมดูลนี้ (อธิบายง่าย ๆ)

Governanceการวางกติกาและคนรับผิดชอบ ว่าใครดูแล AI ตรงไหน ตัดสินใจยังไง เหมือนกฎระเบียบของบริษัท

NIST AI RMFคู่มือจัดการความเสี่ยง AI ของหน่วยงานมาตรฐานสหรัฐฯ ใช้แบบสมัครใจ มี 4 หน้าที่หลัก คือ ดูแล-รู้จัก-วัดผล-จัดการ

ISO/IEC 42001มาตรฐานสากลสำหรับระบบบริหารจัดการ AI คล้าย ISO ที่โรงงานคุ้นเคย แต่เป็นเรื่อง AI โดยเฉพาะ

MITRE ATLASคลังรวมท่าโจมตี AI ของแฮกเกอร์ในโลกจริง เอาไว้ให้เรารู้ว่าศัตรูมักเล่นงานยังไง จะได้ตั้งรับถูก

Confabulationอาการที่ AI แต่งเรื่องมั่วขึ้นมาแบบมั่นใจ ทั้งที่ไม่จริง หรือที่เรียกว่า AI มโน

🧪 ตัวอย่างจริง + ผลลัพธ์ที่ได้

แมปควบคุมข้ามกรอบ

องค์กรเราอยากมี governance backbone ที่เดียว ช่วยอธิบายว่า NIST AI RMF, ISO/IEC 42001, OWASP LLM Top 10 และ MITRE ATLAS ทำงานร่วมกันอย่างไร

✅ ผลลัพธ์ที่ได้

วิธีที่แนะนำ คือใช้ NIST AI RMF (GOVERN/MAP/MEASURE/MANAGE) กับ ISO/IEC 42001 เป็นโครงหลักของทั้งองค์กร (โดย ISO 42001 ช่วยให้มีใบรับรองและหลักฐานพร้อมตรวจ) แล้วค่อยโยงมาตรการควบคุมลงมาที่ OWASP LLM Top 10 ซึ่งดูแลความเสี่ยงในระดับแอป และใช้ MITRE ATLAS มาช่วยคิดล่วงหน้าว่าอะไรจะพังได้บ้างเพื่อเตรียมตั้งรับ ทั้งหมดนี้เสริมกัน กรอบสากลให้โครงภาพรวม ส่วนมาตรฐานเฉพาะทางเติมรายละเอียดเชิงเทคนิค

💡 จุดสอน

องค์กรควรเลือกโครงหลักที่คนยอมรับกันอยู่แล้ว (NIST AI RMF กับ ISO/IEC 42001) แล้วค่อยโยงลงมาที่กรอบเฉพาะทาง ไม่ต้องคิดกรอบใหม่ขึ้นเองจากศูนย์

แบบฝึกหัดท้ายโมดูล

ทำตารางจับคู่ (mapping table) ระหว่าง 4 ขั้นตอนของ NIST AI RMF กับงานด้านความปลอดภัยที่องค์กรคุณทำอยู่จริง
อธิบายว่าทำไม ISO/IEC 42001 ถึงใช้เป็นหลักฐานพร้อมตรวจ (audit-ready) ได้ และต่างจาก NIST AI RMF ตรงไหน

3.2

โมดูล 3.2

EU AI Act และ Google SAIF/CoSAI

เข้าใจว่า EU AI Act ทยอยบังคับใช้ทีละช่วง (phased) ตอนไหนบ้าง และรู้จักกรอบดูแลความปลอดภัยตลอดอายุการใช้งาน (lifecycle security) ของจริง

👋 สำหรับผู้เริ่มต้น — อ่านตรงนี้ก่อน

💡

เปรียบง่าย ๆ: เหมือนกฎหมายฉบับใหม่ที่ค่อย ๆ ทยอยบังคับใช้ทีละส่วนตามปฏิทิน ไม่ใช่เปิดปุ๊บบังคับหมดทันที เราเลยต้องดูว่าวันไหนต้องทำอะไรพร้อม

🎯

ทำไมต้องรู้: ถ้าบริษัทมีลูกค้าหรือทำธุรกิจกับยุโรป การรู้ไทม์ไลน์ล่วงหน้าช่วยให้เตรียมเอกสารและปรับระบบทัน ไม่โดนปรับก้อนโต

🎯 สิ่งที่คุณจะทำได้หลังเรียนโมดูลนี้

บอกได้ว่า EU AI Act ทยอยบังคับใช้ทีละช่วง (2 ก.พ. 2025, 2 ส.ค. 2025, 2 ส.ค. 2026, 2 ส.ค. 2027) แต่ละช่วงต้องทำอะไร และค่าปรับสูงสุดแค่ไหน
รู้ว่ายังมีความไม่แน่นอน เพราะแพ็กเกจแก้กฎ Digital Omnibus/AI Omnibus อาจเลื่อนกำหนดของ AI ความเสี่ยงสูง (high-risk) ออกไป จึงต้องเช็กให้ชัวร์ (verify) ก่อนนำไปอ้าง
อธิบายกรอบความปลอดภัย AI ของ Google (SAIF) และการที่ Google ยกข้อมูลนี้ให้กลุ่ม CoSAI (โครงการเปิดของ OASIS เมื่อ ก.ย. 2025)

เนื้อหา

EU AI Act เริ่มมีผลตั้งแต่ 1 ส.ค. 2024 แต่ไม่ได้บังคับทุกอย่างพร้อมกัน มันทยอยมีผลทีละช่วงตามปฏิทิน คือ วันที่ 2 ก.พ. 2025 เริ่มห้ามการใช้ AI แบบต้องห้าม และกำหนดให้คนในองค์กรต้องมีความรู้เรื่อง AI (AI literacy); วันที่ 2 ส.ค. 2025 เริ่มบังคับกับ AI อเนกประสงค์ (GPAI หรือ general-purpose AI) เช่น ต้องมีเอกสารทางเทคนิค นโยบายลิขสิทธิ์ และสรุปข้อมูลที่ใช้เทรน ส่วนโมเดลใหญ่ที่อาจกระทบเป็นวงกว้าง (systemic-risk) ต้องเพิ่มการทดสอบและประเมิน การทดสอบแบบจำลองการโจมตี และการรายงานเหตุผิดปกติ โดยคณะกรรมาธิการยุโรป (Commission) มีอำนาจบังคับ GPAI ได้ตั้งแต่ 2 ส.ค. 2026; วันที่ 2 ส.ค. 2026 กฎเรื่อง AI ความเสี่ยงสูง (high-risk) และการวางกติกา (governance) ส่วนใหญ่เริ่มมีผล; และวันที่ 2 ส.ค. 2027 ระบบ high-risk ที่ฝังอยู่ในผลิตภัณฑ์ที่มีกฎกำกับอยู่แล้ว รวมถึงโมเดล GPAI ที่ออกก่อน ส.ค. 2025 ต้องทำให้ถูกกฎครบ ข้อควรระวังคือเรื่องนี้เปลี่ยนเร็ว มีแพ็กเกจแก้กฎชื่อ Digital Omnibus/AI Omnibus ที่กำลังเจรจากันในปี 2026 ซึ่งอาจเลื่อนกำหนดของ high-risk บางส่วนออกไป (มีรายงานว่าบางข้ออาจขยับไปราว ธ.ค. 2027 หรือ ส.ค. 2028) ดังนั้นวันที่หลังปี 2026 ให้ถือว่ายังไม่แน่นอน (provisional) และต้องเช็กกับข้อความล่าสุดของ Commission ส่วนค่าปรับนั้นสูงสุดถึง 35 ล้านยูโร หรือ 7% ของรายได้ทั่วโลก ทางฝั่ง Google มีกรอบความปลอดภัย AI ชื่อ SAIF (Secure AI Framework) ที่ให้แนวทางดูแลความปลอดภัยตลอดอายุการใช้งาน พร้อมเครื่องมือประเมินความเสี่ยง SAIF และเมื่อ ก.ย. 2025 Google ได้ยกข้อมูล SAIF ให้กับกลุ่มพันธมิตรด้าน AI ปลอดภัย Coalition for Secure AI (CoSAI) ซึ่งเป็นโครงการเปิดของ OASIS (ที่จัดทำ CoSAI Risk Map)

📖 คำศัพท์ในโมดูลนี้ (อธิบายง่าย ๆ)

EU AI Actกฎหมาย AI ฉบับแรกของสหภาพยุโรป กำหนดว่า AI แบบไหนทำได้ทำไม่ได้ และต้องดูแลยังไง

Phasedการบังคับใช้แบบทยอยเป็นช่วง ๆ ตามวันที่กำหนด ไม่ใช่มีผลทั้งหมดพร้อมกัน

GPAI (General-Purpose AI)AI อเนกประสงค์ที่เอาไปใช้ได้สารพัดงาน เช่น โมเดลแชตขนาดใหญ่ ไม่ได้ทำมาเพื่องานเดียว

SAIFกรอบความปลอดภัย AI ของ Google ที่แนะนำวิธีดูแล AI ให้ปลอดภัยตลอดอายุการใช้งาน

Lifecycleทุกช่วงชีวิตของระบบ AI ตั้งแต่ออกแบบ สร้าง ใช้งาน จนเลิกใช้ ต้องดูแลความปลอดภัยทุกช่วง

🧪 ตัวอย่างจริง + ผลลัพธ์ที่ได้

ประเมิน exposure ต่อ EU AI Act

องค์กรไทยของเราให้บริการโมเดล AI แก่ลูกค้าในยุโรป ช่วยประเมินว่าเราต้องดูไทม์ไลน์ EU AI Act ข้อใดและมีข้อควรระวังอะไร

✅ ผลลัพธ์ที่ได้

ถ้าให้บริการโมเดล GPAI ต้องดูข้อกำหนดที่เริ่มมีผล 2 ส.ค. 2025 คือต้องมีเอกสารทางเทคนิค นโยบายลิขสิทธิ์ และสรุปข้อมูลที่ใช้เทรน ถ้าเป็นโมเดลใหญ่ระดับ systemic-risk ต้องเพิ่มการทดสอบและประเมิน การทดสอบแบบจำลองการโจมตี และการรายงานเหตุผิดปกติด้วย รวมถึงอำนาจบังคับของ Commission ที่มีตั้งแต่ 2 ส.ค. 2026 ข้อควรระวัง กำหนดของ high-risk หลังปี 2026 อาจถูกเลื่อนโดย Digital Omnibus ให้ถือว่ายังไม่แน่นอนและเช็กข้อความล่าสุดก่อน ส่วนค่าปรับสูงสุดถึง 35 ล้านยูโร หรือ 7% ของรายได้ทั่วโลก

💡 จุดสอน

อย่าอ้างวันที่ของ EU AI Act หลังปี 2026 แบบตายตัว เพราะ Omnibus อาจทำให้เลื่อน ถ้าจะใช้ในเรื่องที่เกี่ยวกับการทำตามกฎ (compliance) ให้เช็กให้ชัวร์ก่อนทุกครั้ง

แบบฝึกหัดท้ายโมดูล

ทำไทม์ไลน์ EU AI Act โดยแยกให้ชัดว่าวันไหนแน่นอนแล้ว (stable) วันไหนยังไม่แน่นอน (provisional ต้องเช็กก่อน)
อธิบายว่า Google SAIF กับ CoSAI ช่วยเสริมกติกาการดูแล AI ขององค์กรยังไง และต่างจากกรอบ NIST/ISO ตรงไหน

3.3

โมดูล 3.3

AI-use Policy และการจัดการ Shadow AI

เขียนนโยบายการใช้ AI ที่ยอมรับได้ (AI Acceptable Use Policy) และคุมการแอบใช้ AI (Shadow AI) ด้วยเครื่องมือของจริง

👋 สำหรับผู้เริ่มต้น — อ่านตรงนี้ก่อน

💡

เปรียบง่าย ๆ: เหมือนพนักงานแอบเอาเครื่องมือส่วนตัวมาใช้ทำงานโดยที่บริษัทไม่รู้เห็น สะดวกก็จริงแต่เสี่ยงข้อมูลรั่วเพราะไม่มีใครควบคุม

🎯

ทำไมต้องรู้: การมีนโยบายชัดว่าใช้ AI ตัวไหนได้-ไม่ได้ ช่วยกันข้อมูลลับหลุดออกไป และลดโอกาสเกิดเหตุข้อมูลรั่วที่มีต้นทุนแพงมาก

🎯 สิ่งที่คุณจะทำได้หลังเรียนโมดูลนี้

เขียนนโยบายการใช้ AI ที่ยอมรับได้ ที่ระบุชัดว่าใช้เครื่องมือไหนได้ (sanctioned) ข้อมูลอะไรป้อนได้/ป้อนไม่ได้ และถ้าอยากขอใช้ตัวใหม่ต้องขออนุมัติทางไหน (approval path)
วางระบบตรวจหาและกันข้อมูลรั่วสำหรับ AI (discovery/DLP for AI) ด้วยตัวคุมการใช้คลาวด์ (CASB) การดูการจราจรเครือข่าย/DNS และการเฝ้าดูที่เครื่องปลายทาง (endpoint monitoring)
ลดการแอบใช้ AI ด้วยการหาเครื่องมือที่อนุมัติแล้วและปลอดภัยมาให้ใช้แทน

เนื้อหา

Shadow AI หรือการแอบใช้ AI ก็คือความเสี่ยงที่พนักงานเอาเครื่องมือ AI ที่บริษัทยังไม่อนุมัติมาใช้ทำงาน ผลสำรวจพบว่าพนักงานส่วนใหญ่ใช้เครื่องมือ AI ที่ไม่ได้รับอนุมัติ และรายงาน IBM Cost of a Data Breach ปี 2025 พบว่าราว 1 ใน 5 องค์กรเคยเจอเหตุข้อมูลรั่ว (breach) ที่โยงกับ shadow AI อีกทั้งความเสียหายยังสูงขึ้นชัดเจนเมื่อเหตุนั้นเกี่ยวกับ shadow AI (ตัวเลขแต่ละเจ้าและแต่ละผลสำรวจต่างกันไป ให้ระบุแหล่งและถือเป็นแค่ทิศทางคร่าว ๆ) จุดที่น่าห่วงคือมีองค์กรแค่ส่วนน้อยที่มีนโยบายการใช้ AI อย่างเป็นทางการหรือมีระบบตรวจจับ shadow AI วิธีคุมที่ได้ผลมี 3 อย่าง คือ (1) นโยบายการใช้ AI ที่ยอมรับได้ (AI Acceptable Use Policy) ซึ่งเป็นเอกสารพื้นฐาน ระบุว่าใช้เครื่องมือไหนได้ (sanctioned) ข้อมูลอะไรป้อนได้/ป้อนไม่ได้ ขออนุมัติทางไหน และถ้าฝ่าฝืนจะเป็นยังไง (2) ระบบตรวจหาและกันข้อมูลรั่วสำหรับ AI (Discovery/DLP for AI) โดยใช้ตัวคุมการใช้คลาวด์ (CASB) การดูการจราจรเครือข่าย/DNS ที่วิ่งไปโดเมนของบริการ AI การเฝ้าดูที่เครื่องปลายทางเพื่อหาส่วนเสริม (extension) หรือแอป AI และการวิเคราะห์พฤติกรรม โดยต้องรู้ไว้ว่าระบบกันข้อมูลรั่วแบบเดิม (DLP) ไม่ได้ทำมาเพื่อดักการดูดข้อมูลออกผ่านช่องพิมพ์คำสั่ง (prompt exfiltration) จึงต้องจับคู่กับเครื่องมือที่เข้าใจ AI โดยเฉพาะ (AI-aware controls เช่น Nudge Security, Prompt Security, Aurascape, ตัวคุม AI ของ Zscaler/Netskope) และ (3) หาเครื่องมือที่อนุมัติแล้วและปลอดภัยมาให้ใช้แทน ซึ่งเป็นวิธีลด shadow AI ที่ได้ผลที่สุด เพราะพอมีของดีให้ใช้ พนักงานก็ไม่ต้องหันไปใช้แชตบอตสาธารณะ

📖 คำศัพท์ในโมดูลนี้ (อธิบายง่าย ๆ)

Shadow AIการที่พนักงานแอบใช้เครื่องมือ AI ที่บริษัทยังไม่อนุมัติ ทำให้เกิดความเสี่ยงที่มองไม่เห็น

Acceptable Use Policyเอกสารกติกาว่าพนักงานใช้ AI แบบไหนได้-แบบไหนห้าม เหมือนกฎการใช้ของในออฟฟิศ

Breachเหตุข้อมูลรั่วหรือถูกเจาะ ทำให้ข้อมูลลับหลุดออกไปนอกองค์กร

Data Breach Costต้นทุนความเสียหายเมื่อเกิดข้อมูลรั่ว ทั้งค่าปรับ ค่ากู้ระบบ และความเชื่อมั่นที่หายไป

🧪 ตัวอย่างจริง + ผลลัพธ์ที่ได้

ร่างโครง AI Acceptable Use Policy

ช่วยร่างหัวข้อหลักของ AI Acceptable Use Policy สำหรับองค์กรไทยที่มีข้อมูลลูกค้าอยู่ภายใต้ PDPA

✅ ผลลัพธ์ที่ได้

หัวข้อหลักที่ควรมี (1) เครื่องมือ AI ที่อนุมัติให้ใช้ (sanctioned) กับรายการที่ห้ามใช้ (2) ประเภทข้อมูลที่ห้ามป้อนเด็ดขาด เช่น ข้อมูลส่วนบุคคลภายใต้ PDPA ความลับทางการค้า และข้อมูลล็อกอิน (credentials) (3) ช่องทางขออนุมัติ (approval path) เวลาอยากใช้เครื่องมือใหม่ (4) ข้อห้ามป้อนข้อมูลลูกค้าลงแชตบอตสาธารณะ (5) ผลของการฝ่าฝืน และ (6) การโยงเข้ากับ PDPA (มีเหตุใช้ข้อมูลที่ถูกกฎหมาย และมีสัญญากับผู้ให้บริการที่ห้ามเอาข้อมูลไปเทรน) พร้อมกับจัดหาเครื่องมือที่อนุมัติแล้วมาให้ใช้แทนควบคู่กันไป

💡 จุดสอน

มีแค่นโยบายอย่างเดียวไม่พอ ต้องจับคู่กับระบบตรวจหาและกันข้อมูลรั่วสำหรับ AI และการหาเครื่องมือที่อนุมัติแล้วมาใช้แทนด้วย ถึงจะลดการแอบใช้ AI ได้จริง

แบบฝึกหัดท้ายโมดูล

เขียนนโยบายการใช้ AI ที่ยอมรับได้ ฉบับย่อสำหรับองค์กรคุณ ให้มีครบทั้งเครื่องมือที่อนุมัติ (sanctioned) ข้อมูลที่ห้ามป้อน และช่องทางขออนุมัติ (approval path)
ออกแบบแผนตรวจหาการแอบใช้ AI (Shadow AI) โดยระบุสัญญาณที่จะเฝ้าดู (เช่น โดเมนบริการ AI ส่วนเสริมในเบราว์เซอร์) และเครื่องมือที่เข้าใจ AI ที่จะใช้

3.4

โมดูล 3.4

PDPA ของไทยกับระบบ AI

ทำตาม PDPA พ.ศ. 2562 ให้ถูก เมื่อ AI ของเราต้องประมวลผลข้อมูลส่วนบุคคล

👋 สำหรับผู้เริ่มต้น — อ่านตรงนี้ก่อน

💡

เปรียบง่าย ๆ: เหมือนกฎที่บอกว่าจะเอาข้อมูลส่วนตัวของคนอื่น เช่น ชื่อ เบอร์ รูปหน้า ไปใช้ ต้องขออนุญาตและดูแลให้ดี ห้ามเอาไปใช้ตามใจชอบ

🎯

ทำไมต้องรู้: ถ้า AI ของเราประมวลผลข้อมูลคนไทย ต้องทำตาม PDPA ไม่งั้นเสี่ยงโดนฟ้องและถูกปรับ การเข้าใจกฎช่วยให้ใช้ข้อมูลได้อย่างสบายใจและถูกกฎหมาย

🎯 สิ่งที่คุณจะทำได้หลังเรียนโมดูลนี้

อธิบายได้ว่า PDPA พ.ศ. 2562 (บังคับใช้เต็มตั้งแต่ 1 มิ.ย. 2022) ครอบคลุมระบบ AI แค่ไหน
บอกหน้าที่หลักได้ครบ คือ ต้องมีเหตุใช้ข้อมูลที่ถูกกฎหมายหรือขอความยินยอม (lawful basis/consent) รองรับสิทธิของเจ้าของข้อมูล ตั้งเจ้าหน้าที่คุ้มครองข้อมูล (DPO) วางมาตรการความปลอดภัย และดูกฎการส่งข้อมูลออกนอกประเทศ (cross-border transfer)
ตามให้ทันการบังคับใช้ที่เข้มขึ้นในปี 2025-2026 (ค่าปรับชุดใหญ่ครั้งแรกของ PDPC เมื่อ ส.ค. 2025 รวมกว่า 21.5 ล้านบาท ส่วนค่าปรับครั้งแรกสุดจริง ๆ คือ ส.ค. 2024 กรณี JIB 7 ล้านบาท และการบังคับให้หน่วยงานรัฐต้องมี DPO ตั้งแต่ 9 ต.ค. 2025)

เนื้อหา

PDPA (Personal Data Protection Act พ.ศ. 2562/2019) คือกฎหมายคุ้มครองข้อมูลส่วนบุคคลของไทย ที่ลอกโครงมาจาก GDPR ของยุโรป บังคับใช้เต็มตั้งแต่ 1 มิ.ย. 2022 และใช้กับระบบ AI ที่ประมวลผลข้อมูลส่วนบุคคลตรง ๆ (คือต้องมีเหตุใช้ข้อมูลที่ถูกกฎหมายหรือขอความยินยอม รองรับสิทธิของเจ้าของข้อมูล มี DPO วางมาตรการความปลอดภัย และดูกฎการส่งข้อมูลออกนอกประเทศ) โดยมี PDPC เป็นหน่วยงานกำกับดูแล ช่วงปี 2025-2026 การบังคับใช้เข้มขึ้นชัดเจน เดือน ส.ค. 2025 PDPC ออกค่าปรับทางปกครองก้อนใหญ่เป็นครั้งแรก (มีรายงานว่ารวมกว่า 21.5 ล้านบาท) ซึ่งเป็นสัญญาณว่าช่วงผ่อนผันแบบไม่เป็นทางการจบแล้ว และมีการตรวจสอบเพิ่มขึ้น พอถึง 9 ต.ค. 2025 มีประกาศในราชกิจจานุเบกษาบังคับให้หน่วยงานรัฐต้องมี DPO (ซึ่งส่งผลต่อภาคเอกชนตามมาด้วย) ดังนั้นองค์กรที่เอา AI ไปใช้กับข้อมูลส่วนบุคคลของคนไทย ควรเริ่มจับคู่หน้าที่ตาม PDPA ตั้งแต่ตอนนี้เลย

📖 คำศัพท์ในโมดูลนี้ (อธิบายง่าย ๆ)

PDPAกฎหมายคุ้มครองข้อมูลส่วนบุคคลของไทย พ.ศ. 2562 คุมว่าใครเก็บใช้ข้อมูลส่วนตัวคนอื่นได้แค่ไหน

GDPRกฎหมายคุ้มครองข้อมูลส่วนบุคคลของยุโรป เป็นต้นแบบที่ PDPA ของไทยลอกโครงมา

Lawful Basis / Consentเหตุผลที่ถูกกฎหมายในการใช้ข้อมูล เช่น การขอความยินยอมจากเจ้าของข้อมูลก่อนนำไปใช้

DPOเจ้าหน้าที่คุ้มครองข้อมูลส่วนบุคคล คนที่รับผิดชอบดูแลว่าองค์กรทำตามกฎข้อมูลถูกต้อง

Cross-border Transferการส่งข้อมูลส่วนบุคคลออกไปต่างประเทศ ซึ่งมีกฎควบคุมเป็นพิเศษว่าต้องทำยังไงถึงปลอดภัย

🧪 ตัวอย่างจริง + ผลลัพธ์ที่ได้

แมปหน้าที่ PDPA กับโปรเจกต์ AI

เราจะสร้างระบบ AI วิเคราะห์พฤติกรรมลูกค้าจากข้อมูลส่วนบุคคล ช่วยระบุหน้าที่ PDPA ที่ต้องทำก่อนเริ่ม

✅ ผลลัพธ์ที่ได้

หน้าที่ที่ต้องทำ (1) กำหนดเหตุใช้ข้อมูลที่ถูกกฎหมาย หรือขอความยินยอมให้ถูกต้องก่อนประมวลผล (2) รองรับสิทธิของเจ้าของข้อมูล เช่น ขอเข้าถึง แก้ไข หรือลบข้อมูลได้ (3) ตั้ง DPO ตามเกณฑ์ (4) วางมาตรการความปลอดภัยของข้อมูล (5) เช็กกฎการส่งข้อมูลออกนอกประเทศ (cross-border transfer) ถ้ามีการส่งข้อมูลออกไปต่างประเทศ (6) ทำสัญญากับผู้ให้บริการ AI (DPA) ที่ระบุห้ามเอาข้อมูลไปเทรนโมเดลถ้าไม่ได้รับอนุญาต ทั้งหมดนี้อยู่ภายใต้การกำกับของ PDPC

💡 จุดสอน

PDPA ใช้กับ AI แบบเต็ม ๆ องค์กรควรจับคู่หน้าที่ให้ครบตั้งแต่ก่อนเริ่มโปรเจกต์ ไม่ใช่รอทำหลังเอาระบบขึ้นใช้จริง เพราะตอนนี้ PDPC บังคับใช้เข้มขึ้นแล้ว

แบบฝึกหัดท้ายโมดูล

จับคู่หน้าที่ตาม PDPA (เหตุใช้ข้อมูลที่ถูกกฎหมาย สิทธิเจ้าของข้อมูล DPO ความปลอดภัย และการส่งข้อมูลออกนอกประเทศ) เข้ากับแต่ละช่วงในอายุการใช้งาน (lifecycle) ของระบบ AI
ร่างข้อกำหนดในสัญญากับผู้ให้บริการ AI (DPA) ที่ห้ามเอาข้อมูลขององค์กรไปเทรนโมเดลถ้าไม่ได้รับอนุญาต

3.5

โมดูล 3.5

ร่างแนวทาง AI ของ PDPC และทิศทางกฎหมาย AI ไทย

ตามให้ทันร่างแนวทาง AI ของ PDPC และทิศทางที่ ETDA วางไว้สำหรับกฎหมาย AI

👋 สำหรับผู้เริ่มต้น — อ่านตรงนี้ก่อน

💡

เปรียบง่าย ๆ: เหมือนติดตามข่าวว่ากฎจราจรฉบับใหม่กำลังจะออก ตอนนี้ยังเป็นร่างให้ทุกคนช่วยกันคอมเมนต์ ก่อนจะประกาศใช้จริง เราจะได้เตรียมตัวไว้ก่อน

🎯

ทำไมต้องรู้: การรู้ทิศทางกฎหมาย AI ไทยตั้งแต่ยังเป็นร่าง ช่วยให้องค์กรปรับตัวล่วงหน้า ไม่ต้องรีบแก้ทีหลังแบบวุ่นวายเมื่อกฎบังคับใช้จริง

🎯 สิ่งที่คุณจะทำได้หลังเรียนโมดูลนี้

เล่าสาระของร่างแนวทาง (Guidelines) ของ PDPC (17 ก.พ. 2026) เรื่องการคุ้มครองข้อมูลส่วนบุคคลตอนพัฒนาและใช้ AI ได้
บอกได้ว่าใครเป็นผู้ควบคุมข้อมูล ใครเป็นผู้ประมวลผลข้อมูล คือ คนที่เอา AI ไปใช้ (deployer) มักเป็นผู้ควบคุมข้อมูล ส่วนเจ้าของ AI ที่ขายให้ (AI vendor) มักเป็นผู้ประมวลผลข้อมูล
อธิบายสถานะกฎหมาย AI ของไทยได้ ว่ายังไม่มีกฎหมาย AI เฉพาะ (AI Act) และ ETDA กำลังเปิดรับฟังความเห็นร่างหลักการอยู่ (กลางปี 2025)

เนื้อหา

โมดูลนี้จะพาตามความเคลื่อนไหวล่าสุดของไทย เมื่อ 17 ก.พ. 2026 PDPC ออกร่างแนวทางเรื่องการคุ้มครองข้อมูลส่วนบุคคลตอนพัฒนาและใช้ AI (Guidelines on Personal Data Protection in the Development and Use of AI) ซึ่งตอนนี้อยู่ในช่วงเปิดรับฟังความเห็น (public consultation มีรายงานว่าเปิดถึงราว 25 ก.พ. 2026) สาระสำคัญคือแปลงหน้าที่ของผู้ควบคุมข้อมูลและผู้ประมวลผลข้อมูลมาใช้กับทุกช่วงชีวิตของระบบ AI คือ ชี้ชัดว่าใครเป็นใคร (คนที่เอา AI ไปใช้อย่าง deployer มักเป็นผู้ควบคุมข้อมูล ส่วนเจ้าของ AI ที่ขายให้อย่าง AI vendor มักเป็นผู้ประมวลผลข้อมูล) กำหนดให้ในสัญญาต้องมีข้อห้ามเอาข้อมูลไปเทรนโมเดล บังคับให้ประเมินผลกระทบด้านข้อมูล (DPIA) สำหรับ AI ที่เสี่ยงสูง และวางมาตรการความปลอดภัยตลอดอายุการใช้งาน ข้อควรระวังคือเรื่องนี้เปลี่ยนเร็วและตัวนี้ยังเป็นแค่ร่าง ยังไม่ใช่ฉบับจริง จึงต้องคอยเช็กสถานะ ส่วนกฎหมาย AI เฉพาะนั้น ไทยยังไม่มี AI Act แบบแยกฉบับ โดย ETDA เปิดรับฟังความเห็นเรื่องร่างหลักการกฎหมาย AI (Draft Principles for AI Legislation) เมื่อกลางปี 2025 ซึ่งเอาร่างพระราชกฤษฎีกาปี 2022 กับร่าง พ.ร.บ. ส่งเสริม AI ปี 2023 มารวมกัน ตอนนี้กรอบเฉพาะยังอยู่ในขั้นยกร่าง กว่าจะเสร็จ การทำตามกฎก็ต้องพึ่ง PDPA กับกฎเฉพาะของแต่ละอุตสาหกรรม (sector) ไปก่อน

📖 คำศัพท์ในโมดูลนี้ (อธิบายง่าย ๆ)

PDPCคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล หน่วยงานไทยที่กำกับดูแลเรื่องข้อมูลส่วนบุคคลและออกแนวทาง AI

Guidelines (ร่างแนวทาง)เอกสารแนะนำวิธีปฏิบัติ ยังไม่ใช่กฎหมายบังคับ แต่บอกทิศทางว่าควรทำยังไง

Public Consultationช่วงเปิดรับฟังความเห็นจากประชาชนและผู้เกี่ยวข้อง ก่อนจะสรุปเป็นแนวทางหรือกฎจริง

Controller / Processorผู้ควบคุมข้อมูล (คนตัดสินใจว่าจะใช้ข้อมูลทำอะไร) กับผู้ประมวลผลข้อมูล (คนรับจ้างจัดการข้อมูลให้)

Deployerผู้ที่นำระบบ AI ไปใช้งานจริง ซึ่งมักมีหน้าที่เป็นผู้ควบคุมข้อมูลตามกฎ

🧪 ตัวอย่างจริง + ผลลัพธ์ที่ได้

เตรียมองค์กรรับร่างแนวทาง PDPC

ในฐานะที่เราเป็น deployer ของระบบ AI ที่ซื้อจาก vendor ต่างชาติ ร่างแนวทาง PDPC จะกระทบเราอย่างไรและต้องเตรียมอะไร

✅ ผลลัพธ์ที่ได้

ตามร่างแนวทางของ PDPC ในฐานะที่เราเป็นคนเอา AI ไปใช้ (deployer) องค์กรมักถูกจัดเป็นผู้ควบคุมข้อมูล ส่วน AI vendor มักเป็นผู้ประมวลผลข้อมูล สิ่งที่ต้องเตรียมคือ (1) ทบทวนสัญญากับผู้ให้บริการ (DPA) ให้มีข้อห้ามเอาข้อมูลไปเทรนโมเดล (2) ทำการประเมินผลกระทบด้านข้อมูล (DPIA) ถ้า AI จัดเป็นความเสี่ยงสูง (3) วางมาตรการความปลอดภัยตลอดอายุการใช้งาน (4) ระบุให้ชัดในสัญญาว่าใครเป็นผู้ควบคุม ใครเป็นผู้ประมวลผลข้อมูล ข้อควรระวังคือร่างนี้ยังไม่ใช่ฉบับจริง ให้ตามสถานะและปรับตามฉบับสุดท้ายด้วย

💡 จุดสอน

ถึงจะยังเป็นแค่ร่าง องค์กรก็ควรเตรียมตัวไว้ก่อน โดยเฉพาะเรื่องสัญญาห้ามเทรนและการทำ DPIA เพราะสองเรื่องนี้สอดคล้องกับ PDPA ที่บังคับใช้อยู่แล้ว

แบบฝึกหัดท้ายโมดูล

สรุปสาระสำคัญของร่างแนวทาง (Guidelines) ของ PDPC (17 ก.พ. 2026) ให้เป็นเช็กลิสต์ที่องค์กรเอาไปเตรียมตัวได้
อธิบายสถานะปัจจุบันของกฎหมาย AI ไทย และสิ่งที่องค์กรต้องพึ่งไปก่อน (PDPA กับกฎเฉพาะของแต่ละอุตสาหกรรม) จนกว่าจะมีกฎหมาย AI เฉพาะ

3.6

โมดูล 3.6

การป้องกัน Deepfake และ AI Social Engineering

กันการหลอกลวง (fraud) ด้วยของปลอมจาก AI (deepfake) ด้วยการวางขั้นตอน ไม่ใช่พึ่งแค่เครื่องมือตรวจจับอย่างเดียว

👋 สำหรับผู้เริ่มต้น — อ่านตรงนี้ก่อน

💡

เปรียบง่าย ๆ: เหมือนมิจฉาชีพปลอมเสียงหรือหน้าเป็นคนที่เรารู้จักเพื่อหลอกโอนเงิน วิธีกันที่ดีสุดไม่ใช่แค่จับผิดของปลอม แต่คือมีขั้นตอนยืนยันตัวก่อนทำตาม

🎯

ทำไมต้องรู้: พอวางกระบวนการตรวจสอบไว้ เช่น โทรกลับยืนยันก่อนโอนเงิน องค์กรก็รอดจากการหลอกลวงด้วย deepfake แม้ของปลอมจะเนียนแค่ไหนก็ตาม

🎯 สิ่งที่คุณจะทำได้หลังเรียนโมดูลนี้

เลือกแพลตฟอร์มฝึกให้พนักงานรู้ทันภัยและซ้อมสถานการณ์จำลอง (awareness/simulation training) ของจริงได้ เช่น KnowBe4, Adaptive Security, Hoxhunt
เข้าใจข้อจำกัดของเครื่องมือตรวจจับของปลอม (detection) ว่าไม่มีตัวไหนแม่น 100%
ออกแบบขั้นตอนป้องกันที่ได้ผลจริง คือ ยืนยันผ่านช่องทางอื่น (out-of-band verification) ใช้รหัสลับ (code-words) และให้มีคนอนุมัติสองคน (dual-authorization)

เนื้อหา

โมดูลปิดท้ายนี้ว่าด้วยการรับมือของปลอมจาก AI (deepfake) และการหลอกลวงด้วยจิตวิทยาผ่าน AI (social engineering) แบบเน้นตั้งรับ แพลตฟอร์มฝึกให้พนักงานรู้ทันภัยและซ้อมสถานการณ์จำลองของจริง ได้แก่ KnowBe4 (เปิดคอร์สฝึกเรื่อง deepfake โดยเฉพาะเมื่อ ธ.ค. 2025), Adaptive Security, Jericho Security, Hoxhunt, Brightside AI, Callstrike, Breacher.ai ซึ่งจำลองและฝึกได้หลายช่องทาง (multi-channel ทั้งอีเมล เสียง วิดีโอ และ SMS) ส่วนเครื่องมือตรวจจับของปลอม (detection ที่ยังไม่สมบูรณ์) เช่น Reality Defender, Intel FakeCatcher, Microsoft Video Authenticator แต่ข้อควรระวังที่สำคัญมากคือไม่มีตัวตรวจจับตัวไหนแม่น 100% ให้ถือว่าการตรวจจับเป็นแค่หนึ่งในหลายชั้นของการป้องกันเท่านั้น วิธีที่ได้ผลดีที่สุดคือ "ขั้นตอน" ไม่ใช่ "การตรวจจับ" ได้แก่ การยืนยันผ่านช่องทางอื่นหรือโทรกลับ (out-of-band verification/callback) ทุกครั้งที่มีคำขอด้านการเงินหรือขอสิทธิเข้าถึง การใช้รหัสลับ (code-words) สำหรับผู้บริหาร และการให้มีคนอนุมัติสองคน (dual-authorization) เวลาจ่ายเงิน แค่นี้ก็เอาชนะการหลอกลวงด้วย deepfake ได้เกือบหมดแล้ว ไม่ว่าของปลอมจะทำมาเนียนแค่ไหนก็ตาม

📖 คำศัพท์ในโมดูลนี้ (อธิบายง่าย ๆ)

Deepfakeภาพ เสียง หรือวิดีโอปลอมที่ AI สร้างให้เหมือนคนจริง จนแยกด้วยตาแทบไม่ออก

Social Engineeringการหลอกลวงโดยใช้จิตวิทยา หลอกให้คนหลงเชื่อและทำตาม เช่น บอกให้โอนเงินหรือบอกรหัสผ่าน

Awareness Trainingการฝึกอบรมให้พนักงานรู้ทันภัยและกลโกง จะได้ไม่ตกเป็นเหยื่อง่าย ๆ

Simulationการจำลองสถานการณ์หลอกลวงเสมือนจริงมาซ้อมให้พนักงาน เหมือนซ้อมหนีไฟก่อนเกิดเหตุจริง

Multi-channelการโจมตีหลายช่องทางพร้อมกัน เช่น อีเมล โทรศัพท์ แชต เพื่อให้ดูน่าเชื่อถือขึ้น

🧪 ตัวอย่างจริง + ผลลัพธ์ที่ได้

ออกแบบ process กันการโอนเงินหลอกด้วย deepfake

มีคน video call ปลอมเป็น CEO สั่งให้ฝ่ายการเงินโอนเงินด่วน ช่วยออกแบบ process ป้องกันที่ไม่พึ่ง detection tool อย่างเดียว

✅ ผลลัพธ์ที่ได้

ขั้นตอนที่ได้ผลคือ (1) กำหนดให้ยืนยันผ่านช่องทางอื่น (out-of-band verification) โดยบังคับโทรกลับผ่านช่องทางที่ยืนยันแล้วก่อนโอนทุกครั้งที่มีคำขอด้านการเงิน (2) ใช้รหัสลับ (code-word) ให้ผู้บริหารยืนยันตัวตน (3) บังคับให้มีคนอนุมัติสองคน (dual-authorization) เวลาจ่ายเงิน (4) ฝึกให้พนักงานรู้ทันภัยแบบหลายช่องทาง (เช่น KnowBe4 หรือ Hoxhunt) ส่วนเครื่องมือตรวจจับของปลอม (เช่น Reality Defender) ใช้เป็นตัวเสริมเท่านั้น เพราะไม่มีตัวไหนแม่น 100%

💡 จุดสอน

การกัน deepfake ที่ได้ผลที่สุดคือการวางขั้นตอน (ยืนยันตัวตน อนุมัติสองคน และใช้รหัสลับ) ไม่ใช่การพึ่งตัวตรวจจับที่ยังไม่สมบูรณ์

แบบฝึกหัดท้ายโมดูล

ออกแบบนโยบายการโทรกลับยืนยันผ่านช่องทางอื่น (out-of-band verification) สำหรับคำขอด้านการเงินและการขอสิทธิเข้าถึงในองค์กรคุณ
ร่างแผนฝึกให้พนักงานรู้ทันภัยแบบหลายช่องทาง (multi-channel) และอธิบายว่าทำไมถึงไม่ควรพึ่งแค่ตัวตรวจจับ deepfake อย่างเดียว

🏆 โปรเจกต์ปิดท้ายระดับสูง (Capstone Advanced): ออกแบบโปรแกรมดูแลความปลอดภัยและกติกา AI ให้ทั้งองค์กร

วางโครงหลักของกติกาการดูแล AI (governance backbone) ด้วย NIST AI RMF กับ ISO/IEC 42001 พร้อมโยงมาตรการควบคุมลงมาที่ OWASP LLM Top 10 และ MITRE ATLAS
ทำแผนการทำตามกฎ (compliance map) สำหรับองค์กรที่ให้บริการทั้งในไทยและ EU โดยแยกไทม์ไลน์ EU AI Act ว่าวันไหนแน่นอนแล้ว วันไหนยังไม่แน่นอน แล้วจับคู่หน้าที่ตาม PDPA
เขียนนโยบายการใช้ AI ที่ยอมรับได้ (AI Acceptable Use Policy) พร้อมแผนคุมการแอบใช้ AI (ระบบตรวจหาและกันข้อมูลรั่วสำหรับ AI กับการหาเครื่องมือที่อนุมัติแล้วมาใช้แทน)
ทำเช็กลิสต์เตรียมรับร่างแนวทาง AI ของ PDPC รวมถึงการประเมินผลกระทบด้านข้อมูล (DPIA) สำหรับ AI ที่เสี่ยงสูง และสัญญากับผู้ให้บริการที่ห้ามเอาข้อมูลไปเทรน
ออกแบบขั้นตอนกัน deepfake (ยืนยันผ่านช่องทางอื่น ใช้รหัสลับ และให้มีคนอนุมัติสองคน) พร้อมแผนฝึกให้พนักงานรู้ทันภัย
นำเสนอโปรแกรมทั้งหมด พร้อมย้ำเส้นที่ห้ามข้ามเด็ดขาด คือ ทดสอบเฉพาะระบบที่ตัวเองเป็นเจ้าของหรือได้รับอนุญาตเท่านั้น ไม่สอนเทคนิคโจมตี (offensive tradecraft) ต้องมีคนเป็นผู้รับผิดชอบเสมอ (human accountability) และตรวจสอบย้อนหลังได้ (auditability)

🎓

จบหลักสูตรการใช้งาน AI Security อย่างมืออาชีพ

OWASP LLM →blueteam →Governance →