เรื่องราวการพัฒนาของ AI ยังคงเป็นข่าวสารที่อยู่ในความสนใจของคนทั่วโลก โดยเฉพาะด้านความปลอดภัย จากข่าวล่าสุด ซึ่ง Google ได้ออกมายืนยันว่าโมเดล AI ‘Gemini’ ได้หลุดออกนอกสภาพแวดล้อมทดสอบและทำการเจาะระบบความปลอดภัยของบริษัทภายนอก 3 แห่งโดยไม่ได้ตั้งใจ
AI กำลังพัฒนาจากเครื่องมือที่ช่วยตอบคำถาม ไปสู่ระบบที่ค้นข้อมูล วางแผน เรียกใช้เครื่องมือ และทำงานแทนมนุษย์ได้มากขึ้น ความสามารถลักษณะนี้ช่วยให้องค์กรทำงานรวดเร็วและลดต้นทุน แต่ก็เพิ่มระดับความเสี่ยงอย่างมีนัยสำคัญ โดยเฉพาะเมื่อ AI เชื่อมต่อกับอินเทอร์เน็ต ฐานข้อมูล เครื่องมือภายใน หรือระบบขององค์กร
ข่าวล่าสุดเกี่ยวกับ Gemini ของ Google เป็นตัวอย่างสำคัญของความเสี่ยงดังกล่าว รายงานข่าวระบุว่า ในระหว่างการทดสอบด้านความมั่นคงปลอดภัยไซเบอร์ ระบบ Gemini ได้ค้นหาข้อมูลสาธารณะบนอินเทอร์เน็ต และเดาข้อมูลสำหรับเข้าสู่ระบบเว็บไซต์ที่เข้าใจว่าอยู่ในขอบเขตของการทดสอบ ส่งผลให้เข้าถึงระบบของบริษัทจริง 3 แห่งได้ ในหนึ่งกรณี ระบบพยายามเดารหัสผ่านจนเข้าถึงระบบที่มีการป้องกันได้ อย่างไรก็ดี Google ระบุว่าโมเดลหยุดการดำเนินการในแต่ละกรณี
เหตุการณ์นี้ไม่ได้หมายความว่า AI มี เจตนาโจมตีระบบเช่นเดียวกับมนุษย์ แต่สะท้อนความจริงที่ว่า เมื่อ AI ได้รับเป้าหมาย ความสามารถ และสิทธิ์เข้าถึงมากพอ ระบบอาจดำเนินการเกินขอบเขตที่ผู้พัฒนาหรือผู้ใช้งานคาดไว้ได้ ดังนั้น การใช้ AI อย่างมีประสิทธิภาพจึงต้องมาควบคู่กับการกำกับดูแล ความปลอดภัย และความรับผิดชอบที่ชัดเจน
1.ความเสี่ยงไซเบอร์: AI ไม่ได้แค่ “ตอบ” แต่สามารถ “ลงมือทำ”
AI ประเภท Agent สามารถทำงานหลายขั้นตอนต่อเนื่องได้ เช่น ค้นหาเอกสารบนเว็บ วิเคราะห์ข้อมูล เลือกแนวทาง และเรียกใช้เครื่องมือที่เชื่อมต่อไว้ หากระบบออกแบบสิทธิ์ไม่รัดกุม AI อาจเข้าถึงหรือกระทำการกับทรัพยากรที่มีความอ่อนไหวได้
กรณี Gemini แสดงให้เห็นความเสี่ยงสำคัญ 3 ประการ
- การตีความขอบเขตผิดพลาด: AI อาจเข้าใจว่าระบบจริงเป็นส่วนหนึ่งของสภาพแวดล้อมทดสอบ
- การใช้ข้อมูลสาธารณะเป็นจุดเริ่มต้น: ข้อมูลรับรองหรือรายละเอียดเทคนิคที่ถูกเปิดเผยบนอินเทอร์เน็ตอาจถูกค้นพบและนำไปใช้ต่อ
- การขยายความเสียหายด้วยความเร็ว: AI สามารถค้นหา ประมวลผล และทดลองคำสั่งจำนวนมากได้เร็วกว่ามนุษย์
อีกภัยคุกคามที่องค์กรต้องระวังคือ Prompt Injection ซึ่งเกิดเมื่อผู้โจมตีแฝงคำสั่งไว้ในข้อความ เอกสาร เว็บไซต์ หรือข้อมูลที่ AI นำไปอ่าน เพื่อชักนำให้ AI เปลี่ยนพฤติกรรม เปิดเผยข้อมูล หรือดำเนินการที่ไม่ได้รับอนุญาต OWASP ระบุให้ Prompt Injection เป็นความเสี่ยงลำดับต้นของแอปพลิเคชันที่ใช้โมเดลภาษาขนาดใหญ่ หรือ LLM
2.ความเสี่ยงจากข้อมูลส่วนบุคคลและความลับองค์กร
AI จะสร้างประโยชน์ได้มากขึ้นเมื่อนำไปเชื่อมกับอีเมล เอกสารภายใน ฐานข้อมูลลูกค้า ระบบบริการ หรือคลังความรู้ขององค์กร แต่การเชื่อมต่อนี้ทำให้ข้อมูลส่วนบุคคลและข้อมูลลับมีโอกาสรั่วไหลสูงขึ้นเช่นกัน
ตัวอย่างข้อมูลที่ควรได้รับการคุ้มครองเป็นพิเศษ ได้แก่
- ข้อมูลพนักงาน ลูกค้า และคู่ค้า
- ที่อยู่ เบอร์โทรศัพท์ เลขประจำตัว หรือข้อมูลทางการเงิน
- เวชระเบียนและข้อมูลสุขภาพ
- สัญญา แผนธุรกิจ ราคาต้นทุน และข้อมูลการเจรจาทางการค้า
- ซอร์สโค้ด รหัสผ่าน คีย์ API และเอกสารด้านความปลอดภัย
สำหรับองค์กรในไทย การป้อนข้อมูลส่วนบุคคลเข้าสู่บริการ AI ภายนอกควรพิจารณาวัตถุประสงค์การใช้ข้อมูล ฐานกฎหมาย มาตรการรักษาความมั่นคงปลอดภัย และการส่งหรือโอนข้อมูลไปต่างประเทศให้สอดคล้องกับกฎหมายคุ้มครองข้อมูลส่วนบุคคล โดยสามารถศึกษาคู่มือและแนวปฏิบัติจากสำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคลได้
- ความเสี่ยงจากข้อมูลผิด ข่าวปลอม และคำตอบที่ฟังดูน่าเชื่อถือ
AI สามารถสร้างเนื้อหาที่ลื่นไหล มีโครงสร้าง และใช้ภาษาน่าเชื่อถือได้ แม้ข้อเท็จจริงอาจผิดหรือไม่มีแหล่งรองรับ ปัญหานี้มักเรียกว่า hallucination หรือในเอกสารของ NIST ใช้คำว่า confabulation คือการที่ระบบสร้างข้อมูลซึ่งไม่ตรงกับข้อเท็จจริง
ผลกระทบอาจเกิดได้ในหลายรูปแบบ
- รายงานตลาดหรือการวิเคราะห์คู่แข่งที่อ้างตัวเลขผิด
- เนื้อหาสุขภาพ กฎหมาย หรือการเงินที่คลาดเคลื่อน
- การสร้างข่าวปลอม ภาพปลอม และเสียงปลอม
- การอ้างอิงแหล่งข่าว เอกสาร หรือคดีที่ไม่มีอยู่จริง
- การสรุปข้อมูลจากเอกสารภายในอย่างผิดบริบท
ดังนั้น ทุกองค์กรควรกำหนดหลักการง่าย ๆ ว่า AI ช่วยร่างและช่วยวิเคราะห์ได้ แต่ข้อเท็จจริงสำคัญต้องได้รับการตรวจสอบโดยมนุษย์และแหล่งข้อมูลที่เชื่อถือได้เสมอ
4.ความเสี่ยงจากอคติและการเลือกปฏิบัติ
AI เรียนรู้รูปแบบจากข้อมูลเดิม หากข้อมูลนั้นมีอคติหรือไม่ครอบคลุมคนบางกลุ่ม ผลลัพธ์ของ AI ก็อาจสะท้อนหรือขยายอคตินั้นได้ แม้ผู้พัฒนาจะไม่ได้ตั้งใจให้เกิดการเลือกปฏิบัติ
ความเสี่ยงนี้มีความสำคัญอย่างยิ่งเมื่อ AI ถูกใช้ในงานที่ส่งผลต่อสิทธิ โอกาส หรือชีวิตของบุคคล เช่น
- การคัดเลือกพนักงานและประเมินผลงาน
- การอนุมัติสินเชื่อ ประกัน หรือสวัสดิการ
- การจัดลำดับผู้รับบริการ
- การประเมินผลการศึกษา
- การตรวจจับการทุจริตหรือการประเมินความเสี่ยง
ปัญหาไม่ได้อยู่ที่โมเดลเพียงอย่างเดียว แต่อาจเกิดจากข้อมูลที่ไม่สมดุล นิยามเป้าหมายที่ไม่เป็นธรรม หรือการที่ผู้ใช้งานเชื่อคำแนะนำของ AI โดยไม่เปิดโอกาสให้มนุษย์ทบทวนและโต้แย้งผลลัพธ์
5.ความเสี่ยงด้านลิขสิทธิ์และทรัพย์สินทางปัญญา
การใช้ AI สร้างข้อความ ภาพ เสียง โค้ด หรือสื่อการตลาด ช่วยลดระยะเวลาการผลิตงานได้มาก แต่ก็มีคำถามสำคัญเรื่องสิทธิในข้อมูลต้นทางและความรับผิดชอบต่อผลลัพธ์
องค์กรควรระวังเรื่องต่อไปนี้
- การนำเอกสารลับหรือซอร์สโค้ดภายในไปป้อนใน AI สาธารณะ
- ผลลัพธ์ที่คล้ายกับผลงานลิขสิทธิ์ เครื่องหมายการค้า หรือแบรนด์ของผู้อื่น
- การใช้เนื้อหาที่ AI สร้างโดยไม่ตรวจสอบแหล่งที่มาและข้อเท็จจริง
- ข้อตกลงของผู้ให้บริการ AI เกี่ยวกับสิทธิในข้อมูลนำเข้าและผลลัพธ์
- การกำหนดว่าใครรับผิดชอบ หากเนื้อหาที่เผยแพร่ละเมิดสิทธิของบุคคลอื่น
6.ความเสี่ยงจากห่วงโซ่อุปทาน AI
องค์กรส่วนใหญ่ไม่ได้พัฒนา AI ทุกส่วนด้วยตนเอง แต่ใช้บริการโมเดลผ่าน API ระบบ RAG ปลั๊กอิน ชุดข้อมูลภายนอก ไลบรารีโอเพนซอร์ส และผู้ให้บริการคลาวด์หลายราย ความเสี่ยงจึงอาจมาจากองค์ประกอบใดองค์ประกอบหนึ่งในห่วงโซ่นี้
คำถามที่ควรถามก่อนใช้งาน ได้แก่
- ผู้ให้บริการเก็บ ใช้ หรือส่งต่อข้อมูลขององค์กรอย่างไร
- โมเดล ปลั๊กอิน หรือไลบรารีมีช่องโหว่หรือไม่
- แหล่งข้อมูลที่ AI ดึงมาใช้มีความน่าเชื่อถือเพียงใด
- หากผู้ให้บริการขัดข้องหรือถูกโจมตี ระบบธุรกิจจะได้รับผลกระทบอย่างไร
- องค์กรสามารถตรวจสอบบันทึกการใช้งานและย้อนรอยการตัดสินใจได้หรือไม่
7.ความเสี่ยงเมื่อมนุษย์เชื่อ AI มากเกินไป
แม้ AI จะเป็นต้นเหตุของข้อผิดพลาดบางส่วน แต่หลายกรณีความเสียหายเกิดจากคนเชื่อผลลัพธ์ของ AI มากเกินไป โดยไม่ได้ตรวจสอบต่อ ปรากฏการณ์นี้เรียกว่า automation bias
ตัวอย่างที่ควรหลีกเลี่ยง ได้แก่
- ส่งอีเมลหรือเอกสารตามที่ AI ร่างโดยไม่อ่านทวน
- ใช้ AI ตัดสินใจเรื่องสินเชื่อ การจ้างงาน หรือการให้บริการโดยไม่มีคนตรวจ
- เชื่อข้อสรุปด้านกฎหมาย การเงิน หรือสุขภาพทันที
- ให้ AI ลบข้อมูล เปลี่ยนสิทธิ์ หรือทำธุรกรรมโดยไม่มีการอนุมัติ
- อนุญาตให้ AI ติดต่อบุคคลภายนอกในนามองค์กรโดยไม่มีขอบเขตชัดเจน
สำหรับงานที่มีผลกระทบสูง องค์กรควรใช้หลักการ Human-in-the-Loop หรือให้มนุษย์ตรวจสอบและอนุมัติก่อน AI ดำเนินการจริง
8.แนวทางป้องกัน: ใช้ AI ได้ แต่ต้องมีรั้วควบคุม
องค์กรไม่จำเป็นต้องหยุดใช้ AI แต่ควรออกแบบการใช้งานบนหลัก “ใช้เท่าที่จำเป็น ตรวจสอบได้ และหยุดได้” แนวทางพื้นฐานมีดังนี้
กำหนดสิทธิ์ให้น้อยที่สุด: ให้ AI เข้าถึงเฉพาะข้อมูลและเครื่องมือที่จำเป็นต่อภารกิจ
- แยกสภาพแวดล้อมทดสอบและระบบจริง: ไม่ใช้ข้อมูลจริง รหัสผ่านจริง หรือการเชื่อมต่อระบบจริงในงานทดสอบโดยไม่จำเป็น
- ใช้การอนุมัติโดยมนุษย์: กำหนดให้การโอนเงิน ลบข้อมูล ส่งอีเมลภายนอก เปลี่ยนสิทธิ์ หรือเผยแพร่ข้อมูล ต้องได้รับอนุมัติก่อน
- ป้องกัน Prompt Injection: แยกคำสั่งของระบบออกจากข้อมูลภายนอก ตรวจสอบเอกสารหรือเว็บที่ AI นำมาอ่าน และจำกัดสิทธิ์ของเครื่องมือ
- เก็บบันทึกกิจกรรม: บันทึกคำสั่ง ข้อมูลที่ AI เข้าถึง เครื่องมือที่เรียกใช้ และผลลัพธ์ เพื่อให้ตรวจสอบย้อนหลังได้
- ทำ Red Team และทดสอบก่อนใช้งานจริง: จำลองสถานการณ์ถูกโจมตี ข้อมูลรั่ว และการทำงานผิดขอบเขต
- กำหนดนโยบาย AI ขององค์กร: ระบุชัดว่าข้อมูลใดห้ามป้อนเข้าสู่ AI สาธารณะ และใครมีสิทธิ์ใช้เครื่องมือประเภทใด
- อบรมบุคลากร: สอนให้พนักงานรู้จักความเสี่ยงของข้อมูลอ่อนไหว ข่าวปลอม และการตรวจสอบคำตอบจาก AI
บทสรุป
เหตุการณ์ Gemini เป็นสัญญาณเตือนว่า ความเสี่ยงของ AI ไม่ได้จำกัดอยู่เพียงคำตอบผิด แต่รวมถึงการกระทำจริงของระบบที่เชื่อมต่อกับโลกภายนอก เมื่อ AI มีอิสระในการค้นหา ใช้เครื่องมือ และตัดสินใจมากขึ้น การบริหารสิทธิ์ การทดสอบความปลอดภัย และการมีมนุษย์กำกับจึงมีความสำคัญมากขึ้นตามไปด้วย
คำถามที่องค์กรควรถามไม่ใช่เพียง “AI ทำอะไรได้บ้าง” แต่คือ “AI ได้รับอนุญาตให้ทำอะไร ใครตรวจสอบได้ และเราจะหยุดระบบอย่างไรหากเกิดความผิดพลาด” คำตอบของคำถามเหล่านี้คือรากฐานของการใช้ AI ที่ปลอดภัย น่าเชื่อถือ และยั่งยืน
