AI Security และ AI Governance: ป้องกันทุกองค์ประกอบของ AI

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

ทำไม AI ต้องมีแนวทางความปลอดภัยของตัวเอง

มาตรการแบบเดิมยังจำเป็น แต่ AI มีลักษณะบางอย่างที่มาตรการเหล่านั้นไม่ได้ออกแบบมารองรับ ได้แก่

• คำสั่งกับข้อมูลปนอยู่ในช่องทางเดียวกัน: โมเดลภาษา (LLM) แยกไม่ได้แน่นอนว่าข้อความไหนเป็นคำสั่งที่เชื่อถือได้ และข้อความไหนเป็นเพียงเนื้อหาที่อ่านเจอในอีเมล เว็บ หรือเอกสาร ด้วยเหตุนี้ Prompt Injection (การแทรกคำสั่งในข้อความเพื่อหลอกให้โมเดลทำตาม) จึงเป็นความเสี่ยงอันดับ LLM01 ใน OWASP Top 10 for LLM Applications 2025 (รายการความเสี่ยง 10 อันดับของแอปที่ใช้โมเดลภาษา)
• ผลลัพธ์ไม่แน่นอน: อินพุตเดียวกันอาจได้ผลลัพธ์ต่างกัน จึงทดสอบให้ครบทุกกรณีแบบที่ทดสอบฟังก์ชันของโปรแกรมทั่วไปไม่ได้
• พื้นที่ที่ถูกโจมตีได้กว้างกว่าโค้ด: ข้อมูลที่ใช้ฝึกโมเดล embedding (ข้อมูลที่แปลงข้อความเป็นตัวเลขเพื่อใช้ค้นหาตามความหมาย) ไฟล์โมเดล และแม้แต่คำอธิบายของ tool (เครื่องมือที่ AI เรียกใช้ได้) ล้วนถูกแก้ไขแทรกแซงได้
• ข้อความกลายเป็นการกระทำ: เมื่อโมเดลเรียกใช้ tool ได้ คำตอบที่ถูกชักจูงอาจกลายเป็นการลบไฟล์ การส่งอีเมล หรือการสั่งจ่ายเงินจริง (OWASP LLM06 Excessive Agency คือการปล่อยให้ AI มีสิทธิ์หรืออิสระในการลงมือทำมากเกินไป)

NIST (สถาบันมาตรฐานและเทคโนโลยีของสหรัฐฯ) จัดหมวดการโจมตีระบบ machine learning (adversarial machine learning) ไว้ในเอกสาร AI 100-2 ฉบับปี 2025 เป็นสี่กลุ่ม คือ evasion (หลอกให้โมเดลตัดสินผิด) poisoning (ลอบปนข้อมูลเสียเข้าไป) privacy (ล้วงข้อมูลที่โมเดลเรียนรู้มา) และ abuse (นำไปใช้ในทางที่ผิด) ส่วน MITRE ATLAS รวบรวมเทคนิคที่ผู้โจมตีใช้จริงกับระบบที่มี AI เจ็ดชั้นด้านล่างนำรายการเหล่านี้มาจัดให้มอบหมายเจ้าของแต่ละชั้นได้

7 ชั้นของ AI ที่ต้องปกป้อง

ให้มองระบบ AI ที่ใช้งานจริงเป็นเจ็ดชั้น หากชั้นใดชั้นหนึ่งมีช่องโหว่ มาตรการในชั้นอื่นก็อาจไร้ผลไปด้วย

