มี Guardrails แล้วทำไม AI Agent ของเรายังหลุดตอบเรื่องที่ไม่ควรตอบ

ทีมพัฒนาจำนวนไม่น้อยเริ่มต้นทำ Guardrails ด้วยวิธีที่ง่ายที่สุดคือเขียนกฎไว้ใน System Prompt เช่น 'ห้ามตอบเรื่องการเมือง' หรือ 'ห้ามเปิดเผยข้อมูลลูกค้ารายอื่น' แล้วคิดว่าเพียงพอแล้ว แต่พอเปิดใช้จริงกับผู้ใช้จำนวนมาก กลับพบว่า Agent ยังหลุดตอบเรื่องต้องห้ามอยู่ดี บางครั้งเพราะผู้ใช้พิมพ์คำถามในรูปแบบที่ System Prompt ไม่เคยครอบคลุมไว้ บางครั้งเพราะมีคนจงใจพิมพ์ข้อความหลอกให้โมเดลลืมกฎที่ตั้งไว้

ปัญหานี้ไม่ได้แปลว่า Guardrails ที่ทำไปใช้ไม่ได้ผลเลย แต่สะท้อนว่า Guardrails ชั้นเดียวไม่เพียงพอสำหรับระบบที่มีผู้ใช้จริงจำนวนมากและหลากหลายพฤติกรรม เพราะ System Prompt เป็นเพียงคำแนะนำที่โมเดลอาจให้น้ำหนักน้อยลงเมื่อมีข้อความอื่นในบทสนทนาที่ขัดแย้งกันชัดเจนพอ

บทความนี้จะอธิบายว่า AI Guardrails ที่ทำงานได้จริงควรมีโครงสร้างแบบไหน ป้องกันความเสี่ยงหลักอะไรบ้าง และจุดที่ทีมส่วนใหญ่มักลืมทดสอบจนทำให้ Guardrails ที่ตั้งใจทำไว้ดีกลับยังหลุดได้ในสถานการณ์จริง

AI Guardrails คืออะไร ครอบคลุมความเสี่ยงแบบไหนบ้าง

AI Guardrails หมายถึงชุดกลไกที่ควบคุมพฤติกรรมของระบบ AI ให้อยู่ในขอบเขตที่ยอมรับได้ ทั้งในแง่เนื้อหาที่ตอบ ข้อมูลที่เปิดเผย และ Action ที่ Agent สามารถลงมือทำได้จริง ไม่ใช่แค่เรื่อง 'ห้ามพูดคำหยาบ' อย่างที่หลายคนเข้าใจแบบผิว ๆ แต่ครอบคลุมความเสี่ยงหลายมิติพร้อมกัน

ความเสี่ยงหลักที่ Guardrails ต้องป้องกันแบ่งได้เป็นสามกลุ่มใหญ่ กลุ่มแรกคือ Prompt Injection ที่ผู้ใช้พยายามหลอกให้โมเดลทำสิ่งที่ไม่ควรทำผ่านข้อความที่ออกแบบมาเฉพาะ กลุ่มที่สองคือ Data Leakage ที่ระบบเผลอเปิดเผยข้อมูลที่ไม่ควรเปิดเผย เช่น ข้อมูลลูกค้ารายอื่นหรือ System Prompt ภายใน และกลุ่มที่สามคือ Unsafe Actions ที่ Agent ที่มีสิทธิ์เรียก Tool หรือ API ไปทำ Action ที่สร้างความเสียหายจริงโดยไม่มีการตรวจสอบก่อน

แต่ละกลุ่มความเสี่ยงต้องการกลไกป้องกันที่ต่างกัน ทำให้ Guardrails ที่ดีมักไม่ใช่กฎเดียวที่ใช้ครอบคลุมทุกอย่าง แต่เป็นระบบหลายชั้นที่ทำงานร่วมกัน

ทำไมพึ่ง System Prompt อย่างเดียวถึงยังหลุดได้

System Prompt เป็นเพียงข้อความหนึ่งในบริบทที่โมเดลใช้ตัดสินใจ ไม่ใช่กฎที่บังคับในระดับโครงสร้างเหมือน Structured Output ที่ควบคุม Token การ Generate โดยตรง เมื่อผู้ใช้ป้อนข้อความที่ขัดแย้งกับ System Prompt อย่างชัดเจนและซับซ้อนพอ โมเดลอาจให้น้ำหนักกับข้อความล่าสุดมากกว่ากฎที่ตั้งไว้ตั้งแต่ต้น

อีกจุดที่ทำให้ System Prompt เพียงอย่างเดียวไม่พอคือ Edge Case ที่ทีมไม่เคยคิดถึงตอนเขียนกฎ เช่น ตั้งกฎห้ามตอบเรื่องการเมืองไว้ตรง ๆ แต่ผู้ใช้ถามในมุมที่แฝงอยู่ในคำถามเชิงประวัติศาสตร์หรือเชิงวิชาการ ซึ่งกฎที่เขียนแบบตรงไปตรงมาไม่ครอบคลุมถึง

