เลือกบริษัทพัฒนา AI ปี 2026 — สัญญา ขอบเขตงาน และการอ่านใบเสนอราคา

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

ทำไมงานพัฒนา AI จึงยากที่จะรับปากว่างานจะ “เสร็จสมบูรณ์”

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

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

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

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

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

เริ่มจากจำแนกว่าโครงการของตัวเองอยู่ในประเภทใด

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

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

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

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

การพัฒนาแบบแบ่งขั้นตอนเชิงสำรวจ แบ่งสัญญาออกเป็น 4 ขั้นตอน

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

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

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

ความหมายที่แท้จริงของการแบ่งขั้นตอน คือการสร้างจุดที่หยุดได้

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

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

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

เขียน “เงื่อนไขเข้า” และ “เงื่อนไขออก” ของแต่ละขั้นตอน

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

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

สัญญาจ้างทำของหรือสัญญาแบบ jun-inin และทางสายกลางที่เรียกว่า “แบบส่งมอบผลงาน”

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

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

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

สองรูปแบบย่อยของสัญญาแบบ jun-inin

สัญญาแบบ jun-inin ยังแยกออกเป็นสองรูปแบบ

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

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

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

ตั้งสมมติฐานไว้เลยว่าผู้พัฒนาระบบมีแนวโน้มเลี่ยงสัญญาจ้างทำของ

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

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

วิธีจับคู่ขั้นตอนกับประเภทสัญญา เป็นการเรียบเรียงเชิงแนวคิด

ต่อไปนี้เป็นการเรียบเรียงตามแนวคิดของแนวทาง METI และไม่ได้รับประกันความชอบด้วยกฎหมายหรือความเหมาะสมของโครงการรายกรณี

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

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

อ่านใบเสนอราคาโดยแยกออกเป็น 5 ชั้น

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

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

5 ชั้น

ใบเสนอราคาที่ “ถูก” ส่วนใหญ่ขาดชั้นที่ 4 และชั้นที่ 5

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

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

การทดลองทางความคิด ชั้นที่หายไปทำให้ใบเสนอราคาดูถูกลงเท่าไร

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

ค่าตั้งต้น ทั้งหมดเป็นค่าสมมติ

มาคำนวณกัน

• จำนวนคน-วันของการสร้างระบบตั้งต้นที่รวมชั้นที่ 1 ถึงชั้นที่ 4 ครบ 10 + 25 + 30 + 20 = 85 คน-วัน
• จำนวนคน-วันบนใบเสนอราคาเมื่อชั้นที่ 4 หายไป 10 + 25 + 30 = 65 คน-วัน
• อัตราที่ดูถูกลง (85 − 65) ÷ 85 = 20 ÷ 85 ≈ 0.235 จึง ดูถูกลงประมาณ 23.5%
• จำนวนคน-วันรวม 3 ปี ชั้นที่ 1 ถึงชั้นที่ 4 บวกชั้นที่ 5 สามปี 85 + 12 × 3 = 85 + 36 = 121 คน-วัน
• สัดส่วนของใบเสนอราคา 65 คน-วันที่ขาดชั้นที่ 4 และ 5 เทียบกับคน-วันรวม 3 ปี 65 ÷ 121 ≈ 0.537 จึงราว 53.7%

พูดอีกอย่างคือ ภายใต้สมมติฐานชุดนี้ ใบเสนอราคาที่ขาดชั้นที่ 4 และชั้นที่ 5 สะท้อนงานที่จำเป็นจริงตลอด 3 ปีเพียง ราวครึ่งเดียว เมื่อมีใบเสนอราคาสองใบวางเรียงกัน บริษัท A 65 คน-วัน กับบริษัท B 85 คน-วัน สิ่งที่ต้องตรวจสอบเป็นอันดับแรกคือความเป็นไปได้ที่ว่า B ไม่ได้แพง แต่ A แค่ไม่ได้รวมชั้นที่ 4 เข้ามาต่างหาก

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

ขั้นตอนปฏิบัติในการจับคู่ทีละบรรทัด

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

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

ออกแบบเงื่อนไขการตรวจรับงาน อย่ารับงานด้วยคำว่า “ความแม่นยำ 99%”

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

