ภัยเงียบจาก Shadow AI: เมื่อพนักงานใช้เครื่องมือ AI โดยที่ฝ่าย IT ไม่รู้ตัว

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

ในมุมคนทำงาน นี่เป็นเรื่องเข้าใจได้มาก ไม่มีใครอยากรอ policy หนา ๆ ถ้าเครื่องมือหนึ่งช่วยลดงานซ้ำ ๆ ได้จริง แต่ในมุมองค์กร นี่คือจุดเริ่มของ Shadow AI หรือการใช้เครื่องมือ AI ที่องค์กรไม่ได้อนุมัติ ไม่ได้จัดซื้อ ไม่ได้ผูกกับ identity ขององค์กร และบางครั้งฝ่าย IT ก็ไม่รู้ด้วยซ้ำว่ามีการใช้งานอยู่

สิ่งที่น่ากังวลไม่ใช่แค่ว่า “พนักงานใช้ AI ตัวไหน” แต่คือ “ข้อมูลอะไรถูกส่งออกไป”, “เครื่องมือนั้นเก็บ log หรือใช้ข้อมูลต่ออย่างไร”, “ใครมีสิทธิ์ตรวจสอบ”, “ถ้าเกิดข้อมูลรั่วจะรู้ได้ไหม” และ “ใครเป็นเจ้าของความเสี่ยงนี้”

Shadow AI คืออะไรในทางปฏิบัติ

ถ้าพูดแบบง่าย ๆ Shadow AI คือการใช้ AI tool นอกกรอบที่องค์กรเห็นหรือควบคุมได้ เช่น พนักงานใช้ personal account เพื่อสรุปเอกสารลูกค้า เอา source code ไปถาม chatbot สาธารณะ ใช้ browser extension ช่วยตอบอีเมล ใช้ AI note taker ที่ไม่ได้ผ่าน procurement หรือเชื่อม AI plugin เข้ากับ Google Drive, Slack, Notion, CRM หรือ ticketing system โดยไม่ได้ประเมินความเสี่ยงก่อน

บางกรณีอาจไม่ได้มีเจตนาไม่ดีเลย คนใช้เพราะอยากทำงานให้เร็วขึ้น และหลายครั้งหัวหน้าก็อาจเห็นผลลัพธ์ว่าดีขึ้นด้วยซ้ำ ปัญหาคือ productivity เพิ่มขึ้นก่อนที่ governance จะตามทัน

จากประสบการณ์ ผมคิดว่า Shadow AI มักเกิดจาก 4 สาเหตุหลัก:

1. เครื่องมือที่องค์กรอนุญาตยังไม่ตอบโจทย์งานจริง
2. ขั้นตอนขออนุมัติเครื่องมือใหม่ช้าเกินไป
3. policy เขียนกว้างหรือห้ามทุกอย่างจนคนไม่รู้ว่าอะไรทำได้
4. พนักงานไม่เข้าใจว่าข้อมูลที่ใส่เข้า AI มีผลต่อ privacy และ compliance อย่างไร

ดังนั้นถ้าจะจัดการ Shadow AI ด้วยการบล็อกอย่างเดียว มักได้ผลระยะสั้น แต่ระยะยาวคนอาจย้ายไปใช้เครื่องมือผ่านมือถือ personal hotspot หรือ account ส่วนตัวแทน ซึ่งทำให้ visibility แย่กว่าเดิม

ความเสี่ยงที่แท้จริงคือข้อมูลไหลออกแบบเงียบ ๆ

ในโลก security เรามักคุ้นกับเหตุการณ์ใหญ่ เช่น malware, phishing, ransomware หรือ credential theft แต่ Shadow AI หลายครั้งไม่ได้เกิดเป็น incident ดัง ๆ มันเกิดเป็นการรั่วทีละน้อย เช่น ใส่สัญญาลูกค้าเข้าไปให้ AI สรุป ใส่ incident ticket เพื่อให้ช่วยเขียน timeline ใส่ log ที่มี IP, username หรือ token ปนอยู่ หรือใส่ proposal ที่ยังไม่เปิดเผยให้ช่วย polish ภาษา

ข้อมูลที่ควรระวังไม่ได้มีแค่ password หรือ secret key แต่รวมถึง:

1. ข้อมูลส่วนบุคคลของลูกค้าและพนักงาน
2. เอกสารสัญญา ราคา proposal และข้อมูลทางการเงิน
3. source code, architecture diagram และ vulnerability detail
4. incident log, ticket, meeting transcript และ chat ภายใน
5. ข้อมูลที่อยู่ภายใต้ NDA, regulatory requirement หรือ data residency

OWASP Top 10 for LLM Applications 2025 จัด Sensitive Information Disclosure เป็นหนึ่งในความเสี่ยงสำคัญของระบบ LLM เพราะข้อมูลอ่อนไหวอาจเกี่ยวข้องทั้งกับตัวโมเดลและ application context เช่น PII, financial detail, legal document, credential และข้อมูลธุรกิจที่เป็นความลับ ส่วน CISA, NSA, FBI และพันธมิตรเองก็ออกแนวทาง AI Data Security โดยเน้นว่าความปลอดภัยของข้อมูลมีผลต่อความถูกต้อง ความน่าเชื่อถือ และความปลอดภัยของผลลัพธ์ AI ตลอด lifecycle ตั้งแต่พัฒนา ทดสอบ deploy จนถึงใช้งานจริง

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

Compliance ไม่ได้เริ่มตอน auditor มาถาม

หลายองค์กรจะเริ่มกังวลเรื่อง compliance ก็ตอนมี audit, customer due diligence หรือ incident แล้วต้องตอบคำถามว่า “ข้อมูลลูกค้าถูกส่งไปยัง third party รายใดบ้าง” แต่ในทางปฏิบัติ คำถามนี้ควรถูกตอบได้ตั้งแต่ก่อนใช้งาน

ปัญหาของ Shadow AI คือมันทำให้ third-party risk เกิดขึ้นโดยไม่ผ่าน third-party review เครื่องมือ AI บางตัวอาจมีเงื่อนไขการใช้ข้อมูลที่เหมาะกับงานทั่วไป แต่ไม่เหมาะกับข้อมูลลูกค้า บางตัวอาจเก็บ prompt เพื่อ improve service บางตัวอาจมี plugin หรือ connector ที่ขอสิทธิ์กว้างเกินจำเป็น และบางตัวอาจไม่มี data processing agreement ที่องค์กรต้องใช้

ถ้าเป็นองค์กรที่ต้องอยู่ภายใต้ PDPA, GDPR, HIPAA, PCI DSS, financial regulation หรือข้อกำหนดจากลูกค้า enterprise การใช้ AI แบบไม่เห็นภาพรวมจะกลายเป็นปัญหาเร็วมาก เพราะความเสี่ยงไม่ได้อยู่แค่ตัวข้อมูล แต่รวมถึงความสามารถในการอธิบายว่าองค์กรควบคุมข้อมูลอย่างไรด้วย

ในมุมนี้ Shadow AI จึงไม่ใช่เรื่องของ IT อย่างเดียว แต่เป็นเรื่องร่วมกันของ business owner, legal, privacy, procurement, security และผู้บริหาร

Governance ที่ดีต้องเริ่มจาก workflow จริง ไม่ใช่เอกสารยาว

NIST AI Risk Management Framework อธิบาย AI risk management ในเชิงการออกแบบ พัฒนา ใช้ และประเมินระบบ AI ให้คำนึงถึงความน่าเชื่อถือและผลกระทบต่อคน องค์กร และสังคม ส่วน Generative AI Profile ของ NIST ช่วยขยายมุมความเสี่ยงเฉพาะของ generative AI ให้ชัดขึ้น

แต่ถ้าเอามาใช้กับองค์กรขนาดเล็กหรือทีมที่ยังเริ่มต้น ผมไม่คิดว่าควรเริ่มจากเอกสาร governance หนา ๆ ก่อน สิ่งที่ควรเริ่มคือทำให้คนตอบคำถามพื้นฐานได้:

1. Use case ไหนใช้ AI ได้
2. ข้อมูลประเภทใดห้ามใส่ใน AI ภายนอก
3. เครื่องมือใดได้รับอนุมัติแล้ว
4. ถ้าต้องใช้เครื่องมือใหม่ต้องขออย่างไร
5. งานแบบไหนต้องมี human review
6. ใครเป็น owner ของความเสี่ยงแต่ละ use case

