การสร้างระบบ LLM Red Teaming ภายในองค์กร: การจัดระเบียบและการดำเนินงานด้านการทดสอบความปลอดภัย

การสร้างโครงสร้างองค์กรสำหรับ LLM Red Teaming คือการจัดตั้งกลไกที่ฝ่ายความปลอดภัย ฝ่าย AI และฝ่ายธุรกิจทำงานร่วมกัน โดยมีการแบ่งบทบาทหน้าที่ที่ชัดเจนและใช้การผสมผสานระหว่างระบบอัตโนมัติกับการตัดสินใจโดยมนุษย์ เพื่อให้สามารถตรวจจับช่องโหว่และปรับปรุง LLM ที่ใช้งานจริงได้อย่างต่อเนื่อง บทความนี้จัดทำขึ้นสำหรับผู้รับผิดชอบด้านความปลอดภัย ทีมปฏิบัติการ AI และฝ่ายความปลอดภัยสารสนเทศในองค์กรที่นำ LLM มาใช้งานแล้ว โดยจะอธิบายแนวคิดการออกแบบโครงสร้างองค์กรโดยอ้างอิงจากมาตรฐานต่างๆ เช่น NIST AI RMF และ OWASP LLM Top 10 เมื่ออ่านจบ คุณจะสามารถออกแบบตารางแบ่งบทบาทหน้าที่และกระบวนการทดสอบที่เหมาะสมกับองค์กรของคุณ รวมถึงเข้าใจขั้นตอนที่เป็นรูปธรรมในการดำเนินรอบการทดสอบรายไตรมาส ทั้งนี้ บทความนี้เป็นเพียงแนวทางทั่วไปในการสร้างโครงสร้างองค์กรเท่านั้น สำหรับการตัดสินใจในการนำไปใช้งานจริงในแต่ละกรณี ขอแนะนำให้ปรึกษาผู้เชี่ยวชาญหรือผู้ดูแลที่เกี่ยวข้อง

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

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

ดังที่เห็นได้จากตาราง การนำเครื่องมือมาใช้เป็นเพียงวิธีการขยายขอบเขตการตรวจพบเท่านั้น หากไม่มีขั้นตอนการตอบสนองหลังตรวจพบหรือการประสานงานระหว่างแผนก ประสิทธิผลที่ได้ก็จะจำกัด โดยเฉพาะอย่างยิ่ง การติดตามการเปลี่ยนแปลงของ Prompt หรือการอัปเดตโมเดลนั้น หากอาศัยเพียงความตั้งใจดีของผู้รับผิดชอบก็จะไม่มีความต่อเนื่อง ในการตัดสินใจลำดับความสำคัญของการสร้างโครงสร้างองค์กร โปรดใช้สถานะที่ว่าบริษัทของท่านอยู่ในสภาวะ "ตรวจพบปัญหาได้แล้ว แต่ยังไม่สามารถจัดการได้อย่างทั่วถึง" เป็นเกณฑ์แรกในการพิจารณา

โครงสร้างการทำ LLM Red Teaming ไม่สามารถสำเร็จได้ด้วยแผนกเดียว แต่จะทำงานได้ก็ต่อเมื่อทั้ง 3 ฝ่าย ได้แก่ ฝ่ายความปลอดภัย (Security), ฝ่าย AI/ML และฝ่ายธุรกิจ (Business) นำเกณฑ์การตัดสินใจที่แตกต่างกันมาร่วมกันพิจารณา การประเมินช่องโหว่ทางเทคนิคและการประเมินผลกระทบทางธุรกิจเป็นคนละเรื่องกัน ดังนั้น การแบ่งบทบาทหน้าที่ของแต่ละแผนกให้ชัดเจนตั้งแต่เริ่มต้นจึงเป็นจุดเริ่มต้นของการออกแบบโครงสร้างองค์กรนี้