เมื่อในเอกสารข้อเสนอเขียนว่า “ความแม่นยำ 99%” คำถามแรกที่ฝ่ายผู้ว่าจ้างควรถามไม่ใช่ “จริงหรือ” แต่คือ “99% นั้นตัวส่วนคืออะไร”

ตัวส่วนเปลี่ยน เวลาที่ต้องใช้ตรวจสอบก็เปลี่ยน

ลองนึกถึงโครงการที่ให้ AI อ่านเอกสารแบบฟอร์ม คำว่า “ความแม่นยำ 99%” อ่านได้อย่างน้อย 3 แบบ

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

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

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

ค่าตั้งต้น ทั้งหมดเป็นค่าสมมติ

กรณี A ความแม่นยำระดับฟิลด์ 99%

• จำนวนฟิลด์รวมต่อเดือน 1,000 ฉบับ × 20 ฟิลด์ = 20,000 ฟิลด์
• ค่าคาดหมายของจำนวนฟิลด์ที่ผิด 20,000 × 1% = 200 ฟิลด์
• ความน่าจะเป็นที่ทั้ง 20 ฟิลด์ของเอกสาร 1 ฉบับถูกต้องหมด 0.99 ยกกำลัง 20 ≈ 0.8179 ราว 81.8%
• สัดส่วนเอกสารที่มีอย่างน้อย 1 ฟิลด์ผิด 1 − 0.8179 = 0.1821 ราว 18.2%
• จำนวนเอกสารที่ต้องตรวจด้วยคน 1,000 ฉบับ × 18.2% ≈ 182 ฉบับต่อเดือน
• เวลาที่ใช้ตรวจ 182 ฉบับ × 3 นาที = 546 นาที ≈ 9.1 ชั่วโมงทำงานต่อเดือน

กรณี B ความแม่นยำระดับฟิลด์ 99.9%

• ค่าคาดหมายของจำนวนฟิลด์ที่ผิด 20,000 × 0.1% = 20 ฟิลด์
• ความน่าจะเป็นที่ทั้ง 20 ฟิลด์ของเอกสาร 1 ฉบับถูกต้องหมด 0.999 ยกกำลัง 20 ≈ 0.9802 ราว 98.0%
• สัดส่วนเอกสารที่มีอย่างน้อย 1 ฟิลด์ผิด 1 − 0.9802 = 0.0198 ราว 2.0%
• จำนวนเอกสารที่ต้องตรวจด้วยคน 1,000 ฉบับ × 2.0% ≈ 20 ฉบับต่อเดือน
• เวลาที่ใช้ตรวจ 20 ฉบับ × 3 นาที = 60 นาที = 1.0 ชั่วโมงทำงานต่อเดือน

เมื่อดูระดับฟิลด์ “99%” กับ “99.9%” ต่างกันเพียง 0.9 จุดเปอร์เซ็นต์ แต่ภายใต้สมมติฐานชุดนี้ จำนวนเอกสารที่ต้องตรวจด้วยคนคือ 182 ฉบับกับ 20 ฉบับ และเวลาที่ใช้ตรวจคือ 9.1 ชั่วโมงกับ 1.0 ชั่วโมง ห่างกัน ประมาณ 9 เท่า ถ้าเพิ่มจำนวนฟิลด์ต่อเอกสารจาก 20 ฟิลด์เป็น 40 ฟิลด์ การคำนวณแบบเดียวกันจะได้เอกสารที่ต้องตรวจราว 331 ฉบับกับราว 39 ฉบับ ส่วนต่างของจำนวนฉบับจึงขยายจาก 162 ฉบับเป็น 292 ฉบับ ส่วนอัตราส่วนกลับหดลงเล็กน้อยจากราว 9.1 เท่าเหลือราว 8.4 เท่า ขอให้เข้าใจว่ายิ่งเอกสารมีฟิลด์มาก การเข้าใจตัวส่วนผิดยิ่งลงไปเป็นภาระของหน้างานโดยตรง

นัยของการคำนวณนี้ชัดเจน อย่าเขียนในสัญญาแค่ว่า “ความแม่นยำ 99%” ตัวชี้วัดความแม่นยำที่ไม่ได้เขียนตัวส่วนกำกับ จะถูกตีความแตกต่างกันในวันตรวจรับงานอย่างแน่นอน

