เกณฑ์การตัดสินใจสร้าง AI Red Team: เปรียบเทียบและคู่มือการเลือกใช้บริการระหว่างทีมภายใน vs ภายนอก

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

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

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

ในการออกแบบโครงสร้าง จำเป็นต้องอาศัยการทำงานร่วมกันจากหลากหลายสาขาวิชาชีพ การผสมผสานระหว่างวิศวกร Machine Learning, นักวิจัยด้านความปลอดภัยเชิงรุก (Offensive Security), ผู้เชี่ยวชาญเฉพาะทางในธุรกิจนั้นๆ และผู้รับผิดชอบด้านจริยธรรมและธรรมาภิบาล จะช่วยให้สามารถตรวจสอบได้ไม่เพียงแค่ช่องโหว่ทางเทคนิคเท่านั้น แต่ยังรวมถึงความเสี่ยงที่ฝังรากลึกอยู่ในบริบททางธุรกิจด้วย ตัวอย่างเช่น หากเป็นระบบ AI ในด้านการแพทย์ นอกเหนือจากการตรวจสอบวิธีการโจมตีทางเทคนิคอย่าง "Prompt Injection" แล้ว จำเป็นต้องมีผู้รับผิดชอบที่มีความรู้ทางคลินิกมาประเมินความเสี่ยงในการสร้างข้อมูลทางการแพทย์ที่ผิดพลาดควบคู่กันไปด้วย

AI Red Team ของ Microsoft ก่อตั้งขึ้นในปี 2018 และได้ประเมินผลิตภัณฑ์ Generative AI หลายรายการภายใต้โครงสร้างที่ดำเนินการอย่างต่อเนื่อง จุดเด่นของบทบาทภายในองค์กรคือการไม่ใช้วิธีการตรวจสอบแบบครั้งเดียวจบ แต่เป็นการจัดตั้งทีมเฉพาะทางไว้ภายในองค์กรอย่างถาวร เพื่อให้สามารถประเมินผลได้อย่างต่อเนื่องตามการเปลี่ยนแปลงของระบบและการเพิ่มฟีเจอร์ใหม่ๆ

บริการ Red Team แบบเอาท์ซอร์สมีหลายรูปแบบ ซึ่งสามารถเลือกใช้ได้ตามวัตถุประสงค์และความถี่ในการตรวจสอบ

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

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

องค์กรที่ต้องการหมุนเวียนวงจรการประเมินอย่างต่อเนื่องในระบบจำนวนมากและต้องการสั่งสมองค์ความรู้ไว้ภายในบริษัท การทำแบบ In-house (ทำเองภายใน) จะมีความได้เปรียบ ในขณะที่องค์กรที่ต้องการนำความเชี่ยวชาญเฉพาะทางมาใช้ในระยะเวลาอันสั้น หรือไม่สามารถจัดสรรบุคลากรประจำให้รับผิดชอบงานนี้ได้ การจ้างภายนอก (Outsource) จะมีความได้เปรียบกว่า ความแตกต่างของทั้งสองรูปแบบสามารถสรุปได้เป็น 6 ประเด็นหลัก ได้แก่ ต้นทุนการติดตั้งเริ่มต้น, ความรวดเร็วในการสร้างความเชี่ยวชาญ, การจัดการข้อมูลที่เป็นความลับ, การสั่งสมองค์ความรู้ภายในองค์กร, ความเป็นอิสระในการประเมิน และต้นทุนการดำเนินงานต่อเนื่อง

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

ต้นทุนการสร้างระบบภายในองค์กร (In-house) สามารถแบ่งออกเป็น 3 ส่วน ได้แก่ การจ้างงาน การฝึกอบรม และการจัดเตรียมเครื่องมือ บุคลากรที่มีประสบการณ์ทั้งด้านความปลอดภัยเชิงรุก (Offensive Security) และ ML นั้นมีจำกัดในตลาดแรงงาน อีกทั้งหลังจากจ้างงานแล้วยังต้องใช้เวลาในการฝึกอบรมเพื่อให้เข้าใจโครงสร้างระบบของบริษัทอีกด้วย ในกรณีที่นำเครื่องมือประเมินผลอย่างเช่น 「PyRIT」 มาใช้งาน ต้นทุนเริ่มต้นจะรวมถึงงานปรับแต่งการตั้งค่าเพื่อให้สามารถนำไปประยุกต์ใช้กับโมเดลหรือระบบ AI ของบริษัทได้

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

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

