โครงการทดลองผ่านสวย ทีมชอบ ผู้บริหารดูแล้วพยักหน้า พอถึงรอบของบปีถัดไป คำถามที่กลับมามีอยู่ประโยคเดียวว่าที่จ่ายไปแล้วได้อะไรกลับมา แล้วคำตอบดีที่สุดที่หาได้ก็คือทีมทำงานเร็วขึ้น ซึ่งวัดต่อไม่ได้ว่าเร็วขึ้นแล้วบริษัทได้เงินเพิ่มตรงไหน
อาการนี้ไม่ได้เกิดที่บริษัทคุณที่เดียว ไม่ได้เกิดที่ไทยที่เดียวด้วย และมีชื่อเรียกของมันอยู่แล้ว
เราดำเนินรายการเวที "AI Adoption in Thailand: What Actually Works" ในงาน vLLM Bangkok Day 2026 ตั้งคำถามเองทั้ง 6 ข้อ และตั้งใจเลือกคนขึ้นเวทีให้อยู่คนละจุดของโซ่เดียวกัน ไม่ใช่วิทยากร 3 คนที่พูดเรื่องเดียวกันคนละสำนวน
- Dr Komes Chandavimol (KBTG) ต้องทำให้ AI ทำงานได้จริงข้างในธนาคาร และอยู่ใกล้ตลาดที่สุด
- Dr Pin Siang Tan (Embedded LLM) ทำให้โมเดลรันได้จริงบนเครื่องของลูกค้า รวมถึงการเสิร์ฟแบบที่ข้อมูลไม่ออกนอกตึก
- Tuan Luong (Tensormesh) กดต้นทุนการเสิร์ฟให้ถูกลงตั้งแต่ต้นทาง และเทียบข้ามประเทศในภูมิภาคนี้ได้
เราดูแล product ที่ FlowAccount ก็เลยเข้าเวทีนี้ด้วยคำถามของคนที่ต้องเอาของขึ้นจริง และต้องตอบให้ได้ว่าเงินที่ลงไปแล้วได้อะไรกลับมา
ช่วงที่ 1ทำไมองค์กรพิสูจน์ผลของ AI ไม่ได้ ทั้งที่คนใช้แล้วเห็นผลชัด
องค์กรพิสูจน์ไม่ได้เพราะสิ่งที่เห็นเป็นผลของคนคนเดียว ไม่ใช่ผลของเวิร์กโฟลว์ทั้งเส้น Tuan เรียกอาการนี้ว่า productivity paradox
ระดับบุคคล AI ได้ผลชัดมาก คนที่นั่งอยู่ในงานวันนั้นเกือบทุกคนทำงานกับมันทุกวันอยู่แล้ว แต่พอถอยมามองทั้งองค์กร กลับพิสูจน์ไม่ได้ว่างานที่ทำอยู่จริงดีขึ้นตรงไหน เงินออกไปแล้ว ไม่มีใครมั่นใจว่าได้อะไรกลับมา และคนที่เซ็นงบรอบถัดไปต้องเห็นผลตอบแทนก่อนถึงจะจ่ายต่อ
เขาย้ำด้วยว่านี่เป็นปัญหาระดับโลก ไม่ใช่ปัญหาของอาเซียน และคาดว่าช่องว่างนี้จะแคบลงในหนึ่งถึงสองปีข้างหน้า
ตอนตอบคำถามข้อท้ายๆ เขาเปิดไพ่ที่มีประโยชน์ที่สุดของทั้งเวทีสำหรับคนที่ต้องเดินไปคุยกับผู้บริหาร คำถามที่คนตัดสินใจระดับบนถามจริงมีอยู่ 2 ข้อ
AI จะทำให้ผมหาเงินได้เพิ่มขึ้นเท่าไหร่
แล้วจะช่วยผมประหยัดได้เท่าไหร่
อย่างอื่นเป็นการเสนอจากล่างขึ้นบน ซึ่งไม่ผ่านเกณฑ์ตั้งแต่ประโยคแรก การเดินเข้าไปบอกว่าเราไปเห็นเทคโนโลยีใหม่มาในงานหนึ่ง แล้วอยากลอง แพ้คำถาม 2 ข้อนี้ทุกครั้ง
อีกครึ่งของคำตอบมาจากองค์กรใหญ่
Komes เล่าลำดับที่ KBTG เดินมา จุดเริ่มของเขาคือการวัดความพร้อมของคนก่อน แล้วค่อยว่ากันเรื่องเครื่องมือ
ย้อนไป 3 ปีก่อน ตอนที่ ChatGPT เพิ่งออกมา ทุกคนสมมติกันเองว่าใครๆ ก็ใช้เป็นแล้ว พอวัดจริงที่ KBTG ซึ่งเป็นบริษัทเทคโนโลยี ตัวเลขออกมาราว 80 ถึง 90% ที่ใช้อยู่แล้ว คนกลุ่มนั้นคือ early adopter คือกลุ่มที่คว้าของใหม่มาใช้เองโดยไม่ต้องมีใครผลัก ส่วนคนที่เหลือต้องออกแบบให้เหมาะกับเขาเป็นรายกลุ่ม
developer ผ่านขั้นผู้ช่วยไปแล้ว เครื่องมือช่วยเขียนโค้ดกับเครื่องมือเพิ่ม productivity อยู่ในมือครบ AI กลายเป็นคู่หูของเขา ไม่ใช่ของใหม่ที่ต้องมาแนะนำกันอีก
ปีนี้ KBTG เรียงงานไว้เป็น 3 จังหวะ ใช้ให้ถูกวิธีก่อน แล้วค่อยไปที่ productivity แล้วค่อยไปที่ impact ปีหน้าถึงจะรวม impact ของแต่ละคนให้เป็นก้อนใหญ่ แล้วผลักออกไปถึงลูกค้า
ช่วงที่ 2PoC ที่ผ่านสวยแล้วไม่ไปไหนต่อ ปัญหาอยู่ที่ความกล้าไม่พอ
ของที่โชว์แล้วคนว้าว กับระบบที่รอดจาก traffic จริง ห่างกันตรงไหน เราถามไปแบบนั้น แล้วคำตอบของ Pin Siang ก็กลับด้านกับที่เราคาดไว้
ปัญหาของ PoC ส่วนใหญ่คือตั้งเป้าไว้เล็กเกินไป การเริ่มใช้ AI ส่วนใหญ่เริ่มจาก PoC 3 เดือน แล้วตั้งเป้าไว้แค่ว่าให้ดีเท่าระบบซอฟต์แวร์แบบเดิม ซึ่งต่ำกว่าที่ AI ทำได้อยู่แล้วในวันนี้
กรอบวัดผลที่เขาบอกว่าใช้ไม่ได้คือ "ทำให้พนักงานทุกคนเร็วขึ้น 50%" เจ้านายที่เขาคุยด้วยยิงกลับว่าถ้าพนักงานเร็วขึ้น 50% เขาอาจจะแค่ไปนั่งเล่นที่ห้องกาแฟนานขึ้นก็ได้ กรอบที่ใช้ได้คือ superpower คือทำให้ทำสิ่งที่เมื่อก่อนทำไม่ได้เลย ปีที่แล้วของแบบนั้นคือ OCR ที่อ่านตัวหนังสือออกจากรูป กับการหาข้อมูลอ่อนไหวจากบทถอดเสียง ปีนี้คือทีม 10 คนส่งงานคุณภาพระดับโลกได้ ทั้งที่ก่อนหน้านี้ระดับนั้นต้องใช้คนระดับโลกถึงจะไปถึง
และของแบบนี้ไม่โผล่ในการสาธิตสั้นๆ วิธีเดียวที่จะเห็นคือเอาขึ้น production แล้วแจก credit ของ agentic AI ให้ทุกคนใช้ ผลจะแสดงตัวเองภายในราว 2 เดือน (agentic AI คือ AI ที่ลงมือทำงานเป็นขั้นเป็นตอนเองได้ ไม่ได้หยุดอยู่ที่การตอบคำถาม)
ส่วนที่คนนอกมองไม่เห็นคือคนกับกระบวนการ
เราถามต่อว่าอะไรที่คนนอกมองไม่เห็น Komes ตอบว่าเรื่องเครื่องมือคนเห็นกันหมดแล้ว ที่เหลืออยู่หลังฉากคือคนกับกระบวนการ
จุดตั้งต้นคือให้ความรู้พื้นฐานเรื่อง AI กับทุกคนก่อน เพราะคนที่สร้าง pilot ไม่ใช่ developer อีกต่อไปแล้ว knowledge worker สร้าง agent ได้เองในวันนี้ พอพื้นฐานมีครบ ค่อยเดินขึ้นบันไดที่แต่ละขั้นใช้เงินบริษัทมากขึ้นเรื่อยๆ
กล่องที่ 1 · บันได 3 ขั้นก่อนขึ้น production
| ขั้น | ผ่านเมื่อ | บริษัทให้ | ข้อจำกัด |
|---|---|---|---|
| prototype / MVP | ใครจะสร้างก็สร้างได้ ไม่มีเงื่อนไข | เครื่องมือ | ไม่มี |
| pilot | ตอบได้ว่ามีคุณค่าหรือ impact กับบริษัทตรงไหน | playground · credit · เครื่องมือเพิ่ม · สิทธิ์เข้า platform | ทดสอบกับพนักงานเท่านั้น ยังไม่แตะลูกค้า และมีกรอบเวลากำกับ |
| production | บอก exit criteria ให้ชัดก่อน | สิทธิ์ขยายผลเต็มสเกล | ต้องวัดผลตามเกณฑ์ที่ประกาศไว้ |
ขั้นกลางคือขั้นที่คนข้ามกันบ่อย การทดสอบกับพนักงานก่อนไม่ใช่ความขี้ขลาด มันคือการยอมพลาดตอนที่ยังพลาดได้ในราคาถูก ส่วนขั้นสุดท้ายนั้นเกณฑ์เดียวที่ให้ผ่านคือบอกให้ได้ว่าจบแบบไหนถึงเรียกว่าสำเร็จ ตั้งแต่ก่อนเริ่ม
ช่วงที่ 3เมื่อไหร่ควร self-host เมื่อไหร่ควรเรียก API
เราขอเกณฑ์ตัดสินใจแบบที่คนในห้องเอากลับไปใช้ได้เลย Tuan ตอบด้วยเคสที่ลูกค้าโทรมาหาเขาจริง 2 เคส
- ทีมที่ใช้อยู่ราว 100,000 ล้าน input token ต่อเดือน มองบิล GPU ที่ไต่ขึ้นทุกเดือนแล้วโทรมาถามว่าจะกดมันลงยังไง
- บริษัทหนึ่งในไทยที่ตั้งงบ AI ไว้ 500,000 ดอลลาร์ต่อเดือน สำหรับ developer 1,000 คน ปรากฏว่าใช้งบทั้งเดือนหมดตั้งแต่กลางเดือน แล้วต้องหยุดพัฒนากันทั้งทีม
เขาบอกตรงๆ ว่าบิลคือปัจจัยแรกสุด เพราะเป็นเรื่องที่ลูกค้าโทรมาถามจริง ส่วน latency คือเวลาที่ระบบใช้ตอบกลับ และ sovereignty กับนโยบาย data residency เขาพูดต่อท้ายในฐานะของที่ต้องดู แล้วอีกไม่กี่นาทีต่อมาก็เรียก sovereignty ว่าสำคัญมาก ลำดับการพูดตรงนี้จึงอ่านเป็นน้ำหนักไม่ได้
กล่องที่ 2 · เกณฑ์ตัดสิน self-host กับเรียก API
มีอีกข้อที่คนตัดสินใจผิดกันบ่อย ฮาร์ดแวร์ที่ดูแย่ ส่วนใหญ่คือฮาร์ดแวร์ที่ยังไม่ได้จูน ลูกค้ารายหนึ่งใช้การ์ดจอเกมระดับผู้บริโภค 8 ใบ แล้วรายงานว่าประสิทธิภาพไม่ดี
ทีม Embedded LLM ซึ่งถนัดสาย AMD เข้าไปจูน inference จากความเร็วตั้งต้นให้เข้าใกล้ roofline ของเครื่อง ผลออกมาเร็วขึ้น 50 ถึง 100 เท่า โดยจูนให้ตรงกับหน้าตาของงานลูกค้ารายนั้น คือ concurrency ต่ำ (คนใช้พร้อมกันไม่เยอะ) ต้องการ latency ต่ำ และใช้อยู่ในเครื่องตัวเอง
ตัวเลขนี้ไม่ได้แปลว่าทุกเครื่องจะได้เท่านี้ แต่แปลว่าถ้ายังไม่เคยจูน ตัวเลขที่คุณกำลังใช้ตัดสินใจอาจไม่ใช่ความสามารถจริงของเครื่อง
ตอนที่คำถามย้อนกลับมาที่เราเองว่าบ้านเราอยู่ตรงไหนของเกณฑ์นี้ คำตอบคือยังอยู่ฝั่ง API เต็มตัว ใช้ frontier model ซึ่งเป็นโมเดลรุ่นบนสุดของผู้ให้บริการรายใหญ่ รันบนคลาวด์ในส่วนที่ลูกค้าเห็น เรียกผ่าน MCP server tools คือช่องมาตรฐานที่ให้โมเดลหยิบข้อมูลและสั่งงานระบบของเราได้ และยังไม่ได้เสิร์ฟโมเดลของตัวเอง ตรงกับเส้นตัดข้างบนพอดี เพราะเรายังไม่ได้เป็นเจ้าของ GPU
เจาะลึกต่อได้ที่ เมื่อไหร่ควร self-host LLM · เช่า GPU มารันโมเดลเอง · แบ่งงานให้โมเดลหลายตัวในงบก้อนเดียว
ที่เวียดนาม สิ่งที่ดัน GPU เข้าประเทศคือกฎหมาย Tuan เล่าว่าอุตสาหกรรมธนาคารและการเงินที่นั่นใช้ public API ไม่ได้เลย ธนาคารหลายแห่งเลยหันมารัน GPU เอง ทั้งที่เช่าจากผู้ให้บริการในประเทศและที่ตั้งคลัสเตอร์ในธนาคารเอง กฎบังคับให้การ์ดต้องอยู่ในเขตแดน แล้วนั่นก็คือสนามที่บริษัทสาย optimization อย่างเขาแข่งกับ public API พอดี
ช่วงที่ 4sovereignty ที่ตอบได้จริง เริ่มจาก 4 คำถาม
คำว่า sovereignty เป็นคำที่ทุกคนพูดแต่ไม่มีใครนิยามเหมือนกัน Tuan ตั้งคำถามกับคำนี้ว่าวงการไอทีเก่งเรื่องประดิษฐ์คำยากที่ไม่มีใครเข้าใจมา 20 ปีแล้ว คำว่า open source ก็อยู่ในกลุ่มนั้น
ตอนนี้บนอินเทอร์เน็ตมี sovereignty ระดับ 1 ระดับ 2 ระดับ 3 ไปจนถึงระดับสูงสุด โดยไม่มีมาตรฐานรองรับสักอัน และไม่มีใครรู้ว่าจะไปถึงระดับพวกนั้นได้ยังไง
นิยามที่เขาเสนอให้ใช้แทนคือคำเดียวสั้นๆ ว่าควบคุมสิ่งที่เรามีให้ได้มากที่สุด แล้วแตกเป็นคำถามที่ตอบได้จริง
กล่องที่ 3 · 4 คำถาม sovereignty ที่ต้องตอบได้
จุดที่น่าสนใจคือเขาเปิดเรื่องการเลือกโมเดลทิ้งไว้โดยตั้งใจ ใช้อะไรก็ได้ ขอแค่ควบคุมมันได้
ของแบบไหนควรทำเอง ของแบบไหนควรหยิบของคนอื่นมาใช้
Pin Siang แบ่งเป็น 3 กอง
- ทำเอง คือการจูน inference ให้ตรงกับงานของตัวเอง ถ้าเป็นเจ้าของ GPU และรู้ว่ากำลังเล็งงานหน้าตาไหน ยังมีประสิทธิภาพเหลือให้ดึงออกมาจากฮาร์ดแวร์ในมืออีกมาก
- หยิบมาใช้ คือการเรียก API ของผู้ให้บริการหลายเจ้า วิธีนี้เป็นที่นิยมและราคาถือว่าคุ้มเมื่อเทียบกับ productivity ที่ได้
- ทำเป็นสินค้า คือของอย่าง TokenVisor ของทีมเขา ที่ให้ลูกค้าเลือกเองได้ว่าจะใช้ผู้ให้บริการเจ้าไหน โดยปุ่มควบคุมทั้งหมดอยู่บนเซิร์ฟเวอร์ของลูกค้า ในนั้นมีทั้ง guardrail คือกติกาที่ตีกรอบว่าโมเดลตอบอะไรได้ตอบอะไรไม่ได้ โควตา token รายคน rate limit คือเพดานจำนวนครั้งที่เรียกใช้ได้ต่อช่วงเวลา และการกำหนดว่าโปรเจกต์ไหนไป API โปรเจกต์ไหน self-host โปรเจกต์ไหนไปคลาวด์ GPU ที่จองไว้ พวกเขาเรียกของชิ้นนี้ว่า AI firewall คือด่านที่คั่นระหว่างคนในบริษัทกับโมเดล
ส่วนของที่ปล่อยขึ้น upstream คือการส่งงานกลับเข้าโครงการต้นทางให้คนอื่นใช้ต่อ เขาบอกเหตุผลไว้ว่าไม่ได้ทำเพราะใจดี แต่เพราะอุตสาหกรรมนี้วิ่งเร็วพอ ของที่ปล่อยขึ้นไปเลยกลับมาหาเราในรูปงานที่ชุมชนต่อยอดไว้ให้แล้ว
เขายังตอบเรื่องอาเซียนแบบไม่เข้าข้างตัวเองด้วย ถ้านั่งลงนับจริงๆ ว่ามี developer จากอาเซียนกี่คนที่มีชื่ออยู่บนโครงการเหล่านั้น ก็จะเห็นว่าภูมิภาคนี้ยังอยู่ในระดับหยิบของมาใช้ ยังไม่ถึงระดับร่วมสร้าง ความหวังที่เขาฝากไว้คือคนรุ่นใหม่ที่กำลังจะเข้าไปเล่นในเกมระดับโลก
ช่วงที่ 5governance ยุคใหม่ไม่ใช่การควบคุม แต่คือการจัดสรร
ในหัวคนส่วนใหญ่ governance แปลว่าของที่ทำให้ช้าลง เราเลยถามให้ตรงข้าม แล้วคำตอบของ Komes ก็เปลี่ยนคำนิยามทิ้งเลย
เมื่อก่อน governance แปลว่าการควบคุม ตอนนี้แปลว่าการจัดสรร
เริ่มที่คนอีกแล้ว ในไทยมีทั้ง developer มี AI builder ที่ประกอบโซลูชันขึ้นมา และมีนักวิจัยที่สร้าง LLM ภาษาไทย หน้าที่ของ governance คือทำให้คนเลือกเครื่องมือให้ถูกกับงานได้
- งบ token คือคันโยกหลัก และขนาดของมันมาจากมูลค่าของโปรเจกต์ งานที่มี impact ระดับองค์กรได้ token เยอะ ส่วน "อยากให้ AI สร้างรูปหรือแต่งเพลง" ได้เครื่องมือกับเวลาไม่กี่วัน เพราะ impact เล็ก
- ต้องบอกเกณฑ์ความสำเร็จก่อนเริ่ม กระบวนการถามตั้งแต่ต้นว่า impact คืออะไร และจะวัดออกมาเป็นตัวเลขยังไง แล้วงบกับกำหนดเวลาก็อนุมัติตามคำตอบนั้น
- governance ไม่จบตอนขึ้นระบบ เมื่อก่อนมันจบตรงนั้น แต่พอเป็น AI ที่ลูกค้าใช้ตรงๆ ต้องเฝ้าต่อทั้งเรื่องที่โมเดลกุเรื่องขึ้นมาเอง และการวนซ้ำไม่รู้จบ ดู token ทุกตัวที่จ่ายไปเทียบกับ impact และประสิทธิภาพที่ได้ และถ้าผิดพลาดต้องดึงสินค้ากลับได้
- ตัวเลข funnel ที่เขาให้ไว้ ราว 1,000 ไอเดีย เหลือ MVP หลักร้อย เหลือ pilot ราว 10 โครงการ ส่วนการขยาย pilot ที่ทดสอบกับคน 100 คน ไปสู่ฐานลูกค้าราว 20 ล้านคน นับเป็นอีกจังหวะของ governance ในตัวเอง เพราะต้นทุน token ไม่ได้ขยายตามสัดส่วนเดิม
- แผนถอยจึงเป็นของบังคับ ถ้าดึงสินค้า AI กลับ ลูกค้ายังต้องได้รับบริการอยู่ ไม่งั้นสิ่งที่เสียไปคือความเชื่อใจ
ตัวเลข funnel นั่นคือของที่เอาไปวางตรงหน้าผู้บริหารได้ทันที เพราะมันบอกว่า pilot ที่ตายระหว่างทางคือรูปร่างปกติของกระบวนการ
คนขายของก็มอง governance เป็นเรื่องความเชื่อใจเหมือนกัน Pin Siang บอกว่า governance คือสิ่งที่ทำให้ลูกค้าเชื่อเราได้ ในวันที่งานส่วนใหญ่ส่งต่อให้ AI ทำ คำสัญญาที่เราให้ลูกค้าไว้ขึ้นอยู่กับทุก request ที่ระบบเฝ้าอยู่ นับเป็น token หลักพันล้าน และทุกตัวต้องอยู่ในกติกาของบริษัท
ของที่เขาทำจริงมี 2 ชั้น ชั้นแรกคือ AI firewall ที่ผู้ดูแลตั้งคำสั่งกันข้อมูลทรัพย์สินทางปัญญารั่ว ระบุได้ว่าอะไรห้ามหลุด แล้วโมเดลจะไม่ข้ามเส้นนั้น ชั้นที่สองคือ TokenVisor Spaces ซึ่งเป็นพื้นที่ปิด (sandbox) ที่เก็บ agent หลายตัวไว้ด้วยกัน แล้ว agent จะเข้าถึงได้เฉพาะเอกสารที่วางไว้ในพื้นที่นั้น โปรเจกต์คนละลูกค้าอยู่คนละพื้นที่ มี RBAC คือการให้สิทธิ์ตามบทบาทของแต่ละคน และแยกสิทธิ์รายโปรเจกต์ตั้งแต่วันแรก
เป้าหมายการออกแบบที่เขาพูดออกมาน่าจดไว้ คือทำให้ง่ายพอที่ฝ่ายบริหารเข้าใจได้ เพราะของที่ผู้บริหารเข้าใจเท่านั้นที่ปกป้องบริษัทได้จริง
เจาะลึกต่อได้ที่ แบ่งชั้นการตัดสินใจว่าเรื่องไหนคนต้องอยู่ในลูป · agent ที่ต้องอยู่ยาว ต้องออกแบบยังไง
ช่วงที่ 6ปลายหางของตลาด ใครทำส่วนไหน
ปลายหางของตลาดคือกลุ่มธุรกิจเล็กจำนวนมหาศาลที่อยู่ท้ายเส้นกราฟ เราถามข้อนี้ในนามคนที่ทำงานกับคนกลุ่มนั้น ลูกค้าจำนวนมากของเราไม่มีทีมไอทีเลยสักคน และไม่เคยได้ยินคำว่า fine tuning ซึ่งแปลว่าการเอาโมเดลมาฝึกต่อด้วยข้อมูลของตัวเอง
ถ้า AI จะไปถึงเขาจริงๆ มันจะไปถึงในรูปของเครื่องมือที่เขาจ่ายเงินใช้อยู่แล้ว ไม่ใช่ในรูปของอะไรที่เขาต้องไปสร้างเอง คำถามคือใครทำส่วนไหน วิศวกร บริษัทซอฟต์แวร์ หรือรัฐ
Tuan ซึ่งใช้เวลา 12 ปีปั้นกลุ่มผู้ใช้ open source ในเวียดนามจนกลายเป็นชุมชนที่บริษัทต่างๆ พึ่งพาได้ ตอบไว้ 3 ท่อน คำถามข้อนี้เราต้องถามซ้ำ 2 รอบกว่าจะสื่อกันติด รอบแรกไปตกที่เรื่ององค์กรใหญ่ ซึ่งเป็นหลักฐานเล็กๆ ของสิ่งที่บทความนี้พูดอยู่ทั้งใบ คนคนละฝั่งของโซ่เดียวกันไม่ได้ใช้คำเดียวกันโดยอัตโนมัติ
- วิศวกรมีหน้าที่ใช้มันทุกวัน จนกลายเป็นเรื่องปกติ แล้วแบ่งปันต่อไปเรื่อยๆ เขาบอกว่าตอนนี้ตัวเองอยู่ไม่ได้แล้วถ้าไม่มีมัน
- แต่วิศวกรขยับการนำ AI เข้าองค์กรใหญ่หรือภาครัฐไม่ได้ เรื่องนั้นเป็นเรื่องของการลงทุน เรื่องเงิน และเรื่องคนกำหนดนโยบาย การเสนอจากล่างขึ้นบนแพ้คำถามจากบนลงล่างเสมอว่าประหยัดได้เท่าไหร่หรือทำเงินได้เท่าไหร่
- ภาครัฐในอาเซียนเดินตามประเทศใหญ่ คือดูประเทศที่มีอำนาจมากกว่าเป็นตัวตั้ง แล้วค่อยปรับให้เข้ากับวัฒนธรรมท้องถิ่น คำแนะนำของเขาคือให้ใจเย็นกับภาครัฐ และคาดว่าจะเห็นความต่างขนาดใหญ่มากในอีกปีสองปีข้างหน้า ตอนที่รัฐบาลอาเซียนทุกประเทศพยายามเอา AI ไปใช้
Komes ตอบจากที่นั่งของธนาคารที่ต้องดูแลทั้งตัวเองและลูกค้า SME
- สำหรับวิศวกร เริ่มที่ responsible AI ตั้งแต่ต้น เวลาเลือกของ open source ต้องเข้าใจว่าของที่หยิบมาคืออะไร และรับผิดชอบคุณภาพของผลลัพธ์ที่ออกมาเอง
- สำหรับ SME ที่ไม่มีวิศวกรและไม่มีไอที เขาตอบว่าคนกลุ่มนี้ไม่ได้พึ่งวิศวกร และไม่ได้พึ่งรัฐ เขาพึ่งตัวเอง ความสามารถขั้นต่ำที่ต้องมีคือการตรวจคำตอบเป็น เวลาโมเดลตอบมา ต้องดูออกว่านี่คือคำตอบที่ถูกของคำถามที่ถามไปหรือเปล่า และต้องรู้ว่านี่โมเดลของบริษัทไหน ซอฟต์แวร์ของใคร ทั้งหมดนี้สรุปลงที่คำเดียวคือ AI literacy ระดับพื้นฐาน เท่ากับรู้วิธีใช้ Google บวกความสามารถตรวจสิ่งที่ได้กลับมา
- พื้นฐานธุรกิจไม่ได้เปลี่ยน มันแค่เร็วขึ้นและซับซ้อนขึ้น SME ที่อยากได้รายได้เพิ่มหรือต้นทุนลดยังต้องการ AI อยู่ดี แต่ต้องใช้อย่างรับผิดชอบและเข้าใจพอที่จะตรวจก่อนเชื่อ
ช่วงที่ 7โซ่ที่ไม่มีใครขยับคนเดียวได้
รอบปิดเราถาม 2 ข้อ ข้อแรกว่าใน 12 เดือนข้างหน้า แต่ละคนจะทำอะไรที่ช่วยให้เรื่องนี้ขยับ ข้อสองว่าต้องการอะไรจากคนอื่นบนเวที ของที่หยิบไปใช้ได้ทันทีมี 5 อัน
ให้ AI ลงบนรางที่วิ่งอยู่แล้ว Tuan แนะนำองค์กรไว้ว่าไปดูรางงานที่วิ่งอยู่ในบริษัท เลือกเส้นที่ง่ายที่สุด เอา AI ลงตรงนั้นก่อน วัดผล แล้วค่อยเขียนนโยบายจากผลที่ได้ ไม่ใช่เขียนนโยบายก่อนแล้วค่อยหาที่ลง
เปลี่ยนจากสั่งงาน เป็นบอกผลลัพธ์ที่ต้องการ Pin Siang เล่าเทคนิคที่เขาใช้เอง แทนที่จะสั่งว่าทำ PowerPoint หน้านี้ ใส่อันนี้ ใส่อันนั้น ให้บอกไปว่างานนำเสนอชิ้นนี้ต้องปิดลูกค้าให้ได้ แล้วถามกลับว่าเราควรทำอะไรบ้าง เขาบอกว่านี่เป็นช่วงเวลาที่ดีที่สุดที่จะเริ่ม และชี้ไปที่บริษัทที่มีคนอยู่คนเดียว ซึ่งตอนนี้ทำโมเดลธุรกิจที่เมื่อก่อนเป็นไปไม่ได้ ประโยคปิดของเขาคือ get hungry and get foolish สำนวนของเขาเองจากประโยคของ Steve Jobs
งานที่ AI ทำแทนได้ ออกไปไกลกว่างานหน้าจอแล้ว Pin Siang เล่าถึงเพื่อนในวงการโซลาร์ที่ใช้ AI หาทำเลติดตั้งแผง งานราว 90% เป็นงานของ agent ส่วนคนที่เหลือแค่ช่วยให้บริษัทติดตั้งแผงให้เสร็จ เขาเสริมว่าการเปิดให้ทุกคนเข้าถึง AI ได้จากฝั่งภาครัฐ เป็นจุดเริ่มที่ดี อ่านต่อเรื่องนี้ได้ที่ AI ที่ออกจากจอไปอยู่ในของจริง
ดูให้ออกว่า AI ตัวไหนดีไม่ดี Tuan เทียบว่าคลื่นคลาวด์สร้างวิศวกรคลาวด์กับใบรับรองขึ้นมาทั้งรุ่น ส่วน AI เป็นคลื่นที่ใหญ่กว่าคลาวด์ และจะไม่มีวิศวกรคนไหนรอดได้ถ้าไม่รู้เรื่องนี้ ไม่ใช่ในระดับอัลกอริทึม แต่ในระดับใช้เป็น และดูออกว่าตัวไหนดีตัวไหนไม่ดี ในวันที่ทุกซอฟต์แวร์ติดป้ายว่าฉลาด คำปิดของเขาคืออย่าเครียดกับมันมาก แค่เรียนรู้และใช้ทุกวัน แล้วความรู้จะซึมเข้าไปในงานเอง
ดูอยู่เฉยๆ ไม่ทำให้เข้าใจ Komes ทิ้งประโยคที่ตรงกับหัวข้อของเวทีไว้ว่าต้องลงมือ ทดลอง ทำ PoC และที่สำคัญที่สุดคือต้องเข้าใจว่าโมเดลพลาดตรงไหนหรือไม่พลาดตรงไหน แล้วเรียนจากผลลัพธ์ที่ได้ วนกลับไปเรียนใหม่ให้ดีขึ้น
พอวางคำตอบทั้งหมดเรียงกัน สิ่งที่โผล่ขึ้นมาชัดคือรูปร่างของปัญหา องค์กรใหญ่แก้เรื่องคนกับการจัดสรรงบได้ แต่กดต้นทุนต่อ token ลงไม่ได้ คนที่ทำให้โมเดลรันได้ดึงประสิทธิภาพออกจากฮาร์ดแวร์ได้ แต่เขียนนโยบายให้บริษัทอื่นไม่ได้ ส่วนคนที่กดต้นทุนการเสิร์ฟลงมา ทำได้แค่เปลี่ยนตัวเลขในสมการ บริษัทไทยที่ตั้งงบ 500,000 ดอลลาร์ต่อเดือนแล้วใช้หมดตั้งแต่กลางเดือน ไม่ได้รอราคาต่อ token ที่ถูกลง แต่รอคนที่จะบอกว่าใครใช้ได้เท่าไหร่ ซึ่งเป็นงานที่คนขายของทำแทนให้ไม่ได้
เราเลยปิดเวทีด้วยประโยคเดียวว่า AI adoption ไม่ได้อยู่ที่ใครมีโมเดลดีที่สุด มันเกิดตอนที่เทคโนโลยี องค์กร และเศรษฐศาสตร์ ขยับไปด้วยกัน และไม่มีส่วนไหนของโซ่นี้ที่ขยับมันได้ลำพัง
เวทีนี้เกิดขึ้นได้เพราะทีม vLLM Thailand พางานระดับนี้เข้ามาจัดในกรุงเทพ และคุณ Job Natdhanai จาก AGICAFET ไว้วางใจให้เรามาดำเนินรายการ
ที่มาและอ้างอิง
- เนื้อหาทั้งหมดมาจากเวที "AI Adoption in Thailand: What Actually Works" งาน vLLM Bangkok Day 2026 สตรีมวันที่ 6 ก.ย. 2026 ผู้เขียนเป็นผู้ดำเนินรายการบนเวทีนั้นเอง
- vLLM Bangkok Day 2026 หน้าเว็บของงาน
- สตรีมเต็มของงาน (Creatorsgarten)