สามสาขาสร้างบอทตอบกฎการลาไม่ตรงกัน 3 แบบ? ฟีเจอร์ใหม่ของ Copilot ให้ส่ง Agent ขึ้นทะเบียนเป็นเวอร์ชันทางการเดียว

ผู้จัดการฝ่ายบุคคลของแบรนด์ชานมไข่มุกเครือหนึ่งเพิ่งปวดหัวกับสายร้องเรียนสามสาย ผู้จัดการสาขาทั้งสามแห่งต่างคนต่างใช้ Copilot Agent Builder สร้าง "ผู้ช่วยตอบระเบียบการลา" ขึ้นมาเอง Agent ของสาขา A อ้างอิงระเบียบฉบับเก่าปีที่แล้วที่ยังไม่ได้ปรับปรุง สาขา B เป็นไฟล์ Excel ที่ผู้จัดการรวบรวมเอง (มีบางข้อจำผิดด้วย) ส่วนสาขา C เชื่อมกับ SOP ฉบับล่าสุดของบริษัท พนักงานทั้งสามคนแคปหน้าจอเทียบคำตอบกันในกลุ่มแชทจนทะเลาะ สุดท้ายทุกคนหันมาถามฝ่ายบุคคลว่า "ตกลงอันไหนถูก" ฝ่ายบุคคลถึงเพิ่งรู้ว่ามี "Agent ป่า" แบบนี้วิ่งอยู่กี่ตัวในบริษัท ไม่ต้องพูดถึงว่าใครดูแล อ้างอิงเอกสารฉบับไหน

ทำไมเรื่องนี้ถึงจัดการไม่ได้สักที

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

องค์ประกอบของกลไกการกำกับดูแลที่ดี

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

🔧 AI ลงมือทำ: ส่ง Agent ที่สร้างเองขึ้นทะเบียนใน Agent Store ของบริษัท

Microsoft 365 Copilot เปิดตัวฟีเจอร์ "ส่งขึ้นทะเบียน": Agent ที่สร้างจาก Agent Builder เดิมใช้ได้แค่แชร์ลิงก์ส่วนตัว ตอนนี้กด "ส่งขึ้นทะเบียน" ในหน้า Agent Builder ได้โดยตรง ผู้ดูแลระบบอนุมัติในศูนย์ผู้ดูแลระบบ Microsoft 365 แล้ว Agent จะปรากฏในส่วน "สร้างโดยองค์กรของคุณ" ของ Agent Store ให้ทุกคนเข้าถึงจากจุดเดียว แต่ขึ้นทะเบียนไม่ได้แปลว่าจบเรื่อง ขั้นตอนตรวจสอบต่างหากที่ตัดสินความสำเร็จของการกำกับดูแล ใช้พรอมป์นี้ให้ผู้บริหารหรือ IT ที่รับผิดชอบตรวจสอบ ไล่เช็กทีละรายการ:

คุณคือผู้ตรวจสอบการกำกับดูแล AI Agent ของ "[ชื่อบริษัท]" กรุณาจัดทำเช็กลิสต์สำหรับ Agent "[ชื่อ Agent]" ที่จะส่งขึ้นทะเบียน:
1. แหล่งความรู้มาจากเอกสารใดบ้าง? ระบุชื่อและวันที่ปรับปรุงล่าสุด
2. ใครรับผิดชอบดูแลเอกสารแต่ละฉบับ? ถ้าไม่มีให้ระบุ "ความเสี่ยง: ไม่มีผู้รับผิดชอบอัปเดต"
3. หากตอบผิดจะก่อผลกระทบอะไร?
4. รอบทบทวนที่แนะนำคือนานเท่าใด? อธิบายเหตุผล (ควรสอดคล้องกับความถี่ในการปรับปรุงเอกสารต้นทาง)
5. สิทธิ์เข้าถึงข้อมูลที่ Agent อ้างอิง อิงตามบัญชีผู้ใช้หรืออิงตามตัว Agent เอง? กรุณาระบุให้ชัดเจน
6. หากผู้สร้างเดิม ([ชื่อผู้สร้าง]) ลาออกหรือโยกย้ายตำแหน่ง ใครจะรับช่วงดูแลต่อ?
7. ใครมีสิทธิ์ถอดออกหรือระงับการใช้งาน Agent นี้ได้ทันทีเมื่อพบว่าตอบผิด?
สรุปเป็นตาราง ช่องว่างระบุ "รอเพิ่มเติม" และให้คำแนะนำว่า "ควรขึ้นทะเบียน" / "ควรขึ้นทะเบียนหลังเพิ่มเอกสารให้ครบ" / "ไม่แนะนำให้ขึ้นทะเบียน"

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

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