ฝ่ายความปลอดภัยมีหน้าที่รับผิดชอบในการวางแผนการทดสอบและการตัดสินใจขั้นสุดท้ายในการประเมินผล โดยเฉพาะอย่างยิ่ง จะต้องกำหนดว่าหมวดหมู่ใดจาก OWASP LLM Top 10 (เช่น Prompt Injection, การรั่วไหลของข้อมูลที่เป็นความลับ, สิทธิ์ของเอเจนต์ที่มากเกินไป เป็นต้น) ที่จะนำมาเป็นเป้าหมายในการทดสอบครั้งนี้ พร้อมทั้งระบุขอบเขตของระบบที่ทดสอบ รายการที่ยกเว้น และระยะเวลาดำเนินการลงในแผนงาน นอกจากนี้ ยังรวมถึงบทบาทในการตรวจสอบความสมเหตุสมผลของสถานการณ์การโจมตี โดยรับข้อมูลโครงสร้างโมเดลและเนื้อหาของ System Prompt ที่ได้รับจากฝ่าย AI/ML ในขั้นตอนการวางแผน ในการจำกัดขอบเขตการทดสอบ หากมีการแยกรายการที่สามารถตรวจสอบได้ด้วยการป้อนข้อมูลเพียงครั้งเดียว เช่น Direct Injection ออกจากรายการที่ต้องใช้การตรวจสอบหลายขั้นตอนผ่านแหล่งข้อมูลภายนอก เช่น Indirect Injection และระบุไว้ในแผนอย่างชัดเจน จะช่วยให้การประมาณระยะเวลาดำเนินการมีความแม่นยำและไม่คลาดเคลื่อนง่าย

ในการประเมินผล จำเป็นต้องจำแนกช่องโหว่ที่ตรวจพบตามระดับความรุนแรง และต้องแยกจัดการระหว่างช่องโหว่ที่เป็นที่รู้จักซึ่งลงทะเบียนไว้ในฐานข้อมูลภายนอก เช่น CVE กับปัญหาเฉพาะของ LLM ที่ขึ้นอยู่กับบริบท (เช่น อัตราความสำเร็จของการ Jailbreak, ขอบเขตการเข้าถึงของ Indirect Injection เป็นต้น) หากใช้ตัวชี้วัดอย่าง Attack Success Rate (ASR) ประเด็นสำคัญในทางปฏิบัติสำหรับการประเมินคือการวัดรูปแบบการโจมตีเดิมอย่างต่อเนื่องเพื่อให้สามารถเปรียบเทียบก่อนและหลังการอัปเดตโมเดลได้

นอกจากนี้ การนำผลลัพธ์ที่ได้จากเครื่องมือวินิจฉัยอัตโนมัติ เช่น Promptfoo หรือ PyRIT มาใช้เป็นขั้นตอนการคัดกรองเบื้องต้น (Primary Screening) รวมถึงการกำจัดผลลัพธ์ที่ผิดพลาด (False Positive) และการจัดลำดับความสำคัญโดยใช้บุคลากร ก็ถือเป็นหน้าที่ของฝ่ายความปลอดภัยเช่นกัน ระดับความรุนแรงและลำดับความสำคัญที่ตัดสินในขั้นตอนนี้จะเป็นข้อมูลนำเข้าสำหรับกระบวนการอนุมัติโดยฝ่ายธุรกิจในลำดับถัดไป การรับผิดชอบตั้งแต่การวางแผนทดสอบไปจนถึงการประเมินผลอย่างครบวงจร จะช่วยให้สามารถระบุเหตุผลสนับสนุนสำหรับมาตรการปรับปรุงที่ฝ่าย AI/ML จะนำไปดำเนินการได้อย่างชัดเจน

แผนก AI/ML มีหน้าที่อธิบายสาเหตุที่ช่องโหว่ที่ตรวจพบเกิดขึ้น โดยอ้างอิงจากหลักการทำงานของโมเดลและดำเนินการปรับปรุงแก้ไข เพื่อให้แผนกความปลอดภัยสามารถประเมินความสมเหตุสมผลของสถานการณ์การโจมตีได้ จำเป็นต้องอาศัยข้อมูลทางเทคนิค เช่น โครงสร้างของ System Prompt, ขอบเขตการเรียนรู้ของการทำ Fine-tuning, ขนาดของ Chunk ใน RAG และการตั้งค่าการค้นหา (Search settings) ซึ่งแผนก AI/ML จะเป็นจุดเริ่มต้นในการให้ข้อมูลเหล่านี้ ตัวอย่างเช่น ในกรณีที่การทำ Jailbreak ประสบความสำเร็จ แผนกจะทำการจำลองว่าข้อจำกัดของ System Prompt ถูกหลีกเลี่ยงด้วยการใช้คำถามที่เปลี่ยนรูปแบบไปได้อย่างไร และแยกแยะว่าสาเหตุเกิดจากลำดับการเขียนคำสั่ง (Instruction) หรือเกิดจากการกระจายตัวของข้อมูลที่ใช้เรียนรู้ (Training data distribution)

