Blog, Insight Hub

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

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

ทุกวันนี้พนักงานจำนวนมากเริ่มใช้ AI เป็นส่วนหนึ่งของการทำงานโดยธรรมชาติ

เขียนอีเมลด้วย Generative AI

นำรายงานให้ AI ช่วยสรุป

อัปโหลด Spreadsheet เพื่อวิเคราะห์

ใช้ AI ช่วยเขียนโปรแกรม

ติดตั้ง Browser Extension ที่มี AI

ให้ AI Meeting Assistant เข้าประชุมและสรุปบทสนทนา

หรือเชื่อม AI Agent เข้ากับ Email, Cloud Drive และระบบงานของบริษัท

หลายกรณีช่วยประหยัดเวลาและเพิ่ม Productivity ได้จริง

แต่มีคำถามสำคัญที่องค์กรต้องตอบให้ได้ว่า

“ฝ่าย IT หรือ Security รู้หรือไม่ว่า AI ตัวไหนกำลังถูกใช้งาน
และข้อมูลอะไรขององค์กรกำลังถูกส่งเข้าไป?”

ถ้าคำตอบคือ “ไม่รู้” นี่คือจุดเริ่มต้นของสิ่งที่เรียกว่า Shadow AI

Microsoft อธิบาย Shadow AI ว่าเป็นการใช้ AI ภายในองค์กรโดยปราศจากการกำกับดูแล
ซึ่งอาจรวมถึง AI Application ที่พนักงานเลือกใช้เอง ตลอดจน Agent และเครื่องมือ AI
ที่อยู่นอกการควบคุมของ IT ขณะที่ IBM ให้นิยามในลักษณะใกล้เคียงกันว่าเป็นการใช้ AI
โดยไม่ได้รับการอนุมัติหรือกำกับอย่างเป็นทางการจากฝ่าย IT

ประเด็นสำคัญจึงไม่ใช่ว่า

“พนักงานใช้ AI = ผิด”

แต่คือ

“องค์กรไม่สามารถบริหารความเสี่ยงของ AI ที่องค์กรไม่รู้ว่ามีอยู่ได้”

Shadow AI คืออะไร?

Shadow AI คือการใช้ ติดตั้ง เชื่อมต่อ หรือพัฒนาระบบ Artificial Intelligence
ภายในบริบทการทำงาน โดยอยู่นอกกระบวนการอนุมัติ การตรวจสอบ
หรือการกำกับดูแลที่องค์กรกำหนด

ตัวอย่างง่าย ๆ เช่น บริษัทอนุญาตให้ใช้ Enterprise AI Platform ตัวหนึ่ง
แต่พนักงานเลือกใช้ AI Application อื่นผ่านบัญชีส่วนตัว เพราะใช้ง่ายกว่า

จากมุมของพนักงาน สิ่งที่เกิดขึ้นอาจดูเหมือนแค่

Copy → Paste → Ask AI → Get Answer

แต่จากมุม Cybersecurity ข้อมูลอาจเดินทางเป็น

Corporate Data → User Device → Third-party AI Service → External
Infrastructure → Processing/Logging/Retention

และหากองค์กรไม่รู้ว่าเกิดกระบวนการนี้ขึ้น ก็อาจไม่สามารถตอบได้ว่า

ข้อมูลอะไรถูกส่งออกไป? ใครเป็นผู้ส่ง? ส่งให้ Provider ใด? Provider
เก็บข้อมูลนานเท่าไร? ข้อมูลถูกนำไปใช้ในลักษณะใด? และสามารถ Audit ย้อนหลังได้หรือไม่?

Microsoft ระบุความเสี่ยงหลักของ Shadow AI ไว้ทั้ง Data Leakage, Compliance
Violations, Security Vulnerabilities และ Lack of
Auditability/Governance

Shadow AI ต่างจาก Shadow IT อย่างไร?

Shadow AI มีรากฐานคล้ายกับ Shadow IT

Shadow IT คือการที่พนักงานใช้ Hardware, Software, SaaS หรือ Cloud Service
ที่องค์กรไม่ได้อนุมัติ

ตัวอย่างเช่นนำไฟล์บริษัทไปเก็บใน Cloud Drive ส่วนตัว หรือใช้ Application
ส่วนตัวจัดการข้อมูลบริษัท

