การกำกับดูแล AI Agent คือความพยายามในการควบคุมพฤติกรรมของ AI Agent ที่วางแผนและดำเนินการตามภารกิจโดยอัตโนมัติ ผ่านกลไกการจัดการสิทธิ์ การกำหนดขอบเขตความปลอดภัย (Guardrails) และการตรวจสอบ เพื่อให้เป็นไปตามระบบขององค์กร ต่างจาก AI รูปแบบแชททั่วไป ตรงที่ AI Agent สามารถเข้าถึงและจัดการระบบหรือข้อมูลภายนอกได้โดยตรง ดังนั้นการทำงานที่ผิดพลาดอาจส่งผลโดยตรงต่อการทำลายข้อมูลทางธุรกิจหรือก่อให้เกิดความล้มเหลวต่อเนื่องได้ ในบทความนี้ เราจะอธิบายกรอบการทำงานเชิงปฏิบัติเพื่อลดความเสี่ยงจากการทำงานอัตโนมัติเป็นลำดับขั้น สำหรับแผนกสารสนเทศและผู้รับผิดชอบด้านการส่งเสริม AI ที่ดูแลการนำ AI Agent มาใช้งาน โดยครอบคลุมตั้งแต่การกำหนดขอบเขตของสิทธิ์ การออกแบบ Guardrails บันทึกการตรวจสอบ ไปจนถึงการขยายขีดความสามารถสู่สภาพแวดล้อมแบบ Multi-agent เมื่ออ่านจบ คุณจะมีความพร้อมในการตัดสินใจว่า "ควรจัดเตรียมสิ่งใดและตามลำดับอย่างไร" สำหรับแผนการนำ AI Agent มาใช้ในองค์กรของคุณ

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

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

ความเสี่ยงที่เป็นตัวแทนหลักสามารถแบ่งออกได้เป็น 4 ประเภทดังนี้:

• การเบี่ยงเบนจากเจตนา (Intent Deviation): การตีความคำสั่งที่คลุมเครือเกินความจำเป็น ตัวอย่างเช่น คำสั่งที่ว่า "ช่วยจัดการข้อมูลเก่าให้หน่อย" อาจถูกตีความและดำเนินการเป็นการลบข้อมูลแทนที่จะเป็นการจัดเก็บเข้าคลัง (Archive)
• การใช้อำนาจเกินขอบเขต (Excessive Agency): Agent ที่ถือสิทธิ์เกินความจำเป็นสำหรับงานนั้นๆ อาจเข้าไปแก้ไขทรัพยากรที่ไม่ควรแตะต้อง ซึ่งในรายการความเสี่ยงด้านความปลอดภัยสำหรับแอปพลิเคชัน LLM ของ OWASP ก็ได้ระบุเรื่องนี้ไว้เป็นหัวข้อแยกต่างหากในชื่อ "Excessive Agency"
• การถูกยึดครองผ่าน Prompt Injection: การที่ Agent ถูกสั่งให้ดำเนินการตามเจตนาของผู้โจมตี ผ่านคำสั่งที่แฝงอยู่ในเนื้อหาภายนอกที่ Agent อ่าน (เช่น อีเมล, หน้าเว็บ, เอกสาร)
• ความล้มเหลวแบบลูกโซ่ (Cascading Failures): การดำเนินการที่ผิดพลาดเพียงครั้งเดียวไปกระตุ้นกระบวนการอัตโนมัติในขั้นตอนถัดไป ทำให้ความเสียหายขยายวงกว้าง เช่น การอัปเดตข้อมูลสต็อกสินค้าที่ผิดพลาด ส่งผลกระทบต่อเนื่องไปถึงระบบการสั่งซื้อและการออกใบแจ้งหนี้อัตโนมัติ

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

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

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

ในด้านกฎระเบียบ ข้อกำหนดสำหรับ AI ที่ทำงานอย่างอิสระ (Autonomous AI) มีความเข้มงวดขึ้นอย่างชัดเจน

