AI Agent อัตโนมัติงานออฟฟิศ: 7 จุดพลาดที่เราเจอจากการใช้งานจริง

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

บทสรุป: ความสำเร็จของระบบอัตโนมัติอยู่ที่ “การรู้ว่ามันพัง” ไม่ใช่ความฉลาดของโมเดล

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

ทั้งหมดนี้ไม่ใช่ “AI ทำผิด” แต่มาจากสิ่งที่อยู่รอบตัว Agent คือความสมบูรณ์ของข้อมูลขาเข้า ความไม่ซ้ำของบันทึก การเฝ้าระวัง และเส้นแบ่งการอนุมัติของมนุษย์ ดังนั้นศูนย์กลางของการออกแบบระบบอัตโนมัติภายในองค์กรจึงมี 5 ข้อ

1. แยกได้หรือไม่ระหว่าง “ดึงข้อมูลไม่ได้” กับ “ข้อมูลมีศูนย์รายการ”
2. นิยามตัวระบุที่ป้องกันการบันทึกเหตุการณ์เดิมซ้ำ โดยเป็นอิสระจากโค้ดได้หรือไม่
3. ผลลัพธ์ทุกชิ้นระบุตัวหารและช่วงเวลาไว้หรือไม่
4. มีเส้นแบ่งระหว่างงานที่มนุษย์ต้องอนุมัติ กับงานที่ Agent ทำเองได้หรือไม่
5. เมื่อระบบพัง ใครจะรู้ เมื่อไร และผ่านช่องทางใด

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

เราทำอะไรให้เป็นอัตโนมัติบ้าง: 9 สายงานหลังบ้านที่รันทุกวัน

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

รูปแบบเหมือนกันหมด คือ เก็บรวบรวม → ทำให้เป็นมาตรฐาน → บันทึก → แจ้งเตือน โดย Generative AI รับหน้าที่หลักในขั้นทำให้เป็นมาตรฐาน (จัดหมวด สรุป แปล จับคู่) เราจงใจบันทึกลงในที่ที่คนดูอยู่แล้ว ได้แก่ ฐานข้อมูลงานและบันทึกการประชุม แชทงาน และโฟลเดอร์ฉบับร่างอีเมล และไม่สร้างหน้าจอเฉพาะสำหรับ Agent ขึ้นมาใหม่ เพราะระบบอัตโนมัติที่บังคับให้พนักงานต้องเรียนรู้หน้าจอใหม่ จะไม่มีใครเปิดดูตั้งแต่สัปดาห์แรกของการใช้งาน

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

จุดพลาดที่ 1: ความล้มเหลวที่ปลอมตัวเป็น “0 รายการ”

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

สาเหตุคือโค้ดแทนค่า “ผลลัพธ์ว่างเปล่า” กับ “ดึงข้อมูลไม่ได้” ด้วยอาเรย์ว่างตัวเดียวกัน Agent ได้รับอาเรย์ว่างและรายงานว่า 0 อย่างซื่อสัตย์ ไม่มีใครโกหก แต่กระบวนการหยุดไป 15 วัน

ตอนนี้เราใส่สามอย่างนี้ในทุกงาน

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

โดยทั่วไป การเฝ้าระวังงานแบบ Batch มักออกแบบให้ “ส่งเสียงเมื่อล้มเหลว” แต่ AI Agent มีคุณสมบัติตรงกันข้าม คือมันปัดความล้มเหลวขึ้นเป็นความสำเร็จ ให้ใส่ การเฝ้าระวังแบบ dead-man ที่ถือว่าความเงียบคือความผิดปกติ ตั้งแต่วันแรก

จุดพลาดที่ 2: เมื่อคีย์กันซ้ำเปลี่ยนไป ทุกอย่างจะดูเหมือนใหม่ทุกเช้า

เมื่อการตรวจสอบเดิมรันทุกวัน การ “ไม่สร้างงานที่สร้างไปแล้วซ้ำอีก” จึงเป็นสิ่งจำเป็น เราตัดสินเรื่องนี้ด้วยค่าแฮชของสตริงที่ระบุรายการนั้นได้เพียงหนึ่งเดียว เรียกว่าคีย์กันซ้ำ (idempotency key)

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

สรุปในรูปแบบที่นำไปใช้ต่อได้

