เมื่อโครงการ TH-AI Passport และแพลตฟอร์ม AiPASS เริ่มได้รับความสนใจจากสาธารณชนมากขึ้น พวกเราได้รับคำถามของผู้บริหารและเจ้าหน้าที่คุ้มครองข้อมูลส่วนบุคคล (Data Protection Officer: DPO) ไม่ใช่แค่ประเด็นว่า “พนักงานควรสมัครหรือไม่” แต่ขยับไปสู่คำถามสำคัญกว่า คือ “องค์กรควรสนับสนุนให้พนักงานใช้ AiPASS หรือไม่ และหากใช้ องค์กรควรกำกับอย่างไร”

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

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

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

1. AiPASS เป็นโอกาสขององค์กรในการพัฒนาความรู้เท่าทันและทักษะการใช้ AI (AI Literacy)
องค์กรควรเปิดโอกาสให้พนักงานเรียนรู้และทดลองใช้ AI เพราะความรู้เท่าทันและความสามารถในการใช้ AI (AI Literacy) กำลังเป็นทักษะพื้นฐานของคนทำงาน เช่นเดียวกับทักษะดิจิทัลที่องค์กรต้องพัฒนาอย่างต่อเนื่อง และ AiPASS สามารถเป็นหนึ่งในเครื่องมือสำหรับการเรียนรู้ดังกล่าวได้
สิ่งที่องค์กรควรมุ่งหวังไม่ใช่เพียงให้พนักงาน “ใช้ AI เป็น” ในความหมายว่าเขียนคำสั่ง (Prompt) ได้ แต่ต้องเข้าใจด้วยว่า AI ทำอะไรได้ อะไรทำไม่ได้ คำตอบใดต้องตรวจสอบ และมีความเสี่ยงอะไรอยู่เบื้องหลัง เช่น การสร้างข้อมูลที่ผิดแต่ดูน่าเชื่อถือ (Hallucination) ความเป็นส่วนตัว (Privacy) ความมั่นคงปลอดภัยไซเบอร์ (Cybersecurity) และลิขสิทธิ์ (Copyright)

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

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

กรณีดังกล่าว การที่พนักงานเป็นผู้ลงทะเบียนบัญชีหรือเป็นผู้พิมพ์ Prompt ด้วยตนเอง ไม่ได้ทำให้กิจกรรมนั้นกลายเป็นเรื่องส่วนตัวของพนักงาน หากพนักงานใช้ AiPASS ตามวัตถุประสงค์และหน้าที่ที่องค์กรกำหนด องค์กรยังคงต้องรับผิดชอบต่อการประมวลผลข้อมูลที่เกิดขึ้นในกิจกรรมนั้น
หากมีข้อมูลส่วนบุคคลเข้ามาเกี่ยวข้อง องค์กรต้องพิจารณาหน้าที่ตามพระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 (Personal Data Protection Act: PDPA) ของตนเอง เช่น
– วัตถุประสงค์ของการประมวลผลตามมาตรา 21
– การเก็บรวบรวมเท่าที่จำเป็นตามมาตรา 22
– การแจ้งประกาศความเป็นส่วนตัวตามมาตรา 23 หรือมาตรา 25
– ฐานกฎหมายตามมาตรา 24 หรือมาตรา 26 สำหรับข้อมูลส่วนบุคคลอ่อนไหว
– การใช้หรือเปิดเผยตามมาตรา 27
– การส่งหรือโอนข้อมูลไปต่างประเทศตามมาตรา 28 และ 29
– การรักษาความมั่นคงปลอดภัยตามมาตรา 37 และ
– การรองรับสิทธิของเจ้าของข้อมูลส่วนบุคคลตามมาตรา 19, 20, 30-34 และ 36

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

สำหรับ AiPASS ข้อมูลส่วนบุคคลและข้อมูลลับควรถูกจำกัดไว้เป็นค่าเริ่มต้น

ในเชิงนโยบายขององค์กร สำหรับการใช้ AiPASS กับงานจริง ข้อมูลส่วนบุคคลและข้อมูลลับขององค์กรควรถูกกำหนดเป็น “จำกัดการนำเข้าไว้เป็นค่าเริ่มต้น” (Restricted by Default) กล่าวคือ ไม่ให้นำเข้าโดยปริยาย จนกว่ากรณีการใช้งาน (Use Case) นั้นจะได้รับการประเมินและอนุมัติเป็นการเฉพาะ และองค์กรเห็นว่ามีมาตรการควบคุมที่เหมาะสม จนอยู่ในระดับความเสี่ยงตามเกณฑ์ที่ยอมรับได้

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

3. บัญชีผูกกับพนักงาน แต่ความรับผิดชอบยังอยู่ที่องค์กร
สำนักงานคณะกรรมการดิจิทัลเพื่อเศรษฐกิจและสังคมแห่งชาติ (สดช.) ระบุสถานะของตนเป็นผู้ควบคุมข้อมูลส่วนบุคคล (Data Controller) สำหรับการดำเนินโครงการและแพลตฟอร์ม AiPASS ขณะเดียวกัน หากองค์กรกำหนดให้พนักงานใช้ AiPASS เพื่อดำเนินกิจกรรมขององค์กรที่มีการประมวลผลข้อมูลส่วนบุคคล องค์กรก็เป็น Data Controller สำหรับกิจกรรมขององค์กรนั้น

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

