AI Red Teaming: ทดสอบความปลอดภัยของระบบ AI อย่างไร

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

AI red teaming ต่างจากการทดสอบความปลอดภัยทั่วไปอย่างไร

OWASP (ชุมชนด้านความปลอดภัยซอฟต์แวร์แบบเปิด) เผยแพร่ GenAI Red Teaming Guide เวอร์ชัน 1.0 เมื่อเดือนมกราคม 2025 คู่มือนิยามว่า GenAI red teaming คือวิธีทดสอบที่มีโครงสร้าง โดยผสมความเชี่ยวชาญของคนเข้ากับระบบอัตโนมัติและเครื่องมือ AI ระบบที่ทดสอบคือระบบที่มี generative AI (AI ที่สร้างเนื้อหาใหม่ เช่น ข้อความหรือภาพ) เป็นส่วนประกอบ เป้าหมายคือหาช่องว่างสี่เรื่อง ได้แก่ safety (ความปลอดภัยของผู้ใช้) security (ความปลอดภัยของผู้ให้บริการระบบ) trust (ความไว้วางใจ) และประสิทธิภาพ ส่วน CISA (หน่วยงานด้านความมั่นคงปลอดภัยไซเบอร์ของสหรัฐ) ระบุในบล็อกเมื่อพฤศจิกายน 2024 ว่า AI red teaming คือการประเมินความปลอดภัยของระบบ AI โดยบุคคลที่สาม และเป็นส่วนย่อยของ TEVV (การทดสอบ ประเมิน ตรวจสอบ และยืนยันความถูกต้อง) ซึ่งงานซอฟต์แวร์ทำกันมานานแล้ว CISA จึงแนะนำให้ต่อยอดจากแนวปฏิบัติของซอฟต์แวร์เดิม ไม่ต้องสร้างกระบวนการแยกต่างหาก

OWASP สรุปความต่างจาก red team แบบเดิมไว้หลายข้อ ข้อสำคัญมีดังนี้:

• ขอบเขตกว้างกว่า: นอกจากช่องโหว่ทางเทคนิค ยังต้องทดสอบสิ่งที่โมเดลสร้างออกมา เช่น เนื้อหาอันตราย อคติ (bias) หรือข้อมูลผิดที่ AI พูดอย่างมั่นใจ (hallucination) และต้องมองทั้งมุมผู้โจมตีและมุมผู้ใช้ที่ได้รับผลกระทบ
• ผลลัพธ์ไม่แน่นอน: โมเดลอาจตอบต่างกันจากคำถามเดิม จึงต้องทดสอบแบบสถิติ คือทดลองซ้ำหลายครั้งแล้วดูสัดส่วน ไม่ใช่ดูว่าผ่านหรือไม่ผ่านครั้งเดียว
• เกณฑ์ตัดสินซับซ้อนกว่า: แยกความคลาดเคลื่อนปกติของโมเดลออกจากผลของการโจมตีได้ยาก OWASP ยกคำถามว่า ถ้าโมเดลแม่นยำเกิน 90% แล้วตอบผิด จะรู้ได้อย่างไรว่าเป็นความคลาดเคลื่อนปกติหรือเป็นฝีมือผู้โจมตี
• ต้องใช้ทีมหลายสาขา: ผู้เชี่ยวชาญด้าน responsible AI (การพัฒนา AI อย่างรับผิดชอบ) ดูเรื่องอคติและเนื้อหาอันตราย ส่วนผู้เชี่ยวชาญด้านความปลอดภัยไซเบอร์ดูเรื่องช่องทางลับ (backdoor) การข้ามมาตรการควบคุม และการนำไปใช้จริง

ทดสอบอะไรบ้าง: สี่ด้านของระบบ AI

AI ที่ใช้งานจริงไม่ได้มีแค่โมเดล แต่ประกอบด้วยตัวโมเดล ส่วนที่ครอบโมเดลไว้ ระบบรอบข้าง และคนที่ใช้งาน OWASP จึงแบ่งการทดสอบเป็นสี่ด้านดังนี้:

• โมเดล (model evaluation): ทดสอบจุดอ่อนของตัวโมเดลเอง เช่น ความทนต่อข้อความที่ออกแบบมาหลอก การสร้างเนื้อหาอันตราย อคติ และการหลุดข้อมูลที่โมเดลเคยเรียน
• ส่วนที่ครอบโมเดล (implementation): ทดสอบสิ่งที่ครอบโมเดลไว้ ได้แก่ system prompt (คำสั่งตั้งต้นที่ผู้พัฒนาซ่อนไว้ให้โมเดล) guardrail (กฎและตัวกรองที่คุมคำตอบของ AI) และ RAG (ระบบที่ให้ AI ค้นเอกสารขององค์กรมาประกอบคำตอบ) ว่าถูกหลอกให้ปล่อยสิ่งที่ไม่ควรผ่านหรือไม่
• ระบบรอบข้าง (system): ทดสอบ API, ที่เก็บข้อมูล, ห่วงโซ่อุปทาน (supply chain) ของโมเดลและไลบรารี (ชุดโค้ดสำเร็จรูปที่นำมาใช้) และการเชื่อมต่อกับระบบอื่น รวมถึงกรณีที่ AI ได้สิทธิ์ทำมากเกินไป
• ขณะใช้งานจริง (runtime): ทดสอบการโต้ตอบระหว่างคนกับ AI และระหว่าง agent (AI ที่ลงมือทำงานต่อเนื่องเอง) กับระบบอื่น ซึ่งรวมถึงการเชื่อ AI มากเกินไปและการหลอกลวงคน (social engineering)

OWASP ยกตัวอย่างช่องโหว่ของ Microsoft Copilot ที่เปิดเผยในงาน Black Hat USA (งานประชุมด้านความปลอดภัยไซเบอร์) ปี 2024 ช่องโหว่เหล่านี้ส่วนใหญ่ไม่ได้โจมตีจุดอ่อนของโมเดล แต่ใช้สิทธิ์การค้นหาที่ตั้งไว้หละหลวมในระบบรอบข้าง จนข้อมูลสำคัญรั่ว บทเรียนคือต้องทดสอบทั้งระบบ ไม่ใช่เฉพาะโมเดล ถ้าระบบมี agent ที่เรียกเครื่องมือและลงมือทำเอง ต้องทดสอบสิทธิ์และการอนุมัติของ agent ด้วย ดู Agentic AI Security: เมื่อ AI ลงมือทำเองได้ ต้องคุมอะไร

วิธีทำ AI red teaming ทีละขั้น

OWASP มี Quick Start Guide (คู่มือเริ่มต้นฉบับย่อ) ที่แนะนำขั้นแรก ๆ และมีภาพรวมกิจกรรมการประเมินรวม 11 ขั้น ตั้งแต่กำหนดขอบเขตจนถึงทดสอบซ้ำหลังแก้ไข ขั้นตอนด้านล่างเรียบเรียงจากสองส่วนนี้ ส่วนการเรียงลำดับเป็นของเราเอง ขั้นตอนมีดังนี้:

• กำหนดวัตถุประสงค์และขอบเขตตามความเสี่ยง: เริ่มจากระบบ AI ที่สำคัญต่อธุรกิจหรือใช้ข้อมูลอ่อนไหว ระบุให้ชัดว่าทดสอบระบบใด เรื่องอะไร และเรื่องใดอยู่นอกขอบเขต OWASP ให้ข้อสังเกตว่าระบบที่ใช้ภายในมักเสี่ยงน้อยกว่าระบบที่เปิดให้คนภายนอก
• ตั้งทีมผสมหลายสาขา: วิศวกร AI ผู้เชี่ยวชาญด้านความปลอดภัย และถ้าเป็นไปได้ผู้เชี่ยวชาญด้านจริยธรรมหรือกฎระเบียบ
• วิเคราะห์ภัยคุกคาม (threat modeling): คือการไล่ดูระบบอย่างเป็นระบบว่าผู้โจมตีจะเข้ามาทางไหนได้ OWASP ใช้สี่คำถามจาก Threat Modeling Manifesto คือ กำลังทำงานกับอะไร อะไรอาจผิดพลาด จะทำอย่างไรกับมัน และทำดีพอแล้วหรือยัง
• ตกลงกติกาการทดสอบและขออนุญาต: กติกาการทดสอบ (rules of engagement) กำหนดว่าทดสอบที่ไหน ใช้อะไรได้ ห้ามทำอะไร และใครตัดสินใจเมื่อเกิดปัญหา
• ทดสอบทั้งสี่ด้านด้วยทั้งคนและเครื่องมือ: ใช้เครื่องมืออัตโนมัติเพื่อให้ได้ปริมาณมาก และใช้คนตรวจผลกับคิดสถานการณ์ที่เครื่องมือคิดไม่ถึง
• รายงานพร้อมหลักฐานและระดับความรุนแรง: บันทึกกรณีทดสอบ หลักฐาน ผลกระทบ และคำแนะนำแก้ไข และมีช่องทางรายงานถึงผู้บริหารระดับสูงเมื่อพบเรื่องร้ายแรง
• แก้ไขแล้วทดสอบซ้ำ: OWASP ระบุว่า red teaming ไม่ใช่งานครั้งเดียว ควรทดสอบซ้ำหลังแก้ไข และทำเป็นระยะตลอดวงจรชีวิตของระบบ