EU AI Act ได้นำแนวทางแบบอิงตามความเสี่ยง (Risk-based approach) มาใช้ โดยกำหนดให้ระบบ AI ที่ถูกจัดอยู่ในกลุ่มความเสี่ยงสูงต้องมีการบันทึก Log, การกำกับดูแลโดยมนุษย์ (Human oversight) และการจัดตั้งระบบบริหารจัดการความเสี่ยง หาก AI Agent เข้าไปมีส่วนเกี่ยวข้องกับการประเมินผลงานพนักงาน การตัดสินใจด้านสินเชื่อ หรือการควบคุมโครงสร้างพื้นฐานที่สำคัญ ก็อาจเข้าข่ายต้องปฏิบัติตามข้อกำหนดเหล่านี้เช่นกัน ในส่วนของ AI Risk Management Framework (AI RMF) จาก NIST ของสหรัฐอเมริกาก็ได้กำหนดให้ Govern (การกำกับดูแล) เป็นฟังก์ชันหลัก และเรียกร้องให้มีระบบการจัดการเชิงองค์กรต่อการกระทำของ AI สำหรับในญี่ปุ่น แนวทางปฏิบัติสำหรับผู้ประกอบการ AI ของรัฐบาลก็ได้ระบุให้การรับรองความปลอดภัยของ AI และการกำกับดูแลโดยมนุษย์เป็นหลักการพื้นฐาน

นอกเหนือจากการปฏิบัติตามกฎระเบียบแล้ว สิ่งที่มักถูกมองข้ามคือ การเชื่อมโยงกับระบบการควบคุมภายใน (Internal Control) หาก AI Agent เข้าไปจัดการข้อมูลทางบัญชีหรือบันทึกการทำธุรกรรม การกระทำเหล่านั้นย่อมตกเป็นเป้าหมายของการตรวจสอบภายใต้ระบบ IT Control ที่มีอยู่เดิม (เช่น การจัดการสิทธิ์เข้าถึง, การจัดการการเปลี่ยนแปลง, และการแบ่งแยกหน้าที่) ข้ออ้างที่ว่า "เป็น AI จึงเป็นข้อยกเว้น" นั้นใช้ไม่ได้ และในทางกลับกัน เนื่องจากเป็นการทำงานแบบอัตโนมัติ จึงยิ่งจำเป็นต้องมีหลักฐานการควบคุมที่เข้มงวดกว่าเดิม หากออกแบบระบบธรรมาภิบาล (Governance) ไว้ทีหลัง อาจมีความเสี่ยงที่การนำระบบมาใช้งานจริงจะต้องหยุดชะงักในขั้นตอนการตรวจสอบได้

ก่อนที่จะเริ่มติดตั้ง Guardrail สิ่งที่เป็นจุดเริ่มต้นคือการกำหนดให้ชัดเจนเป็นลายลักษณ์อักษรว่า "จะมอบหมายงานอะไรและมากน้อยแค่ไหนให้กับ Agent" สิ่งที่ต้องตัดสินใจในขั้นตอนการเตรียมการมี 3 ประการ ได้แก่ ขอบเขตอำนาจ (Authority Scope), การประเมินความเสี่ยง (Risk Assessment) และขั้นตอนการอนุมัติ (Approval Flow) หากเริ่มดำเนินการติดตั้งโดยที่ส่วนนี้ยังคลุมเครือ กระบวนการในขั้นตอนถัดไปทั้งหมดจะกลายเป็นการแก้ปัญหาเฉพาะหน้าไปเรื่อยๆ

สิ่งที่ควรทำเป็นอันดับแรกคือการสำรวจการดำเนินการทั้งหมดที่เอเจนต์ (Agent) จะต้องทำและจำกัดสิทธิ์ให้เหลือน้อยที่สุด หลักการพื้นฐานคือ หลักการให้สิทธิ์น้อยที่สุด (Principle of Least Privilege) ซึ่งเป็นหลักการคลาสสิกด้านความปลอดภัย โดยสรุปคือ "การให้สิทธิ์เพียงเท่าที่จำเป็นต่อการปฏิบัติงานเท่านั้น"

การดำเนินการสามารถจัดระเบียบได้ง่ายโดยแบ่งออกเป็น 4 ระดับ ดังนี้:

1. การอ่าน (Read): ดูข้อมูลได้เพียงอย่างเดียว ผลกระทบจำกัดอยู่แค่ความเสี่ยงในการรั่วไหลของข้อมูล
2. การเขียน/อัปเดต (Write/Update): การแก้ไขข้อมูลที่มีอยู่ หากเกิดความผิดพลาดจะต้องมีขั้นตอนการกู้คืนข้อมูล
3. การลบ (Delete): ในหลายกรณีไม่สามารถย้อนกลับได้ โดยหลักการแล้วไม่ควรให้สิทธิ์นี้แก่เอเจนต์
4. การส่งข้อมูลออกภายนอก (External Transmission): เช่น การส่งอีเมล การเรียกใช้ API ภายนอก หรือการชำระเงิน เนื่องจากส่งผลกระทบต่อภายนอกองค์กร จึงต้องจัดการด้วยความระมัดระวังสูงสุด

จากนั้นให้กำหนด ขอบเขตการทำงาน (Execution Boundaries) โดยระบุเป็นลายลักษณ์อักษรให้ชัดเจน ได้แก่ "รายการระบบที่อนุญาตให้เข้าถึงได้" "ขอบเขตของข้อมูลที่อนุญาตให้จัดการได้ (ตาราง, โฟลเดอร์, กลุ่มลูกค้า)" และ "ขีดจำกัดจำนวนครั้งหรือมูลค่าต่อครั้ง/ต่อวัน"

ในด้านการนำไปใช้งาน สิ่งสำคัญคือต้องออก Service Account แยกสำหรับเอเจนต์โดยเฉพาะ และห้ามใช้ ID ของมนุษย์ร่วมกัน เอเจนต์ที่ทำงานด้วยข้อมูลยืนยันตัวตนเดียวกับมนุษย์จะไม่สามารถแยกแยะออกจากกิจกรรมของมนุษย์ได้ในบันทึก (Log) ซึ่งจะทำให้การตรวจสอบ (Audit) และการสืบสวนเหตุการณ์ผิดปกติ (Incident Investigation) ไม่สามารถทำได้

การใช้มาตรการควบคุมเดียวกันกับทุกการปฏิบัติงานจะทำให้การดำเนินงานล้มเหลว เครื่องมือสำหรับประเมินความเสี่ยงและปรับเปลี่ยนระดับความเข้มงวดของมาตรการควบคุมสำหรับแต่ละการปฏิบัติงานคือ Risk Assessment Matrix (เมทริกซ์การประเมินความเสี่ยง) โดยแนะนำให้ใช้แกนประเมิน 2 แกน ได้แก่ "ระดับผลกระทบ" (Impact) และ "ความสามารถในการย้อนกลับ" (Reversibility)

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

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

การกำกับดูแล Agent ไม่สามารถทำได้โดยแผนกไอทีเพียงฝ่ายเดียว อย่างน้อยที่สุดต้องมีการจัดสรรบทบาทของผู้ที่เกี่ยวข้องดังต่อไปนี้:

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

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

ขั้นตอนการอนุมัติจะนำไปปฏิบัติได้ง่ายกว่าหากรวมเข้ากับกระบวนการจัดการการเปลี่ยนแปลงด้านไอที (IT Change Management) ที่มีอยู่เดิม แทนที่จะสร้างขึ้นใหม่ โดยให้กำหนดเหตุการณ์ที่ต้องมีการจัดการการเปลี่ยนแปลง 3 ประการ ได้แก่ "การนำ Agent ใหม่มาใช้", "การเปลี่ยนแปลงขอบเขตสิทธิ์" และ "การเปลี่ยนแปลงการตั้งค่าระบบป้องกัน" แล้วดำเนินการผ่านวงจรการขออนุมัติ การอนุมัติ และการบันทึกข้อมูลเช่นเดียวกับการเปลี่ยนแปลงระบบทั่วไป

การวางแนวป้องกัน (Guardrails) โดยพื้นฐานแล้วควรแบ่งเป็น 3 ชั้น ได้แก่ "การป้อนข้อมูล (Input)", "การประมวลผล (Execution)" และ "การแสดงผล (Output)" การป้องกันเพียงชั้นเดียวจะถูกเจาะผ่านด้วยเส้นทางที่ไม่คาดคิดได้ในที่สุด บทความนี้จะอธิบายถึงรูปแบบการนำไปใช้งานในแต่ละชั้น และแนวคิดในการแบ่งระดับความเข้มงวดของการควบคุม

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

