การนำ AI agent มาใช้ 2026｜4 สิ่งที่ต้องกำหนดก่อน จึงไม่จบแค่ PoC

PoC เดินได้ แต่ไม่เคยขึ้นใช้งานจริง นี่คือบทสรุปที่พบบ่อยที่สุดของการนำ AI agent มาใช้ ผลสำรวจของ Anaconda ร่วมกับ Forrester ระบุว่า 88% ของ PoC ที่เกี่ยวกับ agent ไปไม่ถึงการใช้งานจริง สาเหตุไม่ได้อยู่ที่การเลือกโมเดลหรือการเลือกเครื่องมือ แต่อยู่ที่การไม่ได้กำหนด 4 เรื่อง คือ สิทธิ์ ขอบเขตข้อมูล การเฝ้าติดตาม และความเป็นเจ้าของ ให้เสร็จ “ก่อนจะลอง” บทความนี้จะจัดระเบียบเรื่องการออกแบบ 4 ข้อที่ต้องตัดสินใจก่อนเริ่ม รายละเอียดค่าใช้จ่าย และแนวทางดำเนินการ 90 วัน โดยตั้งอยู่บนบริบทของโรงงานในประเทศไทย

โครงสร้างที่ทำให้การนำ AI agent มาใช้จบลงแค่ PoC

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

88% ไปไม่ถึงการใช้งานจริง

จากผลสำรวจของ Anaconda และ Forrester 88% ของ PoC ที่เกี่ยวกับ agent ไปไม่ถึงการใช้งานจริง ตัวเลขระดับเดียวกันนี้ปรากฏซ้ำในกลุ่มตัวอย่างผู้บริหาร CIO ของ a16z และ MIT Sloan ส่วน Gartner ให้ตัวเลขที่เข้มกว่า คือ 89% หยุดอยู่ที่ขั้น PoC ผู้ทำสำรวจและกลุ่มตัวอย่างต่างกัน แต่ทุกฉบับบรรจบที่ข้อสรุปเดียวกันว่า เกือบ 9 ใน 10 ไม่ได้ขึ้นใช้งานจริง

ผลสำรวจเดียวกันยังระบุปัจจัยที่ขวางการขึ้นใช้งานจริงไว้ด้วย

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

78% มี PoC แต่มีเพียง 14% ที่ขึ้นใช้งานทั้งองค์กร

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

• 78% ขององค์กรมี PoC อย่างน้อย 1 ตัว
• แต่มีเพียง 14% ที่ไปถึงการใช้งานจริงในระดับทั้งองค์กร
• 64% ขององค์กรที่มี PoC พยายามขยายผลแล้วติดค้างอยู่นานเกิน 6 เดือน
• ระยะเวลาเฉลี่ยของ PoC ก่อนจะเข้าสู่ภาวะติดค้างคือ 4.7 เดือน

ส่วนต่างระหว่าง 78% กับ 14% หรือ ช่องว่าง 64 จุด คือ “ช่องว่างของการขยายผล” (scaling gap) โดยตรง จุดสำคัญคือ 64% นั้นไม่ได้ถูกอธิบายว่า “ล้มเหลว” แต่ถูกอธิบายว่า “ติดค้าง” ของที่เดินได้นั้นสร้างเสร็จแล้ว แต่ทันทีที่พยายามขยาย ประเด็นที่ตอน PoC ไม่เคยถูกถามก็ผุดขึ้นมาพร้อมกันทั้งหมด

ตัวเลขเฉลี่ย 4.7 เดือนก็บอกอะไรได้มาก ใช้เวลาเกือบครึ่งปีเดิน PoC แล้วเริ่มขยายผล จากนั้นนิ่งอีกกว่า 6 เดือน รวมแล้วเกือบ 1 ปีผ่านไป ตลอดช่วงนี้ ค่าแรงและค่าไลเซนส์ที่จ่ายไปไม่ได้ถูกคืนกลับมาเลย

ช่องว่างระหว่างอุตสาหกรรมต่างกันเกือบ 3 เท่า

ควรดูอัตราการขึ้นใช้งานจริงแยกตามอุตสาหกรรมจากผลสำรวจเดียวกันด้วย

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

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

ต้นทุนจมจากความล้มเหลวเฉลี่ย 2.1 ล้านดอลลาร์สหรัฐ

โครงการ agent ที่ล้มเหลวในบริษัทกลุ่ม Fortune 1000 มี ต้นทุนจมเฉลี่ยราว 2.1 ล้านดอลลาร์สหรัฐ แน่นอนว่านี่คือตัวเลขของบริษัทขนาดใหญ่ และนำมาใช้กับโรงงานในประเทศไทยตรง ๆ ไม่ได้ แต่เมื่อแยกองค์ประกอบออกมาจะเห็นว่า ต่อให้ขนาดต่างกัน รายการค่าใช้จ่ายก็เกิดขึ้นเหมือนกัน

