
ท่ามกลางการนำ AI มาใช้ในงานธุรกิจที่เติบโตอย่างรวดเร็ว รากฐานของ Cybersecurity กำลังเปลี่ยนแปลงไปอย่างสิ้นเชิง การโจมตีที่ใช้ประโยชน์จาก AI มีความซับซ้อนมากขึ้นเรื่อยๆ และระบบ AI เองก็กลายเป็นเป้าหมายการโจมตีรูปแบบใหม่ จากการสำรวจของ WEF พบว่า 94% ของผู้ตอบแบบสอบถามระบุว่า "AI คือปัจจัยที่ส่งผลเปลี่ยนแปลงมากที่สุดใน Cybersecurity" และรายงานของ IBM ระบุว่า 1 ใน 6 ของเหตุการณ์ Data Breach มีสาเหตุมาจากการใช้ AI ของผู้โจมตี
บทความนี้จะรวบรวมกรณีศึกษา Incident ล่าสุด แนวโน้มด้านกฎระเบียบ และ Industry Framework ที่เกี่ยวข้อง พร้อมอธิบาย "มาตรการที่ควรดำเนินการทันที" สำหรับผู้รับผิดชอบด้าน Information Security ขององค์กร ใน 3 ระดับ ได้แก่ ด้านเทคนิค ด้านการปฏิบัติงาน และด้าน Governance

ผลกระทบของ AI ต่อความปลอดภัยทางไซเบอร์นั้น สามารถทำความเข้าใจภาพรวมได้ง่ายขึ้น หากแบ่งพิจารณาออกเป็น 2 แกนหลัก หากมุ่งเน้นมาตรการเพียงแกนใดแกนหนึ่ง แกนที่เหลือก็จะกลายเป็นจุดอ่อนที่มองข้ามไป
ความเสี่ยงด้านความปลอดภัยที่เกี่ยวข้องกับ AI สามารถจัดระเบียบได้ตาม 2 แกนหลัก ดังนี้
แกนที่ 1: การโจมตีโดยใช้ AI (Offensive AI) คือกรณีที่ผู้โจมตีใช้ AI เป็น "อาวุธ" ได้แก่ การปลอมแปลงตัวตนด้วย Deepfake, การสร้างอีเมลฟิชชิง (Phishing) ที่แนบเนียนโดย AI, และการสร้าง Polymorphic Malware โดยอัตโนมัติ รูปแบบการโจมตีแบบเดิมถูก AI เร่งความเร็ว ขยายขนาด และปรับให้เป็นแบบ Personalized จนฝ่ายป้องกันตรวจจับได้ไม่ทัน ก่อให้เกิดโครงสร้างของปัญหาที่ยากต่อการรับมือ
แกนที่ 2: การโจมตีต่อ AI (Attacks on AI) คือการโจมตีที่มุ่งเป้าไปยังระบบ AI ที่องค์กรนำมาใช้งานโดยตรง ได้แก่ การใช้ Prompt Injection เพื่อแก้ไขพฤติกรรมของ LLM, การฝังแบ็คดอร์ในข้อมูลฝึกสอน (Data Poisoning), และการใช้ประโยชน์จากการเชื่อมต่อเครื่องมือของ AI Agent ในทางที่ผิด ยิ่งองค์กรนำ AI มาใช้มากเท่าใด ความเสี่ยงในแกนนี้ก็ยิ่งเพิ่มสูงขึ้นเท่านั้น
กรณีที่ทั้งสองแกนตัดกันก็เพิ่มมากขึ้นเช่นกัน ตัวอย่างเช่น มีการยืนยันพบกรณีที่ผู้โจมตีจากกลุ่มที่มีความเชื่อมโยงกับจีนได้ทำการ Jailbreak AI Coding Assistant และสามารถทำให้กระบวนการโจมตีทางไซเบอร์ (Cyberattack Chain) เป็นแบบอัตโนมัติได้ถึง 80–90%
ระบบรักษาความปลอดภัยแบบดั้งเดิมถูกออกแบบมาบนสมมติฐานที่ว่า "ผู้โจมตีเป็นมนุษย์ ใช้เทคนิคที่รู้จักกันดี และใช้ malware รูปแบบตายตัว" แต่ AI ได้พลิกสมมติฐานทั้งสามข้อนี้โดยสิ้นเชิง
รายงาน Data Breach ประจำปี 2025 ของ IBM ระบุว่า องค์กรที่นำ AI security tool มาใช้อย่างแพร่หลายสามารถลดระยะเวลาในการตรวจจับและควบคุมภัยคุกคามได้เฉลี่ย 80 วัน และลดต้นทุนได้ถึง $1.9M ในทางกลับกัน หากไม่นำ AI มาใช้ในด้านการป้องกัน ความไม่สมดุลระหว่างผู้โจมตีและผู้ป้องกันก็จะยิ่งถ่างกว้างออกไปเรื่อยๆ

