จ้างพัฒนา AI อย่างไร: คู่มือ RFP สัญญา และการทดสอบรับมอบ

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

3 จุดควบคุมที่ต้องกำหนดก่อนจ้างพัฒนา AI

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

ควรกำหนด 3 จุดควบคุมต่อไปนี้เป็นระบบเดียวตั้งแต่ต้น

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

อย่าใช้ชื่อโมเดลและเดโมเป็นเกณฑ์หลัก

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

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

จึงควรเปรียบเทียบผู้ให้บริการจากหลักฐานต่อไปนี้

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

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

เขียน RFP งานพัฒนาระบบ AI จากสถานการณ์งาน

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

1. งานที่รวมและไม่รวมในขอบเขต

งานในขอบเขตควรระบุ Trigger, End condition, ผู้ใช้ แหล่งข้อมูล ปลายทาง ปริมาณโดยประมาณ ช่วงเวลาใช้งาน ภาษา และเจ้าของความรับผิดชอบ งานนอกขอบเขตควรระบุการตัดสินใจที่ AI ทำไม่ได้ การกระทำที่ต้องให้คนอนุมัติ ข้อมูลห้ามใช้ และบริษัท โรงงาน หรือกลุ่มผลิตภัณฑ์ที่ไม่รวม

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

2. สถานการณ์สำเร็จและล้มเหลว

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

3. แยก Non-functional requirement ให้เป็นภาษาของ AI

Performance ต้องครอบคลุมขนาดอินพุต Concurrent use การ Retry ขีดจำกัด API ภายนอก เพดานค่าใช้จ่าย และพฤติกรรมเมื่อ Timeout ไม่ใช่เฉพาะเวลาเฉลี่ย Availability ต้องวัด End-to-end ตั้งแต่แปลงเอกสาร ค้นหา ยืนยันตัวตน โมเดล เชื่อม ERP ไปจนถึงการอนุมัติของคน

ด้านความมั่นคง ควรรวม Identity, Encryption และ Vulnerability management แบบทั่วไปกับกรณี Prompt injection, Sensitive information disclosure, Excessive agency, Untrusted output ไปยังระบบปลายทาง ความเสี่ยง Supply chain และการใช้ทรัพยากรไม่จำกัด หน้าโครงการ OWASP ระบุ GenAI LLM Top 10 2026 ซึ่งเผยแพร่วันที่ 4 สิงหาคม 2026 เป็นฉบับปัจจุบัน แต่การติ๊ก Checklist ไม่ใช่หลักฐานรับมอบ ต้องกำหนดอินพุต สิทธิผู้ใช้ การเชื่อมต่อปลายทาง และสิ่งที่ห้ามเกิดสำหรับความเสี่ยงแต่ละข้อ

ทำชุดข้อมูลรับมอบให้เป็นผลงานตามสัญญา

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

แบ่งชุดข้อมูลเป็น 6 ชั้น

1. ข้อมูลตัวแทน: อินพุตที่พบมาก สมดุลตามโรงงาน แผนก ภาษา ชนิดเอกสาร และผู้ใช้
2. ข้อมูลขอบเขต: Part ใกล้เคียง อินพุตยาว ภาพเสื่อม การสะกดต่างกัน หลายภาษา และขอบเขตวันที่
3. ข้อมูลผิดพลาด: ข้อมูลหาย ขัดแย้ง ซ้ำ อ่านไม่ได้ หรือแหล่งอ้างอิงหยุดชั่วคราว
4. ข้อมูลความปลอดภัย: ขอข้อมูลเกินสิทธิ คำสั่งชักจูง ดึงข้อมูลลับ หรือขอการกระทำอันตราย
5. Regression: กรณีของข้อบกพร่องที่แก้แล้ว เพื่อป้องกันการเกิดซ้ำหลังอัปเดต
6. Holdout: กรณีที่ลูกค้าควบคุมและไม่เปิดก่อนการรับมอบสุดท้าย เพื่อจับการปรับเฉพาะเดโม

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

ประเมินผลลัพธ์ที่ไม่มีคำตอบเดียว

งาน Classification และ Extraction มักมี Label ชัด แต่ Summary, Q&A และข้อเสนออาจมีคำตอบเหมาะสมหลายแบบ จึงควรใช้สิ่งที่ต้องมี สิ่งต้องห้าม หลักฐาน โครงสร้าง และ Rubric ของคนร่วมกัน แทนการบังคับให้ข้อความตรงทุกตัวอักษร