• 1. ข้อมูล: ได้แก่ข้อมูลที่ใช้ฝึกสอน ปรับแต่งโมเดล และข้อมูลที่โมเดลดึงมาใช้ตอบ ความเสี่ยงหลักคือ poisoning (LLM04) และการรั่วไหลของข้อมูลสำคัญ (LLM02) มาตรการ: จัดชั้นความลับของข้อมูลก่อนส่งให้โมเดล ลดข้อมูลส่วนบุคคลให้เหลือเท่าที่จำเป็นหรือทำให้ระบุตัวตนไม่ได้ บันทึกแหล่งที่มาของข้อมูล จำกัดว่าใครเขียนข้อมูลลงแหล่งฝึกสอนและฐานความรู้ได้ และตรวจว่าข้อมูลไม่ถูกแก้ไข
• 2. โมเดลและห่วงโซ่อุปทานซอฟต์แวร์ (LLM03): ได้แก่โมเดลที่มีคนฝึกไว้แล้ว ชุดข้อมูล ไลบรารี และปลั๊กอินที่องค์กรไม่ได้สร้างเอง มาตรการ: ใช้แหล่งดาวน์โหลดที่เชื่อถือได้ ตรึงเวอร์ชัน (ระบุเวอร์ชันตายตัว) และตรวจค่า hash (ค่าที่ใช้เช็กว่าไฟล์ไม่ถูกแก้ไข) เลือกไฟล์โมเดลรูปแบบ safetensors ซึ่งปลอดภัยกว่าไฟล์แบบ pickle ที่อาจรันโค้ดทันทีที่โหลด สแกนและทดลองใน sandbox (พื้นที่ทดสอบที่แยกจากระบบจริง) ก่อนใช้ และทำบัญชีรายการส่วนประกอบ (AI bill of materials)
• 3. Prompt และผลลัพธ์ (LLM01, LLM05, LLM07): มาตรการ: ไม่ใส่ความลับใน system prompt (คำสั่งตั้งต้นที่กำหนดพฤติกรรมของโมเดล) เพราะอาจรั่วออกมาได้ การกรองอินพุตและเอาต์พุตทำได้ แต่ให้ถือเป็นเพียงชั้นป้องกันหนึ่งชั้น ไม่ใช่ชั้นเดียว และให้มองผลลัพธ์ของโมเดลเป็นข้อมูลที่ยังเชื่อไม่ได้ ก่อนส่งเข้าฐานข้อมูล shell หรือเบราว์เซอร์ ต้องตรวจสอบความถูกต้อง เข้ารหัสอักขระ (encode) หรือใช้ parameterize (ส่งค่าแยกจากคำสั่ง) เสียก่อน
• 4. การค้นคืนข้อมูลและ vector store (LLM08): ระบบ RAG (เทคนิคให้โมเดลค้นเอกสารขององค์กรมาประกอบคำตอบ) มักเก็บเอกสารที่ละเอียดอ่อนที่สุดไว้ใน vector store (ฐานข้อมูลที่ค้นตามความหมายได้) มาตรการ: ตรวจสิทธิ์ของผู้ใช้แต่ละคนทุกครั้งที่ค้น แยกข้อมูลของแต่ละ tenant (หน่วยงานหรือลูกค้าที่ใช้ระบบร่วมกัน) ออกจากกัน คัดกรองเอกสารก่อนนำเข้า เพราะเอกสารที่ถูกวางยาก็เป็นช่องทาง injection ได้ และปกป้อง embedding เหมือนข้อมูลต้นฉบับ
• 5. Agent และ tool (LLM06): Agent คือ AI ที่ลงมือทำงานเองได้ผ่าน tool มาตรการ: ให้ tool แต่ละตัวมีสิทธิ์เท่าที่จำเป็น (least privilege) ใช้ credential ที่อายุสั้น จำกัดขอบเขต และผูกกับตัวผู้ใช้จริง ให้คนอนุมัติก่อนทำสิ่งที่กระทบสูง เช่น จ่ายเงิน ลบข้อมูล หรือส่งข้อความออกนอกองค์กร และบันทึกการเรียกใช้ tool ทุกครั้ง ดูรายละเอียดเชิงเทคนิคได้ที่ MCP คืออะไร: สถาปัตยกรรม ความเสี่ยง และวิธีรับมือเชิงเทคนิค
• 6. โครงสร้างพื้นฐานและตัวตน (LLM10): ได้แก่ API key, endpoint (จุดเรียกใช้บริการโมเดล), GPU และ pipeline (สายงานอัตโนมัติสำหรับฝึกและนำโมเดลไปใช้) มาตรการ: เก็บความลับด้วยระบบจัดการความลับ (secrets management) ยืนยันตัวตนให้เข้มแข็งที่ทุก endpoint ของโมเดล แบ่งส่วนเครือข่าย จำกัดอัตราการเรียก (rate limit) และตั้งโควตาค่าใช้จ่าย เพื่อกันการใช้ทรัพยากรแบบไม่จำกัด และเข้ารหัสข้อมูลทั้งตอนส่งและตอนจัดเก็บ
• 7. คน การใช้งาน และการเฝ้าระวัง (LLM09): มาตรการ: จัดเครื่องมือที่อนุมัติแล้วให้พนักงานใช้ จะได้ไม่หันไปใช้ Shadow AI (AI ที่พนักงานใช้เองโดยองค์กรไม่รู้) อบรมว่าข้อมูลประเภทใดใส่เครื่องมือใดได้ ให้คนตรวจทานในงานที่คำตอบผิดแล้วเกิดความเสียหาย บันทึก log โดยคำนึงถึงความเป็นส่วนตัว มีระบบตรวจจับ ทำ red team (ทีมจำลองการโจมตี) สม่ำเสมอ และมี playbook (คู่มือขั้นตอนรับมือ) สำหรับเหตุการณ์ด้านความปลอดภัย

