Shadow AI Audit คืออะไร? วิธีตรวจจับและจัดการเครื่องมือ AI ที่พนักงานใช้โดยไม่ได้รับอนุญาต

การตรวจสอบ Shadow AI คือกระบวนการตรวจจับ ประเมิน และจัดการเครื่องมือ AI ที่พนักงานใช้งานโดยไม่ได้รับอนุญาตจากองค์กร บทความนี้จะอธิบายขั้นตอนการตรวจสอบภายในและวิธีการสร้างระบบการจัดการสำหรับผู้ดูแลระบบไอทีและผู้รับผิดชอบด้านความปลอดภัยของข้อมูลที่ต้องการทราบสถานะที่แท้จริงของ Shadow AI ซึ่งมีความเสี่ยงต่อการรั่วไหลของข้อมูลและการละเมิดกฎระเบียบ
การตรวจสอบ Shadow AI คือกระบวนการตรวจสอบภายในเพื่อตรวจหาและประเมินเครื่องมือ AI ที่พนักงานนำมาใช้ในการทำงานโดยไม่ได้รับอนุญาตจากองค์กร เพื่อนำมาอยู่ภายใต้การกำกับดูแลตามกฎระเบียบการใช้งาน ในขณะที่การใช้งาน ChatGPT, Gemini และอื่นๆ ผ่านบัญชีส่วนตัวกำลังแพร่หลายมากขึ้น บทความนี้จะอธิบายขั้นตอนตั้งแต่การเตรียมการ การตรวจหา การประเมิน ไปจนถึงการสร้างระบบบริหารจัดการ เพื่อให้เจ้าหน้าที่ไอทีและผู้รับผิดชอบด้านความปลอดภัยของข้อมูลสามารถรับมือกับความเสี่ยงด้านการรั่วไหลของข้อมูลและการละเมิดกฎระเบียบ (Compliance) ได้ โดยจะนำเสนอแนวทางการดำเนินงานที่ทำได้จริงในระดับปฏิบัติการ พร้อมทั้งสอดแทรกมุมมองด้านการคุ้มครองข้อมูล รวมถึง PDPA (พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล) ของประเทศไทยด้วย
Shadow AI คือคำเรียกโดยรวมของเครื่องมือ AI ที่พนักงานนำมาใช้ในการทำงานโดยที่ฝ่ายไอทีและฝ่ายความปลอดภัยไม่ได้รับทราบ ด้วยความสะดวกสบายจึงทำให้เกิดการแพร่กระจายอย่างรวดเร็วในหน้างาน และมักกลายเป็นช่องทางที่ทำให้ข้อมูลลับรั่วไหลออกสู่ภายนอกบริษัทโดยไม่รู้ตัว ก่อนอื่นเรามาทำความเข้าใจกันว่าเหตุใดเรื่องนี้จึงมีความแตกต่างในเชิงคุณภาพจากปัญหาเดิมๆ ที่เคยมีมา
นิยามของ Shadow AI และความแตกต่างจาก Shadow IT แบบเดิม
Shadow IT หมายถึงการใช้ SaaS หรืออุปกรณ์ส่วนตัวโดยไม่ได้รับอนุญาตจากแผนกไอที ส่วน Shadow AI เป็นรูปแบบหนึ่งของ Shadow IT แต่มีจุดที่แตกต่างกันอย่างสิ้นเชิง นั่นคือข้อมูลที่ป้อนเข้าไปจะถูกส่งไปยังฝั่ง AI และอาจถูกนำไปใช้ในการเรียนรู้หรือสร้างคำตอบ ไม่ใช่แค่เพียงเครื่องมือที่อยู่นอกเหนือการควบคุมเท่านั้น แต่ข้อมูลลับหรือข้อมูลส่วนบุคคลที่แปะลงใน Prompt จะรั่วไหลไปยังโมเดลภายนอก และข้อมูลที่ส่งไปแล้วนั้นไม่สามารถเรียกคืนได้
นอกจากนี้ Shadow AI ยังมีความซับซ้อนในด้านต่างๆ ได้แก่ อุปสรรคในการเข้าใช้งานที่ต่ำซึ่งใครก็สามารถใช้งานได้ฟรีในทันที ความเสี่ยงด้านคุณภาพและอาการประสาทหลอนของ AI (Hallucination - ข้อมูลที่ผิดพลาดแต่ดูน่าเชื่อถือ) จากการนำผลลัพธ์ไปใช้ในการตัดสินใจทางธุรกิจโดยตรง และความยากลำบากในการมองเห็นภาพรวม (Visibility) เนื่องจากสามารถทำทุกอย่างให้เสร็จสิ้นได้ผ่านเบราว์เซอร์เพียงอย่างเดียว จึงจำเป็นต้องจัดการในฐานะความเสี่ยงที่มีคุณลักษณะใหม่ ซึ่งไม่สามารถครอบคลุมได้ด้วยกรอบแนวคิดเดิมของ "แอปพลิเคชันที่อยู่นอกเหนือการควบคุม" เพียงอย่างเดียว
เบื้องหลังการเพิ่มขึ้นอย่างรวดเร็วของ Shadow AI ในองค์กร
การเพิ่มขึ้นอย่างรวดเร็วของ Shadow AI มีปัจจัยหลายประการประกอบกัน ได้แก่ ① Generative AI แพร่หลายจนพนักงานคุ้นเคยกับการใช้งานในชีวิตประจำวัน ② AI อย่างเป็นทางการของบริษัทไม่มีความพร้อมหรือใช้งานยาก ทำให้หน้างานต้องหันไปใช้เครื่องมือส่วนตัวเพื่อเอาตัวรอด ③ ไม่มีอุปสรรคในการใช้งานจริง เพราะฟรี ใช้งานได้ทันที และจบได้ในสมาร์ทโฟน ④ มีแรงกดดันที่ต้องการผลลัพธ์ที่รวดเร็ว
กล่าวคือ สภาพความเป็นจริงนั้นใกล้เคียงกับคำว่า "สะดวกจนไม่มีเหตุผลที่จะไม่ใช้" มากกว่าจะเป็นเพียง "การฝ่าฝืนคำสั่งห้าม" ในการสำรวจด้านธรรมาภิบาล AI หลายแห่งระบุซ้ำๆ ว่า ในองค์กรส่วนใหญ่ พนักงานใช้ ChatGPT หรือ Claude ผ่านบัญชีส่วนตัวหรืออุปกรณ์ส่วนตัว โดยที่แผนก IT ไม่สามารถมองเห็นสภาพความเป็นจริงเหล่านั้นได้ หลายบริษัทกำลังยืนอยู่บนจุดเปลี่ยนว่าจะปล่อยทิ้งไว้โดยเชื่อในความสุจริต หรือจะทำให้มองเห็นภาพรวมเพื่อนำมาอยู่ภายใต้การควบคุม
ความเสี่ยงหากปล่อยทิ้งไว้: การละเมิด PDPA, การรั่วไหลของข้อมูล และการล่มสลายของธรรมาภิบาล AI
ความเสี่ยงจากการปล่อยปละละเลย Shadow AI สามารถแบ่งออกได้เป็น 3 ประการหลัก ประการแรกคือการรั่วไหลของข้อมูล หากมีการป้อนข้อมูลส่วนบุคคลของลูกค้า ความลับทางการค้า หรือซอร์สโค้ดเข้าสู่ AI ภายนอก ข้อมูลเหล่านั้นอาจรั่วไหลออกสู่ภายนอกองค์กรได้ ประการที่สองคือการละเมิดกฎหมาย กฎหมายคุ้มครองข้อมูลส่วนบุคคล เช่น PDPA ของประเทศไทย มีข้อจำกัดเกี่ยวกับการเปิดเผยข้อมูลส่วนบุคคลนอกเหนือจากวัตถุประสงค์ที่กำหนดหรือการโอนข้อมูลไปต่างประเทศ หากพนักงานนำข้อมูลส่วนบุคคลไปใช้กับ AI โดยไม่ได้รับอนุญาต อาจนำไปสู่การละเมิดที่ส่งผลให้เกิดบทลงโทษทางปกครอง ค่าปรับ และความเสียหายต่อชื่อเสียงได้ ประการที่สามคือการล่มสลายของธรรมาภิบาล (Governance) หากไม่มีการบันทึกว่า "ใคร เป็นผู้ใช้ AI ตัวใด และป้อนข้อมูลอะไรลงไป" องค์กรจะไม่สามารถดำเนินการตรวจสอบหรือแสดงความรับผิดชอบได้ อีกทั้งยังไม่สามารถควบคุมความเสี่ยงด้านคุณภาพที่อาจเกิดจากข้อผิดพลาดของผลลัพธ์ที่ AI สร้างขึ้นและหลุดรอดเข้าไปในกระบวนการทำงานได้
ความเสี่ยงทั้งหมดนี้ หากเกิดการรั่วไหลหรือการละเมิดขึ้นจริง จะส่งผลให้ต้นทุนในการรับมือพุ่งสูงขึ้นอย่างมาก ปัญหาสำคัญคือสิ่งเหล่านี้กำลังดำเนินไปใน "จุดที่มองไม่เห็น"
ต้องเตรียมตัวอย่างไรก่อนเริ่มการตรวจสอบ? เงื่อนไขเบื้องต้นและการสร้างระบบ
ก่อนที่จะเริ่มมองหาเครื่องมือในทันที ให้กำหนดให้ชัดเจนก่อนว่า "ใคร เป็นผู้มีอำนาจระดับใด และขอบเขตการตรวจสอบครอบคลุมถึงจุดไหน" หากเริ่มดำเนินการตรวจจับโดยที่โครงสร้างและขอบเขตยังไม่ชัดเจน มักจะนำไปสู่การต่อต้านจากหน้างานและการทำงานที่สูญเปล่าได้ง่าย
การจัดตั้งทีมตรวจสอบและการกำหนดอำนาจหน้าที่ให้ชัดเจน
ทีมตรวจสอบไม่ควรประกอบด้วยแผนกเดียว แต่โดยพื้นฐานแล้วควรประกอบด้วยฝ่ายความมั่นคงปลอดภัยสารสนเทศและไอที, ฝ่ายกฎหมายและกำกับดูแล (เช่น มุมมองด้านการคุ้มครองข้อมูลตาม PDPA), ตัวแทนจากแต่ละหน่วยธุรกิจ และผู้สนับสนุนระดับบริหาร (Management Sponsor) ที่เป็นผู้ให้การสนับสนุนด้านอำนาจการตัดสินใจ
ในด้านอำนาจหน้าที่ ควรมีการกำหนดอำนาจอย่างเป็นทางการก่อนเริ่มการตรวจสอบ เช่น การเข้าถึงบันทึกข้อมูล (Log) และการตรวจสอบเครือข่าย, การสัมภาษณ์พนักงาน และการเข้าถึงข้อมูลการสำรวจเครื่องมือต่างๆ ในขณะเดียวกัน การตรวจสอบพนักงานหากทำเกินขอบเขตอาจก่อให้เกิดปัญหาทางกฎหมายด้านแรงงานและความเป็นส่วนตัว จึงจำเป็นต้องใช้ความระมัดระวัง การแบ่งหน้าที่ควรระบุให้ชัดเจนด้วย RACI (Responsible, Accountable, Consulted, Informed) เพื่อไม่ให้เกิดความคลุมเครือว่าใครเป็นผู้ตัดสินใจขั้นสุดท้าย การได้รับอนุมัติจากฝ่ายบริหารไว้ล่วงหน้าจะช่วยเพิ่มอำนาจในการดำเนินการแก้ไขในขั้นตอนต่อไป (เช่น การสั่งห้ามใช้งานหรือการจัดหาทางเลือกอื่น) ได้อย่างมีนัยสำคัญ
การตรวจสอบสถานะนโยบายการใช้ AI และการกำหนดเกณฑ์มาตรฐาน
ก่อนอื่น ให้ตรวจสอบว่ามีนโยบายการใช้งาน AI ในปัจจุบันอยู่หรือไม่ ในความเป็นจริงมีหลายบริษัทที่ยังไม่มีนโยบายเฉพาะสำหรับ AI สำหรับกรอบแนวทางที่สามารถนำมาอ้างอิงในการสร้างมาตรฐานได้นั้น มี NIST AI RMF (กรอบการทำงานแบบสมัครใจจากสหรัฐอเมริกา ซึ่งประกอบด้วย 4 ฟังก์ชัน ได้แก่ Govern, Map, Measure และ Manage) และ ISO/IEC 42001 (มาตรฐานระบบการจัดการ AI ระดับสากลที่สามารถขอการรับรองได้) ทั้งสองอย่างนี้มีหัวข้อการจัดการที่ซ้ำซ้อนกันมาก หลายองค์กรจึงเลือกใช้ NIST AI RMF สำหรับโมเดลการดำเนินงาน และใช้ ISO/IEC 42001 เป็นเป้าหมายสำหรับการรับรองจากภายนอก
ในขั้นตอนนี้ ไม่จำเป็นต้องสร้างนโยบายที่สมบูรณ์แบบ ให้กำหนดเกณฑ์การตัดสินใจเบื้องต้นว่า "อะไรที่อนุญาต อะไรที่อนุญาตโดยมีเงื่อนไข และอะไรที่ห้าม" โดยพิจารณาจากความลับของข้อมูลควบคู่ไปกับคุณลักษณะของเครื่องมือ แล้วจึงนำไปปรับปรุงให้ละเอียดขึ้นในขั้นตอนถัดไปโดยเทียบกับผลการตรวจพบ
การกำหนดขอบเขตการตรวจสอบ: แผนก เครื่องมือ และข้อมูลที่เกี่ยวข้อง
ขอบเขตการตรวจสอบ (Audit Scope) จะถูกกำหนดโดยใช้ 3 แกนหลัก ได้แก่: ① แผนกเป้าหมาย: เนื่องจากภาระงานในการตรวจสอบทั้งบริษัทพร้อมกันนั้นหนักเกินไป จึงควรเริ่มจากแผนกที่จัดการข้อมูลลับ (เช่น ฝ่ายขาย, ฝ่ายพัฒนา, ฝ่ายบุคคล, ฝ่ายบัญชี เป็นต้น) ② เครื่องมือเป้าหมาย: ไม่เพียงแค่ AI แบบแชทเท่านั้น แต่ต้องรวมถึง SaaS ที่มีฟังก์ชัน AI ในตัว, ส่วนขยายของเบราว์เซอร์ (Browser extension) และเครื่องมือช่วยเขียนโค้ดด้วย ③ ข้อมูลเป้าหมาย: ต้องระบุให้ชัดเจนว่าข้อมูลส่วนบุคคล, ความลับทางการค้า และข้อมูลภายใต้การกำกับดูแลอยู่ที่ใดบ้าง
หากกำหนดขอบเขตมากเกินไป การตรวจสอบจะไม่มีวันสิ้นสุด ในรอบแรกจึงควรจำกัดวงไว้ที่พื้นที่ที่มีความเสี่ยงสูง และค่อยๆ ขยายขอบเขตออกไปในขณะที่ดำเนินการจริง นอกจากนี้ ควรมีการกำหนดระยะเวลาของการตรวจสอบและผลลัพธ์ที่คาดหวัง (เช่น ตารางรายการเครื่องมือ, การประเมินความเสี่ยง, แผนการแก้ไข) ไว้ตั้งแต่ต้น การระบุเป้าหมายให้ชัดเจนเป็นลายลักษณ์อักษรจะช่วยหลีกเลี่ยงสถานการณ์ที่ว่า "ทำไปแล้วแต่ไม่ได้ข้อสรุปอะไรเลย"
ขั้นตอนที่ 1: จะทราบสถานะการใช้งานเครื่องมือ AI ในองค์กรได้อย่างไร?
การตรวจจับโดยพื้นฐานแล้วต้องใช้การผสมผสานระหว่าง "บันทึกข้อมูล (Log) ของเครือข่ายและอุปกรณ์ปลายทาง" กับ "การสอบถามจากบุคคล" เนื่องจากหากพึ่งพาเพียงการตรวจจับทางเทคนิคอาจทำให้พลาดการตรวจสอบผ่านอุปกรณ์ส่วนตัว และหากพึ่งพาเพียงการสอบถามก็มักจะนำไปสู่การรายงานข้อมูลที่ต่ำกว่าความเป็นจริงได้
การวิเคราะห์ทราฟฟิกเครือข่ายและการใช้ Proxy Log
พื้นฐานของการตรวจจับทางเทคนิคคือการรวบรวมข้อมูลการเข้าถึงโดเมนของบริการ AI ที่รู้จักจากบันทึก (log) ของพร็อกซี, ไฟร์วอลล์ และ SWG (Secure Web Gateway) หากมีการนำ CASB หรือ SASE มาใช้งาน ก็จะสามารถมองเห็นการใช้งาน SaaS ได้ในวงกว้างยิ่งขึ้น นอกจากนี้ บันทึก DNS และการตรวจจับแอปพลิเคชันบนอุปกรณ์ปลายทาง (endpoint) ยังช่วยเสริมข้อมูลได้อีกด้วย
อย่างไรก็ตาม วิธีนี้มีข้อจำกัด อุปกรณ์ส่วนตัว เครือข่ายมือถือ และการใช้งานจากที่บ้านจะไม่สามารถตรวจจับได้เนื่องจากไม่ได้ผ่านเครือข่ายของบริษัท นอกจากนี้ การทำ SSL Inspection เพื่อดูเนื้อหาของการสื่อสารที่เข้ารหัส จำเป็นต้องคำนึงถึงความเป็นส่วนตัวและมีเหตุผลทางกฎหมายรองรับ ความแม่นยำในการตรวจจับขึ้นอยู่กับว่าสามารถจัดเตรียมและอัปเดตรายการโดเมนของบริการ AI ที่รู้จักได้ดีเพียงใด เนื่องจากมีบริการใหม่ๆ เกิดขึ้นอย่างต่อเนื่อง รายการดังกล่าวจึงไม่สามารถทำเพียงครั้งเดียวแล้วจบได้
การรวบรวมข้อมูลการใช้งานจริงผ่านแบบสอบถามและการสัมภาษณ์พนักงาน
การใช้แบบสอบถามและการสัมภาษณ์คือวิธีปิดจุดบอดของการตรวจจับทางเทคนิค สิ่งที่สำคัญที่สุดในขั้นตอนนี้คือการระบุให้ชัดเจนตั้งแต่ต้นว่า "จุดประสงค์ไม่ใช่เพื่อการลงโทษ แต่เป็นการสำรวจเพื่อทำความเข้าใจสถานการณ์จริงและปรับปรุงสภาพแวดล้อมการทำงาน" หากผู้ปฏิบัติงานสัมผัสได้ถึงท่าทีในการตำหนิ ข้อมูลที่ได้รับจะกลายเป็นการรายงานที่ต่ำกว่าความเป็นจริงทันที
ให้รวบรวมข้อมูลว่า "ใช้ AI ตัวไหน ในงานอะไร และใช้ข้อมูลประเภทใด" ผ่านแบบสอบถามแบบไม่ระบุตัวตน และรับฟังความคิดเห็นที่แท้จริง (เช่น ความไม่สะดวกของเครื่องมือที่เป็นทางการ) ผ่านการสัมภาษณ์หน้างาน ในความเป็นจริงแล้ว มีคำตอบจำนวนมากที่ระบุว่า "ไม่ทราบว่ามีการห้ามไว้" ซึ่งกรณีนี้ไม่ควรถูกมองว่าเป็นเป้าหมายในการควบคุม แต่ควรใช้เป็นเบาะแสสำหรับความต้องการด้านการฝึกอบรม หากต้องการเพิ่มอัตราการตอบกลับ การให้ผู้บริหารเป็นผู้สื่อสารจะช่วยให้ได้ผลลัพธ์ที่ดีขึ้น การออกแบบการสำรวจให้เป็นการทำความเข้าใจสถานการณ์หน้างานแทนที่จะเป็นการตรวจสอบเพื่อควบคุมตัวเลข จะนำไปสู่การเข้าใจสถานการณ์จริงได้อย่างแม่นยำในท้ายที่สุด
การตรวจจับบริการ AI อัตโนมัติโดยใช้เครื่องมือจัดการ SaaS
การใช้เครื่องมือจัดการ SaaS (เช่น SSPM หรือ CASB) ช่วยให้สามารถตรวจสอบรายการบริการ AI ที่กำลังใช้งานอยู่ได้โดยอัตโนมัติ โดยอ้างอิงจากข้อมูลสัญญา การเรียกเก็บเงิน การเชื่อมต่อ OAuth และส่วนขยายของเบราว์เซอร์ สิ่งที่มีประสิทธิภาพเป็นพิเศษคือการตรวจสอบแอป AI ภายนอกที่เชื่อมต่อกับบัญชีบริษัทผ่าน OAuth เนื่องจากแอปเหล่านี้อาจกลายเป็นช่องทางในการเข้าถึงข้อมูลภายในบริษัทโดยไม่ได้รับอนุญาต นอกจากนี้ ควรนำข้อมูลไปเปรียบเทียบกับสถานะการจัดการส่วนขยายของเบราว์เซอร์และประวัติการเข้าสู่ระบบของ IdP (โครงสร้างพื้นฐานด้าน ID) ด้วย
จุดแข็งของเครื่องมือเหล่านี้คือความสามารถในการตรวจจับได้อย่างต่อเนื่อง ซึ่งแตกต่างจากการตรวจสอบด้วยตนเอง การนำเครื่องมือนี้ไปรวมเป็นส่วนหนึ่งของกลไก "การเฝ้าระวังตลอดเวลา" หลังจากเสร็จสิ้นการตรวจสอบรอบแรกจะมีประสิทธิภาพมาก เนื่องจากมีเครื่องมือจำนวนมากในตลาด จึงควรเลือกเครื่องมือที่เหมาะสมกับสภาพแวดล้อมด้านไอทีของบริษัท (เช่น การมีอยู่ของ IdP หรือ MDM) และควรตัดสินใจให้ชัดเจนก่อนว่าต้องการตรวจจับอะไร เพื่อไม่ให้การนำเครื่องมือมาใช้กลายเป็นเป้าหมายหลักเพียงอย่างเดียว
ขั้นตอนที่ 2: จะประเมินและจำแนกเครื่องมือ AI ที่ตรวจพบได้อย่างไร?
เครื่องมือที่ตรวจพบจะถูกให้คะแนนตาม "แกนความเสี่ยง" และแบ่งออกเป็น 3 ระดับ ได้แก่ อนุมัติ, อนุมัติแบบมีเงื่อนไข และห้ามใช้ การไม่ห้ามทั้งหมดหรือปล่อยปละละเลยทั้งหมด แต่ใช้วิธีการขีดเส้นแบ่งตามระดับความเสี่ยงนั้นถือเป็นทางออกที่สมจริงที่สุด
4 แกนหลักในการประเมินความเสี่ยง: ความลับของข้อมูล, ข้อกำหนดการใช้งาน, ความปลอดภัย และการปฏิบัติตามกฎระเบียบ
โดยสรุปแล้ว ความเสี่ยงจะถูกกำหนดโดยผลคูณระหว่าง "ข้อมูลประเภทใดที่ใส่เข้าไป" และ "เครื่องมือจัดการข้อมูลนั้นอย่างไร"
| เกณฑ์การประเมิน | จุดที่ต้องตรวจสอบ |
|---|---|
| ความลับของข้อมูล | ประเภทของข้อมูลที่ป้อนเข้า (สาธารณะ / ความลับบริษัท / ข้อมูลส่วนบุคคล / ข้อมูลภายใต้กฎระเบียบ) |
| ข้อกำหนดการใช้งานและการจัดการข้อมูล | การนำข้อมูลไปใช้เทรนโมเดล, ระยะเวลาการจัดเก็บ, การจัดเก็บในต่างประเทศ, ความสามารถในการเลือกปฏิเสธ (Opt-out) |
| ความปลอดภัย | การยืนยันตัวตน (SSO/MFA), การเข้ารหัส, การควบคุมการเข้าถึง, ผลงานของผู้ให้บริการ |
| การปฏิบัติตามกฎระเบียบ | ข้อกำหนดข้อมูลส่วนบุคคล เช่น PDPA, กฎระเบียบเฉพาะอุตสาหกรรม, ภาระผูกพันในการรักษาความลับตามสัญญา |
ให้ประเมินคะแนนแต่ละเกณฑ์เป็น สูง/กลาง/ต่ำ แล้วนำมารวมกันเพื่อดูระดับความเสี่ยง สิ่งที่ควรระวังเป็นพิเศษคือ แผนการใช้งานส่วนบุคคลแบบฟรี มักถูกออกแบบมาให้ข้อมูลที่ป้อนเข้าไปถูกนำไปใช้ในการเทรนโมเดลได้ง่าย แม้จะเป็นเครื่องมือเดียวกัน แต่การจัดการข้อมูลอาจเปลี่ยนไปตามแผนสัญญาที่เลือกใช้ ดังนั้นจึงต้องประเมินรวมไปถึง "แผนการใช้งานที่ใช้อยู่" ด้วย
เกณฑ์การจำแนก 3 ระดับ: อนุมัติ, อนุมัติแบบมีเงื่อนไข, และห้ามใช้
โดยสรุปแล้ว ให้แบ่งการจัดการโดยพิจารณาจากหลักฐานความปลอดภัยในการจัดการข้อมูลลับ หากผ่านเกณฑ์ให้ "อนุมัติ" หากมีความเสี่ยงแต่หาเครื่องมือทดแทนได้ยากให้ "อนุมัติแบบมีเงื่อนไข" และหากไม่ผ่านเกณฑ์ให้ "ห้ามใช้"
| การจำแนก | เกณฑ์ | ตัวอย่าง |
|---|---|---|
| อนุมัติ | มีสัญญาสำหรับองค์กรที่รับประกันว่าจะไม่นำข้อมูลไปเทรนและมีการคุ้มครองข้อมูล รวมถึงรองรับการเชื่อมต่อ SSO | บริการ AI ที่ทำสัญญาอย่างเป็นทางการแล้ว |
| อนุมัติแบบมีเงื่อนไข | อนุญาตให้ใช้ได้หากจำกัดวัตถุประสงค์และประเภทข้อมูล (เช่น ห้ามป้อนข้อมูลส่วนบุคคล) | การใช้แชท AI ทั่วไปสำหรับงานที่ไม่เป็นความลับเท่านั้น |
| ห้ามใช้ | หลีกเลี่ยงการนำข้อมูลลับไปเทรนหรือการจัดเก็บข้อมูลในต่างประเทศไม่ได้ และข้อกำหนดการใช้งานไม่โปร่งใส | เครื่องมือ AI ฟรีที่ไม่ทราบที่มา |
การจำแนกนี้จะไม่คงที่ แต่จะมีการทบทวนตามการเปลี่ยนแปลงของสัญญาหรือการจัดหาเครื่องมือทดแทน สิ่งสำคัญที่สุดคือ เมื่อมีการกำหนด "ห้ามใช้" จะต้องระบุ "เครื่องมือทดแทนที่ได้รับอนุมัติ" ควบคู่ไปด้วยเสมอ หากประกาศห้ามโดยไม่มีทางเลือกอื่น พนักงานจะกลับไปใช้ Shadow AI อีกครั้ง
การสร้างภาพรวมและบันทึกเครื่องมือที่ใช้งานโดยใช้ AI BOM
AI BOM (AI Bills of Materials) คือ "รายการส่วนประกอบ" ที่รวบรวมโมเดล แหล่งข้อมูล การพึ่งพาอาศัยกัน และบริการ AI ภายนอกที่ระบบใช้งานไว้ทั้งหมด โดยผลลัพธ์จากการตรวจสอบ Shadow AI คือการนำเครื่องมือ AI ทั้งหมดที่ตรวจพบมาลงทะเบียนใน AI BOM พร้อมบันทึกวัตถุประสงค์ ประเภทข้อมูล ระดับความเสี่ยง และสถานะการอนุมัติ
สิ่งนี้ถือเป็นรากฐานของการกำกับดูแลอย่างต่อเนื่อง เมื่อมีเครื่องมือใหม่ปรากฏขึ้นให้นำมาเพิ่มในรายการและใช้เป็นหลักฐานในการตรวจสอบ กรอบการทำงานต่างๆ เช่น NIST AI RMF ต่างก็กำหนดให้การจัดการบัญชีทรัพย์สิน (Inventory) ในลักษณะนี้เป็นข้อกำหนดร่วมกัน การรวมศูนย์ข้อมูลไว้ในบัญชีรายการจะช่วยขจัดสภาวะที่เป็นต้นตอของ Shadow AI ซึ่งก็คือการที่ "ไม่มีใครเข้าใจภาพรวมทั้งหมด" ในทางกลับกัน หากไม่มีบัญชีรายการดังกล่าว ต่อให้ตรวจพบเครื่องมือเป็นรายกรณีไป การบริหารจัดการก็จะไม่สามารถต่อยอดขึ้นไปได้
ขั้นตอนที่ 3: จะนำระบบการจัดการและมาตรการแก้ไขไปปฏิบัติอย่างไร?
อย่าให้จบแค่การประเมิน แต่ต้องนำไปปรับใช้เป็น "กลไกที่ใช้งานได้อย่างต่อเนื่อง" ใน 3 ด้าน ได้แก่ นโยบาย, การควบคุมทางเทคนิค และการศึกษา การตรวจสอบไม่ใช่เหตุการณ์ที่เกิดขึ้นเพียงครั้งเดียว แต่เป็นกระบวนการดำเนินงานที่ต้องทำอย่างต่อเนื่อง
การกำหนด/ปรับปรุงนโยบายการใช้ AI และวิธีการสื่อสารทั่วทั้งองค์กร
นโยบายการใช้งาน AI ควรประกอบด้วยรายการเครื่องมือที่ได้รับอนุญาต การระบุว่าข้อมูลประเภทใดสามารถป้อนเข้าสู่ระบบได้บ้าง ข้อห้าม มาตรการเมื่อมีการฝ่าฝืน และขั้นตอนการขออนุมัติ เคล็ดลับในการเพิ่มประสิทธิภาพคือนโยบายต้องไม่เป็นเพียงหลักการเชิงนามธรรม แต่ต้องระบุตัวอย่างที่ชัดเจนว่า "สำหรับงานนี้ สามารถใช้ AI ตัวนี้ กับข้อมูลประเภทนี้ได้/ไม่ได้"
การสื่อสารนโยบายไม่ควรจบลงเพียงแค่การแจกจ่ายเอกสาร แต่ต้องมาพร้อมกับการจัดอบรม การทดสอบความเข้าใจ และการบรรจุไว้ในกระบวนการปฐมนิเทศพนักงานใหม่ นอกจากนี้ ควรมีการกำหนดรอบการทบทวนนโยบายไว้ล่วงหน้า เนื่องจากทั้ง AI เครื่องมือ และข้อกำหนดของผู้ให้บริการมีการเปลี่ยนแปลงอยู่ตลอดเวลา สิ่งที่ต้องระวังคือหากนโยบายเข้มงวดจนเกินไปจะนำไปสู่การใช้งานแบบลับๆ (Shadow AI) อีกครั้ง การกำหนดมาตรฐานที่สมเหตุสมผลซึ่งหน้างานสามารถปฏิบัติตามได้จริง จะช่วยเพิ่มอัตราการปฏิบัติตามนโยบายได้ในที่สุด
การนำ AI Guardrails มาใช้และการควบคุมการเข้าถึงทางเทคนิค
สิ่งสำคัญคือต้องไม่พึ่งพาเพียงแค่กฎระเบียบเท่านั้น แต่ต้องอาศัยเทคโนโลยีเข้ามาสนับสนุนด้วย โดยมีรายละเอียดดังนี้: ① ใช้ CASB หรือ SWG ในการควบคุมการเข้าถึงบริการ AI ที่ไม่ได้รับอนุญาต (บล็อกหรือแจ้งเตือน) ② ใช้ DLP (Data Loss Prevention) เพื่อตรวจจับและสกัดกั้นการส่งข้อมูลที่เป็นความลับไปยัง AI ภายนอก ③ จัดเตรียม AI สำหรับองค์กรที่มาพร้อมกับ SSO และ MFA เพื่อให้ใช้งานผ่านช่องทางที่ถูกต้องได้ง่ายขึ้น และ ④ บันทึกและตรวจสอบ Prompt รวมถึงผลลัพธ์ที่ได้บนโครงสร้างพื้นฐาน AI ภายในองค์กร
หลักการสำคัญที่ขาดไม่ได้คือ ต้องทำ "การควบคุมทางเทคนิคเพื่อห้ามใช้งาน" ควบคู่ไปกับ "การจัดเตรียมช่องทางที่ถูกต้อง" เสมอ หากปิดกั้นการเข้าถึงเพียงอย่างเดียว พนักงานจะพยายามหาทางเลี่ยง การควบคุมทางเทคนิคจะทำงานได้อย่างมีประสิทธิภาพก็ต่อเมื่อมีการออกแบบเพื่อจูงใจให้พนักงานหันมาใช้ช่องทางที่เป็นทางการซึ่งทั้งปลอดภัยและสะดวกสบาย การปิดกั้นและการเปิดให้ใช้งานจึงไม่ใช่สิ่งที่ขัดแย้งกัน แต่เป็นสิ่งที่ต้องออกแบบให้ทำงานควบคู่กันไปเหมือนล้อทั้งสองข้าง
การให้ความรู้ด้าน AI Literacy และกลไกการติดตามผลอย่างต่อเนื่อง
ในการให้ความรู้ ต้องอธิบายว่าทำไมถึงอันตราย (สถานการณ์การรั่วไหลที่ชัดเจน) อะไรที่ถือเป็นข้อมูลลับ และวิธีใช้งานอย่างไรให้ปลอดภัย โดยไม่ควรจัดอบรมเพียงครั้งเดียวจบ แต่ต้องดำเนินการอย่างสม่ำเสมอ ในด้านการตรวจสอบ ต้องตรวจหาบริการ AI ใหม่ๆ อย่างต่อเนื่อง (ทำซ้ำ Step 1 เป็นระยะ) อัปเดต AI BOM และเตรียมขั้นตอนการรับมือเหตุการณ์ไม่พึงประสงค์ไว้
ตัวอย่าง KPI สำหรับวัดความคืบหน้า ได้แก่ อัตราการใช้งานเครื่องมือที่ได้รับอนุมัติ แนวโน้มจำนวนการเข้าถึงที่ไม่ได้รับอนุญาต และอัตราการเข้ารับการอบรม เป็นต้น โดยใช้ข้อมูลเหล่านี้เพื่อขับเคลื่อนวงจร PDCA คือ การตรวจสอบ (Audit) → การแก้ไข (Corrective Action) → การตรวจสอบซ้ำ (Re-audit) สุดท้ายนี้ มีมุมมองด้านการปฏิบัติงานที่สำคัญประการหนึ่ง คือต้องตั้งอยู่บนสมมติฐานที่ว่าเราไม่สามารถกำจัด Shadow AI ให้เป็นศูนย์ได้ เป้าหมายจึงไม่ใช่การกวาดล้างให้หมดสิ้น แต่เป็นการควบคุมความเสี่ยงให้อยู่ในระดับที่ยอมรับได้เสมอ
รูปแบบความล้มเหลวที่พบบ่อยในการตรวจสอบ Shadow AI และวิธีหลีกเลี่ยง
ความล้มเหลวที่พบบ่อยมี 2 ประการ คือ "การสั่งห้ามโดยทันที" และ "การตรวจสอบเพียงครั้งเดียวแล้วจบไป" ซึ่งทั้งสองวิธีนี้จะส่งผลให้ Shadow AI ยิ่งหลบเร้นไปอยู่ในจุดที่มองไม่เห็นมากยิ่งขึ้นในท้ายที่สุด
กับดักของแนวทาง "สั่งห้ามก่อน" ที่นำไปสู่การต่อต้านจากพนักงาน
หากห้ามโดยไม่มีมาตรการทดแทนรองรับ ฝ่ายปฏิบัติงานจะต่อต้านว่า "แบบนี้งานก็เดินไม่ได้" และจะแอบนำไปใช้ในอุปกรณ์ส่วนตัวหรือที่บ้าน กล่าวคือ ปัญหาจะยิ่งหลบเข้าไปอยู่ในจุดที่มองไม่เห็น ซึ่งส่งผลเสียมากกว่าเดิม
วิธีหลีกเลี่ยงคือ 1. จัดหาเครื่องมือทดแทนที่ผ่านการอนุมัติควบคู่ไปกับการสั่งห้าม 2. อธิบายเหตุผลที่ต้องห้ามให้เข้าใจอย่างถ่องแท้ 3. รับฟังความต้องการในการทำงานของหน้างานและนำมาปรับใช้กับเครื่องมือที่เป็นทางการ และ 4. กำหนดช่วงเวลาเปลี่ยนผ่าน กุญแจสำคัญคือการเปลี่ยนข้อความจาก "ห้ามใช้" เป็น "ให้ใช้สิ่งนี้แทน" การออกแบบที่ทำให้ความปลอดภัยและความสามารถในการผลิตขัดแย้งกันนั้น มักจะล้มเหลวในจุดใดจุดหนึ่งเสมอ การวางระบบโดยตั้งอยู่บนพื้นฐานที่ว่าทั้งสองอย่างต้องอยู่ร่วมกันได้ คือทางลัดสู่ความสำเร็จในการนำไปปฏิบัติจริง
ปัญหาของการตรวจสอบเพียงครั้งเดียวแล้วจบไป
บริการ AI ใหม่ๆ เกิดขึ้นอย่างต่อเนื่องและวิธีการใช้งานของพนักงานก็เปลี่ยนไปตามกาลเวลา ส่งผลให้ผลการตรวจสอบเพียงครั้งเดียวกลายเป็นข้อมูลที่ล้าสมัยอย่างรวดเร็ว วิธีแก้ไขคือการดำเนินการตรวจจับอย่างสม่ำเสมอ (เช่น ทุกไตรมาส) อัปเดต AI BOM ให้เป็นบัญชีรายการที่มีการเคลื่อนไหวอยู่ตลอดเวลา ปรับปรุงนโยบายเป็นระยะ และประเมินความเสี่ยงของบริการใหม่ๆ อย่างต่อเนื่อง กล่าวโดยสรุปคือ ต้องเปลี่ยนการตรวจสอบให้เป็น "กระบวนการดำเนินงาน" (Operational Process) แทนที่จะเป็นเพียง "โครงการ" โดยกำหนดผู้รับผิดชอบ ความถี่ และผลลัพธ์ให้เป็นมาตรฐาน กรอบการทำงานอย่าง NIST AI RMF เองก็ตั้งอยู่บนสมมติฐานของการกำกับดูแล (Govern) และการวัดผล (Measure) อย่างต่อเนื่องเช่นกัน
สุดท้ายนี้ ขอย้ำอีกครั้งว่าจุดประสงค์ของการตรวจสอบ Shadow AI ไม่ใช่การควบคุมเพื่อห้ามปราม แต่เป็นการสร้างสภาพแวดล้อมที่สามารถใช้งานได้อย่างปลอดภัย หากทำให้วงจรการมองเห็น (Visualization) → การประเมิน (Evaluation) → การจัดการ (Management) → การให้ความรู้ (Education) กลายเป็นเรื่องปกติได้ ก็จะสามารถเก็บเกี่ยวผลประโยชน์จากการใช้ AI ได้อย่างเต็มที่ในขณะที่ยังคงควบคุมความเสี่ยงไว้ได้
ผู้เขียน・ผู้ตรวจสอบ
Yusuke Ishihara
เริ่มเขียนโปรแกรมตั้งแต่อายุ 13 ปี ด้วย MSX หลังจบการศึกษาจากมหาวิทยาลัย Musashi ได้ทำงานพัฒนาระบบขนาดใหญ่ รวมถึงระบบหลักของสายการบิน และโครงสร้าง Windows Server Hosting/VPS แห่งแรกของญี่ปุ่น ร่วมก่อตั้ง Site Engine Inc. ในปี 2008 ก่อตั้ง Unimon Inc. ในปี 2010 และ Enison Inc. ในปี 2025 นำทีมพัฒนาระบบธุรกิจ การประมวลผลภาษาธรรมชาติ และแพลตฟอร์ม ปัจจุบันมุ่งเน้นการพัฒนาผลิตภัณฑ์และการส่งเสริม AI/DX โดยใช้ generative AI และ Large Language Models (LLM)


