การตรวจประเมิน AI: การประเมิน AI Agent ต่อเนื่องและอนุมัติซ้ำ

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

ข้อสรุปก่อน: หน่วยตรวจประเมินต้องเป็นชุดกำหนดค่าของงาน

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

หน่วยประเมินที่แนะนำคือ:

สถานการณ์ธุรกิจ × เครื่องมือ × สิทธิ์ × ข้อมูล × รุ่นของโมเดล/พรอมต์

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

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

ทำไม AI Agent ที่ผ่านการทดสอบรับมอบแล้วต้องประเมินอีก

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

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

NIST AI RMF Core วางแนวคิดให้บริหารความเสี่ยงต่อเนื่องตลอดวงจรชีวิต และให้ทดสอบระบบ AI ก่อนนำไปใช้รวมถึงประเมินเป็นระยะขณะทำงาน Measure 2.4 กล่าวถึงการเฝ้าระวังการทำงานและพฤติกรรมของระบบกับองค์ประกอบในระบบจริง ส่วน NIST Playbook ระบุว่าการเปลี่ยนสภาพแวดล้อม การเปลี่ยนรูปแบบข้อมูล และการเปลี่ยนพฤติกรรมโมเดลเป็นเหตุให้ต้องทบทวนว่าตัวชี้วัดและมาตรการควบคุมเดิมยังเหมาะสมหรือไม่

ดังนั้นอย่าใช้เพียงปฏิทินที่รันชุดทดสอบเดิมซ้ำ ควรใช้ทั้งการทบทวนตามรอบและการประเมินเมื่อมีเหตุ อย่างน้อยให้เริ่มวิเคราะห์ผลกระทบเมื่อเกิด:

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

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

สร้างทะเบียนชุดกำหนดค่าที่ทำซ้ำได้

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

สถานการณ์ธุรกิจ

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

เครื่องมือ

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

สิทธิ์

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

ข้อมูล

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

รุ่นของโมเดลและพรอมต์

รวมรหัสโมเดล วิธีให้บริการ ค่าตั้ง พรอมต์ระบบ คำอธิบายเครื่องมือ การเลือกเส้นทาง นโยบายความจำ การตรวจผลลัพธ์ และรุ่นนโยบายไว้ในเอกสารกำหนดค่าชุดเดียว หลีกเลี่ยงชื่อแปรผันอย่าง “รุ่นล่าสุด” เพราะต้องเทียบสิ่งที่ทดสอบกับสิ่งที่เปิดใช้จริงได้

กำหนดขอบเขตทดสอบใหม่จากความต่างจริง

การทดสอบทั้งหมดใหม่ทุกครั้งทำให้งานช้า แต่การไม่ทดสอบเลยทำให้มองข้ามความเสี่ยง ใช้การเปลี่ยนแปลงเป็นข้อมูลตั้งต้นดังนี้:

1. ระบุองค์ประกอบที่เปลี่ยนทั้งหมด
2. ย้อนหาสถานการณ์ธุรกิจ เครื่องมือ สิทธิ์ และข้อมูลที่พึ่งพาองค์ประกอบนั้น
3. ระบุรูปแบบความล้มเหลวและมาตรการควบคุมที่เกี่ยวข้อง
4. เลือกการทดสอบถดถอย การทดสอบเชิงรุก การยืนยันทางธุรกิจ และการตรวจหลักฐานที่ต้องทำ
5. จัดแนวผู้ประเมินและผู้อนุมัติซ้ำตามความเสี่ยง
6. กำหนดเงื่อนไขเฝ้าระวังหลังเปิดใช้และเงื่อนไขย้อนกลับ

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

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

ออกแบบการประเมิน AI อย่างเป็นอิสระด้วย 3 แนว

NIST AI RMF Measure 1.3 เสนอให้ผู้เชี่ยวชาญภายในที่ไม่ได้เป็นผู้พัฒนาแนวหน้า และ/หรือผู้ประเมินอิสระ เข้าร่วมการประเมินเป็นระยะ หลักการออกแบบของ NIST Dioptra กล่าวถึงการทดสอบโดยผู้พัฒนา การทดสอบในช่วงจัดหาหรือในห้องประเมิน และการทดสอบโดยบุคคลที่สามเพื่อการตรวจประเมินหรือการกำกับดูแล พร้อมเน้นการทำซ้ำและการสืบย้อน บทความนี้แปลงแนวคิดดังกล่าวเป็น 3 แนวสำหรับองค์กร ซึ่งเป็นข้อเสนอเชิงปฏิบัติของ TOMAS TECH ไม่ใช่โครงสร้างที่ NIST บังคับ

