ผู้ช่วยที่อ่านสถานะคำสั่งซื้อได้ ไม่จำเป็นต้องแก้ที่อยู่จัดส่งได้ด้วย และผู้ช่วยที่ร่างอีเมลได้ก็ไม่จำเป็นต้องส่งออกไปหาลูกค้าได้ทันที ความสามารถเหล่านี้อาจอยู่ในเครื่องมือเดียวกัน แต่มีผลต่อธุรกิจและต้องใช้สิทธิ์ต่างกัน
ก่อนให้ AI Agent เชื่อมกับระบบบริษัท ควรกำหนดให้ชัดว่าอ่านอะไรได้ เสนออะไรได้ ทำรายการใดได้เอง และจุดไหนต้องให้คนอนุมัติ การเขียนกฎในคำสั่งของ AI เป็นเพียงส่วนหนึ่ง สิทธิ์ต้องถูกบังคับใช้ในระบบที่ถือข้อมูลและดำเนินรายการจริงด้วย
เริ่มจากแยก “ช่วยคิด” ออกจาก “ทำรายการ”
สมมติทีมต้องการผู้ช่วยดูแลงานขายภายใน ขอบเขตเริ่มต้นอาจเป็นค้นคำสั่งซื้อที่ผู้ใช้มีสิทธิ์ดู แล้วร่างข้อความสรุป การให้บัญชีเชื่อมต่อเป็นผู้ดูแลระบบเต็มสิทธิ์เพื่อความสะดวกจะเปิดความสามารถมากกว่างานที่ตั้งใจไว้
| งานที่ต้องการ | ข้อมูลหรือสิทธิ์ที่เกี่ยวข้อง | จุดตรวจที่ควรกำหนด |
|---|---|---|
| อ่านสถานะคำสั่งซื้อ | อ่านเฉพาะรายการที่ผู้ใช้เข้าถึงได้ | ตรวจตัวตนผู้ใช้และขอบเขตข้อมูลทุกครั้ง |
| ร่างคำตอบลูกค้า | อ่านข้อมูลที่จำเป็นและสร้างฉบับร่าง | ให้ผู้ใช้เห็นแหล่งข้อมูลและตรวจข้อความ |
| ส่งอีเมลที่ตรวจแล้ว | ส่งไปยังผู้รับที่ระบุ | ตรวจผู้รับ เนื้อหา และไฟล์แนบก่อนส่ง |
| เสนอเปลี่ยนที่อยู่จัดส่ง | อ่านค่าปัจจุบันและเตรียมค่าใหม่ | แสดงความต่าง ตรวจสถานะคำสั่งซื้อ และขออนุมัติตามกติกาธุรกิจ |
ตารางนี้เป็นตัวอย่างการออกแบบ ไม่ใช่สิทธิ์มาตรฐานสำหรับทุกธุรกิจ จุดสำคัญคือแต่ละงานต้องมีขอบเขตแยกกัน หากเครื่องมือรองรับเฉพาะการเข้าถึงแบบกว้าง ควรพิจารณาตัวกลางที่เปิดเฉพาะคำสั่งที่ต้องใช้ แทนการเปิดทุกอย่างให้ Agent แล้วหวังว่าจะเลือกทำถูกเอง
สิทธิ์ของผู้ใช้ต้องตามไปถึงข้อมูลปลายทาง
เมื่อพนักงานสองคนเห็นข้อมูลคนละชุด ผู้ช่วยของแต่ละคนก็ควรเห็นตามขอบเขตนั้น การค้นเอกสารทั้งหมดก่อนแล้วค่อยสั่ง AI ว่าอย่าแสดงบางส่วนมีความเสี่ยง เพราะข้อมูลที่ไม่ควรเข้าถึงได้เข้าไปอยู่ในบริบทของระบบแล้ว
กำหนดสิทธิ์ตามประเภทข้อมูล การกระทำ และขอบเขตงาน เช่น อ่านคำสั่งซื้อของทีมที่ดูแล แต่ไม่แก้ข้อมูลลูกค้าทั้งหมด ไม่ควรเก็บรหัสผ่านหรือคีย์เชื่อมต่อไว้ในข้อความสนทนาหรือเอกสารที่โมเดลอ่าน ให้ระบบจัดการข้อมูลรับรองแยกจากเนื้อหาที่ใช้สร้างคำตอบ
OWASP อธิบายความเสี่ยง Excessive Agency ว่าเกี่ยวข้องกับความสามารถ สิทธิ์ หรืออิสระในการลงมือที่มากเกินไป พร้อมแนะนำให้จำกัดสิทธิ์ของเครื่องมือ หลักการนี้ควรถูกแปลงเป็นข้อจำกัดที่ปลายทางบังคับใช้ได้ ไม่ใช่เพียงข้อความเตือนในหน้าจอ
ปุ่มอนุมัติต้องบอกว่ากำลังอนุมัติอะไร
คำถามว่า “ให้ดำเนินการต่อไหม” ยังไม่พอสำหรับการเปลี่ยนข้อมูล ผู้ตรวจควรเห็นระบบและรายการปลายทาง ค่าปัจจุบัน ค่าใหม่ ผู้รับหรือผู้ได้รับผล และส่วนที่ย้อนคืนได้หรือไม่ได้ตามลักษณะงาน หากเป็นการส่งข้อความ ต้องเห็นเนื้อหาและไฟล์แนบชุดที่จะส่งจริง
การอนุมัติต้องผูกกับรายการที่ตรวจแล้ว หาก Agent เปลี่ยนผู้รับ เพิ่มไฟล์แนบ หรือแก้ค่าหลังจากกดยืนยัน ต้องตรวจใหม่ตามกติกาที่กำหนด ไม่ให้การกดครั้งหนึ่งกลายเป็นสิทธิ์เปิดกว้างสำหรับรายการถัดไปทั้งหมด
ก่อนลงมือ ระบบควรตรวจด้วยว่าสถานะต้นทางยังเหมือนตอนเสนอหรือไม่ เช่น คำสั่งซื้ออาจถูกส่งออกไปแล้วระหว่างรออนุมัติ งานเปลี่ยนที่อยู่จึงอาจทำต่อแบบเดิมไม่ได้ แม้คนเคยเห็นชอบข้อเสนอ การอนุมัติไม่ได้ทำให้ข้อจำกัดของกระบวนการธุรกิจหายไป
Amazon Bedrock มีฟีเจอร์ยืนยันก่อนเรียกใช้บางการกระทำ เป็นตัวอย่างว่าจุดยืนยันสามารถแยกตามคำสั่งได้ แต่ทีมยังต้องออกแบบว่าใครมีสิทธิ์อนุมัติ หน้าจอแสดงอะไร และระบบปลายทางตรวจขอบเขตอย่างไร
เอกสารที่ Agent อ่านอาจมีคำสั่งที่ไม่ควรทำตาม
อีเมล หน้าเว็บ หรือเอกสารที่ใช้เป็นข้อมูลอาจมีข้อความให้ละเลยกฎหรือส่งข้อมูลไปที่อื่น เนื้อหาเหล่านั้นไม่ควรมีอำนาจเท่าคำสั่งของผู้ใช้หรือกติกาของระบบ ต้องแยกข้อมูลประกอบออกจากสิทธิ์ในการสั่งงาน
ลองทดสอบด้วยเอกสารจำลองที่มีคำสั่งแปลกปลอม ดูว่าระบบเพียงนำข้อความมาอธิบายหรือกลับนำไปเรียกเครื่องมือจริง ไม่จำเป็นต้องใช้ข้อมูลลับในการทดสอบ จุดตรวจควรครอบคลุมทั้งการเลือกเครื่องมือ การกรอกค่าปลายทาง และผลหลังดำเนินการ
การให้คนอนุมัติก็ยังต้องทำให้ตรวจได้ง่าย หากแสดงรายละเอียดไม่ครบหรือขออนุมัติถี่จนคนกดผ่านโดยไม่อ่าน จุดตรวจนั้นจะมีคุณค่าน้อยลง ควรลดการขอซ้ำในงานที่ไม่มีผลสำคัญตามนโยบาย และเน้นแสดงผลกระทบชัดในรายการที่ต้องตัดสินใจจริง
บันทึกให้ตอบได้ว่าใครขอ ใครอนุมัติ และเกิดอะไรขึ้น
เก็บข้อมูลที่เชื่อมจากคำขอไปยังข้อเสนอ การอนุมัติ และผลจากระบบปลายทางได้ เช่น รหัสคำขอ คำสั่งที่ใช้ และรายการที่เปลี่ยน โดยไม่บันทึกความลับเกินจำเป็น สถานะ “สำเร็จ” ต้องมาจากผลที่ยืนยันได้ ไม่ใช่จากการที่ AI เขียนว่างานเสร็จแล้ว
ถ้าปลายทางตอบช้าหรือขาดการเชื่อมต่อ ต้องตรวจว่ารายการเกิดขึ้นแล้วหรือยังก่อนลองใหม่ โดยเฉพาะงานที่อาจสร้างข้อความหรืองานซ้ำ กำหนดว่าใครตรวจกรณีไม่ทราบผล และมีข้อมูลอะไรให้เขาตามต่อได้
เตรียมวิธีหยุดการทำรายการของ Agent โดยยังเก็บหลักฐานให้ตรวจต่อได้ ระบุเจ้าของการปิดสิทธิ์และวิธีให้ทีมกลับไปทำงานด้วยขั้นตอนเดิม เมื่อแก้ปัญหาแล้วจึงทดสอบเฉพาะส่วนที่ได้รับผลก่อนเปิดอีกครั้ง
เปิดสิทธิ์ทีละงาน หลังผ่านกรณีที่ควรปฏิเสธด้วย
ก่อนใช้งานจริง ให้ทดสอบผู้ใช้ที่มีและไม่มีสิทธิ์ ข้อมูลที่เปลี่ยนระหว่างรออนุมัติ การยกเลิกคำขอ และการลองใหม่หลังระบบไม่ตอบ ผลผ่านต้องรวมการปฏิเสธที่ถูกต้อง ไม่ใช่ดูแค่ว่า Agent ทำรายการสำเร็จได้
เริ่มจากงานอ่านหรือร่างที่ช่วยทีมได้ก่อน แล้วเพิ่มการกระทำเมื่อมีเจ้าของงาน จุดตรวจ และวิธีติดตามผลชัดเจน หากยังอธิบายไม่ได้ว่าใครรับผิดชอบเมื่อทำผิด ก็ควรจำกัดขอบเขตนั้นไว้จนกว่าจะออกแบบการรับช่วงได้
การแยกบทบาทตั้งแต่ต้นสัมพันธ์กับ การเลือก Chatbot หรือ AI Agent ส่วนขั้นอนุมัติที่ต้องติดตามหลายฝ่ายสามารถใช้แนวคิดจาก ระบบอนุมัติเอกสารออนไลน์ มาประกอบการวางงาน
อยากให้ AI ทำงานต่อได้ โดยยังควบคุมสิทธิ์และการอนุมัติ?
Talvyn Labs ช่วยแยกหน้าที่ของ Agent ออกแบบเครื่องมือเชื่อมต่อ และวางจุดให้คนตรวจรายการจริงก่อนดำเนินการ เริ่มจากงานหนึ่งขั้นตอนและสิทธิ์เท่าที่จำเป็นกับงานนั้น
วางขอบเขตและสิทธิ์ของ AI Agent