AiPASS กับองค์กร โอกาสพัฒนาทักษะ AI ของพนักงาน และโจทย์การกำกับการใช้ AI อย่างมีธรรมาภิบาล
ดร.อุดมธิปก ไพรเกษตร นายกสมาคมผู้ตรวจสอบและให้คำปรึกษาการคุ้มครองข้อมูลส่วนบุคคลไทย
อาจารย์สุกฤษ โกยอัครเดช ประธานฝ่ายวิเทศสัมพันธ์และเลขาธิการสมาคมผู้ตรวจสอบและให้คำปรึกษาการคุ้มครองข้อมูลส่วนบุคคลไทย
ดร.ณัฏฐ์ ธนวนกุล ประธานฝ่ายมาตรฐานการคุ้มครองข้อมูลส่วนบุคคล สมาคมผู้ตรวจสอบและให้คำปรึกษาการคุ้มครองข้อมูลส่วนบุคคลไทย
เมื่อโครงการ 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 ที่มีความเสี่ยงสูง
เมื่อโครงการ 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 ที่มีความเสี่ยงสูง