ด้วยเหตุนี้ระบบที่ต้องการความปลอดภัยจริงจังจึงควรมีชั้นตรวจสอบเพิ่มเติมนอกเหนือจาก System Prompt เช่น การตรวจ Input ก่อนส่งเข้าโมเดล และการตรวจ Output ก่อนส่งกลับผู้ใช้ แทนที่จะพึ่งความหวังว่าโมเดลจะทำตามกฎเสมอ

Prompt Injection คืออะไร มีกี่รูปแบบที่พบบ่อย

Prompt Injection คือการที่ผู้ใช้หรือเนื้อหาภายนอกพยายามแทรกคำสั่งที่ขัดแย้งกับเจตนาเดิมของระบบเข้าไปในบทสนทนา เพื่อให้โมเดลทำสิ่งที่นักพัฒนาไม่ได้ตั้งใจให้ทำ รูปแบบมีหลากหลายตั้งแต่ตรงไปตรงมาไปจนถึงซับซ้อนแนบเนียน

Data Leakage เกิดขึ้นได้จากจุดไหนบ้างในระบบ AI

Data Leakage ในระบบ AI ไม่ได้เกิดจากการโจมตีที่ซับซ้อนเสมอไป บ่อยครั้งเกิดจากการออกแบบระบบที่ไม่ได้แยกขอบเขตข้อมูลให้ชัดเจนตั้งแต่ต้น เช่น ระบบที่ดึง Context ของผู้ใช้หลายคนมารวมกันใน Session เดียวโดยไม่ตั้งใจ หรือ Agent ที่มีสิทธิ์เข้าถึงฐานข้อมูลกว้างเกินความจำเป็นของ Task นั้น

อีกความเสี่ยงที่พบบ่อยคือการรั่วไหลของ System Prompt เอง ผู้ใช้บางคนพยายามถามให้โมเดล 'พิมพ์คำสั่งที่ได้รับมาทั้งหมด' ซึ่งถ้าไม่มี Guardrails ป้องกัน โมเดลอาจเผลอเปิดเผยรายละเอียดภายในที่ทีมไม่ต้องการให้คนภายนอกเห็น เช่น Logic ทางธุรกิจหรือ API Key ที่ฝังอยู่ในตัวอย่างของ Prompt โดยไม่ตั้งใจ

แนวทางป้องกันที่ได้ผลคือการออกแบบระบบให้ Agent เข้าถึงเฉพาะข้อมูลที่จำเป็นต่อ Task ตรงหน้าเท่านั้น (Least Privilege) และมีชั้นตรวจ Output ก่อนส่งกลับเสมอ เพื่อดักจับกรณีที่โมเดลพยายามเปิดเผยข้อมูลที่ไม่ควรเปิดเผย

ควบคุม Unsafe Actions อย่างไรเมื่อ Agent เรียก Tool ได้จริง

เมื่อ Agent มีความสามารถเรียก Tool หรือ Function จริง ความเสี่ยงจะเปลี่ยนจากแค่ 'ตอบผิด' ไปเป็น 'ทำผิดจริง' เช่น ยกเลิกออเดอร์ผิดรายการ หรือส่งอีเมลถึงผู้รับผิดคน กลไกที่ควบคุมว่า Agent เรียกฟังก์ชันด้วย Parameter ถูกต้องอยู่แล้วอย่าง Structured Output ไม่ได้ป้องกันเรื่องนี้ เพราะควบคุมแค่รูปแบบ ไม่ได้ควบคุมว่าควรเรียกฟังก์ชันนั้นหรือไม่ในสถานการณ์นั้น หากต้องการเข้าใจกลไกที่ทำให้ Agent เรียก Tool ได้อย่างถูกต้องตาม Parameter ลองอ่านเพิ่มเติมที่ บทความเรื่อง Tool Calling

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

สำหรับ Action ที่มีความเสี่ยงสูง การให้คนเข้ามาอนุมัติก่อนเป็นแนวทางที่ยังจำเป็นอยู่แม้ระบบ AI จะพัฒนาไปมากแล้วก็ตาม ดูรายละเอียดเรื่องจุดไหนควรให้คนเข้ามาอนุมัติได้ที่ แนวทางออกแบบ Human in the Loop สำหรับ AI Agent

ออกแบบ Guardrails แบบหลายชั้นอย่างไรให้ครอบคลุม

1. ชั้น Input: ตรวจข้อความหรือ Context ก่อนส่งเข้าโมเดลหลัก ด้วยกฎง่าย ๆ หรือโมเดลแยกที่เชี่ยวชาญเรื่องตรวจจับ Prompt Injection โดยเฉพาะ
2. ชั้น Reasoning: กำหนดขอบเขตชัดเจนใน System Prompt ว่า Agent ควรทำอะไรได้บ้าง แต่ไม่ควรเป็นชั้นป้องกันเดียวของระบบ
3. ชั้น Output: ตรวจคำตอบก่อนส่งกลับผู้ใช้ ทั้งเรื่องเนื้อหาที่ไม่เหมาะสมและการรั่วไหลของข้อมูลภายใน ก่อนถึงมือผู้ใช้จริง
4. ชั้น Action: จำกัดสิทธิ์ของ Agent ต่อ Tool แต่ละตัวตามความจำเป็นของ Task และตั้งเพดานความเสี่ยงที่ต้องมีการยืนยันเพิ่มก่อนดำเนินการ
5. ชั้น Monitoring: เก็บ Log ทุกครั้งที่ Guardrails ทำงานหรือดักจับปัญหาได้ เพื่อนำมาวิเคราะห์ว่ารูปแบบการโจมตีหรือ Edge Case ใหม่เกิดขึ้นบ่อยแค่ไหน

