วิธีเชื่อมต่อเอเจนต์ AI กับระบบเดิมขององค์กร: สถาปัตยกรรม กระบวนการ และแนวปฏิบัติด้านความปลอดภัย

ทำความเข้าใจ “การเชื่อมต่อ” ก่อน: โมเดลไม่ควรมีสิทธิ์เข้าถึงระบบโดยตรง

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

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

สำรวจงานก่อน แล้วจึงตัดสินใจว่าจะเชื่อมต่อระบบใด

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

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

จะเลือกใช้ API, Webhook, การเรียกใช้ฟังก์ชัน และ RPA อย่างไร

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

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

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

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

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

สถาปัตยกรรมที่แนะนำ: แยกการวางแผน การดำเนินการ และการกำกับดูแลออกจากกัน

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

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

จากโครงการนำร่องสู่การใช้งานจริง: ค่อย ๆ ขยายตามระดับความเสี่ยง

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

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

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

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

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

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

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

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

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

จะวัดได้อย่างไรว่าการเชื่อมต่อระบบมีประสิทธิผล

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

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

คำถามที่พบบ่อย

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

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

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

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

บทสรุป: เริ่มจากการดำเนินการเล็ก ๆ ที่ตรวจสอบได้

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