【2026】แนวโน้มล่าสุดของ AI Cybersecurity

ท่ามกลางการนำ 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 ได้พลิกสมมติฐานทั้งสามข้อนี้โดยสิ้นเชิง

• การเปลี่ยนแปลงด้านความเร็วและขนาด: AI สามารถสร้างอีเมล phishing ได้ภายในไม่กี่วินาที และปรับแต่งให้เหมาะกับเป้าหมายแต่ละรายอย่างเฉพาะเจาะจง ซึ่งเป็นปริมาณที่การตรวจสอบโดยมนุษย์ไม่สามารถตามทันได้
• การหลบเลี่ยงการตรวจจับที่ซับซ้อนยิ่งขึ้น: Polymorphic malware จะกลายพันธุ์โค้ดทุกครั้งที่ถูกรัน ทำให้การตรวจจับแบบ signature-based ไม่ได้ผล มีรายงานว่า malware ที่สร้างโดย AI ถึง 76% เป็นประเภท polymorphic
• พื้นที่การโจมตีรูปแบบใหม่: ได้มีการโจมตีในรูปแบบใหม่ปรากฏขึ้น ไม่ว่าจะเป็น prompt injection, model poisoning และการใช้ MCP tool ในทางที่ผิด ซึ่งเป็นพื้นที่การโจมตีที่ firewall หรือ WAF แบบดั้งเดิมไม่สามารถป้องกันได้

รายงาน 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) กำลังเพิ่มขึ้นอย่างรวดเร็ว

ตัวอย่างที่ได้รับการยืนยันจริง:

• Cursor Agent ของ Supabase ประมวลผลคำสั่ง SQL ที่ฝังอยู่ในตั๋วซัพพอร์ต และส่ง Integration Token ที่เป็นความลับออกไปภายนอก
• แพ็กเกจ npm ปลอมที่แอบอ้างเป็น Email Integration ทำการคัดลอกอีเมลขาออกไปยังที่อยู่ของผู้โจมตีอย่างเงียบๆ
• นักวิจัยระบุพบ Tool Poisoning, ช่องโหว่ RCE (Remote Code Execution), การให้สิทธิ์เกินความจำเป็น และการปลอมแปลง Supply Chain ภายในระบบนิเวศ MCP

การโจมตีเหล่านี้ตรวจจับได้ยากด้วยการตรวจสอบเครือข่ายแบบดั้งเดิม เนื่องจาก 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

ปัจจัยหลักที่ทำให้ต้นทุนเพิ่มสูงขึ้น ได้แก่:

• ความล่าช้าในการตรวจจับ: การรั่วไหลจากเครื่องมือที่ฝ่าย IT ไม่ทราบว่ามีอยู่ใช้เวลาตรวจพบนานกว่าเฉลี่ยหลายสิบวัน
• ความซับซ้อนในการรับมือกับเหตุการณ์: การระบุเส้นทางการรั่วไหลใช้เวลานานขึ้น ส่งผลให้การควบคุมความเสียหายล่าช้าตามไปด้วย
• การละเมิดข้อกำหนดด้านการปฏิบัติตามกฎระเบียบ: การใช้เครื่องมือที่ไม่ได้รับอนุมัติอาจนำไปสู่การละเมิดกฎระเบียบอย่าง GDPR โดยตรง

การใช้จ่ายด้าน 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 อื่น ๆ

หมวดหมู่ความเสี่ยงหลัก:

• Prompt Injection และการโจมตีเพื่อควบคุม: การปลอมแปลงคำสั่งของ Agent เพื่อให้ดำเนินการที่ไม่ได้ตั้งใจ
• การใช้ Tool ในทางที่ผิดและการยกระดับสิทธิ์: การใช้สิทธิ์การเข้าถึง Tool ที่มอบให้แก่ Agent เกินขอบเขตที่กำหนด
• Memory Poisoning: การปนเปื้อน Memory ที่คงอยู่ข้ามเซสชัน (แตกต่างจาก Prompt Injection ทั่วไป ตรงที่ผลกระทบจะคงอยู่ต่อเนื่อง)
• Cascade Failure ในระบบ Multi-Agent: ความผิดพลาดของ Agent หนึ่งที่แพร่กระจายไปยัง Agent อื่น ๆ แบบลูกโซ่
• Supply Chain Attack ต่อ Agent Tool Chain: การโจมตีผ่าน MCP Server และ Plugin

