An AI-driven support system thought to be locked down at the model-output stage was leaking customer data through the “side door” that feeds CRM records into the prompt. The creator’s post-mortem shows that protecting only the text the model generates isn’t enough – the inbound request, the data fetched from internal tools, and the final emission all need independent safeguards, or a business can expose names, emails and IDs without ever seeing a model-output breach.

ทำไมขอบเขตทั้งสามจึงมีความสำคัญ

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

  • Ingress (ขาเข้า) – คำถามดิบที่ลูกค้าพิมพ์เข้ามา
  • Return path (เส้นทางส่งคืน) – ข้อมูลที่ agent ดึงมาจากระบบปลายทาง เช่น CRM
  • Emission (การแสดงผล) – ข้อความที่โมเดลส่งกลับไปยังผู้ใช้

หากช่องทางใดช่องทางหนึ่งมีข้อมูลระบุตัวตนที่ไม่มีการป้องกัน agent อาจนำข้อมูลเหล่านั้นไปใส่ไว้ในคำตอบโดยไม่ตั้งใจ แม้ว่าจะมีตัวกรองในชั้นการแสดงผล (output layer) แล้วก็ตาม

จากเดโมสู่การใช้งานจริง: บทเรียนที่แลกมาด้วยความยากลำบาก

การเปลี่ยนจากตัวต้นแบบ (prototype) ไปสู่ระบบ help desk ที่ใช้งานจริง เผยให้เห็นความล้มเหลวที่เป็นรูปธรรม ซึ่งวิธีการแบบ "ปกปิดข้อมูลแล้วค่อยส่ง" (redact-then-send) แบบง่ายๆ ไม่สามารถตรวจพบได้

  • ใช้การ Tokenize แทนการปกปิดข้อมูล (Redact) – การลบชื่อหรืออีเมลออกก่อนที่ข้อมูลจะถึงโมเดล จะทำให้ระบบไม่สามารถสร้างคำตอบที่ถูกต้องได้ วิธีที่ควรทำคือ เก็บค่าเดิมไว้ในคลังข้อมูลที่ปลอดภัย (secure vault) แล้วแทนที่ด้วย UUID แบบสุ่มในพรอมต์ จากนั้นจึงเปลี่ยน UUID กลับเป็นค่าเดิมหลังจากโมเดลทำงานเสร็จ วิธีนี้จะช่วยกันข้อมูลดิบออกจากบริบท (context) ของโมเดลในขณะที่ยังคงรักษาฟังก์ชันการทำงานไว้ได้

  • ตรวจสอบข้อมูลระบุตัวตนด้วย Checksum – Regular expression (Regex) สามารถตรวจจับข้อความที่ดูเหมือนเลขบัญชีได้ แต่ Checksum จะช่วยยืนยันว่าเป็น ID จริงหรือไม่ ตัวกรองแบบ Checksum จะช่วยป้องกันไม่ให้ agent ปฏิบัติต่อตัวเลขทั่วไปเสมือนเป็นข้อมูลที่ละเอียดอ่อน ซึ่งช่วยลดความผิดพลาด (false positives) ที่จะนำไปสู่การปกปิดข้อมูลโดยไม่จำเป็น

  • รวมส่วนที่ซ้อนทับกัน (Merge overlapping spans) – บันทึกข้อมูลลูกค้ามักมีชื่อตามด้วยที่อยู่อีเมลที่มีตัวอักษรร่วมกัน (เช่น “John Doe john.doe@example.com”) หากทำ Tokenize เฉพาะชื่อ จะทำให้เศษเสี้ยวของอีเมลยังคงเป็นข้อความปกติ (clear text) ซึ่งอาจถูกแสดงผลออกมาได้ ดังนั้นควรจัดการกับพื้นที่ที่ซ้อนทับกันทั้งหมดให้เป็น token เดียวกัน

  • ทดสอบให้ถูกขอบเขต – การทดสอบที่ผ่านเพียงเพราะตรวจสอบแค่ชั้นการแสดงผล (emission layer) จะทำให้เกิดความรู้สึกปลอดภัยที่ผิดพลาด การทดสอบที่ล้มเหลวและตรวจพบการรั่วไหลในเส้นทางส่งคืน (return path) จะช่วยบีบให้ต้องมีการแก้ไข ควรออกแบบชุดการทดสอบ (test suites) ที่ตรวจสอบขอบเขตทั้งสามอย่างชัดเจน

  • ติดตามค่าความจริง (Ground truth) – เมื่อมนุษย์แก้ไขร่างที่ AI สร้างขึ้นก่อนจะส่งออกไป นั่นหมายความว่าโมเดลได้สร้างคำตอบที่ผิดพลาดออกมาแล้ว การเปรียบเทียบระหว่างร่างของ AI กับข้อความสุดท้ายที่มนุษย์อนุมัติ จะช่วยให้เห็นช่องว่างของความมั่นใจ (confidence gaps) และป้องกันไม่ให้ระบบเรียนรู้ที่จะทำผิดซ้ำเดิม

ความเสี่ยงสำหรับธุรกิจ

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

ข้อโต้แย้ง: ทำไมบางคนยังคงนิยมการปกปิดข้อมูล (Redaction)

บทสรุป

การรักษาความปลอดภัยให้กับ AI-powered customer-service agent นั้นไม่ใช่ปัญหาแบบประตูเดียว จงปฏิบัติกับคำขอขาเข้า, ข้อมูลที่ดึงมาจากระบบภายใน และข้อความขาออก เสมือนเป็นกำแพงที่แยกจากกัน หากกำแพงใดกำแพงหนึ่งถูกเจาะ บริการทั้งหมดก็จะตกอยู่ในความเสี่ยง การทำ Tokenize ฟิลด์ที่ละเอียดอ่อน, การตรวจสอบข้อมูลระบุตัวตน, การรวมส่วนที่ซ้อนทับกัน, การทดสอบขอบเขตที่ถูกต้อง และการเปรียบเทียบร่างของ AI กับข้อความสุดท้ายของมนุษย์อย่างต่อเนื่อง คือขั้นตอนที่นำไปสู่การเปลี่ยนจาก "copilot" ให้กลายเป็นบริการแบบ agentic ที่น่าเชื่อถือ