“ทำสัญญา ChatGPT แบบองค์กรไปแล้ว แล้วขั้นต่อไปควรทำอะไร” นี่คือคำถามเกี่ยวกับการสร้างระบบ AI ภายในองค์กรที่บริษัทญี่ปุ่นซึ่งมีฐานการผลิตในประเทศไทยส่งเข้ามาปรึกษามากที่สุดตั้งแต่เข้าปี 2026 แชตทั่วไปใช้งานได้จริง แต่มันไม่อ่านแบบวิศวกรรมของเรา ไม่อ่านคู่มือขั้นตอนการทำงานของเรา และไม่รู้ประวัติของเสียของเรา ครั้นจะสร้างทุกอย่างขึ้นมาเองทั้งหมดก็ไม่มีกำลังพอ คำว่าการสร้างระบบ AI ภายในองค์กรครอบคลุมขอบเขตที่กว้างมาก และระหว่างการพัฒนาเอง การใช้ SaaS และรูปแบบไฮบริด ทั้งเม็ดเงินลงทุนและโครงสร้างทีมต่างกันคนละหลัก บทความนี้จะเรียบเรียงเกณฑ์ตัดสินว่าควรสร้างเองหรือควรซื้อ โรดแมปการสร้างทีละขั้น โครงสร้างต้นทุนแยกตามชั้น และประเด็นเฉพาะของฐานการผลิตในประเทศไทย ตามลำดับเดียวกับที่ต้องตั้งโครงการขึ้นจริง
การสร้างระบบ AI ภายในองค์กรเปลี่ยนจาก “จะลองไหม” เป็น “จะสร้างอย่างไร”
ตัวเลขที่บอกว่าตอนนี้เรายืนอยู่ตรงไหน
การใช้ generative AI ภายในองค์กรกำลังก้าวพ้นขั้นของการทดลองแล้ว สถิติปี 2026 ที่รวบรวมสภาพการนำ AI ไปใช้ในภาคอุตสาหกรรมระบุว่า 55% ของภาคการผลิตได้นำ use case ของ AI อย่างน้อยหนึ่งกรณีขึ้นใช้งานจริงในระดับ production แล้ว อย่างไรก็ตาม ความแตกต่างระหว่างประเภทอุตสาหกรรมสูงมาก อัตราการขึ้นใช้งานจริงอยู่ที่ 85% ในกลุ่มยานยนต์และอากาศยาน 78% ในกลุ่มน้ำมันก๊าซและพลังงาน และ 60% ในกลุ่มอาหารและเครื่องดื่ม ขณะที่การผลิตทั่วไปอยู่เพียง 45% การสำรวจชุดเดียวกันยังระบุว่าโครงการนำร่อง AI สำหรับภาคอุตสาหกรรมราว 30% จบลงโดยไม่ขยายออกไปพ้นเครื่องจักรเครื่องแรก ขณะที่ 64% ขององค์กรรายงานว่าได้ ROI เป็นบวกภายใน 12 เดือน
เมื่อวางตัวเลขสองชุดนี้ไว้ข้างกัน แก่นของการสร้างระบบ AI ภายในองค์กรก็ปรากฏขึ้น โครงการที่คืนทุนได้ภายใน 12 เดือน กับโครงการที่ใช้เวลาหนึ่งปีแล้วจบลงเพียงการทดลองกับเครื่องจักรหนึ่งเครื่อง กำลังเดินคู่ขนานกันอยู่ภายใต้ชื่อเดียวกันว่าการนำ AI มาใช้ สิ่งที่สร้างความต่างไม่ใช่สมรรถนะของโมเดล แต่คือวิธีประกอบโครงการขึ้นมา
เมื่อหันมามองตลาดไทย มีการคาดการณ์ว่ามูลค่าตลาด AI สำหรับภาคการผลิตจะเติบโตจาก 1.15 พันล้านดอลลาร์สหรัฐในปี 2025 ไปเป็น 4.80 พันล้านดอลลาร์สหรัฐในปี 2031 หรือคิดเป็นอัตราเติบโตเฉลี่ยต่อปี 26.6% สำหรับฐานการผลิตของทุนญี่ปุ่นในประเทศไทย ตัวเลขนี้ยังหมายความว่าเราเข้าสู่ช่วงเวลาที่คู่แข่งและซัพพลายเออร์ท้องถิ่นเริ่มลงทุนใน AI ไปพร้อมกัน
ขอบเขตที่บทความนี้ครอบคลุมและไม่ครอบคลุม
เนื่องจากหัวข้อการสร้างระบบ AI ภายในองค์กรนั้นกว้าง จึงขอระบุจุดยืนของบทความนี้ไว้ก่อน สิ่งที่เราจะพูดถึงคือการตัดสินใจในฐานะโครงการหนึ่ง กล่าวคือ บริษัทควรสร้างเองหรือไม่ตั้งแต่ต้น หากสร้างจะสร้างอะไรก่อนหลัง จะจัดสรรงบประมาณเท่าใดให้ชั้นไหน และใครมีสิทธิ์ใช้งานอะไรบ้าง ทั้งหมดนี้คือการตัดสินใจเชิงออกแบบ
ภาพรวมของการนำ generative AI มาใช้ทั้งกระบวนการ รวมถึงขั้นตอนการวางกฎระเบียบภายในองค์กร เราได้อธิบายไว้แล้วในแนวทางและค่าใช้จ่ายในการนำ generative AI มาใช้ บทความนี้จึงเลี่ยงการทับซ้อน และจะโฟกัสเฉพาะการตัดสินใจของโครงการสร้างระบบ
การสร้างระบบ AI ภายในองค์กรคือการสร้างอะไรกันแน่
แบ่งออกเป็น 5 ชั้นเพื่อให้มองเห็นภาพเดียวกัน
เวลาคำว่าระบบ AI ภายในองค์กรถูกพูดถึงในห้องประชุม สิ่งที่แต่ละคนนึกภาพอยู่ในหัวมักไม่ตรงกันเลย บางคนนึกถึงแชตบอตสำหรับพนักงาน บางคนนึกถึงฟังก์ชันสรุปข้อความที่ฝังอยู่ในระบบหลัก บางคนนึกถึงตัวโมเดลที่รันอยู่บนเซิร์ฟเวอร์ของบริษัทเอง ความไม่ตรงกันนี้ทำให้การถกเรื่องงบประมาณหมุนอยู่กับที่
เพื่อให้การคุยกันบรรจบกันได้ เราจะแยกระบบ AI ภายในองค์กรออกเป็น 5 ชั้น
- ชั้นฐานการประมวลผล กำหนดว่าจะรันโมเดลที่ไหน มีทางเลือกทั้ง API บนคลาวด์ เทนแนนต์เฉพาะ หรือสภาพแวดล้อม inference บนเซิร์ฟเวอร์ของบริษัทเอง
- ชั้นข้อมูล รวบรวม จัดระเบียบ และติดข้อมูลสิทธิ์การเข้าถึงให้กับข้อมูลภายในที่จะให้ AI อ่าน เช่น แบบวิศวกรรม คู่มือขั้นตอนการทำงาน รายงานของเสีย บันทึกการประชุม อีเมล และมาสเตอร์ของระบบหลัก
- ชั้นค้นหาและอ้างอิง กลไกที่ตัดสินว่าคำถามหนึ่งควรไปอ้างอิงส่วนไหนของข้อมูลภายใน แล้วส่งส่วนนั้นไปเป็นหลักฐาน สิ่งที่เรียกกันว่า RAG อยู่ในชั้นนี้
- ชั้นแอปพลิเคชัน หน้าจอที่ผู้ใช้สัมผัสจริงและการฝังเข้าไปในงานที่มีอยู่เดิม ไม่จำเป็นต้องมีแค่หน้าจอแชตเสมอไป
- ชั้นปฏิบัติการและธรรมาภิบาล สิทธิ์ว่าใครเห็นอะไรได้ ล็อกการใช้งาน การประเมินคุณภาพคำตอบ การอบรม และการตามให้ทันเมื่อโมเดลมีการอัปเดต
โครงการสร้างระบบ AI ภายในองค์กรมักมีปัญหาเพราะคนคุยเรื่องราคาก่อนคุยเรื่องชั้น ถ้าเทียบเฉพาะชั้นฐานการประมวลผล ทางเลือกมีอยู่ไม่มาก แต่ค่าใช้จ่ายส่วนใหญ่กลับไปเกิดที่ชั้นข้อมูลและชั้นปฏิบัติการกับธรรมาภิบาล
ในบรรดาชั้นเหล่านี้ รายละเอียดเชิงเทคนิคและกรอบค่าใช้จ่ายของชั้นค้นหาและอ้างอิง เราอธิบายไว้อย่างละเอียดในค่าใช้จ่ายและแนวทางการสร้าง RAG บทความนี้จะมองชั้นดังกล่าวในมุมว่าควรลงมือเมื่อไรในภาพรวมของโครงการ และควรกันงบประมาณไว้เท่าไร
ต่างจากการทำสัญญา SaaS ตรงจุดชี้ขาดใด
ความต่างระหว่างการทำสัญญาใช้ generative AI แบบ SaaS ทั่วไป กับการสร้างระบบ AI ภายในองค์กร ไม่ได้อยู่ที่จำนวนฟังก์ชัน แต่อยู่ที่ว่า ข้อมูลของบริษัทเราเข้าไปอยู่ในกลไกนั้นหรือไม่
การทำสัญญาแชตทั่วไปเปรียบได้กับการแจกที่ปรึกษาที่เก่งมากแต่ไม่รู้อะไรเกี่ยวกับบริษัทเราเลยให้พนักงานทุกคน งานเขียนทั่วไปและงานแปลจะเห็นคุณค่าทันที แต่มันตอบคำถามที่เกิดบ่อยที่สุดในหน้างานผลิตไม่ได้ เช่น ของเสียตัวนี้เมื่อปีที่แล้วเคยออกมาคล้ายกันหรือไม่ หรือเกณฑ์การตรวจรับของลูกค้ารายนี้กำหนดไว้กี่มิลลิเมตร งานที่ทำให้มันตอบได้คือชั้นข้อมูลกับชั้นค้นหาและอ้างอิง และจากจุดนั้นไปคือเนื้อแท้ของการสร้างระบบ AI ภายในองค์กร
วิธีเลือกระหว่างพัฒนาเอง SaaS และไฮบริด
นิยามทางเลือกทั้งสาม
ขอปรับนิยามให้ตรงกันก่อน
แบบเน้น SaaS คือการทำสัญญาใช้บริการ generative AI ของผู้ให้บริการภายนอก แล้วใช้ฟังก์ชันอัปโหลดไฟล์หรือเชื่อมข้อมูลภายในที่เตรียมมาให้แล้ว สิ่งที่ต้องสร้างแทบไม่มี งานที่แท้จริงคือการตั้งค่าและการวางกฎการใช้งาน
แบบพัฒนาเอง คือการใช้ API ของโมเดลหรือฐาน inference ในสภาพแวดล้อมของบริษัทเป็นพื้น แล้วประกอบการเชื่อมข้อมูล การค้นหา หน้าจอ และสิทธิ์การเข้าถึงทั้งหมดขึ้นตามการออกแบบของบริษัทเอง คำว่าพัฒนาเองในที่นี้ไม่ได้จำกัดอยู่แค่ฝ่ายไอทีภายในเขียนโค้ดเองทั้งหมด แต่รวมถึงรูปแบบที่บริษัทเป็นผู้กำหนดทิศทางของสเปกเอง แล้วสร้างไปด้วยกันกับพาร์ตเนอร์พัฒนาภายนอก
แบบไฮบริด คือการยกงานที่ใช้ได้ทั่วไปให้ SaaS แล้วสร้างเฉพาะงานที่ต้องใช้ข้อมูลภายในขึ้นเป็นแอปพลิเคชันที่บริษัทออกแบบเอง ณ ปี 2026 รูปแบบนี้คือจุดลงตัวที่สมจริงที่สุดสำหรับฐานการผลิตของทุนญี่ปุ่นในประเทศไทย
เปรียบเทียบทั้งสามรูปแบบ
| แกนเปรียบเทียบ | แบบเน้น SaaS | แบบพัฒนาเอง | แบบไฮบริด |
|---|---|---|---|
| ระยะเวลาเริ่มใช้งานโดยประมาณ | 2 สัปดาห์ถึง 1 เดือน | 6 เดือนถึง 12 เดือน | 2 เดือนถึง 4 เดือน |
| ค่าใช้จ่ายเริ่มต้น | แทบไม่เกิดขึ้น | สูง กระจุกตัวที่ชั้นข้อมูลและการพัฒนา | ปานกลาง แปรผันตามจำนวนงานเป้าหมาย |
| ค่าใช้จ่ายต่อเนื่อง | แปรผันตามจำนวนผู้ใช้ | เน้นที่โครงสร้างพื้นฐานและการบำรุงรักษา จำนวนคนมีผลน้อย | เป็นผลรวมของทั้งสองแบบ |
| ระดับการใช้ประโยชน์จากข้อมูลภายใน | จำกัดอยู่ในขอบเขตของฟังก์ชันมาตรฐาน | ลึกได้ไม่มีเพดานตามการออกแบบ | เทียบเท่าแบบพัฒนาเองหากจำกัดเฉพาะงานเป้าหมาย |
| การเชื่อมต่อกับระบบงาน | ขึ้นกับปลายทางที่ผู้ให้บริการเตรียมไว้ | เข้าถึงได้ถึงระบบหลักและข้อมูลจากเครื่องจักร | เข้าถึงได้เฉพาะงานเป้าหมาย |
| การควบคุมที่ตั้งของข้อมูล | เป็นไปตามการออกแบบของผู้ให้บริการ | บริษัทกำหนดเองได้ | เลือกใช้ต่างกันได้ตามแต่ละงาน |
| ความง่ายในการถอนตัวหรือเปลี่ยนระบบ | ง่าย | ยาก สินทรัพย์ยังอยู่แต่ค่าแรงในการย้ายสูง | พิจารณาแยกได้ทีละงาน |
| ทีมงานภายในที่จำเป็น | ผู้ดูแลระบบราว 1 คน | ต้องมีทีมขับเคลื่อนแบบเต็มเวลา | ผู้ขับเคลื่อนแบบควบตำแหน่งบวกพาร์ตเนอร์ภายนอก |
ตารางนี้ไม่ได้บอกว่าแบบไหนดีกว่า แต่เป็นรายการว่าเรายอมรับข้อจำกัดชุดไหนได้ แบบเน้น SaaS เร็วแต่ตื้น แบบพัฒนาเองลึกแต่ช้าและหนัก ส่วนแบบไฮบริดคือแนวคิดที่แยกส่วนที่ต้องเร็วออกจากส่วนที่ต้องลึกตามแต่ละงาน
การเลือกเครื่องมือ generative AI ตัดสินด้วยเส้นแบ่ง ไม่ใช่ตารางฟังก์ชัน
เวลาพิจารณาการเลือกเครื่องมือ generative AI หลายบริษัททำตารางเปรียบเทียบฟังก์ชันขึ้นมา สรุปความได้ไหม รองรับภาษาญี่ปุ่นและภาษาไทยหรือไม่ อ่านไฟล์ได้ครั้งละกี่ไฟล์ แต่สิ่งที่ตัดสินจริงในภาคการผลิตไม่ใช่ฟังก์ชัน หากเป็นเส้นแบ่ง 4 เส้นต่อไปนี้
เส้นที่หนึ่ง ข้อมูลของบริษัทไปอยู่ที่ไหน ไฟล์ที่อัปโหลดขึ้นไปถูกประมวลผลและจัดเก็บในประเทศใดและรีเจียนใด สัญญาระบุว่าไม่ถูกนำไปใช้เทรนโมเดลหรือไม่ หากพนักงานขายให้คำมั่นด้วยวาจาเกินกว่าที่ตรวจสอบได้จากเอกสารสำหรับผู้ดูแลระบบที่ผู้ให้บริการเผยแพร่ ขอให้ยืนยันใหม่เป็นลายลักษณ์อักษรทุกครั้ง
เส้นที่สอง ความละเอียดของสิทธิ์การเข้าถึง การออกแบบเปิดช่องให้ฝ่ายจัดซื้ออ่านแบบวิศวกรรมของฝ่ายวิศวกรรมการผลิตได้หรือไม่ SaaS ทั่วไปจำนวนมากถือสิทธิ์ได้แค่ระดับผู้อัปโหลดกับปลายทางที่แชร์เท่านั้น ในบริษัทที่ขอบเขตการเปิดอ่านเอกสารภายในแยกตามแผนกและตามกระบวนการ จุดเดียวนี้ก็ตัดทางเลือกที่ใช้ SaaS อย่างเดียวออกไปแล้ว
เส้นที่สาม ระยะที่เอื้อมถึงระบบเดิม ข้อมูลผลการผลิตจากระบบบริหารการผลิต ข้อมูลอนุกรมเวลาที่ส่งขึ้นมาจากเครื่องจักร บันทึกการตรวจสอบคุณภาพ หากแตะสิ่งเหล่านี้ไม่ได้ AI ก็ตอบได้เพียงสิ่งที่เขียนอยู่ในเอกสารเท่านั้น
เส้นที่สี่ มีบันทึกหลงเหลือหรือไม่ ใครถามอะไรเมื่อไร และ AI ตอบโดยอ้างอิงอะไร เมื่อถูกขอคำอธิบายในการตรวจประเมินจากลูกค้าหรือการตรวจสอบภายใน หากไม่มีล็อก เราก็อธิบายได้ไม่เกินว่า AI บอกมาแบบนั้น
ทางเลือกด้านความปลอดภัยและโครงสร้างพื้นฐาน พร้อมค่าใช้จ่ายของแต่ละแบบ เราเปรียบเทียบไว้ 3 โครงสร้างในสภาพแวดล้อม generative AI ที่ปลอดภัยปี 2026 บทความนี้จะเน้นว่าการตัดสินเส้นแบ่งเหล่านี้ควรถูกล็อกไว้ในขั้นตอนใดของโครงการและล็อกอย่างไร
วิธีเดินโครงการสร้างระบบ AI ภายในองค์กร
สาเหตุที่การสร้างระบบ AI ภายในองค์กรมักลงเอยด้วยการใช้เวลาหนึ่งปีแล้วจบที่โครงการนำร่องเดียว ส่วนใหญ่คือปัญหาเรื่องลำดับ หลายกรณีเริ่มจากการพิสูจน์เทคโนโลยี แล้วผลักการเลือกงานเป้าหมายกับการออกแบบสิทธิ์ไปไว้ทีหลัง ต่อไปนี้คือลำดับที่ไปถึงการใช้งานจริงได้ง่ายกว่า
ขั้นที่ 0 สำรวจงานทั้งหมดและคัดเหลือ 3 งาน
สิ่งแรกที่ต้องทำไม่ใช่การเลือกเครื่องมือ แต่คือการสำรวจงาน ให้แต่ละแผนกกวาดรายการงานที่ใช้เวลานานในการค้นหาเอกสาร งานที่มีคำถามเดิมซ้ำ ๆ เข้ามา และงานที่มีการแปลกับการสรุปความคั่นอยู่ สิ่งที่โผล่ขึ้นมาทุกครั้งในโรงงานญี่ปุ่นในประเทศไทยคือการหาตำแหน่งที่เกี่ยวข้องในสเปกของลูกค้า การหาเคสของเสียในอดีตที่คล้ายกัน การเทียบคู่มือขั้นตอนการทำงานฉบับภาษาไทยกับฉบับภาษาญี่ปุ่น และการสรุปรายงานประจำวัน
จากรายการที่กวาดได้ ให้คัดงานที่จะลงมือก่อนเหลือ 3 งาน เกณฑ์การคัดมี 3 ข้อ คือความถี่ต้องสูง เอกสารที่เป็นหลักฐานต้องอยู่ในรูปดิจิทัลแล้ว และคนต้องตรวจสอบความถูกต้องของคำตอบได้ การเลือกงานที่ถ้าสำเร็จแล้วจะมีอิมแพ็กต์ใหญ่มาเป็นงานแรกคือสูตรสำเร็จของความล้มเหลว เพราะงานที่อิมแพ็กต์ยิ่งใหญ่ ข้อมูลที่เป็นหลักฐานยิ่งฝังอยู่ในกระดาษ และการตัดสินว่าคำตอบถูกหรือผิดยิ่งกินเวลาผู้เชี่ยวชาญ
ขั้นที่ 1 สำรวจที่ตั้งของข้อมูลและสิทธิ์การเข้าถึง
สำหรับ 3 งานที่เลือกไว้ ให้ระบุที่ตั้งของเอกสารและข้อมูลที่ AI จำเป็นต้องอ่าน อยู่ในโฟลเดอร์ไหนของไฟล์เซิร์ฟเวอร์ อยู่บนไดรฟ์ที่แชร์กัน อยู่ในตารางไหนของระบบหลัก หรืออยู่ในเครื่องคอมพิวเตอร์ส่วนตัวของใครบางคน
พร้อมกันนั้นให้บันทึกไว้ด้วยว่าปัจจุบันใครเห็นข้อมูลนั้นได้บ้าง หากสร้างระบบ AI ภายในองค์กรโดยไม่ทำงานนี้ AI จะกลายเป็นช่องลัดของสิทธิ์ เนื้อหาในโฟลเดอร์ที่แต่เดิมมีแค่ฝ่ายวิศวกรรมการผลิตเปิดได้ จะถูก AI สรุปคืนให้ใครก็ได้ นี่ไม่ใช่ความบกพร่องทางเทคนิค แต่คือการออกแบบที่ขาดหายไป อนึ่ง มีไม่น้อยที่ในขั้นนี้เองบริษัทจะพบว่าไม่มีใครรู้ว่าสิทธิ์ของโฟลเดอร์ตั้งไว้อย่างไร นั่นเองก็คือการค้นพบประเด็นที่ต้องจัดการก่อนจะพูดถึง AI
ขั้นที่ 2 ตัดสินรูปแบบและล็อกงบประมาณโดยประมาณ
เมื่อถือผลของขั้นที่ 0 และขั้นที่ 1 มาแล้ว จึงค่อยตัดสินระหว่าง SaaS พัฒนาเอง และไฮบริดเป็นครั้งแรก ถึงตรงนี้วัตถุดิบสำหรับตัดสินครบแล้ว มีงานเป้าหมาย 3 งาน รู้ที่ตั้งของข้อมูลที่ต้องใช้ และเห็นว่าสิทธิ์แยกกันอย่างไร
สิ่งที่ต้องตัดสินตรงนี้ไม่ใช่แค่รูปแบบ แต่รวมถึงการจัดสรรงบประมาณแยกตามชั้นด้วย ถ้าอนุมัติยอดรวมเป็นตัวเลขเดียว งบจะเอียงไปทางการพัฒนาแล้วการจัดระเบียบข้อมูลจะผอมลง วิธีที่ปลอดภัยกว่าคือแบ่งกรอบงบตามโครงสร้างต้นทุนรายชั้นที่จะกล่าวถึงต่อไป แล้วขออนุมัติเป็นกรอบ ๆ ไว้ล่วงหน้า
ขั้นที่ 3 ลงมือทำ 1 งานและตั้งเกณฑ์การประเมิน
เลือกทำ 1 งานจาก 3 งานก่อน สิ่งสำคัญที่สุดในขั้นนี้คือการกำหนดเกณฑ์การประเมินให้เสร็จก่อนลงมือพัฒนา
รูปธรรมคือเตรียมคำถามที่คาดว่าจะเกิดขึ้นไว้ 30 ถึง 50 ข้อ แล้วให้คนเตรียมคำตอบที่ถูกต้องพร้อมตำแหน่งในเอกสารที่เป็นหลักฐานของคำตอบนั้นไว้ล่วงหน้าทุกข้อ หลังพัฒนาเสร็จจึงตัดสินด้วยอัตราการตอบถูกและความแม่นยำของหลักฐานที่ระบบยกมาอ้าง หากเดินหน้าขึ้นใช้งานจริงด้วยความรู้สึกว่าลองแล้วดูดี เมื่อภายหลังมีคนตั้งคำถามเรื่องคุณภาพ เราจะไม่มีเกณฑ์ให้ย้อนกลับไปดู
สถิติของ AI สำหรับภาคอุตสาหกรรมรายงานว่าในขั้นการติดตั้งช่วงต้น ผลการตรวจจับสูงสุดถึง 40% อาจเป็นการแจ้งเตือนผิดพลาด แม้การตรวจจับความผิดปกติกับการค้นหาเอกสารจะมีธรรมชาติต่างกัน แต่ข้อชี้แนะร่วมกันคืออย่านำผลลัพธ์ก่อนการปรับจูนไปแสดงต่อหน้างานตรง ๆ หากนำไปแสดงโดยไม่มีสมมติฐานข้อนี้ เดโมครั้งแรกจะทำให้เสียความเชื่อถือและไม่มีใครกลับมาใช้อีกเลย ประเมินและปรับจูนก่อน แล้วจึงส่งออกสู่หน้างาน ลำดับนี้สลับกันไม่ได้
ขั้นที่ 4 ขยายสู่หน้างานและต่อยอดไปยังอีก 2 งานที่เหลือ
เมื่องานแรกผ่านเกณฑ์การประเมินแล้ว ให้เริ่มใช้งานจริงในแผนกที่จำกัดขอบเขตไว้ สิ่งที่ต้องเตรียมตอนขยายไม่ใช่คำอธิบายวิธีใช้ แต่คือเส้นแบ่งระหว่างสถานการณ์ที่ใช้คำตอบของ AI ได้เลย กับสถานการณ์ที่ต้องกลับไปตรวจเอกสารต้นฉบับเสมอ ถ้าขยายไปโดยที่เส้นแบ่งนี้ยังคลุมเครือ หน้างานจะแกว่งไปสุดขั้วใดขั้วหนึ่ง คือเชื่อกันหมดทุกคน หรือไม่ใช้กันเลยสักคน
ฐานที่สร้างไว้ในงานแรก ได้แก่ การเชื่อมข้อมูล การค้นหา สิทธิ์ และกลไกจัดเก็บล็อก สามารถนำกลับมาใช้ซ้ำได้ตั้งแต่งานที่สองเป็นต้นไป ผลตอบแทนต่อการลงทุนของการสร้างระบบ AI ภายในองค์กรเริ่มดีขึ้นจากจุดนี้ พูดกลับกันคือถ้าหยุดที่งานเดียว เราจะจบลงในสภาพที่แพงที่สุด
ขั้นที่ 5 ทำให้อยู่ตัวและตามให้ทันการอัปเดตโมเดล
ทุกครึ่งปี ให้ดูล็อกการใช้งานแล้วแยกฟังก์ชันที่ไม่มีคนใช้ออกจากฟังก์ชันที่มีคนใช้ ฟังก์ชันที่ไม่มีคนใช้ให้ตัดทิ้ง นอกจากนี้ เนื่องจากโมเดลพื้นฐานมีการอัปเดตปีละหลายครั้ง ให้กำหนดแนวปฏิบัติว่าจะรันชุดคำถามที่สร้างไว้ในขั้นที่ 3 ใหม่ทุกครั้งที่มีการอัปเดต หากไม่มีการทดสอบย้อนกลับนี้ วันหนึ่งคุณภาพคำตอบเปลี่ยนไปแล้วจะไม่มีใครสังเกตเห็นเลย