แต่ Shadow AI เพิ่มความซับซ้อนขึ้นอีกขั้น เพราะ AI ไม่ได้ทำหน้าที่เพียง “เก็บข้อมูล”

มันสามารถ

อ่าน → วิเคราะห์ → สรุป → Transform → Generate → เชื่อมต่อระบบ → และในกรณี AI
Agent อาจดำเนินการบางอย่างต่อได้

Microsoft แยกประเด็น Shadow AI จาก Shadow IT โดยชี้ว่าเครื่องมือ AI
ที่ไม่มีการกำกับสามารถเพิ่มความเสี่ยงจากกิจกรรมของ AI
ที่ทำงานด้วยตนเองและการดำเนินการที่ไม่ได้ตั้งใจได้

ดังนั้น เมื่อองค์กรเข้าสู่ยุค Agentic AI ความเสี่ยงจึงไม่ได้มีเพียง

“AI เห็นข้อมูลอะไร?”

แต่เพิ่มเป็น

“AI สามารถทำอะไรกับข้อมูลและระบบของเราได้บ้าง?”

ตัวอย่าง Shadow AI ที่อาจกำลังเกิดขึ้นในองค์กร

ลองนึกภาพเหตุการณ์เหล่านี้

ฝ่าย HR นำ Resume ผู้สมัคร 100 คนอัปโหลดเข้า AI เพื่อให้ช่วยคัดเลือก

ฝ่าย Finance นำ Excel งบประมาณหรือ Cash Flow ไปให้ AI วิเคราะห์

ฝ่าย Sales นำรายชื่อลูกค้าและประวัติการซื้อให้ AI ช่วยสร้างข้อเสนอ

ฝ่าย Legal นำสัญญาที่ยังไม่เปิดเผยให้ AI ช่วยตรวจ

Programmer นำ Source Code ภายในไปให้ Coding Assistant ช่วย Debug

แพทย์หรือบุคลากรนำข้อมูลผู้ป่วยไปถาม Consumer AI เพื่อช่วยสรุป

พนักงานติดตั้ง AI Browser Extension แล้วอนุญาตให้ Extension อ่านเนื้อหาในหน้าเว็บ

อีกคนเชื่อม AI Agent เข้ากับ Email, Calendar หรือ Cloud Drive
เพื่อให้ช่วยทำงานอัตโนมัติ

แต่ฝ่าย IT ไม่ทราบว่ามีการเชื่อมต่อเหล่านั้นอยู่

เครื่องมือเหล่านี้อาจมีประโยชน์และไม่ได้เป็นอันตรายโดยตัวมันเอง

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

1. Data Leakage — ความเสี่ยงแรกคือข้อมูลรั่วไหล

นี่เป็นหนึ่งในความเสี่ยงที่ชัดเจนที่สุดของ Shadow AI

สมมติพนักงานต้องการให้ AI ช่วยสรุปรายงาน จึง Copy ข้อมูลลูกค้าแล้ว Paste ลงไป

หรือ Upload ไฟล์ Excel เพื่อให้ AI วิเคราะห์

ภายในไฟล์นั้นอาจมี

ชื่อ-นามสกุล ** เบอร์โทรศัพท์** ** อีเมล** ** ข้อมูลลูกค้า** ** ข้อมูลพนักงาน** **
ข้อมูลทางการเงิน** ** ข้อมูลสุขภาพ** ** ข้อมูลสัญญา** ** Source Code** ** API
Key** ** ข้อมูลโครงการ** ** Trade Secret**

สิ่งที่พนักงานมองว่าเป็น “การให้ AI ช่วยทำงาน”

ในมุม Data Governance อาจกลายเป็น การส่งข้อมูลออกไปประมวลผลกับ Third Party

Cloudflare ระบุว่า Shadow AI สามารถทำให้องค์กรเผชิญความเสี่ยงจากการเปิดเผย
Sensitive Data และ Intellectual Property ผ่านเครื่องมือหรือ LLM Endpoint
ที่ไม่ได้รับอนุญาต

2. Privacy และ Compliance — AI อาจทำให้ข้อมูลออกนอกขอบเขตที่องค์กรควบคุม