• เขียนนิยามของคีย์กันซ้ำเป็นข้อความไว้ที่เดียว แล้วให้โค้ดอ้างอิงถึงที่นั่น เช่น “ต่อวันที่กับรายการเหตุการณ์ที่เรียงแล้วด้วย | จากนั้นเอา 12 อักขระแรกของค่า SHA-1″ โดยอักขระคั่นเป็นส่วนหนึ่งของข้อกำหนด
• ห้ามผสมเวลาที่รันหรือสภาพแวดล้อมที่รันเข้าไปในวัตถุดิบของคีย์ เวลาปัจจุบัน ชื่อโฮสต์ และพาธไฟล์ ล้วนทำให้เหตุการณ์เดิมกลายเป็นคนละเหตุการณ์ในทุกรอบ
• ทำให้ผลของการตรวจซ้ำมองเห็นได้ พิมพ์ “ใหม่ n รายการ อัปเดต m รายการ ไม่เปลี่ยน k รายการ” ทุกรอบ เมื่อสัดส่วนกระโดด คุณจะเห็น และถ้าทุกอย่างกลายเป็นของใหม่ คุณจะเห็นตั้งแต่เช้าวันนั้น

จุดพลาดที่ 3: ฟังก์ชันค้นหาที่คิดว่ามีอยู่ กลับใช้ไม่ได้ในสภาพแวดล้อมจริง

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

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

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

• ไวยากรณ์ค้นหาหรือกรองทำงานจบ ที่ปริมาณข้อมูลจริง หรือไม่ (ทดสอบด้วยจำนวนระดับใช้งานจริง ไม่ใช่ตัวอย่าง 100 รายการ)
• API แบบอะซิงโครนัส แจ้งการเสร็จสิ้นหรือไม่ ถ้าต้องวนถาม เงื่อนไขสิ้นสุดคืออะไร
• ไฟล์แนบ เนื้อหา หรือฟิลด์ที่กำหนดเอง มี ข้อจำกัดด้านสิทธิ์และไลเซนส์ หรือไม่
• พฤติกรรมเมื่อชนขีดจำกัดอัตราการเรียก ให้ยืนยันช่วงเวลาการลองใหม่และเพดานจากเอกสารของผู้ให้บริการเอง ทั้ง Microsoft Graph และ Notion API ต่างเผยแพร่ค่าขีดจำกัดและพฤติกรรมที่แนะนำไว้

จุดพลาดที่ 4: ถ้าไม่ระบุตัวหาร ข้อสรุปของการรวมข้อมูลจะกลับด้าน

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

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

กฎที่เราตั้งไว้มีดังนี้

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

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

จุดพลาดที่ 5: วันและเวลาเคลื่อนอย่างเงียบ ๆ ตามสภาพแวดล้อม

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

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

มาตรการแก้ไขนั้นเรียบง่าย แต่ต้องบังคับใช้จริง

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

จุดพลาดที่ 6: มีแคชและการซิงก์คั่นอยู่ระหว่างการเขียนกับการอ่าน

เมื่อระบบอัตโนมัติเขียนลงระบบภายในหรือเว็บไซต์ของบริษัทเอง คุณจะเจอปรากฏการณ์ที่ เนื้อหาที่เขียนไปแล้วหายไป เรายืนยันได้สองรูปแบบ

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

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

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

จุดพลาดที่ 7: เมื่อมีต้นฉบับสองที่ ฉบับที่แก้ไม่ใช่ฉบับที่ถูกอ่าน

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

เรื่องนี้ไม่ใช่ปัญหาเฉพาะของ AI แต่มันสร้างความเสียหายมากกว่าเมื่ออยู่ในการใช้งานแบบ Agent เพราะ Agent อ่านตำแหน่งที่ถูกชี้ให้อ่าน และทำตามสิ่งที่เขียนไว้ตรงนั้นเป๊ะ ๆ มันจึงรันจนจบอย่างมั่นใจแม้อ่านนิยามเก่า มนุษย์จะหยุดคิดว่า “เอ๊ะ ก็แก้ไปแล้วนี่” แต่ Agent ไม่หยุด

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

จะวางการอนุมัติของมนุษย์ไว้ตรงไหน: กำหนดระดับความอิสระเป็นขั้น

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

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

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

องค์ประกอบขั้นต่ำสำหรับการใช้งานจริง

นี่คือเนื้อหาเดียวกันในรูปของรายการความต้องการขั้นต่ำสำหรับองค์กรที่กำลังเริ่มต้น การมีครบ 7 ข้อนี้สำคัญต่อความต่อเนื่องมากกว่าฟีเจอร์ขั้นสูงใด ๆ

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

เริ่มอย่างไร: สร้างเล็ก ๆ แล้วทดสอบวิธีที่มันพังก่อน