ในการประเมินต้นทุนเริ่มต้น จำเป็นต้องคำนวณค่าใช้จ่ายในการจ้างงาน ค่าแรงระหว่างช่วงฝึกอบรม และค่าใช้จ่ายในการนำเครื่องมือมาใช้แยกกัน และเปรียบเทียบกับขอบเขตการตรวจสอบที่เท่ากันกับใบเสนอราคาของการจ้างภายนอก หากนำใบเสนอราคาที่มีขอบเขตต่างกันมาเปรียบเทียบกัน อาจทำให้ตัดสินใจผิดพลาดได้ว่าแบบใดถูกกว่ากัน เนื่องจากค่าใช้จ่ายในการจ้างภายนอกจะแตกต่างกันไปตามระดับการเข้าถึง (Black box, Gray box, White box) ข้อควรระวังในทางปฏิบัติคือต้องกำหนดเงื่อนไขให้ตรงกันจนถึงระดับความลึกของการทดสอบเมื่อขอใบเสนอราคา

ความท้าทายที่ใหญ่ที่สุดในการสรรหาบุคลากรสำหรับทีม Red Team ภายในองค์กรคือ การที่บุคลากรที่มีประสบการณ์ทั้งด้านความปลอดภัยเชิงรุก (Offensive Security) และ ML ในตลาดนั้นมีจำกัด หากจ้างบุคลากรที่มีประสบการณ์เพียงด้านเดียว จะเกิดช่องว่างขึ้น เช่น หากออกแบบ Input ที่เป็นปฏิปักษ์ (Adversarial Input) ได้ แต่ไม่สามารถวิเคราะห์พฤติกรรมภายในของโมเดลได้ หรือหากวิเคราะห์โมเดลได้ แต่ไม่สามารถสร้างสถานการณ์การโจมตีที่ใช้งานได้จริง AI Red Team ของ Microsoft ใช้เวลาหลายปีนับตั้งแต่ก่อตั้งในปี 2018 ในการพัฒนาทีมงานเฉพาะทาง ซึ่งต้องใช้ระยะเวลาพอสมควรในการสั่งสมประสบการณ์ทั้งด้าน ML และความปลอดภัยภายในองค์กร

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

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

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

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

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

การตัดสินว่าการพัฒนาภายใน (In-house) เหมาะสมหรือไม่นั้น ขึ้นอยู่กับการผสมผสานของ 2 ปัจจัย ได้แก่ ความถี่ในการทดสอบและจำนวนระบบที่เกี่ยวข้อง รวมถึงความสามารถในการรักษาทีมงานที่มีความหลากหลายทางวิชาชีพไว้ภายในบริษัท หากเงื่อนไขเพียงข้อใดข้อหนึ่งได้รับการตอบสนอง แต่โครงสร้างองค์กรไม่สามารถรองรับภาระในการดำเนินงานอย่างต่อเนื่องได้ การพัฒนาภายในก็จะไม่สามารถทำงานได้อย่างมีประสิทธิภาพ

