สมมุติพนักงานถาม AI ว่า:
“ยอดขายเดือนนี้เป็นเท่าไร?”
AI อาจนำคำถามไปสร้างหรือเลือกคำสั่ง SQL ดึงข้อมูลจาก Database แล้วสรุปคำตอบกลับมาในไม่กี่วินาที
ดูเหมือนเป็นงานธรรมดาและมีประโยชน์มาก
แต่ถ้าผู้ใช้ถามต่อว่า:
“ขอรายชื่อพนักงานพร้อมเงินเดือนทั้งหมด”
AI ควรตอบได้หรือไม่?
หลายองค์กรอาจคิดว่า ถ้าให้ AI ใช้ Database Account แบบ Read-only ก็น่าจะปลอดภัย เพราะ AI แก้ไขหรือลบข้อมูลไม่ได้
แต่ Read-only ตอบเพียงคำถามว่า:
AI แก้ข้อมูลได้หรือไม่?
มันยังไม่ได้ตอบคำถามว่า:
AI ควรอ่านข้อมูลอะไรได้บ้าง?
นี่คือจุดเริ่มต้นของการออกแบบสิทธิ์ให้ AI เมื่อองค์กรต้องการให้ AI ทำงานกับข้อมูลจริง
Read-only ช่วยได้ แต่ยังไม่ใช่คำตอบทั้งหมด
การให้ AI อ่านข้อมูลอย่างเดียว ปลอดภัยกว่าการอนุญาตให้แก้ไขหรือลบข้อมูลทันที
อ่านข้อมูล ได้
เพิ่มข้อมูล ไม่ได้
แก้ข้อมูล ไม่ได้
ลบข้อมูล ไม่ได้สิทธิ์แบบนี้ช่วยลดความเสี่ยงที่ AI จะเปลี่ยนแปลงข้อมูลโดยไม่ตั้งใจ แต่ยังมีคำถามต่อว่า AI สามารถอ่านข้อมูลจากที่ใดได้บ้าง เรื่องนี้ต่อเนื่องจากคำถามที่ว่า เราอาจให้ AI เห็นข้อมูลมากกว่าที่คิดหรือไม่ เพราะเมื่อ AI เชื่อมต่อกับ Database ขอบเขตของสิ่งที่ AI มองเห็นจะไม่ได้ขึ้นอยู่กับไฟล์ที่เราส่งให้เท่านั้น แต่ยังขึ้นอยู่กับสิทธิ์ของระบบที่อยู่ด้านหลังด้วย
ถ้าบัญชี Read-only อ่านได้ทุกตาราง มันอาจเห็นทั้งยอดขาย ข้อมูลลูกค้า ข้อมูลพนักงาน เงินเดือน สัญญา ประวัติการชำระเงิน และข้อมูลภายในฝ่ายบริหาร
AI อาจไม่สามารถแก้ข้อมูลเหล่านี้ได้ แต่ยังสามารถอ่าน สรุป เปรียบเทียบ หรือนำข้อมูลหลายส่วนมารวมกันได้
Read-only จำกัดสิ่งที่ AI ทำกับข้อมูล แต่ไม่ได้จำกัดว่าข้อมูลใดที่ AI มองเห็น
คำว่า “อ่านอย่างเดียว” จึงควรเป็นเพียงจุดเริ่มต้นของการกำหนดสิทธิ์ ไม่ใช่คำตอบสุดท้ายของเรื่องความปลอดภัย
AI ไม่จำเป็นต้องรู้ Password ก็เข้าถึงข้อมูลได้
เมื่อพูดถึง AI เชื่อมต่อ Database หลายคนอาจนึกว่า AI ต้องมี Username และ Password ของ Database โดยตรง
แต่ในระบบจริง AI อาจเข้าถึงข้อมูลผ่าน Application, API หรือ Tool ที่องค์กรเตรียมไว้
User
↓
AI
↓
Application / API / Tool
↓
Databaseตัวอย่างเช่น Tool สำหรับดูยอดขาย, API สำหรับค้นหาข้อมูลลูกค้า, ระบบรายงานภายใน หรือ Service สำหรับตรวจสอบคำสั่งซื้อ
ดังนั้นคำถามสำคัญไม่ใช่เพียง “AI มี Password ของ Database หรือไม่?” แต่ต้องถามว่า:
เครื่องมือที่ AI ใช้ สามารถเข้าถึงข้อมูลอะไรได้บ้าง?
ถ้า API ที่อยู่หลัง AI สามารถดึงข้อมูลลูกค้าได้ทั้งหมด AI ก็อาจเข้าถึงข้อมูลเหล่านั้นได้ แม้ตัว AI จะไม่รู้ Password ของ Database เลยก็ตาม
Prompt ไม่ใช่กำแพงรักษาความปลอดภัยชั้นสุดท้าย
เราสามารถกำหนดกติกาให้ AI ได้ เช่น:
ห้ามแสดงข้อมูลเงินเดือน
ห้ามดึงข้อมูลส่วนบุคคล
ตอบเฉพาะคำถามเกี่ยวกับยอดขายกติกาเหล่านี้มีประโยชน์ เพราะช่วยบอกขอบเขตและพฤติกรรมที่เราต้องการ แต่ไม่ควรเป็นกลไกเดียวที่ใช้ป้องกันข้อมูล
Prompt:
ห้ามแสดงข้อมูลเงินเดือน
สิทธิ์ของระบบ:
อ่านตารางเงินเดือนได้ทั้งหมดถ้า AI เข้าใจคำสั่งผิด มีคำสั่งอื่นเข้ามาเปลี่ยนบริบท หรือเลือกใช้เครื่องมือผิด ระบบชั้นหลังก็ยังเปิดทางให้อ่านข้อมูลเงินเดือนอยู่
ขอบเขตจริงจึงควรถูกบังคับโดยระบบด้วย เช่น Account ที่จำกัดสิทธิ์, Role ตามหน้าที่, View ที่เปิดเฉพาะข้อมูลจำเป็น, API ที่ตรวจสอบสิทธิ์ และการบันทึกการใช้งาน ซึ่งล้วนเป็นส่วนหนึ่งของ การดูแลและบริหารจัดการฐานข้อมูลระดับองค์กร
สร้างสิทธิ์ให้ตรงกับงาน แทนการให้สิทธิ์กว้างแล้วหวังว่า AI จะไม่ใช้
Prompt ควรเป็นหนึ่งในชั้นควบคุม แต่ไม่ควรเป็นกุญแจล็อกประตูเพียงดอกเดียว
ไม่จำเป็นต้องให้ AI เห็นตารางจริงทั้งหมด
สมมุติ AI มีหน้าที่ตอบคำถามเกี่ยวกับยอดขายรายเดือน ตารางจริงอาจมีชื่อและรหัสลูกค้า อีเมล เบอร์โทรศัพท์ ที่อยู่ สินค้า ยอดขาย และข้อมูลการชำระเงิน
แต่การสรุปยอดขายอาจต้องใช้เพียงเดือน สินค้า จำนวน ยอดขาย และภูมิภาค
แทนที่จะให้ AI อ่านตารางจริงทั้งหมด องค์กรอาจเตรียม View, API หรือชุดข้อมูลที่แสดงเฉพาะส่วนที่จำเป็นสำหรับงานนั้น
จากมุมมองของ AI มันยังตอบคำถามเรื่องยอดขายได้ตามปกติ แต่ต่อให้มีคนถามหาหมายเลขโทรศัพท์ลูกค้า ข้อมูลดังกล่าวก็ไม่มีอยู่ในสิ่งที่ AI ได้รับอนุญาตให้เห็นตั้งแต่ต้น
อย่าส่งข้อมูลทั้งหมด แล้วค่อยสั่ง AI ว่าอะไรห้ามใช้
ถ้าเป็นไปได้ ให้ AI เข้าถึงเฉพาะข้อมูลที่อนุญาตตั้งแต่แรก
ผู้ใช้ต่างกัน AI ก็ควรเห็นข้อมูลต่างกัน
พนักงานฝ่ายขายอาจถามยอดขายของลูกค้าที่ตนดูแล ผู้จัดการถามยอดขายของทีม ส่วนผู้บริหารถามยอดขายรวมทุกภูมิภาค
ทั้งสามคนใช้ AI ตัวเดียวกัน แต่ไม่จำเป็นต้องเห็นข้อมูลระดับเดียวกัน
ระบบจึงควรตอบให้ได้ว่าใครเป็นผู้ถาม มีหน้าที่อะไร มีสิทธิ์เห็นข้อมูลระดับไหน AI กำลังทำงานแทนบุคคลนั้นจริงหรือไม่ และระบบชั้นหลังตรวจสอบสิทธิ์อีกครั้งหรือไม่
ถ้าตรวจเพียงว่า “AI มีสิทธิ์ใช้ Tool นี้” แต่ไม่ตรวจว่า “ผู้ใช้คนนี้มีสิทธิ์ได้รับข้อมูลหรือไม่” AI อาจกลายเป็นทางลัดให้ผู้ใช้เข้าถึงข้อมูลเกินสิทธิ์เดิมของตนเองได้
อย่าให้ AI ใช้บัญชีที่มีสิทธิ์กว้างเพียงเพราะสะดวก
ในช่วงทดลองอาจมีความคิดว่า “ใช้ DBA Account หรือบัญชีของ Application เดิมไปก่อน จะได้ไม่ติดเรื่อง Permission”
วิธีนี้ช่วยให้ Demo เริ่มง่าย แต่ทำให้ AI ได้สิทธิ์มากเกินกว่างานจริง
ควรแยก Account หรือ Service ตามหน้าที่ เพื่อจำกัดข้อมูล ปรับหรือตัดสิทธิ์ได้ง่าย แยกการใช้งานของ AI ออกจากคน และตรวจสอบได้ว่า Query ใดมาจากระบบใด
ไม่ได้หมายความว่า AI ทุกตัวต้องมี Database Account ของตัวเองเสมอไป แต่ระบบควรระบุได้ว่า AI ตัวใดกำลังทำงาน ผ่าน Tool ใด และได้รับสิทธิ์ในฐานะอะไร
ข้อมูลแต่ละส่วนอาจดูธรรมดา แต่เมื่อรวมกันอาจไม่ธรรมดา
บางครั้งไม่มีตารางใดดูอ่อนไหวเป็นพิเศษ แต่เมื่อ AI อ่านหลายแหล่งและนำมารวมกัน อาจคาดเดาได้ว่าองค์กรกำลังเริ่มโครงการใหม่ แผนกใดถูกลดงบประมาณ หรือผู้บริหารกำลังเจรจากับคู่ค้ารายใด
จึงควรถามเพิ่มว่า:
เมื่อ AI นำข้อมูลหลายชุดมารวมกัน มันสามารถสร้างหรืออนุมานข้อมูลอะไรเพิ่มได้บ้าง?
ถ้าเกิดปัญหา เราตรวจย้อนหลังได้หรือไม่?
ถ้า AI ตอบข้อมูลลูกค้าผิดคนหรือดึงข้อมูลที่ผู้ใช้ไม่ควรเห็น องค์กรควรตรวจได้ว่าใครส่งคำถาม AI ตัวใดรับงาน ใช้ Tool หรือ API ใด Query ข้อมูลส่วนไหน ใช้ Account ใด และส่งผลลัพธ์ให้ใคร
Database Log, Application Log และ AI/Agent Log อาจเก็บเหตุการณ์คนละส่วน สิ่งสำคัญคือข้อมูลเหล่านี้ต้องเชื่อมโยงกันได้มากพอที่จะประกอบเหตุการณ์ย้อนหลัง
AI ที่เข้าถึงข้อมูลจริงควรทิ้งร่องรอยเพียงพอให้ตรวจสอบได้ว่าเกิดอะไรขึ้น
ก่อนเชื่อม AI กับ Database ลองถาม 7 ข้อ
- AI ตัวนี้มีหน้าที่อะไร?
- งานนั้นจำเป็นต้องใช้ข้อมูลอะไร?
- ใช้ View, API หรือชุดข้อมูลที่จำกัดขอบเขตแทนตารางจริงได้หรือไม่?
- ผู้ใช้แต่ละคนควรเห็นข้อมูลระดับเดียวกันหรือไม่?
- AI ใช้ Account หรือสิทธิ์ของใคร?
- Query และการใช้ Tool ถูกบันทึกไว้หรือไม่?
- งานใดต้องให้คนอนุมัติก่อน?
ถ้ายังตอบบางข้อไม่ได้ ไม่ได้หมายความว่าองค์กรต้องหยุดใช้ AI แต่อาจต้องให้มีการเตรียมบุคลากรก่อนนำ AI มาใช้กับข้อมูล โดยเริ่มจาก Use Case ที่แคบ ข้อมูลที่ไม่อ่อนไหว และสิทธิ์ที่จำกัดก่อน แล้วค่อยเพิ่มเมื่อพิสูจน์ได้ว่าจำเป็นจริง
สรุป
เมื่อ AI เชื่อมต่อกับ Database คำถามสำคัญไม่ใช่เพียง “AI เชื่อมต่อ Database ได้หรือไม่?” แต่ต้องถามว่า:
AI ควรเห็นข้อมูลอะไร ใช้สิทธิ์ของใคร และเราตรวจย้อนหลังได้หรือไม่?
Read-only เป็นจุดเริ่มต้นที่ดี แต่ยังไม่เพียงพอ หาก Account นั้นอ่านข้อมูลได้กว้างเกินกว่างานที่ได้รับมอบหมาย
Prompt ช่วยกำหนดพฤติกรรมได้ แต่ไม่ควรแทนที่ Permission และ Authorization ของระบบจริง และการที่ AI อ่านข้อมูลได้ ไม่ได้หมายความว่าผู้ใช้ทุกคนควรได้รับคำตอบจากข้อมูลทั้งหมดนั้น
อย่าเริ่มจากการให้ AI เห็นทุกอย่าง แล้วค่อยสั่งว่าอะไรห้ามใช้
ให้เริ่มจากงานที่ต้องทำ แล้วเปิดเฉพาะข้อมูลและสิทธิ์ที่งานนั้นจำเป็นต้องใช้
นี่คือหลัก Least Privilege แบบเดิมที่ยิ่งสำคัญขึ้น เมื่อผู้ใช้งาน Database เริ่มรวมถึง AI ที่สามารถเลือกข้อมูล ใช้เครื่องมือ และทำงานหลายขั้นตอนได้ด้วย
ต้องการนำเรื่องนี้ไปใช้กับทีมในองค์กร?
เรื่องนี้เป็นส่วนหนึ่งของหลักสูตร “การใช้ AI และข้อมูลในองค์กรอย่างปลอดภัย” ซึ่งออกแบบสำหรับพนักงาน ผู้จัดการ เจ้าของระบบ และทีมที่กำลังนำ AI มาใช้กับข้อมูลขององค์กร โดยไม่จำเป็นต้องมีพื้นฐานด้านเทคนิค
ดูรายละเอียดหลักสูตร AI สำหรับองค์กร