เขียนตัวชี้วัดการตรวจรับงานด้วยตัวชี้วัดทางธุรกิจ ไม่ใช่ “อ่านออกหรือไม่”

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

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

เรื่องวิธีเคาะตัวส่วนของความแม่นยำ เราลงลึกไว้ในบทความเปรียบเทียบ AI-OCR รวมถึงแนวคิดของแต่ละผลิตภัณฑ์ อ่านสักรอบก่อนลงมือเขียนเงื่อนไขการตรวจรับงาน แล้วความคมของคำถามจะเพิ่มขึ้น

เขียนวิธีจัดการกรณีตรวจรับงานไม่ผ่านไว้ล่วงหน้าด้วย

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

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

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

การถือครองสิทธิ โมเดลที่ผ่านการเทรนแล้วจะเป็นของใคร

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

foreground IP กับ background IP

• background IP คือทรัพย์สินที่แต่ละฝ่ายถือครองอยู่ก่อนทำสัญญา ฝั่งผู้พัฒนาระบบได้แก่ ไลบรารีเดิม โมเดลทั่วไป และเฟรมเวิร์กภายในบริษัท ฝั่งผู้ว่าจ้างได้แก่ ข้อมูลการดำเนินงานของตัวเอง ระบบเดิม และองค์ความรู้
• foreground IP คือผลงานที่ถูกสร้างขึ้นใหม่ภายใต้สัญญาฉบับนี้

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

4 สิ่งที่ต้องแยกคิด

เวลาถกเรื่องการถือครองสิทธิ อย่าเหมารวมเป็นคำว่า “โมเดล AI” คำเดียว ให้แยกเป็น 4 สิ่งต่อไปนี้

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

ประโยคที่ต้องเช็กในสัญญาให้ได้

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

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

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

วิธีเขียนมีทางเลือกดังนี้

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

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

เขียนรูปแบบการส่งมอบให้เป็นรูปธรรมด้วย

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

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

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

สิ่งที่ต้องตัดสินใจเพิ่มเมื่อสั่งงานจากฐานในประเทศไทย

จากตรงนี้เป็นประเด็นเฉพาะของบริษัทที่ดำเนินกิจการอยู่ในประเทศไทยและอาเซียน แม้จะเป็นการว่าจ้างพัฒนา AI เรื่องเดียวกัน แต่การวางว่าใครเป็นคู่สัญญาจะเปลี่ยนการปฏิบัติทางภาษีและทางกฎหมาย

จะให้บริษัทแม่ที่ญี่ปุ่นเป็นคู่สัญญา หรือให้นิติบุคคลไทยเป็นคู่สัญญา

การตัดสินใจนี้คือประตูทางเข้า ถ้าบริษัทแม่ที่ญี่ปุ่นเป็นคู่สัญญา ก็จบภายในกฎหมายและภาษีของญี่ปุ่นได้ง่ายกว่า แต่คนที่ใช้ระบบจริงคือโรงงานในประเทศไทย ถ้านิติบุคคลไทยเป็นคู่สัญญา ก็เดินด้วยงบประมาณและอำนาจอนุมัติในประเทศได้ แต่ต้องใช้ระบบภาษีของไทย ตามข้อมูลของ JETRO ภาษีเงินได้นิติบุคคลของไทยโดยหลักการเป็นอัตราถาวรที่ 20% สำหรับรอบบัญชีที่เริ่มตั้งแต่วันที่ 1 มกราคม 2016 เป็นต้นไป และภาษีมูลค่าเพิ่ม (VAT) ปัจจุบันอยู่ที่ 7% โดยอัตราตามหลักของกฎหมายคือ 10% แต่ถูกลดลงเหลือ 7% ด้วยพระราชกฤษฎีกา

กรณีสั่งงานกับผู้พัฒนาระบบในประเทศไทย

ค่าบริการที่จ่ายให้ผู้ให้บริการภายในประเทศไทยจะมีภาษีหัก ณ ที่จ่าย (WHT) เมื่อบริษัททั่วไปเป็นผู้จ่าย อัตราคือ 3% และเป็น 5% หากผู้รับเงินเป็นสาขาของบริษัทต่างประเทศที่มิได้ประกอบกิจการในประเทศไทยเป็นการถาวร แบบยื่นสำหรับการจ่ายให้นิติบุคคลคือ ภ.ง.ด.53 (PND53) ซึ่งต้องยื่นและชำระภายในวันที่ 7 ของเดือนถัดจากเดือนที่จ่าย