นิสัยที่ช่วยได้มากคือถามสี่ข้อนี้กับทุกงานที่ใช้ AI (use case) ได้แก่ ข้อมูลอะไรเข้าไปบ้าง ใครมีโอกาสส่งผลต่ออินพุตได้ ผลลัพธ์สั่งให้เกิดอะไรได้บ้าง และเมื่อเกิดปัญหาจะแจ้งใคร ถ้าข้อใดตอบว่า "ไม่มีใครรู้" นั่นคือประเด็นแรกที่ต้องแก้

AI Governance ประกอบด้วยอะไรบ้าง

AI Governance ไม่ใช่นโยบายฉบับเดียว โปรแกรมที่ใช้ได้จริงมักประกอบด้วยส่วนหลักไม่กี่ส่วนเหมือนกัน ได้แก่

• ความรับผิดชอบ (Accountability): ผู้บริหารที่เป็นเจ้าของเรื่องและระบุชื่อได้ คณะทำงานขนาดเล็กจากหลายหน่วย (ความปลอดภัย กฎหมาย ความเป็นส่วนตัว ข้อมูล และฝ่ายธุรกิจ) และเจ้าของความเสี่ยงที่ระบุชื่อได้ของ AI แต่ละระบบ
• บัญชีรายการ AI (inventory): รายการ AI ทุกระบบที่อัปเดตอยู่เสมอ รวมถึงฟีเจอร์ AI ที่ฝังอยู่ในเครื่องมือ SaaS (ซอฟต์แวร์แบบเช่าใช้ผ่านอินเทอร์เน็ต) โมเดลของผู้ให้บริการ และการใช้งานที่ไม่ได้รับอนุญาต ถ้ามองไม่เห็นก็กำกับดูแลไม่ได้
• ชุดนโยบาย: นโยบายการใช้งานที่ยอมรับได้ ซึ่งกำหนดว่าข้อมูลระดับใดใส่เครื่องมือใดได้ รวมถึงนโยบายจัดซื้อ ข้อมูล การกำกับโดยมนุษย์ และการรับมือเหตุการณ์
• การจัดระดับความเสี่ยง (risk tiering): จัดกลุ่มงานที่ใช้ AI ตามผลกระทบเมื่อผลลัพธ์ผิดหรือถูกชักจูง ไม่ใช่ตามชนิดของเทคโนโลยี แล้วปรับความเข้มของการตรวจสอบตามกลุ่มนั้น
• การประเมินผู้ให้บริการ: ถามว่าข้อมูลขององค์กรถูกเก็บไว้หรือถูกนำไปฝึกโมเดลหรือไม่ ประมวลผลที่ไหน มี sub-processor (ผู้ให้บริการช่วงที่รับข้อมูลไปประมวลผลต่อ) รายใดบ้าง มีใบรับรองอะไร (เช่น ISO/IEC 42001, ISO/IEC 27001, SOC 2) แจ้งเหตุเร็วแค่ไหน และเลิกใช้บริการได้อย่างไร
• การทดสอบและการสร้างความมั่นใจ: ประเมินก่อนใช้งานจริง ทำ red team และทดสอบซ้ำทุกครั้งที่โมเดล prompt หรือแหล่งข้อมูลเปลี่ยน
• การเฝ้าระวังและการตรวจสอบ: log ตัวชี้วัดความเสี่ยง การทบทวนเป็นรอบ และหลักฐานที่แสดงต่อหน่วยงานกำกับหรือลูกค้าได้

การจัดระดับความเสี่ยงช่วยให้ Governance ไม่หนักเกินจำเป็น ตัวสรุปเอกสารสาธารณะกับ agent ที่แก้ไขระบบ production ได้ ไม่ควรต้องผ่านกระบวนการเดียวกัน

ยึดกรอบมาตรฐานที่มีอยู่แล้ว

ไม่ต้องคิดกรอบขึ้นเอง กรอบเหล่านี้ตอบคนละคำถาม