คู่มือ evals ของ OpenAI ยกตัวอย่างการกำหนดการประเมินด้วย data_source_config และ testing_criteria โดยใช้ชุดทดสอบที่เป็นตัวแทนและ Ground truth จากคน แนวคิดที่นำไปใช้ได้กับทุกผู้ให้บริการคือ แยก “ข้อมูลประเมิน” ออกจาก “กฎผ่าน” ใส่ Version และรันซ้ำได้

ระบุหน้าที่การสร้างชุดข้อมูล

ผู้รับจ้างกำหนด “ความจริงทางธุรกิจ” คนเดียวไม่ได้ แต่หากลูกค้ากำหนดคนเดียวก็อาจสร้างเกณฑ์ที่วัดเชิงเทคนิคไม่ได้ รูปแบบที่ทำงานได้คือ เจ้าของกระบวนการกำหนด Scenario และผลกระทบ IT/Security กำหนดสภาพแวดล้อมและเงื่อนไขปลอดภัย ผู้รับจ้างเสนอวิธีวัดและ Automation แล้วร่วมกัน Freeze Baseline ก่อน Build

สัญญาควรระบุผู้จัดหาข้อมูลดิบ ผู้ทำ Anonymization/Label ผู้อนุมัติคุณภาพ และผู้รับต้นทุนเมื่อเพิ่มกรณี แม้ผู้รับจ้างจะทำข้อมูลประเมิน ลูกค้าควรเก็บ Holdout และมีอำนาจอนุมัติผลสุดท้าย

แยกเกณฑ์ประเมินบริษัทรับพัฒนา AI ออกจาก “ความแม่นยำเฉลี่ย”

ควรแยกผลลัพธ์ทางธุรกิจ คุณภาพ ความปลอดภัย การปฏิบัติการ และเศรษฐศาสตร์ ระบบอาจไม่ผ่านทันทีเมื่อ Critical case ผิดหนึ่งกรณี แม้ค่าเฉลี่ยสูงกว่าเกณฑ์ ในทางกลับกัน ควรกำหนดค่าคลาดเคลื่อนที่ยอมรับได้ เพื่อไม่ให้ความชอบด้านสำนวนทำให้ระบบทั้งหมดไม่ผ่าน

ตัวชี้วัดคุณภาพ

• Classification: ถูก ผิด และงดตอบ แยกตาม Class โดยดู Class สำคัญที่มีจำนวนน้อยต่างหาก
• Extraction: ฟิลด์ถูก หาย และผิด พร้อมน้ำหนักสำหรับ Equipment ID มูลค่า หรือข้อมูลวิกฤต
• Retrieval: เอกสารที่ต้องใช้ติดอันดับหรือไม่ ฉบับล่าสุดมาก่อนหรือไม่ และตัดเอกสารเกินสิทธิหรือไม่
• Generation: สอดคล้องหลักฐาน มีสิ่งจำเป็น ไม่มีสิ่งต้องห้าม ใช้ภาษาและรูปแบบตามกำหนด
• Workflow: อัตราส่งต่อ Rework เวลา จำนวนการตรวจ และอัตราจบกระบวนการ

Gate ด้านความปลอดภัยและการควบคุม

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

Human oversight ต้องมากกว่า “มีคนดูตอนท้าย” ต้องทดสอบเงื่อนไข Auto/Review ใครอนุมัติหรือปฏิเสธได้ และการตัดสินถูกบันทึกหรือไม่ แนวทาง ETDA ยกตัวอย่างการให้คนตรวจ รับ หรือปฏิเสธผล Generative AI เพื่อลดการพึ่งพามากเกินไป

วิธีตั้งเกณฑ์ผ่านอย่างใช้งานได้

RFP ไม่จำเป็นต้องเดาตัวเลขตั้งแต่วันแรก แต่อาจกำหนดวิธีว่า วัด Baseline ตอนเริ่ม PoC ให้เจ้าของงานอนุมัติ Critical case และ Tolerance แล้ว Freeze Acceptance plan ก่อน Build ค่าจริงควรอิงข้อมูลจริง ความเสี่ยง อัตราผิดของกระบวนการปัจจุบัน และกำลังคนตรวจ

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

วาดขอบเขตข้อมูล โมเดล พรอมต์ และผลงาน