อีกมาตรการที่น่าจับตาคือ ภาษีหัก ณ ที่จ่ายอัตราพิเศษ 1% สำหรับ e-Withholding Tax คณะรัฐมนตรีของไทยอนุมัติให้ขยายเวลาการใช้อัตราพิเศษของการหักภาษี ณ ที่จ่ายทางอิเล็กทรอนิกส์ออกไป ทำให้มาตรการที่เดิมจะสิ้นสุดปลายปี 2025 ถูกต่ออายุออกไปจนถึงสิ้นปี 2027 โดยให้มีผลย้อนหลัง อัตรายังคงเป็น 1% ซึ่งลดลงจากอัตราปกติ 5% 3% และ 2% และช่วงเวลาที่ใช้บังคับคือ 1 มกราคม 2026 ถึง 31 ธันวาคม 2027 มาตรการนี้ใช้กับการจ่ายเงินได้พึงประเมินผ่านระบบ e-Withholding Tax ทั้งที่จ่ายให้นิติบุคคล ซึ่งไม่รวมมูลนิธิและสมาคม และที่จ่ายให้บุคคลธรรมดา โดยครอบคลุมค่าบริการ ค่าวิชาชีพ ค่าเช่า ค่าโฆษณา ค่าลิขสิทธิ์ ค่าส่งเสริมการขาย และเงินรางวัล เป็นต้น

พร้อมกันนี้ยังมีการอนุมัติให้หักรายจ่ายเพิ่มเติมทางภาษีเงินได้นิติบุคคล สำหรับการลงทุนในระบบ e-Tax Invoice และ e-Receipt การลงทุนในระบบ e-Withholding Tax ค่าใช้จ่ายผู้ให้บริการที่เกี่ยวข้องกับการใช้ระบบเหล่านี้ และบริการประเมินระบบสารสนเทศผ่านสำนักงานพัฒนาธุรกรรมทางอิเล็กทรอนิกส์ (ETDA) โดยใช้ช่วงเวลาเดียวกันคือ 1 มกราคม 2026 ถึง 31 ธันวาคม 2027 มาตรการเหล่านี้เป็นการต่ออายุสิ่งที่สิ้นผลไปแล้วเมื่อวันที่ 31 ธันวาคม 2025

การทดลองทางความคิด การหักภาษี ณ ที่จ่ายที่ต่างกันทำให้ยอดโอนเปลี่ยนไปอย่างไร

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

ค่าตั้งต้น จำนวนเงินเป็นค่าสมมติ นิติบุคคลไทยจ่ายค่าบริการ 100,000 บาท ไม่รวมภาษี ให้แก่บริษัทพัฒนา AI ในประเทศไทย

การคำนวณคือ 100,000 + 7,000 − 3,000 = 104,000 และ 100,000 + 7,000 − 1,000 = 106,000

ยอดที่ต้องจ่ายทั้งหมด คือค่าบริการบวก VAT เท่ากันทั้งสองกรณี สิ่งที่เปลี่ยนคือสัดส่วนระหว่างส่วนที่หักไว้นำส่งรัฐกับส่วนที่ถึงมือผู้พัฒนาระบบโดยตรง ในมุมของผู้พัฒนาระบบ เงินสดที่เข้ามือมากขึ้น จึงมีบางกรณีที่ใช้ความพร้อมด้าน e-Withholding Tax เป็นเครื่องมือเจรจาได้ อนึ่ง การปฏิบัติเกี่ยวกับ VAT ว่าเครดิตภาษีซื้อได้หรือไม่และเมื่อใด รวมถึงการขอคืนหรือเครดิตภาษีหัก ณ ที่จ่าย ต้องพิจารณาเป็นรายกรณี กรุณาตรวจสอบกับผู้เชี่ยวชาญด้านภาษีเสมอ

กรณีสั่งงานกับผู้ให้บริการนอกประเทศ ภาษีมูลค่าเพิ่มแบบ reverse charge และ ภ.ง.ด.54