• ค่าไลเซนส์และค่าใช้ API (ระหว่างช่วง PoC ก็ยังถูกเรียกเก็บต่อเนื่อง)
• ค่าจ้างผู้ขายภายนอก
• ค่าแรงภายในบริษัท (ชั่วโมงงานของทีมโครงการ)
• งานพัฒนาเพื่อเชื่อมต่อ (การต่อเข้ากับระบบเดิม)
• การจัดเตรียมข้อมูล (การจัดระเบียบเอกสารเพื่อให้ agent อ่านและอ้างอิง)

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

ถ้าเริ่มจาก “ลองดูก่อนว่าใช้ได้ไหม” จะหยุดเสมอ

โครงการจำนวนมากเริ่มจาก “ลองดูก่อนว่าใช้ได้ไหม” ดูเหมือนจุดตั้งต้นที่ดีต่อสุขภาพ แต่การเข้าแบบนี้มีข้อบกพร่องเชิงโครงสร้าง 4 ข้อ

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

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

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

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

ทั้ง 4 ข้อนี้สอดคล้องกับ “สิทธิ์ ขอบเขตข้อมูล การเฝ้าติดตาม และความเป็นเจ้าของ” ที่จะกล่าวถึงในบทหลัง จุดที่ 88% หยุดอยู่นั้นแทบทั้งหมดกระจุกตัวอยู่ที่ 4 จุดนี้

62% ยังอยู่ขั้นทดลอง มีเพียง 23% ที่ขยายผล — ตำแหน่งของทั่วโลกและญี่ปุ่น

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

McKinsey: 62% อยู่ขั้นทดลอง 23% ขยายผลได้

รายงาน “The State of AI” ของ McKinsey (ฉบับเดือนพฤศจิกายน 2025) ระบุว่า 62% ขององค์กรอยู่ในขั้นทดลอง AI agent ขณะที่องค์กรซึ่งขยายผลการใช้งานจริงในระดับทั้งบริษัทได้อย่างน้อย 1 งาน มีอยู่เพียง 23%

การจับคู่ระหว่าง 62% กับ 23% นี้ มีโครงสร้างเหมือนกับ 78% กับ 14% ในบทก่อนหน้า กลุ่มตัวอย่างและนิยามต่างกันจึงเทียบกันตรง ๆ ไม่ได้ แต่ ภาพที่ว่า “บริษัทที่กำลังลองเป็นเสียงข้างมาก บริษัทที่เดินได้จริงเป็นเสียงข้างน้อย” นั้นตรงกันในหลายผลสำรวจ

สิ่งที่ควรจับไว้คือ เกณฑ์ของ 23% นั้นหลวมมาก คือ “ขยายผลได้แม้เพียง 1 งานก็นับ” พูดอีกอย่าง ณ ปี 2026 แค่เดินระบบ agent ใน 1 งานได้อย่างมั่นคง ก็อยู่ใน 20% แรกแล้ว ตีความกลับกันคือ ไม่จำเป็นต้องเล็งการขยายผลทั้งองค์กรตั้งแต่แรก การทำ 1 งานให้เดินได้แน่นอน คือตำแหน่งเชิงการแข่งขันในตัวมันเอง

อัตราการใช้ generative AI ในงานของญี่ปุ่นอยู่ที่ 55.2%

ตามสมุดปกขาวด้านสารสนเทศและการสื่อสารฉบับปีเรวะ 7 ของกระทรวงกิจการภายในและการสื่อสารญี่ปุ่น อัตราการใช้ generative AI ในการทำงานเป็นดังนี้

มีเพียงญี่ปุ่นที่ต่ำกว่าประเทศอื่นเกือบ 40 จุด อย่างน้อยก็อ่านได้ว่า “ในบริษัทญี่ปุ่น การใช้ generative AI ในงานยังไม่กลายเป็นเรื่องปกติ”

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

บริษัทญี่ปุ่นที่ได้ผลเกินความคาดหมายมาก มี 23%

ผลสำรวจสภาพจริงของ generative AI ฤดูใบไม้ผลิ 2025 ของ PwC Japan ระบุว่า บริษัทญี่ปุ่นที่ตอบว่าผลของ generative AI “เกินความคาดหมายมาก” มีอยู่ 23%

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

อัตราการมีนโยบายการใช้ AI: บริษัทใหญ่ 50% SME 30%

อัตราการจัดทำนโยบายการใช้ AI ของบริษัทญี่ปุ่นอยู่ที่ ราว 50% ในบริษัทขนาดใหญ่ และราว 30% ใน SME

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

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

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

ตลาดปี 2026 อยู่ที่ 7.8 พันล้านดอลลาร์ และ 40% ของแอปพลิเคชันองค์กรจะฝัง AI agent

ควรจับความเคลื่อนไหวฝั่งผู้ให้บริการไว้ด้วย

• ขนาดตลาดของ AI agent ในปี 2026 อยู่ที่ 7.8 พันล้านดอลลาร์สหรัฐ (เพิ่มขึ้น 50% จากปีก่อน)
• Gartner คาดการณ์ว่า ภายในสิ้นปี 2026 แอปพลิเคชันองค์กร 40% จะฝัง AI agent เข้าไป

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

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