หากข้อมูลที่ถูกส่งเข้า AI มี Personal Data
หรือข้อมูลที่อยู่ภายใต้ข้อกำหนดเฉพาะขององค์กร การใช้ AI อาจทำให้เกิดคำถามด้าน Privacy
และ Compliance ตามมา

เช่น

ข้อมูลถูกส่งไปประมวลผลที่ประเทศใด?

ใครเป็น Data Processor?

มี Data Processing Agreement หรือไม่?

Retention Policy คืออะไร?

ข้อมูลถูกนำไปใช้เพื่อปรับปรุงหรือ Train Model หรือไม่?

สามารถลบข้อมูลตามคำขอได้หรือไม่?

ใครสามารถเข้าถึง Prompt และ Output?

มี Audit Log หรือไม่?

ดังนั้นก่อนใช้ AI กับข้อมูลสำคัญ องค์กรต้องดู Terms, Privacy Policy, Enterprise
Agreement และ Technical Controls ของบริการนั้นจริง ๆ ไม่ควรเหมารวมว่า AI
ทุกบริการมีนโยบายด้านข้อมูลเหมือนกัน

NIST Generative AI Profile แนะนำให้องค์กรบริหารความเสี่ยงของ Generative AI
ให้สอดคล้องกับวัตถุประสงค์องค์กร กฎหมาย ข้อกำหนด และ Risk Tolerance
ตลอดวงจรชีวิตของ AI

3. Intellectual Property — Source Code และความลับทางธุรกิจก็เป็นข้อมูล

Shadow AI ไม่ได้เกี่ยวข้องเฉพาะข้อมูลส่วนบุคคล

อีกกลุ่มหนึ่งที่สำคัญคือ Intellectual Property

ลองคิดถึง Programmer ที่พบ Bug ในระบบของบริษัท

แทนที่จะส่ง Code Snippet ที่ตัดข้อมูลสำคัญออกแล้ว เขาอาจ Copy Source Code
หลายร้อยบรรทัดเข้า AI Coding Assistant

ภายในนั้นอาจมี

Business Logic ** Database Schema** ** Internal URL** **
Infrastructure Configuration** ** Credential** ** API Endpoint** **
Algorithm** ** Security Control**

ในเดือนกันยายน 2026 Reuters
รายงานว่าบริษัทเทคโนโลยีบางแห่งกำลังเพิ่มข้อจำกัดต่อการใช้โมเดล AI
บางประเภทกับงานที่มีข้อมูลอ่อนไหวหรือทรัพย์สินทางปัญญา สะท้อนว่าความกังวลเรื่อง Data
Security และ Proprietary Information
เป็นประเด็นที่องค์กรขนาดใหญ่กำลังบริหารอย่างจริงจัง

4. Hallucination — ข้อมูลไม่รั่ว แต่ AI อาจตอบผิด

Shadow AI ยังมีอีกด้านหนึ่งที่มักถูกมองข้าม

ถ้าข้อมูลไม่รั่ว ก็ไม่ได้หมายความว่าปลอดภัยแล้ว

Generative AI สามารถสร้างคำตอบที่ฟังดูสมเหตุสมผล แต่ไม่ถูกต้องหรือไม่มีหลักฐานรองรับ

หากพนักงานใช้ AI ช่วยเขียน Social Media Post แล้วข้อมูลผิด ผลกระทบอาจอยู่ในระดับหนึ่ง

แต่ถ้าใช้ AI เพื่อช่วย

วิเคราะห์สัญญา ** ประเมิน Cybersecurity** ** คำนวณข้อมูลทางการเงิน** **
ตีความข้อกฎหมาย** ** ประเมินข้อมูลสุขภาพ** ** ตัดสินใจเกี่ยวกับลูกค้า**

ผลกระทบจากคำตอบผิดอาจสูงขึ้นอย่างมาก

ดังนั้นองค์กรต้องกำหนดว่า Use Case ใดสามารถใช้ AI เป็น Drafting Assistant และ
Use Case ใดจำเป็นต้องมี Human Review หรือผู้เชี่ยวชาญตรวจสอบก่อนนำไปใช้

5. Shadow AI Agent อาจอันตรายกว่า Shadow AI Chatbot

ความเสี่ยงกำลังเพิ่มขึ้นเมื่อ AI เปลี่ยนจาก Chatbot ไปสู่ AI Agent

Chatbot แบบทั่วไปอาจทำงานประมาณ