แนวที่ 1: ผู้พัฒนาและทีมปฏิบัติการประเมินตนเอง

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

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

แนวที่ 2: ฝ่ายธุรกิจ ความเสี่ยง และคุณภาพทักท้วงสมมติฐาน

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

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

แนวที่ 3: การประเมินโดยบุคคลภายนอก

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

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

จัดสรรความเป็นอิสระตามความเสี่ยง

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

เลิกใช้ “ความแม่นยำค่าเดียว” แล้วประเมิน 6 มิติ

1. อัตราความสำเร็จทางธุรกิจ

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

2. อัตราการกระทำเกินสิทธิ์

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

3. อัตราข้อผิดพลาดร้ายแรง

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

4. การหยุดและกู้คืน

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

OpenAI ประกาศ Agents API เมื่อ 10 กันยายน 2026 ในฐานะรุ่นทดสอบสาธารณะ (public beta) จึงต้องถือว่าสถานะความพร้อมยังเป็นข้อจำกัด ไม่ใช่มาตรฐานการตรวจประเมินที่สุกงอม หน้าประกาศแสดงตัวอย่างจากลูกค้า ซึ่งเป็นกรณีการตลาด ไม่ใช่เกณฑ์กลางหรือการรับประกันประสิทธิภาพ ประเด็นที่ใช้ได้คือ Agent อาจทำงานยาวร่วมกับบริบท เครื่องมือ และ Agent ย่อย ดังนั้นหน่วยประเมินต้องรวมสภาพแวดล้อมและเครื่องมือด้วย อ่านชั้นการทำงานได้ในคู่มือการดำเนินงาน Agents API

5. ความครบถ้วนของหลักฐาน

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

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

6. การทดสอบถดถอยหลังเปลี่ยน

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

บทความนี้ไม่กำหนดเกณฑ์สากล องค์กรต้องอนุมัติเกณฑ์ก่อนทดสอบตามผลกระทบ ความเสี่ยงที่ยอมรับ สัญญา กฎหมาย และมาตรการควบคุม

ผนวกการทดสอบเชิงรุกเข้ากับการประเมินต่อเนื่อง

การทดสอบเชิงรุกหรือ red teaming ไม่ควรเป็นงานครั้งเดียวก่อนเปิดใช้ ต้องปรับสมมติฐานภัยเมื่อความสามารถ จุดเชื่อมต่อ หรือภัยเปลี่ยน การทดสอบถดถอยถามว่าข้อกำหนดเดิมยังทำงานหรือไม่ ส่วนการทดสอบเชิงรุกมองหาเส้นทางที่คาดไม่ถึงเพื่อข้ามขอบเขต

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

ทิศทาง AI 2026 ของ ETDA ที่เผยแพร่ 9 มิถุนายน 2026 เน้น AI Governance Testing และ Red Teaming Challenge ครั้งแรกของไทย ETDA ระบุว่าแนวทาง/ชุดเครื่องมือด้านธรรมาภิบาล AI พร้อมใช้งาน 12 ชุด และกำลังพัฒนาอีก 2 ชุดในปี 2026 ได้แก่ AI Ethical Impact Assessment Playbook และ AI Value Creation ข้อมูลนี้สะท้อนทิศทางระบบนิเวศในไทย ไม่ใช่หน้าที่ทางกฎหมายทั่วไปของทุกบริษัท และบทความนี้เสนอให้องค์กรต่อยอดจากการทดสอบก่อนใช้ไปสู่การประเมินหลังเปิดใช้

สร้างหลักฐานระหว่างทำงาน ไม่ใช่รวบรวมก่อนตรวจ

เอกสารหลักฐานแต่ละชุดควรมี:

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

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

เชื่อมผลกับ GO / CONDITIONAL GO / HOLD / STOP

GO

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