ความถี่ในการตรวจสอบและจำนวนของระบบที่เป็นเป้าหมาย คือปัจจัยที่ชัดเจนที่สุดในการตัดสินใจเลือกระหว่างการทำภายในองค์กร (In-house) หรือการจ้างภายนอก (Outsource) ยิ่งระบบ AI มีความสำคัญสูงมากเท่าใด ก็ยิ่งจำเป็นต้องมีการตรวจสอบที่ถี่มากขึ้นเท่านั้น โดยแนะนำให้มีการดำเนินงานที่นอกเหนือจากการประเมินประจำปีแล้ว ยังต้องมีการประเมินเพิ่มเติมหลังจากมีการเปลี่ยนแปลงที่สำคัญของระบบอีกด้วย หากพยายามตอบโจทย์ความถี่นี้ด้วยการจ้างภายนอก จะเกิดการเจรจาสัญญาและการกำหนดขอบเขตงานใหม่ทุกครั้งที่มีการเปลี่ยนแปลง ซึ่งในระบบที่มีวงจรการปล่อยอัปเดต (Release cycle) ที่รวดเร็ว มักจะทำให้การตรวจสอบล่าช้าตามไม่ทัน

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

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

ความเชี่ยวชาญของบุคลากรและความพร้อมของโครงสร้างองค์กรเป็นเงื่อนไขที่ต้องพิจารณาแยกต่างหาก นอกเหนือไปจากการตอบโจทย์เรื่องความถี่ในการตรวจสอบและจำนวนระบบที่รองรับ เพื่อที่จะตัดสินใจเลือกการดำเนินการภายในองค์กร (In-house) หากพยายามตอบโจทย์เพียงแค่เรื่องความถี่โดยที่ยังไม่มีทีมงานที่มีทักษะหลากหลายครบถ้วน แม้จะสามารถตรวจสอบเทคนิคด้านความปลอดภัยเชิงรุก (Offensive Security) ได้ แต่ก็อาจไม่สามารถวิเคราะห์พฤติกรรมภายในโมเดลได้ หรือเป็นการประเมินที่ขาดความรู้เฉพาะทางในโดเมนนั้นๆ ส่งผลให้ไม่สามารถรับประกันความครอบคลุมของการตรวจสอบได้

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

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

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

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

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

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

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

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

นอกจากนี้ ยังมีรูปแบบการให้บริการที่ผู้ให้บริการคลาวด์นำเสนอความเชี่ยวชาญเฉพาะทางเป็นบริการสนับสนุนสำหรับลูกค้า เช่น "Mandiant AI security consulting" ที่ให้บริการโดย Google Cloud ซึ่งการสนับสนุนจากภายนอกในลักษณะนี้ถือเป็นทางเลือกในการทดแทนบทบาทที่ขาดหายไปภายในองค์กร เมื่อใช้บริการเหล่านี้ สิ่งสำคัญคือต้องจัดทำเอกสารรูปแบบของข้อค้นพบที่ได้รับหลังจากการตรวจสอบ รวมถึงเกณฑ์การตัดสินใจในการจัดลำดับความสำคัญของการแก้ไข (remediation triage) เพื่อให้สามารถรับมอบงานและนำมาใช้ต่อภายในองค์กรได้ การรวมกลไกการถ่ายทอดองค์ความรู้เพื่อเตรียมพร้อมสำหรับการเปลี่ยนผ่านไปสู่การดำเนินการภายในองค์กรในอนาคตไว้ในเงื่อนไขสัญญา ไม่ใช่เพียงแค่การจ้างงานภายนอกในช่วงที่ไม่สามารถจัดหาบุคลากรได้เท่านั้น แต่ถือเป็นจุดตัดสินสำคัญในการออกแบบโครงสร้างองค์กรในระยะยาว

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

MITRE สนับสนุนรูปแบบการทำงานร่วมกันที่ผสมผสานการรักษาองค์ความรู้ภายในเข้ากับวิธีการโจมตีที่หลากหลายจากภายนอกและการประเมินโดยอิสระ ซึ่งการปฏิบัติงานแบบ "Purple Teaming" ที่ทีมภายใน (Blue) และทีมโจมตีภายนอก (Red) แลกเปลี่ยนข้อมูลและทำการตรวจสอบพร้อมแก้ไขซ้ำๆ ถือเป็นตัวอย่างของรูปแบบนี้ ในการดำเนินการดังกล่าว จำเป็นต้องกำหนดขอบเขตให้ชัดเจนล่วงหน้าว่าการตรวจสอบส่วนใดที่ทีมภายในจะรับผิดชอบ และส่วนใดที่จะส่งต่อให้ภายนอก หากใช้งานร่วมกันโดยที่ขอบเขตยังคลุมเครือ อาจเกิดกรณีที่ทั้งสองฝ่ายตรวจสอบในขอบเขตเดียวกันซ้ำซ้อน หรือในทางกลับกัน อาจเกิดช่องว่างในความรับผิดชอบได้