Prompt → Answer

แต่ Agent สามารถเป็น

Prompt → Reason/Plan → Call Tool → Access Data → Execute Action →
Observe → Continue

ถ้า Agent ถูกเชื่อมกับ

Email ** Google Drive** ** Microsoft 365** ** CRM** ** ERP** **
Database** ** GitHub** ** Cloud Infrastructure**

ความเสียหายที่เป็นไปได้ก็เพิ่มขึ้นตามสิทธิ์ที่ Agent ได้รับ

OWASP เรียกความเสี่ยงประเภทหนึ่งว่า Excessive Agency ซึ่งเกิดเมื่อ LLM-based
System ได้รับ Functionality, Permission หรือ Autonomy มากเกินความจำเป็น
และอาจนำไปสู่ผลกระทบต่อ Confidentiality, Integrity และ Availability ได้

หลักการเดียวกับ Cybersecurity จึงควรนำมาใช้กับ Agent:

Least Privilege

AI ควรได้รับสิทธิ์ เท่าที่จำเป็นต่อหน้าที่ ไม่ใช่ให้สิทธิ์ทั้งหมดเพราะสะดวกต่อการ
Integration

6. Browser Extension และ Desktop AI คือ Blind Spot ใหม่

Shadow AI ไม่ได้เกิดเฉพาะตอนพนักงานเปิดเว็บไซต์ AI

AI กำลังเข้าไปอยู่ใน

Browser Extension ** Desktop Application** ** IDE** ** Meeting
Software** ** Email Client** ** Office Application** ** Mobile
Application**

บางเครื่องมือสามารถอ่านหน้าเว็บที่ผู้ใช้กำลังเปิดอยู่ หรือได้รับ Permission เข้าถึงข้อมูลใน
Application อื่น

Microsoft ระบุว่าเครื่องมือ Shadow AI ปัจจุบันอาจรวมถึง Consumer-facing AI
Applications และ Standalone Agents ที่ทำงานบนอุปกรณ์ของผู้ใช้ ซึ่งสามารถสร้าง
Blind Spot ต่อ Security และ Compliance ขององค์กรได้

ดังนั้นการ Block รายชื่อเว็บไซต์ AI อย่างเดียวอาจไม่เพียงพออีกต่อไป

7. “AI ที่อนุมัติแล้ว” ก็ยังทำข้อมูลรั่วได้

นี่เป็นประเด็นที่สำคัญมาก

สมมติองค์กรอนุมัติ AI Platform อย่างเป็นทางการแล้ว

ไม่ได้หมายความว่าพนักงานสามารถนำ ข้อมูลทุกประเภท เข้าไปใช้ได้

Microsoft แนะนำแยกการควบคุมออกเป็นขั้น เช่น

Discover AI Apps → Block Unsanctioned AI → Protect Sensitive Data →
Govern AI Usage

และระบุว่าแม้เป็น AI Application ที่องค์กรอนุญาตแล้ว ก็ยังควรมีมาตรการป้องกันไม่ให้
Sensitive Information ถูก Paste, Upload หรือส่งไปยัง Application
อย่างไม่เหมาะสม

นี่ทำให้เกิดหลักคิดสำคัญว่า

Approved AI ≠ Approved Data

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

แล้วทำไมพนักงานถึงใช้ Shadow AI?

การแก้ Shadow AI ด้วยการตำหนิพนักงานอย่างเดียวมักไม่แก้ต้นเหตุ

ในหลายกรณี พนักงานไม่ได้มีเจตนาขโมยข้อมูล

เขาเพียงต้องการ

ทำงานเร็วขึ้น ** ลดงานซ้ำ** ** สรุปเอกสารเร็วขึ้น** ** เขียนงานดีขึ้น** **
วิเคราะห์ข้อมูลเร็วขึ้น** ** แก้ปัญหาให้ลูกค้าได้ทันเวลา**

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

ดังนั้น Shadow AI อาจเป็นทั้ง Security Risk และ สัญญาณของ Unmet Business
Demand

ฝ่าย IT จึงไม่ควรถามเพียง

“จะ Block AI อย่างไร?”

แต่ควรถามด้วยว่า

“พนักงานกำลังพยายามแก้ปัญหาอะไรด้วย AI?”