ช่องว่างเฉพาะของประเทศไทย — องค์กร 10.7% แต่พนักงาน 72%

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

การกลับด้าน: องค์กร 10.7% พนักงานรายบุคคล 72%

เมื่อเรียงตัวเลขของไทยออกมา จะเห็นรอยแยกอย่างชัดเจน

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

Microsoft Work Trend Index 2026 ก็รายงานภาพเดียวกัน คือแรงงานไทยนำหน้าภูมิภาคในการใช้ AI ขณะที่ฝั่งองค์กรตามหลังอยู่ หน้างานวิ่งไปก่อน บริษัทตามไม่ทัน คือภาพจริงของประเทศไทย

ความเสี่ยง 3 ข้อที่เกิดจากโครงสร้างนี้

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

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

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

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

ความพร้อมทางดิจิทัลของไทยอยู่ที่ 2.12 / 4.0

ความพร้อมทางดิจิทัล (digital maturity) ของบริษัทไทยอยู่ที่ค่าเฉลี่ย 2.12 / 4.0 เพิ่มขึ้นจาก 1.56 ในปี 2025 ทิศทางถือว่าเดินหน้า

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

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

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

3 ประเด็นเฉพาะของโรงงานญี่ปุ่นในประเทศไทย

นอกจากข้างต้น โรงงานที่มีบริษัทแม่เป็นญี่ปุ่นยังมีเงื่อนไขเฉพาะของตัวเอง

ประเด็นที่ 1: การตัดสินใจแยกขาดกันระหว่างสำนักงานใหญ่กับโรงงาน

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

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

ประเด็นที่ 2: ภาษาแยกเป็น 3 ชั้น

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

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

ประเด็นที่ 3: ต้องออกแบบโดยตั้งสมมติฐานว่ามีการเปลี่ยนคน

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

เปลี่ยนการใช้งานรายบุคคลที่นำหน้าอยู่ให้เป็นสินทรัพย์ขององค์กร

ไม่จำเป็นต้องมองโครงสร้างของไทยในแง่ร้าย ข้อเท็จจริงที่ว่าพนักงาน 72% ใช้ AI อยู่แล้ว หมายความว่าแรงต้านต่อการนำมาใช้มีน้อย ในขณะที่สำนักงานใหญ่ที่ญี่ปุ่นเรียกร้องให้ “ลองใช้ AI กันเถอะ” แล้วปฏิกิริยาเงียบ ๆ แต่ในโรงงานที่ไทย คนที่ใช้อยู่แล้วเป็นเสียงข้างมาก

สิ่งที่ต้องทำจึงไม่ใช่การห้าม แต่คือการเตรียมที่รองรับ ในทางปฏิบัติ ลำดับต่อไปนี้ทำได้จริง

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

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

อนึ่ง ฝั่งภาครัฐไทยเองก็มีกรอบการสนับสนุนที่เดินอยู่ ทั้ง TH-AI Passport ของสำนักงานส่งเสริมเศรษฐกิจดิจิทัล (DEPA) และสิทธิประโยชน์ทางภาษีสำหรับการพัฒนาบุคลากร ซึ่งจะจัดระเบียบร่วมกับแผนงบประมาณในบทแผนดำเนินการ 90 วันต่อไป

AI agent ต่างจากอะไร — เส้นแบ่งกับ generative AI, RPA และแชตบอต

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

แบ่งด้วยคำถามว่าใครเป็นผู้ตัดสินใจ

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

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

จะจัดการกับ RPA ที่มีอยู่เดิมอย่างไร

โรงงานในประเทศไทยที่ติดตั้ง RPA ไว้แล้วก็มีไม่น้อย คำถามที่ได้ยินบ่อยคือ “ถ้าเอา agent เข้ามา ต้องทิ้ง RPA หรือไม่” คำตอบคือไม่ต้องทิ้ง

จัดระเบียบได้ดังนี้

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

อนึ่ง เวลาประเมินข้อเสนอจากผู้ขาย ให้ตรวจสอบ 3 ข้อ คือ “เป็นผลิตภัณฑ์ที่ต้องนิยามสถานการณ์ไว้ล่วงหน้าหรือไม่” “ข้ามหลายระบบได้หรือไม่” และ “เมื่อล้มเหลวจะเกิดอะไรขึ้น” แล้วจะเห็นสภาพจริง ผลิตภัณฑ์ที่ต้องนิยามสถานการณ์ล่วงหน้านั้นแท้จริงแล้วคือเครื่องมือ workflow ถ้าตั้งความคาดหวังด้วยมาตรฐานของ agent จะไม่ตรงกัน

อนึ่ง กรณีที่จะให้ agent อ้างอิงเอกสารภายในหรือแบบทางวิศวกรรม จำเป็นต้องสร้าง RAG (retrieval-augmented generation) เป็นฐานรองรับ การจัดเตรียมข้อมูลที่จะให้อ้างอิงมักใช้ชั่วโมงงานมากกว่าตัว agent เสียอีก แนวทางดำเนินการและค่าใช้จ่ายของส่วนนี้ได้จัดระเบียบไว้แยกต่างหากในค่าใช้จ่ายและแนวทางสร้าง RAG