ในขั้นตอนการดำเนินการ การตรวจสอบอาร์กิวเมนต์ของการเรียกใช้เครื่องมือ (Tool Call) ถือเป็นหัวใจสำคัญ โดยห้ามนำอาร์กิวเมนต์ API ที่ LLM สร้างขึ้นไปใช้งานทันที แต่ต้องผ่านการตรวจสอบสคีมา (ประเภทข้อมูล ช่วงข้อมูล และรูปแบบ) และการตรวจสอบกับรายการที่อนุญาต (Allowlist) การจำกัดรูปแบบให้เป็นเพียง "การเติมพารามิเตอร์ลงในคิวรีที่กำหนดไว้ล่วงหน้า" แทนที่จะเป็น "การสร้างและเรียกใช้ SQL อย่างอิสระ" จะช่วยลดความเสี่ยงลงได้อย่างมาก

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

การ์ดเรล (Guardrails) แบ่งออกเป็น Hard Limit ที่ไม่สามารถละเมิดได้ และ Soft Limit ที่โดยหลักการแล้วต้องปฏิบัติตามแต่สามารถถูกละเมิดได้ หากไม่ตระหนักถึงความแตกต่างนี้ จะนำไปสู่ความเชื่อที่อันตรายว่า "ปลอดภัยแล้วเพราะเขียนคำสั่งห้ามไว้ใน Prompt"

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

ในทางกลับกัน Soft Limit เหมาะสำหรับการควบคุม "พฤติกรรมที่พึงประสงค์" เช่น รูปแบบการเขียน ลำดับความสำคัญ หรือเกณฑ์การตัดสินใจ การใช้ Hard Limit กับทุกอย่างจะทำให้ต้นทุนในการปรับเปลี่ยนสูงขึ้น ดังนั้นทางออกที่เป็นจริงคือการผสมผสานทั้งสองอย่างเข้าด้วยกันตามระดับความเสี่ยงในตารางประเมินความเสี่ยง (Risk Assessment Matrix)

Human-in-the-loop (HITL) คือการนำไปใช้งานที่สอดคล้องกับช่อง "การอนุมัติล่วงหน้า" (Pre-approval) ในเมทริกซ์การประเมินความเสี่ยง จุดสำคัญของการออกแบบอยู่ที่ว่าจะวางการอนุมัติไว้ที่ไหนและมากน้อยเพียงใด

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

ประเด็นสำคัญในการออกแบบเพื่อป้องกันไม่ให้การอนุมัติกลายเป็นเพียงพิธีกรรมมี 3 ข้อดังนี้:

1. จำกัดขอบเขตสิ่งที่ต้องอนุมัติ: จำกัดเฉพาะการดำเนินการที่ไม่สามารถย้อนกลับได้หรือมีผลกระทบสูงเท่านั้น ส่วนที่เหลือให้ใช้วิธีการตรวจสอบย้อนหลัง (Post-review)
2. รวบรวมข้อมูลที่จำเป็นสำหรับการอนุมัติไว้ในหน้าเดียว: นำเสนอข้อมูลว่ากำลังจะทำอะไร ทำไม และทำกับข้อมูลชุดไหน ในรูปแบบที่สามารถตัดสินใจได้ทันทีโดยไม่ต้องไปสืบค้นเพิ่ม
3. กำหนดให้การหมดเวลา (Timeout) เป็นการปฏิเสธโดยค่าเริ่มต้น: หลีกเลี่ยงการออกแบบที่ "ดำเนินการอัตโนมัติ" หากปล่อยคำขออนุมัติทิ้งไว้โดยเด็ดขาด ตามหลักการ Fail-safe หากไม่มีการตอบสนอง ให้เลือกฝั่งที่หยุดการทำงานไว้ก่อน

นอกจากนี้ การกำหนดเส้นทางการยกระดับ (Escalation path) ว่าควรส่งต่อให้ใครในกรณีที่ผู้อนุมัติไม่อยู่หรือตัดสินใจไม่ได้ จะช่วยให้การดำเนินงานไม่หยุดชะงัก