แอป AI มักไม่ได้มีเฉพาะโค้ดผู้รับจ้าง แต่อาจรวม Cloud, Foundation/Embedding model, Retrieval, Document parsing, Monitoring, OSS และ API ภายนอก ควรขอ Data flow และ Responsibility map หนึ่งหน้าตั้งแต่อินพุตถึงเอาต์พุต

Component register ที่ขอใน RFP

ข้อความว่า “ไม่ใช้ข้อมูลลูกค้าฝึกโมเดล” ยังไม่อธิบาย Embedding, Log, การวิเคราะห์ปัญหา การปรับปรุงบริการ การส่ง Third party และ Backup อย่าใช้คำว่า Training ครอบทุกอย่าง ให้ตรวจวัตถุประสงค์ ปลายทาง การเก็บ การใช้ซ้ำ และการลบของแต่ละ Flow

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

ผลงานและทรัพย์สินทางปัญญา

คำว่า “ส่งมอบผลงานทั้งหมด” กว้างเกินไป ควรระบุ Source code, Infrastructure/Environment config, Prompt, Tool definition, Retrieval config, Schema, Evaluation script, Test case, คู่มือปฏิบัติ Architecture, Component inventory, Known limitation และทรัพย์สินที่ Train/Tune หากมี

แยกทรัพย์สินเดิมกับงานใหม่ และให้ฝ่ายกฎหมายยืนยันสิทธิใช้ แก้ไข ให้บุคคลอื่นดูแล และใช้ต่อหลังสัญญา รวมทั้งเงื่อนไข Third party ลูกค้าอาจไม่ได้เป็นเจ้าของ Foundation model แต่ลด Lock-in ได้ด้วย Interface, Evaluation asset, Configuration และ Data export ที่รองรับการเปลี่ยนโมเดล

ETDA แบ่งรูปแบบเป็น Adopter, Customizer และ Maker ตามความซับซ้อน การใช้บริการสำเร็จรูปต่างจากการทำ RAG/Fine-tuning และต่างจากการสร้าง Foundation model ในด้านสิทธิ หลักฐาน และทักษะ RFP ควรระบุบทบาทที่ใกล้เคียง ไม่รวมทุกอย่างไว้ในคำว่า “พัฒนา AI”

แปลง Secure development เป็นคำถามจัดซื้อ

NIST อธิบาย SSDF ว่าเป็นภาษากลางที่ผู้ผลิตและผู้จัดซื้อซอฟต์แวร์ใช้ใน Procurement และ Management โดยแบ่งเป็น Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW) และ Respond to Vulnerabilities (RV)

NIST SP 800-218A เป็น SSDF Community Profile สำหรับ Generative AI และ Dual-use foundation model ไม่ควรยกทุกข้อของผู้สร้าง Foundation model ไปบังคับโครงการ RAG ขนาดเล็กโดยไม่วิเคราะห์ ควรเลือกตามบทบาท Adopter/Customizer/Maker และผู้สร้างแต่ละองค์ประกอบ

สถานการณ์รับมอบ Security เฉพาะ AI

• ฝังคำสั่งให้ละเลยกฎในเอกสาร แล้วพยายามดึงข้อมูลหรือสั่งงานเกินสิทธิ
• ใช้บัญชีสิทธิต่ำค้นข้อมูลอีกโรงงาน บริษัท หรือแผนก
• แทรก SQL, URL, Code หรือคำสั่งในเอาต์พุต และยืนยันว่าระบบปลายทางไม่รันโดยไม่ตรวจ
• ส่ง Request ใหญ่และซ้ำ เพื่อทดสอบ Limit, Timeout, Cost guard และ Safe stop
• ปิดโมเดล ระบบค้นหา หรือ ERP แล้วตรวจ Error, Retry และป้องกันรายการซ้ำ
• อัปเดตโมเดลหรือพรอมต์ แล้วตรวจว่า Version ไม่อนุมัติเข้าผลิตไม่ได้

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

รายการปฏิบัติในสัญญา PO และ SOW

รายการต่อไปนี้เป็นหัวข้อปฏิบัติ ไม่ใช่ข้อความกฎหมายสำเร็จรูป ควรตกลงในสัญญา PO, SOW หรือ Acceptance plan และให้ผู้เชี่ยวชาญปรับตามคู่สัญญา กฎหมาย ข้อมูล และอุตสาหกรรมจริง