หากสั่งงานกับบริษัทพัฒนา AI ในญี่ปุ่น หรือกับผู้พัฒนาระบบในสิงคโปร์ ยุโรป หรือสหรัฐอเมริกา จะมีประเด็นที่ต้องคิดเพิ่ม

เมื่อบริษัทนอกประเทศไทยให้บริการจากต่างประเทศ และ บริการนั้นถูกใช้ภายในประเทศไทย จะถือว่ามีการให้บริการในประเทศไทย และเกิด ภาษีมูลค่าเพิ่ม 7% ในกรณีนี้ นิติบุคคลไทยผู้รับบริการต้องยื่นแบบแสดงรายการภาษีแทนผู้ให้บริการต่างประเทศ ด้วยแบบ ภ.พ.36 (P.P.36) ซึ่งก็คือกลไก reverse charge นั่นเอง

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

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

1. จะให้ใครเป็นคู่สัญญา ระหว่างบริษัทแม่ที่ญี่ปุ่นกับนิติบุคคลไทย
2. “สถานที่ใช้บริการ” จะถูกตีความว่าอยู่ที่ใด
3. VAT และภาษีหัก ณ ที่จ่ายจะรวมอยู่ในวงเงินตามสัญญา หรือให้รับภาระต่างหาก คือมีข้อสัญญาแบบ gross-up หรือไม่

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

ร่างกฎหมาย AI ของไทยยังไม่มีผลบังคับใช้ ยิ่งเป็นเหตุผลให้ต้องเขียนไว้ในสัญญา

ยังมีอีกประเด็นที่มีความไวต่อเวลาสูง สำนักงานพัฒนาธุรกรรมทางอิเล็กทรอนิกส์ (ETDA) เผยแพร่ ร่างฉบับใหม่ ของร่างพระราชบัญญัติว่าด้วยปัญญาประดิษฐ์ (Draft Act on Artificial Intelligence) เมื่อวันที่ 2 กรกฎาคม 2026 และเปิดรับฟังความคิดเห็นสาธารณะประมาณ 30 วัน โดยคาดว่าช่วงเวลารับฟังความคิดเห็นได้สิ้นสุดลงแล้วในต้นเดือนสิงหาคม 2026 ณ เวลาที่เขียนบทความนี้ กฎหมายดังกล่าวยังไม่มีผลบังคับใช้

ณ ปัจจุบันกฎหมายฉบับนี้ยังไม่มีผลบังคับใช้ และยังไม่มีกำหนดเวลาที่แน่นอนว่าจะมีผลเมื่อใด บทความนี้จึงไม่ได้บอกให้ “ปฏิบัติตามกฎหมาย AI ของไทย” แต่เนื้อหาในร่างมีองค์ประกอบที่ฝ่ายผู้ว่าจ้างควรลงมือจัดการไว้ตั้งแต่ตอนนี้

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

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

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

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

10 คำถามที่ต้องถามบริษัทพัฒนา AI เสมอ

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

1. บริษัทของท่านคิดว่าโครงการนี้เข้าข่ายประเภทใดใน 3 ประเภทของเช็กลิสต์ ระหว่างประเภทใช้บริการ AI ทั่วไป ประเภทปรับแต่ง และประเภทพัฒนาขึ้นใหม่

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

สัญญาณอันตราย ตอบทันทีว่า “เราทำใหม่ทั้งหมดแบบสั่งตัด” เป็นไปได้ว่ากำลังดันส่วนที่บริการสำเร็จรูปรองรับได้อยู่แล้วให้กลายเป็นงานพัฒนาใหม่

2. เราทำสัญญาแยกตามขั้นตอนแบบการพัฒนาแบบแบ่งขั้นตอนเชิงสำรวจได้หรือไม่

ทำไมต้องถาม เป็นการตรวจสอบว่าสร้างจุดที่หยุดได้หรือเปล่า

สัญญาณอันตราย พยายามผลักดันด้วยเหตุผลว่า “ทำสัญญาก้อนเดียวถูกกว่า” คุณกำลังแลกเสรีภาพในการถอนตัวกับส่วนลด