ประเด็นสำคัญที่องค์กรต้องพิจารณาเพิ่มเติมคือ จากการตรวจสอบระบบโดยผู้เขียน ณ วันที่ 26 สิงหาคม 2569 ระบบ AiPASS ไม่มีระบบควบคุมสำหรับผู้ดูแลระดับองค์กร (Enterprise Admin Control) องค์กรจึงไม่มีระบบบริหารจัดการจากส่วนกลาง (Admin Console) สำหรับบริหารบัญชีพนักงานหรือตรวจสอบบันทึกการใช้งานระดับองค์กร (Audit Log) กำหนดวงจรการเก็บหรือลบข้อมูล หรือจัดการบัญชีและข้อมูลในรูปแบบเดียวกับบริการ AI ที่ออกแบบมาสำหรับองค์กร (Enterprise) ซึ่ง “การไม่มีเครื่องมือควบคุมระดับองค์กร (Enterprise Control) ไม่ได้ทำให้องค์กรมีหน้าที่น้อยลง แต่ทำให้องค์กรต้องออกแบบมาตรการควบคุมขององค์กร (Organizational Control) ให้ชัดเจนยิ่งขึ้น”

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

4. เมื่อแพลตฟอร์มไม่มีเครื่องมือควบคุมระดับองค์กร องค์กรต้องสร้างระบบกำกับของตนเอง
การกำกับดูแลเรื่องนี้ไม่ใช่การห้ามใช้ AiPASS แบบเหมารวม แต่คือการสร้าง “มาตรการควบคุมทดแทน” (Compensating Controls) ภายนอกแพลตฟอร์ม เพื่อให้การใช้ AiPASS โดยพนักงาน แต่เพื่อประโยชน์ขององค์กรยังอยู่ภายใต้กติกาและความรับผิดชอบที่องค์กรกำหนดได้

4.1 ใช้บัญชีอีเมลที่องค์กรควบคุม (Organization-controlled Email Account) เป็นมาตรการควบคุมทดแทน
หากองค์กรสนับสนุนให้พนักงานเข้าร่วมโครงการและต้องการให้ใช้ AiPASS เพื่อทำงานขององค์กร ควรกำหนดให้ลงทะเบียนด้วยบัญชีอีเมลที่องค์กรเป็นผู้จัดหา ลงทะเบียน เป็นเจ้าของ และสามารถบริหารวงจรชีวิตของบัญชีได้ ไม่ว่าจะเป็นอีเมลภายใต้โดเมนขององค์กร หรือบัญชี Google, Microsoft หรือ Apple ที่องค์กรสร้างและควบคุม แม้บัญชีนั้นจะใช้บริการแบบไม่มีค่าใช้จ่ายก็ตาม

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

มาตรการนี้ไม่ใช่ Admin Control ของ AiPASS แต่เป็น Organizational Control ที่องค์กรสร้างขึ้นเอง และเนื่องจาก AiPASS มีการยืนยันตัวตนของผู้ใช้ บัญชีที่ใช้ทำงานควรเป็นบัญชีของพนักงานแต่ละราย ไม่ใช่บัญชีร่วม และไม่ควรแชร์รหัสผ่าน (Password) หรือข้อมูลรับรองการเข้าถึง (Credential) ระหว่างกัน

4.2 อนุมัติ Use Case ไม่ใช่อนุมัติเพียงชื่อเครื่องมือ
การประกาศว่า “ใช้ AiPASS ได้” หรือ “ห้ามใช้ AiPASS” เป็นคำสั่งที่กว้างเกินไป เพราะเครื่องมือเดียวกันอาจใช้กับงานที่มีความเสี่ยงต่างกันมาก ตั้งแต่การถามคำถามทั่วไป การวาดภาพ หรือการร่างข้อความจากข้อมูลสาธารณะ ไปจนถึงการอัปโหลดข้อมูลลูกค้าเพื่อวิเคราะห์
องค์กรจึงควรอนุมัติวิธีใช้ ไม่ใช่อนุมัติเพียงชื่อเครื่องมือ (Approve the Use Case, not just the Tool) โดยพิจารณาอย่างน้อย 5 เรื่องพร้อมกัน ได้แก่

การใช้งาน (Use Case) ว่า…ใช้ AI ทำอะไร?
ข้อมูล (Data) ว่า…ใช้ข้อมูลประเภทใด?
โมเดล (Model) ว่า…ใช้โมเดลหรือผู้ให้บริการใด?
ผู้ตรวจสอบและผู้รับผิดชอบ (Human) ว่า…เป็นใคร?
ความเสี่ยง (Risk) ว่า…หากผิดพลาดหรือข้อมูลรั่วไหลจะเกิดผลกระทบอะไร?

