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

เมื่อวันที่ 19 กุมภาพันธ์ 2026 OECD เผยแพร่แนวทาง Due Diligence สำหรับ Responsible AI โดยเสนอวงจร 6 ขั้น ตั้งแต่ฝังความรับผิดชอบในนโยบาย ประเมินผลกระทบ ป้องกันและบรรเทา ติดตามผล สื่อสาร ไปจนถึงการเยียวยา ส่วน NIST และ GSA ประกาศเมื่อ 18 มีนาคม 2026 ว่าจะพัฒนาวิธีประเมิน AI ก่อนและหลังใช้งานจริงสำหรับการจัดซื้อภาครัฐของสหรัฐฯ

“การจัดซื้อ” ต้องเป็นด่านควบคุมตลอดอายุระบบ ไม่ใช่เพียงการเลือกผู้ขาย บทความนี้เสนอกรอบ TOR, RFP และสัญญาสำหรับองค์กรไทย โดยควรให้กฎหมาย จัดซื้อ IT Security, DPO และเจ้าของกระบวนงานปรับใช้ตามบริบท

ทำไมการซื้อ AI จึงต่างจากการซื้อซอฟต์แวร์ทั่วไป

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

ความเสี่ยงอยู่ตลอด AI Value Chain ตั้งแต่ข้อมูล การเชื่อม API และการอนุมัติของมนุษย์ ไปจนถึงการเปลี่ยนเวอร์ชันหลังเซ็นสัญญา

OECD Due Diligence Guidance for Responsible AI ระบุชัดว่าองค์กรต้องพิจารณาทั้งกิจกรรมของตนและความสัมพันธ์ทางธุรกิจในห่วงโซ่ AI ขณะที่คณะทำงานของสหภาพยุโรปจัดทำ EU AI Model Contractual Clauses แยกฉบับเต็มสำหรับระบบความเสี่ยงสูงและฉบับปรับแต่งสำหรับระบบที่ไม่ใช่ความเสี่ยงสูง

4 เอกสารที่ต้องมี ก่อนออก TOR

  • AI Use Case Brief: ปัญหา ผู้ใช้ ผู้ได้รับผลกระทบ ผลลัพธ์ และสิ่งที่ AI ห้ามตัดสินใจ
  • Data Flow Map: ข้อมูลที่ใช้ ปลายทาง ผู้เข้าถึง ระยะเวลาเก็บ และผู้รับจ้างช่วง
  • Evaluation Protocol: Baseline, Acceptance Threshold, ชุดทดสอบ และวิธีตรวจคุณภาพเดียวกันสำหรับผู้ขายทุกราย
  • Risk and Exit Plan: ความเสี่ยง ผู้มีอำนาจหยุดระบบ งานทดแทน และวิธีย้ายข้อมูลเมื่อเปลี่ยนผู้ขาย

12 ข้อกำหนดที่ควรอยู่ใน TOR และสัญญา AI

1. วัตถุประสงค์และขอบเขตการใช้

กำหนด Intended Purpose, ผู้ใช้ ข้อมูล ระบบปลายทาง และ Prohibited Use แยกงาน “ช่วยร่าง” ออกจากงาน “อนุมัติหรือตัดสินใจ”

2. สิทธิในข้อมูลและวัตถุประสงค์การประมวลผล

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

3. ที่ตั้งข้อมูลและผู้รับจ้างช่วง

ให้เปิดเผย Data Residency, Cloud Region, Model Provider และ Subprocessor พร้อมแจ้งก่อนเปลี่ยนคู่ค้าสำคัญ เพื่อประเมิน PDPA และข้อจำกัดเฉพาะอุตสาหกรรม

4. เกณฑ์คุณภาพที่ตรวจรับได้

อย่าใช้คำว่า “แม่นยำสูง” โดยไม่มีนิยาม กำหนดตัวชี้วัดตามงาน เช่น Error Rate, Citation Accuracy, Completion Rate, เวลา และสัดส่วนงานที่มนุษย์ต้องแก้ พร้อมชุดทดสอบภาษาไทย