ใช้กรอบอ้างอิงช่วยวางแผนทดสอบ

ไม่ต้องคิดรายการทดสอบเองทั้งหมด กรอบอ้างอิงต่อไปนี้ตอบคำถามต่างกัน:

• OWASP Top 10 for LLM Applications 2025: รายการความเสี่ยงสิบข้อของแอปที่ใช้ LLM (โมเดลภาษาขนาดใหญ่ ซึ่งอยู่เบื้องหลังแชตบอต) ใช้เป็นเช็กลิสต์ว่าควรทดสอบอะไร เช่น prompt injection (การแทรกคำสั่งหลอกให้โมเดลทำผิดจากที่ตั้งไว้)
• MITRE ATLAS (ฐานความรู้สาธารณะเกี่ยวกับวิธีโจมตีระบบ AI): รวบรวมกลยุทธ์ เทคนิค และวิธีการ (tactics, techniques, procedures) ของผู้โจมตีที่เล็งระบบ AI จัดรูปแบบคล้าย MITRE ATT&CK (ฐานความรู้เทคนิคของผู้โจมตีระบบไอทีทั่วไป) ข้อมูลเวอร์ชัน 2026.09 มี 16 กลยุทธ์ พร้อมมาตรการบรรเทาและกรณีศึกษา ตัวอย่างเช่น AML.T0051 LLM Prompt Injection แยกเป็น Direct, Indirect และ Triggered ใช้แปลงสถานการณ์ของผู้โจมตีเป็นกรณีทดสอบ และอ้างรหัสเทคนิคในรายงานได้
• NIST AI 100-2 E2025: การจัดหมวดหมู่ (taxonomy) ของการโจมตีและมาตรการบรรเทา ฉบับสมบูรณ์ (final) เมื่อมีนาคม 2025 ครอบคลุมทั้ง AI แบบทำนาย (predictive AI) และ generative AI ใช้เป็นภาษากลางในการเรียกประเภทการโจมตี
• NIST AI 600-1: Generative AI Profile (กรกฎาคม 2024) อธิบายการทำ AI red-teaming และรูปแบบของทีมทดสอบ OWASP ใช้เป็นหนึ่งในสามเอกสารอ้างอิงหลักเรื่องขอบเขตการทดสอบ

OWASP แนะนำให้ทดสอบตามช่วงชีวิตของโมเดลด้วย คือช่วงจัดหาโมเดล ช่วงทดลองและฝึก และช่วงให้บริการ ศัพท์เรื่องช่วงชีวิตนี้ OWASP ยืมมาจาก ISO/IEC 5338:2023 ส่วนมาตรฐาน ISO ที่เจาะจงเรื่อง AI red teaming เราไม่พบในการตรวจครั้งนี้ ภาพรวมเจ็ดชั้นของระบบ AI ที่ควรปกป้องและการกำกับดูแล อยู่ใน AI Security และ AI Governance: ป้องกันทุกองค์ประกอบของ AI

ใครทดสอบ และใช้เครื่องมืออัตโนมัติอย่างไร