4 สิ่งที่ต้องกำหนดก่อนเริ่ม — สิทธิ์ ขอบเขตข้อมูล การเฝ้าติดตาม และความเป็นเจ้าของ

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

ทำไมการกำหนด “ก่อน” จึงได้ผล

ในผลสำรวจของ Digital Applied มีตัวเลขที่ชี้ขาดอยู่ตัวหนึ่ง องค์กรที่วางทีมดูแลการใช้งาน AI แบบเต็มเวลาไว้ “ก่อน” การขยายผลเชิงปริมาณ มีอัตราความสำเร็จเป็น 5.7 เท่า ขององค์กรที่มากำหนดทีหลัง

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

ทั้ง 5 อันดับแรกตรงกับการออกแบบข้อใดข้อหนึ่งใน 4 ข้อทั้งหมด ไม่ได้หยุดเพราะยากทางเทคนิค แต่หยุดเพราะยังไม่ได้ตัดสินใจ

ต่อไปจะดูทีละข้อ

การออกแบบที่ 1: สิทธิ์ — agent ทำงานในนามของใคร

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

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

จัดระเบียบรายการที่ต้องตัดสินใจได้ดังนี้

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

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

การออกแบบที่ 2: ขอบเขตข้อมูล — ให้อ่านอะไร ไม่ให้อ่านอะไร

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

เริ่มจากแบ่งข้อมูลออกเป็น 4 กลุ่ม

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

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

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

ในทางปฏิบัติ การออกแบบขอบเขตข้อมูลจะเดินไปพร้อมกับแผนการจัดเตรียมเอกสารอ้างอิงเป็นเนื้อเดียวกัน

การออกแบบที่ 3: การเฝ้าติดตาม — จะตรวจจับการเสื่อมคุณภาพอย่างไร

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

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

ดังนั้นการเฝ้าติดตามจึงต้องออกแบบในฐานะ การเฝ้าติดตามเชิงงาน (ถูกต้องหรือไม่) ไม่ใช่การเฝ้าติดตามเชิงระบบ (เดินอยู่หรือไม่) อย่างน้อยที่สุดให้ดู 4 อย่างต่อไปนี้

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

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

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

การออกแบบที่ 4: ความเป็นเจ้าของ — นี่เป็นกลไกของใคร

ข้อสุดท้ายคือความเป็นเจ้าของ ตัวเลข “ขาดความเป็นเจ้าของในองค์กร 49%” บอกว่าราวครึ่งหนึ่งขององค์กรยังไม่ได้ตัดสินใจว่า “นี่เป็นกลไกของใคร”

สิ่งที่ต้องกำหนดคือบทบาท 4 อย่างต่อไปนี้

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

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

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

สรุปทั้ง 4 ข้อลงในกระดาษแผ่นเดียว

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

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

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

งานจัดทำกระดาษแผ่นนี้ ถ้าผู้เกี่ยวข้องมาประชุมกันก็จบได้ใน 2-3 ครั้ง สิ่งที่สร้างส่วนต่าง 5.7 เท่าคืองานแค่ระดับนี้เอง

ค่าใช้จ่ายและรายละเอียดของการนำ AI agent มาใช้ (ปี 2026)

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

ช่วงราคา 3 ระดับ

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

กรณีที่ต้องรายงานต่อสำนักงานใหญ่ที่ญี่ปุ่นเป็นสกุลเงินเยน หากคิดที่อัตรา 1 บาท ประมาณ 4.5 เยน ค่าใช้จ่ายเริ่มต้นของระดับ A จะอยู่ราว 450,000-2,250,000 เยน ระดับ B ราว 3,600,000-13,500,000 เยน และระดับ C ราว 13,500,000-67,500,000 เยน อัตราแลกเปลี่ยนผันผวน จึงขอให้ใช้เพียงเพื่อจับหลักของตัวเลข

ไม่จำเป็นต้องเล็งระดับ C ตั้งแต่ต้น อย่างที่กล่าวไว้ก่อนหน้า ณ ปี 2026 แค่ขยายผลได้ 1 งานก็อยู่ใน 20% แรกแล้ว การทำ 1 งานให้เดินได้แน่นอนด้วยระดับ B แล้วค่อยขยายจากความรู้ที่ได้ สุดท้ายจะเร็วกว่าและถูกกว่า

ต้นทุนต่อเนื่องที่มองไม่เห็น 3 ประเภท

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

ข้อที่ 1: ค่าโทเคนและค่าใช้ API

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

ตอนทำใบเสนอราคาให้ประมาณด้วยสูตรนี้

ค่าโทเคนรายเดือน = ปริมาณโทเคนที่คาดต่อ 1 รายการ x จำนวนรายการต่อเดือน x ราคาต่อหน่วย

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