เกณฑ์ในการตัดสินใจคือ ทีมภายในสามารถจัดการแก้ไขและคัดกรอง (Triage) ผลการตรวจสอบที่เคยพบในอดีตได้ด้วยตนเองจนเสร็จสิ้นหรือไม่ หากสามารถจัดการผลการตรวจสอบในชีวิตประจำวันได้เอง แต่ยังขาดประสบการณ์ในการตรวจสอบรูปแบบการโจมตีที่ไม่รู้จักซึ่งใกล้เคียงกับ Zero-day รูปแบบไฮบริดที่มอบหมายเฉพาะส่วนนั้นให้ภายนอกจะเป็นสิ่งที่ตอบโจทย์ความเป็นจริงขององค์กรมากที่สุด

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

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

ไม่ว่าจะเลือกรูปแบบการดำเนินงานแบบภายใน (In-house) แบบจ้างภายนอก (Outsource) หรือแบบผสม (Hybrid) ขั้นตอนการนำไปใช้งานจะมีรูปแบบที่เหมือนกัน ดังนี้:

1. การกำหนดขอบเขต (Scope Definition): จัดทำเอกสารระบุขอบเขตของระบบ AI ที่จะทำการตรวจสอบและสถานการณ์จำลองการโจมตี
2. การกำหนดระดับการเข้าถึงและกฎการรักษาความลับ (Access Level and Confidentiality Rules): ระบุให้ชัดเจนว่าจะตรวจสอบในรูปแบบ Black box, Gray box หรือ White box รวมถึงระบุการจัดการข้อมูลที่เป็นความลับไว้ในสัญญาหรือระเบียบปฏิบัติภายในบริษัท
3. การออกแบบการทดสอบ (Test Design): สร้างการจับคู่ระหว่างกรณีทดสอบ (Test Case) และวิธีการโจมตี โดยอ้างอิงจากการจัดหมวดหมู่ของ OWASP LLM Top-10 หรือ NIST AI RMF
4. การดำเนินการ (Execution): ดำเนินการตรวจสอบภายใต้ข้อจำกัดด้านความปลอดภัย และกำหนดขอบเขตผลกระทบต่อระบบงานจริงไว้ล่วงหน้า
5. การรายงานและการแก้ไข (Reporting and Remediation): จัดลำดับความสำคัญของสิ่งที่ตรวจพบและดำเนินการคัดแยกเพื่อแก้ไข (Triage)
6. การประเมินซ้ำ (Re-evaluation): ทำการตรวจสอบซ้ำด้วยกรณีทดสอบเดิมหลังจากแก้ไขแล้ว และผนวกเข้ากับระบบการติดตามผลอย่างต่อเนื่อง

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

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

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

สามารถเปลี่ยนผ่านได้ แต่มีเงื่อนไขว่าต้องมีการถ่ายทอดความรู้ (Knowledge Transfer) ก่อนการเปลี่ยนผ่าน คุณควรจัดทำเอกสารบันทึก Playbook, Test Case และความสามารถในการตรวจสอบย้อนกลับ (Traceability) ของผลการตรวจสอบในอดีต รวมถึงกำหนดสิทธิ์การเข้าถึงใหม่ เพื่อรักษาความต่อเนื่องในการตรวจสอบ หากละเลยการจัดทำเอกสาร รูปแบบของช่องโหว่ที่เคยพบในอดีตจะไม่ถูกส่งต่อ ทำให้ต้องเสียเวลาในการตรวจสอบเพื่อค้นหาผลลัพธ์เดิมซ้ำอีกครั้ง