ผู้โจมตีใช้ประโยชน์จาก AI ใน 3 วิธีหลัก ทั้งหมดนี้เป็นการต่อยอดจากวิธีการเดิมที่มีอยู่แล้ว แต่สิ่งที่เหมือนกันคือ AI ได้ยกระดับทั้งคุณภาพและปริมาณขึ้นอย่างก้าวกระโดด
จากการสำรวจของ Cyble พบว่าในไตรมาสแรกของปี 2025 เพียงไตรมาสเดียว มีเหตุการณ์ที่เกี่ยวข้องกับ Deepfake เกิดขึ้นถึง 179 ครั้ง ซึ่งสูงกว่าตลอดทั้งปี 2024 ถึง 19% และ 62% ขององค์กรรายงานว่าตกเป็นเป้าหมายของการโจมตีด้วย Deepfake ในช่วง 12 เดือนที่ผ่านมา
สิ่งที่น่าเป็นห่วงเป็นพิเศษคือการโคลนเสียง (Voice Cloning) ในกรณีการโจมตีที่ใช้การโคลนเสียงของรัฐมนตรีกลาโหมอิตาลี ผู้โจมตีสามารถฉ้อโกงเงินไปได้ประมาณ 1 ล้านยูโร โดยใช้ตัวอย่างเสียงเพียงไม่กี่นาทีในการจำลองเสียงของบุคคลนั้น แล้วสั่งโอนเงินผ่านทางโทรศัพท์ นี่คือ Social Engineering ที่อยู่คนละมิติกับ "อีเมลน่าสงสัย" แบบเดิม เนื่องจากผู้รับแทบไม่มีโอกาสตั้งข้อสงสัยได้เลย
ยิ่งไปกว่านั้น การแพร่หลายของแพลตฟอร์ม "Deepfake-as-a-Service (DFaaS)" ทำให้ผู้โจมตีที่ไม่มีความเชี่ยวชาญด้านเทคนิคสามารถสร้าง Deepfake ได้เช่นกัน ผู้ให้บริการด้านความปลอดภัยหลายรายคาดการณ์ว่า ภายในปลายปี 2026 Deepfake จะกลายเป็นวิธีการเริ่มต้น (Default) ของ Social Engineering
จากรายงานปี 2025 ของ KnowBe4 พบว่าอีเมลฟิชชิ่ง 83% ถูกสร้างขึ้นโดย AI โดยมีการโจมตีด้วย ransomware หรือฟิชชิ่งเกิดขึ้นทุก 11 วินาที และมูลค่าความเสียหายจากการฉ้อโกงทางการเงินในสหรัฐอเมริกาพุ่งสูงถึง 1.25 หมื่นล้านดอลลาร์ในปี 2025
สิ่งที่ทำให้ฟิชชิ่งที่สร้างโดย AI เป็นปัญหาที่น่ากังวลอย่างยิ่ง คือการที่เบาะแสในการตรวจจับแบบเดิม อย่างเช่น "ภาษาที่ผิดธรรมชาติ" หรือ "รูปแบบข้อความที่ซ้ำซาก" ไม่สามารถใช้งานได้อีกต่อไป เนื่องจาก LLM สามารถวิเคราะห์โปรไฟล์ LinkedIn และโทนของอีเมลในอดีตของเป้าหมาย แล้วสร้างข้อความที่ดูเหมือนว่าบุคคลนั้นเป็นผู้เขียนเองได้ จากการทดสอบอีเมลฟิชชิ่งที่สร้างโดย AI ของผู้เขียน พบว่าเจ้าหน้าที่รักษาความปลอดภัยภายในองค์กร 3 ใน 5 คน ไม่สามารถแยกแยะได้ว่าเป็นอีเมลปลอม
สำหรับมาตรการรับมือนั้น นอกจากการบังคับใช้โปรโตคอลการยืนยันตัวตนอีเมล (DMARC, DKIM, SPF) อย่างเข้มงวดแล้ว การนำระบบกรองอีเมลที่ใช้ AI มาใช้งานก็กลายเป็นสิ่งที่ขาดไม่ได้ การตรวจจับโดยอาศัย "สายตามนุษย์" เพียงอย่างเดียวได้ถึงขีดจำกัดของมันแล้ว
มัลแวร์ที่ AI สร้างขึ้น 76% เป็นประเภท Polymorphic — เปลี่ยนแปลงโครงสร้างโค้ดทุกครั้งที่รัน เพื่อหลบเลี่ยงโปรแกรมแอนตี้ไวรัสแบบ Signature-based รายงานภัยคุกคามปี 2026 ของ Darktrace ยืนยันการเปลี่ยนผ่านจากการโจมตีที่มุ่งเน้น Exploit ไปสู่การโจมตีแบบขโมยข้อมูลประจำตัว (Credential Theft) โดยใช้ AI เป็นเครื่องมือหลัก
อีกหนึ่งความกังวลคือการทำให้ห่วงโซ่การโจมตีเป็นแบบอัตโนมัติ มีรายงานกรณีที่ Threat Actor สัญชาติจีน Jailbreak AI Coding Assistant และทำให้ห่วงโซ่การโจมตี 80–90% เป็นแบบอัตโนมัติ ครอบคลุมตั้งแต่การลาดตระเวน (Reconnaissance) การสร้าง Payload การส่ง และการเคลื่อนที่ในเครือข่าย (Lateral Movement) "อุปสรรคในการเข้าสู่" วงการโจมตีลดลงอย่างมาก และ AI กำลังทำให้การโจมตีขั้นสูงที่เคยต้องอาศัยทักษะเฉพาะทางกลายเป็นสินค้าทั่วไป (Commoditize)