ความสามารถในการย้อนกลับมาตรวจสอบได้ว่า "เอเจนต์ตัวไหน ทำอะไร โดยมีพื้นฐานมาจากอะไร" คือเกณฑ์มาตรฐานของบันทึกการตรวจสอบ (Audit Log) ทั้งการสอบสวนเหตุการณ์ การตอบสนองต่อการตรวจสอบ และการปรับปรุงระบบป้องกัน (Guardrails) ล้วนขึ้นอยู่กับคุณภาพของบันทึกข้อมูลทั้งสิ้น โดยต้องมีการออกแบบใน 3 ประเด็นหลัก ได้แก่ รายการที่ต้องบันทึก, การตรวจจับความผิดปกติ และการจัดเก็บข้อมูล

บันทึกการตรวจสอบ (Audit Log) ของเอเจนต์นั้นแตกต่างจากบันทึกของแอปพลิเคชันทั่วไป ตรงที่จำเป็นต้องบันทึกไปจนถึง "กระบวนการตัดสินใจ" โดยควรมีเหตุการณ์ขั้นต่ำดังต่อไปนี้:

• การรับคำสั่ง: ใครเป็นผู้ให้คำสั่ง และคำสั่ง (Prompt) คืออะไร
• การสร้างแผน: เอเจนต์วางแผนขั้นตอนการทำงานไว้อย่างไร
• การเรียกใช้เครื่องมือ: API ที่เรียกใช้, อาร์กิวเมนต์ และทรัพยากรเป้าหมาย
• ผลลัพธ์การดำเนินการ: ความสำเร็จ/ความล้มเหลว, ค่าก่อนและหลังการเปลี่ยนแปลง (ส่วนต่าง)
• การอนุมัติ/ปฏิเสธ: การตัดสินใจของมนุษย์ในกระบวนการ HITL (Human-in-the-loop) และผู้ที่ทำการตัดสินใจ
• การทำงานของ Guardrail: ข้อเท็จจริงและเหตุผลที่ระบบบล็อกหรือตัวกรองทำงาน

รายการที่จำเป็นสำหรับแต่ละบันทึก ได้แก่ การประทับเวลา (Timestamp), Agent ID, Session ID (ตัวระบุที่เชื่อมโยงงานทั้งชุดเข้าด้วยกัน), ทรัพยากรเป้าหมาย และประเภทของการดำเนินการ หากไม่มี Session ID จะไม่สามารถติดตามได้ว่า "การลบนี้เป็นส่วนหนึ่งของห่วงโซ่ที่เริ่มจากคำสั่งใด" ซึ่งจะทำให้การตรวจสอบหาสาเหตุหยุดชะงัก

ข้อควรระวังคือ หากมีการบันทึกข้อมูลนำเข้าและส่งออกของ LLM ทั้งหมด ข้อมูลส่วนบุคคลหรือข้อมูลลับอาจปะปนอยู่ในบันทึกได้ หากไม่มีการออกแบบกระบวนการปกปิดข้อมูล (Masking) ในตัวบันทึกควบคู่ไปกับการควบคุมการเข้าถึง (Access Control) ที่จะกล่าวถึงในภายหลัง ตัวฐานข้อมูลบันทึกเองอาจกลายเป็นจุดเสี่ยงใหม่ที่ทำให้ข้อมูลรั่วไหลได้

การเก็บล็อกเพียงอย่างเดียวไม่มีความหมาย การจะทำหน้าที่เป็น "การ์ดเรล" (Guardrail) ได้นั้น ต้องสามารถตรวจจับความผิดปกติได้แบบเรียลไทม์เสียก่อน พื้นฐานของการตรวจจับคือ การเบี่ยงเบนจากค่าพื้นฐาน (Baseline)

ตัวชี้วัดที่มีประสิทธิภาพสำหรับการเฝ้าระวังมีดังนี้:

• จำนวนการเรียกใช้เครื่องมือต่อหน่วยเวลาที่เพิ่มขึ้นอย่างรวดเร็ว (สัญญาณของการทำงานผิดปกติหรือการวนลูป)
• อัตราความล้มเหลวหรืออัตราการลองใหม่ (Retry rate) ของการดำเนินการที่สูงขึ้น (สัญญาณของการเปลี่ยนแปลงสภาพแวดล้อมหรือการโจมตี)
• การเข้าถึงทรัพยากรที่ไม่เคยเข้าถึงมาก่อนเป็นครั้งแรก
• การทำงานนอกช่วงเวลาปกติ

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

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