ในการดำเนินการปรับปรุง จะมีการพิจารณามาตรการรับมือหลายรูปแบบ เช่น การแก้ไข System Prompt, การเพิ่มกฎของ Guardrails และการเสริมความแข็งแกร่งให้กับการตรวจสอบ Grounding ของ RAG พร้อมทั้งประเมินว่าการแก้ไขดังกล่าวจะส่งผลกระทบต่อคุณภาพการตอบกลับเดิมหรือไม่ เนื่องจากการแก้ไขที่ต้องอาศัยการอัปเดตโมเดลหรือการทำ Fine-tuning มีต้นทุนในการตรวจสอบสูงกว่าการปรับปรุงฟังก์ชันทั่วไป เกณฑ์การตัดสินใจในทางปฏิบัติจึงมักเริ่มจากการพิจารณาขอบเขตที่สามารถแก้ไขได้ด้วยการปรับเปลี่ยนที่ฝั่ง Prompt ก่อน

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

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

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

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

ใน RACI สิ่งสำคัญคือต้องแยกแยะระหว่างผู้รับผิดชอบงาน (Responsible) และผู้รับผิดชอบผลลัพธ์ (Accountable) การรวมอำนาจการตัดสินใจขั้นสุดท้ายไว้ที่บุคคลหรือแผนกเดียว ในขณะที่กระจายงานปฏิบัติการตามความเชี่ยวชาญของแต่ละฝ่าย จะช่วยป้องกันสถานการณ์ที่งานต้องหยุดชะงักจากการรอการอนุมัติ

ดังที่เห็นได้จากตาราง แผนกความปลอดภัยรับผิดชอบผลลัพธ์ในการวางแผนและการตรวจหาช่องโหว่ แผนก AI/ML รับผิดชอบผลลัพธ์ในการนำมาตรการแก้ไขไปใช้ และแผนกธุรกิจเป็นผู้ตัดสินใจขั้นสุดท้ายในการอนุมัติการปล่อยมาตรการแก้ไข หากกำหนดให้หลายแผนกถือสถานะ A ในรายการงานเดียวกัน จะทำให้เกิดความล่าช้าในกรณีฉุกเฉินเนื่องจากไม่ทราบว่าฝ่ายใดเป็นผู้ตัดสินใจขั้นสุดท้าย ดังนั้นจึงต้องจำกัดให้มีเพียง 1 แผนกเท่านั้นที่ถือสถานะ A นอกจากนี้ อย่าปล่อยให้ความแตกต่างระหว่าง C (ปรึกษาหารือ) และ I (รับทราบ) คลุมเครือ การรวมแผนกที่เพียงแค่ต้องรับทราบข้อมูลเข้ามาในการปรึกษาหารือจะทำให้โครงสร้างการประชุมขยายตัวเกินความจำเป็น และส่งผลให้ความเร็วในการดำเนินงานตามรอบรายไตรมาสลดลง

การสร้างระบบควรดำเนินการตามลำดับคือ การวินิจฉัยสถานะปัจจุบัน การจัดวางบุคลากร และการสร้างมาตรฐานกระบวนการ เพื่อลดการทำงานซ้ำซ้อน หากกำหนดการแบ่งบทบาทหน้าที่ก่อนโดยที่ยังไม่สอดคล้องกับขีดความสามารถในการดำเนินงานที่มีอยู่จริง การดำเนินงานนั้นก็จะล้มเหลว ดังนั้นลำดับขั้นตอนที่นำผลการวินิจฉัยมาเป็นรากฐานแล้วจึงค่อยจัดวางคนและกลไกให้สอดรับกัน จึงเป็นจุดตัดสินสำคัญในการปฏิบัติงานจริง