หากนำ AI มาใช้งาน ตัว AI เองก็จะกลายเป็นพื้นที่โจมตีใหม่ OWASP ได้จัดระบบช่องโหว่เฉพาะของ LLM และอัปเดตเป็นประจำทุกปี บทความนี้จะสรุปเวกเตอร์การโจมตีหลักที่องค์กรควรตระหนักถึง
OWASP Top 10 for LLM Applications 2025 ระบุว่า Prompt Injection ยังคงอยู่ในอันดับที่ 1 อย่างต่อเนื่อง โดย 35% ของเหตุการณ์ด้านความปลอดภัยของ AI ในโลกจริงเกิดจาก Prompt อย่างง่าย และบางกรณีก่อให้เกิดความเสียหายมากกว่า 100,000 ดอลลาร์
กรณีตัวอย่างที่โดดเด่นคือช่องโหว่ "EchoLeak" ของ Microsoft 365 Copilot (CVE-2025-32711) ซึ่งเป็น Zero-Click Prompt Injection ที่ทำให้ผู้โจมตีสามารถขโมยข้อมูลทางธุรกิจที่เป็นความลับได้โดยไม่ต้องอาศัยการกระทำใดๆ จากผู้ใช้ เพียงแค่ฝัง Prompt ที่เป็นอันตรายลงในเอกสารที่แชร์หรืออีเมลที่ได้รับ Copilot ก็จะดำเนินการตามนั้นโดยอัตโนมัติ
ความยากที่แท้จริงของ Prompt Injection อยู่ที่ขอบเขตระหว่าง "คำสั่ง" และ "ข้อมูล" ที่ไม่ชัดเจน ในกรณีของ SQL Injection มีมาตรการที่ชัดเจนอย่าง Parameterized Query แต่สำหรับ LLM นั้น ยังไม่มีวิธีมาตรฐานที่ได้รับการยอมรับในการแยก Prompt ออกจาก User Input อย่างสมบูรณ์
การทดลองเชิงประจักษ์โดยนักวิจัยพบว่า เพียงแค่การฉีดเอกสารที่ปนเปื้อน 250 รายการเข้าไปในข้อมูลการเรียนรู้ ก็สามารถฝัง backdoor ที่ตรวจจับได้ยากลงในโมเดลได้ backdoor แบบ "Sleeper Agent" นี้จะทำงานได้ปกติ 99.9% ในสภาวะทั่วไป และจะแสดงพฤติกรรมอันตรายก็ต่อเมื่อมีการป้อน trigger phrase ที่กำหนดไว้เท่านั้น
ในเดือนมกราคม 2025 ได้มีการพิสูจน์ให้เห็นว่า LLM ทางการแพทย์อาจถูกโจมตีผ่าน data poisoning ในโดเมนที่เกี่ยวข้องโดยตรงกับ YMYL (Your Money or Your Life) อย่างวงการแพทย์ หาก AI ให้ผลลัพธ์ที่ผิดพลาด ผลกระทบที่ตามมาย่อมประเมินค่าไม่ได้
ในฐานะมาตรการรับมือ การจัดการห่วงโซ่ที่มาของข้อมูลการเรียนรู้ (Data Provenance) และการจัดทำ AI-BOM (AI Bill of Materials) จึงมีความสำคัญอย่างยิ่ง หากไม่สามารถทำให้ "ข้อมูลใด โดยใคร และเรียนรู้เมื่อใด" ตลอดทั้ง supply chain เป็น traceable ได้ การตรวจจับ poisoning ก็เป็นเรื่องที่แทบเป็นไปไม่ได้
การโจมตีที่ใช้ประโยชน์จากกลไกที่ AI Agent ใช้เรียกใช้งานเครื่องมือภายนอก (เช่น MCP: Model Context Protocol) กำลังเพิ่มขึ้นอย่างรวดเร็ว
ตัวอย่างที่ได้รับการยืนยันจริง:
การโจมตีเหล่านี้ตรวจจับได้ยากด้วยการตรวจสอบเครือข่ายแบบดั้งเดิม เนื่องจาก AI Agent เรียกใช้เครื่องมือภายนอกในฐานะ "การดำเนินการปกติ" จึงมักไม่เกิดรูปแบบ Traffic ที่ผิดปกติ แนวทางรับมือหลักประกอบด้วยการตรวจสอบความถูกต้องของ Input สำหรับการเชื่อมต่อเครื่องมือ การกำหนดให้ใช้ Signed Artifact และการบันทึก Log การดำเนินการทั้งหมด