NIST AI 600-1 ระบุว่าคุณภาพของผลการทดสอบสัมพันธ์กับภูมิหลังและความเชี่ยวชาญของทีม ทีมที่หลากหลายและเข้าใจบริบทการใช้งานช่วยหาข้อบกพร่องได้ในสถานการณ์ที่ต่างกัน NIST ยกรูปแบบของทีมไว้สี่แบบ ดังนี้:

• ผู้ใช้ทั่วไป (general public): คนที่คาดว่าจะใช้ระบบจริง นำประสบการณ์ของตนมาลองกระตุ้นให้ระบบแสดงพฤติกรรมที่เป็นอันตราย NIST ระบุว่าแบบนี้อาจได้ผลดีขึ้นเมื่อมีผู้ร่วมทดสอบกลุ่มใหญ่
• ผู้เชี่ยวชาญ (expert): ผู้ชำนาญเฉพาะด้าน เช่น การแพทย์ ชีวเทคโนโลยี หรือความปลอดภัยไซเบอร์
• แบบผสม (combination): ใช้ทั้งสองกลุ่ม เช่น ให้ผู้เชี่ยวชาญแก้ไขหรือตรวจข้อความทดสอบที่ผู้ใช้ทั่วไปเขียน
• คนร่วมกับ AI (human/AI): ใช้ generative AI ช่วยหรือนำการทดสอบ NIST ระบุว่าอาจคุ้มค่ากว่าการใช้คนอย่างเดียว และแต่ละแบบอาจเหมาะกับการหาอันตรายคนละชนิด

เครื่องมืออัตโนมัติช่วยให้ลองโจมตีได้เร็วและทำซ้ำได้ OWASP ระบุเครื่องมือโอเพนซอร์สไว้ในภาคผนวก เช่น PyRIT ของ Microsoft, garak และ promptfoo ซึ่งเป็นเพียงตัวอย่าง ไม่ใช่การจัดอันดับ NIST AI 100-2 อธิบายการทดสอบอัตโนมัติแบบหนึ่งว่าใช้โมเดลผู้โจมตี โมเดลเป้าหมาย และโมเดลผู้ตัดสิน (judge) ที่ประเมินว่าคำตอบอันตรายหรือไม่ OWASP เตือนว่าต้องมีคนตรวจผลของเครื่องมือ เพราะเครื่องมืออาจตัดสินผิดได้ทั้งสองทาง คือบอกว่าปลอดภัยทั้งที่ไม่ปลอดภัย หรือบอกว่าอันตรายทั้งที่ไม่ใช่ OWASP ยังเตือนว่าการผ่านการทดสอบอัตโนมัติส่วนใหญ่ไม่ได้แปลว่าระบบปลอดภัย และการไม่ผ่านก็ไม่ได้แปลว่าไม่ปลอดภัย เพราะชุดทดสอบอาจออกแบบไว้สำหรับโมเดลคนละแบบ

อ่านผลและวัดผลอย่างไร

เพราะคำตอบของโมเดลไม่คงที่ ผลทดสอบครั้งเดียวจึงบอกอะไรได้น้อย OWASP เสนอตัวชี้วัดตั้งต้นให้ปรับตามกรณีใช้งาน ตัวอย่างมีดังนี้:

• อัตราการโจมตีสำเร็จ (ASR: Attack Success Rate): สัดส่วนของข้อมูลที่ป้อนเข้าไปเพื่อโจมตี (adversarial input) ที่ทำให้เกิดพฤติกรรมไม่พึงประสงค์ได้จริง
• อัตราการตรวจจับ (Detection Rate): สัดส่วนของข้อมูลโจมตีที่กลไกป้องกันตรวจพบและทำเครื่องหมายได้ถูกต้อง
• ระดับความรุนแรงของข้อค้นพบ: OWASP เสนอแนวทางสี่ระดับคือ Critical, High, Medium และ Low โดยให้แต่ละองค์กรกำหนดเกณฑ์ของตนเอง
• ตัวชี้วัดการดำเนินงาน: อัตราการพบช่องโหว่ เวลาในการตรวจพบ ความครอบคลุมของการทดสอบ อัตราการแจ้งเตือนผิดพลาด (false positive) และประสิทธิผลของการแก้ไข