4.3 กำหนดกติกาเรื่องการใช้ข้อมูลขององค์กร
กรอบ Green-Amber-Red คือกติกาใช้งานภายในองค์กร ไม่ใช่กรอบที่ทำให้ข้อมูลทุกประเภท “ใช้ผ่าน AiPASS” ได้โดยอัตโนมัติ
• Green คือข้อมูลที่ใช้ได้หากเป็นข้อมูลสาธารณะ งานระดมความคิด การแปล การสร้างโครงร่าง หรือเนื้อหาที่ไม่เกี่ยวกับข้อมูลส่วนบุคคลและข้อมูลลับ โดยยังต้องตรวจสอบผลลัพธ์ก่อนใช้
• Amber คือข้อมูลภายในองค์กรระดับทั่วไปที่ไม่ใช่ความลับ ข้อมูลสังเคราะห์ (Synthetic Data) หรือข้อมูลส่วนบุคคลที่ผ่านการทำข้อมูลแฝง (Pseudonymization) แล้ว สามารถใช้ได้ตามเงื่อนไขและแนวปฏิบัติที่องค์กรกำหนดไว้เฉพาะ
• Red คือการจำกัดการนำเข้าข้อมูลไว้เป็นค่าเริ่มต้น (Restricted by Default) เมื่อเกี่ยวข้องกับข้อมูลส่วนบุคคล ข้อมูลส่วนบุคคลอ่อนไหว ข้อมูลสุขภาพตาม PDPA ข้อมูลทางการเงิน ความลับทางการค้า เอกสารสัญญาที่เป็นความลับ ซอร์สโค้ด (Source Code) ที่สำคัญ รวมถึงข้อมูลที่องค์กรยังไม่ได้ประเมิน ส่วนรหัสผ่าน (Password) ข้อมูลรับรองการเข้าถึง (Credential) กุญแจ API (API Key) และกุญแจส่วนตัว (Private Key) ควรกำหนดเป็นข้อมูลที่ห้ามนำเข้าสู่ระบบ AI โดยเด็ดขาด

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

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

Use Case ที่มีผลกระทบสูง เช่น การคัดกรองผู้สมัครงาน การประเมินพนักงาน การประเมินเครดิต หรือการใช้ข้อมูลสุขภาพ ควรได้รับการประเมินผลกระทบและควบคุมให้เหมาะสมกับระดับความเสี่ยง เช่น การประเมินผลกระทบด้านการคุ้มครองข้อมูลส่วนบุคคล (Data Protection Impact Assessment: DPIA) หรือการประเมินผลกระทบด้าน AI และ Privacy ตามบริบทของกิจกรรมและบริบทขององค์กร

องค์กรควรกำหนดการกำกับโดยมนุษย์ (Human Oversight) โดยเฉพาะการใช้ AI ในการตัดสินใจที่มีผลสำคัญต่อบุคคล และหากองค์กรมี Use Case จำนวนมาก ในหลายส่วนงาน การจัดทำทะเบียนกรณีการใช้ AI (AI Use Case Register) จะช่วยให้สามารถติดตามเจ้าของงาน ระดับความเสี่ยง และมาตรการควบคุมได้อย่างเป็นระบบและตรวจสอบได้

สำหรับ AiPASS องค์กรอาจมีทะเบียนบัญชี AI ที่ได้รับอนุมัติ (Approved AI Account Register) เพิ่มเติม เพื่อบันทึกว่าใครได้รับอนุญาตให้ใช้บัญชีใด เพื่อ Use Case ใด อยู่ภายใต้หน่วยงานใด และเมื่อใดต้องทบทวนหรือยุติสิทธิ

หากพนักงานเผลอส่งข้อมูลที่ไม่ควรนำเข้าสู่ AI ต้องมีขั้นตอนการรับมือเหตุการณ์ (Incident Response) ที่ชัดเจน ให้หยุดส่งข้อมูลเพิ่มเติม เก็บข้อเท็จจริง แจ้งฝ่ายที่เกี่ยวข้อง เช่น ฝ่ายความมั่นคงปลอดภัยสารสนเทศ DPO หรือฝ่ายกฎหมาย และประสานผู้ให้บริการเพื่อจำกัดหรือลบข้อมูลเท่าที่ทำได้ หากเข้าข่ายเหตุละเมิดข้อมูลส่วนบุคคล (Personal Data Breach) ต้องประเมินหน้าที่ตามมาตรา 37(4) ของ PDPA (ซึ่งการที่องค์กรทำความเข้าใจแผนภาพการไหลของข้อมูล (Data Flow) ตั้งแต่จุดที่พิมพ์ Prompt ข้อมูลวิ่งผ่านโมเดลใด ไปจนถึงเซิร์ฟเวอร์ปลายทาง จะช่วยให้ประเมินขอบเขตผลกระทบได้อย่างแม่นยำ)

หากเหตุละเมิดมีความเสี่ยงต่อสิทธิและเสรีภาพของบุคคล ต้องแจ้งสำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (สคส.) โดยไม่ชักช้าภายใน 72 ชั่วโมงนับแต่ทราบเหตุเท่าที่สามารถกระทำได้ และหากมีความเสี่ยงสูงต่อสิทธิและเสรีภาพของบุคคล นอกจากต้องแจ้ง สคส. แล้วยังต้องแจ้งเจ้าของข้อมูลส่วนบุคคลโดยไม่ชักช้าด้วย