การ Block AI ทั้งหมดอาจไม่ใช่คำตอบระยะยาว

องค์กรบางแห่งอาจเลือกวิธีง่ายที่สุดคือ

Block ChatGPT ** Block Gemini** ** Block Claude** ** Block AI
Websites ทั้งหมด**

วิธีนี้อาจเหมาะกับบางระบบหรือบางกลุ่มผู้ใช้ที่มีความเสี่ยงสูง แต่ในระดับองค์กรทั้งหมด การ
Block อย่างเดียวอาจผลักการใช้งานออกไปยังช่องทางที่ตรวจสอบยากขึ้น เช่น Mobile
Device, Personal Internet หรือ AI Application อื่น

แนวทางที่มีโครงสร้างมากกว่าคือ

Discover → Assess → Classify → Approve → Control → Monitor → Educate

Microsoft เองวาง Discovery เป็นขั้นแรกของแนวทางป้องกัน Data Leakage จาก
Shadow AI เพื่อให้องค์กรทราบก่อนว่า AI Application ใดกำลังถูกใช้ ใครใช้
และมีการส่ง Sensitive Data หรือไม่

องค์กรจะค้นหา Shadow AI ได้อย่างไร?

AI Inventory

สิ่งแรกคือสร้าง AI Inventory

องค์กรควรพยายามตอบให้ได้ว่า

AI อะไรถูกใช้อยู่? ** ใครเป็นผู้ใช้?** ** ใช้ผ่าน Web, App, API หรือ
Extension?** ** ใช้ข้อมูลประเภทใด?** ** เชื่อมต่อระบบอะไร?** ** มี Permission
ระดับไหน?** ** ได้รับอนุมัติหรือยัง?**

แหล่งข้อมูลสำหรับค้นหา Shadow AI

ข้อมูลสามารถมาจากหลายระบบ เช่น

Secure Web Gateway / Firewall Logs ** DNS Logs** ** CASB** **
SASE/SSE** ** Endpoint/EDR** ** Browser Management** ** Cloud
Application Discovery** ** Identity/SSO Logs** ** DLP** ** API
Monitoring**

ตัวอย่างเช่น Microsoft Entra Global Secure Access มีความสามารถตรวจจับ Traffic
ไปยัง Generative AI Application, AI Model Provider Framework และ SaaS MCP
Server เพื่อช่วยค้นหา AI ที่ไม่ได้รับอนุมัติในองค์กร

อย่าดูแค่ว่า “ใครเข้า ChatGPT”

การตรวจ Shadow AI ที่ดีควรลึกกว่าการนับจำนวนครั้งที่เข้าเว็บไซต์

องค์กรควรพยายามสร้างภาพประมาณนี้

User → Device → AI Application → Data Classification → Action →
Destination → Risk

ตัวอย่าง:

Finance User → Corporate Laptop → External AI → Confidential Financial
File → Upload → External Processing → High Risk

กับ

Marketing User → Corporate Laptop → Approved Enterprise AI → Public
Marketing Copy → Prompt → Approved Tenant → Low Risk

แม้ทั้งสองคนกำลัง “ใช้ AI” เหมือนกัน แต่ Risk Profile แตกต่างกันอย่างมาก

นโยบาย AI ควรแบ่งข้อมูลเป็นระดับ

Data Classification

องค์กรสามารถกำหนด Data Classification เช่น

Public — ข้อมูลที่เผยแพร่ต่อสาธารณะแล้ว

Internal — ข้อมูลภายในทั่วไป

Confidential — ข้อมูลลูกค้า สัญญา การเงิน Source Code หรือข้อมูลธุรกิจสำคัญ

Restricted / Highly Sensitive — Credential, Secret, ข้อมูลสุขภาพ
ข้อมูลส่วนบุคคลที่มีความอ่อนไหว หรือข้อมูล Critical System

AI Usage Matrix

จากนั้นกำหนด AI Usage Matrix

เช่น

Public Data → Approved AI ใช้ได้

Internal Data → ใช้เฉพาะ Enterprise AI ที่ผ่านการประเมิน

Confidential Data → ต้องมี Control และ Use Case Approval

Restricted Data → ห้ามส่งเข้า External AI เว้นแต่มี Architecture และ
Governance ที่ได้รับอนุมัติโดยเฉพาะ