ข้อที่ 2: ค่าแรงของการเฝ้าติดตาม

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

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

ข้อที่ 3: การอัปเดตข้อมูลอ้างอิงและการปรับจูนใหม่

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

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

ใส่ต้นทุนของความล้มเหลวเข้าไปในการประเมินด้วย

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

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

3 จุดที่ต้องตรวจสอบเวลาประเมินใบเสนอราคา

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

พื้นที่การใช้งานที่ได้ผลจริงในหน้างานการผลิต

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

พื้นที่ที่ 1: การบริหารการผลิตและการตอบกำหนดส่งมอบ

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

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

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

พื้นที่ที่ 2: คุณภาพและการวิเคราะห์ของเสีย

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

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

พื้นที่ที่ 3: การบำรุงรักษาเครื่องจักร

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

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

พื้นที่ที่ 4: การจัดซื้อจัดหา

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

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

พื้นที่ที่ 5: เอกสารหลายภาษา

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

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

แกนในการตัดสินใจว่าจะเริ่มจากตรงไหน

แม้จะเรียง 5 พื้นที่ไว้ แต่ไม่ควรเริ่มทั้งหมดพร้อมกัน แกนในการเลือกมี 4 ข้อดังนี้

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

แผนดำเนินการ 90 วันสำหรับโรงงานในประเทศไทย

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

Day 0-30: ตัดสินใจโดยยังไม่ต้องแตะเครื่องมือ

งานส่วนใหญ่ใน 30 วันนี้เป็นงานที่ไม่ต้องแตะเครื่องมือเลย

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

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

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

Day 31-60: เดินระบบเล็ก ๆ และลงมือเฝ้าติดตามจริง

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

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

จุดที่มักสะดุดคือการเฝ้าติดตาม ถ้า “สัปดาห์นี้ยุ่ง ขอข้ามก่อน” เกิดขึ้น 2 ครั้งติดกัน หลังจากนั้นก็จะไม่ทำอีกเลย จำเป็นต้อง กันตัวผู้รับผิดชอบและกรอบเวลาของการเฝ้าติดตามไว้เป็นงานตั้งแต่ช่วง Day 0-30 อีกหลุมพรางหนึ่งคือ การขยายผู้ใช้มากเกินไป เมื่อคนใช้ได้มากขึ้น คำขอเพิ่มฟังก์ชันจะพอกพูน และเป้าหมายที่ต้องประเมินก็จะเบลอ สิ่งที่ถูกต้องคือช่วง Day 31-60 ให้ล็อกฟังก์ชันไว้แล้วทุ่มไปที่การเก็บค่าวัดจริง

Day 61-90: ตัดสินใจและกำหนดโครงสร้างการดูแล

เมื่อค่าวัดจริงครบแล้ว ให้ตัดสินใจเรื่องการขึ้นใช้งานจริง วัตถุดิบของการตัดสินใจมี 4 อย่าง

1. ผ่านเกณฑ์การประเมินหรือไม่: เทียบค่าวัดจริงกับเกณฑ์ที่กำหนดไว้ใน Day 0-30
2. อัตราการแก้ไขอยู่ในระดับที่ยอมรับได้หรือไม่: ถ้าผู้ใช้ต้องลงมือแก้มากทุกครั้ง แสดงว่ายังเร็วเกินไปที่จะขึ้นใช้งานจริง
3. ค่าใช้จ่ายต่อเนื่องที่วัดได้จริงเท่าไร: คำนวณค่าใช้จ่ายรายปีจากค่าโทเคนที่วัดจริง แล้วเทียบกับผลของการลดต้นทุน
4. มีโครงสร้างที่เฝ้าติดตามต่อเนื่องได้หรือไม่: กันตัวผู้รับผิดชอบและชั่วโมงงานได้หรือไม่

ถ้าข้อใดข้อหนึ่งใน 4 ข้อนี้ไม่ผ่าน ให้ นำการยุติไว้ก่อนเข้ามาเป็นทางเลือกด้วย ไม่ใช่การยืดเวลา ความหมายของการกำหนดเกณฑ์การยุติไว้ล่วงหน้าอยู่ตรงนี้

ถ้าผ่านทั้งหมด ให้กำหนดโครงสร้างการดูแล

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

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

ใส่มาตรการของ DEPA และ BOI เข้าไปในแผนงบประมาณ

ในฐานะข้อเสริมเฉพาะของโรงงานในประเทศไทย ควรใส่การตรวจสอบมาตรการสนับสนุนจากภาครัฐเข้าไปในแผนด้วย