4.5 จะใช้ AiPASS ต้องคิดถึงวันจบโครงการตั้งแต่วันเริ่มใช้
อีกประเด็นที่องค์กรไม่ควรมองข้ามคือ “แผนยุติหรือเปลี่ยนผ่านการใช้งาน (Exit Plan)” เมื่อโครงการ TH-AI Passport สิ้นสุดลง หรือเงื่อนไขการให้บริการเปลี่ยนไป องค์กรต้องตอบให้ได้ว่า ข้อมูลขององค์กรที่เคยถูกนำไปใช้กับ AiPASS จะจัดการอย่างไร บัญชีจะถูกยุติหรือเปลี่ยนผ่านอย่างไร และหากมีระบบหรือกระบวนการทำงานอื่นเชื่อมโยงกับ AI จาก AiPASS จะย้าย หยุด หรือทดแทนอย่างไร

ธรรมาภิบาลที่ดีจึงไม่ควรคิดเพียงเรื่องการเริ่มใช้งาน (Onboarding) ว่าจะเริ่มใช้ AI อย่างไร แต่ต้องคิดถึงการยุติสิทธิหรือพ้นสภาพผู้ใช้งาน (Offboarding) และการยุติหรือเปลี่ยนผ่านระบบ (Exit) ตั้งแต่ต้นด้วย

5. เริ่มจากโครงการนำร่อง (Pilot) แล้วค่อยขยาย ไม่เปิดทุกงานพร้อมกัน
องค์กรที่ต้องการใช้ AiPASS หรือปัญญาประดิษฐ์เชิงสร้างสรรค์ (Generative AI) เพื่อเพิ่มประสิทธิภาพ ไม่ควรเริ่มจากการเปิดใช้กับทุกงานและทุกข้อมูลพร้อมกัน แต่ควรเริ่มจาก Use Case ความเสี่ยงต่ำ 3–5 เรื่อง ในระดับ Green เช่น การร่างเอกสารจากข้อมูลทั่วไป การสรุปข้อมูลสาธารณะ การแปลภาษา หรือการระดมความคิด

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

จากนั้นจึงวัดผลจากการใช้งานจริงว่า AI ช่วยประหยัดเวลาหรือเพิ่มคุณภาพงานเพียงใด เกิดการสร้างข้อมูลที่ผิดแต่ดูน่าเชื่อถือ (Hallucination) มากน้อยเพียงใด มีการนำข้อมูลผิดประเภทเข้าสู่ระบบหรือไม่ การกำกับโดยมนุษย์ (Human Oversight) เพียงพอหรือไม่ และที่สำคัญ องค์กรสามารถกำกับการใช้งานได้จริงเพียงใด และมีแผนยุติหรือเปลี่ยนผ่านการใช้งาน (Exit Plan) อย่างไร?

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

สรุปคำถาม 7 ข้อที่ผู้บริหารควรถามก่อนให้ใช้ AiPASS ทำงานขององค์กร
• Use Case นี้ใช้ AI ทำอะไร และใครเป็นเจ้าของงาน?
• จะนำข้อมูลประเภทใดเข้าไป และมีข้อมูลส่วนบุคคล (Personal Data) หรือข้อมูลลับหรือไม่?
• ข้อมูลและ Prompt จะไหลไปที่ใด ผ่านโมเดลหรือผู้ให้บริการใด และองค์กรเข้าใจการไหลของข้อมูล (Data Flow) เพียงพอหรือยัง?
• พนักงานใช้บัญชีใด และบัญชีนั้นอยู่ภายใต้การควบคุมขององค์กรหรือไม่?
• ใครตรวจสอบผลลัพธ์จาก AI (AI Output) และใครรับผิดชอบเมื่อนำผลลัพธ์ไปใช้?
• หากส่งข้อมูลผิด เกิดเหตุการณ์ผิดปกติ (Incident) หรือพนักงานพ้นสภาพ องค์กรจะจัดการอย่างไร?
• ถ้าโครงการสิ้นสุดหรือเงื่อนไขเปลี่ยน องค์กรมี Exit Plan สำหรับข้อมูล บัญชี และระบบที่เชื่อมโยงแล้วหรือยัง?
จุดยืนของสมาคมผู้ตรวจสอบและให้คำปรึกษาการคุ้มครองข้อมูลส่วนบุคคลไทย (TPDPA)

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

สำหรับ AiPASS โดยเฉพาะ ข้อจำกัดจากการไม่มีระบบควบคุมสำหรับผู้ดูแลระดับองค์กร และเงื่อนไขของโครงการต้องถูกนำมาพิจารณา หากองค์กรจะใช้ AiPASS ในการทำงาน องค์กรต้องสร้างระบบกำกับของตนเอง โดยบัญชีอีเมลที่องค์กรควบคุม (Organization-controlled Email Account) เป็นเพียงหนึ่งในมาตรการสำคัญ และต้องทำงานร่วมกับนโยบาย การควบคุม Use Case การควบคุมข้อมูล การกำกับโดยมนุษย์ การรับมือเหตุการณ์ และ Exit Plan

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