ความสามารถในการป้องกันการแก้ไข (Tamper resistance) ของบันทึกข้อมูลถือเป็นข้อกำหนดสำคัญในการตรวจสอบ (Audit) หากโครงสร้างของระบบยอมให้ตัว Agent เองหรือผู้ดูแลระบบสามารถแก้ไขบันทึกข้อมูลได้ บันทึกนั้นจะไม่สามารถใช้เป็นหลักฐานที่น่าเชื่อถือได้ จึงควรนำกลไกที่สามารถตรวจจับการแก้ไขข้อมูลมาใช้ เช่น การใช้พื้นที่จัดเก็บแบบเขียนเพิ่มได้อย่างเดียว (Write-once storage) หรือการตรวจสอบความถูกต้องของข้อมูล (Integrity verification) ผ่านการลงลายมือชื่อดิจิทัล (Digital signature) หรือ Hash chain

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

เมื่อเอเจนต์หลายตัวทำงานร่วมกัน ความเสี่ยงจะไม่ได้เพิ่มขึ้นแบบบวก แต่จะเพิ่มขึ้นแบบทวีคูณ นอกเหนือจากระบบป้องกัน (Guardrails) สำหรับเอเจนต์เดี่ยวแล้ว จำเป็นต้องมีการควบคุม "ระหว่าง" เอเจนต์ด้วย โดยมี Trust Model และ Rollback เป็นเสาหลักในการออกแบบ

หลักการของสภาพแวดล้อมแบบมัลติเอเจนต์ (Multi-agent environment) ก็เหมือนกับระบบของมนุษย์ นั่นคือ Zero Trust โดยจะไม่มีการตั้งสมมติฐานว่า "เชื่อถือได้เพราะเป็นเอเจนต์ภายในบริษัทเหมือนกัน"

โดยเฉพาะอย่างยิ่ง จะต้องมีการนำหลักการ 3 ประการต่อไปนี้ไปใช้งาน:

1. การตรวจสอบสิทธิ์ซึ่งกันและกัน (Mutual Authentication): แม้จะเป็นการสื่อสารระหว่างเอเจนต์ ก็ต้องมีการตรวจสอบสิทธิ์ของผู้เรียกใช้งานเพื่อป้องกันการปลอมแปลง
2. การจำกัดสิทธิ์ร่วม (Intersection of Permissions): เมื่อเอเจนต์ A ร้องขอให้เอเจนต์ B ทำงาน สิทธิ์ที่ B สามารถใช้ได้จะถูกจำกัดไว้ที่ "ส่วนร่วมของสิทธิ์ของ A และสิทธิ์ของ B" เท่านั้น หากออกแบบให้สิทธิ์ขยายตัวผ่านการร้องขอ (Privilege Escalation) จะทำให้เมื่อเอเจนต์ที่อ่อนแอที่สุดถูกบุกรุก สิทธิ์ทั้งหมดจะถูกเปิดเผยทันที
3. การตรวจสอบผลลัพธ์ซ้ำ (Re-validation of Output): เอเจนต์หนึ่งจะไม่นำผลลัพธ์ของอีกเอเจนต์หนึ่งไปดำเนินการตามคำสั่งโดยไม่มีการตรวจสอบก่อน

ประเด็นที่ 3 มักถูกมองข้ามได้ง่ายที่สุด ตัวอย่างเช่น เอเจนต์ A อ่านหน้าเว็บภายนอกแล้วนำเนื้อหานั้นไปร้องขอต่อเอเจนต์ B ในเส้นทางนี้ การฉีดคำสั่ง (Injection) ที่แฝงอยู่ในหน้าเว็บจะถูกส่งผ่าน A ไปยัง B นี่คือ การเชื่อมโยงของการฉีดคำสั่งผ่านพรอมต์ทางอ้อม (Indirect Prompt Injection Chain) ดังนั้น แม้จะเป็นขอบเขตระหว่างเอเจนต์ ก็ห้ามละเลยการทำความสะอาดข้อมูล (Sanitization) และการตรวจสอบอาร์กิวเมนต์ที่มาจากภายนอกโดยเด็ดขาด