• NIST AI RMF (กรอบบริหารความเสี่ยง AI ของ NIST มีสี่หน้าที่หลักคือ Govern, Map, Measure, Manage) และ Generative AI Profile (NIST AI 600-1 ภาคเสริมสำหรับ generative AI): โครงสร้างบริหารความเสี่ยงที่องค์กรเลือกนำไปใช้ได้โดยสมัครใจ อ่านต่อที่ NIST AI RMF คืออะไร: กรอบบริหารความเสี่ยง AI สำหรับองค์กร
• ISO/IEC 42001 (เผยแพร่ธันวาคม 2023): มาตรฐานระบบบริหารจัดการ AI ที่องค์กรขอการรับรองได้ มีประโยชน์เมื่อลูกค้าหรือผู้ตรวจสอบต้องการหลักฐานรับรองจากหน่วยงานอิสระ
• OWASP Top 10 for LLM Applications 2025: รายการภัยคุกคามเชิงเทคนิคที่ใช้อธิบายเจ็ดชั้นข้างต้น
• MITRE ATLAS และ NIST AI 100-2: รายการเทคนิคของผู้โจมตีและการจัดหมวดการโจมตี ใช้ประกอบการทำ threat modeling (การวิเคราะห์ว่าระบบอาจถูกโจมตีทางไหนได้บ้าง) และ red team
• NCSC Guidelines for Secure AI System Development: แนวทางที่ครอบคลุมตลอดวงจรชีวิตของระบบ ตั้งแต่ออกแบบ พัฒนา นำไปใช้ จนถึงการดูแลระบบ จัดทำโดย NCSC (หน่วยงานความปลอดภัยไซเบอร์ของสหราชอาณาจักร) ร่วมกับ CISA (หน่วยงานความมั่นคงปลอดภัยไซเบอร์ของสหรัฐฯ) และพันธมิตรนานาชาติ

ภาพรวมกฎหมายและกฎระเบียบ (ณ ตุลาคม 2026)

กฎระเบียบเปลี่ยนเร็ว จึงควรตรวจสอบสถานะล่าสุดก่อนอ้างอิงวันที่ใด ๆ

• EU AI Act: กฎหมาย AI ของสหภาพยุโรป กำหนดภาระตามระดับความเสี่ยง และมีผลบังคับถึงองค์กรนอกสหภาพยุโรปด้วย ตามสรุปของสำนักงานกฎหมาย Digital Omnibus on AI (Regulation (EU) 2026/1744 มีผลตั้งแต่ 27 กรกฎาคม 2026) เลื่อนกำหนดภาระของระบบความเสี่ยงสูงใน Annex III ไปเป็น 2 ธันวาคม 2027 และของระบบที่ฝังในผลิตภัณฑ์ตาม Annex I ไปเป็น 2 สิงหาคม 2028 ส่วนหน้าที่ด้านความโปร่งใส และภาระของโมเดล AI วัตถุประสงค์ทั่วไป (general-purpose AI) ไม่ถูกเลื่อน
• ประเทศไทย: เท่าที่แหล่งข้อมูลสาธารณะระบุ ร่าง พ.ร.บ. AI ยังเป็นร่างอยู่ หลังการรับฟังความคิดเห็นสาธารณะในปี 2026 จนกว่าจะมีกฎหมายประกาศใช้ การใช้ AI จึงถูกกำกับทางอ้อมผ่าน PDPA (พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคล) กฎหมายคุ้มครองผู้บริโภค และหน่วยงานกำกับดูแลของแต่ละภาคส่วน ดังนั้น AI ที่ประมวลผลข้อมูลส่วนบุคคลจึงอยู่ภายใต้ PDPA อยู่แล้ว

โปรแกรม Governance ที่สร้างบนการจัดระดับความเสี่ยง บัญชีรายการ และหลักฐาน ใช้รองรับได้ทั้งสองกรณี เมื่อมีกฎหมายออกมาจึงไม่ต้องเริ่มใหม่

ขั้นแรกที่ทำได้ทันที

ทำให้คืบหน้าได้จริงภายในไม่กี่สัปดาห์โดยไม่ต้องซื้ออะไรเพิ่ม