แหล่งข้อมูลที่ใช้ตรวจสอบ
• พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 — ราชกิจจานุเบกษา
• ประกาศความเป็นส่วนตัวแพลตฟอร์ม AiPASS ภายใต้โครงการ TH-AI Passport ฉบับ 1.0 มีผลใช้บังคับวันที่ 19 สิงหาคม 2569 — https://de.aipass.net/privacy-policy
• การตรวจสอบคุณสมบัติและการทำงานของระบบ AiPASS โดยผู้เขียน ณ วันที่ 26 สิงหาคม 2569 สำหรับประเด็น Enterprise Admin Control
• ข้อกำหนดและเงื่อนไขสำหรับประชาชนที่เข้าร่วมโครงการ TH-AI Passport มีผลใช้บังคับวันที่ 19 สิงหาคม 2569 — https://de.aipass.net/term-and-cond-th
• เว็บไซต์และคำถามที่พบบ่อยของโครงการ TH-AI Passport — https://de.aipass.net/ และ https://de.aipass.net/faq
เอกสารสาธารณะของ AiPASS ที่ใช้ตรวจสอบเป็นข้อมูลล่าสุด ณ วันที่ 26 สิงหาคม 2569

หมายเหตุ: เอกสาร เงื่อนไข และความสามารถของแพลตฟอร์มอาจมีการปรับปรุง องค์กรควรตรวจสอบฉบับล่าสุดก่อนใช้กับข้อมูลจริงหรือ Use Case ที่มีความเสี่ยงสูง

เมื่อวันที่ 7 กรกฎาคม 2569 ผมเคยเขียน บทความวิจารณ์ TOR โครงการ TH-AI Passport ในมุมของพระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 (PDPA)

https://tpdpa.or.th/tor-th-ai-passport-pdpa-analysis/

ตอนนั้นผมตั้งคำถามหลายเรื่อง ตั้งแต่ใครเป็นผู้ควบคุมข้อมูล ใช้ฐานกฎหมายอะไร ข้อมูลจะถูกส่งไปไหน ไปจนถึงการใช้ Prompt, File และข้อมูลพฤติกรรมของผู้ใช้

วันที่ 19 สิงหาคม 2569 โครงการเปิดให้ลงทะเบียนล่วงหน้าผ่าน AiPASS และมีเอกสารเพิ่มเติมให้ศึกษา ทั้ง Terms and Conditions, Privacy Notice ฉบับที่ 1.0 และ FAQ ทำให้หลายคำถามที่เคยมีเริ่มเห็นคำตอบมากขึ้น

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

อย่างไรก็ตาม ผมยังไม่ได้เห็นสัญญาหลักและเอกสารแนบท้ายทั้งหมด การวิเคราะห์ในบทความนี้จึงไม่ควรนำ TOR หรือสัญญาแก้ไขเพิ่มเติมเพียงส่วนใดส่วนหนึ่งมาสรุปว่าการดำเนินงานผิดสัญญา แต่จะใช้เอกสารเหล่านี้ประกอบกับ Terms and Conditions, Privacy Notice และ FAQ เพื่อพิจารณาเฉพาะประเด็นที่เกี่ยวข้องกับการคุ้มครองข้อมูลส่วนบุคคล

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

1.หลายคำถามจาก TOR วันนี้มีคำตอบแล้ว

เรื่องแรกที่ชัดขึ้นคือ ใครเป็นผู้ควบคุมข้อมูล โดย Terms and Conditions ข้อ 4 และ Privacy Notice ข้อ 1.2 ระบุว่า สดช. เป็นผู้ควบคุมข้อมูลส่วนบุคคล (Data Controller) เรื่องนี้จึงไม่ต้องคาดเดาเหมือนตอนอ่าน TOR

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

แต่ยังมีบางจุดที่ควรทำให้สอดคล้องกัน เช่น บางวัตถุประสงค์เขียนว่าใช้ทั้งฐานสัญญาและฐานภารกิจเพื่อประโยชน์สาธารณะ แต่ระบุมาตรา 24(4) เพียงมาตราเดียว ขณะที่ฐานสัญญาอยู่ในมาตรา 24(3) ส่วนการวิจัยและพัฒนา National LLM ปัจจุบัน Privacy Notice ระบุมาตรา 24(4) จึงควรอธิบายให้ชัดว่าการวิจัยดังกล่าวอยู่ภายใต้ภารกิจของ สดช. อย่างไร และมีส่วนใดที่ต้องพิจารณาฐานการวิจัยตามมาตรา 24(1) เพิ่มเติมหรือไม่

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

2.ข้อมูลไม่ได้อยู่แค่ในระบบ AiPASS และความรับผิดชอบก็ไม่ได้อยู่ที่ผู้รับจ้างหลักเพียงรายเดียว

สิ่งที่สำคัญกว่า Privacy Notice คือ เมื่อข้อมูลเดินทางต่อไปหาองค์กรอื่น ใครรับผิดชอบอะไรในแต่ละช่วง