ในการวินิจฉัยสถานะปัจจุบัน เราจะทำการตรวจสอบว่าการดำเนินงานด้านความปลอดภัยที่มีอยู่นั้น สามารถรับมือกับความเสี่ยงเฉพาะของ LLM ได้มากน้อยเพียงใด แม้แต่ในองค์กรที่มีระบบการทดสอบการเจาะระบบ (Penetration Test) ทั่วไปอยู่แล้ว แต่ช่องโหว่เฉพาะของ LLM เช่น Prompt Injection หรือ Hallucination มักจะไม่ได้รวมอยู่ในรายการการวินิจฉัยที่มีอยู่ ดังนั้นจุดเริ่มต้นจึงอยู่ที่การทำให้เห็นภาพชัดเจนว่าส่วนใดที่ยังขาดหายไป โดยเฉพาะอย่างยิ่ง เราจะจัดระเบียบรายการวินิจฉัยออกเป็น 3 ประเด็น ดังนี้:

1. ทีมรักษาความปลอดภัยที่มีอยู่มีประสบการณ์ในการตรวจสอบหมวดหมู่ของ OWASP LLM Top 10 มากน้อยเพียงใด
2. แผนก AI/ML อยู่ในสถานะที่สามารถเปิดเผยเนื้อหาของ System Prompt และการทำ Fine-tuning ให้กับแผนกรักษาความปลอดภัยได้หรือไม่
3. แผนกธุรกิจมีประสบการณ์ในการตัดสินใจโดยเชื่อมโยงความรุนแรงของช่องโหว่เข้ากับผลกระทบทางธุรกิจหรือไม่

หากประเด็นใดประเด็นหนึ่งใน 3 ข้อนี้ยังไม่พร้อม การออกแบบโครงสร้างองค์กรจำเป็นต้องดำเนินการในลักษณะที่เข้ามาเติมเต็มส่วนที่ขาดหายไปนั้น ตัวอย่างเช่น หากแผนกรักษาความปลอดภัยไม่มีประสบการณ์ในการตรวจสอบเฉพาะทางสำหรับ LLM ในระยะเริ่มต้น การพึ่งพาเฟรมเวิร์ก LLM Red Teaming จากภายนอกหรือผลลัพธ์จากเครื่องมือวินิจฉัยอัตโนมัติในสัดส่วนที่สูงขึ้นถือเป็นแนวทางที่สมเหตุสมผล และค่อยขยายขอบเขตการตัดสินใจโดยมนุษย์เมื่อมีการสั่งสมองค์ความรู้ภายในองค์กรแล้ว

ในขั้นตอนการออกแบบโครงสร้างองค์กร แทนที่จะใช้ตาราง RACI แบบเดิมโดยตรง เราจะปรับเปลี่ยนแผนกที่รับผิดชอบ A (Accountability) เป็นการชั่วคราวตามผลการวินิจฉัย ในองค์กรที่แผนก AI/ML ยังมีการเปิดเผยข้อมูลไม่เพียงพอ เราจะเพิ่มการมีส่วนร่วมของแผนกอื่นนอกเหนือจากแผนกรักษาความปลอดภัยในส่วน C (Consulted) ของการวางแผนทดสอบ และดำเนินการในรูปแบบโครงสร้างชั่วคราวจนกว่ากระบวนการเปิดเผยข้อมูลจะพร้อม ผลลัพธ์จากการวินิจฉัยและการออกแบบนี้จะถูกนำไปใช้เป็นข้อมูลนำเข้าสำหรับการจัดสรรบุคลากรและโปรแกรมการฝึกอบรมในขั้นตอนต่อไป

การจัดสรรบุคลากรให้เริ่มจากการแบ่งบทบาทระหว่างผู้รับผิดชอบเต็มเวลาและผู้รับผิดชอบควบตำแหน่ง ตามส่วนที่ขาดแคลนซึ่งปรากฏชัดจากการวินิจฉัยสถานะปัจจุบัน โดยรูปแบบการจัดสรรที่เหมาะสมในทางปฏิบัติคือ การมอบหมายให้มีผู้รับผิดชอบเต็มเวลา 1-2 คนจากแผนกรักษาความปลอดภัยเพื่อดูแลความเสี่ยงเฉพาะของ LLM ส่วนแผนก AI/ML และแผนกธุรกิจให้เข้าร่วมในรอบการทดสอบรายไตรมาสโดยทำหน้าที่ควบคู่ไปกับงานประจำ เหตุผลที่จำกัดแผนกที่มีผู้รับผิดชอบเต็มเวลาไว้เพียงบางส่วน เนื่องจากความรู้ในหมวดหมู่ของ OWASP LLM Top 10 และวิธีการตรวจสอบการเจลเบรก (Jailbreak) เป็นทักษะที่ต้องอาศัยการสั่งสม หากให้ทำเพียงควบตำแหน่งจะทำให้องค์ความรู้ขาดช่วงได้

