AI Safety สำหรับองค์กร: ใช้ AI ให้เกิดประโยชน์ โดยไม่ฝากความเสี่ยงไว้กับคำว่า "ฉลาด"

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

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

สัญญาณเตือนไม่ได้มาจากภายนอกองค์กรเท่านั้น ในเดือนสิงหาคม 2026 CEO ของบริษัท AI ชั้นนำหลายรายออกมาพูดสอดคล้องกันว่า "เราควรชะลอการพัฒนา AI ลง" คนที่สร้าง AI ที่ทันสุดในโลกกำลังบอกว่ามันทันสมัยเกินกว่าที่เราจะควบคุมได้ นี่คือเหตุผลที่ AI Safety ไม่ใช่แค่เรื่องของนักวิจัย แต่เป็นเรื่องที่ทุกองค์กรที่ใช้ AI ต้องให้ความสำคัญ

1. AI Safety ไม่ใช่แค่การป้องกันแฮกเกอร์

ในบริบทองค์กร ควรมอง AI Safety เป็นการลดโอกาสและผลกระทบที่ AI จะสร้างความเสียหาย ทั้งจากการทำงานผิดพลาด การใช้งานผิดบริบท และการถูกนำไปใช้ในทางที่ไม่เหมาะสม ส่วน AI Security เน้นการป้องกันการโจมตีและการเข้าถึงโดยไม่ได้รับอนุญาต ทั้งสองเรื่องต้องทำงานร่วมกับการคุ้มครองข้อมูล ความเป็นธรรม และความรับผิดชอบ ไม่ใช่แยกทำเฉพาะด้านเทคนิค แนวคิดนี้สอดคล้องกับ NIST AI Risk Management Framework ซึ่งมองความเสี่ยงและความน่าเชื่อถือของ AI ตลอดวงจรชีวิตของระบบ

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

2. ความเสี่ยงที่เกิดขึ้นจริงแล้วในองค์กร

ไม่ใช่เรื่องอนาคตไกล แต่เกิดขึ้นแล้ว:

• Deepfake Fraud - มีบริษัทในฮ่องกงเสียเงินไป 200 ล้านบาท เพราะพนักงานถูกหลอกให้โอนเงินด้วยวิดีโอประชุมที่ "ผู้บริหาร" เป็น Deepfake ทั้งหมด
• Scam ด้วย AI เสียง - อาชญากรใช้ AI โคลนเสียงลูกสาวหรือหลาน โทรมาหลอกขอเงินจากผู้สูงอายุ โดยเสียงเหมือนมากจนแยกไม่ออก
• AI เปิดเผยข้อมูลที่ไม่ควรเปิดเผย - พนักงานวางข้อมูลลับของบริษัทลงใน AI Chatbot สาธารณะ แล้วข้อมูลนั้นหลุดออกไปโดยไม่รู้ตัว
• AI Hallucination ในงานจริง - ทนายความใช้ AI ค้นหา Case Law แล้ว AI สร้างคดีที่ไม่มีอยู่จริงขึ้นมา ทำให้ยื่นศาลด้วยข้อมูลปลอม

3. ความเสี่ยงสำคัญที่องค์กรต้องมองให้ครบ

คำตอบดูน่าเชื่อถือ แต่ไม่มีหลักฐานรองรับ

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

ข้อมูลภายในหลุดข้ามสิทธิ์การเข้าถึง

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

AI ถูกหลอกผ่านข้อมูลที่มันอ่าน

Prompt Injection คือการแทรกคำสั่งเพื่อเปลี่ยนพฤติกรรมของ AI โดยคำสั่งอาจซ่อนอยู่ในเว็บไซต์ อีเมล หรือเอกสารที่ดูเหมือนข้อมูลปกติ เช่น เอกสารที่พยายามสั่งให้ AI เปิดเผยข้อมูลอื่นในระบบ ประเด็นสำคัญคือ การใช้ RAG หรือปรับแต่งโมเดลเพิ่มเติมไม่ได้กำจัดความเสี่ยงนี้ทั้งหมด จึงต้องถือว่าเนื้อหาที่ค้นมาเป็น "ข้อมูลสำหรับอ่าน" ไม่ใช่ "ผู้มีอำนาจสั่งการ"