5. การทดสอบความทนทานและความเสี่ยง

กำหนดการทดสอบ Hallucination, Prompt Injection, Data Leakage, Bias และกรณีนอกขอบเขต ผู้ขายต้องส่งผลทดสอบ วิธีแก้ และข้อจำกัด

6. Human Oversight และสิทธิหยุดระบบ

ระบุจุดที่คนต้องตรวจ ผู้อนุมัติ การ Override, Rollback และ Kill Switch โดยเฉพาะงานที่มีผลกระทบสูง

7. Security และการแจ้งเหตุ

กำหนดการควบคุมสิทธิ์ การเข้ารหัส การแยก Tenant การจัดการช่องโหว่ และกรอบเวลาแจ้ง Incident พร้อมผู้ประสานงานและหลักฐานหลังแก้ไข

8. Logging, Audit และ Evidence

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

9. การเปลี่ยนโมเดลและ Change Control

กำหนด Material Change, ระยะเวลาแจ้ง การทดสอบซ้ำ และสิทธิชะลอหรือยกเลิกเมื่อการเปลี่ยนโมเดลกระทบคุณภาพหรือความเสี่ยง

10. ทรัพย์สินทางปัญญาและสิทธิใช้ผลลัพธ์

ระบุสิทธิใน Input, Prompt, Configuration, Fine-tuned Asset และ Output รวมถึงกระบวนการรับเรื่องลิขสิทธิ์ โดยให้ฝ่ายกฎหมายตรวจตามกรณี

11. ความต่อเนื่อง การย้ายออก และ Vendor Lock-in

กำหนด SLA, Backup, Export Format, API Portability, การส่งคืนข้อมูล และการสนับสนุนช่วงเปลี่ยนผ่าน รวมถึง Vector Database และ Evaluation Set

12. ความรับผิด การเยียวยา และการปรับปรุง

เชื่อมเหตุผิดสัญญากับ Root Cause Analysis, Corrective Action, Service Credit และการเยียวยาที่ได้สัดส่วนกับบทบาทและความเสี่ยง

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

Scorecard 100 คะแนน: เลือกจากคุณค่า ไม่ใช่ Demo

เสนอให้จัดน้ำหนักดังนี้

  • Business Outcome 25 คะแนน: ผลลัพธ์เชื่อม KPI, Baseline และต้นทุนรวม
  • Performance and Evidence 20 คะแนน: ผลทดสอบบนข้อมูลตัวแทนและข้อจำกัดที่เปิดเผย
  • Governance and Accountability 20 คะแนน: เจ้าภาพ การกำกับ Human Oversight, Audit และ Incident
  • Security and Privacy 15 คะแนน: Architecture, Access, Data Flow และ Subprocessor
  • Integration and Operations 10 คะแนน: API, Workflow, Support, Monitoring และทักษะทีม
  • Commercial and Exit 10 คะแนน: TCO, เงื่อนไขเปลี่ยนราคา สิทธิในสินทรัพย์ และการย้ายออก

กำหนด Minimum Gate สำหรับ Security, Privacy และคุณภาพ แม้คะแนนรวมสูงก็ไม่ควรผ่านหากตกเกณฑ์สำคัญ

จาก PoC สู่ Production ต้องผ่าน 3 Gates

Gate 1: Evidence

ทดสอบกับ Baseline และข้อมูลตัวแทนเดียวกัน พร้อมเปิดเผยข้อผิดพลาด

Gate 2: Control

ตรวจ Data Flow, สิทธิ์, Human Approval, Logging, Incident และ Rollback ก่อนเชื่อมระบบสำคัญ

Gate 3: Value

วัดเวลา ต้นทุน คุณภาพ ความเสี่ยง และ Adoption หากเพิ่มภาระตรวจหรือค่า Cloud สูง ต้องปรับก่อนขยาย

NIST–GSA collaboration เน้นทั้ง Pre-deployment Assessment และ Post-deployment Performance ใน Workflow จริง สอดคล้องกับหลักว่า Acceptance Test ครั้งเดียวไม่เพียงพอสำหรับระบบที่เปลี่ยนแปลงต่อเนื่อง

