𝗚𝘂𝗮𝗿𝗱𝗿𝗮𝗶𝗹𝘀 𝗳𝗼𝗿 𝗘𝗻𝘁𝗲𝗿𝗽𝗿𝗶𝘀𝗲 𝗔𝗜 𝗔𝗴𝗲𝗻𝘁𝘀
คำแนะนำเรื่อง AI guardrails ส่วนใหญ่มักฟังดูเหมือนการขายของ ซึ่งมักจะเน้นไปที่แผนภาพสวยหรูและรายการตรวจสอบ (checklists)
ความปลอดภัยในการใช้งานจริง (production) นั้นไม่ได้ดูหรูหราขนาดนั้น แต่มันขึ้นอยู่กับสิ่งที่ดำรงอยู่มานานก่อนที่จะมี LLMs เสียอีก
ผมใช้เวลาสองปีในการสร้าง AI agents ให้กับบริษัทในกลุ่ม Fortune 100 โดย agents เหล่านี้ทำหน้าที่จัดการกับความล้มเหลวของ CI/CD, เหตุการณ์ผิดปกติใน Kubernetes และเอกสารโครงสร้างพื้นฐาน (infrastructure docs)
และนี่คือโครงสร้างแบบแบ่งชั้น (layered stack) ที่เราใช้เพื่อให้พวกมันปลอดภัย
การระบุตัวตนที่ขอบเขตของ agent (Identity at the agent boundary): ทุก agent จะใช้ workload identity และจะไม่ใช้ข้อมูลประจำตัว (credentials) ร่วมกัน ขอบเขตของ IAM คือเพดานความปลอดภัยของคุณ หาก agent ไม่จำเป็นต้องเข้าถึงฐานข้อมูล บทบาท (role) ของ IAM ก็ต้องไม่มีสิทธิ์นั้น นี่คือการควบคุมที่สำคัญที่สุดของคุณ
รายการเครื่องมือที่อนุญาต (Tool allow-lists): แพลตฟอร์มจะเป็นผู้ตัดสินว่า agent สามารถมองเห็นเครื่องมือใดได้บ้าง เช่น agent สำหรับค้นหาโค้ดไม่ควรมีเครื่องมือส่งอีเมล เราใช้การกำหนดค่าแบบคงที่ (static configs) สำหรับเรื่องนี้ และเราจะไม่ใช้การลงทะเบียนเครื่องมือแบบไดนามิก (dynamic tool registration)
การควบคุมการส่งข้อมูลออกทางเครือข่าย (Network egress controls): Agent จะเข้าถึงได้เฉพาะปลายทาง (endpoints) ที่อยู่ในรายการที่อนุญาตเท่านั้น เราใช้การกรอง DNS และ egress proxy เพื่อป้องกันไม่ให้การหลอนของโมเดล (model hallucinations) นำไปสู่การเรียกใช้งาน URL ที่ผิดพลาด
การแยกความลับออกจากกัน (Secrets isolation): Agent จะไม่เห็นความลับ (secrets) ในรูปแบบดิบ (raw) เราใช้ session tokens ที่มีอายุการใช้งานสั้นซึ่งจะถูกฉีดเข้าไปในระหว่างการเรียกใช้เครื่องมือ ห้ามใส่ความลับไว้ใน prompt โดยเด็ดขาด เพราะทุกอย่างที่อยู่ใน prompt สามารถถูกบันทึก (log) หรือนำมาเล่นซ้ำ (replay) ได้
บันทึกการตรวจสอบที่ครบถ้วน (Full audit trails): คุณต้องบันทึก (log) ทุกการเรียกใช้โมเดลและทุกการเรียกใช้เครื่องมือ ซึ่งรวมถึง input, output, อาร์กิวเมนต์ของเครื่องมือ (tool arguments) และตัวตนของผู้ใช้ คุณจำเป็นต้องมีสิ่งนี้เพื่อทำความเข้าใจว่าเกิดอะไรขึ้นผิดพลาดระหว่างเกิดเหตุการณ์ผิดปกติ
การอนุมัติโดยมนุษย์ (Human approval): สำหรับการดำเนินการใดๆ ที่มีการเปลี่ยนแปลงระบบบันทึกข้อมูลหลัก (system of record) แพลตฟอร์มจะต้องหยุดชะงักชั่วคราวเพื่อให้มนุษย์เป็นผู้อนุมัติการดำเนินการนั้น นี่คือตาข่ายนิรภัยของคุณ
หลีกเลี่ยงข้อผิดพลาดทั่วไปเหล่านี้:
คำสั่งในระดับ prompt: การบอกโมเดลว่า "ห้ามทำ X" ไม่ใช่การรักษาความปลอดภัย เพราะผู้ใช้สามารถหลอกล่อโมเดลได้ ควรย้ายการควบคุมไปไว้ที่ชั้น IAM หรือชั้นเครื่องมือแทน
ตัวกรอง PII แบบทั่วไป: ตัวกรองเหล่านี้มีอัตราความผิดพลาดสูง วิธีที่ดีกว่าคือการจำกัดการเข้าถึงข้อมูลผ่าน IAM เพื่อไม่ให้ agent มองเห็นข้อมูลที่ละเอียดอ่อน
โมเดล guardrail: การใช้ LLM ตัวที่สองมาประเมินตัวแรกจะทำให้เกิดความหน่วง (latency) และมันไม่ใช่การควบคุมความปลอดภัยที่แท้จริง แต่มันเป็นเพียงการใช้โมเดลร่วมกัน (model ensemble) เท่านั้น
บทเรียนที่ผมเรียนรู้ด้วยวิธีที่ยากลำบาก:
แก้ไข IAM ก่อน prompt: ผมเสียเวลาไปกับการปรับแต่ง prompt ทั้งที่จริงๆ แล้วผมควรจะไปเพิ่มความเข้มงวดให้กับบทบาท (roles) ของ IAM ควรย้ายการควบคุมไปไว้ในชั้นที่ต่ำที่สุดของ stack เท่าที่จะเป็นไปได้
สร้าง audit trail ให้ละเอียดและครอบคลุมกว่าปกติ การเก็บเพียงแค่ prompt และคำตอบนั้นไม่เพียงพอ คุณจำเป็นต้องเก็บข้อมูลการเรียกใช้เครื่องมือ (tool calls) และอาร์กิวเมนต์ (arguments) ระหว่างทางด้วย การบันทึกข้อมูล (log) ตั้งแต่เนิ่นๆ นั้นมีต้นทุนต่ำ แต่การตามแก้ไขภายหลังนั้นมีต้นทุนสูง
จำกัดการสื่อสารระหว่างเอเจนต์ ในระบบ multi-agent ควรมีการกำหนดเพดานสูงสุด (hard cap) สำหรับการเรียกใช้งานระหว่างเอเจนต์ (agent-to-agent calls) เพื่อป้องกันความล้มเหลวแบบต่อเนื่อง (cascading failures)
ความปลอดภัยของ AI ในระดับสเกลไม่ใช่ปัญหาของโมเดล แต่มันคือปัญหาของแพลตฟอร์ม จงดูแลเอเจนต์ของคุณด้วยวินัยในการปฏิบัติงาน (operational discipline) เช่นเดียวกับระบบ production อื่นๆ
ชุมชนการเรียนรู้เพิ่มเติม: https://t.me/GyaanSetuAi