Guardrails สำหรับ AI agent ที่ลงมือทำงานจริง

ให้สิทธิ์น้อยที่สุดเท่าที่งานต้องการ

หลักข้อแรกคือ least privilege agent ที่ตอบคำถามเรื่องสถานะออเดอร์ควรอ่านข้อมูลออเดอร์ได้ แต่ไม่ควรมีสิทธิ์ลบหรือคืนเงิน ให้สร้างบัญชีหรือ API key เฉพาะสำหรับ agent แทนการใช้บัญชีของพนักงานคนใดคนหนึ่ง เพื่อจำกัดขอบเขตและตรวจสอบย้อนหลังได้ง่าย

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

ใส่ขั้นอนุมัติตรงจุดที่เสี่ยง

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

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

• ผ่านอัตโนมัติ: อ่านข้อมูล ร่างข้อความ สรุป
• ต้องอนุมัติ: ส่งข้อความออกภายนอก แก้ข้อมูลลูกค้า ทำรายการเกี่ยวกับเงิน
• ห้ามทำเลย: ลบข้อมูลถาวร เปลี่ยนสิทธิ์ผู้ใช้

เก็บ log ให้ย้อนดูได้ทุกก้าว

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

ระวังอย่าเก็บข้อมูลส่วนบุคคลใน log เกินความจำเป็น ให้ปิดบังข้อมูลอ่อนไหว กำหนดระยะเวลาเก็บ และจำกัดว่าใครเปิดดู log ได้ ตามหลัก PDPA

ทำให้การกระทำย้อนกลับได้

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

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

ถ้ากดผิดแล้วย้อนไม่ได้ ให้ถามก่อนทำ ถ้าย้อนได้ ค่อยทำแล้วแจ้งทีหลัง

ทดสอบใน sandbox ก่อนแตะของจริง

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

ชุดสถานการณ์เหล่านี้ควรรันซ้ำทุกครั้งที่เปลี่ยน prompt เครื่องมือ หรือโมเดล เช่นเดียวกับการทำ regression test ในซอฟต์แวร์ทั่วไป

เฝ้าดูหลังเปิดใช้ และเตรียมปุ่มหยุดฉุกเฉิน

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

เตรียมสวิตช์หยุด agent ได้ทันทีโดยไม่ต้อง deploy ใหม่ และฝึกซ้อมว่าใครมีหน้าที่กดและแจ้งใคร เมื่อเกิดเหตุจะได้ไม่ต้องหาวิธีตอนที่กำลังวุ่น