AI Search แบบปลอดภัย: ให้พนักงานค้นข้อมูลภายในองค์กรโดยไม่ทำข้อมูลรั่ว
AI Search และ RAG ช่วยให้พนักงานค้นความรู้ภายในองค์กรได้เร็วขึ้น แต่ถ้าไม่วาง access control, data boundary และ logging ให้ดี ก็อาจกลายเป็นช่องทางใหม่ที่ทำให้ข้อมูลสำคัญรั่วโดยไม่ตั้งใจ
หลายองค์กรเริ่มสนใจ AI Search เพราะข้อมูลภายในกระจัดกระจายมากครับ เอกสารอยู่ใน Drive, ticket อยู่ใน helpdesk, runbook อยู่ใน wiki, policy อยู่ใน SharePoint หรือ Notion, บางอย่างอยู่ในอีเมล และคนในทีมก็เสียเวลาไล่ถามกันซ้ำ ๆ ว่าไฟล์ล่าสุดอยู่ตรงไหน
พอมี AI Search หรือระบบถามตอบจากเอกสารภายใน ภาพที่อยากได้คือพนักงานถามภาษาคนแล้วได้คำตอบพร้อมแหล่งอ้างอิงทันที เช่น "ขั้นตอนขอ access production ต้องทำอย่างไร", "นโยบายเบิกอุปกรณ์ล่าสุดอยู่ตรงไหน", หรือ "ลูกค้าเคยแจ้งปัญหาแบบนี้ไว้ใน ticket ไหนบ้าง"
แต่ความสะดวกนี้มีด้านที่ต้องระวัง ถ้าระบบค้นข้อมูลภายในตอบจากเอกสารที่ผู้ใช้คนนั้นไม่มีสิทธิ์อ่าน เดิมข้อมูลอาจไม่ได้รั่วเพราะคนไม่รู้ว่ามีไฟล์นั้นอยู่ แต่ AI Search อาจทำให้ข้อมูลที่เคยถูกซ่อนด้วยความกระจัดกระจาย ถูกค้นเจอและสรุปออกมาในไม่กี่วินาที
สำหรับผม โจทย์ของ AI Search ในองค์กรจึงไม่ใช่แค่ "ทำอย่างไรให้ตอบเก่ง" แต่คือ "ทำอย่างไรให้ตอบเฉพาะสิ่งที่ผู้ถามควรรู้ เหลือหลักฐานตรวจสอบได้ และไม่ทำให้ข้อมูลภายในไหลออกจากขอบเขตที่ควรอยู่"
สาระตั้งต้นจากแหล่งข้อมูล
ก่อนเขียนเป็นแนวทาง ผมสรุปแก่นจากแหล่งอ้างอิงและประสบการณ์ใช้งานจริงไว้ก่อน:
- NIST AI Risk Management Framework เน้นการจัดการความเสี่ยง AI ผ่านการ govern, map, measure และ manage ซึ่งแปลในบริบท AI Search ได้ว่าต้องรู้ว่าระบบค้นข้อมูลอะไร ใครใช้ได้ วัดความเสี่ยงอย่างไร และปรับปรุงอย่างไร
- NIST Generative AI Profile ชี้ให้เห็นความเสี่ยงของ generative AI เช่นข้อมูลที่ไม่ควรเปิดเผย คำตอบผิดแต่ดูน่าเชื่อถือ และการใช้งานเกินบริบท
- CISA AI Data Security ให้ความสำคัญกับการปกป้องข้อมูลตลอด lifecycle ของ AI ทั้งข้อมูลที่ใช้สร้างระบบ ข้อมูลที่ใช้ตอนถามตอบ และข้อมูลที่เกิดจากการใช้งาน
- OWASP Top 10 for LLM Applications 2025 ระบุความเสี่ยงอย่าง Sensitive Information Disclosure และ Vector and Embedding Weaknesses ซึ่งเกี่ยวข้องโดยตรงกับระบบ RAG และ AI Search
- Microsoft Azure AI Search มีแนวคิดเรื่อง security trimming หรือการกรองผลลัพธ์ตามสิทธิ์ผู้ใช้ก่อนส่งข้อมูลให้ระบบตอบคำถาม ซึ่งเป็น pattern สำคัญของ AI Search ในองค์กร
ถ้าแปลงให้เป็นภาษาปฏิบัติ AI Search ที่ปลอดภัยต้องเริ่มจากสิทธิ์และข้อมูล ไม่ใช่เริ่มจากหน้าจอถามตอบที่ดูฉลาดอย่างเดียว
RAG ไม่ได้แปลว่าปลอดภัยโดยอัตโนมัติ
หลายคนรู้จัก RAG หรือ Retrieval-Augmented Generation ในฐานะวิธีทำให้ AI ตอบจากเอกสารของเราเอง แทนที่จะตอบจากความรู้ทั่วไปของโมเดล แนวคิดพื้นฐานคือระบบจะค้นเอกสารที่เกี่ยวข้องก่อน แล้วค่อยส่งบริบทนั้นให้โมเดลสร้างคำตอบ
ข้อดีคือคำตอบมีโอกาสอิงแหล่งข้อมูลจริงมากขึ้น และถ้าออกแบบดี ระบบสามารถแนบ citation หรือแหล่งอ้างอิงกลับมาให้ตรวจได้ แต่ RAG ไม่ได้ทำให้ระบบปลอดภัยเองโดยอัตโนมัติครับ
ตัวอย่างปัญหาที่เจอได้:
- index รวมเอกสารทุกฝ่ายไว้ด้วยกัน แต่ตอนค้นไม่ได้กรองตามสิทธิ์ผู้ใช้
- เอกสารเก่าหรือร่างที่ไม่ควรใช้จริงถูกดึงมาเป็นบริบท
- ข้อมูลลับถูกแปลงเป็น embedding แล้วเก็บในระบบที่ไม่มีการควบคุม access ดีพอ
- ผู้ใช้ถามแบบอ้อม ๆ แล้วระบบสรุปข้อมูลที่เขาไม่ควรเห็น
- ไม่มี log ว่าคำตอบหนึ่งอ้างอิงเอกสารใด ผู้ใช้คนไหนถาม และระบบดึงข้อมูลอะไรมาใช้
ดังนั้นการทำ AI Search ให้ปลอดภัยต้องคิดทั้ง pipeline ตั้งแต่ source document, indexing, permission metadata, retrieval, answer generation, citation, logging และ review loop
เริ่มจากขอบเขตข้อมูลก่อนทำ index
คำถามแรกไม่ควรเป็น "จะใช้ vector database ตัวไหนดี" แต่ควรเป็น "ข้อมูลอะไรควรเข้า AI Search ตั้งแต่แรก"
สำหรับองค์กรเล็กหรือทีมที่เพิ่งเริ่ม ผมแนะนำให้แบ่งข้อมูลอย่างง่ายก่อน เช่น:
- Public หรือ company-wide: ข้อมูลที่ทุกคนในองค์กรอ่านได้ เช่น policy ทั่วไป คู่มือ onboarding หรือประกาศภายใน
- Team-restricted: ข้อมูลที่อ่านได้เฉพาะบางทีม เช่น runbook infra, sales playbook, support ticket หรือ design document
- Confidential: ข้อมูลที่มีข้อมูลลูกค้า สัญญา ราคา payroll incident detail vulnerability detail หรือข้อมูลภายใต้ NDA
- Excluded: ข้อมูลที่ยังไม่ควรเข้า AI Search เช่น secret, token, private key, raw production log ที่ยังไม่ได้ scrub, เอกสาร legal ที่ยังไม่อนุมัติ หรือข้อมูลส่วนบุคคลที่ไม่จำเป็น
ประเด็นสำคัญคือไม่ใช่ทุกอย่างที่ค้นได้ควรถูกใส่เข้า AI Search ทันที ถ้าข้อมูลเดิมยังจัดสิทธิ์ไม่ดี การเอาไปทำ index อาจทำให้ปัญหาเดิมใหญ่ขึ้น เพราะ AI Search ทำให้ค้นข้ามเอกสารได้เร็วและสรุปได้ง่ายกว่าเดิมมาก
ก่อนเริ่ม index ควรถามให้ชัด:
- เจ้าของข้อมูลคือใคร
- ใครควรอ่านข้อมูลนี้ได้
- ข้อมูลนี้มีอายุการใช้งานหรือหมดอายุเมื่อไร
- มีข้อมูลส่วนบุคคลหรือข้อมูลลูกค้าหรือไม่
- ควรให้ AI ใช้ตอบโดยตรง หรือให้แค่ค้นเจอแล้วส่งคนไปอ่านต้นฉบับเอง
ถ้าตอบคำถามเหล่านี้ไม่ได้ การทำ AI Search อาจกลายเป็นการเอาข้อมูลที่ยังไม่พร้อมไปเปิดช่องทางเข้าถึงใหม่
Access control ต้องอยู่ใน retrieval ไม่ใช่แค่ UI
ข้อผิดพลาดที่อันตรายคือคิดว่าแค่ซ่อนปุ่มหรือซ่อนเมนูในหน้าเว็บก็พอ แต่ในระบบ AI Search access control ต้องอยู่ในขั้นตอน retrieval ด้วย
พูดง่าย ๆ คือก่อนที่ระบบจะส่งเอกสารใดให้โมเดลใช้ตอบ ต้องตรวจว่าผู้ใช้คนนั้นมีสิทธิ์อ่านเอกสารนั้นจริงหรือไม่ ไม่ใช่ให้โมเดลเห็นทุกอย่างแล้วหวังว่ามันจะไม่พูดออกมา
แนวทางที่ควรมี:
- เก็บ permission metadata ไปพร้อมกับเอกสารตอน index เช่น department, group, role, owner, sensitivity label หรือ ACL
- ผูกผู้ใช้กับ identity กลาง เช่น SSO หรือ IdP ไม่ใช้ account แยกที่ไม่รู้ว่าเป็นใคร
- กรองผลลัพธ์ค้นหาตามสิทธิ์ผู้ใช้ก่อนส่งเข้า prompt
- ตรวจสิทธิ์ใหม่เมื่อ permission ของเอกสารเปลี่ยน ไม่ปล่อยให้ index เก่าเก็บสิทธิ์ผิด
- แยก index สำหรับข้อมูลที่มีระดับความลับต่างกันมาก ถ้าการกรองใน index เดียวเสี่ยงเกินไป
ในทางปฏิบัติ security trimming เป็น pattern สำคัญมาก เพราะ AI Search ไม่ควรตอบจากเอกสารที่ผู้ใช้เปิดอ่านเองไม่ได้อยู่แล้ว ถ้าผู้ใช้ไม่มีสิทธิ์อ่านไฟล์ payroll ระบบก็ไม่ควรดึง payroll มาเป็นบริบท แม้คำถามจะดูเกี่ยวข้องก็ตาม
ตรงนี้เชื่อมกับแนวคิด least privilege และ Zero Trust โดยตรง ถ้าต้องการพื้นฐานเรื่องนี้ อ่าน เปลี่ยนผ่านสู่ยุค Zero Trust: แนวคิดพื้นฐานที่ควรเข้าใจ และตัวอย่างการใช้ในชีวิตจริง ต่อได้ครับ
Logging ทำให้ระบบตรวจสอบได้
AI Search ที่ใช้ในองค์กรควรมี log มากกว่าระบบ search ธรรมดา เพราะคำตอบไม่ได้เป็นแค่รายการผลลัพธ์ แต่เป็นการสรุปข้อมูลหลายแหล่งให้ผู้ใช้
อย่างน้อยควรเก็บ log เพื่อตอบคำถามเหล่านี้:
- ใครถาม
- ถามเมื่อไร
- ระบบค้นจาก data source หรือ index ไหน
- เอกสารหรือ chunk ใดถูกดึงมาใช้เป็นบริบท
- คำตอบอ้างอิง source ใด
- มีการ block ผลลัพธ์เพราะ permission หรือ sensitivity หรือไม่
- ผู้ใช้กด feedback ว่าคำตอบผิด ไม่ครบ หรือมีข้อมูลไม่ควรเปิดเผยหรือไม่
Log เหล่านี้ช่วยได้หลายเรื่อง เช่นตรวจ incident, วิเคราะห์ data leakage, ปรับคุณภาพ retrieval, หาเอกสารที่สิทธิ์ผิด และทำ post-incident review หากมีคำตอบที่ไม่ควรหลุดออกมา
แต่ log เองก็เป็นข้อมูลอ่อนไหวครับ เพราะอาจมี prompt, ชื่อเอกสาร, user ID, query และบางครั้งอาจมีข้อมูลที่ผู้ใช้พิมพ์ผิดพลาดเข้ามา ดังนั้น log ต้องมี retention, access control และ redaction ที่เหมาะสม ไม่ใช่เก็บทุกอย่างแบบเปิดกว้าง
ถ้าอยากต่อยอดเรื่อง log ในงาน incident อ่าน ทำไม Log ถึงสำคัญตอนเกิด Incident มากกว่าที่หลายคนคิด เพราะหลักคิดเดียวกันใช้กับ AI Search ได้ตรงมาก
คำตอบต้องมีแหล่งอ้างอิงและข้อจำกัด
AI Search ภายในองค์กรไม่ควรตอบเหมือน chatbot ทั่วไปที่พูดมั่นใจโดยไม่มีหลักฐาน โดยเฉพาะเมื่อตอบเรื่อง policy, security, legal, customer issue หรือ technical runbook
สิ่งที่ควรออกแบบตั้งแต่แรก:
- ทุกคำตอบควรแสดงแหล่งอ้างอิงหรือ link ไปยังเอกสารต้นทาง
- ถ้าระบบไม่พบเอกสารที่เกี่ยวข้องพอ ควรบอกว่าไม่พอ ไม่ควรเดา
- ถ้า source ขัดแย้งกัน ควรบอกว่าพบข้อมูลหลายชุดและชี้ให้คนตรวจ
- เอกสารที่หมดอายุหรือยังเป็น draft ไม่ควรถูกใช้ตอบแบบเท่ากับเอกสาร approved
- คำตอบที่กระทบงานสำคัญควรมี human review หรืออย่างน้อยต้องส่งคนไปอ่านต้นฉบับก่อนลงมือ
ปัญหาของ AI Search ไม่ได้มีแค่ข้อมูลรั่ว แต่รวมถึงการตอบผิดจากเอกสารเก่า เอกสารซ้ำ หรือเอกสารที่ไม่มี owner ถ้าพนักงานเชื่อคำตอบโดยไม่เห็น source ความเสี่ยงจะย้ายจาก "ค้นไม่เจอ" ไปเป็น "เจอคำตอบที่ดูน่าเชื่อแต่ผิด"
Connector คือจุดที่ต้องระวังเป็นพิเศษ
AI Search มักเชื่อมกับ connector เช่น Google Drive, Microsoft 365, Slack, Jira, Git repository, CRM, ticketing system หรือ wiki จุดนี้มีประโยชน์มาก แต่ก็เป็นจุดเสี่ยงมากเช่นกัน
คำถามที่ควรถามก่อนเปิด connector:
- Connector ขอสิทธิ์อ่านข้อมูลกว้างแค่ไหน
- ใช้สิทธิ์ของผู้ใช้แต่ละคน หรือใช้ service account กลาง
- ถ้าใช้ service account กลาง สิทธิ์กว้างเกินจำเป็นหรือไม่
- เมื่อผู้ใช้ถูกถอดออกจากทีม สิทธิ์ใน AI Search ถูกปรับตามจริงหรือไม่
- ถ้าเอกสารถูกลบหรือเปลี่ยนสิทธิ์ index จะ update เร็วแค่ไหน
- มี data source ไหนที่ไม่ควรถูกต่อเข้าระบบค้นหาตั้งแต่แรกหรือไม่
สำหรับทีมเล็ก ผมมักแนะนำให้เริ่มจาก data source ที่ควบคุมง่ายก่อน เช่น knowledge base ที่จัด owner และสิทธิ์ชัดเจน อย่าเพิ่งต่อทุกอย่างเข้ามาพร้อมกัน เพราะถ้ามีปัญหา จะหาต้นตอยากมาก
Checklist เริ่มต้นสำหรับทีมที่อยากทำ AI Search
ถ้าต้องเริ่มแบบ practical ผมจะวางลำดับแบบนี้:
- เลือก use case แคบ ๆ ก่อน เช่นค้น policy ภายในหรือ runbook ที่ approved แล้ว
- ทำ inventory ของ data source ที่จะนำเข้า
- แยกข้อมูลที่ company-wide, team-restricted, confidential และ excluded
- กำหนด owner ของแต่ละ data source
- ผูกระบบกับ identity กลางและ group ที่ใช้จริง
- เก็บ permission metadata ตอน index
- ทำ security trimming ก่อนส่งบริบทให้โมเดล
- ให้คำตอบแสดง source และบอกข้อจำกัดเมื่อไม่แน่ใจ
- เก็บ log ของ query, retrieved source, permission decision และ feedback
- ทดสอบด้วย user หลาย role ว่าไม่เห็นข้อมูลข้ามสิทธิ์
- ทำ red-team scenario แบบง่าย เช่นถามอ้อม ๆ เพื่อดูว่าระบบสรุปข้อมูลลับออกมาหรือไม่
- ตั้ง review cadence เพราะเอกสารและสิทธิ์ในองค์กรเปลี่ยนตลอดเวลา
สิ่งที่ไม่ควรทำคือเริ่มจากการต่อทุก repository ทุก drive และทุก ticket เข้าระบบเดียว แล้วค่อยหวังว่าจะคุมทีหลัง ระบบแบบนั้นอาจ demo ได้เร็ว แต่ความเสี่ยงจะโตเร็วตามไปด้วย
ความปลอดภัยต้องไม่ทำให้คนเลี่ยงระบบ
อีกด้านหนึ่ง ถ้าระบบ AI Search ภายในใช้งานยาก ตอบช้า หรือค้นได้น้อยเกินไป คนก็อาจกลับไปใช้ public AI account หรือส่งไฟล์กันเองเหมือนเดิม เรื่องนี้คล้ายกับ Shadow AI ในทีมเล็ก คือถ้า path ทางการไม่ตอบโจทย์งานจริง path นอกระบบจะเกิดขึ้นเอง
ดังนั้น guardrail ที่ดีควรทำให้คนทำงานได้ ไม่ใช่ทำให้ทุกอย่างติด approval จนใช้ไม่ได้ ตัวอย่างเช่น:
- ข้อมูล company-wide ค้นได้ทันที
- ข้อมูล team-restricted ค้นได้ตาม group ที่ผู้ใช้มีอยู่แล้ว
- ข้อมูล confidential อาจค้นเจอเฉพาะ metadata หรือให้ขอ access จาก owner
- คำตอบที่ไม่มี source ชัดเจนควรถูกลดความน่าเชื่อถือ
- ผู้ใช้ควรรายงานคำตอบผิดหรือข้อมูลไม่ควรเปิดเผยได้ง่าย
ถ้าวางแบบนี้ AI Search จะเป็นเครื่องมือทำงานที่เร็วขึ้นและปลอดภัยขึ้นพร้อมกัน ไม่ใช่แค่ช่อง search ใหม่ที่ทุกคนต้องระแวง
สรุป
AI Search ภายในองค์กรมีประโยชน์มาก เพราะช่วยลดเวลาหาเอกสาร ลดคำถามซ้ำ และทำให้ความรู้ที่กระจัดกระจายถูกใช้งานได้จริง แต่ความสามารถเดียวกันนี้ก็ทำให้ข้อมูลที่จัดสิทธิ์ไม่ดีหรือไม่มี owner ถูกค้นและสรุปออกมาได้ง่ายกว่าเดิม
การทำให้ปลอดภัยจึงต้องเริ่มจากขอบเขตข้อมูลและ access control ก่อน แล้วค่อยตามด้วย RAG, embedding, prompt, model และ UI ระบบควรดึงเฉพาะเอกสารที่ผู้ใช้มีสิทธิ์อ่าน แสดง source เก็บ log ตรวจสอบได้ และมีวิธีจัดการเมื่อคำตอบผิดหรือข้อมูลไม่ควรถูกเปิดเผย
ในทางปฏิบัติ ไม่ต้องเริ่มจากระบบใหญ่ที่สุด เริ่มจาก use case แคบ ๆ ที่ข้อมูลพร้อม สิทธิ์ชัด และมี owner ก่อน แล้วค่อยขยายทีละส่วน AI Search ที่ดีไม่ใช่ระบบที่รู้ทุกอย่าง แต่คือระบบที่รู้พอเหมาะ ตอบจากหลักฐาน และเคารพขอบเขตข้อมูลขององค์กร
อ่านต่อที่เกี่ยวข้อง
- ถ้าอยากเข้าใจการวางขอบเขต AI ในทีมเล็ก อ่าน AI Governance สำหรับทีมเล็ก: ไม่ต้องมีเอกสารร้อยหน้า แต่ต้องมีขอบเขต
- ถ้าอยากเห็นความเสี่ยงจากการใช้ AI นอกกรอบทีม อ่าน Shadow AI ในทีมเล็ก: Productivity เพิ่มขึ้น แต่ข้อมูลอาจไหลออกแบบเงียบ ๆ
- ถ้าต้องการพื้นฐานเรื่อง least privilege และการไม่เชื่อสิทธิ์โดยอัตโนมัติ อ่าน เปลี่ยนผ่านสู่ยุค 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 LLM08:2025 Vector and Embedding Weaknesses
- Microsoft Learn: Security filters for trimming results in Azure AI Search