ก่อนนำ AI Agent มาใช้ ลองถามคำถามเชย ๆ ข้อหนึ่ง: ข้อมูลลูกค้าของคุณมีกี่เวอร์ชัน?

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

ระบบตอบตัวเลขกลับมา รองประธานขมวดคิ้ว "ไม่ใช่สิ ตัวเลขนี้น้อยไป"

ภายหลังค้นเจอว่าใน ERP มีลูกค้าสามรายคือ "ปตท." "บริษัท ปตท. จำกัด (มหาชน)" และ "PTT" ออร์เดอร์กระจายอยู่ใต้สามรหัส AI ไม่ได้ผิด มันซื่อ ๆ เอายอดของ "ปตท." รายเดียวมารวมบอกคุณ ที่ผิดคือข้อมูล

ข้อสรุปของการประชุมสาธิตครั้งนี้คือ "AI ยังไม่สุกงอม" ผมว่าข้อสรุปนี้ด่วนไป

เบื้องหลังเหตุการณ์

การสำรวจผู้บริหารระดับ C-level ทั่วโลก 1,000 คนในปี 2026 ให้ตัวเลขที่น่าสนใจมาก คือ การจัดการข้อมูลกลายเป็นความท้าทายใหญ่สุดของการนำ AI ไปใช้จริง คิดเป็น 51% แซงหน้าทั้งต้นทุนและบุคลากร

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

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

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

ประเด็นสำคัญครั้งนี้

การจะให้ Agent เข้าทำงานอย่างปลอดภัย มีพื้นฐานข้อมูลสามเรื่องที่หลบไม่พ้น:

• การจัดการข้อมูลหลัก (MDM): ทำให้ลูกค้า สินค้า ซัพพลายเออร์คนเดียวกันเป็นรายการเดียวกันในทุกระบบ นี่คือพื้นฐานที่สุด และถูกข้ามบ่อยที่สุดด้วย
• การแยกแยะเอนทิตี (entity resolution): ตัดสินว่า "สมชาย ใจดี" "คุณสมชาย ใจดี" "SOMCHAI JAIDEE" เป็นคนเดียวกันหรือไม่ และต้องบอกได้ว่าเพราะอะไร ความสามารถในการอธิบายในอุตสาหกรรมที่ถูกกำกับดูแลไม่ใช่แต้มบวก แต่เป็นเงื่อนไขจำเป็น
• สายเลือดข้อมูลและการกำกับการเข้าถึง: ข้อมูลนี้มาจากไหน ใครแก้ Agent มองเห็นฟิลด์ไหนได้บ้าง ไม่มีชั้นนี้ เวลาเกิดเรื่องคุณไล่หาไม่ได้เลย

วิเคราะห์ผลกระทบต่อตลาด

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

จะตัดสินว่าผู้ช่วย AI ของบริษัทคุณน่าเชื่อถือหรือไม่ มีวิธีทดสอบเชย ๆ อยู่ คือถามคำถามที่คุณรู้คำตอบอยู่แล้ว ถ้าแม้แต่ข้อนี้ยังตอบผิด แล้วตอนมันตอบคำถามที่คุณไม่รู้ คุณจะเชื่อมันด้วยอะไร

ต่อการใช้งานในองค์กร: สภาพข้อมูลขององค์กรในไทยมีปัญหาเฉพาะหลายอย่าง

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

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

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

ในตลาดมีเครื่องมือจัดการชั้นนี้ไม่น้อย: Reltio เดินแนวเรียลไทม์และ AI แบบ agentic, Semarchy ชูวินัย DataOps, Profisee ผูกลึกกับระบบนิเวศ Microsoft, CluedIn ใช้ฐานข้อมูลกราฟและคิดค่าแบบจ่ายตามใช้เพื่อลดกำแพง ส่วนที่เชี่ยวชาญการเทียบคู่โดยเฉพาะมี Senzing และ Data Ladder คำถามแรกของการเลือกไม่ใช่การเปรียบเทียบฟังก์ชัน แต่คือ "เข้ากับ data stack ที่ผมมีอยู่หรือไม่"

ต่อนักพัฒนา: หากคุณกำลังทำ AI Agent ภายในองค์กร มีหลักการออกแบบข้อหนึ่งที่ผมคิดว่าต้องยึด คือ ข้อมูลทุกรายการที่ Agent อ่าน ต้องตอบได้ว่า "อันนี้มาจากไหน"

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

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

แนวโน้มการพัฒนาในอนาคต

ผมสังเกตเห็นสองทิศทาง

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

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

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

บทสรุปและความเห็นจาก TheAI Academy

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

สาธิตอีกครั้ง ตัวเลขถูกต้อง

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

คำแนะนำที่เป็นรูปธรรมสำหรับผู้อ่านในไทย ขอพูดสามเรื่องที่เริ่มทำได้สัปดาห์หน้า:

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

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

สาม ขอบเขตต้องเล็ก อย่าเปิดโปรเจกต์ "กำกับข้อมูลทั้งบริษัท" นั่นแน่นอนว่าทำสามปีแล้วเงียบหาย เลือกด้านข้อมูลที่ Agent ใช้บ่อยที่สุด (มักเป็นลูกค้า) สามเดือนทำเวอร์ชันที่สะอาดออกมา ใช้มันพิสูจน์คุณค่า แล้วค่อยขยายออก

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

แหล่งข้อมูล

• McKinsey: The State of AI (Global Survey)
• Gartner Magic Quadrant for Master Data Management Solutions (เผยแพร่ซ้ำโดยเว็บทางการของผู้ผลิตแต่ละราย)
• คำอธิบายการสำรวจทางการของ Semarchy

เรียบเรียงจากข้อมูลสาธารณะ ตัวเลขการสำรวจแต่ละรายการอ้างอิงตามรายงานต้นฉบับ