แยกค่าใช้จ่ายของการสร้างระบบ AI ภายในองค์กรออกเป็นรายชั้น
จับตัวแปรที่ทำให้ค่าใช้จ่ายขยับให้ได้ก่อน
ใบเสนอราคาของการสร้างระบบ AI ภายในองค์กรต่างกันได้คนละหลัก ทั้งที่ใช้ชื่อเดียวกันว่าแชตบอต AI ภายในองค์กร ตัวการหลักของความผันผวนมี 4 อย่าง
- สภาพความพร้อมของข้อมูลเป้าหมาย หากเป็นดิจิทัลแล้ว มีกฎการตั้งชื่อ และระบุฉบับล่าสุดได้ ชั้นข้อมูลจะเบา แต่ถ้ากระดาษ ไฟล์ PDF สแกน และหลายเวอร์ชันปะปนกันอยู่ ชั้นนี้จะกลายเป็นรายการค่าใช้จ่ายที่ใหญ่ที่สุด
- ความซับซ้อนของสิทธิ์ ถ้าพนักงานทุกคนเห็นของชุดเดียวกันได้ก็ง่าย แต่ยิ่งแยกตามแผนก ตามกระบวนการ และตามลูกค้ามากเท่าไร ค่าแรงในการออกแบบและตรวจสอบก็ยิ่งเพิ่ม
- จำนวนเส้นการเชื่อมต่อกับระบบเดิม จะเชื่อมกี่เส้นในบรรดาระบบบริหารการผลิต คุณภาพ เครื่องจักร และทรัพยากรบุคคล
- จำนวนผู้ใช้และความถี่ในการใช้ ตรงนี้แทบเป็นตัวกำหนดค่าใช้จ่ายต่อเนื่องทั้งหมด
แสดงโครงสร้างต้นทุนรายชั้นด้วยการคำนวณจากโมเดลสมมติ
เพื่อให้เห็นเป็นรูปธรรม เราจะคำนวณจากฐานการผลิตสมมติ สมมติฐานทั้งหมดจะระบุไว้ชัดเจน ผู้อ่านสามารถแทนที่ด้วยตัวเลขของบริษัทตนเองได้ สมมติฐานคือ ฐานการผลิตของทุนญี่ปุ่นในจังหวัดชลบุรี พนักงาน 400 คน ผู้ใช้ AI 120 คน งานเป้าหมาย 3 งาน เอกสารภายในส่วนสำคัญเป็นดิจิทัลแล้วและเชื่อมกับระบบหลัก 1 ระบบ สกุลเงินเป็นบาท
| ชั้น | งานที่เกิดขึ้นในช่วงเริ่มต้น | ค่าใช้จ่ายเริ่มต้นโดยประมาณ | ค่าดำเนินการรายปีโดยประมาณ |
|---|---|---|---|
| ชั้นฐานการประมวลผล | ตัดสินรูปแบบการใช้โมเดล จัดโครงสร้างเทนแนนต์และเครือข่าย | 200,000 ถึง 500,000 | ส่วนที่คิดตามปริมาณการใช้ 300,000 ถึง 700,000 |
| ชั้นข้อมูล | รวบรวมเอกสารเป้าหมาย จัดระเบียบ จัดการเวอร์ชัน ติดข้อมูลสิทธิ์ ดึงข้อมูลจากระบบหลัก | 500,000 ถึง 1,500,000 | 200,000 ถึง 400,000 |
| ชั้นค้นหาและอ้างอิง | ตัดแบ่งเอกสารและทำดัชนี ปรับความแม่นยำของการค้นหา ออกแบบการแสดงหลักฐาน | 400,000 ถึง 900,000 | 150,000 ถึง 300,000 |
| ชั้นแอปพลิเคชัน | หน้าจอใช้งาน การฝังเข้ากับงาน การแสดงผลหลายภาษา | 400,000 ถึง 1,200,000 | 100,000 ถึง 250,000 |
| ชั้นปฏิบัติการและธรรมาภิบาล | ออกแบบสิทธิ์ ฐานจัดเก็บล็อก จัดทำชุดคำถามสำหรับประเมิน กฎการใช้งานและการอบรม | 300,000 ถึง 600,000 | 250,000 ถึง 500,000 |
เมื่อรวมยอดในตาราง กรณีเริ่มต้นแบบไฮบริดกับงานเป้าหมาย 3 งาน ค่าใช้จ่ายเริ่มต้นจะอยู่ราว 1,800,000 ถึง 4,700,000 บาท และค่าดำเนินการรายปีของส่วนที่สร้างเองจะอยู่ในช่วงราว 1,000,000 ถึง 2,150,000 บาท ยังไม่รวมค่าไลเซนส์ SaaS ทั่วไป สาเหตุที่ช่วงกว้างเกินสองเท่าไม่ใช่เพราะประมาณการหละหลวม แต่เพราะความต่างของสภาพความพร้อมด้านข้อมูลสะท้อนออกมาตรง ๆ
เมื่อเทียบยอดรวม 3 ปีของทั้งสามรูปแบบภายใต้สมมติฐานเดียวกัน ความหมายของการเลือกจะชัดขึ้น โดยสมมติว่าแบบเน้น SaaS มีค่าใช้จ่าย 1,000 บาทต่อผู้ใช้หนึ่งคนต่อเดือน
| รูปแบบ | ค่าใช้จ่ายเริ่มต้น | ค่าดำเนินการรายปี | ยอดรวม 3 ปีโดยประมาณ | สิ่งที่เหลืออยู่ในมือหลัง 3 ปี |
|---|---|---|---|---|
| แบบเน้น SaaS | แทบไม่เกิดขึ้น | ราว 1,440,000 | ราว 4,320,000 | มีเพียงสัญญาและองค์ความรู้ด้านการใช้งาน |
| แบบพัฒนาเอง | ราว 3,500,000 ถึง 6,000,000 | ราว 1,500,000 ถึง 2,500,000 | ราว 8,000,000 ถึง 13,500,000 | ฐานข้อมูล สินทรัพย์ด้านการค้นหา การฝังเข้ากับงาน และองค์ความรู้ภายใน |
| แบบไฮบริด | ราว 1,800,000 ถึง 4,700,000 | ราว 2,440,000 ถึง 3,590,000 | ราว 9,120,000 ถึง 15,470,000 | ฐานข้อมูลของงานเป้าหมาย และความพร้อมใช้งานทันทีของส่วนที่ใช้ทั่วไป |
เหตุที่ค่าดำเนินการรายปีของแบบไฮบริดดูสูงเป็นเพราะมีค่าไลเซนส์ SaaS บวกทับเข้ามา รายละเอียดคือค่าดำเนินการรายปีจากตารางรายชั้นที่ 1,000,000 ถึง 2,150,000 บาท บวกค่าไลเซนส์ SaaS สำหรับ 120 คนอีก 1,440,000 บาท อย่างไรก็ตาม ในแบบไฮบริดเราสามารถจำกัดส่วนที่ออกแบบเองไว้เฉพาะแผนกที่จำเป็น และจำกัดไลเซนส์ SaaS ให้เฉพาะจำนวนคนที่จำเป็นแทนที่จะแจกพนักงานทุกคนได้ด้วย ตารางข้างต้นวางไว้แบบระมัดระวังที่สุด คือสมมติว่าแจก SaaS ให้ครบทั้ง 120 คน
อย่าพูดถึงความคุ้มค่าด้วยชั่วโมงแรงงานอย่างเดียว
การอ้างเหตุผลให้กับการลงทุนระดับ 10,000,000 บาทใน 3 ปี ด้วยมูลค่าเวลาที่ประหยัดได้เพียงอย่างเดียวนั้นทำได้ยาก ในฐานการผลิตสมมติเดียวกัน ให้สมมติว่าการใช้ AI ช่วยลดเวลาที่ใช้ค้นเอกสารและแปลกับสรุปความลงได้คนละ 30 นาทีต่อสัปดาห์ สำหรับ 120 คนจะเท่ากับ 60 ชั่วโมงต่อสัปดาห์ คิดที่การทำงาน 48 สัปดาห์จะได้ราว 2,880 ชั่วโมงต่อปี หากคิดค่าแรงต่อชั่วโมงของพนักงานออฟฟิศที่ 300 บาท จะเท่ากับ 864,000 บาทต่อปี หรือราว 2,590,000 บาทใน 3 ปี เพียงเท่านี้ยังไม่พอ
สิ่งที่มาเติมส่วนที่ขาดคือส่วนที่ส่งผลต่อคุณภาพของการตัดสินใจ ไม่ใช่เวลา การลดการเกิดซ้ำของของเสียเพราะดึงเคสของเสียที่คล้ายกันในอดีตขึ้นมาได้ภายในไม่กี่นาที การป้องกันงานย้อนกลับจากการอ่านสเปกของลูกค้าผิด และการย่นระยะเวลาตั้งไข่เพราะความรู้ฝังลึกของพนักงานที่ลาออกถูกเก็บไว้เป็นเอกสาร สิ่งเหล่านี้ตีเป็นตัวเงินได้ยาก แต่สำหรับฐานการผลิตแล้วมีน้ำหนักมากกว่าการลดชั่วโมงแรงงาน พูดกลับกันคือ ถ้ากำลังเอา AI ไปลงกับงานที่ไม่มีผลลัพธ์แบบนี้ให้คาดหวัง การตัดสินใจลงทุนก็ไม่มีเหตุผลรองรับ