ในการทำงานแบบต่อเนื่องโดยใช้เอเจนต์หลายตัว (Multi-agent) จำเป็นต้องมีการออกแบบวิธีรับมือกับสถานะที่ "สำเร็จเพียงบางส่วนและล้มเหลวในระหว่างทาง" ไว้ล่วงหน้า หากเป็นงานที่ทำด้วยมือ มนุษย์สามารถตรวจสอบสถานการณ์และย้อนกลับ (Rollback) ได้ แต่ในการทำงานแบบอัตโนมัติที่ต่อเนื่องกัน สถานะที่ค้างคาจะถูกปล่อยทิ้งไว้และสะสมจนกลายเป็นความไม่สอดคล้องของข้อมูล (Data Inconsistency)

รูปแบบการออกแบบ (Design Pattern) สามารถนำความรู้จากระบบแบบกระจาย (Distributed Systems) มาประยุกต์ใช้ได้ดังนี้:

• การประมวลผลชดเชย (Saga Pattern): กำหนด "การดำเนินการยกเลิก" คู่กับแต่ละขั้นตอน เมื่อเกิดความล้มเหลวให้ทำการยกเลิกขั้นตอนที่เสร็จสิ้นไปแล้วย้อนกลับตามลำดับ
• การทดสอบการทำงาน (Dry Run): ทดลองรันทุกขั้นตอนในโหมดจำลองก่อน เพื่อตรวจสอบความเป็นไปได้ก่อนที่จะดำเนินการจริง
• การดำเนินการแบบ Staging: สะสมการเปลี่ยนแปลงไว้ในพื้นที่ชั่วคราว และทำการอัปเดตพร้อมกันหลังจากยืนยันว่าทุกขั้นตอนสำเร็จแล้ว

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

ความล้มเหลวของธรรมาภิบาลมักไม่ได้เกิดจาก "การควบคุมที่หละหลวมเกินไป" แต่เกิดจาก "ความไม่สอดคล้องกันระหว่างการออกแบบและการปฏิบัติจริง" การทำความเข้าใจรูปแบบความล้มเหลวที่อยู่ตรงข้ามกัน 2 ประการ ได้แก่ การเป็นเพียงรูปแบบที่ไร้เนื้อหา (Formalism) และการควบคุมที่มากเกินไป (Over-control) จะช่วยให้คุณสามารถตรวจสอบได้ว่าการดำเนินงานของบริษัทตนเองกำลังเอนเอียงไปในทิศทางใด

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

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

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

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

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

ความน่ากลัวที่แท้จริงของการควบคุมที่มากเกินไปไม่ใช่การที่มูลค่าของ Agent หายไป แต่เป็นสิ่งที่ตามมาหลังจากนั้น เมื่อ Agent ที่เป็นทางการใช้งานไม่ได้จริง พนักงานในหน้างานจะเริ่มนำข้อมูลทางธุรกิจไปป้อนให้กับบริการ AI ภายนอกที่ไม่ได้รับอนุญาต "Agent เถื่อน" (Shadow Agents) ที่ทำงานอยู่นอกเหนือการมองเห็นของการควบคุม คือความเสี่ยงสูงสุดที่เกิดจากการควบคุมที่มากเกินไป และอันตรายกว่าการควบคุมที่หละหลวมเสียอีก

แนวทางในการสร้างสมดุลมี 2 ประการ ประการแรก คือการยึดมั่นตามตารางประเมินความเสี่ยง (Risk Assessment Matrix) โดยไม่นำการดำเนินการที่สามารถแก้ไขได้และมีผลกระทบต่ำมารวมไว้ในการอนุมัติล่วงหน้า ประการที่สอง คือการออกแบบให้มี การขยายสิทธิ์แบบค่อยเป็นค่อยไปตามผลงานที่เกิดขึ้นจริง ในช่วงเริ่มต้นของการนำมาใช้งาน ให้เริ่มจากสิทธิ์ที่จำกัดและการตรวจสอบที่ถี่ จากนั้นจึงขยายขอบเขตการทำงานอัตโนมัติโดยมีเงื่อนไขว่าต้องมีการทำงานที่เสถียรและการตรวจสอบบันทึกการใช้งาน (Log Review) ในระยะเวลาหนึ่ง การควบคุมไม่ควรถูกมองว่าเป็นค่าคงที่ แต่ควรเป็นพารามิเตอร์ที่ปรับเปลี่ยนได้ตามการสั่งสมของความเชื่อมั่น ซึ่งเป็นแนวทางที่เหมาะสมกว่า