CONDITIONAL GO

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

HOLD

หลักฐานขาด ทำซ้ำไม่ได้ ยังมีข้อบกพร่องสำคัญ ไม่ผ่านเกณฑ์ หรือการทบทวนอิสระยังไม่ครบ ให้หยุดเผยแพร่และระบุสิ่งที่ต้องแก้กับการทดสอบที่ต้องทำใหม่

STOP

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

สิ่งที่ RFP การตรวจประเมิน AI ควรกำหนด

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

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

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

ด้านผล ให้รายงาน 6 มิติแยกกัน ห้ามคะแนนรวมชดเชยความล้มเหลวร้ายแรง และกำหนดสิทธิ์ตัดสิน GO, CONDITIONAL GO, HOLD, STOP สิ่งส่งมอบควรมีเอกสารกำหนดค่า บัญชีกรณี บันทึกทดสอบ หลักฐานความล้มเหลว ขั้นตอนทำซ้ำ ข้อค้นพบ ระดับความร้ายแรง การแก้ และผลทดสอบซ้ำ ไม่ใช่เพียงสไลด์ผู้บริหาร

หากขอตารางเทียบ ISO/IEC 42001, NIST AI RMF หรือกฎหมาย ให้ผู้ประเมินระบุเอกสารต้นฉบับและขอบเขตที่ตรวจจริง หน้าอธิบายทางการของ ISO ระบุ ISO/IEC 42001 เป็นระบบการจัดการตามวงจร Plan-Do-Check-Act เพื่อปรับปรุงต่อเนื่อง และกล่าวถึงการสืบย้อน ความโปร่งใส การประเมินความเสี่ยง และแนวทางตรวจ บทความนี้ไม่ได้ตรวจเนื้อหามาตรฐานฉบับจำหน่าย จึงไม่สร้างเลขข้อ อ่านภาพรวม AIMS ได้ในคู่มือ ISO 42001

การอ่าน EU AI Act Article 72 จากประเทศไทย

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

นี่คือตัวอย่างกฎหมายสำหรับการติดตามตลอดวงจรชีวิต ไม่ได้หมายความว่า Article 72 ใช้บังคับโดยตรงกับบริษัทไทยทุกแห่งหรือ AI Agent ทุกระบบ ต้องตรวจตลาด EU บทบาทขององค์กร การจัดเป็นระบบความเสี่ยงสูง และห่วงโซ่ผลิตภัณฑ์/บริการ พร้อมขอคำแนะนำกฎหมายเมื่อจำเป็น แม้ไม่อยู่ในขอบเขต แนวคิดเรื่องการติดตามตลอดอายุ เอกสาร และการตรวจความสอดคล้องต่อเนื่องก็ใช้เป็นข้อมูลอ้างอิงภายในได้

ขั้นตอนจากคำขอเปลี่ยนถึงการอนุมัติซ้ำ

1. ลงทะเบียนการเปลี่ยน พร้อมผลต่อสถานการณ์ ความสามารถ ข้อมูล สิทธิ์ ผู้ใช้ และเขตอำนาจ
2. เทียบเอกสารกำหนดค่าที่อนุมัติกับชุดใหม่ ครบโมเดล พรอมต์ เครื่องมือ สิทธิ์ ข้อมูล และวิธีประเมิน
3. จัดระดับผลกระทบและแนวผู้ประเมิน โดยดูการตรวจพบ การกู้คืน และมาตรการควบคุม
4. ตรึงกรณี ข้อมูลเข้า ผลที่คาด เกณฑ์ ระดับความร้ายแรง และสภาพแวดล้อมก่อนทดสอบ
5. แยกการทดสอบถดถอย กรณีจากเหตุเดิม และการทดสอบเชิงรุก
6. รายงาน 6 มิติและข้อยกเว้นสำคัญแยกจากค่าเฉลี่ย
7. แยกผู้อนุมัติจากผู้ทดสอบ แล้วบันทึกรุ่น วันหมดอายุ การเฝ้าระวัง และการย้อนกลับ
8. นำความล้มเหลว การแทรกแซงโดยคน ความพยายามเกินสิทธิ์ และเสียงผู้ใช้กลับเข้าทะเบียนความเสี่ยง