มีความเสี่ยงที่ใกล้ตัวกว่าการโจมตีทางเทคนิค และยังจัดการได้ยากกว่าด้วย นั่นคือ "Shadow AI" ซึ่งหมายถึงการที่พนักงานนำเครื่องมือ AI มาใช้ในการทำงานโดยไม่ได้รับการอนุมัติจากฝ่าย IT
Gartner คาดการณ์ว่าภายในปี 2030 องค์กรมากกว่า 40% จะประสบกับเหตุการณ์ด้านความปลอดภัยและการปฏิบัติตามกฎระเบียบ (Security & Compliance Incident) อันเนื่องมาจากเครื่องมือ AI ที่ไม่ได้รับอนุมัติ จากการสำรวจในปี 2025 พบว่า 69% ขององค์กรตอบว่า "สงสัยว่าพนักงานใช้งาน Public GenAI ที่ถูกห้ามอยู่"
สิ่งที่ทำให้ Shadow AI เป็นปัญหาที่น่าหนักใจ คือพนักงานที่ใช้งานมักมีเจตนาดี โดยนำมาใช้เพื่อเพิ่มประสิทธิภาพในการทำงาน ไม่ว่าจะเป็นการวางข้อมูลลูกค้าลงใน ChatGPT เพื่อสร้างรายงาน หรือการส่ง Source Code ให้ Claude ช่วยหาบัก — แม้ประสิทธิภาพส่วนบุคคลจะเพิ่มขึ้น แต่ก็แฝงไว้ด้วยความเสี่ยงที่ข้อมูลความลับจะรั่วไหลไปยังบริการภายนอก นอกจากนี้ยังมีผลการสำรวจที่ระบุว่าใน 27% ขององค์กร ข้อมูลที่ถูกประมวลผลด้วย AI มากกว่า 30% มีข้อมูลส่วนตัวรวมอยู่ด้วย
รายงานการละเมิดข้อมูลประจำปี 2025 ของ IBM ได้เปิดเผยตัวเลขความเสียหายที่เพิ่มขึ้นจากการละเมิดข้อมูลที่เกี่ยวข้องกับ Shadow AI โดยการละเมิดที่มี Shadow AI เข้ามาเกี่ยวข้องมีต้นทุนสูงกว่าการละเมิดทั่วไปเฉลี่ย $670,000 (ประมาณ 100 ล้านเยน) และในปัจจุบัน 20% ของการละเมิดข้อมูลทั้งหมดมีความเชื่อมโยงกับ Shadow AI
ปัจจัยหลักที่ทำให้ต้นทุนเพิ่มสูงขึ้น ได้แก่:
การใช้จ่ายด้าน AI Governance คาดว่าจะแตะระดับ $492M ในปี 2026 และมีแนวโน้มจะเกิน $1B ในปี 2030 ความสำคัญที่เพิ่มขึ้นของการลงทุนในด้านนี้สะท้อนให้เห็นถึงความรุนแรงที่เพิ่มขึ้นของ "ต้นทุนที่มองไม่เห็น" อันเกิดจาก Shadow AI

ในปี 2026 รูปแบบการใช้งาน AI กำลังเปลี่ยนผ่านจาก "chatbot" ไปสู่ "autonomous agent" Gartner คาดการณ์ว่าภายในสิ้นปี 2026 แอปพลิเคชันระดับ enterprise ถึง 40% จะมี AI agent เฉพาะทางสำหรับงานแต่ละประเภทฝังอยู่ (เพิ่มขึ้นอย่างรวดเร็วจากที่ต่ำกว่า 5% ในปี 2025) แม้ว่า agent จะมีความสามารถสูง แต่ความเสี่ยงด้านความปลอดภัยก็เปลี่ยนแปลงไปในเชิงคุณภาพเช่นกัน
OWASP ได้ร่วมมือกับผู้เชี่ยวชาญในอุตสาหกรรมกว่า 100 คน เพื่อเผยแพร่ "OWASP Top 10 for Agentic Applications 2026" ซึ่งรวบรวมความเสี่ยงที่เฉพาะเจาะจงสำหรับระบบ AI อัตโนมัติ แตกต่างจาก LLM Top 10 แบบเดิม โดยมุ่งเน้นไปที่สภาพแวดล้อมที่ Agent สามารถเรียกใช้ Tool ได้อย่างอิสระ ตัดสินใจเอง และประสานงานกับ Agent อื่น ๆ
หมวดหมู่ความเสี่ยงหลัก:
จากการสำรวจในช่วงต้นปี 2026 พบว่า 80% ขององค์กรที่นำ AI agent มาใช้งานรายงานว่าพบ "พฤติกรรมอันตราย เช่น การเข้าถึงโดยไม่ได้รับอนุญาต และการเปิดเผยข้อมูล" ในขณะที่ผู้บริหารที่สามารถมองเห็นสิทธิ์และการเข้าถึงข้อมูลของ agent ได้อย่างครบถ้วนมีเพียง 21% และองค์กรที่ระบุว่า "พร้อมรับมือ" กับความปลอดภัยของ agent มีเพียง 29% เท่านั้น
สาเหตุหลักของช่องว่างนี้อยู่ที่การออกแบบให้ agent "ตัดสินใจแทนมนุษย์" chatbot นั้นต้องการให้มนุษย์ป้อน prompt และตรวจสอบผลลัพธ์ก่อนจึงจะดำเนินการ แต่ agent จะทำการตัดสินใจขั้นกลางโดยอัตโนมัติ ส่งผลให้ input ที่เป็นอันตรายเพียงครั้งเดียวสามารถก่อให้เกิดการกระทำต่อเนื่องเป็นลูกโซ่ได้ ยิ่งมีขั้นตอนที่ไม่มีมนุษย์เข้ามาตรวจสอบมากเท่าใด ความเสี่ยงก็จะยิ่งขยายตัวแบบทวีคูณมากเท่านั้น
CyberArk Labs ได้สาธิตสถานการณ์การโจมตีที่แสดงให้เห็นถึงความเสี่ยงของ Agent อย่างชัดเจน
ผู้โจมตีฝัง prompt อันตรายไว้ในช่องที่อยู่จัดส่งของเว็บไซต์อีคอมเมิร์ซ เมื่อเจ้าหน้าที่ฝ่ายขายใช้ AI Agent เพื่อตรวจสอบข้อมูลคำสั่งซื้อ Agent จะ "อ่าน" ข้อมูลที่อยู่นั้น และดำเนินการตาม prompt ที่ฝังไว้ราวกับเป็นคำสั่ง ผลลัพธ์คือข้อมูลที่เป็นความลับในฐานข้อมูลคำสั่งซื้อถูกส่งออกไปยังภายนอก
บทเรียนที่ได้จากกรณีนี้มี 3 ประการ:

สภาพแวดล้อมด้านกฎระเบียบที่เกี่ยวข้องกับ AI security กำลังได้รับการจัดระเบียบอย่างรวดเร็ว องค์กรต่างๆ จำเป็นต้องรับมือไม่เพียงแค่ในแง่ของมาตรการทางเทคนิคเท่านั้น แต่ยังต้องคำนึงถึงมุมมองด้าน compliance ด้วยเช่นกัน
EU AI Act มีการบังคับใช้แบบเป็นขั้นตอน โดย "ข้อกำหนดสำหรับระบบ AI ความเสี่ยงสูง" ซึ่งมีผลกระทบมากที่สุดจะมีผลบังคับใช้อย่างสมบูรณ์ในเดือนสิงหาคม ปี 2026
| วันที่บังคับใช้ | เนื้อหา |
|---|---|
| กุมภาพันธ์ 2025 | การห้ามใช้ระบบ AI ที่ต้องห้ามมีผลบังคับใช้ |
| สิงหาคม 2025 | พันธกรณีสำหรับโมเดล AI อเนกประสงค์ (GPAI) เริ่มต้น |
| สิงหาคม 2026 | ข้อกำหนดสำหรับระบบ AI ความเสี่ยงสูงมีผลบังคับใช้อย่างสมบูรณ์ |
| กรณีละเมิด | สูงสุด 35 ล้านยูโร หรือ 7% ของรายได้ทั่วโลก |
องค์กรที่ดำเนินการระบบที่ถูกจัดประเภทเป็น AI ความเสี่ยงสูง (เช่น การคัดเลือกพนักงาน การให้คะแนนเครดิต การจัดการโครงสร้างพื้นฐานที่สำคัญ เป็นต้น) จะต้องจัดให้มีระบบการจัดการความเสี่ยง การกำกับดูแลข้อมูล (Data Governance) ข้อกำหนดด้านความโปร่งใส และกลไกการกำกับดูแลโดยมนุษย์ แม้แต่บริษัทญี่ปุ่นก็อยู่ในขอบเขตการบังคับใช้ หากให้บริการภายในเขต EU
ในสหรัฐอเมริกา NIST AI Risk Management Framework (AI RMF) ทำหน้าที่เป็นกรอบมาตรฐานโดยพฤตินัย โดยบริหารจัดการความเสี่ยงด้าน AI อย่างเป็นระบบผ่าน 4 เฟส ได้แก่ "Map (ระบุ)、Measure (วัด)、Manage (จัดการ)、Govern (กำกับดูแล)" สำหรับโปรไฟล์เฉพาะสำหรับ Generative AI (AI 600-1) นั้น ได้มีการกำหนดหมวดหมู่ความเสี่ยงไว้ 12 ประเภท
ในระดับมาตรฐานสากล ISO/IEC 42001 ให้การรับรองมาตรฐานระบบการจัดการ AI นอกจากนี้ยังถูกนำมาใช้เป็นเครื่องมือในการแสดงความสอดคล้องกับข้อกำหนดความเสี่ยงสูงของ EU AI Act อีกด้วย
แม้ว่ากรอบการทำงานเหล่านี้จะไม่ใช่ข้อบังคับ แต่ก็ทำหน้าที่เป็นหลักฐานว่า "ได้ดำเนินมาตรการที่สมเหตุสมผลแล้ว" ในกรณีที่เกิดเหตุการณ์ด้านความปลอดภัย นอกจากนี้ยังมีคุณค่าที่ควรพิจารณานำไปใช้ในแง่ของการตอบสนองต่อข้อกำหนดจากคู่ค้าทางธุรกิจและการรับมือกับการตรวจสอบ (Audit) อีกด้วย
ในเดือนมกราคม ปี 2026 รัฐบาลกลางสหรัฐอเมริกาได้เผยแพร่ "คำขอข้อมูล (RFI) เกี่ยวกับความปลอดภัยของ AI Agent" ในราชกิจจานุเบกษาของรัฐบาลกลาง (Federal Register) นี่คือสัญญาณบ่งชี้ถึงการกำกับดูแลด้านความเสี่ยงด้านความปลอดภัยที่เป็นลักษณะเฉพาะของ AI Agent โดยมุ่งเน้นไปที่ระบบ AI ที่สามารถตัดสินใจและดำเนินการได้อย่างอิสระ
แม้ยังไม่อยู่ในขั้นตอนของการออกกฎหมาย แต่ทิศทางนั้นชัดเจนแล้ว มีความเป็นไปได้สูงที่จะมีข้อกำหนดเกี่ยวกับการจัดการสิทธิ์ของ Agent การบันทึก Log ของการดำเนินการ และการรับประกันฟังก์ชัน Override โดยมนุษย์ การเตรียมความพร้อมและจัดระบบรับมือล่วงหน้าจะช่วยลดต้นทุนในการปฏิบัติตามกฎระเบียบภายหลังการบังคับใช้ได้อย่างมีนัยสำคัญ