DEPA กำลังเดินหน้า TH-AI Passport (ขนาด 1.6 พันล้านบาท เปิดลงทะเบียนวันที่ 5 มิถุนายน 2026) และได้เริ่ม Coding Thailand 2026 เมื่อวันที่ 16 มีนาคม 2026 ที่ Siam Square SiamScape ด้านบุคลากรมี สิทธิประโยชน์ทางภาษีสำหรับค่าอบรมพนักงานที่เกี่ยวข้องกับการพัฒนาบุคลากรสูงสุด 250% เตรียมไว้ เนื่องจากในการนำ agent มาใช้ คอขวดมักอยู่ที่การพัฒนาบุคลากรมากกว่าค่าเครื่องมือ จึง คุ้มค่าที่จะตรวจสอบการจัดการค่าใช้จ่ายด้านการอบรมในมุมภาษีตอนกำหนดโครงสร้างการดูแลในช่วง Day 61-90

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

วิธีวัดผลและคำนวณ ROI

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

แนวคิดพื้นฐาน: ดูด้วย 4 รายการ

ไม่จำเป็นต้องทำให้ซับซ้อน ให้ประเมินประโยชน์รายปีด้วย 4 รายการต่อไปนี้ แล้วเทียบกับค่าใช้จ่าย

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

ตัวอย่างการคำนวณ: งานตอบกำหนดส่งมอบ

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

เงื่อนไขตั้งต้น

• งานเป้าหมาย: การตอบคำถามเรื่องกำหนดส่งมอบจากลูกค้า
• จำนวนรายการ: วันละ 50 รายการ x วันทำงาน 240 วันต่อปี = 12,000 รายการต่อปี
• เวลาที่ใช้ในปัจจุบัน: เฉลี่ย 12 นาทีต่อรายการ (การไล่ดูหลายระบบ + การเขียนข้อความตอบ)
• เวลาที่ใช้หลังนำมาใช้: เฉลี่ย 4 นาทีต่อรายการ (agent สร้างฉบับร่าง คนตรวจแล้วส่ง)
• ค่าแรงต่อหน่วย: 400 บาทต่อชั่วโมง (คิดจากค่าใช้จ่ายบุคลากรรวมของพนักงานสายบริหาร)

การคำนวณประโยชน์

• ชั่วโมงงานต่อปีในปัจจุบัน: 12 นาที x 12,000 รายการ ÷ 60 = 2,400 ชั่วโมง
• ชั่วโมงงานต่อปีหลังนำมาใช้: 4 นาที x 12,000 รายการ ÷ 60 = 800 ชั่วโมง
• ชั่วโมงงานที่ลดได้: 1,600 ชั่วโมงต่อปี
• แปลงเป็นเงิน: 1,600 ชั่วโมง x 400 บาท = 640,000 บาทต่อปี

การคำนวณค่าใช้จ่าย

• ค่าใช้จ่ายเริ่มต้น: 900,000 บาท (ใกล้ขอบล่างของระดับ B รวมการเชื่อมต่อกับระบบเดิม)
• ค่าใช้จ่ายต่อเนื่องต่อปี: 258,400 บาท

– ค่าโทเคนและค่าใช้ API: ประมาณ 140,000 บาท

– ค่าแรงของการเฝ้าติดตาม: 8 ชั่วโมงต่อเดือน x 12 เดือน x 400 บาท = 38,400 บาท

– การบำรุงรักษาและอัปเดตข้อมูลอ้างอิง: ประมาณ 80,000 บาท

การคำนวณการคืนทุน

• ประโยชน์สุทธิต่อปี: 640,000 − 258,400 = 381,600 บาทต่อปี
• จำนวนปีคืนทุนอย่างง่าย: 900,000 ÷ 381,600 = ประมาณ 2.4 ปี

สำหรับระบบหน้างานในภาคการผลิต ความรู้สึกทั่วไปคือ ถ้าคืนทุนได้ภายใน 2-4 ปี การตัดสินใจลงทุนมักผ่านได้ง่าย การประมาณการนี้อยู่ในช่วงดังกล่าว

3 จุดที่มักคำนวณผิด

การคำนวณข้างต้นเรียบง่าย แต่ในทางปฏิบัติมักเกิดความผิดพลาดใน 3 จุดต่อไปนี้

ผิดพลาดข้อที่ 1: ไม่ได้ใส่ค่าใช้จ่ายต่อเนื่องเข้าไปในค่าใช้จ่าย

ถ้าคำนวณจำนวนปีคืนทุนด้วยค่าใช้จ่ายเริ่มต้นอย่างเดียว จะได้ 900,000 ÷ 640,000 = ประมาณ 1.4 ปี ซึ่งห่างจาก 2.4 ปีที่เป็นจริงอย่างมาก โดยเฉพาะค่าโทเคนและค่าแรงของการเฝ้าติดตามที่ไม่ปรากฏในใบเสนอราคา จึงต้องตั้งใจใส่เข้าไปเอง

ผิดพลาดข้อที่ 2: ตั้งเวลาที่ใช้หลังนำมาใช้ในแง่ดีเกินไป

หลายคนอยากตั้งสมมติฐานว่า “จาก 12 นาทีต่อรายการจะเหลือ 1 นาที” แต่ เวลาที่คนตรวจสอบยังเหลืออยู่เสมอ ถ้าตั้งค่าบนกระดาษโดยไม่ใช้ค่าวัดจริงจาก Day 31-60 ส่วนนี้จะถูกประเมินต่ำเกินไป

