ฝ่ายการตลาดแอบต่อเอเจนต์ AI สามตัว โดยที่ฝ่าย IT ไม่รู้เรื่องเลย: Shadow AI กำลังกลายเป็นหลุมดำความปลอดภัย

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

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

ไม่มีใครเป็นคนไม่ดี ไม่มีใครฝ่าฝืนกฎบริษัท เพราะบริษัทไม่มีกฎข้อนี้เลยตั้งแต่แรก

ภูมิหลังของเรื่อง

คำว่า Shadow IT มีมานานแล้ว พนักงานเลี่ยงฝ่าย IT ไปใช้เครื่องมือเอง ใช้ Dropbox ส่วนตัวส่งไฟล์ ใช้เครื่องมือออนไลน์ฟรีแปลง PDF ความเสี่ยงมีอยู่จริง แต่ขอบเขตค่อนข้างชัด เครื่องมือเหล่านั้นเป็นแบบตั้งรับ คุณใส่อะไรเข้าไปมันก็ประมวลผลสิ่งนั้น

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

และอุปสรรคในการนำมันมาใช้ต่ำจนไม่น่าเชื่อ แพลตฟอร์ม low-code ในปัจจุบันทำให้เจ้าหน้าที่การตลาดคนหนึ่งต่อเอเจนต์ที่อ่าน CRM เขียนรายงาน ส่งข้อความ Slack ได้ในบ่ายวันเดียว เขาไม่ต้องขออนุมัติจาก IT ไม่ต้องมีกระบวนการจัดซื้อ อาจไม่รู้สึกด้วยซ้ำว่าตัวเองกำลัง "นำระบบมาใช้" เขารู้สึกว่าตัวเองแค่ตั้งค่าการทำงานอัตโนมัติ

ปัญหานี้ใหญ่ถึงขั้นมีสตาร์ตอัปทำเรื่องนี้โดยเฉพาะ Decawork รุ่นฤดูร้อน 2026 ของ Y Combinator เรียกตัวเองว่าเป็น "ระนาบควบคุมเอเจนต์สำหรับทีม IT" ชูการให้ฝ่าย IT ดีพลอย กำกับดูแล และดูแลเอเจนต์ AI ทั้งองค์กรบนอินเทอร์เฟซเดียว ต้องเซ็นอนุมัติก่อนเปิดใช้ สิทธิ์ของข้อมูลรับรองต้องจำกัดให้แคบที่สุด ทุกการกระทำถูกเฝ้าติดตามและทิ้งร่องรอย บริษัทก่อตั้งโดย Aman Raj และ Sarthak Aggarwal ในซานฟรานซิสโกเมื่อปี 2026 ปัจจุบันทีมมีแค่สองคน ขนาดเล็กมาก แต่ทิศทางบอกถึงความเป็นจริงของปัญหา

ประเด็นสำคัญของครั้งนี้

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

วิเคราะห์ผลกระทบต่อตลาด

ต่อผู้ใช้ชาวไทย

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

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

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

ต่อการใช้งานในองค์กร

จากมุมการบริหารความเสี่ยงขององค์กร อันตรายของ Shadow AI ถูกประเมินต่ำอย่างเป็นระบบ ด้วยเหตุผลสามข้อ

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

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

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

ในทางปฏิบัติ ขั้นแรกไม่ใช่การซื้อเครื่องมือ แต่คือการสำรวจ ใช้วิธีดั้งเดิมที่สุด ตรวจบันทึกการออก API key ตรวจรูปแบบการเข้าถึงฐานข้อมูลที่ผิดปกติ ตรวจบิลค่าสมัคร SaaS ของแต่ละแผนก ถามหัวหน้าแต่ละแผนกตรง ๆ ว่า "พวกคุณมีการใช้เครื่องมืออะไรที่ทำงานอัตโนมัติไหม" รายการนี้มักทำให้คนตกใจ

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

ต่อนักพัฒนา

สำหรับทีมวิศวกร บทเรียนที่สมจริงที่สุดของเรื่องนี้คือ การออกข้อมูลรับรองต้องมีวงจรชีวิต

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

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

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

แนวโน้มการพัฒนาในอนาคต

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

สอง "อัตลักษณ์ของเอเจนต์" จะกลายเป็นแนวคิดที่ชัดเจน เหมือนที่ service account เมื่อก่อนแยกตัวออกมาจากบัญชีของคน เอเจนต์ต้องการประเภทอัตลักษณ์ของตัวเอง โมเดลสิทธิ์ของตัวเอง และการจัดการวงจรชีวิตของตัวเอง

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

บทสรุปและความเห็นจาก TheAI Academy

ผมอยากพูดประโยคที่อาจไม่ค่อยเป็นที่นิยมก่อน ความรับผิดชอบของเรื่องนี้ไม่ได้อยู่ที่พนักงานที่ต่อเอเจนต์เอง

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

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

จังหวะที่ควรจัดการคือตอนนี้ ตอนที่รายการยังสำรวจให้ครบได้

ความเห็น: Shadow AI ไม่ใช่ปัญหาวินัยของพนักงาน แต่คือช่องว่างการกำกับดูแลขององค์กร การห้ามไม่ได้ผล วิธีเดียวที่ได้ผลคือปูทางที่ชอบด้วยกฎให้เดินง่ายกว่าการฝ่าฝืน

คำแนะนำที่เป็นรูปธรรมสำหรับผู้อ่านชาวไทย: หากคุณรับผิดชอบ IT หรือความปลอดภัยของบริษัท เดือนนี้ทำสามเรื่อง หนึ่ง สำรวจ ตรวจบันทึกการออก API key รูปแบบการเข้าถึงฐานข้อมูลที่ผิดปกติ และบิล SaaS ของแต่ละแผนก ทำรายการเอเจนต์ออกมาหนึ่งชุด สอง รวบข้อมูลรับรอง ตั้งวันหมดอายุให้ข้อมูลรับรองชั่วคราวทั้งหมด จำกัดสิทธิ์ของเอเจนต์ทุกตัวให้อยู่ในขอบเขตน้อยที่สุดที่จำเป็น สาม เปิดช่องทางที่ชอบด้วยกฎเส้นหนึ่ง ออกแบบแบบฟอร์มลงทะเบียนที่กรอกเสร็จในห้านาที ให้เพื่อนร่วมงานยอมแจ้งด้วยความเต็มใจ ส่วนเครื่องมือกำกับดูแล ผลิตภัณฑ์อย่าง Decawork ทิศทางถูกต้องแต่ทีมมีแค่สองคนและเพิ่งก่อตั้งปีนี้ ระยะนี้แนะนำให้เข้าใจปัญหาก่อน สังเกตในวงแคบ อย่าเพิ่งรีบมอบกุญแจของบริษัทออกไป อยากเข้าใจเครื่องมือที่เกี่ยวข้องเพิ่ม ดูได้ที่หมวด เฟรมเวิร์กและโครงสร้างพื้นฐานการพัฒนา AI หรือดู คู่มืองาน AI บนเว็บไซต์

แหล่งข้อมูล

• Decawork (หน้าบริษัทใน Y Combinator)
• คณะกรรมาธิการยุโรป: กรอบการบังคับใช้กฎหมาย AI

(บทความนี้เรียบเรียงจากข้อมูลสาธารณะ ฉากกรณีเป็นการเรียบเรียงใหม่จากการสัมภาษณ์หลายฝ่าย ไม่พาดพิงถึงบริษัทใดโดยเฉพาะ)