เมื่อเข้าใจความเสี่ยงแล้ว ขั้นตอนต่อไปคือการป้องกันอย่างเป็นรูปธรรม มาตรการด้าน AI Security นั้นสร้างขึ้นบน 3 ชั้น ได้แก่ "Technology" "Operations" และ "Governance" หากขาดชั้นใดชั้นหนึ่งไป ย่อมเกิดช่องโหว่ขึ้นอย่างหลีกเลี่ยงไม่ได้
1. การจัดทำ AI-BOM (AI Bill of Materials) เช่นเดียวกับ SBOM ของซอฟต์แวร์ ให้บริหารจัดการแหล่งที่มาของ model, ข้อมูลการเรียนรู้ และ library ที่ใช้ในระบบ AI แบบรวมศูนย์ สิ่งนี้มีความสำคัญอย่างยิ่งต่อการตรวจจับ model poisoning และการโจมตีแบบ supply chain รวมถึงการระบุขอบเขตของผลกระทบ
2. การกรองข้อมูลขาเข้าและขาออก (Input/Output Filtering) ติดตั้ง filtering layer ทั้งในส่วนของ input และ output สำหรับ LLM เพื่อตรวจจับ prompt injection, ป้องกันการแสดงผลข้อมูลที่ละเอียดอ่อน (PII, API key ฯลฯ) และบล็อกการสร้าง code ที่เป็นอันตราย
3. หลักการสิทธิ์ขั้นต่ำ (Principle of Least Privilege) จำกัดการเข้าถึง tool ที่มอบให้ AI agent เฉพาะสิ่งที่จำเป็นขั้นต่ำสุดสำหรับการปฏิบัติงาน ควบคุมระดับความละเอียดให้ชัดเจน เช่น แทนที่จะให้สิทธิ์เข้าถึง database แบบเต็ม ให้อนุญาตเพียงการอ่านข้อมูลจาก table ที่กำหนดเท่านั้น นอกจากนี้ การ logging ทุก action ถือเป็นสิ่งที่ขาดไม่ได้
4. การนำเครื่องมือป้องกันที่ใช้ AI มาใช้งาน รายงานของ IBM ระบุว่าองค์กรที่ใช้ประโยชน์จาก AI security tool อย่างกว้างขวางมีต้นทุนจากการละเมิดข้อมูลต่ำกว่าถึง $1.9M เนื่องจากฝ่ายโจมตีใช้ AI อยู่แล้ว หากฝ่ายป้องกันไม่นำ AI มาใช้เช่นกัน ก็จะเสียเปรียบในด้านความเร็วในการตรวจจับ
1. การตรวจจับและจัดการ Shadow AI ผสานการใช้งาน DLP (Data Loss Prevention) และ CASB (Cloud Access Security Broker) เพื่อตรวจจับและบล็อกการส่งข้อมูลไปยังเครื่องมือ AI ที่ไม่ได้รับอนุญาต การห้ามใช้งานโดยสมบูรณ์นั้นไม่ใช่แนวทางที่ปฏิบัติได้จริง ดังนั้นการจัดทำรายการเครื่องมือ AI ที่ได้รับการอนุมัติและจัดหาทางเลือกที่ปลอดภัยให้แก่ผู้ใช้งานจึงเป็นวิธีที่มีประสิทธิภาพกว่า
2. การอบรมพนักงานเฉพาะด้าน AI จัดการฝึกซ้อมจำลองสถานการณ์โดยใช้ Deepfake และฟิชชิงที่สร้างโดย AI เป็นหัวข้อหลักอย่างสม่ำเสมอ สิ่งสำคัญคือต้องให้พนักงานตระหนักด้วยตนเองว่าเกณฑ์การตัดสินแบบเดิมที่ว่า "ข้อความอีเมลดูเป็นธรรมชาติจึงปลอดภัย" นั้นใช้ไม่ได้อีกต่อไป นอกจากนี้ การนำโปรโตคอลยืนยันตัวตนทางโทรศัพท์มาใช้ เช่น การโทรกลับเพื่อยืนยัน (Callback Confirmation) และการใช้รหัสลับ ก็เป็นมาตรการที่มีประสิทธิผลเช่นกัน
3. การจัดทำแผนรับมือเหตุการณ์ด้าน AI เพิ่มสถานการณ์เฉพาะที่เกี่ยวข้องกับ AI เข้าไปในแผนรับมือเหตุการณ์ (Incident Response Plan) ที่มีอยู่เดิม โดยควรกำหนดขั้นตอนล่วงหน้าให้ครอบคลุม ได้แก่ กระบวนการ Rollback เมื่อโมเดลถูกปนเปื้อน (Model Poisoning) การระบุขอบเขตความเสียหายเมื่อเกิด Prompt Injection สำเร็จ และขั้นตอนการรับมือเมื่อข้อมูลรั่วไหลจาก Shadow AI
1. การกำหนดนโยบายการใช้งาน AI รายงานของ IBM ระบุว่า 63% ของการละเมิดที่เกี่ยวข้องกับ AI เกิดจากการขาด AI Governance Policy กำหนดให้ชัดเจนว่างานใดที่อนุญาตให้ใช้ AI ข้อมูลใดที่สามารถป้อนเข้าสู่ AI ได้ และกระบวนการอนุมัติควรเป็นอย่างไร รูปแบบนโยบายที่เหมาะสมควรเป็น "Allowlist + Guardrails" มากกว่า "Blocklist"
2. การตรวจสอบความปลอดภัยของ AI อย่างสม่ำเสมอ ดำเนินการตรวจสอบสถานะความปลอดภัยของระบบ AI ทุกไตรมาส โดยใช้ OWASP Top 10 for LLM and Agentic Applications เป็น Checklist เพื่อตรวจสอบความทนทานต่อ Prompt Injection การตั้งค่าสิทธิ์ และขอบเขตการเข้าถึงข้อมูล นอกจากนี้ การใช้ Framework ของ MITRE ATLAS เพื่อ Mapping พื้นที่โจมตี AI จะช่วยเพิ่มความครอบคลุมในการประเมิน
3. การลงทุนล่วงหน้าเพื่อรองรับการปฏิบัติตามกฎระเบียบ เริ่มเตรียมความพร้อมด้านเอกสารการบริหารความเสี่ยง ระบบ Data Governance และรายงานความโปร่งใส โดยคำนึงถึงข้อกำหนดความเสี่ยงสูงของ EU AI Act (สิงหาคม 2026) และทิศทางกฎระเบียบ AI Agent ของสหรัฐอเมริกา มีความเป็นไปได้สูงที่ข้อกำหนดเหล่านี้จะมีขนาดใหญ่เกินกว่าจะรับมือได้ทัน หากรอให้กฎระเบียบมีผลบังคับใช้ก่อนแล้วค่อยดำเนินการ