ผลลัพธ์และขอบเขต

• กระบวนการ บริษัท/โรงงาน ผู้ใช้ ภาษา และระบบที่เชื่อม
• Phase ของ PoC, Production, Migration, Stabilization, Support และ Gate จบแต่ละช่วง
• Deliverable, Editable original, Repository, Format และวันที่ส่ง
• งานที่ลูกค้า/ผู้รับจ้างต้องเตรียม ข้อมูล Environment และกำหนดตัดสินใจ
• งานนอกขอบเขต วิธีคิด Change และผู้อนุมัติลำดับความสำคัญ

การรับมอบและเมื่อไม่ผ่าน

• ชุดรับมอบ ผู้เก็บ ส่วนที่เปิดเผย และ Version control
• Metric, Critical gate, Tolerance และ Human assessor
• Test environment จำนวนรัน เงื่อนไขทำซ้ำ และรูปแบบหลักฐาน
• Severity ของบั๊ก การแก้ Retest Conditional acceptance และ Known limitation
• การเปลี่ยนโมเดลหรือบริการที่ทำให้ต้องประเมินใหม่

ข้อมูล Security และ Third party

• Data flow, Location, Access, Encryption, Log, Retention, Return/Delete
• External service, Subcontractor, OSS, Model, License และ Change notice
• วัตถุประสงค์ที่แต่ละผู้ให้บริการใช้ Data, Input, Output, Log ได้
• ช่องรายงานช่องโหว่ แจ้งเหตุ สนับสนุนสอบสวน เก็บหลักฐาน แก้ และ Mitigation
• Least privilege, Secret management, Environment separation และ Admin audit

Operations, Change และ Cost

• เวลาบริการ ช่อง Support, Incident severity, Response และ Restore goal
• Quality, Abstention, Escalation, Latency, Usage และ Cost metric
• Change request/approval ของ Prompt, Model, Retrieval, Tool และ Threshold
• ผู้รับผิดชอบค่า External fee, Exchange rate, Volume, Reevaluation และ Emergency
• Service review, Report, Improvement backlog, Training และ Document update

ทดสอบ Monitoring และ Change control ก่อนรับมอบ

คุณภาพ AI เปลี่ยนตาม Input distribution, Revision เอกสาร คำถามผู้ใช้ โมเดล Retrieval index และกฎธุรกิจ จึงไม่พอที่จะบอกว่า “แม่นตอนส่งมอบ” ต้องรันขั้นตอน Monitoring และ Response จริงเป็นส่วนหนึ่งของ Acceptance

สัญญาณ 5 ประเภท

1. ธุรกิจ: Completion, Escalation, Reject, Processing time และ Adoption ตามแผนก
2. คุณภาพ: คำตอบไม่มีหลักฐาน Misclassification ฟิลด์สำคัญหาย Feedback และ Regression
3. ความปลอดภัย: Access denial, Prohibited input, Masking, Tool call ผิดปกติ และ Audit event หาย
4. เทคนิค: Latency, Error, External API, Retrieval failure, Queue, Limit และ Rollback readiness
5. เศรษฐศาสตร์: Cost ต่อกรณี Retry อินพุตยาว Storage แรงงานตรวจ และ Budget variance

ทุก Alert ต้องมี Owner, เวลาตอบสนอง การตัดสินใจ และผู้มีอำนาจ Stop Dashboard ที่ไม่มีขั้นตอนตัดสินและสื่อสารไม่ใช่การควบคุม

แบ่งการเปลี่ยนเป็น 4 ระดับ

• Minor: แก้ข้อความหรือหน้าจอ จำกัดขอบเขต Regression ได้
• Standard: เปลี่ยน Prompt, Retrieval, Threshold หรือ Ingestion ต้องประเมินกรณีที่เกี่ยวข้อง
• Major: เปลี่ยน Model, Processing location, External service, Tool privilege หรือ Decision scope ต้องอนุมัติ Risk/Legal/Security ใหม่
• Emergency: Stop หรือ Rollback เพราะช่องโหว่/เหตุการณ์ แล้วทำ Review และแก้ถาวร

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