ผิดพลาดข้อที่ 3: ไม่ได้กำหนดว่าจะเอาเวลาที่ลดได้ไปใช้ทำอะไร

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

เขียนเกณฑ์การประเมินเป็นเอกสารก่อนเริ่ม

สิ่งที่สำคัญกว่าตัวสูตรคำนวณคือ การเขียนการคำนวณนี้เป็นเอกสารตั้งแต่ช่วง Day 0-30

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

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

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

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

การนำ AI agent มาใช้มีค่าใช้จ่ายเท่าไร

แตกต่างกันมากตามรูปแบบการนำมาใช้ กรอบราคาทั่วไปคือ การตั้งค่าใช้บริการสำเร็จรูปมีค่าใช้จ่ายเริ่มต้นราว 100,000-500,000 บาท การสร้างแบบเฉพาะทางที่จำกัดไว้ 1-2 งานราว 800,000-3,000,000 บาท และการขยายผลหลายงานพร้อมเชื่อมระบบหลักราว 3,000,000-15,000,000 บาท แต่ตัวเลขนี้แปรผันอย่างมากตามงานเป้าหมาย จำนวนระบบที่ต้องเชื่อมต่อ และสภาพการจัดเตรียมข้อมูลเดิม

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

AI agent ต่างจาก RPA อย่างไร

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

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

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

ต้องใช้เวลานานแค่ไหนในการนำมาใช้

ถ้าจำกัดที่ 1 งาน จะใช้เวลาราว 90 วันจนกว่าวัตถุดิบของการตัดสินใจจะครบ แบ่งเป็นการสำรวจสภาพจริงและการออกแบบ 30 วัน PoC ในขอบเขตจำกัดและการเฝ้าติดตาม 30 วัน และการตัดสินใจขึ้นใช้งานจริงพร้อมกำหนดโครงสร้างการดูแลอีก 30 วัน

สิ่งที่ต้องระวังคือ ผลสำรวจระบุว่า ระยะเวลาเฉลี่ยของ PoC อยู่ที่ 4.7 เดือน และหลังจากนั้น 64% ติดค้างอยู่นานเกิน 6 เดือน สาเหตุหลักที่ระยะเวลายืดออกไม่ใช่เทคโนโลยี แต่คือการพูดซ้ำว่า “ขอดูสถานการณ์อีกหน่อย” โดยไม่มีเกณฑ์การตัดสินใจ การกำหนดเกณฑ์การยุติไว้ตั้งแต่จุดเริ่มต้นจะป้องกันภาวะติดค้างนี้ได้ อนึ่ง กรณีที่เอกสารซึ่งจะให้อ้างอิงยังไม่ได้จัดเตรียม ต้องเผื่อระยะเวลาจัดเตรียมเพิ่มต่างหาก การจำกัดงานเป้าหมายจะทำให้ขอบเขตของการจัดเตรียมแคบลงด้วย หลักการ “เริ่มจาก 1 งาน” จึงได้ผลตรงนี้เช่นกัน

โรงงานขนาดเล็กนำมาใช้ได้หรือไม่

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

สิ่งที่เสียเปรียบในแง่ขนาดคือจำนวนรายการ เนื่องจาก ROI ถูกกำหนดด้วย “เวลาที่ลดได้ต่อรายการ x จำนวนรายการ” งานที่มีจำนวนรายการน้อยจึงเห็นผลยาก สิ่งที่ถูกต้องคือตัดสินด้วยจำนวนรายการของงานเป้าหมาย ไม่ใช่จำนวนพนักงาน ถ้าเป็นงานวันละไม่กี่รายการ การทำให้ขั้นตอนง่ายขึ้นได้ผลกว่าการทำเป็น agent สำหรับโรงงานขนาดเล็ก ลำดับที่เป็นจริงคือเริ่มจากการตั้งค่าใช้บริการสำเร็จรูป (ระดับ A) ก่อน แล้วค่อยพิจารณาการสร้างแบบเฉพาะทางเมื่อยืนยันผลได้แล้ว

ปรึกษาเป็นภาษาไทยได้หรือไม่

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

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

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

ต้องเปลี่ยนระบบหลักเดิมก่อนหรือไม่

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

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

จะบริหารความเสี่ยงข้อมูลรั่วไหลอย่างไร

สิ่งที่ต้องบริหารมี 2 อย่าง คือ การรั่วไหลจาก agent ที่องค์กรนำมาใช้ และ การรั่วไหลจากการใช้งานรายบุคคลที่องค์กรไม่รับรู้

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

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

บทสรุป

สิ่งที่ชี้ขาดความสำเร็จหรือล้มเหลวของการนำ AI agent มาใช้ ไม่ใช่การเลือกโมเดลหรือการเลือกเครื่องมือ แต่คือ การได้กำหนด 4 ข้อ คือ สิทธิ์ ขอบเขตข้อมูล การเฝ้าติดตาม และความเป็นเจ้าของ ก่อนเข้าสู่ PoC หรือไม่ สาเหตุที่ 88% หยุดอยู่แค่ PoC คือการเลื่อน 4 ข้อนี้ไปทีหลังแล้วเริ่มจาก “ลองดูก่อนว่าใช้ได้ไหม”