Governance ที่ใช้งานได้จริงควรสั้นพอให้คนจำได้ และเฉพาะเจาะจงพอให้ตัดสินใจได้ เช่น “ห้ามใส่ข้อมูลลูกค้าที่ระบุตัวบุคคลได้ใน AI public account” ชัดกว่า “ใช้ AI อย่างมีความรับผิดชอบ” มาก

อย่าบังคับให้คนเลือกระหว่างปลอดภัยกับทำงานทัน

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

ตัวอย่างเช่น:

1. จัดหา AI tool ที่ผูกกับบัญชีองค์กรและมี admin control
2. ปิด training on customer data หรือใช้ enterprise privacy setting เมื่อมีให้เลือก
3. ทำ data classification แบบเข้าใจง่าย เช่น public, internal, confidential, restricted
4. ทำ prompt guideline ที่บอกตัวอย่างว่าอะไรใส่ได้และอะไรต้อง redact
5. สร้างช่องทางขออนุมัติ AI tool ใหม่ที่เร็วและมี SLA
6. มีตัวอย่าง use case ที่อนุญาต เช่น สรุปเอกสาร public, ช่วยร่างอีเมลทั่วไป, brainstorm outline
7. มีตัวอย่าง use case ที่ต้องห้ามหรือขออนุมัติก่อน เช่น ข้อมูลลูกค้า, source code สำคัญ, incident detail, legal document

จุดสำคัญคือ policy ต้องไม่ทำให้คนรู้สึกว่า “ถ้าถาม IT จะโดนห้าม” เพราะถ้าเป็นแบบนั้น คนจะเลิกถาม แล้ว Shadow AI จะยิ่งเงียบกว่าเดิม

ควบคุม connector และ agent ให้เข้มกว่าการถามตอบทั่วไป

AI ที่ใช้แค่ถามตอบยังมีความเสี่ยงเรื่องข้อมูล แต่ AI ที่ต่อกับ connector, plugin หรือ agent มีความเสี่ยงเพิ่มขึ้นอีกระดับ เพราะมันไม่ได้แค่อ่านข้อมูล แต่มันอาจค้นไฟล์ ส่งอีเมล สร้าง ticket แก้เอกสาร เรียก API หรือ trigger workflow ได้

OWASP ใช้คำว่า Excessive Agency สำหรับความเสี่ยงที่ระบบ LLM มี functionality, permission หรือ autonomy มากเกินจำเป็น ถ้าเอามาแปลในบริบทองค์กร คืออย่าให้ AI มีสิทธิ์มากกว่า use case ที่มันควรทำ

ตัวอย่างที่ควรระวังคือ AI note taker ที่เข้าถึง calendar และ meeting transcript มากกว่าที่จำเป็น, plugin ที่อ่านไฟล์ได้ทั้ง drive แทนที่จะอ่านเฉพาะ folder, agent ที่ใช้ service account สิทธิ์สูง, หรือ chatbot ภายในที่ตอบจาก knowledge base ซึ่งมีเอกสาร confidential ปนอยู่โดยไม่ได้แยก permission ตามผู้ใช้

หลักคิดแบบ practical คือ:

1. แยก use case อ่านข้อมูลกับเขียนข้อมูลออกจากกัน
2. ใช้ least privilege กับ connector ทุกตัว
3. ให้ AI ทำ action สำคัญได้หลังมี human approval เท่านั้น
4. log ทุก action ที่ AI หรือ plugin ทำแทนผู้ใช้
5. review permission เป็นรอบ ๆ ไม่ใช่อนุมัติครั้งเดียวแล้วจบ

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

เริ่มควบคุม Shadow AI อย่างไรแบบไม่เว่อร์เกินไป

ถ้าต้องเริ่มจากศูนย์ ผมจะไม่เริ่มจากการซื้อ platform ใหญ่ทันที แต่จะเริ่มจาก visibility และ guardrail พื้นฐานก่อน

Checklist ที่คุ้มสำหรับ 30-60 วันแรกคือ:

1. สำรวจว่าทีมใช้ AI tool อะไรอยู่จริง โดยทำให้เป็นการเรียนรู้ ไม่ใช่การจับผิด
2. แยกกลุ่มเครื่องมือเป็น approved, allowed with conditions, not allowed
3. เขียน policy สั้น ๆ ว่าข้อมูลอะไรใส่ AI ภายนอกไม่ได้
4. เปิดช่องทางขอ exception หรือขอประเมินเครื่องมือใหม่
5. เลือก AI tool หลักที่องค์กรควบคุม account, log และ privacy setting ได้
6. ทำ training สั้น ๆ ด้วยตัวอย่างจริง เช่น contract, customer data, source code, ticket
7. ตรวจ connector และ browser extension ที่ขอสิทธิ์กว้างผิดปกติ
8. ตั้ง logging หรือ CASB/DLP ตามความเหมาะสมกับขนาดองค์กร
9. กำหนด owner ของแต่ละ high-risk AI use case
10. ทบทวน policy ทุกไตรมาส เพราะเครื่องมือและพฤติกรรมการใช้ AI เปลี่ยนเร็วมาก

สำหรับทีมเล็ก อาจเริ่มแค่ข้อ 1-6 ก็ได้ สิ่งสำคัญคือทำให้คนรู้ว่ามีทางใช้ AI แบบถูกต้อง ไม่ใช่ต้องแอบใช้เอง

สรุป

Shadow AI ไม่ได้เกิดเพราะพนักงานไม่สนใจความปลอดภัยเสมอไป หลายครั้งมันเกิดเพราะองค์กรยังไม่มีทางเลือกที่ดีพอให้คนใช้ AI อย่างปลอดภัยและเร็วพอ งานจริงจึงวิ่งนำหน้า policy

คำตอบจึงไม่ใช่การห้ามทุกอย่าง และไม่ใช่การปล่อยทุกอย่าง แต่คือการยอมรับว่า AI กลายเป็นส่วนหนึ่งของ workflow แล้ว จากนั้นค่อยวางขอบเขตข้อมูล เครื่องมือที่อนุมัติ วิธีขอ exception การตรวจ permission และ human review ให้เหมาะกับความเสี่ยง

ในมุมของผม องค์กรที่จัดการ Shadow AI ได้ดีจะไม่ใช่องค์กรที่มีเอกสาร AI governance ยาวที่สุด แต่เป็นองค์กรที่ทำให้คนตอบได้ง่าย ๆ ว่า “งานนี้ใช้ AI ได้ไหม”, “ข้อมูลนี้ใส่ได้หรือเปล่า”, “ถ้าไม่แน่ใจต้องถามใคร” และ “ถ้าอยากใช้เครื่องมือใหม่ต้องทำอย่างไร”

ถ้าตอบคำถามเหล่านี้ได้ชัด Shadow AI จะค่อย ๆ เปลี่ยนจากภัยเงียบเป็นการใช้ AI ที่มองเห็น ควบคุมได้ และยังไม่ทำลาย productivity ที่คนต้องการตั้งแต่แรก

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

• ถ้าอยากมองความเสี่ยง AI ในภาพกว้างขึ้น อ่าน ความเสี่ยงจากการใช้ AI: ตั้งแต่ Deepfake, Prompt Injection ไปจนถึง Agent ที่มีสิทธิ์เกินจำเป็น
• ถ้าอยากต่อยอดเรื่องการใช้ AI ในงาน security โดยไม่ขายฝัน อ่าน สิ่งที่ควรคิดก่อนนำ AI มาใช้ในงาน Cybersecurity
• ถ้าอยากเข้าใจการลด implicit trust และการจำกัดสิทธิ์ อ่าน เปลี่ยนผ่านสู่ยุค Zero Trust: แนวคิดพื้นฐานที่ควรเข้าใจ และตัวอย่างการใช้ในชีวิตจริง

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

• NIST: Artificial Intelligence Risk Management Framework (AI RMF 1.0)
• NIST: Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile
• CISA: AI Data Security - Best Practices for Securing Data Used to Train & Operate AI Systems
• OWASP Top 10 for LLM Applications 2025
• OWASP LLM02:2025 Sensitive Information Disclosure
• OWASP LLM06:2025 Excessive Agency