NIST AI RMF Generative AI Profile เป็นทรัพยากรสมัครใจสำหรับนำความน่าเชื่อถือเข้าไปใน Design, Development, Use และ Evaluation ส่วน Concept Note ปี 2026 ของ NIST สำหรับ AI ที่น่าเชื่อถือในโครงสร้างพื้นฐานสำคัญ เน้นการมีส่วนร่วมข้าม Sector, Role และ Supply chain ข้อสรุปเชิงปฏิบัติสำหรับโรงงานคือ ต้องบริหาร Lifecycle ที่รวมเครื่องจักร กระบวนการ ซัพพลายเออร์ และผู้ใช้ ไม่ใช่ดูโมเดลเดี่ยว ทั้งนี้ Concept Note ยังเป็นโครงการต่อเนื่อง ไม่ใช่มาตรฐานเสร็จสมบูรณ์

ออกแบบ Exit transfer ตั้งแต่ก่อนเดือนสุดท้าย

หากรวบรวมของส่งมอบตอนสัญญาจะจบ สิทธิ ชุดประเมิน ประวัติพรอมต์ และสัญญาภายนอกอาจไม่ครบ ควรขอ Exit plan ใน RFP และอัปเดตตอน Design review, Acceptance และ Service review

ชุดส่งมอบขั้นต่ำ

• Source, Config, Prompt, Tool definition และ Schema เวอร์ชันล่าสุดกับ Stable ก่อนหน้า
• Architecture, Data flow, Dependency, Component/License register และสัญญาภายนอก
• Build, Deploy, Backup, Recovery, Monitoring, Incident และ Access procedure
• Acceptance/Regression dataset, Grading, ประวัติรายกรณี และ Known limitation
• Retrieval content, วิธีสร้าง Index ใหม่ ประวัติ Update/Delete และวิธีแสดง Evidence
• Open defect, Vulnerability, Planned change, Cost, Account, Certificate และ Renewal date
• Data/Log export ของลูกค้าและหลักฐาน Return/Delete

อย่าตรวจเพียงว่าเอกสารมีอยู่ ให้ลูกค้าหรือผู้ดูแลอีกคนสร้าง Non-production environment และรันกรณีตัวแทน การเปลี่ยน Vendor อาจยังยาก แต่การเก็บ Evaluation asset, Data และ Interface ที่แยกส่วนจะช่วย Business continuity และอำนาจต่อรอง

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

Scorecard เปรียบเทียบผู้รับจ้างพัฒนา AI

ให้คะแนนหลักฐาน ไม่ใช่ความสวยของ Presentation และปรับน้ำหนักตามความเสี่ยง

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

วิธีนำ AI มาใช้ 8 ขั้นตอน ตั้งแต่ RFP ถึงรับมอบ

1. ตั้งเจ้าของธุรกิจ และเขียนขอบเขต สิ่งไม่รวม ผลกระทบเมื่อผิด และจุดตัดสินของคน
2. วาด Data flow และระบุ Personal, Confidential, Transfer, Third-party และ Privilege
3. เตรียม Representative, Edge, Error, Safety, Regression และ Holdout case
4. ตกลง Metric, Critical gate, Tolerance, Assessor, Evidence และ Retest trigger
5. ขอ Component register, Development evidence, Operation, Change และ Exit plan ใน RFP
6. ใช้ PoC ทดสอบ Workflow, People, Security, Economics และ Recovery ควบคู่คุณภาพ
7. ก่อน Production ซ้อม Monitoring, Rollback, Incident, Change approval, Training และ Transfer
8. หลัง Go-live รัน Regression ซ้ำและอัปเดต Risk/Document ทุกครั้งที่เปลี่ยน

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

FAQ เรื่องการจ้างพัฒนา AI

ควรเลือกผู้รับจ้างจากความแม่นยำของโมเดลหรือไม่?

Benchmark ของโมเดลใช้ประกอบได้แต่ไม่พอ ต้องเปรียบเทียบผล End-to-end ด้วยกรณีปกติ ขอบเขต ผิดปกติ และความปลอดภัยของงานจริง รวม Retrieval, Permission, Integration และ Human review เลือกผู้ให้บริการที่ส่งผลรายกรณีและวิธีทำซ้ำได้

สิ่งสำคัญที่สุดในสัญญา AI รับจ้างพัฒนาคืออะไร?

ไม่ใช่ข้อเดียว แต่คือการเชื่อม Acceptance, ขอบเขต Data/Deliverable/Third party, Operation change และ Exit transfer หากไม่ชัดว่าใช้ข้อมูลใด ใครตัดสิน และหลักฐานใดหมายถึงงานเสร็จ ความเข้าใจสองฝ่ายจะต่างกัน ข้อความกฎหมายต้องให้ผู้เชี่ยวชาญตรวจตามโครงการ