3. หากขั้นตอนประเมินความเป็นไปได้สรุปว่าโครงการนี้ยาก จะมีอะไรส่งมอบให้บ้าง

ทำไมต้องถาม เป็นการตรวจสอบว่าถ้าไปได้ไม่ดี เราจะเหลืออะไรอยู่ในมือ

สัญญาณอันตราย ตอบไม่ได้ชัดเจน หรือบอกว่า “กรณีแบบนั้นไม่เกิดขึ้นหรอก”

4. สัญญาของแต่ละขั้นตอนเป็นสัญญาจ้างทำของหรือแบบ jun-inin ถ้าเป็น jun-inin เป็นแบบคิดตามสัดส่วนงานที่ทำหรือแบบส่งมอบผลงาน

ทำไมต้องถาม เป็นคำถามที่บังคับให้เปิดเผยว่ามีหน้าที่ทำให้งานสำเร็จหรือไม่

สัญญาณอันตราย คำอธิบายคลุมเครืออย่าง “เป็น jun-inin แต่เนื้อแท้เหมือนสัญญาจ้างทำของ” ในทางกฎหมายสองอย่างนี้ต่างกันสิ้นเชิง

5. ตัวชี้วัดความแม่นยำในข้อเสนอของท่านมีตัวส่วนเป็นอะไร ต่อตัวอักษร ต่อฟิลด์ หรือต่อฉบับ

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

สัญญาณอันตราย ตอบทันทีไม่ได้ หรือตอบว่า “โดยทั่วไปได้ราว 99%” โดยไม่มีตัวส่วนกำกับ

6. ชุดข้อมูลสำหรับตรวจรับงานจะกำหนดอย่างไร กี่รายการ และมีสัดส่วนตามประเภทแบบใด

ทำไมต้องถาม ถ้าไม่ตรึงประชากรกลุ่มตัวอย่าง การตรวจรับงานก็ไม่เกิดขึ้นจริง

สัญญาณอันตราย พยายามจบด้วยประโยค “ลองใช้งานจริงแล้วถ้าไม่มีปัญหาก็ผ่าน”

7. หากไม่เป็นไปตามเกณฑ์การตรวจรับงาน จะแก้ไขให้ฟรีกี่รอบ ภายในกี่สัปดาห์ และหลังจากนั้นจะเป็นอย่างไร

ทำไมต้องถาม เป็นการตรวจสอบทางออกเมื่อสิ่งต่าง ๆ ไปได้ไม่ดี

สัญญาณอันตราย ตอบว่า “ทำจนกว่าจะผ่าน” โดยไม่กำหนดกรอบเวลา ความรับผิดที่ไม่มีขอบเขตไม่เคยถูกปฏิบัติจริง

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

ทำไมต้องถาม เป็นประเด็นแกนของหัวข้อการถือครองสิทธิ

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

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

ทำไมต้องถาม เป็นคำถามที่อุดช่องโหว่ของชั้นที่ 4

สัญญาณอันตราย ผลักส่วนเชื่อมต่อออกนอกขอบเขตด้วยประโยค “ส่วนนี้ทางบริษัทท่านดำเนินการเอง” โดยไม่ระบุเงื่อนไขใด ๆ

10. หลังเปิดใช้งาน ใครจะเป็นผู้เทรนซ้ำ ด้วยความถี่เท่าไร และด้วยทีมงานแบบใด และคู่สัญญาเป็นนิติบุคคลไทยหรือนิติบุคคลญี่ปุ่น

ทำไมต้องถาม ตรวจสอบชั้นที่ 5 และประตูทางเข้าเรื่องภาษีและกฎหมายไปพร้อมกัน

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

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

6 รูปแบบความล้มเหลวที่พบบ่อย

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

รูปแบบที่ 1 ค้างอยู่ที่ PoC แล้วดองทิ้งไว้อย่างนั้น

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

มาตรการรับมือ ตกลงเป็นลายลักษณ์อักษรก่อนเริ่ม PoC ว่าตัวเลขใดต้องถึงระดับใดจึงจะเดินเข้าขั้นตอนพัฒนา และเขียนขั้นตอนการยุติในกรณีที่ไม่เดินต่อไปพร้อมกัน

รูปแบบที่ 2 ตีความคำว่า “ความแม่นยำ” ไม่ตรงกันในวันตรวจรับงาน

