ทุกวันนี้เราอาจขอให้ AI ช่วยสรุปรายงาน ตรวจอีเมล วิเคราะห์ข้อมูลลูกค้า แปลเอกสาร หรือให้คำแนะนำเกี่ยวกับปัญหาส่วนตัว การใช้งานเหล่านี้ช่วยประหยัดเวลาได้มาก แต่ในขณะเดียวกัน ข้อมูลที่เราป้อนเข้าไปอาจประกอบด้วยชื่อบุคคล ที่อยู่ อีเมล หมายเลขโทรศัพท์ เอกสารภายในองค์กร ข้อมูลสุขภาพ ข้อมูลทางการเงิน หรือรายละเอียดอื่นที่ไม่ควรถูกเปิดเผย
คำถามสำคัญจึงไม่ใช่แค่ว่า AI สามารถทำอะไรให้เราได้บ้าง แต่รวมถึงว่า เรากำลังมอบข้อมูลอะไรให้ AI เพื่อแลกกับความสะดวกนั้น
AI ทำให้ความเสี่ยงด้านข้อมูลเปลี่ยนไปอย่างไร
AI ไม่ได้สร้างปัญหาความเป็นส่วนตัวขึ้นมาใหม่ทั้งหมด การเก็บข้อมูลเกินความจำเป็น การเข้าถึงข้อมูลโดยไม่ได้รับอนุญาต และการรั่วไหลของข้อมูลเกิดขึ้นมานานก่อนยุค Generative AI อีก
สิ่งที่ AI ทำให้เกิดการเปลี่ยนแปลงคือ ขนาด ความเร็ว และความสามารถในการเชื่อมโยงข้อมูล ระบบ AI สามารถประมวลผลข้อมูลจำนวนมาก ค้นหารูปแบบที่มนุษย์มองไม่เห็น และคาดเดาข้อมูลบางอย่างจากรายละเอียดที่ดูเหมือนไม่สำคัญ เมื่อ AI ถูกเชื่อมต่อกับอีเมล ฐานข้อมูล เอกสารภายใน หรือระบบขององค์กร ผลกระทบจากความผิดพลาดหรือการถูกแฮ็กก็อาจขยายวงกว้างขึ้น
สำนักงานคณะกรรมาธิการข้อมูลแห่งออสเตรเลีย หรือ OAIC ระบุว่า Generative AI มีความเสี่ยงด้านความเป็นส่วนตัวเป็นพิเศษ เนื่องจากลักษณะการทำงานแบบคาดการณ์ การพึ่งพาข้อมูลที่เทรนให้ AI เป็นจำนวนมาก และความเป็นไปได้ที่จะถูกนำไปใช้ในทางที่ไม่เหมาะสม อย่างไรก็ตาม ความเสี่ยงไม่ได้เกิดขึ้นในระดับเดียวกันกับ AI ทุกระบบ แต่ขึ้นอยู่กับการออกแบบ ประเภทข้อมูล และวิธีนำระบบไปใช้ด้วย
1. การเก็บข้อมูลมากเกินความจำเป็น
การพัฒนา AI โดยเฉพาะโมเดลภาษาขนาดใหญ่ (large language models) มักอาศัยข้อมูลจากแหล่งต่าง ๆ ไม่ว่าจะเป็นเว็บไซต์ หนังสือ บทความ ฐานข้อมูล หรือข้อมูลที่จัดเตรียมขึ้นโดยเฉพาะ กระบวนการรวบรวมข้อมูลเหล่านี้ทำให้เกิดคำถามว่า เจ้าของข้อมูลทราบหรือไม่ว่าข้อมูลของตนถูกนำไปใช้ และเคยให้ความยินยอมไว้ในขอบเขตใด
สำหรับองค์กร ความเสี่ยงอีกด้านหนึ่งเกิดจากความคิดว่า ยิ่งให้ข้อมูลแก่ AI มากเท่าไร ผลลัพธ์ก็จะยิ่งดีขึ้น จึงอาจนำข้อมูลทั้งหมดเข้าสู่ระบบไว้ก่อน แม้งานที่ต้องการทำจะใช้เพียงบางส่วนเท่านั้น
แนวทางที่ปลอดภัยกว่าคือหลัก data minimisation หรือการใช้ข้อมูลให้น้อยที่สุดเท่าที่จำเป็น หากต้องการให้ AI วิเคราะห์แนวโน้มยอดขาย ระบบอาจไม่จำเป็นต้องทราบชื่อ ที่อยู่ หรือหมายเลขโทรศัพท์ของลูกค้าแต่ละคน หากต้องการให้ช่วยปรับภาษาในเอกสาร ก็อาจไม่จำเป็นต้องส่งรายงานทั้งฉบับพร้อมข้อมูลลับขององค์กร
2. ข้อมูลรั่วจากสิ่งที่เราเป็นคนนำเข้าไปเอง
ความเสี่ยงที่ใกล้ตัวที่สุดอาจไม่ได้เกิดจากแฮ็กเกอร์หรือช่องโหว่ที่ซับซ้อน แต่อาจเริ่มจากการคัดลอกข้อมูลแล้ววางลงในช่องสนทนาโดยไม่ทันคิด
พนักงานคนหนึ่งอาจนำสัญญาที่ยังไม่เปิดเผยให้ AI ช่วยสรุป อาจารย์อาจส่งข้อมูลนักศึกษาเพื่อให้ช่วยจัดกลุ่มผลการเรียน เจ้าหน้าที่อาจป้อนรายงานสุขภาพของผู้รับบริการ หรือผู้ใช้ทั่วไปอาจส่งภาพบัตรประจำตัวเพื่อขอให้ AI ช่วยอ่านข้อความ
แม้จุดประสงค์จะไม่ได้เป็นอันตราย แต่ผู้ใช้ควรถามก่อนเสมอว่า ตนเองมีสิทธิ์นำข้อมูลนั้นออกจากระบบเดิมหรือไม่ และบริการ AI ที่กำลังใช้อยู่มีนโยบายเก็บรักษา ประมวลผล และลบข้อมูลอย่างไร
คำว่า “ใช้ฟรี” หรือ “ใช้งานผ่านบัญชีส่วนตัว” ไม่ได้หมายความว่าข้อมูลนั้นเป็นพื้นที่ส่วนตัวโดยอัตโนมัติ โดยเฉพาะเมื่อนำเครื่องมือสาธารณะมาใช้กับข้อมูลของมหาวิทยาลัย บริษัท หน่วยงานรัฐ หรือลูกค้า
3. โมเดลอาจจดจำข้อมูลบางส่วน
โมเดล AI ไม่ได้ทำงานเหมือนฐานข้อมูลที่ค้นแล้วดึงเอกสารต้นฉบับออกมาตรง ๆ แต่การวิจัยด้านความปลอดภัยพบว่า โมเดลบางระบบอาจจดจำข้อมูลบางส่วนจากการเทรนหรือป้อนข้อมูลให้ AI โดยเฉพาะข้อความหรือข้อมูลที่มีลักษณะเฉพาะและพบไม่บ่อย
ในบางเงื่อนไข แฮ็กเกอร์อาจพยายามตั้งคำถามซ้ำ ๆ หรือใช้วิธีเฉพาะเพื่อทำให้ระบบเปิดเผยข้อมูลที่เกี่ยวข้องกับสิ่งที่ถูกเทรนให้ AI การโจมตีอาจรวมถึงการตรวจสอบว่าข้อมูลของบุคคลหนึ่งเคยอยู่ในข้อมูลที่ถูกป้อนหรือไม่ หรือพยายามสร้างข้อมูลบางส่วนกลับคืนมา
อย่างไรก็ตาม เรื่องนี้ควรอธิบายอย่างระมัดระวัง ไม่ใช่ว่า AI ทุกระบบจะจดจำและนำข้อมูลส่วนบุคคลออกมาตอบในการสนทนาตามปกติ ระดับความเสี่ยงขึ้นอยู่กับโมเดล ชุดข้อมูล วิธีการเทรนหรือป้อนข้อมูล การป้องกันของผู้ให้บริการ และความสามารถของแฮ็กเกอร์ รายงานด้าน Adversarial Machine Learning ของ NIST จึงจัดการจดจำข้อมูล การอนุมานสมาชิกของชุดข้อมูล และการสร้างข้อมูลกลับคืนไว้ในกลุ่มความเสี่ยงที่ควรได้รับการประเมินอย่างจริงจัง
4. ไม่มีชื่อ ไม่ได้หมายความว่าไม่รู้ว่าเป็นใคร
หลายองค์กรเชื่อว่าการลบชื่อออกจากข้อมูลเพียงอย่างเดียว ก็เพียงพอที่จะทำให้ข้อมูลนั้นไม่สามารถระบุตัวบุคคลได้ แต่ AI สามารถเชื่อมโยงรายละเอียดจากหลายแหล่งเข้าด้วยกันได้
ตัวอย่างเช่น ชุดข้อมูลหนึ่งอาจไม่มีชื่อ แต่มีอายุ ตำแหน่งงาน พื้นที่พักอาศัย และวันที่เข้ารับบริการ เมื่อเชื่อมกับข้อมูลสาธารณะหรือข้อมูลจากอีกฐานหนึ่ง รายละเอียดเหล่านี้อาจทำให้คาดเดาได้ว่าบุคคลนั้นคือใคร
ความเสี่ยงนี้เรียกว่า re-identification หรือ deanonymisation ซึ่งหมายถึงการนำข้อมูลที่ดูเหมือนไม่ระบุตัวบุคคลกลับมาเชื่อมโยงกับบุคคลจริงได้ NIST เตือนว่า AI อาจสร้างความเสี่ยงใหม่ผ่านการอนุมานตัวตนหรือข้อมูลส่วนตัวจากข้อมูลที่กระจัดกระจายอยู่ในหลายแหล่ง
ดังนั้น การลบแค่ชื่อและหมายเลขประจำตัวอาจยังไม่เพียงพอ องค์กรต้องพิจารณาด้วยว่า เมื่อนำรายละเอียดที่เหลือมารวมกันแล้ว ยังสามารถชี้กลับไปยังบุคคลใดบุคคลหนึ่งได้หรือไม่
5. เมื่อคำสั่งที่เป็นอันตรายซ่อนอยู่ในเอกสาร
Prompt injection คือการใส่คำสั่งที่ออกแบบมาเพื่อทำให้ AI เพิกเฉยต่อข้อกำหนดเดิม หรือทำงานในลักษณะที่ผู้พัฒนาไม่ได้ตั้งใจ คำสั่งดังกล่าวอาจมาจากผู้ใช้โดยตรง หรือซ่อนอยู่ในเว็บไซต์ อีเมล และเอกสารที่ AI ถูกสั่งให้อ่าน
ลองนึกถึง AI ที่มีหน้าที่อ่านอีเมลและจัดทำสรุปประจำวัน หากมีคำสั่งซ่อนอยู่ในอีเมลฉบับหนึ่งว่า ให้ค้นหาเอกสารลับแล้วส่งข้อมูลออกไป ระบบที่ไม่ได้จำกัดสิทธิ์อย่างเหมาะสมอาจถูกชักนำให้ทำสิ่งที่ไม่ควรทำ
Prompt injection จึงน่ากังวลมากขึ้นเมื่อ AI ไม่ได้มีหน้าที่เพียงตอบคำถาม แต่สามารถเปิดไฟล์ เข้าถึงฐานข้อมูล ส่งข้อความ หรือดำเนินการแทนผู้ใช้ได้ OWASP จัดให้ prompt injection เป็นหนึ่งในความเสี่ยงสำคัญของแอปพลิเคชันที่ใช้โมเดลภาษา
ปัญหาไม่ได้อยู่ที่ AI “ไม่เชื่อฟัง” เพียงอย่างเดียว แต่อยู่ที่ระบบรอบตัว AI มอบสิทธิ์ให้มันมากเพียงใด
มีการฝึกโมเดลแบบปิดหรือไม่เพื่อความปลอดภัยของข้อมูล
บริการ AI หลายแห่งเปิดโอกาสให้ผู้ใช้ปิดการนำบทสนทนาไปใช้ปรับปรุงหรือฝึกโมเดล การปิดตัวเลือกนี้เป็นขั้นตอนที่ควรทำ โดยเฉพาะเมื่อใช้บัญชีส่วนบุคคล
แต่การปิดการฝึกโมเดลไม่ได้มีความหมายเดียวกับการไม่เก็บข้อมูลเลย บริการอาจยังจัดเก็บบทสนทนาตามระยะเวลาที่กำหนด เพื่อแสดงประวัติการใช้งาน ตรวจสอบการละเมิด หรือรักษาความปลอดภัยของระบบ นโยบายยังแตกต่างกันระหว่างบัญชีส่วนบุคคล บัญชีธุรกิจ API และบริการของแต่ละบริษัท
ตัวอย่างเช่น OpenAI ระบุว่า ผู้ใช้สามารถปิด “Improve the model for everyone” เพื่อไม่ให้นำบทสนทนาใหม่ไปใช้ฝึกโมเดล แต่บทสนทนาอาจยังปรากฏอยู่ในประวัติการใช้งาน ส่วน Temporary Chat จะไม่ถูกนำไปฝึกโมเดลและมีกระบวนการลบออกจากระบบภายในระยะเวลาที่กำหนด รายละเอียดเหล่านี้สามารถตรวจสอบได้จากหน้า Data Controls ของ OpenAI
ดังนั้น ผู้ใช้ไม่ควรหยุดอยู่ที่การปิดสวิตช์เพียงตัวเดียว แต่ควรตรวจสอบนโยบายการเก็บรักษา การลบ การเข้าถึง และการนำข้อมูลไปใช้ประกอบกัน
ก่อนส่งข้อมูลให้ AI เราควรทำอะไรบ้าง
ความปลอดภัยไม่ได้ขึ้นอยู่กับมาตรการของผู้ให้บริการเพียงอย่างเดียว แต่เริ่มจากการตัดสินใจของผู้ใช้ก่อนกดส่งข้อความหรืออัปโหลดเอกสาร หลักปฏิบัติที่ควรนำมาใช้มีดังนี้
อย่าใส่ข้อมูลที่เราไม่มีสิทธิ์เปิดเผย แม้จะใช้ AI เพียงเพื่อสรุป แปล หรือตรวจแก้ภาษา หากเอกสารเป็นขององค์กร ลูกค้า นักศึกษา ผู้ป่วย หรือบุคคลอื่น ผู้ใช้ต้องตรวจสอบก่อนว่าตนได้รับอนุญาตให้นำข้อมูลออกจากระบบเดิมหรือไม่
ส่งเฉพาะข้อมูลที่จำเป็นต่องาน หากต้องการให้ AI ปรับภาษาเพียงหนึ่งย่อหน้า ก็ไม่จำเป็นต้องอัปโหลดเอกสารทั้งฉบับ หลัก data minimisation หรือการใช้ข้อมูลให้น้อยที่สุดช่วยลดผลกระทบหากเกิดความผิดพลาดหรือข้อมูลรั่วไหล
ลบหรือแทนที่ข้อมูลที่ระบุตัวบุคคลได้ เช่น ชื่อ อีเมล หมายเลขโทรศัพท์ เลขประจำตัว ข้อมูลสุขภาพ ข้อมูลทางการเงิน และความลับทางธุรกิจ อย่างไรก็ตาม ต้องพิจารณาด้วยว่า รายละเอียดที่เหลือสามารถเชื่อมโยงกลับไปหาบุคคลเดิมได้หรือไม่ เพราะการลบชื่อเพียงอย่างเดียวอาจยังไม่เพียงพอ
เลือกใช้บริการที่องค์กรอนุมัติ พร้อมตรวจสอบว่าผู้ให้บริการเก็บข้อมูลไว้นานเพียงใด ใครสามารถเข้าถึงได้ ผู้ใช้สามารถลบข้อมูลได้หรือไม่ และข้อมูลจะถูกนำไปฝึกหรือปรับปรุงโมเดลหรือไม่ บัญชีส่วนบุคคล บัญชีองค์กร และการใช้งานผ่าน API อาจมีเงื่อนไขแตกต่างกัน
ปิดการนำบทสนทนาไปใช้ฝึกโมเดลเมื่อมีตัวเลือก แต่ต้องเข้าใจว่า การปิดการฝึกโมเดลไม่ได้หมายความว่าข้อมูลจะไม่ถูกจัดเก็บเลย บริการอาจยังเก็บบันทึกไว้ตามระยะเวลาหรือนโยบายด้านความปลอดภัย ตัวอย่างเช่น ChatGPT แยกการควบคุมการนำบทสนทนาไปปรับปรุงโมเดลออกจากการจัดเก็บประวัติการสนทนา ผู้ใช้จึงควรตรวจสอบทั้งสองส่วนจากหน้า OpenAI Data Controls
กำหนดสิทธิ์ให้ AI เท่าที่จำเป็น สำหรับองค์กรควรใช้หลัก least privilege หาก AI มีหน้าที่อ่านเอกสาร ก็ควรได้รับสิทธิ์แบบอ่านอย่างเดียวและเข้าถึงเฉพาะข้อมูลที่เกี่ยวข้อง ควรใช้ร่วมกับการยืนยันตัวตนหลายขั้นตอนหรือ MFA การเข้ารหัส การบันทึกกิจกรรม และการตรวจสอบย้อนหลัง
ให้มนุษย์อนุมัติก่อนดำเนินการสำคัญ โดยเฉพาะเมื่อ AI สามารถส่งอีเมล เปิดเผยเอกสาร เปลี่ยนแปลงข้อมูล ทำธุรกรรม หรือสื่อสารกับบุคคลภายนอก ไม่ควรปล่อยให้ระบบดำเนินการที่มีผลกระทบสูงโดยอัตโนมัติทั้งหมด
ประเมินความเป็นส่วนตัวตั้งแต่ก่อนเริ่มโครงการ องค์กรควรถามตั้งแต่ต้นว่า จำเป็นต้องใช้ข้อมูลใด ความเสียหายจะเกิดกับใครหากข้อมูลถูกเปิดเผย และจะลบข้อมูลเมื่อหมดความจำเป็นอย่างไร แนวทางนี้สอดคล้องกับหลัก privacy by design ซึ่งให้ความสำคัญกับการป้องกันตั้งแต่ขั้นออกแบบ แทนการรอให้เกิดเหตุแล้วจึงแก้ไข ตามคำแนะนำของ Information Commissioner’s Office
รายการเหล่านี้ไม่สามารถกำจัดความเสี่ยงได้ทั้งหมด แต่ช่วยให้เราตัดสินใจก่อนส่งข้อมูล แทนที่จะเพิ่งกลับมาตั้งคำถามหลังข้อมูลออกจากการควบคุมของเราไปแล้ว
ไม่จำเป็นต้องหยุดใช้ AI แต่ต้องรู้จักตั้งขอบเขต
AI มีประโยชน์อย่างมากต่อการเรียน การทำงาน การวิจัย และการสร้างสรรค์เนื้อหา ปัญหาไม่ได้อยู่ที่การใช้หรือไม่ใช้ AI เพียงสองทาง แต่อยู่ที่ว่า เราเข้าใจระบบที่กำลังใช้มากเพียงใด และรู้หรือไม่ว่ากำลังนำข้อมูลของใครเข้าไปเกี่ยวข้อง
ก่อนกดส่งข้อความหรืออัปโหลดเอกสาร เราอาจหยุดคิดเพียงไม่กี่วินาทีว่า ข้อมูลนี้เป็นของใคร เรามีสิทธิ์ใช้หรือไม่ จำเป็นต้องส่งทั้งหมดหรือเปล่า และหากข้อมูลนี้ถูกเปิดเผยขึ้นมา จะส่งผลกระทบต่อใครบ้าง
ความเป็นส่วนตัวในยุค AI จึงไม่ใช่เรื่องของการซ่อนตัวจากเทคโนโลยี แต่คือความสามารถในการกำหนดว่า ข้อมูลใดควรถูกใช้ ใช้เพื่อวัตถุประสงค์ใด ใครควรเข้าถึง และควรถูกเก็บไว้นานเพียงใด
เราไม่จำเป็นต้องกลัวว่า AI จะรู้จักเรา แต่เราควรรู้ว่า เมื่อใดที่ AI กำลังรู้จักเรามากเกินไป