กฎจริงต้องปรับตามบริบท กฎหมาย สัญญา และ Risk Appetite ของแต่ละองค์กร ไม่ควรใช้
Classification ตัวอย่างนี้แทนการประเมินจริง

Technical Control สำหรับ Shadow AI

Defense in Depth

การควบคุมควรเป็นแบบ Defense in Depth

Network Layer

ที่ Network Layer สามารถใช้ Firewall, Secure Web Gateway, DNS Filtering
หรือ SASE/SSE เพื่อควบคุม AI Service ตามนโยบาย

Cloud Layer

ที่ Cloud Layer สามารถใช้ CASB เพื่อค้นหาและจัดประเภท Cloud/AI Application

Data Layer

ที่ Data Layer ใช้ DLP และ Sensitivity Labels เพื่อป้องกัน Sensitive Data
ถูก Copy, Paste หรือ Upload ไปยังบริการที่ไม่เหมาะสม

Endpoint Layer

ที่ Endpoint Layer ใช้ EDR, Application Control และ Browser Management
เพื่อควบคุม Desktop AI และ Extension

Identity Layer

ที่ Identity Layer ใช้ SSO, MFA, Conditional Access และ Least Privilege

AI Agent Control

และสำหรับ AI Agent ต้องเพิ่ม

Agent Security Controls

Tool Allowlist + Permission Boundary + Human Approval + Logging + Kill
Switch

Monitoring & Verification

Microsoft ระบุในแนวทาง Security Operations ว่า Shadow AI และ Unsanctioned
MCP Server สามารถถูกตรวจสอบและควบคุมผ่าน Network Visibility และ Web
Filtering ตาม Risk Scenario ได้

โรงพยาบาลต้องระวัง Shadow AI เป็นพิเศษ

ลองนึกภาพบุคลากรทางการแพทย์ Copy ข้อมูลจากเวชระเบียน เช่น

ชื่อผู้ป่วย ** อาการ** ** ผล Lab** ** ประวัติการรักษา** ** รายการยา** **
ภาพทางการแพทย์**

แล้วนำไปถาม Consumer AI เพื่อช่วยสรุปเคส

เจตนาอาจเป็นเพียงต้องการทำงานให้เร็วขึ้น

แต่ข้อมูลดังกล่าวอาจเกี่ยวข้องกับข้อมูลสุขภาพและข้อมูลส่วนบุคคลที่ต้องมีการควบคุมสูง

สำหรับโรงพยาบาล Shadow AI จึงไม่ใช่เพียง IT Issue

แต่เกี่ยวข้องกับ

Clinical Governance + Privacy + Cybersecurity + Data Governance + AI
Governance

องค์กรจึงควรมี Approved Clinical AI Environment ที่กำหนด Use Case, Data
Boundary, Access Control, Audit Trail และ Human Oversight อย่างชัดเจน
แทนที่จะปล่อยให้บุคลากรแต่ละคนเลือกเครื่องมือเอง

Shadow AI Governance Framework สำหรับองค์กร

องค์กรสามารถเริ่มจาก Framework ง่าย ๆ 7 ขั้นตอน:

Discover — ค้นหาว่ามี AI อะไรใช้งานอยู่จริง
Inventory — ทำทะเบียน AI Application, Model, Agent และ
Integration
Classify — แบ่งระดับข้อมูลและระดับความเสี่ยงของ Use Case
Approve — สร้าง Approved AI List และกระบวนการอนุมัติ
Protect — ใช้ DLP, CASB, SWG, EDR และ Identity Control
Monitor — ตรวจ Prompt/Data Movement/Agent Activity
เท่าที่เหมาะสมและชอบด้วยกฎหมาย
Educate — ทำ AI Awareness และ Secure AI Usage Training

แนวทางนี้สอดคล้องกับหลัก Risk Management ของ NIST ที่เน้นการจัดการความเสี่ยง AI
ผ่านฟังก์ชัน Govern, Map, Measure และ Manage

Checklist สำหรับผู้บริหาร CIO / CISO

ลองถามองค์กร 10 ข้อนี้

1. เรารู้หรือไม่ว่าพนักงานใช้ AI อะไรบ้าง?

2. มี Approved AI List หรือไม่?

3. มี AI Acceptable Use Policy หรือยัง?