5 รูปแบบความล้มเหลวของการใช้ข้อมูลภายในกับ generative AI
เราขอเรียบเรียงความล้มเหลวที่เกิดซ้ำในหน้างานของการใช้ข้อมูลภายในกับ generative AI พร้อมสาเหตุ เนื้อในของสถิติที่ว่าโครงการนำร่อง AI สำหรับภาคอุตสาหกรรมราว 30% ไม่ขยายออกไปพ้นกรณีแรก ส่วนใหญ่อยู่ใน 5 ข้อนี้
รูปแบบที่ 1 ผลักการจัดระเบียบข้อมูลไปเป็นค่อยทำทีหลัง
นี่คือความล้มเหลวที่พบมากที่สุด เดโมทำงานได้ เพราะป้อนไฟล์ PDF สิบกว่าไฟล์ที่จัดระเบียบมาแล้วเข้าไป พอขึ้นใช้งานจริง ขอบเขตพองขึ้นเป็นหลักพันถึงหลักหมื่นไฟล์ ในนั้นมีจำนวนไม่น้อยที่ยังเป็นฉบับเก่า มีไฟล์ภาพสแกนที่ดึงตัวอักษรออกมาไม่ได้ปนอยู่ และมีไฟล์ชื่อเดียวกันแต่เนื้อหาต่างกันเรียงกันอยู่
คำตอบที่ AI คืนมาในสภาพเช่นนี้คือเนื้อหาที่ผิดในรูปแบบที่ถูกต้อง และเพราะผิดอย่างเป็นธรรมชาติ หน้างานจึงไม่ทันสังเกต ชั้นข้อมูลคือชั้นที่ต้องกันงบไว้ตั้งแต่แรก ไม่ใช่ชั้นที่ตัดได้
รูปแบบที่ 2 AI เดินผ่านสิทธิ์ไปเฉย ๆ
เป็นปัญหาที่กล่าวถึงในขั้นที่ 1 ร่างการประเมินผลพนักงาน รายละเอียดต้นทุน เงื่อนไขการค้าของลูกค้าแต่ละราย ทั้งหมดนี้อยู่ในที่เก็บเอกสารเดียวกัน แล้ว AI อ่านทั้งหมดและตอบให้ทุกคน หากรอให้เกิดอุบัติเหตุก่อนแล้วค่อยมาเติมสิทธิ์ทีหลัง จะต้องรื้อดัชนีใหม่ทั้งหมด และกินค่าแรงพอ ๆ กับการสร้างครั้งแรก
รูปแบบที่ 3 ไม่มีใครนิยามว่าอะไรคือคำตอบที่ถูก
มีรายงานขึ้นมาว่าความแม่นยำไม่ดี แต่ไม่เคยมีการตกลงว่าอะไรคือความถูกต้อง ฝ่ายพัฒนาตอบว่าคำถามลักษณะนั้นอยู่นอกขอบเขตที่คาดไว้ ส่วนหน้างานสรุปว่าใช้ไม่ได้ ถ้าจัดทำชุดคำถามอย่างที่กล่าวไว้ในขั้นที่ 3 ไว้ก่อน ความขัดแย้งนี้จะไม่เกิด ความแม่นยำจะปรับปรุงได้ก็ต่อเมื่อทำให้วัดได้เสียก่อน
รูปแบบที่ 4 หน้างานไม่ใช้
สภาพที่ผ่านไป 3 เดือนหลังเริ่มใช้ แล้วเหลือคนที่ใช้เป็นประจำอยู่แค่ผู้รับผิดชอบบางคน สาเหตุจำกัดอยู่ 3 ข้อ คือถูกวางไว้ในที่ที่หลุดจากเส้นทางการทำงานเดิม ไม่รู้ว่าคำตอบเชื่อถือได้แค่ไหน และไม่รู้ว่าจะถามอย่างไร
มาตรการรับมือคือฝังเข้าไปในระบบงาน แนบลิงก์ไปยังเอกสารที่เป็นหลักฐานไว้กับคำตอบทุกครั้ง และจัดทำประโยคคำถามที่ใช้บ่อยแผนกละ 10 ข้อแจกออกไป ข้อที่สามได้ผลมากเป็นพิเศษ เพราะผู้ใช้ส่วนใหญ่ที่ได้รับมาแต่ช่องกรอกข้อความอิสระจะเลิกใช้ภายในสัปดาห์แรก
รูปแบบที่ 5 คนที่สร้างหายไป
สภาพที่ยกทุกอย่างให้ผู้ให้บริการภายนอก แล้วไม่มีใครในบริษัทเข้าใจกลไก หรือพนักงานญี่ปุ่นประจำการที่เป็นคนขับเคลื่อนโครงการหมดวาระกลับประเทศ แล้วคนที่มารับช่วงต่อไม่ได้ ผลคือตามการอัปเดตโมเดลพื้นฐานและการเปลี่ยนโครงสร้างองค์กรภายในไม่ทัน และภายในหนึ่งปีก็เหลือแต่รูปแบบโดยไม่มีใครอัปเดต
นี่ไม่ใช่ปัญหาเชิงเทคนิคแต่เป็นปัญหาเชิงโครงสร้างทีม เรื่องการจัดหาบุคลากรฝั่งบริษัทที่เข้าใจสเปกและตัดสินใจได้ เราเรียบเรียงบทบาทที่จำเป็นและแนวทางการพัฒนาคนไว้ในวิธีเลือกบริการสนับสนุนการพัฒนา AI ด้วยทีมภายใน เพราะสิ่งที่เติมทีหลังได้ยากที่สุดคือคน จึงขอให้เดินเรื่องโครงสร้างทีมคู่ขนานไปพร้อมกับการตั้งโครงการสร้างระบบ