ขอยกตัวอย่างรูปแบบความผิดพลาดที่องค์กรมักเผชิญในการดำเนินมาตรการด้านความปลอดภัย AI จำนวน 2 รูปแบบ
ความเข้าใจผิดที่ว่าเพียงแค่นำเครื่องมือด้านความปลอดภัย AI มาใช้แล้วจะปลอดภัยนั้นเป็นเรื่องอันตราย เครื่องมือเหล่านี้ช่วยเร่งความเร็วในการตรวจจับและตอบสนอง แต่หากนำไปใช้งานโดยปราศจากนโยบายที่ชัดเจน ก็จะก่อให้เกิดความเสี่ยงใหม่ขึ้นมาแทน
ตัวอย่างเช่น มีกรณีที่องค์กรนำ SIEM ที่ใช้ AI มาใช้งาน แต่ปล่อยให้ AI เป็นผู้กำหนดค่า threshold ของการแจ้งเตือนเอง ส่งผลให้เกิด false positive จำนวนมาก และทำให้ทีมความปลอดภัยตกอยู่ในภาวะ "alert fatigue" นอกจากนี้ยังต้องไม่ลืมว่าเครื่องมือป้องกันที่ใช้ AI เองก็อาจตกเป็นเป้าหมายของ prompt injection ได้เช่นกัน
เครื่องมือเหล่านี้เป็นเพียง "ชั้นเทคโนโลยี" ใน 3 ชั้นของการป้องกันเท่านั้น หากขาดการดำเนินงานและ governance ที่เหมาะสม ก็ไม่อาจได้รับผลลัพธ์ที่คุ้มค่ากับการลงทุนได้
รายงานปี 2025 ของ IBM เปิดเผยตัวเลขที่น่าเป็นห่วง โดย 97% ของการละเมิดที่เกี่ยวข้องกับ AI ขาดการควบคุมการเข้าถึง AI ที่เหมาะสม และ 63% ไม่มีนโยบาย AI Governance
การนำ AI ไปใช้งานโดยปราศจาก Governance จะก่อให้เกิดปฏิกิริยาลูกโซ่ดังต่อไปนี้:
แนวทาง "ลองใช้ก่อน แล้วค่อยแก้ปัญหาเมื่อเกิดขึ้น" มีต้นทุนสูงในบริบทของ AI การรักษาลำดับขั้นตอน ได้แก่ การกำหนดนโยบาย → การนำร่อง (Pilot) → การขยายผลแบบค่อยเป็นค่อยไป จะให้ความคุ้มค่าด้านต้นทุนสูงสุดในท้ายที่สุด