ควรเปิดข้อมูล AI PoC ทั้งหมดให้ผู้รับจ้างหรือไม่?

สามารถแยก Development กับ Evaluation และเก็บ Holdout ภายใต้ลูกค้า พร้อมตรวจสิทธิ Anonymization การส่งอย่างปลอดภัย และคุณภาพ Label ความลับอย่างเดียวไม่ทำให้ชุดทดสอบดี ต้องเป็นตัวแทนของ Production ด้วย

ถ้าความแม่นยำลดหลัง Go-live ควรทำอย่างไร?

Monitor สัญญาณ Quality/Business แล้วแยกการเปลี่ยนของ Input, Document, Model, Prompt, Retrieval และ External service อนุมัติการแก้ รัน Regression และมีขั้นตอนกลับ Stable version ก่อนหน้า

วิธีนำ AI มาใช้ควรเริ่มด้วยสัญญา Production เต็มรูปแบบหรือไม่?

งานเสี่ยงสูงควรแบ่ง Business definition, Data preparation, PoC, Production และ Stabilization พร้อม Gate ตัดสินใจทุกช่วง แต่ไม่ควรทิ้ง PoC; Evaluation asset, Data flow และ Operation criteria ต้องยกไป Production ได้

เมื่อมีข้อมูลส่วนบุคคลในไทย ต้องตรวจอะไร?

ทำแผน Data field, Purpose, Role, Access, Location, Subcontractor, Retention, Delete และ Incident response แล้วให้ผู้เชี่ยวชาญกฎหมาย/Privacy ไทยตรวจตามความสัมพันธ์จริง อย่าสรุปจากชื่อระบบหรือ Cloud region เพียงอย่างเดียว

สรุป: จ้างซื้อระบบที่ตรวจรับ เปลี่ยน และส่งต่อได้

การจ้างพัฒนา AI ควรได้มากกว่าเดโมหรือสิทธิใช้โมเดลชื่อดัง ประการแรก ต้องได้ชุดข้อมูลรับมอบตามสถานการณ์และเกณฑ์ผ่าน ประการที่สอง ต้องชัดเจนเรื่องสิทธิและขอบเขตของข้อมูล โมเดล พรอมต์ โค้ด ผลลัพธ์ Log และ Third party ประการที่สาม ต้องได้ทรัพย์สินปฏิบัติการสำหรับ Monitoring, Change approval, Recovery และ Transfer

เมื่อ 3 จุดนี้เชื่อมจาก RFP ไปสัญญาและ Acceptance ลูกค้าจะใช้มาตรฐานธุรกิจเดิมตัดสินได้แม้โมเดลหรือผู้ให้บริการเปลี่ยน หากหลักฐานงานเสร็จมีเพียงเดโมครั้งเดียว การควบคุมคุณภาพที่ลด ค่าเพิ่ม การโยนความรับผิดชอบ และ Vendor lock-in จะยากขึ้น เริ่มจากกระบวนการเล็กได้ แต่ควรเขียน Acceptance case, Prohibited result, Data flow, Change procedure และ Transfer package ตั้งแต่วันแรก

TOMAS TECH สนับสนุนโรงงานในไทยและอาเซียนได้ตั้งแต่ก่อนเลือกผู้รับจ้าง ทั้งการจัดกระบวนการ เตรียม RFP เกณฑ์รับ AI PoC การเชื่อมข้อมูล/ระบบหลัก การควบคุมงานจริง และแผนส่งมอบ แม้ยังไม่เลือกโมเดลหรือ Vendor ก็สามารถเริ่มจาก Workflow ปัจจุบันและผลกระทบเมื่อผิดได้ ติดต่อ TOMAS TECH

ข้อมูลอ้างอิง

1. ETDA: AI 2026 “Driving Trust AI Governance”
2. ETDA: Generative AI Governance Guideline for Organizations
3. NIST: AI RMF Generative AI Profile
4. NIST: Concept Note for Trustworthy AI in Critical Infrastructure
5. NIST: Secure Software Development Framework
6. NIST SP 800-218A
7. OWASP: Top 10 for Large Language Model Applications
8. OpenAI: Working with evals
9. กรมที่ดิน: หน้าประกาศทางการของพระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562