NIST AI 100-2 เตือนว่าต้องประเมินมาตรการป้องกันกับการโจมตีแบบปรับตัว (adaptive attack คือผู้โจมตีที่รู้มาตรการป้องกันแล้วปรับวิธีโจมตีให้เข้ากัน) ที่รุนแรง และยอมรับว่าการออกแบบมาตรการบรรเทาเป็นกระบวนการที่ทำแบบเฉพาะกิจและพลาดได้ OWASP ระบุว่าไม่มีโมเดล AI ใดที่ "เสร็จสมบูรณ์" หรือ "ปลอดภัย" อย่างแท้จริง OWASP ยังระบุว่า red team ทำหน้าที่หาปัญหา ส่วนการปิดช่องว่างมักเป็นหน้าที่ของ blue team (ทีมป้องกัน) หรือ purple team (ทีมที่ประสานงานระหว่างฝ่ายโจมตีและฝ่ายป้องกัน) ข้อค้นพบทุกข้อจึงควรมีเจ้าของที่รับไปแก้ ควรอ่านผลทดสอบตามนี้:

• ผ่านการทดสอบอัตโนมัติ ไม่ได้แปลว่าปลอดภัย: เป็นหลักฐานเฉพาะข้อที่ทดสอบเท่านั้น
• ทดสอบซ้ำเมื่อมีการเปลี่ยนแปลง: OWASP ยกตัวอย่างว่าเมื่อเพิ่ม RAG เข้าไป โมเดลตอบตรงข้อเท็จจริงขึ้นแต่เข้าใจอารมณ์ผู้ใช้น้อยลง ทั้งที่ไม่ได้แตะตัวโมเดล
• ลองโจมตีหลายครั้งและปรับวิธี: การโจมตีที่ล้มเหลวหนึ่งครั้งไม่ได้พิสูจน์ว่าป้องกันได้

ความปลอดภัยของการทดสอบเอง

การจำลองโจมตีอาจสร้างความเสียหายจริงได้ถ้าไม่มีกติกา OWASP ระบุหัวข้อที่กติกาการทดสอบควรครอบคลุมดังนี้:

• สภาพแวดล้อมและเครื่องมือ: ทดสอบที่ไหน ใช้เครื่องมือและเทคนิคใดได้ และมาตรฐานการบันทึกและการสื่อสารเป็นอย่างไร
• การควบคุมความปลอดภัย: วิธีจัดการข้อมูล การควบคุมการเข้าถึงโมเดล การเฝ้าดูผลลัพธ์ แผนรับมือเหตุการณ์ และความสามารถในการย้อนกลับ (rollback)
• ขอบเขตด้านจริยธรรม: หัวข้อที่อ่อนไหว ข้อจำกัดของเนื้อหา ความเป็นส่วนตัว และข้อกำหนดทางกฎหมาย
• ขั้นตอนฉุกเฉินและการแจ้งเหตุ: ถ้าพบเรื่องร้ายแรง ต้องแจ้งใครและทำอะไรทันที
• การอนุญาต: ต้องได้รับอนุญาตที่จำเป็นจากผู้เกี่ยวข้องก่อนเริ่ม

หลักความปลอดภัยของการจำลองโดยทั่วไป เช่น แยกสภาพแวดล้อมทดสอบออกจากระบบที่ใช้งานจริง และขออนุญาตเป็นลายลักษณ์อักษร อ่านเพิ่มใน Network & Cyber Security Simulator: ประเภทและการใช้งาน ส่วนด้านที่เกี่ยวกับคน เช่น การเชื่อ AI มากเกินไปและการหลอกลวง ดู Security Awareness และ Phishing Simulation ที่ได้ผล

ข้อผิดพลาดที่พบบ่อย