ตอบคำถามที่พบบ่อยอย่างกระชับ
จำเป็นอย่างยิ่ง ในทางกลับกัน บริษัทขนาดกลางและขนาดเล็กมีทีมรักษาความปลอดภัยที่มีขนาดเล็กกว่า จึงมีความต้านทานต่อการโจมตีที่ใช้ประโยชน์จาก AI ในทางที่ผิดได้น้อยกว่า อย่างไรก็ตาม เนื่องจากการลงทุนในระดับเดียวกับองค์กรขนาดใหญ่นั้นไม่เป็นไปได้ในทางปฏิบัติ จึงควรจัดลำดับความสำคัญในการรับมือ
มีสิ่งที่ควรดำเนินการขั้นต่ำ 3 ประการ ได้แก่ การทำความเข้าใจสถานการณ์การใช้งาน Shadow AI จริง (การนำ CASB มาใช้งาน) การอบรมพนักงานให้รับมือกับ Phishing ที่สร้างโดย AI และการกำหนด Policy การใช้งาน AI สำหรับมาตรการทางเทคนิค การเริ่มต้นด้วย Email Filtering ที่ใช้ AI เป็นพื้นฐานนั้นมีความคุ้มค่าด้านต้นทุนสูง
สามารถรับมือได้บางส่วน แต่ยังไม่เพียงพอ Firewall, WAF และ EDR มีประสิทธิภาพต่อการโจมตีแบบดั้งเดิม แต่ไม่ครอบคลุม Prompt Injection หรือ Model Poisoning แนวทางที่เป็นไปได้จริงคือการเพิ่ม Security Layer เฉพาะทางสำหรับ AI (เช่น LLM Firewall, เครื่องมือจัดการ AI-BOM เป็นต้น) เข้าไปในสแตกที่มีอยู่เดิม
ยึดหลักการสามข้อ ข้อแรกคือ "Least Privilege" — จำกัดการเข้าถึงเครื่องมือที่มอบให้ Agent ให้เหลือเพียงเท่าที่จำเป็นขั้นต่ำสุด ข้อที่สองคือ "Logging ทุก Action" — บันทึกสิ่งที่ Agent ดำเนินการไว้อย่างครบถ้วน เพื่อให้สามารถตรวจสอบ (Audit) ได้ ข้อที่สามคือ "Human Override" — ผนวก Human-in-the-Loop เข้าไปในการตัดสินใจที่สำคัญ นอกจากนี้ควรนำ OWASP Top 10 for Agentic Applications 2026 มาใช้เป็น Checklist ประกอบด้วย

ความเสี่ยงด้านความปลอดภัยทางไซเบอร์ของ AI กำลังขยายตัวอย่างรวดเร็วใน 2 แกนหลัก ได้แก่ "การโจมตีโดยใช้ AI" และ "การโจมตีต่อ AI" Deepfake เพิ่มขึ้น 19% เมื่อเทียบกับปีก่อน, Phishing ถึง 83% ถูกสร้างโดย AI และ 80% ขององค์กรที่นำ Agent มาใช้งานเคยประสบกับพฤติกรรมที่เป็นอันตราย — ตัวเลขเหล่านี้ล้วนชี้ให้เห็นถึง "วิกฤตที่กำลังเกิดขึ้นในขณะนี้"
มาตรการรับมือควรสร้างขึ้นใน 3 ชั้น ได้แก่ เทคโนโลยี การปฏิบัติงาน และ Governance โดยป้องกันในเชิงเทคนิคด้วย AI-BOM และการกรองข้อมูลขาเข้า/ขาออก (Input/Output Filtering), เสริมความแข็งแกร่งด้านการปฏิบัติงานด้วยการตรวจจับ Shadow AI และการอบรมพนักงาน และสร้าง Governance ด้วยนโยบายการใช้งาน AI และการตรวจสอบเป็นระยะ เมื่อมองไปยังข้อกำหนดความเสี่ยงสูงของ EU AI Act (เดือนสิงหาคม 2026) ถึงเวลาแล้วที่จะเริ่มลงทุนล่วงหน้าตั้งแต่ตอนนี้
การป้องกันที่สมบูรณ์แบบไม่มีอยู่จริง แต่การผสมผสาน 3 ชั้นเข้าด้วยกันจะช่วยควบคุมความเสี่ยงให้อยู่ในระดับที่ยอมรับได้ ขอให้เริ่มต้นด้วยการสำรวจและจัดทำรายการสถานะการใช้งาน AI ขององค์กรของคุณก่อนเป็นอันดับแรก
Yusuke Ishihara
เริ่มเขียนโปรแกรมตั้งแต่อายุ 13 ปี ด้วย MSX หลังจบการศึกษาจากมหาวิทยาลัย Musashi ได้ทำงานพัฒนาระบบขนาดใหญ่ รวมถึงระบบหลักของสายการบิน และโครงสร้าง Windows Server Hosting/VPS แห่งแรกของญี่ปุ่น ร่วมก่อตั้ง Site Engine Inc. ในปี 2008 ก่อตั้ง Unimon Inc. ในปี 2010 และ Enison Inc. ในปี 2025 นำทีมพัฒนาระบบธุรกิจ การประมวลผลภาษาธรรมชาติ และแพลตฟอร์ม ปัจจุบันมุ่งเน้นการพัฒนาผลิตภัณฑ์และการส่งเสริม AI/DX โดยใช้ generative AI และ Large Language Models (LLM)