ความผิดพลาดที่พบบ่อย

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

รายการตรวจใช้งานจริง

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

FAQ: การตรวจประเมิน AI และการประเมิน AI Agent ต่อเนื่อง

ควรตรวจประเมิน AI บ่อยเพียงใด?

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

การประเมินต่อเนื่องต่างจากการทดสอบรับมอบอย่างไร?

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

ต้องใช้บุคคลที่สามทุกครั้งหรือไม่?

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

การทดสอบเชิงรุกเพียงอย่างเดียวถือว่าตรวจเสร็จหรือไม่?

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

ความแม่นยำดีขึ้นแล้วอนุมัติซ้ำได้เลยหรือไม่?

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

RFP การตรวจประเมิน AI ควรชี้แจงอะไรก่อน?

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

มี ISO/IEC 42001 แล้ว ยังต้องประเมินระบบต่อเนื่องหรือไม่?

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

สรุป: เชื่อมการตรวจประเมิน AI เข้ากับการควบคุมการเปลี่ยนและสิทธิ์เผยแพร่

แม้ AI Agent ผ่านการรับมอบแล้ว เป้าหมายตรวจยังเปลี่ยนเมื่อโมเดล พรอมต์ เครื่องมือ สิทธิ์ หรือข้อมูลเปลี่ยน ให้ตรึงหน่วยประเมินเป็นสถานการณ์ธุรกิจ × เครื่องมือ × สิทธิ์ × ข้อมูล × รุ่นโมเดล/พรอมต์ แล้วเลือกการทดสอบจากความต่างจริง จัดแนวผู้พัฒนา ธุรกิจ/ความเสี่ยง และผู้ประเมินภายนอกตามผลกระทบ ประเมินความสำเร็จทางธุรกิจ การเกินสิทธิ์ ข้อผิดพลาดร้ายแรง การหยุด/กู้คืน ความครบถ้วนหลักฐาน และการทดสอบถดถอยแยกกัน เชื่อมผลกับ GO, CONDITIONAL GO, HOLD หรือ STOP พร้อมบันทึกรุ่น วันหมดอายุ การเฝ้าระวัง และการย้อนกลับ จึงจะเปลี่ยนรายงานตรวจให้เป็นมาตรการควบคุมจริง

TOMAS TECH สามารถช่วยวางการตรวจประเมิน AI และการประเมินต่อเนื่อง ตั้งแต่ RFP ทะเบียนชุดกำหนดค่า เหตุที่ต้องประเมิน กรณีทดสอบ ชุดหลักฐาน จนถึงการอนุมัติซ้ำ เริ่มได้ตั้งแต่ช่วงที่องค์กรกำลังเชื่อมการรับมอบหรือ ISO 42001 เดิมเข้ากับการควบคุมหลังเปิดใช้

แหล่งอ้างอิง

• Anthropic, “Partnering with Accenture on embedded evaluation” (18 กันยายน 2026): https://www.anthropic.com/news/accenture-embedded-evaluation
• NIST, AI Risk Management Framework Core — Measure: https://airc.nist.gov/airmf-resources/airmf/5-sec-core/
• NIST, AI RMF Playbook — Measure: https://airc.nist.gov/airmf-resources/playbook/measure/
• NIST, Dioptra Design Principles: https://pages.nist.gov/dioptra/explanation/dioptra-motivation/design-principles.html
• ISO, AI management systems: What businesses need to know: https://www.iso.org/artificial-intelligence/ai-management-systems
• European Union, AI Act consolidated text, Article 72 (27 กรกฎาคม 2026): https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX%3A02024R1689-20260727
• ETDA, AI 2026 — Driving Trust AI Governance (9 มิถุนายน 2026): https://www.etda.or.th/th/pr-news/aigc_Driving-Trust_AI_Governance.aspx
• OpenAI, “Introducing the Agents API” (10 กันยายน 2026): https://openai.com/index/introducing-the-agents-api/

บทความนี้เป็นแนวทางปฏิบัติทั่วไปจากข้อมูลสาธารณะที่ตรวจสอบถึงวันที่ 19 กันยายน 2026 ไม่ใช่คำแนะนำกฎหมาย การรับรอง หรือการรับประกันผล