โปรแกรมการฝึกอบรมควรออกแบบโดยแยกการเรียนภาคทฤษฎีและการฝึกปฏิบัติออกจากกัน ในภาคทฤษฎีให้ใช้เนื้อหาจากหมวดหมู่ต่างๆ ของ OWASP LLM Top 10 และฟังก์ชันทั้ง 4 ของ NIST AI RMF ได้แก่ Govern, Map, Measure และ Manage มาเป็นสื่อการสอน โดยให้ผู้รับผิดชอบแต่ละคนเขียนระบุว่ากระบวนการทำงานของบริษัทตนเองนั้นสอดคล้องกับฟังก์ชันใดบ้าง ส่วนการฝึกปฏิบัติให้ใช้เครื่องมือวินิจฉัยอัตโนมัติ เช่น Promptfoo หรือ PyRIT เพื่อทดลองรันสถานการณ์การโจมตีจริงกับระบบที่เป็นเป้าหมายการทดสอบ เพื่อให้ผู้เรียนได้เรียนรู้วิธีอ่านผลการตรวจพบและวิธีแยกแยะผลบวกลวง (False Positive)

ตัวอย่างสถานการณ์สมมติที่ใช้เป็นเนื้อหาการฝึกอบรมได้ดี คือการให้ผู้รับผิดชอบจากแผนก AI/ML ทดลองรันสถานการณ์การโจมตีแบบ Indirect Injection กับระบบสอบถามข้อมูลภายในที่ใช้ RAG เพื่อตรวจสอบว่าการแทรกคำสั่งผ่านแหล่งข้อมูลภายนอกนั้นสามารถผ่านการตรวจสอบความถูกต้องของข้อมูล (Grounding Check) ไปได้มากน้อยเพียงใด หลังจบการฝึกปฏิบัติควรบันทึกรายการที่ผู้รับผิดชอบแต่ละคนตรวจพบและรายการที่มองข้ามไป เพื่อนำมาปรับเนื้อหาการฝึกอบรมในครั้งถัดไปให้เหมาะสมกับรายบุคคล ซึ่งจะช่วยลดความเหลื่อมล้ำของระดับความชำนาญได้

ในการสร้างมาตรฐานกระบวนการทดสอบ เป้าหมายคือการทำเป็นเทมเพลตเพื่อให้การตัดสินใจของบุคลากรที่ได้รับการพัฒนาผ่านการจัดสรรทรัพยากรบุคคลและโปรแกรมการฝึกอบรมมีความสม่ำเสมอ ไม่แตกต่างกันไปตามตัวบุคคล โดยเป้าหมายของการสร้างมาตรฐานมี 3 ประการ ได้แก่ รูปแบบของแผนการทดสอบ (Test Plan), การจัดหมวดหมู่สถานการณ์การโจมตี (Attack Scenario) และรายการบันทึกผลการตรวจพบ หากไม่จัดทำเอกสารเหล่านี้และพึ่งพาเพียงการสื่อสารด้วยวาจา เมื่อมีการโยกย้ายพนักงาน ความรู้ความชำนาญจะไม่ถูกส่งต่อ และรอบการทำงานรายไตรมาสจะขึ้นอยู่กับระยะเวลาการทำงานของพนักงานแต่ละคน