Red Flags ที่ฝ่ายจัดซื้อไม่ควรมองข้าม

  • ไม่ยอมเปิดเผย Model Provider หรือ Subprocessor
  • รับประกันความแม่นยำ แต่ไม่ยอมทดสอบกับข้อมูลขององค์กร
  • เปลี่ยนโมเดลได้ฝ่ายเดียวโดยไม่แจ้ง
  • ใช้ข้อมูลลูกค้าเพื่อฝึกโมเดลโดยมีเงื่อนไขคลุมเครือ
  • ไม่มี Export, Exit Assistance หรือวิธีลบข้อมูลที่ตรวจสอบได้
  • อ้างว่า “ผ่านมาตรฐาน” แต่ไม่ระบุขอบเขต ใบรับรอง หรือวันที่
  • ไม่มีกระบวนการแจ้งเหตุ Root Cause และ Corrective Action

Roadmap 90 วัน

  • วัน 1–30 — Define: เลือก Use Case จัดระดับความเสี่ยง ทำ Data Flow, Baseline และตั้งคณะทำงานร่วม
  • วัน 31–60 — Compete: ออก TOR พร้อม Scorecard ให้ผู้ขายทดสอบด้วย Protocol เดียวกัน
  • วัน 61–90 — Validate: ทำ Pilot แบบจำกัดสิทธิ์ วัดคุณภาพ ต้นทุน และ Adoption ก่อนอนุมัติ Production

คำถามที่ผู้บริหารถามบ่อย

TOR สำหรับ AI คืออะไร

ข้อกำหนดที่เชื่อมวัตถุประสงค์ ข้อมูล เกณฑ์ทดสอบ ความเสี่ยง สิทธิ และการดำเนินงานตลอดอายุระบบ

PoC ต้องมีข้อกำหนดครบเท่า Production หรือไม่

ควรมีขั้นต่ำเรื่องข้อมูล ความลับ ความปลอดภัย การลบ และสิทธิในผลงาน ส่วน SLA เพิ่มเมื่อเข้าสู่ Production

จะรู้ได้อย่างไรว่าผู้ขายไม่ใช้ข้อมูลเราไปฝึกโมเดล

ตรวจสัญญา การตั้งค่า สถาปัตยกรรม Subprocessor และหลักฐานการควบคุม ไม่พึ่งคำตอบฝ่ายขายเพียงอย่างเดียว

ควรเลือกโมเดลที่คะแนน Benchmark สูงสุดหรือไม่

ไม่เสมอไป ต้องทดสอบกับภาษา ข้อมูล Workflow ต้นทุน ความเร็ว และความเสี่ยงจริงขององค์กร

ใครควรเป็นเจ้าของ AI Procurement

Business Owner รับผิดชอบผลลัพธ์ โดยอนุมัติร่วมกับจัดซื้อ IT Security, Data/DPO, กฎหมาย และผู้กำกับความเสี่ยง

บทสรุป

TOR และสัญญา AI ที่ดีไม่ใช่เอกสารเพื่อชะลอนวัตกรรม แต่ทำให้ผู้ซื้อและผู้ขายเห็นวัตถุประสงค์ หลักฐาน ความเสี่ยง และความรับผิดชอบตรงกัน องค์กรที่กำหนด Baseline, Evaluation Protocol, Change Control และ Exit Plan จะตัดสินใจจากคุณค่ามากกว่าความประทับใจจาก Demo

Top Growth Studio สนับสนุนองค์กรและหน่วยงานภาครัฐในการจัดทำ AI Use Case Portfolio, AI Procurement Scorecard, Governance Requirements, Pilot Evaluation และ ROI Dashboard เพื่อให้การลงทุน AI พร้อมขยายผลอย่างมีความรับผิดชอบ โดยสามารถเริ่มจากโครงการนำร่องหนึ่งโครงการก่อนวางมาตรฐานทั้งองค์กร

แหล่งข้อมูลอ้างอิง