ผู้รับจ้างหลักซึ่งพัฒนาและดูแลระบบน่าจะเป็นผู้ประมวลผลข้อมูลส่วนบุคคล (Data Processor) ในกิจกรรมที่ทำตามคำสั่งของ สดช. มาตรา 40 กำหนดหน้าที่ไว้ทั้งการทำตามคำสั่ง การรักษาความมั่นคงปลอดภัย การแจ้ง Data Controller เมื่อเกิดเหตุละเมิด และการจัดทำบันทึกกิจกรรมการประมวลผล ดังนั้นหน้าที่ของผู้รับจ้างไม่ได้มีแค่ทำให้ระบบใช้งานได้ แต่ต้องทำให้ข้อมูลถูกใช้ตามคำสั่งและวัตถุประสงค์ที่กำหนดด้วย

Privacy Notice ข้อ 4.4 ก็ระบุว่าผู้ให้บริการระบบหรือ Cloud ที่ประมวลผลตามคำสั่งของโครงการเป็น Data Processor ขณะที่ TOR ข้อ 4.10 ห้ามผู้รับจ้างนำข้อมูลของโครงการไปใช้เพื่อกิจการอื่นนอกเหนือจากที่ สดช. อนุญาต แต่การให้ผู้รับจ้างดำเนินการไม่ได้ทำให้หน้าที่ของ สดช. ในฐานะ Data Controller หายไป สดช. ยังต้องกำกับและสามารถพิสูจน์ได้ว่าผู้รับจ้างทำตามสิ่งที่ได้รับมอบหมายจริง

เรื่องนี้สำคัญเพราะ FAQ ระบุว่า AiPASS เชื่อม AI จาก 14 ค่าย มากกว่า 30 โมเดล และโครงการยังอาจมี Cloud ผู้จัดอบรม Call Center ผู้จัดกิจกรรม หรือบริษัทที่ดูแลระบบบางส่วนเข้ามาเกี่ยวข้อง ผู้ให้บริการเหล่านี้อาจเป็น Sub-processor หากประมวลผลตามคำสั่งที่ส่งต่อมาจากผู้รับจ้างหลัก หรืออาจมีสถานะอื่นในบาง Processing Activity หากใช้ข้อมูลเพื่อวัตถุประสงค์ที่ตนกำหนดเอง

ดังนั้น DPA ระหว่าง สดช. กับผู้รับจ้างหลักต้องเข้มพอที่จะทำให้ข้อกำหนดเรื่องการใช้ข้อมูล การรักษาความปลอดภัย การลบข้อมูล การแจ้งเหตุละเมิด และการห้ามนำข้อมูลไปใช้ต่อ ไหลลงไปถึงผู้ให้บริการในทุกทอดได้จริง ผู้รับจ้างหลักก็ควรรู้ว่า Sub-processor มีใครบ้าง ได้ข้อมูลอะไร เก็บที่ไหน ใครเข้าถึงได้ และเมื่อจบงานต้องลบหรือคืนข้อมูลอย่างไร ทั้งนี้ Processor มีหน้าที่จัดทำบันทึกตามมาตรา 40(3) อยู่แล้ว ส่วน Processor/Sub-processor Register เป็นเครื่องมือกำกับที่ช่วยให้ตรวจสอบสายการประมวลผลได้ง่ายขึ้น

อีกกลุ่มหนึ่งที่ต้องแยกออกมาคือสมาคม สถานศึกษา หรือหน่วยงานที่ช่วยประชาสัมพันธ์หรือรวบรวมผู้สมัคร หากเพียงส่ง Link หรือ QR Code แล้วประชาชนสมัคร AiPASS เอง ก็แทบไม่มีการแบ่งปัน Personal Data ระหว่างองค์กร แต่ถ้ามีการรวบรวมรายชื่อส่งเข้าโครงการ หรือมีคะแนน ผลการเรียน หรือข้อมูลการใช้บริการส่งกลับไปยังต้นสังกัด ก็เกิด Data Sharing ขึ้นแล้ว และต้องตอบให้ได้ว่าแต่ละฝ่ายมีบทบาทอะไร ใช้ฐานกฎหมายใด ใช้ข้อมูลเพื่อวัตถุประสงค์อะไร และได้แจ้งเจ้าของข้อมูลไว้อย่างไร

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

3.ส่งข้อมูลไปต่างประเทศ ควรอธิบายให้ชัด

อีกประเด็นที่ถูกตั้งคำถามมากคือ Data Localization กับการส่งข้อมูลไปต่างประเทศ

TOR มีทั้งวัตถุประสงค์ให้ข้อมูลส่วนบุคคลและข้อมูลพฤติกรรมการใช้ AI ถูกจัดเก็บและประมวลผลในประเทศไทย ข้อกำหนดเฉพาะให้ข้อมูลการลงทะเบียนอยู่ในประเทศไทย และกำหนดให้ Main Data Center ตั้งอยู่ในประเทศไทย ขณะที่ Privacy Notice ระบุว่า Prompt และ File อาจถูกส่งไปประมวลผลกับ AI Provider ต่างประเทศ จึงมีคนตั้งข้อสังเกตว่าการทำงานแบบนี้อาจไม่สอดคล้องกับ TOR

