สแกนหน้า-เสียงอาจไม่รอด: ภัยคุกคามจาก Deepfake ที่องค์กรต้องรู้เท่าทัน

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

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

NIST ใช้คำว่า presentation attack detection หรือ PAD สำหรับการตรวจจับความพยายามปลอมตัวเพื่อหลอกระบบ biometrics และในรายงาน FATE Part 10 ที่เผยแพร่วันที่ 19 กันยายน 2023 NIST ทดสอบซอฟต์แวร์ตรวจจับการโจมตีลักษณะนี้กับภาพ 2D หลายรูปแบบ ส่วนผลที่สำคัญสำหรับคนทำงานจริงคือ ประสิทธิภาพของแต่ละระบบต่างกันมาก และไม่มีระบบไหนที่ตรวจจับการโจมตีได้ครบทุกแบบ นี่ไม่ได้แปลว่า biometrics ใช้ไม่ได้ แต่แปลว่ามันไม่ควรถูกมองเป็น “คำตอบสุดท้าย” โดยไม่มีชั้นป้องกันอื่นประกบ

ปัญหาไม่ได้มีแค่ระบบโดนหลอก แต่คนใน workflow ก็โดนหลอกได้

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

FBI ออก Public Service Announcement วันที่ 15 พฤษภาคม 2025 เรื่องการปลอมตัวเป็นเจ้าหน้าที่ระดับสูงของสหรัฐฯ ผ่านข้อความและเสียงที่สร้างด้วย AI เพื่อหลอกให้เหยื่อไว้ใจ จากนั้นค่อยพาไปสู่การเข้าถึงบัญชีหรือข้อมูลเพิ่มเติม รายละเอียดนี้สำคัญมาก เพราะมันชี้ให้เห็นว่า Deepfake ไม่ได้อยู่แค่ในห้องทดลองหรือเดโม แต่ถูกเอาไปใช้เป็นส่วนหนึ่งของ social engineering ที่อาศัยความเร่งด่วน ความคุ้นเคย และอำนาจตามตำแหน่งเหมือนกับ phishing หรือ business email compromise ในอดีต

ถ้าองค์กรยังมีขั้นตอนประมาณนี้ ความเสี่ยงจะยิ่งสูง:

1. พนักงาน help desk reset บัญชีเพราะ “เสียงเหมือน” หรือ “หน้าบนวิดีโอคอลดูใช่”
2. ฝ่ายการเงินรีบปล่อยรายการเพราะมีคำสั่งด่วนจากผู้บริหารในช่องทางแชตหรือเสียง
3. ฝ่าย HR หรือ vendor management ยอมเปลี่ยนข้อมูลสำคัญโดยพึ่งการยืนยันตัวตนแบบสัญญาณเดียว
4. ระบบ onboarding ระยะไกลเชื่อ face scan หรือ voice sample แบบไม่มีกระบวนการตรวจทานกรณีเสี่ยง

Biometrics ยังมีประโยชน์ แต่ไม่ควรยืนอยู่ตัวเดียว

ผมคิดว่าจุดที่ต้องระวังคือเวลาเราพูดถึง Deepfake คนมักเผลอไปสุดสองทาง ทางแรกคือ panic จนมองว่า face หรือ voice biometrics ใช้ไม่ได้แล้วทั้งหมด อีกทางคือชะล่าใจว่าถ้ามี liveness detection หรือมี vendor ที่บอกว่าตรวจ Deepfake ได้ก็พอแล้ว

ความจริงน่าจะอยู่ตรงกลางมากกว่า

NIST อธิบายไว้ใน glossary ว่า PAD เป็นการตรวจจับความพยายามโจมตีระบบ biometrics โดยอัตโนมัติ และส่วนหนึ่งของสิ่งที่คนมักเรียกว่า liveness detection ก็คือการพยายามดูว่าตัวอย่างที่ป้อนเข้ามามาจากบุคคลจริง ณ จุดเก็บข้อมูลหรือไม่ แต่ในทางปฏิบัติ การมี PAD ไม่ได้แปลว่าปลอดภัยอัตโนมัติ เพราะคุณยังต้องถามต่ออีกหลายชั้น เช่น

1. ใช้กับช่องทางไหนบ้าง
2. มี fallback อย่างไรเมื่อระบบไม่มั่นใจ
3. กรณีมูลค่าสูงหรือเสี่ยงสูงต้อง escalate ไปหาใคร
4. log และหลักฐานถูกเก็บพอสำหรับตรวจสอบย้อนหลังหรือไม่

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

ปัญหาใหญ่ของ Voice Deepfake คือมันหลอกกระบวนการที่รีบได้ดีมาก

ถ้า face deepfake มักถูกนึกถึงในงาน eKYC หรือการยืนยันตัวตนผ่านกล้อง voice deepfake จะน่ากลัวมากใน workflow ที่คนต้องตัดสินใจเร็ว เช่น โทรมาขอเปลี่ยนขั้นตอน ขอส่งเงินด่วน ขอแชร์ OTP หรือขอให้ย้ายไปคุยในช่องทางใหม่

FTC เขียนไว้ชัดในบทความเกี่ยวกับการป้องกัน harms จาก AI-enabled voice cloning เมื่อเดือนพฤศจิกายน 2023 ว่าความเสี่ยงจากการโคลนเสียงไม่ควรถูกแก้ด้วยเทคโนโลยีอย่างเดียว และในบทความติดตามผลเดือนเมษายน 2024 ก็ย้ำว่าไม่มี silver bullet เดียวสำหรับป้องกันการฉ้อโกงจากเสียงปลอม สิ่งนี้สอดคล้องกับสิ่งที่องค์กรควรทำในโลกจริงมาก คืออย่าเผลอซื้อ narrative ว่า “มีตัวตรวจจับแล้วจบ” แต่ต้องออกแบบ control รอบกระบวนการด้วย