ในรูปแบบของแผนการทดสอบ ให้รวมรายการหมวดหมู่ของ OWASP LLM Top 10 ไว้ในรูปแบบเช็คลิสต์ และจัดทำช่องสำหรับระบุหมวดหมู่ที่จะรวมอยู่ในการทดสอบครั้งนี้และหมวดหมู่ที่จะยกเว้นไว้อย่างชัดเจน การบันทึกเหตุผลในการยกเว้นจะช่วยให้การพิจารณาทบทวนขอบเขตการทดสอบในครั้งถัดไปทำได้ง่ายขึ้น สำหรับรายการบันทึกผลการตรวจพบ ให้กำหนดโครงสร้างขั้นต่ำ 5 รายการ ได้แก่ รูปแบบการโจมตี, ความสำเร็จหรือไม่สำเร็จ, ระดับความรุนแรง, แผนกที่รับผิดชอบ และวันที่คาดว่าจะทำการทดสอบซ้ำ โดยกำหนดรายการเหล่านี้ไว้ในเทมเพลตของสเปรดชีตหรือระบบจัดการตั๋ว (Ticket Management System)

ในกรณีที่ AI Agent ดำเนินการกับระบบภายนอก เช่น กรณีสิทธิ์ของเอเจนต์ที่มากเกินไป (Excessive Agent Permissions) จำเป็นต้องเพิ่มช่องสำหรับบันทึกผลกระทบข้างเคียงจากการดำเนินการ ซึ่งแตกต่างจากการตรวจสอบ Prompt เพียงอย่างเดียว สำหรับการจัดหมวดหมู่สถานการณ์การโจมตี ให้แยกหมวดหมู่รายการที่มีขั้นตอนการตรวจสอบต่างกัน เช่น Direct Injection และ Indirect Injection ออกจากกัน แทนที่จะรวมไว้ในช่องเดียวกัน เพื่อป้องกันไม่ให้พนักงานสับสนในการใช้คู่มือขั้นตอนการทำงาน

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

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

ในการวางแผนการทดสอบ จุดเปลี่ยนสำคัญในทางปฏิบัติคือการกำหนดขอบเขตโดยแบ่งตาม "หน่วยฟังก์ชัน" (Function unit) แทนที่จะเป็น "หน่วยระบบ" (System unit) เนื่องจากแม้จะเป็นแอปพลิเคชัน LLM เดียวกัน แต่ส่วนการสร้างคำตอบของแชทบอตสำหรับลูกค้าและส่วนการค้นหา RAG สำหรับการสอบถามภายในองค์กรนั้น มีเส้นทางการโจมตีและขั้นตอนการตรวจสอบที่แตกต่างกัน เมื่อแบ่งขอบเขตตามหน่วยฟังก์ชันแล้ว ให้กำหนดหมวดหมู่ของ OWASP LLM Top 10 ให้กับแต่ละฟังก์ชัน และแยกรายการที่สามารถตรวจสอบได้ด้วยการป้อนข้อมูลเพียงครั้งเดียว เช่น Direct Injection ออกจากรายการที่ต้องใช้การตรวจสอบหลายขั้นตอนผ่านแหล่งข้อมูลภายนอก เช่น Indirect Injection หรือ RAG Poisoning เพื่อนำไปใส่ในตารางเวลา

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

การประเมินระยะเวลาดำเนินการควรคำนวณแยกกันโดยสะท้อนถึงการแบ่งตามหน่วยฟังก์ชันและความแตกต่างของขั้นตอนการตรวจสอบ หากประเมินหมวดหมู่ที่ตรวจสอบเพียงครั้งเดียวกับหมวดหมู่ที่ต้องใช้การตรวจสอบหลายขั้นตอนด้วยจำนวนชั่วโมงการทำงานที่เท่ากัน จะทำให้การตรวจสอบ Indirect Injection ล่าช้าในระหว่างการดำเนินงาน และกลายเป็นสาเหตุที่ทำให้ตารางเวลาโดยรวมของแผนงานพังลง ช่องรายการที่ยกเว้นและช่องระยะเวลาในแผนงานจะต้องได้รับการตรวจสอบขั้นสุดท้ายโดยฝ่ายความปลอดภัยซึ่งรับผิดชอบในโครงสร้างทีม Red Team เพื่อตรวจสอบความสอดคล้องกับข้อมูลทางเทคนิคที่ได้รับจากฝ่าย AI/ML ก่อนที่จะสรุปผล