• ทำบัญชีรายการ: สอบถามแต่ละทีมว่าใช้ AI อะไรอยู่ ตรวจ log ของ SaaS และเครือข่าย และรวมฟีเจอร์ AI ที่ฝังมากับซอฟต์แวร์ด้วย
• ออกนโยบายการใช้งานหน้าเดียว: เริ่มจากตารางเทียบระดับชั้นข้อมูลกับเครื่องมือที่อนุมัติแล้วก็เพียงพอ
• ระบุเจ้าของและคณะทำงาน: ความรับผิดชอบสำคัญกว่าขนาดของคณะกรรมการ
• จัดระดับ use case: ให้ตรวจด้านความปลอดภัยและความเป็นส่วนตัวเฉพาะกลุ่มที่เสี่ยงสูงสุด
• เริ่มจากมาตรการที่คุ้มค่าที่สุด: ได้แก่ agent ที่มีสิทธิ์เท่าที่จำเป็น การตรวจสอบเอาต์พุต การค้นคืนข้อมูลที่ตรวจสิทธิ์ผู้ใช้ การจัดการความลับ และการจำกัดอัตราการเรียก
• บันทึก ทดสอบ และซ้อม: กำหนดรอบการทำ red team และเขียน playbook รับมือเหตุการณ์ที่เกี่ยวกับ AI โดยเฉพาะ

หากต้องการดูว่าองค์กรอยู่ตรงไหน ลองใช้ แบบประเมินตนเอง ซึ่งนำคำตอบไปจัดเป็นลำดับความสำคัญของสิ่งที่ควรทำต่อ ส่วนมุมที่ AI ช่วยฝ่ายป้องกันใน SOC (ศูนย์เฝ้าระวังภัยไซเบอร์) อ่านได้ที่ นำ AI มาใช้ใน SOC เพื่อลด MTTD และ MTTR (MTTD คือเวลาเฉลี่ยที่ใช้ตรวจพบเหตุ MTTR คือเวลาเฉลี่ยที่ใช้ตอบสนอง)

ข้อควรระวัง

• ถือว่า guardrail เป็นมาตรการหลัก: guardrail (ตัวกรองและข้อจำกัดที่ครอบโมเดลไว้) และ system prompt ช่วยลดความเสี่ยงได้ แต่ถูกหลบเลี่ยงได้ จึงต้องมีการกำหนดสิทธิ์ การตรวจสอบ และการอนุมัติหนุนหลังอีกชั้น
• Governance บนกระดาษ: นโยบายที่ไม่มีใครบังคับใช้หรือวัดผลเป็นภาระ ไม่ใช่มาตรการ
• ห้ามใช้ AI ทั้งหมด: มักผลักให้การใช้งานไปอยู่นอกสายตาองค์กรและเกิด Shadow AI ควรจัดเครื่องมือที่อนุมัติแล้วไว้ให้แทน
• เชื่อคำสัญญาของผู้ให้บริการอย่างเดียว: คำสัญญาอย่าง "ไม่นำข้อมูลของคุณไปฝึกโมเดล" ควรมีเงื่อนไขในสัญญาและหลักฐานรองรับ
• ประเมินครั้งเดียว: โมเดล prompt และแหล่งข้อมูลเปลี่ยนได้ จึงควรประเมินซ้ำทั้งเมื่อมีการเปลี่ยนแปลงและตามรอบเวลา

ชั้น agent และ tool ต้องใช้การควบคุมที่ลึกกว่านี้ เช่น การกำหนดระดับความเป็นอิสระของ agent ความไว้ใจระหว่าง agent และการตัดการทำงานฉุกเฉิน อ่านต่อใน Agentic AI Security: เมื่อ AI ลงมือทำเองได้ ต้องคุมอะไร

ตัวอย่างที่เป็นรูปธรรมของการกำกับดูแล AI คือเครื่องมือช่วยเขียนโค้ดและ vibe coding (การเขียนโปรแกรมโดยสั่งให้ AI เขียนให้เป็นหลัก) อ่านที่ ความปลอดภัยของ AI Coding Assistant และ Vibe Coding

การทดสอบและการทำ red teaming ของระบบ AI ทีละขั้น พร้อมกรอบอ้างอิง อ่านต่อใน AI Red Teaming: ทดสอบความปลอดภัยของระบบ AI อย่างไร

แหล่งอ้างอิงและข้อมูลเพิ่มเติม

• OWASP Top 10 for LLM Applications 2025: สิบความเสี่ยงที่ใช้ในบทความ
• NIST AI Risk Management Framework และ Generative AI Profile (NIST AI 600-1)
• NIST AI 100-2 E2025: อนุกรมวิธาน Adversarial Machine Learning
• MITRE ATLAS: กลยุทธ์และเทคนิคของผู้โจมตีต่อระบบ AI
• ISO/IEC 42001: ระบบบริหารจัดการ AI
• NCSC: Guidelines for secure AI system development
• Google Secure AI Framework (SAIF)
• กรอบกำกับ EU AI Act และ Orrick: การเปลี่ยนแปลงจาก Digital Omnibus
• Baker McKenzie: ร่าง พ.ร.บ. AI ของไทย 7 นัยสำคัญ