ขอสรุปประเด็นสำคัญของบทความนี้

• 88% ไปไม่ถึงการใช้งานจริง ปัจจัยขวางอันดับต้นคือ เกณฑ์การประเมินไม่ครบถ้วน 64% แรงเสียดทานด้านธรรมาภิบาล 57% และความน่าเชื่อถือของโมเดล 51% สองอันดับแรกไม่เกี่ยวกับสมรรถนะของโมเดล แต่มาจากสิ่งที่ยังไม่ได้ตัดสินใจ
• 78% มี PoC แต่มีเพียง 14% ที่ขึ้นใช้งานทั้งองค์กร 64% ติดค้างเกิน 6 เดือน และระยะเวลาเฉลี่ยของ PoC ก่อนติดค้างคือ 4.7 เดือน ต้นทุนจมเฉลี่ยของโครงการที่ล้มเหลวอยู่ที่ราว 2.1 ล้านดอลลาร์สหรัฐ
• ญี่ปุ่นมีอัตราการใช้ generative AI ในงาน 55.2% ตามหลังจีน 95.8% สหรัฐฯ 90.6% และเยอรมนี 90.3% ส่วน McKinsey ระบุว่า 62% อยู่ขั้นทดลอง และ 23% ขยายผลได้ แค่เดินได้อย่างมั่นคงใน 1 งานก็อยู่ใน 20% แรกแล้ว
• ไทยมีโครงสร้างกลับด้าน คือองค์กร 10.7% แต่พนักงานรายบุคคล 72% เทียบกับสิงคโปร์ 69% และเวียดนาม 23% แล้วการนำมาใช้ระดับองค์กรยังช้า แต่ การที่หน้างานมีแรงต้านน้อยก็เป็นจุดแข็งเช่นกัน ระดับความพร้อม 2.12 / 4.0 บอกว่ามีโรงงานจำนวนมากที่ต้องจัดโครงสร้างพื้นฐานข้อมูลก่อนพูดถึง agent
• การออกแบบ 4 ข้อคือตัวจริง สิทธิ์คือ “ทำงานในนามของใคร” ขอบเขตข้อมูลคือ “ให้อ่านอะไรและไม่ให้อ่านอะไร” การเฝ้าติดตามคือ “จะตรวจจับการเสื่อมอย่างไร” และความเป็นเจ้าของคือ “นี่เป็นกลไกของใคร” องค์กรที่วางทีมเต็มเวลาไว้ก่อนการขยายผลมีอัตราความสำเร็จ 5.7 เท่า
• ตัดสินค่าใช้จ่ายด้วยค่าใช้จ่ายต่อเนื่อง ค่าโทเคนและค่าใช้ API ค่าแรงของการเฝ้าติดตาม และค่าอัปเดตข้อมูลอ้างอิง มักไม่ปรากฏในใบเสนอราคา สิ่งที่ควรทำก่อนคือการลงทุนในฝั่งที่เหลืออยู่แม้ล้มเหลว (การทำให้ดึงข้อมูลออกจากระบบเดิมได้ และการจัดเตรียมเอกสารการทำงาน)
• สร้างวัตถุดิบของการตัดสินใจใน 90 วัน 30 วันแรกไม่ต้องแตะเครื่องมือ ให้ทำการออกแบบและเกณฑ์เป็นเอกสาร 30 วันถัดมาทำ PoC ในขอบเขตจำกัดและวัดผลการเฝ้าติดตามจริง และ 30 วันสุดท้ายตัดสินใจขึ้นใช้งานจริงพร้อมกำหนดโครงสร้างการดูแล
• วาง ROI บนแกนหลักของการลดชั่วโมงงาน หักค่าใช้จ่ายต่อเนื่องออก เหลือเวลาที่คนใช้ตรวจสอบไว้ และกำหนดว่าจะเอาเวลาที่ลดได้ไปใช้ทำอะไร เกณฑ์การประเมินสร้างได้เฉพาะก่อนนำมาใช้เท่านั้น

ในด้านสภาพแวดล้อมภายนอก มีการคาดการณ์ของ Gartner ว่าภายในสิ้นปี 2026 แอปพลิเคชันองค์กร 40% จะฝัง AI agent เข้าไป และขนาดตลาดก็มีแนวโน้มขยายเป็น 7.8 พันล้านดอลลาร์สหรัฐในปี 2026 (เพิ่มขึ้น 50% จากปีก่อน) ต่อให้ไม่สร้างเอง agent ก็จะเข้ามาอยู่ในแอปที่ใช้อยู่แล้ว ช่วงเวลาที่จะเลื่อนการออกแบบสิทธิ์และขอบเขตข้อมูลออกไปได้นั้นไม่ยาวนักแล้ว

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

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