การดำเนินการทดสอบควรแยกการทำงานระหว่างการสแกนเบื้องต้นด้วยเครื่องมือวินิจฉัยอัตโนมัติ และการตรวจสอบเชิงลึกโดยการตัดสินใจของมนุษย์ เพื่อไม่ให้งานซ้ำซ้อนกัน เครื่องมือวินิจฉัยอัตโนมัติอย่าง Promptfoo หรือ PyRIT สามารถส่งรูปแบบการโจมตีแบบ Jailbreak ที่รู้จักกันดีหรือการโจมตีแบบ Prompt Injection ที่เป็นรูปแบบมาตรฐานได้ในคราวเดียว ดังนั้นจึงควรเริ่มจากการรันการสแกนอัตโนมัติกับฟังก์ชันเป้าหมายทั้งหมดก่อน แล้วจึงจัดลำดับความสำคัญให้หมวดหมู่ที่ตรวจพบจำนวนมากเข้าสู่กระบวนการตรวจสอบโดยมนุษย์ เนื่องจากผลลัพธ์ของการสแกนอัตโนมัติอาจมีการตรวจจับที่ผิดพลาด (False Positive) ผู้รับผิดชอบจึงต้องทำหน้าที่ตรวจสอบซ้ำทีละรายการว่า "มีการส่งผลลัพธ์ที่ไม่ถูกต้องออกมาจริงหรือไม่" และคัดแยกรายการที่ตรวจจับผิดพลาดออกไป

ในการตรวจสอบโดยมนุษย์ จะเน้นไปที่สถานการณ์ที่การสแกนอัตโนมัติครอบคลุมได้ยาก เช่น การโจมตีผ่านแหล่งข้อมูลภายนอกอย่าง Indirect Injection หรือการทำ Jailbreak ที่หลบเลี่ยง Guardrails ผ่านการสนทนาหลายรอบ สำหรับฟังก์ชันที่ใช้ RAG จะต้องมีการทดสอบโดยการนำเอกสารทดสอบเข้าไปจริง เพื่อตรวจสอบว่าเอกสารที่ไม่ถูกต้องที่ปนเข้าไปใน Vector Database จะสามารถผ่านการตรวจสอบ Grounding Check ได้มากน้อยเพียงใด

ช่องโหว่ที่ตรวจพบควรบันทึกลงในเทมเพลต 5 หัวข้อที่กำหนดไว้ตอนวางแผนทดสอบ (รูปแบบการโจมตี, ความสำเร็จ/ล้มเหลว, ระดับความรุนแรง, แผนกที่รับผิดชอบ, วันที่กำหนดทดสอบซ้ำ) ทันที และควรหลีกเลี่ยงการรวบยอดไปบันทึกหลังจากตรวจสอบเสร็จสิ้นทั้งหมด หากปล่อยให้การบันทึกเป็นงานที่ทำภายหลัง จะทำให้เกิดการบันทึกรูปแบบเดียวกันซ้ำซ้อนหรือเกิดการตกหล่นได้ง่ายเมื่อมีผู้รับผิดชอบหลายคนตรวจสอบพร้อมกัน การกำหนดให้บันทึกข้อมูลให้เสร็จสิ้นทุกครั้งที่ตรวจสอบฟังก์ชันหนึ่งจบลง ก่อนที่จะย้ายไปตรวจสอบฟังก์ชันถัดไป ถือเป็นหัวใจสำคัญในทางปฏิบัติเพื่อป้องกันความผิดพลาดในการรวบรวมข้อมูลในขั้นตอนการรายงาน

แม้จะเข้าใจทฤษฎีการสร้างโครงสร้างองค์กรแล้ว แต่หลายครั้งก็ยังติดขัดในการตัดสินใจเชิงปฏิบัติ เช่น จำนวนบุคลากร ความแตกต่างของระดับความกระตือรือร้นระหว่างแผนก หรือความเหมาะสมของความถี่ในการทดสอบ ต่อไปนี้คือคำตอบสำหรับข้อสงสัยที่พบบ่อยในการให้คำปรึกษาเฉพาะราย