ผลกระทบต่อคนที่คะแนนความแม่นยำเฉลี่ยมองไม่เห็น

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

4. ออกแบบให้ "แม้ AI พลาด ระบบก็ยังจำกัดความเสียหายได้"

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

ตัวอย่างการประยุกต์ใช้คือ Agent สำหรับคืนเงินอาจค้นคำสั่งซื้อและเตรียมรายการได้ แต่ระบบการเงินต้องตรวจสิทธิ์และวงเงินอีกชั้น รายการที่มีผลกระทบสูงต้องได้รับการอนุมัติก่อนดำเนินการ โดยผู้อนุมัติควรเห็นผู้รับ จำนวนเงิน และหลักฐาน ไม่ใช่เห็นเพียงปุ่ม "ยืนยัน" นอกจากนี้ Agent ที่มีหน้าที่อ่านข้อมูลก็ไม่ควรได้รับสิทธิ์แก้ไขหรือลบข้อมูลติดมาด้วย หลักการให้สิทธิ์เท่าที่จำเป็นและการอนุมัติจากมนุษย์เป็นมาตรการสำคัญที่ OWASP แนะนำ

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

5. AI Governance: จากเอกสารนโยบายสู่กระบวนการทำงานจริง

AI Governance ไม่ใช่แค่ "เขียนนโยบายห้ามใช้ AI" แต่คือ กรอบการทำงานที่กำหนดว่าใครใช้ AI ทำอะไรได้ กับข้อมูลแบบไหน และตรวจสอบอย่างไร ครอบคลุม 4 ด้านหลัก:

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

ในระดับกระบวนการ NIST AI RMF จัดการบริหารความเสี่ยงเป็นสี่หน้าที่ ได้แก่ Govern, Map, Measure และ Manage องค์กรสามารถประยุกต์เป็นการกำหนดเจ้าของความเสี่ยง ทำความเข้าใจบริบทและผลกระทบ ทดสอบด้วยหลักฐาน แล้วควบคุมและติดตามหลังใช้งาน ทั้งหมดนี้ต้องดำเนินต่อเนื่อง ไม่ใช่ตรวจครั้งเดียวก่อนเปิดระบบ

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

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

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

6. เชื่อมโยงกับ PDPA อย่างไร

PDPA ของไทยกำหนดให้องค์กรต้องปกป้องข้อมูลส่วนบุคคล การนำ AI มาใช้โดยไม่มีมาตรการกำกับดูแล อาจทำให้องค์กรเสี่ยงต่อ:

• การส่งข้อมูลส่วนบุคคลออกนอกองค์กรโดยไม่ได้รับความยินยอม
• การเก็บรวบรวมข้อมูลเกินจำเป็นโดยไม่รู้ตัว
• การขาดความโปร่งใสในการตัดสินใจที่อิงจาก AI

แนวทาง ETDA สำหรับการกำกับดูแล Generative AI จึงเป็นจุดเริ่มต้นที่เป็นภาษาไทยและออกแบบสำหรับบริบทองค์กรไทยโดยตรง

7. เริ่มจากงานที่จำกัดผลกระทบได้ แล้วค่อยเพิ่มอิสระ

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

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

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

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

มาตรฐานและเอกสารสำคัญที่ควรอ่านต่อ

ทีม Devsign ช่วยออกแบบ AI Governance และความปลอดภัยของ AI ตั้งแต่ทะเบียนระบบ ชุดทดสอบ สิทธิ์การเข้าถึง จนถึงแผนรับมือเมื่อระบบผิดพลาด