ประเมินผู้ให้บริการ AI ก่อนซื้อ: คู่มือ Due Diligence สำหรับองค์กรไทย

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

AI vendor due diligence คือการตรวจสอบความเหมาะสมของผู้ให้บริการต่อ use case เฉพาะ โดยรวบรวมหลักฐานด้านข้อมูล ความปลอดภัย ประสิทธิภาพ การกำกับดูแล และเงื่อนไขสัญญา บทความนี้เป็นกรอบการทำงานสำหรับผู้บริหารและทีมข้ามสายงาน ไม่ใช่คำวินิจฉัยทางกฎหมายหรือใบรับรองว่าผู้ให้บริการรายใดปลอดภัยเสมอไป

1. ระบุการตัดสินใจที่ AI จะมีอิทธิพล

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

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

2. วาดเส้นทางข้อมูลและสิทธิ์ใช้งาน

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

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

3. ตรวจผู้ให้บริการและห่วงโซ่พึ่งพา

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

ใบรับรองและรายงานตรวจประเมินช่วยคัดกรองได้ แต่ไม่แทนการทดสอบ use case ขององค์กร ตรวจขอบเขต วันที่ และข้อยกเว้นของเอกสารทุกฉบับ โดยเฉพาะเมื่อผู้ขายอ้างมาตรฐาน ISO/IEC 42001 ซึ่งเป็นกรอบระบบบริหารจัดการ AI ไม่ใช่การรับประกันว่าทุกคำตอบของผลิตภัณฑ์ถูกต้องเสมอ

4. ทดสอบด้วยข้อมูลตัวแทนก่อนตัดสินใจ

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

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

5. ผูกคำมั่นสัญญากับสิทธิในสัญญา

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

วางแผนเลิกใช้ตั้งแต่ก่อนซื้อ: ส่งออกข้อมูลและ log ได้ในรูปแบบใด ลบสำเนาและข้อมูลสำรองเมื่อใด ย้าย prompt หรือ workflow ไปเครื่องมือใหม่ได้หรือไม่ และใครช่วยเมื่อสัญญาสิ้นสุด การไม่มีทางออกที่ใช้งานได้จริงอาจทำให้ต้นทุนเปลี่ยนผู้ขายสูงกว่าราคาที่ประหยัดได้ในปีแรก

6. ให้คะแนนตามความเสี่ยงและผลลัพธ์ธุรกิจ

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

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

7. กำกับหลังซื้อ ไม่ใช่ตรวจครั้งเดียว

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

NIST AI RMF แนะนำให้ติดตามความเสี่ยงจากทรัพยากรภายนอกอย่างต่อเนื่อง ขณะที่ ISO/IEC 42001 ช่วยวางระบบนโยบายและความรับผิดชอบระดับองค์กร ใช้กรอบเหล่านี้เป็นจุดอ้างอิง แต่แปลงให้เป็นเจ้าของงาน เกณฑ์วัดผล และรอบทบทวนที่ทำได้จริงในบริบทขององค์กรไทย

สรุป: ซื้อ AI ด้วยหลักฐาน ไม่ใช่คำสัญญา

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

แหล่งอ้างอิงกรอบการประเมิน

• NIST AI RMF Generative AI Profile
• ISO/IEC 42001 overview

ประเมินผู้ให้บริการ AI ให้เหมาะกับองค์กรของคุณ

ดูบริการ Data & AI Consulting ติดต่อเรา

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

ควรเริ่มประเมินผู้ให้บริการ AI จากเรื่องใด

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

การมีใบรับรอง ISO/IEC 42001 เพียงพอหรือไม่

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

ควรใช้ข้อมูลจริงในการทดลองหรือไม่

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

หากผู้ขายเปลี่ยนโมเดลหลังลงนาม ควรทำอย่างไร

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

ใครควรอนุมัติการซื้อ AI ขององค์กร

เจ้าของธุรกิจควรรับผิดชอบผลลัพธ์และความเสี่ยงคงเหลือ โดยมีฝ่ายจัดซื้อ ข้อมูล ความปลอดภัย IT และกฎหมายร่วมตรวจตามบทบาท ระดับผู้อนุมัติควรเพิ่มตามผลกระทบของ use case