• ทดสอบแต่โมเดล: ละเลย guardrail ระบบรอบข้าง และสิทธิ์ ทั้งที่กรณีของ Copilot ตามที่ OWASP ยกมาเกิดจากสิทธิ์การค้นหาที่หละหลวม ไม่ใช่จุดอ่อนของโมเดล
• ทดสอบครั้งเดียวแล้วจบ: โมเดล คำสั่งตั้งต้น และแหล่งข้อมูลเปลี่ยนได้ ผลเก่าจึงใช้ไม่ได้ตลอดไป
• เชื่อผลของเครื่องมืออัตโนมัติโดยไม่ตรวจ: เครื่องมืออาจตัดสินผิดได้ทั้งสองทาง
• เริ่มทดสอบโดยไม่มีขอบเขตและไม่ได้รับอนุญาต: ไม่มีกติกา ไม่มีใครรู้ว่าเมื่อใดควรหยุด
• ทีมมีแต่คนด้านความปลอดภัยหรือมีแต่นักพัฒนา: ขาดคนที่ดูเรื่องเนื้อหาอันตราย อคติ และบริบทการใช้งาน
• ไม่มีเจ้าของแก้ข้อค้นพบ: รายงานที่ไม่มีใครรับไปแก้ไม่ได้ทำให้ระบบปลอดภัยขึ้น

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

• ทำบัญชีรายการระบบ AI: รวมทั้งที่สร้างเอง และฟีเจอร์ AI ในซอฟต์แวร์สำเร็จรูป พร้อมบันทึกว่าแต่ละระบบเข้าถึงข้อมูลและเครื่องมืออะไร
• เลือกหนึ่งระบบที่เสี่ยงที่สุด: เช่น ระบบที่เชื่อมกับข้อมูลอ่อนไหวหรือมีสิทธิ์ลงมือทำ
• ตอบสี่คำถามของ threat modeling: กำลังทำงานกับอะไร อะไรอาจผิดพลาด จะทำอย่างไรกับมัน และทำดีพอแล้วหรือยัง
• เขียนขอบเขตและกติกาหนึ่งหน้า: ระบุสิ่งที่ทดสอบ สิ่งที่ห้ามแตะ ผู้อนุญาต และผู้ที่ต้องแจ้งเมื่อพบเรื่องร้ายแรง
• ลองกรณีทดสอบเล็ก ๆ ในสภาพแวดล้อมทดสอบ: ซ่อนคำสั่งหลอกไว้ในเอกสารที่ระบบจะอ่าน แล้วดูว่าระบบทำตามหรือไม่
• ตั้งตัวชี้วัดตั้งต้นและนัดทดสอบซ้ำ: เริ่มจาก ASR กับอัตราการตรวจจับ แล้วกำหนดวันทดสอบซ้ำหลังแก้ไข

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

สำหรับความต่างระหว่าง red team, pen test และการประเมินช่องโหว่ในระบบทั่วไป ดู Vulnerability Assessment, Pen Test และ Red Team ต่างกันอย่างไร

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

• OWASP GenAI Red Teaming Guide: เวอร์ชัน 1.0 เดือนมกราคม 2025 มีสี่ด้านของการทดสอบ ขั้นตอน ตัวชี้วัด และรายการเครื่องมือ
• OWASP: Announcing the Gen AI Red Teaming Guide: ประกาศเปิดตัวคู่มือเมื่อ 22 มกราคม 2025
• OWASP Top 10 for LLM Applications 2025: สิบความเสี่ยงที่ใช้เป็นเช็กลิสต์การทดสอบ
• MITRE ATLAS: ฐานความรู้เกี่ยวกับเทคนิคของผู้โจมตีที่เล็งระบบ AI พร้อมกรณีศึกษา
• MITRE ATLAS data (GitHub): ข้อมูล ATLAS แบบอ่านด้วยเครื่อง ใช้ตรวจเวอร์ชันและจำนวนกลยุทธ์
• NIST AI 100-2 E2025: Adversarial Machine Learning: อนุกรมวิธานของการโจมตีและมาตรการบรรเทา ฉบับ final มีนาคม 2025 พร้อมนิยามของ red teaming
• NIST AI 600-1: Generative AI Profile: โปรไฟล์ความเสี่ยงของ generative AI กรกฎาคม 2024 มีหัวข้อ AI red-teaming
• CISA: AI Red Teaming: Applying Software TEVV for AI Evaluations: บล็อกวันที่ 26 พฤศจิกายน 2024