หากกำลังพิจารณาระบบอัตโนมัติภายในองค์กร เราแนะนำลำดับนี้ สำหรับการประเมินและการวางแผนตรวจสอบ โปรดดู รายการค่าใช้จ่ายและเกณฑ์ความสำเร็จของ AI PoC ส่วนความสามารถของพนักงาน โปรดดู การทดสอบภาคปฏิบัติสำหรับการอบรม Generative AI ให้พนักงาน

1. เลือกสายงานเดียวเท่านั้น ควรเป็นงานที่เกิดขึ้นทุกวัน ไม่เสียหายร้ายแรงหากล่าช้า และตรวจสอบคำตอบที่ถูกต้องได้ภายหลัง ของเราคือการสะสมอีเมล
2. บันทึกลงเครื่องมือที่มีอยู่แล้ว อย่าสร้างหน้าจอใหม่ วางผลลัพธ์ไว้ในที่ที่คนดูอยู่แล้ว
3. หยุดที่ L4 (ฉบับร่าง) อย่าให้ส่งตั้งแต่แรก ให้คนตรวจให้คะแนนฉบับร่างสัก 1-2 สัปดาห์
4. ทดสอบวิธีที่มันพังก่อน ตัดการเชื่อมต่อ ถอนสิทธิ์ ทำให้ขาเข้าว่างเปล่า แล้วดูว่าการแจ้งเตือนบอกอะไรในแต่ละกรณี ถ้าแยกไม่ออก ให้แก้การออกแบบ
5. ใส่การแจ้งเตือนศูนย์ต่อเนื่องก่อน แล้วจึงย้ายไปสู่การรันแบบไร้คนดูแล
6. จัดรูปแบบคีย์และบันทึกการรันของสายงานที่สองให้ตรงกับสายงานแรก หากแต่ละสายงานคิดธรรมเนียมของตัวเอง ทั้งการเฝ้าระวังและการส่งมอบงานจะทำไม่ได้
7. ตรวจสอบตัวหารของผลลัพธ์ทุกไตรมาส การเปลี่ยนแปลงในกระบวนการทำงานจะเปลี่ยนความหมายของข้อมูลอย่างเงียบ ๆ

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

ระบบอัตโนมัติด้วย AI Agent ต้องใช้ทีมขนาดเท่าใด

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

Generative AI ต้องแม่นยำแค่ไหนจึงจะใช้งานจริงได้

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

ควรเริ่มทำอะไรเป็นอัตโนมัติก่อน

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

จะรู้ได้อย่างไรว่ากระบวนการอัตโนมัติหยุดทำงานแล้ว

แค่ “แจ้งเตือนเมื่อล้มเหลว” ยังไม่พอ ให้เฝ้าระวังรอบที่ได้ศูนย์รายการติดต่อกัน และรอบที่ไม่ได้เกิดขึ้นเลย (การเฝ้าระวังแบบ dead-man) เหตุขัดข้องที่ยืดเยื้อทุกครั้งที่เราเจอ ล้วนปรากฏในรูปของ “สำเร็จ ศูนย์รายการ”

ส่งข้อมูลภายในองค์กรให้ Generative AI ได้หรือไม่

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

ควรให้ Agent ส่งอีเมลหรือไม่

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

สรุป: ระบบอัตโนมัติถูกตัดสินจากวิธีที่มันพังอย่างเงียบ ๆ

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

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

หากคุณกำลังออกแบบระบบอัตโนมัติสำหรับงานหลังบ้านของสำนักงานในไทย หรือระบบอัตโนมัติภายในที่ต้องเชื่อมกับระบบหลัก ติดต่อเราได้ที่ หน้าติดต่อของ TOMAS TECH เมื่อทราบขอบเขตงานและระบบที่มีอยู่ เราจะช่วยทำให้ชัดเจนว่าควรเริ่มจากตรงไหน และควรวางการอนุมัติไว้ที่ใด

ข้อมูลอ้างอิง

• NIST, AI Risk Management Framework: https://www.nist.gov/itl/ai-risk-management-framework
• OWASP, Top 10 for Large Language Model Applications 2025: https://genai.owasp.org/llm-top-10/
• ISO, ISO/IEC 42001:2023 Artificial intelligence management system: https://www.iso.org/standard/42001
• Microsoft Learn, Microsoft Graph throttling guidance: https://learn.microsoft.com/en-us/graph/throttling
• Notion, API request limits: https://developers.notion.com/reference/request-limits
• ETDA, AI Governance Practice Center (AIGPC): https://www.etda.or.th/th/Our-Service/AIGC/index.aspx
• PDPC Thailand, Personal Data Protection Committee: https://www.pdpc.or.th/