จากการสำรวจในช่วงต้นปี 2026 พบว่า 80% ขององค์กรที่นำ AI agent มาใช้งานรายงานว่าพบ "พฤติกรรมอันตราย เช่น การเข้าถึงโดยไม่ได้รับอนุญาต และการเปิดเผยข้อมูล" ในขณะที่ผู้บริหารที่สามารถมองเห็นสิทธิ์และการเข้าถึงข้อมูลของ agent ได้อย่างครบถ้วนมีเพียง 21% และองค์กรที่ระบุว่า "พร้อมรับมือ" กับความปลอดภัยของ agent มีเพียง 29% เท่านั้น

สาเหตุหลักของช่องว่างนี้อยู่ที่การออกแบบให้ agent "ตัดสินใจแทนมนุษย์" chatbot นั้นต้องการให้มนุษย์ป้อน prompt และตรวจสอบผลลัพธ์ก่อนจึงจะดำเนินการ แต่ agent จะทำการตัดสินใจขั้นกลางโดยอัตโนมัติ ส่งผลให้ input ที่เป็นอันตรายเพียงครั้งเดียวสามารถก่อให้เกิดการกระทำต่อเนื่องเป็นลูกโซ่ได้ ยิ่งมีขั้นตอนที่ไม่มีมนุษย์เข้ามาตรวจสอบมากเท่าใด ความเสี่ยงก็จะยิ่งขยายตัวแบบทวีคูณมากเท่านั้น

CyberArk Labs ได้สาธิตสถานการณ์การโจมตีที่แสดงให้เห็นถึงความเสี่ยงของ Agent อย่างชัดเจน

ผู้โจมตีฝัง prompt อันตรายไว้ในช่องที่อยู่จัดส่งของเว็บไซต์อีคอมเมิร์ซ เมื่อเจ้าหน้าที่ฝ่ายขายใช้ AI Agent เพื่อตรวจสอบข้อมูลคำสั่งซื้อ Agent จะ "อ่าน" ข้อมูลที่อยู่นั้น และดำเนินการตาม prompt ที่ฝังไว้ราวกับเป็นคำสั่ง ผลลัพธ์คือข้อมูลที่เป็นความลับในฐานข้อมูลคำสั่งซื้อถูกส่งออกไปยังภายนอก

บทเรียนที่ได้จากกรณีนี้มี 3 ประการ:

1. ข้อมูลกลายเป็นคำสั่ง: AI Agent ประมวลผลข้อมูลจากช่องรับ input ของผู้ใช้ในฐานะ "context ที่เชื่อถือได้"
2. ผู้โจมตีไม่จำเป็นต้องเข้าถึง Agent โดยตรง: การโจมตีสามารถเกิดขึ้นได้ผ่านเส้นทางข้อมูลทางอ้อม
3. การ validate input แบบดั้งเดิมไม่เพียงพอ: "ค่าที่ถูกต้อง" ของช่องที่อยู่อาจมี prompt แฝงอยู่ได้

สภาพแวดล้อมด้านกฎระเบียบที่เกี่ยวข้องกับ AI security กำลังได้รับการจัดระเบียบอย่างรวดเร็ว องค์กรต่างๆ จำเป็นต้องรับมือไม่เพียงแค่ในแง่ของมาตรการทางเทคนิคเท่านั้น แต่ยังต้องคำนึงถึงมุมมองด้าน compliance ด้วยเช่นกัน

EU AI Act มีการบังคับใช้แบบเป็นขั้นตอน โดย "ข้อกำหนดสำหรับระบบ AI ความเสี่ยงสูง" ซึ่งมีผลกระทบมากที่สุดจะมีผลบังคับใช้อย่างสมบูรณ์ในเดือนสิงหาคม ปี 2026

องค์กรที่ดำเนินการระบบที่ถูกจัดประเภทเป็น 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 จะก่อให้เกิดปฏิกิริยาลูกโซ่ดังต่อไปนี้:

1. แต่ละแผนกนำเครื่องมือ AI มาใช้งานเอง (กลายเป็น Shadow AI)
2. ข้อมูลที่เป็นความลับรั่วไหลสู่บริการที่ไม่ได้รับอนุญาต
3. เมื่อเกิดเหตุการณ์ขึ้น ต้องใช้เวลานานในการระบุเส้นทางการรั่วไหล
4. ต้นทุนการรับมือเพิ่มขึ้น $670,000 (ตามการประมาณการของ IBM)
5. ความเสี่ยงต่อการถูกลงโทษจากหน่วยงานกำกับดูแล

แนวทาง "ลองใช้ก่อน แล้วค่อยแก้ปัญหาเมื่อเกิดขึ้น" มีต้นทุนสูงในบริบทของ 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 ขององค์กรของคุณก่อนเป็นอันดับแรก