สำหรับองค์กรขนาดเล็ก ให้ละทิ้งสมมติฐานที่ว่าต้องมีผู้รับผิดชอบเฉพาะทางในหลายแผนก โดยให้เริ่มจาก RACI ฉบับย่อที่ให้เจ้าหน้าที่ความปลอดภัย 1 คนรับผิดชอบทั้งการวางแผนและการประเมินผล ส่วนแผนก AI/ML ให้ผู้พัฒนาทำหน้าที่เพียงการปรับปรุงและนำไปใช้งานจริงควบคู่ไปด้วย สำหรับการอนุมัติจากฝ่ายธุรกิจนั้น สามารถให้ผู้บริหารระดับสูงเพียง 1 คนรับหน้าที่ควบไปได้ ทั้งนี้ ให้เพิ่มสัดส่วนการพึ่งพาผลลัพธ์จากเครื่องมือตรวจสอบอัตโนมัติ และจำกัดการตรวจสอบโดยมนุษย์ไว้เฉพาะรายการที่ทำเป็นอัตโนมัติได้ยาก เช่น การโจมตีแบบ Indirect Injection หรือการทำ Jailbreak แบบหลายขั้นตอน (Multi-turn) การแบ่งบทบาทหน้าที่ตามลำดับเมื่อมีจำนวนบุคลากรเพิ่มขึ้น เป็นแนวทางที่ช่วยให้โครงสร้างองค์กรมีความมั่นคงและไม่พังทลายได้ง่าย

สาเหตุเกิดจากการเปิดเผยข้อมูลไม่เพียงพอ หรือความบกพร่องในการออกแบบกระบวนการหารือ หากแผนก AI/ML ไม่สามารถเปิดเผย System Prompt หรือโครงสร้าง RAG ได้ ให้ถือว่าเป็นส่วนที่ขาดการวินิจฉัยสถานะปัจจุบัน แต่หากมีการเปิดเผยข้อมูลเพียงพอแล้วแต่การประชุมยังคงหยุดชะงัก ให้ตรวจสอบว่ามีแผนกที่ไม่เกี่ยวข้องเข้ามาอยู่ในส่วน C (Consulted) ของ RACI หรือไม่ และมีการขอความเห็นชอบในเนื้อหาที่ควรจะเป็นเพียงการรายงานผลหรือไม่

รอบการทดสอบพื้นฐานควรอยู่ที่ทุกไตรมาส แต่ในบางกรณีควรปรับความถี่ให้เร็วขึ้นตามเงื่อนไขที่กำหนด ดังนี้:

• กรณีมีการเปลี่ยนแปลง System Prompt หรือกฎของ Guardrails: ให้ทำการทดสอบซ้ำทันทีเฉพาะในส่วนที่การเปลี่ยนแปลงส่งผลกระทบต่อหมวดหมู่นั้นๆ
• กรณีมีการทำ Fine-tuning หรืออัปเดตโมเดล: ให้ดำเนินการทดสอบซ้ำกับทุกหมวดหมู่โดยไม่ต้องรอรอบไตรมาส
• กรณีมีการเปลี่ยนแปลงแหล่งข้อมูล (Data Source) หรือ Embedding Model ของ RAG: ให้จัดลำดับความสำคัญในการตรวจสอบซ้ำในหัวข้อ RAG Poisoning และ Grounding Check เป็นอันดับแรก
• กรณีมีการปล่อยการแก้ไขช่องโหว่ที่ตรวจพบ: ให้ทดสอบซ้ำทันทีเฉพาะรูปแบบที่เกี่ยวข้อง และตรวจสอบภาพรวมอีกครั้งในรอบไตรมาส

แม้ในช่วงที่ไม่มีการเปลี่ยนแปลงใดๆ ก็ควรดำเนินการทดสอบตามรอบไตรมาสอย่างต่อเนื่อง เนื่องจากวิธีการโจมตีและเทคนิค Jailbreak ที่ถูกเผยแพร่ออกมามีการอัปเดตอยู่เสมอ แม้โมเดลหรือ Prompt จะไม่เปลี่ยน แต่ความสามารถในการต้านทานต่อรูปแบบใหม่ๆ ก็อาจเปลี่ยนแปลงไปได้ หากต้องการแบ่งความถี่ในการทดสอบตามระดับความสำคัญของฟังก์ชัน การแบ่งโดยใช้รอบที่สั้นกว่าไตรมาสสำหรับฟังก์ชันที่มีผู้ใช้งานจำนวนมาก เช่น แชทบอทสำหรับลูกค้า และคงรอบไตรมาสไว้สำหรับฟังก์ชันภายในองค์กรที่มีการใช้งานต่ำ เป็นแนวทางที่เหมาะสมในทางปฏิบัติ