จากรายละเอียดสัญญาแก้ไขเพิ่มเติมที่เผยแพร่ ไม่ปรากฏว่ามีการแก้ข้อความใน TOR ส่วนที่ผมยกมาวิเคราะห์เรื่องการจัดเก็บและประมวลผลข้อมูลในประเทศไทย ดังนั้น เมื่อทราบแล้วว่า TOR เป็นส่วนหนึ่งของสัญญา คำถามเรื่อง Cross-border Processing จึงไม่ใช่เพียงเรื่องที่ Privacy Notice ต้องอธิบายตาม PDPA แต่ยังควรอธิบายด้วยว่าการดำเนินงานดังกล่าวสอดคล้องกับข้อกำหนดในสัญญาทั้งชุดอย่างไร

สิ่งที่ควรชี้แจงให้ประชาชนเข้าใจได้ง่ายคือ ข้อมูลประเภทใดอยู่ในประเทศไทย ข้อมูลประเภทใดถูกส่งออก Provider ใดรับข้อมูล ประมวลผลที่ Region ไหน เก็บไว้นานเท่าใด และใช้กลไกตามมาตรา 28 หรือ 29 ของ PDPA อย่างไร เพราะ PDPA ไม่ได้ห้ามการส่งข้อมูลไปต่างประเทศโดยเด็ดขาด แต่กำหนดเงื่อนไขและมาตรการที่ต้องปฏิบัติตาม

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

ถ้าอธิบาย Data Flow ตรงนี้ได้ชัด ความกังวลเรื่อง “ข้อมูลออกนอกประเทศ” จะลดลงมาก เพราะคนจะเห็นภาพว่าอะไรออก อะไรไม่ออก และออกไปเพื่อทำอะไร

4.National LLM ต้องแยกจากการที่ AI Provider นำข้อมูลไป Train

ใน TOR เดิมผมยังไม่พบเรื่อง National LLM โดยตรง แต่ Terms and Conditions และ Privacy Notice ปัจจุบันระบุชัดว่า ข้อมูลที่เกิดจากการใช้ AiPASS อาจถูกนำไปใช้เพื่อการวิจัยและพัฒนา รวมถึงการพัฒนา National LLM

อย่างไรก็ตาม ไม่ควรตีความว่าระบบจะนำ Prompt หรือ Chat ที่ยังระบุตัวบุคคลได้ไป Train National LLM โดยตรง เพราะ Terms ข้อ 9.2 ระบุว่า User Content ที่ใช้เพื่อ National LLM จะใช้เฉพาะข้อมูลที่ผ่าน De-identification หรือ Anonymization แล้ว

สิ่งที่ควรอธิบายคือ จากข้อมูลที่เกิดขึ้นระหว่างใช้ AiPASS ไปจนถึง Dataset สำหรับ National LLM มีขั้นตอนอย่างไร Anonymization เกิดเมื่อใด และกรณีที่ Terms ข้อ 6.8 กล่าวถึง Pseudonymisation มีการใช้ข้อมูลลักษณะนี้ในขั้นตอนใด

ส่วน Sensitive Personal Data ยิ่งต้องอธิบายให้ชัด เพราะ Privacy Notice ระบุว่า หากผู้ใช้ป้อนเข้ามา จะใช้เพียงเพื่อสร้างคำตอบ ดังนั้นข้อมูลประเภทนี้ก็ควรถูกกันออกจาก Research หรือ National LLM ด้วย

อีกเรื่องที่ต้องแยกคือ FAQ ระบุว่า AI Provider ถูกห้ามนำข้อมูลของผู้ใช้ไป Train Model ของตน ซึ่งเป็นคนละเรื่องกับการที่โครงการนำข้อมูลที่ผ่านกระบวนการตามที่กำหนดไปพัฒนา National LLM อย่างไรก็ดี FAQ ใช้ถ้อยคำว่ามีข้อตกลงห้าม AI Provider นำข้อมูลไป Train Model ขณะที่ Terms ข้อ 6.8 ใช้ถ้อยคำว่า Opt-out ในทุกกรณีที่ Provider เปิดให้ดำเนินการได้ ถ้อยคำสองส่วนนี้จึงควรอธิบายให้ตรงกัน ทั้งนี้ Terms ข้อ 6.8 ยังให้สิทธิผู้ใช้คัดค้านการประมวลผลเพื่อพัฒนาโมเดล จึงควรอธิบายด้วยว่าเมื่อผู้ใช้คัดค้านแล้วมีผลต่อ Data Pipeline อย่างไร

5.Prompt Monitoring และ Temporary Chat เป็นเรื่องที่ต้องอธิบายมากกว่าแค่ Privacy Notice

Privacy Notice วัตถุประสงค์ข้อ 13 ระบุถึงการตรวจสอบการใช้งานที่อาจขัดต่อกฎหมาย ความสงบเรียบร้อย หรือความมั่นคง และระบุว่าอาจมี Human Review ก่อนจำกัดสิทธิหรือส่งข้อมูลต่อ