สาเหตุ ในสัญญาเขียนไว้แค่ตัวชี้วัดความแม่นยำที่ไม่มีตัวส่วน

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

รูปแบบที่ 3 โมเดลสร้างเสร็จ แต่เชื่อมกับระบบงานไม่ได้

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

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

รูปแบบที่ 4 ผ่านไปครึ่งปีความแม่นยำตกลง แล้วไม่มีใครซ่อมได้

สาเหตุ ทีมของชั้นที่ 5 การปฏิบัติการและเทรนซ้ำ ไม่ได้รวมอยู่ในสัญญา วิศวกรที่พัฒนาย้ายไปโครงการอื่น และไม่มีขั้นตอนการเทรนซ้ำหลงเหลือไว้

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

รูปแบบที่ 5 เปลี่ยนผู้พัฒนาระบบไม่ได้

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

มาตรการรับมือ นำรายการรูปแบบการส่งมอบจากหัวข้อการถือครองสิทธิลงไปในสัญญา และระบุ background IP กับ foreground IP แยกจากกัน

รูปแบบที่ 6 ปัญหาภาษีโผล่ขึ้นมาก่อนเปิดใช้งานไม่นาน

สาเหตุ ประเด็นภาษีมูลค่าเพิ่มแบบ reverse charge และ ภ.ง.ด.54 ที่มากับการจ่ายเงินให้ผู้พัฒนาระบบต่างประเทศ ถูกค้นพบหลังลงนามสัญญาแล้ว เมื่อไม่มีข้อสัญญาแบบ gross-up จึงเถียงกันว่าใครรับภาระ

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

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

แผนดำเนินการ 90 วัน

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

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

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

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

บริษัทพัฒนา AI กับบริษัทที่ปรึกษา AI ต่างกันอย่างไร

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

ทำไมใบเสนอราคาของบริษัทรับพัฒนา AI จึงต่างกันมากในแต่ละบริษัท

ตัวการหลักไม่ใช่ความต่างของอัตราค่าบริการต่อคน-วัน แต่คือ ความต่างของขอบเขตในใบเสนอราคา อย่างที่เห็นในหัวข้อเรื่อง 5 ชั้น การที่ชั้นที่ 4 การเชื่อมต่อระบบเดิมและออกแบบสิทธิ์ กับชั้นที่ 5 การปฏิบัติการและเทรนซ้ำ รวมอยู่ด้วยหรือไม่ ทำให้ยอดรวมเปลี่ยนไปมาก นอกจากนี้ การที่ข้อตั้งต้นของชั้นที่ 2 ต่างกันก็เป็นปัจจัยใหญ่ บริษัทที่เสนอราคาบนสมมติฐานว่า “ข้อมูลจัดเตรียมมาแล้ว” กับบริษัทที่เสนอราคาบนสมมติฐานว่า “เริ่มจากแก้การเขียนที่ไม่ตรงกันก่อน” จะให้จำนวนคน-วันคนละเรื่องกันสำหรับโครงการเดียวกัน เวลาเปรียบเทียบ อย่าเอาตัวเลขมาเรียงกัน แต่ให้ติดป้ายกำกับบรรทัดตาม 5 ชั้น แล้วปรับขอบเขตให้เท่ากันก่อนจึงค่อยเทียบ พอปรับขอบเขตให้เท่ากันแล้ว ส่วนใหญ่ส่วนต่างของราคาจะเล็กกว่าที่จินตนาการไว้

จะ outsource AI หรือพัฒนาระบบ AI เองภายในองค์กร แบบไหนคุ้มกว่ากัน

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

สัญญาพัฒนา AI ทำเป็นสัญญาจ้างทำของไม่ได้จริงหรือ

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

ค่าใช้จ่ายพัฒนา AI ส่วนไหนแกว่งมากที่สุด

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

จ้างพัฒนา AI ควรเริ่มปรึกษาตั้งแต่ขั้นตอนไหน

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

สรุป

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

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