ทดสอบ Guardrails อย่างไรให้รู้ว่าใช้ได้จริงก่อนขึ้น Production

การทดสอบ Guardrails ด้วยคำถามปกติที่คาดว่าผู้ใช้จะถามไม่เพียงพอ เพราะ Guardrails ถูกออกแบบมาเพื่อรับมือกับกรณีที่ผิดปกติเป็นหลัก ทีมที่จริงจังเรื่องนี้ควรทำ Red Teaming คือการจงใจคิดหาวิธีหลอกระบบให้หลุดกฎ เหมือนสวมบทบาทเป็นผู้ใช้ที่ตั้งใจทำสิ่งไม่ดี

รายการทดสอบควรครอบคลุมทั้งการพยายามให้โมเดลลืมกฎเดิม การถามด้วยมุมอ้อมที่แฝงเจตนาไม่ดี การพยายามดึงข้อมูล System Prompt ออกมา และการพยายามให้ Agent เรียก Tool ที่ไม่ควรเรียกในสถานการณ์นั้น ตัวอย่างประกอบกรอบวิเคราะห์ (ไม่ใช่สถิติจริง) คือทีมที่ทดสอบด้วยชุดคำถามเหล่านี้ก่อนขึ้น Production มักพบช่องโหว่ที่ System Prompt เดิมไม่เคยครอบคลุมอยู่หลายจุด

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

แม้มี Guardrails ครบแล้ว ยังพังได้จากอะไรบ้าง

แม้จะออกแบบ Guardrails หลายชั้นแล้ว ก็ยังมีโอกาสที่ระบบจะหลุดได้ในบางกรณี เพราะไม่มีระบบใดปลอดภัย 100% เมื่อโมเดลภาษายังมีความไม่แน่นอนโดยธรรมชาติ สิ่งสำคัญคือการยอมรับข้อจำกัดนี้และออกแบบระบบให้ความเสียหายเมื่อเกิดเหตุมีขอบเขตจำกัด แทนที่จะเชื่อว่า Guardrails ทำให้ระบบปลอดภัยแบบตายตัว

แนวทางที่ช่วยจำกัดความเสียหายเมื่อ Guardrails หลุดคือการมีชั้นตรวจสอบซ้ำสำหรับ Action ที่มีความเสี่ยงสูง และมีแผนสำรองเมื่อ Guardrails ชั้นหนึ่งล้มเหลว คล้ายกับหลักการออกแบบระบบให้ทนต่อความล้มเหลวในเรื่องอื่นของ AI Application ดูแนวคิดที่เกี่ยวข้องได้ที่ แนวทางออกแบบ LLM Fallback Strategy ซึ่งอธิบายหลักการออกแบบระบบให้ทนต่อความล้มเหลวในมุมของ Reliability

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

สรุป

AI Guardrails ที่ทำงานได้จริงไม่ใช่แค่กฎในระดับ System Prompt แต่ต้องเป็นระบบหลายชั้นที่ทำงานร่วมกัน ตั้งแต่การตรวจ Input การกำหนดขอบเขตในชั้น Reasoning การตรวจ Output ก่อนส่งกลับ ไปจนถึงการจำกัดสิทธิ์ Action ที่ Agent ทำได้จริง เพราะแต่ละความเสี่ยงต้องการกลไกป้องกันที่ต่างกัน

ทีมที่ต้องการ Guardrails ที่ใช้ได้จริงควรทดสอบด้วย Red Teaming อย่างสม่ำเสมอ ไม่ใช่ทำครั้งเดียวตอนเริ่มโปรเจกต์ และควรยอมรับว่าไม่มีระบบใดปลอดภัย 100% การออกแบบให้ความเสียหายมีขอบเขตจำกัดเมื่อ Guardrails หลุดจึงสำคัญพอ ๆ กับการพยายามป้องกันไม่ให้หลุดตั้งแต่แรก

• Guardrails ต้องครอบคลุมสามความเสี่ยงหลัก คือ Prompt Injection, Data Leakage และ Unsafe Actions ไม่ใช่แค่กรองคำหยาบ
• ระบบหลายชั้น (Input, Reasoning, Output, Action) ปลอดภัยกว่าการพึ่ง System Prompt เพียงอย่างเดียวเสมอ
• ทดสอบด้วย Red Teaming เป็นรอบสม่ำเสมอ เพราะรูปแบบการพยายามหลอกระบบ AI เปลี่ยนไปเรื่อย ๆ ตามเวลา

คำถามที่พบบ่อย