ซื้อ AI จาก Vendor ไม่ได้แปลว่า หมดความรับผิดชอบ สรุปวิธีบริหารความเสี่ยง Data Privacy ตาม PDPA
ซื้อ AI จาก Vendor ไม่ได้แปลว่าพ้นผิด สรุปข้อพึงระวัง PDPA
การ ซื้อ AI จาก Vendor ในรูปแบบ Software-as-a-Service (AI SaaS) ช่วยให้องค์กรประหยัดเวลา ลดต้นทุนโครงสร้างพื้นฐาน และไม่ต้องพัฒนาโมเดลขึ้นมาเองตั้งแต่ศูนย์ แต่ในทางกฎหมาย การโอนย้ายเทคโนโลยีไม่ได้หมายถึงการโอนย้ายความรับผิดชอบ (Accountability) ด้านการคุ้มครองข้อมูลส่วนบุคคลตามพระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 (PDPA) ออกไปด้วย
แม้ผู้ให้บริการภายนอก (Vendor) จะเป็นผู้จัดหาโมเดลและระบบ Cloud แต่ตัวองค์กรยังคงเป็นผู้กำหนดวัตถุประสงค์ (Purpose) ข้อมูลนำเข้า (Input Data) ตลอดจนการนำผลลัพธ์ไปประมวลผลต่อ ความรับผิดชอบต่อสิทธิของเจ้าของข้อมูลส่วนบุคคลและผลกระทบจากการตัดสินใจของระบบ จึงยังคงผูกพันอยู่กับองค์กรโดยสมบูรณ์ตามกฎหมาย
ทำไมคำว่า “ไม่นำข้อมูลไป Train Model” ถึงยังไม่เพียงพอ
ข้อตกลงจาก Vendor ที่ระบุว่าจะ “ไม่นำข้อมูลของลูกค้าไปใช้ Train Foundation Model” ถือเป็นสัญญาสำคัญ แต่คำกล่าวนั้นยังไม่สามารถตอบโจทย์ความเสี่ยงด้านความเป็นส่วนตัวได้ทั้งหมด
การประเมินความเสี่ยงด้านข้อมูลส่วนบุคคล (Data Privacy Review) จำเป็นต้องแยกวิเคราะห์วัตถุประสงค์การใช้ข้อมูลในแต่ละส่วนอย่างชัดเจน
- Logging & Telemetry ระบบมีการบันทึก Prompt และ Output ไว้หรือไม่ บันทึกเพื่อวัตถุประสงค์ใด เช่น Security, Debugging หรือ Monitoring
- Retention Period ข้อมูล Log ถูกจัดเก็บไว้นานเท่าไร และมีมาตรการลบทำลายอย่างไร
- Subprocessors มีผู้ให้บริการรายย่อยอื่นเข้าถึงข้อมูลเพื่อช่วยประมวลผลหรือไม่
- Cross-border Transfer ข้อมูลถูกจัดเก็บหรือถูกเข้าถึงจากศูนย์ข้อมูล (Data Center) ในประเทศใด
การวิเคราะห์ Vendor Ecosystem และ Data Flow
โครงสร้างการให้บริการของ AI SaaS มีความซับซ้อนและประกอบด้วยผู้เกี่ยวข้องหลายชั้น การตรวจสอบ Vendor จึงไม่ควรมองเพียงตัวสัญญา (Contract Checklist) แต่ต้องเริ่มจากการทำ Data Flow Mapping เพื่อดูเส้นทางการไหลของข้อมูลจริง
องค์กร (Data Controller) ──ส่งข้อมูล──► AI SaaS Provider ──ใช้ API──► Foundation Model Provider
│
ดึงข้อมูลผ่าน RAG
▼
Internal System (CRM/Drive)
เมื่อมีการเชื่อมต่อ AI SaaS เข้ากับระบบภายในองค์กร เช่น CRM, HRIS หรือ Shared Drive ผ่าน API หรือเทคโนโลยี Retrieval-Augmented Generation (RAG) สิทธิการเข้าถึงข้อมูลของ Vendor จะขยายกว้างขึ้นอย่างมาก การประเมิน Vendor จึงต้องพิจารณาตามบริบทของ Use Case และระดับการเชื่อมต่อระบบ ไม่ใช่การอนุมัติสัญญาแบบถาวรครั้งเดียวจบ
การระบุบทบาททางกฎหมาย (Data Role Mapping)
องค์กรมักเรียกผู้ให้บริการ AI ทุกรายว่า ผู้ประมวลผลข้อมูลส่วนบุคคล (Data Processor) โดยอัตโนมัติ ซึ่งอาจไม่ถูกต้องเสมอไป บทบาททางกฎหมายตาม PDPA ขึ้นอยู่กับข้อเท็จจริงว่าใครเป็นผู้กำหนดวัตถุประสงค์และวิธีการประมวลผลข้อมูลในแต่ละกิจกรรม
- Data Processor เมื่อ Vendor ประมวลผลข้อมูลตามคำสั่งและวัตถุประสงค์ขององค์กรอย่างเคร่งครัด
- Data Controller หาก Vendor นำข้อมูลบางส่วน เช่น Log หรือ Metadata ไปใช้ประโยชน์เพื่อวัตถุประสงค์ของตนเอง เช่น การวิเคราะห์เพื่อปรับปรุงบริการ หรือการรักษาความปลอดภัยของระบบ
การระบุบทบาทแยกตามกิจกรรม (Activity-based Role Mapping) จะช่วยให้การจัดทำข้อตกลงประมวลผลข้อมูล (Data Processing Agreement: DPA) มีความแม่นยำและสอดคล้องกับการใช้งานจริง
ข้อสัญญาสำคัญกับการตั้งค่าระบบจริง (Contract vs Configuration)
การมีข้อสัญญาที่รัดกุมเป็นเรื่องจำเป็น แต่ต้องควบคู่ไปกับการตรวจสอบการตั้งค่าระบบจริง (Configuration) และหลักฐานการทำงานจาก Vendor โดยข้อสัญญาควรครอบคลุมประเด็นสำคัญ ดังนี้
- Purpose Restriction & Retention กำหนดขอบเขตการใช้ข้อมูลและระยะเวลาจัดเก็บที่ชัดเจน
- Auditability & Incident Notification มีมาตรการแจ้งเตือนเมื่อเกิดเหตุข้อมูลรั่วไหล และสิทธิ์ในการเข้าตรวจสอบ
- Exit Strategy & Data Deletion กำหนดกระบวนการลบหรือส่งคืนข้อมูลทั้งหมดอย่างปลอดภัยเมื่อสิ้นสุดสัญญา
เมื่อมีการอัปเดตโมเดล หรือการเปลี่ยนแปลงเงื่อนไขการให้บริการ (Terms of Service) องค์กรจำเป็นต้องมีระบบบริหารจัดการการเปลี่ยนแปลง (Change Management) เพื่อทบทวนความเสี่ยงและอัปเดตการประเมินให้สอดคล้องกันเสมอ
ยังต้องรับผิดชอบ เนื่องจากมาตรฐานความปลอดภัย (Cybersecurity) ของ Vendor เป็นเพียงส่วนหนึ่งของการคุ้มครองข้อมูล แต่ความรับผิดชอบในการเลือกใช้ข้อมูล วัตถุประสงค์การประมวลผล และผลกระทบที่เกิดจากการตัดสินใจของ AI ยังคงเป็นขององค์กรในฐานะผู้ควบคุมข้อมูลส่วนบุคคล (Data Controller)
ยังไม่เพียงพอ ข้อตกลง No Training ยืนยันเพียงว่า Vendor จะไม่นำข้อมูลไปพัฒนาโมเดลหลัก แต่ไม่ได้ครอบคลุมถึงระยะเวลาการเก็บ Log, สิทธิ์การเข้าถึงของ Subprocessor, การส่งข้อมูลข้ามประเทศ หรือฐานทางกฎหมายในการประมวลผลขององค์กร
องค์กรควรกำหนดเงื่อนไข Change Trigger ในระบบการจัดการ Vendor เพื่อทบทวนการประเมินความเสี่ยง Data Privacy, ทบทวนการตั้งค่า Privacy/Security และตรวจสอบสิทธิการเข้าถึงข้อมูลใหม่ทุกครั้งที่มีการเปลี่ยนแปลงสำคัญ
สรุป
หลักการสำคัญในการจัดซื้อเทคโนโลยี AI คือ Buy AI ≠ Outsource Accountability องค์กรอาจซื้อเทคโนโลยีโมเดลจากภายนอกได้ แต่ไม่สามารถโอนย้ายวัตถุประสงค์ การตัดสินใจ และความรับผิดชอบต่อผลกระทบที่มีต่อเจ้าของข้อมูลออกไปได้ การประเมิน Vendor ที่ดีจึงต้องดูทั้งเส้นทางการไหลของข้อมูล ข้อสัญญา การตั้งค่าระบบ และการตรวจสอบอย่างต่อเนื่องตลอดวงจรการใช้งาน
อยากนำ AI มาใช้ในองค์กร แต่ยังกังวลเรื่องความปลอดภัยและข้อมูลรั่วไหล?
หลักสูตร “Privacy in AI Era” ช่วยควบคุมความเสี่ยง AI สู่การลงมือทำจริงในสายงานของคุณ
เผยแพร่: 16 กันยายน 2569
อัปเดตล่าสุด: 16 กันยายน 2569
ช่องทางติดต่อ:
Facebook: PDPA Thailand
Line OA: @pdpathailand
Email: [email protected]
Website: www.pdpathailand.com