ธรรมาภิบาลและการออกแบบสิทธิ์การเข้าถึง
ให้สิทธิ์อยู่ฝั่งข้อมูล ไม่ใช่ฝั่งโมเดล
จุดที่รื้อการออกแบบยากที่สุดในการสร้างระบบ AI ภายในองค์กรอยู่ตรงนี้ การออกแบบที่พยายามควบคุมด้วยคำสั่งว่าอย่าตอบถ้าถูกถามนั้นรั่วแน่นอน จึงต้องจำกัดขอบเขตที่ผู้ใช้แต่ละคนอ้างอิงได้เสียก่อน แล้วให้ AI ตอบอยู่ภายในขอบเขตนั้นเท่านั้น ประเด็นสำคัญในการติดตั้งมี 3 ข้อ
ข้อแรก ให้สืบทอดสังกัดและบทบาทของผู้ใช้มาจากฐานการยืนยันตัวตนที่มีอยู่เดิม หากสร้างมาสเตอร์ผู้ใช้ขึ้นใหม่ต่างหากในฝั่ง AI จะตามการโยกย้ายและการลาออกไม่ทัน ข้อสอง ให้ติดข้อมูลสิทธิ์ไปพร้อมกันตั้งแต่ตอนทำดัชนีเอกสาร แล้วจำกัดขอบเขตการอ้างอิงตั้งแต่ขั้นการค้นหา ข้อสาม ให้ผู้ดูแลระบบตรวจสอบผ่านหน้าจอได้ว่าผู้ใช้คนหนึ่งอยู่ในสถานะที่อ้างอิงอะไรได้บ้าง ถ้าตรวจสอบไม่ได้ ก็อธิบายในการตรวจประเมินไม่ได้
ล็อกต้องเก็บคำถาม หลักฐาน และคำตอบผูกกันทั้ง 3 อย่าง
ล็อกการใช้งานต้องเก็บอย่างน้อย 3 อย่างผูกกันไว้ คือเนื้อหาของคำถาม เอกสารและตำแหน่งที่ AI อ้างอิง และคำตอบที่ส่งกลับไป ครบทั้ง 3 อย่างจึงจะย้อนดูภายหลังได้ว่าทำไมคำตอบจึงออกมาแบบนี้ ถ้าเก็บแต่คำตอบอย่างเดียวจะแยกแยะสาเหตุไม่ได้ ระยะเวลาการเก็บรักษาให้อิงตามระเบียบระบบสารสนเทศภายในองค์กร แต่อย่างน้อยต้องยาวพอที่จะคร่อมรอบการตรวจประเมินจากลูกค้าได้หนึ่งรอบ
อนึ่ง กฎการใช้งานภายในองค์กร ขอให้เขียนในรูปของเกณฑ์การตัดสิน ไม่ใช่การไล่เรียงข้อห้าม ตัวอย่างเช่น แบบวิศวกรรมและข้อกำหนดที่รับมาจากลูกค้าอาจถูกจำกัดการส่งต่อให้บุคคลที่สามภายใต้สัญญารักษาความลับ จึงต้องตรวจสอบข้อสัญญาก่อนป้อนเข้า AI กฎที่เขียนเหตุผลและปลายทางที่ต้องไปตรวจสอบไว้ด้วยเท่านั้นที่หน้างานจะทำตาม
ประเด็นเฉพาะของการนำ AI มาใช้ในฐานการผลิตในประเทศไทย
จะจัดการโครงสร้างสองชั้นระหว่างพนักงานญี่ปุ่นที่ประจำการกับพนักงานไทยอย่างไร
เหตุผลตามแบบฉบับที่ทำให้โครงการ AI ในฐานการผลิตของทุนญี่ปุ่นในประเทศไทยหยุดชะงัก ไม่ใช่เทคโนโลยีแต่เป็นโครงสร้างทีม การตัดสินใจอยู่ที่พนักงานญี่ปุ่นที่ประจำการ ส่วนงานปฏิบัติอยู่ที่พนักงานท้องถิ่น วาระประจำการของพนักงานญี่ปุ่นอยู่ที่ 3 ถึง 5 ปี ซึ่งแทบทับซ้อนพอดีกับช่วงตั้งโครงการและช่วงทำให้อยู่ตัว
ทางรับมือที่ทำได้จริงมี 2 ทาง ทางหนึ่งคือเก็บสเปกและเหตุผลของการตัดสินใจไว้เป็นเอกสารเสมอ ให้อยู่ในรูปที่ส่งต่อได้ อีกทางหนึ่งคือแต่งตั้งผู้ขับเคลื่อนจากพนักงานท้องถิ่นตั้งแต่ระยะแรก และให้เข้าร่วมการประชุมกับพาร์ตเนอร์ภายนอกตั้งแต่ต้น โครงการที่หยุดทันทีที่พนักงานญี่ปุ่นกลับประเทศ คือโครงการที่ให้พนักงานญี่ปุ่นคนนั้นเป็นผู้ประสานงานเพียงคนเดียว
การจัดการเรื่องภาษาก็เป็นเรื่องที่ต้องออกแบบเช่นกัน ควรทำให้สลับได้เป็นรายผู้ใช้ว่าจะให้ตอบเป็นภาษาญี่ปุ่น ภาษาอังกฤษ หรือภาษาไทย ส่วนเอกสารที่ยกมาแสดงเป็นหลักฐานให้แสดงในภาษาของต้นฉบับ หากแสดงแต่หลักฐานที่แปลแล้ว จะตรวจสอบความต่างจากต้นฉบับไม่ได้
ความรู้ด้าน AI ของพนักงานไทยเติมด้วยการออกแบบ ไม่ใช่การอบรม
ก่อนจะสรุปว่าสาเหตุที่การใช้ AI ของพนักงานไทยไม่คืบหน้าคือการอบรมไม่พอ การกลับไปทบทวนการออกแบบทางเข้ามีคุณค่ากว่า ในหลายกรณีปัญหาไม่ได้อยู่ที่ความสามารถในการเข้าใจ แต่อยู่ที่ AI ถูกวางไว้ห่างจากหน้าจอทำงานประจำวัน และไม่มีตัวอย่างคำถามเป็นภาษาไทยให้ดู เตรียมประโยคคำถามที่ใช้บ่อยเป็นภาษาไทยแล้วทำเป็นปุ่ม วางปุ่มสรุปความไว้ในหน้าจอกรอกรายงานประจำวัน และแนบลิงก์ดูต้นฉบับไว้ใต้คำตอบทุกครั้ง สามข้อนี้ส่งผลต่ออัตราการใช้งานมากกว่าการจัดอบรมรวมหนึ่งครั้ง
PDPA กับที่ตั้งของข้อมูล
พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคลของไทยหรือ PDPA กำหนดให้การเก็บรวบรวม ใช้ และเปิดเผยข้อมูลส่วนบุคคลต้องมีฐานทางกฎหมายรองรับ และวางกฎเกณฑ์เรื่องการโอนออกนอกประเทศไว้ด้วย สิ่งที่มักกลายเป็นปัญหาในการสร้างระบบ AI ภายในองค์กรคือกรณีที่ข้อมูลส่วนบุคคลปะปนเข้ามาโดยไม่ตั้งใจ บันทึกเวลาทำงานและบันทึกการอบรมที่มีชื่อพนักงาน บันทึกการสัมภาษณ์ บันทึกผู้มาติดต่อ รวมถึงอีเมลและรายงานการประชุมที่มีชื่อและข้อมูลติดต่อของผู้รับผิดชอบฝั่งลูกค้า เมื่อสิ่งเหล่านี้อยู่ร่วมที่เก็บเอกสารเดียวกัน มันจะถูกรวมเข้าเป็นขอบเขตอ้างอิงของ AI โดยอัตโนมัติ
ลำดับการรับมือคือ เริ่มจากสำรวจว่าข้อมูลเป้าหมายมีข้อมูลส่วนบุคคลรวมอยู่หรือไม่ สำหรับส่วนที่มี ให้ตรวจสอบวัตถุประสงค์การใช้และฐานทางกฎหมาย จากนั้นจึงตัดสินว่าจะให้เข้าไปอยู่ในขอบเขตอ้างอิงของ AI หรือจะกันออก กรณีที่กันออก การวางโครงสร้างให้กันออกได้แบบอัตโนมัติในระดับโฟลเดอร์จะทำให้การดำเนินงานมีเสถียรภาพ หากเลือกโครงสร้างที่ประมวลผลบนคลาวด์ต่างประเทศ ขอให้บันทึกปลายทางของการโอนและฐานของการโอนไว้เป็นหลักฐาน
อนึ่ง เนื่องจากการตัดสินเรื่องนี้แตะขอบเขตด้านกฎหมาย ขอให้ถือเป็นเงื่อนไขว่าต้องผ่านการตรวจสอบจากที่ปรึกษากฎหมายของบริษัทหรือที่ปรึกษากฎหมายในประเทศไทยก่อน
ผนวกสิทธิประโยชน์ยกระดับเทคโนโลยีของ BOI เข้าไปในแผนการลงทุน
สิ่งที่มักถูกมองข้ามคือมาตรการส่งเสริมของ BOI หรือคณะกรรมการส่งเสริมการลงทุน ในมาตรการสนับสนุนการยกระดับเทคโนโลยีสำหรับกิจการที่ได้รับการส่งเสริมจาก BOI อยู่แล้ว หรือ Activity 10.1 การลงทุนยกระดับเทคโนโลยีที่เข้าเงื่อนไขจะได้รับการยกเว้นภาษีเงินได้นิติบุคคลเพิ่มอีก 3 ปี ฮาร์ดแวร์ที่เข้าข่ายระบุไว้ชัดเจนว่ารวมถึงเซิร์ฟเวอร์ GPU กล้องสำหรับ computer vision เซ็นเซอร์ IoT และอุปกรณ์ edge computing ดังนั้นโครงสร้างของการสร้างระบบ AI ภายในองค์กรที่วางฐาน inference ไว้ในสภาพแวดล้อมของบริษัทเอง จึงมีโอกาสเข้าข่ายกรอบนี้
นอกจากนี้ บริษัทที่ลงทุนพัฒนาบุคลากรด้าน AI ในสัดส่วน 1% ถึง 3% ของยอดเงินเดือนรวม จะได้รับการยกเว้นเพิ่มอีก 1 ถึง 3 ปีตามสัดส่วนการลงทุน สำหรับภาคการผลิตที่ตั้งอยู่ใน EEC หรือระเบียงเศรษฐกิจพิเศษภาคตะวันออก เมื่อรวมสิทธิเหล่านี้เข้าด้วยกันมีโอกาสไปถึงการยกเว้นภาษีเงินได้นิติบุคคลสูงสุด 15 ปี และสำหรับเครื่องจักรอุปกรณ์ที่เข้าเงื่อนไขยังได้รับการยกเว้นอากรขาเข้าด้วย
นัยเชิงปฏิบัติชัดเจน หากนำความเป็นไปได้ในการใช้สิทธิ BOI เข้ามาพิจารณาตั้งแต่ขั้นตัดสินรูปแบบของการสร้างระบบ AI ภายในองค์กร เม็ดเงินลงทุนจริงของแบบพัฒนาเองและแบบไฮบริดจะเปลี่ยนไป ค่าไลเซนส์ SaaS โดยพื้นฐานไม่เข้ากรอบนี้ แต่ฐานที่วางไว้ในบริษัทเองและการพัฒนาบุคลากรมีโอกาสเข้าได้ จึงคุ้มค่าที่จะตรวจสอบสถานะการได้รับการส่งเสริมจาก BOI ของบริษัทและจังหวะเวลาที่ยื่นขอได้ ก่อนจะเลือกรูปแบบ ทั้งนี้ การเข้าข่ายหรือไม่ขึ้นอยู่กับเงื่อนไขการส่งเสริมของแต่ละบริษัทและเนื้อหาที่ยื่นขอ จึงขอให้ตรวจสอบล่วงหน้ากับ BOI หรือผู้เชี่ยวชาญที่รับดำเนินการยื่นขอ
จะเลือกผู้รับงานพัฒนาระบบ AI อย่างไร
เวลาเลือกผู้รับจ้างพัฒนาระบบ AI การเปรียบเทียบด้วยชื่อโมเดลหรือแผนภาพสถาปัตยกรรมในข้อเสนอจะไม่เห็นความต่าง เพราะ ณ ปี 2026 ผู้ให้บริการทุกรายใช้โมเดลพื้นฐานของผู้เล่นรายใหญ่ และส่วนที่เป็นตำราของโครงสร้างก็คล้ายกันไปหมด สิ่งที่ควรดูมี 4 ข้อ
- เข้าใจโดเมนของงานเป้าหมายหรือไม่ คู่สัญญาที่ไม่รู้จักโครงสร้างของแบบฟอร์มหน้างานผลิต เกณฑ์การตรวจสอบ และข้อกำหนดของลูกค้า จะออกแบบชั้นข้อมูลไม่ได้
- ลงค่าแรงของการจัดระเบียบข้อมูลไว้ในใบเสนอราคาหรือไม่ ข้อเสนอที่ตรงนี้บางจะจบลงด้วยการเรียกเก็บเพิ่มภายหลัง หรือถูกนับว่าเสร็จทั้งที่คุณภาพยังไม่ออก
- ใส่วิธีการประเมินไว้ในข้อเสนอหรือไม่ ควรเลือกคู่สัญญาที่ตกลงกันได้ก่อนเซ็นสัญญาว่าอะไรคือเกณฑ์ของความเสร็จ โดยตกลงกันในรูปของชุดคำถาม
- ตั้งอยู่บนสมมติฐานว่าจะมีการส่งต่อหรือไม่ เอกสารการออกแบบ รายการสิทธิ์ และขั้นตอนการดำเนินงาน อยู่ในรายการส่งมอบหรือไม่
ส่วนคำถามว่าจะทำให้จบภายในประเทศไทยหรือจะใช้บริษัทพัฒนาจากญี่ปุ่น ไม่มีคำตอบสำเร็จรูปเดียว แกนของการตัดสินคือประชุมกับพนักงานไทยเป็นภาษาไทยได้หรือไม่ แตะระบบหลักและโครงสร้างเครือข่ายในพื้นที่ได้หรือไม่ และรับมือตามเวลาท้องถิ่นได้หรือไม่เมื่อเกิดเหตุขัดข้อง ยิ่งเป็นส่วนที่แตะข้อมูลหน้างานมากเท่าไร คุณค่าของทีมที่ขยับได้ในพื้นที่ก็ยิ่งสูง
คำถามที่พบบ่อย
การสร้างระบบ AI ภายในองค์กรมีค่าใช้จ่ายเท่าไร
เปลี่ยนแปลงมากตามขอบเขตที่สร้าง ในการคำนวณจากโมเดลสมมติของบทความนี้ กรณีแบบไฮบริดที่มีพนักงาน 400 คน ผู้ใช้ 120 คน และงานเป้าหมาย 3 งาน ค่าใช้จ่ายเริ่มต้นอยู่ราว 1,800,000 ถึง 4,700,000 บาท และค่าดำเนินการรายปีของส่วนที่สร้างเองอยู่ราว 1,000,000 ถึง 2,150,000 บาท หากบวกค่าไลเซนส์ SaaS ทั่วไปเข้าไปด้วย ค่าดำเนินการรายปีจะอยู่ที่ราว 2,440,000 ถึง 3,590,000 บาท ตัวการใหญ่ที่สุดที่ทำให้เกิดช่วงกว้างคือสภาพความพร้อมของข้อมูลภายใน บริษัทที่แปลงเป็นดิจิทัลและจัดการเวอร์ชันเรียบร้อยแล้ว กับบริษัทที่กระดาษ ไฟล์ PDF สแกน และหลายเวอร์ชันปะปนกัน ค่าแรงของชั้นข้อมูลต่างกันเกือบ 3 เท่า หากคัดงานเป้าหมายเหลือ 3 งานก่อน แล้วตรวจสอบสภาพความพร้อมเฉพาะเอกสารที่งานนั้นต้องใช้ ช่วงของใบเสนอราคาจะแคบลงมาก
ควรเลือกพัฒนาเองหรือ SaaS
การตัดสินขึ้นอยู่กับว่าจะใช้ข้อมูลภายในลึกแค่ไหน ถ้าวัตถุประสงค์หลักคือการเขียนข้อความทั่วไปและการแปล และแทบไม่ต้องอ้างอิงข้อมูลเฉพาะของบริษัท แบบเน้น SaaS ก็เพียงพอ ในทางกลับกัน ถ้าต้องการให้อ้างอิงเอกสารภายในที่สิทธิ์การเปิดอ่านแยกตามแผนก หรือข้อมูลผลการผลิตจากระบบหลัก SaaS อย่างเดียวจะเอื้อมไม่ถึง สิ่งที่ตรงกับฐานการผลิตของทุนญี่ปุ่นในประเทศไทยมากที่สุด ณ ปี 2026 คือแบบไฮบริด ซึ่งใช้ SaaS กับงานทั่วไป และสร้างเฉพาะงานที่ต้องใช้ข้อมูลภายในขึ้นด้วยการออกแบบของบริษัทเอง ขอให้ตัดสินรูปแบบหลังจากสำรวจงานเป้าหมายและที่ตั้งของข้อมูลแล้วเท่านั้น หากกลับลำดับ เรื่องจะกลายเป็นการดัดงานให้เข้ากับรูปแบบที่ตัดสินไปแล้ว
ป้องกันข้อมูลรั่วไหลได้หรือไม่เมื่อใช้ข้อมูลภายในกับ generative AI
ในเชิงเทคนิคควบคุมได้ แต่ถ้าไม่ออกแบบก็ป้องกันไม่ได้ ประเด็นสำคัญมี 3 ข้อ ข้อแรก ยืนยันเป็นเอกสารว่าข้อมูลถูกประมวลผลและจัดเก็บที่ใด และสัญญาระบุว่าไม่ถูกนำไปใช้เทรนโมเดล ข้อสอง ให้สิทธิ์อยู่ฝั่งข้อมูลแทนที่จะอยู่ในคำสั่งฝั่ง AI แล้วจำกัดขอบเขตอ้างอิงเป็นรายผู้ใช้ก่อนจึงให้ตอบ ข้อสาม เก็บล็อกว่าใครถามอะไร และ AI อ้างอิงอะไร พูดกลับกันคือ โครงสร้างที่ไม่มี 3 ข้อนี้อยู่ในการออกแบบ ต่อให้ใช้โครงสร้างพื้นฐานที่แข็งแรงเพียงใด ก็ยังไม่เพียงพอในแง่การควบคุมข้อมูลภายในองค์กร
เดินเรื่องการสร้างระบบ AI ภายในองค์กรด้วยฐานในประเทศไทยอย่างเดียวได้หรือไม่
ทำได้ แต่มีเงื่อนไข ข้อหนึ่งคือต้องตรวจสอบมาตรฐานความปลอดภัยและระเบียบการจัดการข้อมูลที่ฝ่ายไอทีของสำนักงานใหญ่ในญี่ปุ่นกำหนดไว้ก่อน มีกรณีจริงที่ภายหลังไปขัดกับมาตรฐานของสำนักงานใหญ่แล้วต้องสร้างใหม่ อีกข้อหนึ่งคือต้องวางผู้ขับเคลื่อนไว้ในพื้นที่ โครงสร้างที่มีพนักงานญี่ปุ่นประจำการเป็นผู้ประสานงานเพียงคนเดียวจะหยุดลงพร้อมกับการครบวาระ หากดึงพนักงานไทยเข้ามาร่วมตั้งแต่ระยะแรก และจัดทำเอกสารสเปกกับเหตุผลของการตัดสินใจไว้ การสร้างและการดำเนินงานโดยฐานในประเทศเป็นผู้นำก็เกิดขึ้นได้จริง
ใช้สิทธิประโยชน์ของ BOI กับการสร้างระบบ AI ภายในองค์กรได้หรือไม่
หากเป็นกิจการที่ได้รับการส่งเสริมจาก BOI อยู่แล้ว มีความเป็นไปได้ที่จะได้รับการยกเว้นภาษีเงินได้นิติบุคคลเพิ่มเติมภายใต้กรอบมาตรการสนับสนุนการยกระดับเทคโนโลยีหรือ Activity 10.1 ฮาร์ดแวร์ที่เข้าข่ายรวมถึงเซิร์ฟเวอร์ GPU เซ็นเซอร์ IoT และอุปกรณ์ edge computing ดังนั้นโครงสร้างที่วางฐาน inference ไว้ในสภาพแวดล้อมของบริษัทเองจึงมีโอกาสเข้าข่าย นอกจากนี้ หากลงทุนพัฒนาบุคลากรด้าน AI ในสัดส่วน 1% ถึง 3% ของยอดเงินเดือนรวม จะได้รับการยกเว้นเพิ่มตามสัดส่วนการลงทุน สำหรับภาคการผลิตที่ตั้งอยู่ใน EEC เมื่อรวมสิทธิเข้าด้วยกันมีโอกาสไปถึงการยกเว้นสูงสุด 15 ปี อย่างไรก็ตาม การเข้าข่ายหรือไม่ขึ้นกับเงื่อนไขการส่งเสริมของแต่ละบริษัทและเนื้อหาที่ยื่นขอ จึงขอให้ตรวจสอบกับ BOI หรือผู้เชี่ยวชาญที่รับดำเนินการยื่นขอก่อนตัดสินรูปแบบ
สรุป
สิ่งที่แยกบริษัทที่ทำการสร้างระบบ AI ภายในองค์กรสำเร็จ ออกจากบริษัทที่หยุดอยู่แค่โครงการนำร่อง ไม่ใช่การเลือกโมเดลและไม่ใช่ขนาดของงบประมาณ แต่คือลำดับของการตัดสินใจ คัดงานให้เหลือ 3 งาน สำรวจที่ตั้งของข้อมูลและสิทธิ์ แล้วจึงตัดสินรูปแบบและงบประมาณ ถ้ารักษาลำดับนี้ไว้ การเลือกรูปแบบจะลงตัวเองโดยธรรมชาติ
สิ่งที่ถูกถามจริง ๆ ในการเปรียบเทียบระหว่างพัฒนาเอง SaaS และไฮบริด คือจะเอาข้อมูลภายในเข้าไปอยู่ในกลไกลึกแค่ไหน ถ้าไม่เอาเข้าไป SaaS ทั่วไปก็เพียงพอ ถ้าเอาเข้าไป ก็ต้องมีงบประมาณที่สมน้ำสมเนื้อสำหรับสิทธิ์ ล็อก และการจัดระเบียบข้อมูล ขอให้สื่อสารภายในองค์กรก่อนขออนุมัติงบว่าค่าใช้จ่ายส่วนใหญ่ไม่ได้เกิดที่ชั้นฐานการประมวลผล แต่เกิดที่ชั้นข้อมูลและชั้นปฏิบัติการกับธรรมาภิบาล การขออนุมัติโดยแบ่งกรอบตามชั้นคือวิธีที่แน่นอนที่สุดในการป้องกันไม่ให้ครึ่งหลังผอมลง
หากเดินเรื่องด้วยฐานในประเทศไทย จะมีงานปฏิบัติที่ต่างจากโครงการในญี่ปุ่นอยู่ 4 ข้อ คือการออกแบบการส่งต่อที่คร่อมวาระประจำการของพนักงานญี่ปุ่น การใช้การออกแบบทางเข้ามาช่วยพนักงานไทย การแยกข้อมูลส่วนบุคคลตามที่ PDPA กำหนด และการผนวกสิทธิประโยชน์ยกระดับเทคโนโลยีของ BOI เข้าไปในแผนการลงทุน โดยเฉพาะความเป็นไปได้ในการใช้สิทธิ BOI นั้น หากตรวจสอบไว้ก่อนเลือกรูปแบบ จะมีผลต่อเม็ดเงินลงทุนจริง
งานใดในบริษัทควรถูกเลือกเป็น 3 งานแรก เชื่อมกับระบบบริหารการผลิตที่มีอยู่เดิมได้ลึกแค่ไหนจึงจะสมจริง และจะทำให้สอดคล้องกับมาตรฐานความปลอดภัยของสำนักงานใหญ่อย่างไร ประเด็นเหล่านี้มีบริบทต่างกันไปในแต่ละฐานการผลิต และตอบด้วยหลักการทั่วไปไม่ได้ TOMAS TECH ให้การสนับสนุนการสร้างกลไกด้านการบริหารการผลิตและการใช้ข้อมูลหน้างานสำหรับภาคการผลิตของทุนญี่ปุ่นในประเทศไทย และยินดีรับปรึกษาตั้งแต่ระยะเริ่มพิจารณาที่ยังไม่ได้กำหนดรูปแบบหรืองบประมาณ เริ่มจากการรับฟังสถานะของเอกสารและระบบในปัจจุบัน แล้วช่วยกันเรียบเรียงว่าควรลงมือจากจุดใดจึงจะสมจริงก็ได้ ปรึกษาเราได้ที่หน้าติดต่อสอบถาม
ข้อมูลอ้างอิง
- Artificial Intelligence Statistics for Industry – The ROI of Reliability in 2026 – อัตราการนำ AI ขึ้นใช้งานจริงในภาคการผลิต สัดส่วนแยกตามอุตสาหกรรม สัดส่วนโครงการนำร่องที่ไม่ขยายผล อัตราการแจ้งเตือนผิดพลาดในการติดตั้งช่วงต้น และอัตราการไปถึง ROI ภายใน 12 เดือน
- Thailand Artificial Intelligence in Manufacturing Market – การคาดการณ์มูลค่าตลาด AI สำหรับภาคการผลิตของไทยและอัตราการเติบโต
- Thailand BOI Manufacturing Funding and Incentives – อุปกรณ์ที่เข้าข่ายมาตรการสนับสนุนการยกระดับเทคโนโลยีของ BOI หรือ Activity 10.1 การยกเว้นเพิ่มเติมจากการลงทุนพัฒนาบุคลากร เพดานรวมในพื้นที่ EEC และการยกเว้นอากรขาเข้า
- PDPC สำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล – หน่วยงานที่กำกับดูแลพระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคลของไทยและประกาศที่เกี่ยวข้อง
- Thailand Board of Investment – ขั้นตอนการยื่นขอรับการส่งเสริมและรายการกิจการที่เข้าข่ายฉบับล่าสุด