ข้อมูลนี้เพียงพอให้ประชาชนตั้งคำถาม แต่ยังไม่เพียงพอให้สรุปว่า “เจ้าหน้าที่อ่านทุก Prompt”

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

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

Temporary Chat ก็มีประเด็นคล้ายกัน Privacy Notice ระบุว่าสามารถเก็บข้อมูลการสนทนาไว้ภายใน 1 ปี แม้ชื่อ Temporary อาจทำให้คนทั่วไปเข้าใจว่าไม่เก็บหรือเก็บเพียงช่วงสั้น ๆ

เรื่องนี้จึงไม่ใช่แค่ Retention Policy แต่เป็นเรื่องการสื่อสารด้วย แม้ Privacy Notice จะบอกระยะเวลาเก็บแล้ว แต่ยังควรอธิบายให้ผู้ใช้เข้าใจว่า Temporary Chat ต่างจาก Chat ปกติอย่างไร และคำว่า Temporary หมายถึงอะไรในทางปฏิบัติ

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

6.ปัญหาใหญ่ของโครงการนี้ ณ ตอนนี้ อาจไม่ใช่ Privacy Notice แต่คือ Privacy Trust

เมื่อมองทุกประเด็นรวมกัน ผมคิดว่ากิจกรรมประมวลผลหลายอย่างของ AiPASS ไม่ใช่เรื่องผิดปกติ การยืนยันตัวตน การเก็บ Log การส่ง Prompt ไปยัง AI Provider การตรวจจับ Abuse หรือการเก็บข้อมูลไว้ระยะหนึ่ง เป็นสิ่งที่พบได้ในบริการดิจิทัลทั่วไป

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

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

ความเสี่ยงจึงไม่ได้มีเฉพาะ Hacker แต่รวมถึงคนที่ “มีสิทธิ” เข้าถึงข้อมูลด้วย

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

เพราะนี่คือสิ่งที่จะสร้างความเชื่อมั่นได้มากกว่า Privacy Notice ที่ยาวขึ้นอีกหลายหน้า

นอกจากนี้ผมยังเห็นว่า การจัดการโครงการที่เกี่ยวกับข้อมูลส่วนบุคคลของรัฐควรนำหลัก Privacy by Design / by Default มาใช้ รวมถึงการทำ DPIA อย่างจริงจัง ซึ่งจะมีประโยชน์มากกับโครงการลักษณะนี้ เพราะมีทั้งการเชื่อมตัวตน การใช้ AI หลาย Provider, National LLM, Cross-border Processing, Profiling และ Content Monitoring หากโครงการได้ทำแล้ว ไม่จำเป็นต้องเปิดเผยทั้งฉบับ แต่อาจเปิดเผย Summary ว่าประเมินเรื่องอะไร พบความเสี่ยงอะไร และมีมาตรการลดความเสี่ยงอย่างไร

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

7.ในฐานะสมาคมวิชาชีพ ผมยังอยากได้คำตอบจาก สดช. 6 เรื่อง

1. เมื่อ TOR เป็นส่วนหนึ่งของสัญญาหลักและมีสัญญาแก้ไขเพิ่มเติมแล้ว ข้อกำหนดเรื่อง Personal Data, Data Localization, Cross-border Processing และ AI Provider เมื่ออ่านเอกสารสัญญาทั้งชุดประกอบกันควรตีความและนำไปปฏิบัติอย่างไร
2. Data Flow จริงเป็นอย่างไร ใครเข้าถึง Prompt, File, Conversation และข้อมูลระบุตัวตนได้ ข้อมูลถูกส่งต่อให้ผู้รับจ้างช่วงหรือหน่วยงานใดบ้าง มีข้อมูลอะไรส่งกลับไปยังสมาคม สถานศึกษา หรือต้นสังกัดหรือไม่ และทุกการเข้าถึงตรวจสอบย้อนหลังได้หรือไม่
3. DPA ระหว่าง สดช. กับผู้รับจ้างครอบคลุม AI Provider, Cloud และ Sub-processor ทุกทอดหรือไม่ รวมถึงเรื่อง No-training, Breach Notification การลบข้อมูล และการกำกับว่าผู้รับจ้างช่วงใช้ข้อมูลได้เพียงใด
4. ข้อมูลจาก AiPASS ถูกคัดเลือกและผ่าน De-identification หรือ Anonymization ณ จุดใดก่อนนำไปพัฒนา National LLM, Sensitive Personal Data ถูกกันออกอย่างไร และเมื่อผู้ใช้คัดค้านการใช้ข้อมูลเพื่อพัฒนาโมเดล ระบบดำเนินการอย่างไร
5. Temporary Chat, Content Monitoring และคำว่า “จำเป็นเพื่อประโยชน์สาธารณะ” มีหลักเกณฑ์ในทางปฏิบัติอย่างไร ไม่ใช่เพียงเขียนไว้ใน Privacy Notice
6. มีการทำ DPIA แล้วหรือไม่ และหากทำแล้ว สามารถเปิดเผยสาระสำคัญในระดับที่ประชาชนเข้าใจได้หรือไม่

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

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