1. ประเภทสัญญา สัญญาจ้างทำของหรือแบบ jun-inin ถ้าเป็น jun-inin เป็นแบบคิดตามสัดส่วนงานที่ทำหรือแบบส่งมอบผลงาน และเขียนนิยามของคำว่า “สำเร็จ” ให้ครบได้หรือไม่
2. วิธีแบ่งขั้นตอน แบ่งเป็น 4 ขั้นตอน คือ ประเมินความเป็นไปได้ PoC พัฒนา และเทรนเพิ่มเติม พร้อมวางเงื่อนไขเข้าและเงื่อนไขออกในทุกขั้นตอน เพื่อสร้างจุดที่หยุดได้
3. เงื่อนไขการตรวจรับงาน ระบุตัวส่วนของความแม่นยำให้ชัด ตรึงชุดข้อมูลสำหรับตรวจรับงานไว้ในเอกสารแนบ และเขียนด้วยตัวชี้วัดทางธุรกิจ คือจำนวนรายการและจำนวนชั่วโมงของงานที่คนยังต้องทำ
4. การถือครองสิทธิ แยก foreground IP ออกจาก background IP และกำหนดแยกเป็น 4 สิ่ง คือ ข้อมูลดิบ ชุดข้อมูลสำหรับเทรน โมเดลที่ผ่านการเทรนแล้ว และโมเดลต่อยอด พร้อมยืนยันให้ได้เสมอว่านำไปใช้ซ้ำกับโครงการของลูกค้ารายอื่นได้หรือไม่

หากสั่งงานจากประเทศไทย จะมีเรื่องเพิ่มเข้ามาคือการเลือกคู่สัญญา การปฏิบัติเกี่ยวกับภาษีหัก ณ ที่จ่าย ภาษีมูลค่าเพิ่ม และกลไก reverse charge รวมถึงการแบ่งงานรับผิดชอบหากร่างกฎหมาย AI ของไทยที่ยังไม่มีผลบังคับใช้มีผลขึ้นมา เรื่องภาษีและกฎหมายกรุณาตรวจสอบกับผู้เชี่ยวชาญเสมอ

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

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

แหล่งอ้างอิง

• METI, Contract Guidelines on the Use of AI and Data (published June 2018, partially revised December 2019), AI volume — https://www.meti.go.jp/policy/mono_info_service/connected_industries/sharing_and_utilization/20180615001-3.pdf
• METI, Checklist on contracts for the use and development of AI (published 18 February 2025), source PDF — https://www.meti.go.jp/policy/mono_info_service/connected_industries/sharing_and_utilization/20250218003-ar.pdf
• The same, press release — https://www.meti.go.jp/press/2024/02/20250218003/20250218003.html
• Overview material on the contract guidelines (January 2021, METI Information Economy Division) — https://www.jftc.go.jp/cprc/conference/index_files/21011902.pdf
• Logit Partners Law and Accounting Office, commentary on METI’s checklist on contracts for the use and development of AI — https://partners.logit.jp/ai-checkliist-meti/
• Japan Patent Office, IP BASE, “Contract types in AI development” — https://ipbase.go.jp/learn/point/ai/page05.php
• JETRO, “Thailand: Tax System” (corporate income tax 20%, VAT 7%, withholding tax) — https://www.jetro.go.jp/world/asia/th/invest_04.html
• HLB Thailand, “Cabinet Approves Extension of Tax Measures to End of 2027” (e-Withholding Tax reduced rate of 1%, 1 January 2026 to 31 December 2027) — https://www.hlbthai.com/cabinet-approves-extension-of-tax-measures-to-end-of-2027-to-promote-adoption-of-electronic-tax-systems/
• Mahanakorn Partners, “Thailand Approves Two-Year Extension of Electronic Tax System Incentives” — https://mahanakornpartners.com/thailand-approves-two-year-extension-of-electronic-tax-system-incentives/
• JGA, “Payments to overseas suppliers and reverse-charge VAT (P.P.36)” — https://jga.asia/?p=1241
• Mondaq, “Thailand Releases New Draft Artificial Intelligence Act” (ETDA draft published 2 July 2026; not yet enacted) — https://www.mondaq.com/it-and-internet/1811290/thailand-releases-new-draft-artificial-intelligence-act
• Tilleke & Gibbins, “Thailand’s AI Governance Framework” — https://www.tilleke.com/insights/comprehensive-policy-thailands-ai-governance-framework/