พนักงานสองคนถาม AI ด้วยคำถามเดียวกัน แต่ไม่ควรได้รับคำตอบเหมือนกันเสมอไป ผู้จัดการฝ่ายขายอาจเข้าถึงเงื่อนไขส่วนลดของทีมตนเอง ขณะที่พนักงานทั่วไปควรเห็นเพียงนโยบายมาตรฐาน หากระบบค้นหาเอกสารทั้งหมดก่อนแล้วค่อยสร้างคำตอบ ความสะดวกอาจกลายเป็นช่องทางเปิดเผยข้อมูลข้ามสิทธิ์โดยไม่ตั้งใจ
โจทย์ของ RAG AI สำหรับองค์กรจึงไม่ใช่แค่ “ค้นหาให้แม่น” แต่ต้อง “ค้นหาเฉพาะสิ่งที่ผู้ถามมีสิทธิ์เห็น” ตั้งแต่ต้นทาง แนวคิดนี้เรียกว่า permission-aware retrieval หรือการดึงข้อมูลโดยคำนึงถึงสิทธิ์ผู้ใช้ ซึ่งเป็นองค์ประกอบสำคัญของ Enterprise Search ที่นำไปใช้จริงได้
ทำไมสิทธิ์ในระบบเดิมไม่ตามเข้า AI โดยอัตโนมัติ
RAG หรือ Retrieval-Augmented Generation คือวิธีให้ AI ค้นข้อมูลจากแหล่งความรู้ที่กำหนด แล้วนำข้อมูลที่พบมาใช้ประกอบคำตอบ แทนการพึ่งความรู้ทั่วไปของโมเดลเพียงอย่างเดียว กระบวนการนี้มักนำเอกสารมาแบ่งเป็นส่วนย่อยหรือ chunk ก่อนจัดทำดัชนีสำหรับค้นหา
จุดเสี่ยงเกิดขึ้นเมื่อระบบนำเนื้อหาจาก SharePoint, Google Drive, File Server, CRM หรือระบบงานอื่นมารวมไว้ในดัชนีเดียว แต่ไม่ได้ถ่ายทอดสิทธิ์ของต้นทางมาด้วย AI อาจค้นพบข้อความที่ผู้ใช้ไม่สามารถเปิดอ่านจากระบบต้นฉบับได้ แม้หน้าจอแชตจะมีระบบล็อกอินก็ตาม
ข้อมูลที่ต้องควบคุมไม่ได้มีเฉพาะเอกสารลับ แต่อาจรวมถึง:
- ข้อเสนอทางการค้าของลูกค้าแต่ละราย
- ข้อมูลบุคลากรและเอกสารประเมินผลงาน
- รายงานการเงินที่ยังไม่เผยแพร่ภายใน
- คู่มือเฉพาะตำแหน่งหรือเฉพาะสาขา
- สัญญาและเงื่อนไขที่จำกัดผู้รับรู้
ดังนั้น การมี Single Sign-On เพียงอย่างเดียวจึงยังไม่พอ ระบบต้องใช้ตัวตนของผู้ใช้ตัดสินใจในขั้นตอนค้นหาด้วย
โครงสร้างการค้นหาแบบเห็นข้อมูลเท่าที่มีสิทธิ์
การออกแบบที่เหมาะสมควรวางสิทธิ์เป็นส่วนหนึ่งของเส้นทางคำถาม ไม่ใช่ตรวจสอบหลัง AI สร้างคำตอบแล้ว กระบวนการหลักประกอบด้วยองค์ประกอบต่อไปนี้
ระบุตัวตนและบริบทของผู้ถาม
ระบบรับข้อมูล Identity จากบัญชีองค์กร เช่น ผู้ใช้ กลุ่มงาน แผนก ตำแหน่ง หรือหน่วยธุรกิจ จากนั้นแปลงข้อมูลเหล่านี้เป็นเงื่อนไขสำหรับการค้นหา ไม่ควรให้ผู้ใช้ระบุบทบาทของตนเองผ่านข้อความในแชต เพราะข้อความดังกล่าวไม่ใช่หลักฐานยืนยันสิทธิ์
ผูกสิทธิ์กับเอกสารและส่วนย่อย
เอกสารแต่ละรายการควรมี Metadata หรือข้อมูลกำกับ เช่น เจ้าของเอกสาร ระดับความลับ กลุ่มที่เข้าถึงได้ ประเทศ หรือสถานะเอกสาร หากเอกสารถูกแบ่งเป็น chunk สิทธิ์ควรติดตามไปกับแต่ละส่วน เพื่อป้องกันไม่ให้ข้อความบางตอนหลุดจากข้อจำกัดของเอกสารต้นฉบับ
กรองก่อนส่งข้อมูลให้โมเดล
ระบบควรทำ security trimming หรือการตัดผลลัพธ์ที่ผู้ใช้ไม่มีสิทธิ์ออก ก่อนส่งบริบทให้โมเดลสร้างคำตอบ หลักการที่ปลอดภัยคือ deny by default: หากระบุสิทธิ์ไม่ได้ ให้ไม่แสดงข้อมูลจนกว่าจะตรวจสอบได้ ไม่ควรหวังให้คำสั่ง Prompt บอก AI ว่า “ห้ามเปิดเผยข้อมูลลับ” เป็นแนวป้องกันหลัก
แสดงแหล่งอ้างอิงที่ผู้ใช้เปิดได้จริง
คำตอบควรเชื่อมกลับไปยังเอกสารต้นทาง และลิงก์อ้างอิงต้องผ่านการตรวจสิทธิ์เช่นเดียวกัน วิธีนี้ช่วยให้ผู้ใช้ตรวจสอบบริบท เวอร์ชัน และเจ้าของข้อมูลได้ โดยไม่สร้างประสบการณ์แบบเห็นชื่อเอกสารแต่เปิดไม่ได้
จากนโยบายบนกระดาษสู่ระบบที่ใช้งานได้
องค์กรไม่จำเป็นต้องเริ่มด้วยการเชื่อมข้อมูลทั้งหมดพร้อมกัน แนวทางที่ควบคุมความเสี่ยงได้ง่ายกว่าคือเลือกกรณีใช้งานที่ขอบเขตชัด เช่น ค้นหานโยบายภายในของฝ่ายปฏิบัติการ แล้วดำเนินการเป็นลำดับ
- จำแนกแหล่งข้อมูล: ระบุว่าเอกสารอยู่ที่ใด ใครเป็นเจ้าของ และสิทธิ์ปัจจุบันอ้างอิงจากผู้ใช้ กลุ่ม หรือคุณสมบัติใด
- กำหนดแบบจำลองสิทธิ์: ตัดสินใจว่าจะควบคุมระดับคลังข้อมูล โฟลเดอร์ เอกสาร หรือ chunk รวมถึงกำหนดกรณียกเว้นให้ชัดเจน
- ออกแบบการ Sync: เมื่อพนักงานย้ายทีม เอกสารถูกยกเลิก หรือสิทธิ์ต้นทางเปลี่ยน ดัชนีของ RAG ต้องอัปเดตตามในช่วงเวลาที่ธุรกิจยอมรับได้
- ทดสอบด้วยหลายบทบาท: ใช้คำถามเดียวกันกับบัญชีที่มีสิทธิ์ต่างกัน รวมถึงบัญชีที่ไม่ควรเห็นข้อมูล เพื่อยืนยันทั้งการค้นพบและการปฏิเสธ
- บันทึกเหตุการณ์: เก็บว่าใครถามอะไร ระบบค้นเอกสารใด ใช้แหล่งใดตอบ และเหตุใดผลลัพธ์บางรายการจึงถูกกรอง โดยกำหนดการเข้าถึง Log ให้เหมาะสม
เจ้าของโครงการควรประกอบด้วยฝ่ายธุรกิจ เจ้าของข้อมูล ทีม IT และผู้ดูแลความเสี่ยง เพราะทีมเทคนิคเพียงฝ่ายเดียวไม่สามารถตัดสินได้ว่าเอกสารใดควรเปิดให้บทบาทใด
ตัวชี้วัดที่สะท้อนทั้งประโยชน์และการควบคุม
การประเมิน RAG สำหรับค้นข้อมูลองค์กรไม่ควรดูเพียงความเร็วในการตอบ แต่ควรแยกอย่างน้อยสามมิติ
- Retrieval Quality: ระบบค้นพบเอกสารที่เกี่ยวข้อง ถูกเวอร์ชัน และเหมาะกับคำถามหรือไม่
- Access Correctness: ผู้มีสิทธิ์ค้นพบข้อมูลที่ควรเห็น และผู้ไม่มีสิทธิ์ไม่สามารถรับข้อมูลนั้นผ่านคำตอบหรือแหล่งอ้างอิง
- Operational Reliability: การเปลี่ยนสิทธิ์ การลบเอกสาร และการอัปเดตเนื้อหาสะท้อนเข้าสู่ระบบได้ตามกรอบการทำงานที่กำหนด
กรณีทดสอบควรครอบคลุมทั้ง false allow ซึ่งระบบยอมให้เห็นข้อมูลเกินสิทธิ์ และ false deny ซึ่งระบบปฏิเสธข้อมูลที่ผู้ใช้ควรเห็น ประเด็นแรกสร้างความเสี่ยง ส่วนประเด็นหลังลดการยอมรับและทำให้พนักงานกลับไปค้นหาแบบเดิม
Checklist ก่อนเปิดใช้ RAG AI กับข้อมูลหลายแผนก
- ระบบยืนยันตัวตนผ่านบัญชีองค์กรหรือไม่
- สิทธิ์จากแหล่งข้อมูลต้นทางถูกส่งมายังดัชนีครบหรือไม่
- การกรองเกิดก่อนข้อมูลถูกส่งให้โมเดลหรือไม่
- มีหลักการรับมือเอกสารที่ไม่มีเจ้าของหรือระบุสิทธิ์ไม่ได้หรือไม่
- สิทธิ์ที่เปลี่ยนแปลงถูกอัปเดตเข้าสู่ระบบอย่างไร
- คำตอบและแหล่งอ้างอิงผ่านกติกาเดียวกันหรือไม่
- มีชุดทดสอบสำหรับพนักงานต่างบทบาทและกรณีข้ามแผนกหรือไม่
- ผู้รับผิดชอบสามารถตรวจสอบเหตุการณ์ย้อนหลังได้หรือไม่
หากองค์กรกำลังประเมิน AI Knowledge Base ควรถามผู้ให้บริการให้ชัดว่าระบบเชื่อม Identity, Metadata และสิทธิ์ต้นทางอย่างไร รวมถึงรองรับการทดสอบและตรวจสอบย้อนหลังในระดับใด สำหรับ MXAI แนวทางการออกแบบ Private AI และ AI Knowledge Base สามารถนำองค์ประกอบเหล่านี้มาวางร่วมกับระบบและกระบวนการข้อมูลขององค์กร โดยขอบเขตที่เหมาะสมควรพิจารณาตามแหล่งข้อมูลและนโยบายจริงของแต่ละธุรกิจ
คำถามที่พบบ่อยเกี่ยวกับ RAG AI และสิทธิ์ข้อมูล
RAG AI ปลอดภัยทันทีหรือไม่หากใช้ข้อมูลภายในเท่านั้น
ไม่เสมอไป แม้ข้อมูลจะไม่ออกนอกองค์กร แต่ผู้ใช้ภายในอาจมีสิทธิ์ต่างกัน ระบบจึงยังต้องกรองข้อมูลตามตัวตนและบทบาทของผู้ถาม
การล็อกอินก่อนใช้ AI เพียงพอหรือไม่
การล็อกอินช่วยยืนยันว่าใครกำลังใช้งาน แต่ระบบต้องนำตัวตนนั้นไปตรวจสิทธิ์กับเอกสารระหว่างการค้นหาด้วย จึงจะควบคุมการเข้าถึงได้ครบกระบวนการ
ควรกำหนดสิทธิ์ระดับเอกสารหรือระดับ chunk
ขึ้นอยู่กับโครงสร้างข้อมูล หากทุกส่วนของเอกสารใช้สิทธิ์เดียวกัน ระดับเอกสารอาจเพียงพอ แต่เอกสารที่รวมข้อมูลหลายระดับควรแยกเนื้อหาและสิทธิ์ให้ละเอียดขึ้น
RAG AI ควรตอบอย่างไรเมื่อผู้ใช้ไม่มีสิทธิ์
ระบบควรหลีกเลี่ยงการยืนยันรายละเอียดของข้อมูลที่ถูกจำกัด และแจ้งอย่างเหมาะสมว่าไม่พบข้อมูลที่เข้าถึงได้ หรือแนะนำช่องทางขอสิทธิ์ตามกระบวนการองค์กร
ควรเริ่มโครงการจากข้อมูลประเภทใด
ควรเริ่มจากข้อมูลที่มีเจ้าของชัดเจน โครงสร้างสิทธิ์ไม่ซับซ้อน และมีคำถามทางธุรกิจที่เกิดขึ้นซ้ำ เพื่อให้ทดสอบคุณภาพการค้นหาและการควบคุมสิทธิ์ได้เป็นรูปธรรม
Key Takeaway: RAG AI ที่พร้อมใช้ในองค์กรต้องรู้ทั้ง “ข้อมูลใดตอบคำถามได้” และ “ข้อมูลใดผู้ถามมีสิทธิ์เห็น” จุดเริ่มต้นที่เหมาะสมจึงไม่ใช่การนำเอกสารทั้งหมดเข้า AI แต่คือการเลือกกระบวนการหนึ่ง ทำแผนที่สิทธิ์ให้ชัด และทดสอบคำถามเดียวกันผ่านผู้ใช้หลายบทบาทก่อนขยายระบบ