Q1: สำหรับทีมขนาดเล็ก จำเป็นต้องมีระบบธรรมาภิบาล (Governance) ถึงระดับนี้หรือไม่?

ขนาดของระบบขึ้นอยู่กับอำนาจหน้าที่ของ Agent ไม่ใช่ขนาดขององค์กร หากเป็น Agent แบบอ่านได้อย่างเดียว (Read-only) การจัดทำเอกสารขอบเขตอำนาจหน้าที่และการเก็บ Log ก็เพียงพอที่จะเริ่มต้นได้ แต่ในทางกลับกัน หากต้องมอบหมายงานที่เกี่ยวข้องกับการเขียน ลบ หรือส่งข้อมูลออกภายนอก แม้จะเป็นทีมขนาดเล็ก ก็ไม่สามารถละเว้นการแบ่งแยกอำนาจหน้าที่ (Separation of Duties), การกำหนดขีดจำกัดสูงสุด (Hard limits) และขั้นตอนการอนุมัติ (Approval flow) ได้

Q2: มีความเกี่ยวข้องอย่างไรกับมาตรการรักษาความปลอดภัยที่มีอยู่เดิม (IAM, SIEM)?

ไม่ใช่การทดแทน แต่เป็นการขยายขอบเขต คุณสามารถลงทะเบียน Agent ในฐานะ Service Account เฉพาะใน IAM ที่มีอยู่เดิม และรวบรวม Audit log เข้าสู่ SIEM ที่ใช้งานอยู่ได้ ซึ่งจะช่วยให้คุณสามารถใช้กรอบการตรวจสอบและควบคุมที่มีอยู่เดิมได้ทันที โดยไม่จำเป็นต้องสร้างโครงสร้างพื้นฐานการจัดการสำหรับ Agent ขึ้นมาใหม่ตั้งแต่ต้น

Q3: ควรติดตั้ง Guardrails ไว้ที่ฝั่งโมเดลหรือฝั่งแอปพลิเคชัน?

การควบคุมที่ต้องการให้มีผลอย่างแน่นอนควรติดตั้งไว้ที่ชั้นแอปพลิเคชันและโครงสร้างพื้นฐาน (Application/Infrastructure layer) การสั่งการผ่าน System prompt เป็นเพียง Soft limit และควรตั้งสมมติฐานว่าอาจถูกทำลายได้ด้วย Prompt injection ดังนั้น การควบคุมผ่าน Prompt ควรจำกัดไว้เพียงการปรับ "พฤติกรรมที่พึงประสงค์" เช่น รูปแบบภาษาหรือเกณฑ์การตัดสินใจเท่านั้น

Q4: ควรเริ่มต้นจากตรงไหน?

ลำดับที่แนะนำคือ "การสำรวจอำนาจหน้าที่ (Inventory of permissions) → เมทริกซ์การประเมินความเสี่ยง (Risk assessment matrix) → การติดตั้ง Hard limits → Audit log → HITL (Human-in-the-loop)" การเริ่มต้นด้วย Agent ตัวแรกในงานที่จำกัดและขอบเขตอำนาจที่แคบ เพื่อสร้างรูปแบบธรรมาภิบาลระหว่างการใช้งานจริงแล้วค่อยขยายผลออกไป จะเป็นวิธีที่รวดเร็วที่สุด ทั้งนี้ บริษัทของเรามีบริการให้คำปรึกษาด้านการออกแบบธรรมาภิบาลเมื่อมีการนำ AI Agent มาใช้งาน หากการเตรียมความพร้อมด้วยตนเองเป็นเรื่องยาก การให้ผู้เชี่ยวชาญเข้ามาช่วยดูแลก็เป็นทางเลือกหนึ่งที่ควรพิจารณา