ตัวอย่างง่ายที่สุดคือ ถ้ามีคำสั่งที่ผิดปกติจากผู้บริหาร ไม่ว่าจะมาทางเสียง วิดีโอ หรือข้อความ ควรมี out-of-band verification เสมอ เช่น โทรกลับผ่านหมายเลขใน contact list ที่องค์กรควบคุมเอง ไม่ใช่หมายเลขที่ผู้ติดต่อส่งมาในข้อความนั้น หรือใช้ dual approval ในรายการโอนเงินและการเปลี่ยนข้อมูลบัญชีผู้รับเงิน

ถ้าจะเริ่มป้องกันแบบ practical ผมคิดว่าควรเริ่มจาก 6 เรื่องนี้

1. แยก low-risk กับ high-risk action ให้ชัด

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

2. บังคับใช้ out-of-band verification ในกรณีเสี่ยง

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

3. อย่าให้ help desk หรือ frontline staff แบกรับความเสี่ยงคนเดียว

หลายครั้ง workflow หน้าแนวรบอย่าง help desk, call centre, HR support หรือ finance operations ถูกออกแบบให้เร็ว แต่ไม่ได้เผื่อว่าผู้โจมตีอาจใช้เสียงหรือภาพปลอมกดดันให้รีบตัดสินใจ ทางแก้ที่คุ้มคือเตรียม script, escalation path และเหตุผลที่พนักงานสามารถพูดได้ทันทีว่า “เคสนี้ต้องตรวจผ่านขั้นตอนเพิ่มเติม”

4. ใช้ biometrics ร่วมกับ risk signals อื่น

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

5. ซ้อมเหตุการณ์ Deepfake แบบ tabletop

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

6. เก็บ log และหลักฐานให้พอสำหรับตรวจสอบย้อนหลัง

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

สิ่งที่องค์กรไม่ควรทำ

จากมุมมองของผม มี 4 อย่างที่ไม่ควรทำถ้าไม่อยากเปิดประตูให้ Deepfake ง่ายเกินไป

1. เชื่อ vendor claim แบบกว้าง ๆ ว่าตรวจ Deepfake ได้ทั้งหมดโดยไม่ดูผลทดสอบอิสระ
2. ออกแบบ workflow ที่ทำรายการมูลค่าสูงได้จากเสียงหรือวิดีโอเพียงอย่างเดียว
3. สื่อสารกับพนักงานแบบกำกวมว่าให้ “ใช้วิจารณญาณ” แต่ไม่ให้ checklist หรือ authority ในการหยุดเคส
4. มองว่าเรื่องนี้เป็นปัญหาของทีม security อย่างเดียว ทั้งที่เกี่ยวข้องกับ finance, HR, legal, executive office และ customer operations ด้วย

สรุป

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

ถ้าจะสรุปแบบ practical ที่สุด ผมคิดว่าควรจำไว้ 3 เรื่อง

1. face และ voice biometrics ยังมีประโยชน์ แต่ไม่ควรเป็นสัญญาณเดียว
2. ความเสียหายส่วนใหญ่จะเกิดผ่าน workflow คน ไม่ใช่แค่ model ถูกหลอกอย่างเดียว
3. การป้องกันที่คุ้มที่สุดมักเป็นการผสมกันระหว่าง process, escalation, out-of-band verification และการฝึกคน มากกว่าการหวังพึ่งเครื่องมือตรวจจับตัวเดียว

ในระยะสั้น องค์กรที่ทำได้เร็วที่สุดไม่จำเป็นต้องเป็นองค์กรที่มี AI เก่งที่สุด แต่อาจเป็นองค์กรที่ยอมรับก่อนว่า trust signal แบบเดิมกำลังอ่อนลง แล้วรีบออกแบบ control ให้ทันก่อนความเสียหายจะเกิด

อ่านต่อที่เกี่ยวข้อง

• ถ้าอยากมองอีกมุมว่าเวลาเอา AI เข้า workflow ด้าน security ควรประเมิน governance, risk และ human review อย่างไร อ่าน สิ่งที่ควรคิดก่อนนำ AI มาใช้ในงาน Cybersecurity
• ถ้าอยากทบทวนฐานคิดเรื่องการไม่พึ่งสัญญาณเดียวและการยืนยันตัวตนแบบรอบด้าน อ่าน เปลี่ยนผ่านสู่ยุค Zero Trust: แนวคิดพื้นฐานที่ควรเข้าใจ และตัวอย่างการใช้ในชีวิตจริง

แหล่งอ้างอิง

• NIST: Face Analysis Technology Evaluation (FATE) Part 10: Performance of Passive, Software-based Presentation Attack Detection (PAD) Algorithms, 19 September 2023
• NIST Blog: Facing the Facts to Keep Our Biometrics Secure, 2 October 2024
• NIST CSRC Glossary: Presentation Attack Detection (PAD)
• FTC: Preventing the Harms of AI-enabled Voice Cloning, November 2023
• FTC: Approaches to Address AI-enabled Voice Cloning, April 2024
• FBI / IC3: Senior US Officials Impersonated in Malicious Messaging Campaign, 15 May 2025
• CISA: Avoiding Social Engineering and Phishing Attacks, 1 February 2021