UiPath Delegate ทำงานข้ามแอปได้แล้ว แต่สิทธิ์ผู้ใช้ยังเป็นเพดาน

UiPath ประกาศในงาน FUSION วันที่ 23 กันยายน 2026 ว่า Delegate พร้อมใช้งานทั่วไปแล้ว ผลิตภัณฑ์นี้เป็น AI agent บนเดสก์ท็อปที่รับคำสั่งภาษาธรรมชาติหรือเรียนรู้งานจากการสาธิต แล้วทำงานต่อเนื่องผ่านแอปและระบบธุรกิจภายใต้ตัวตน สิทธิ์ และการตรวจสอบของแพลตฟอร์ม UiPath เดิม การเปิดใช้จึงไม่ได้เพิ่มสิทธิ์ใหม่ให้บัญชีพนักงานโดยอัตโนมัติ

สำหรับองค์กรที่ใช้หลายระบบ ข่าวนี้หมายถึงพนักงานสามารถมอบเป้าหมายเดียวให้ Delegate วางขั้นตอนและลงมือทำงานที่เคยต้องย้ายไปมาระหว่างแอป แต่การอ่านข้อมูล การแก้ระเบียน และการส่งข้อความยังมีขอบเขตต่างกัน บทวิเคราะห์ของ THE D*AI*LY BRIEF จัด Delegate อยู่ในกลุ่มผลิตภัณฑ์ที่พร้อมใช้งานจากงาน FUSION และระบุว่า UiPath ยังไม่เผยแพร่ราคาหรือหน่วยคิดค่าบริการเฉพาะของผลิตภัณฑ์นี้

คำสั่งเดียวพางานผ่านหลายแอปอย่างไร

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

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

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

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

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

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

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

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

ต่างจาก RPA เดิมตรงวิธีรับและวางงาน

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

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

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

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

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

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

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

สิทธิ์ของบัญชีเป็นขอบเขตที่คำสั่งข้ามไม่ได้

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

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

เมื่อ Delegate ควบคุมแอปที่ไม่มี API จะทำผ่านหน้าจอและกระบวนการในเซสชันของผู้ใช้ โดยปกติไม่ได้ยกระดับเป็นผู้ดูแลระบบ หาก Windows ไม่ให้โปรเซสทั่วไปควบคุมหน้าต่างที่เปิดด้วยสิทธิ์ผู้ดูแลระบบ agent ก็ทำเช่นนั้นไม่ได้ การอนุมัติในหน้าต่างสนทนาไม่เปลี่ยนข้อจำกัดของระบบปฏิบัติการหรือสิทธิ์ใน CRM

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

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

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

โหมดอนุมัติกำหนดจุดที่คนต้องตัดสินใจ

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

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

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

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

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

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

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

ร่องรอยตรวจสอบต้องตามทันข้อมูลที่ agent ใช้

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

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

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

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

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

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