4. ข้อมูลประเภทใดห้ามส่งเข้า AI?

5. สามารถตรวจพบการ Upload Sensitive Data ไปยัง AI ได้หรือไม่?

6. Browser Extension และ Desktop AI ถูกควบคุมหรือไม่?

7. AI Agent เชื่อมต่อกับระบบอะไรบ้าง?

8. Agent ได้รับ Permission เกินความจำเป็นหรือไม่?

9. สามารถ Audit ย้อนหลังได้หรือไม่ว่า AI ทำอะไรกับข้อมูล?

10. หากพบ AI Agent ทำงานผิดปกติ สามารถหยุดหรือเพิกถอนสิทธิ์ได้ทันทีหรือไม่?

ถ้าองค์กรตอบคำถามเหล่านี้ไม่ได้หลายข้อ ปัญหาอาจไม่ใช่เพียงว่า “มี Shadow AI หรือไม่”

แต่อาจเป็นว่า

“เรายังมองไม่เห็น Shadow AI ที่มีอยู่แล้ว”

เป้าหมายไม่ใช่ “ห้าม AI” แต่คือ “ทำให้ AI ที่ดีออกมาจากเงา”

Shadow AI สะท้อนความขัดแย้งที่องค์กรจำนวนมากกำลังเผชิญ

ฝ่ายธุรกิจต้องการ Speed

พนักงานต้องการ Productivity

ฝ่าย IT ต้องการ Control

ฝ่าย Security ต้องการ Protection

ฝ่าย Privacy และ Legal ต้องการ Compliance

หากองค์กรเลือกเพียงการ Block ทุกอย่าง ธุรกิจอาจเสียโอกาสจาก AI

แต่หากเปิดทุกอย่างโดยไม่มี Governance ก็อาจสร้างความเสี่ยงที่มองไม่เห็น

เป้าหมายจึงควรเป็นการเปลี่ยนจาก

Shadow AI → Governed AI

และจาก

“Don’t use AI”

ไปสู่

“Use AI — but use the right AI, with the right data, under the
right controls.”

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

AI กำลังกลายเป็นเครื่องมือพื้นฐานในการทำงานเร็วกว่าที่หลายองค์กรสามารถออก Policy และ
Control ตามทัน

พนักงานอาจเริ่มใช้ AI ก่อนที่บริษัทจะมี AI Strategy

Developer อาจเชื่อม API ก่อนมี AI Governance

และ AI Agent อาจเข้าถึงข้อมูลก่อน Security Team จะรู้ว่ามันถูกติดตั้ง

ดังนั้นโจทย์ขององค์กรในยุค AI ไม่ใช่เพียง

“เราจะนำ AI มาใช้อย่างไร?”

แต่ต้องถามเพิ่มว่า

“วันนี้มี AI อะไรทำงานอยู่ในองค์กรของเราแล้ว โดยที่เราไม่รู้?”

Shadow AI จึงไม่ใช่เหตุผลที่องค์กรควรหยุดใช้ AI

ตรงกันข้าม มันคือเหตุผลที่องค์กรต้องเร่งสร้าง AI Governance, Data Governance และ
AI Security ให้ทันกับพฤติกรรมการใช้งานจริง

เพราะเราไม่สามารถปกป้องสิ่งที่เรามองไม่เห็น

You can’t govern AI you can’t see.

เกี่ยวกับผู้เขียน

อาจารย์ปรเมศร์ เพียรสกุล ผู้เชี่ยวชาญด้านความมั่นคงปลอดภัยไซเบอร์ (Cybersecurity) ปัญญาประดิษฐ์ (Artificial Intelligence: AI) และการวิเคราะห์ข้อมูลเชิงกลยุทธ์ ปัจจุบันดำรงตำแหน่งประธานเจ้าหน้าที่บริหาร (Chief Executive Officer: CEO) และผู้ก่อตั้ง บริษัท อินเทลลิเจนท์ ดาต้า อนาไลติก จำกัด โดยมุ่งพัฒนาและประยุกต์ใช้เทคโนโลยี เพื่อเปลี่ยนข้อมูลให้เป็นข่าวกรองที่เชื่อถือได้สำหรับการตัดสินใจของผู้บริหารและองค์กรอย่างมีประสิทธิภาพและยั่งยืน