Usage policy là "luật giao thông" của agent: nó nói rõ agent được làm gì, cấm làm gì, và làm sao khi gặp trường hợp mập mờ. Chính sách tốt phải vừa là văn bản cho con người đọc, vừa dịch được thành ràng buộc kỹ thuật (system prompt, guardrail, tool permission).
Ba lớp của một usage policy
- Allowed (Được phép): phạm vi hành động hợp lệ.
- Prohibited (Cấm tuyệt đối): ranh giới đỏ, không có ngoại lệ.
- Escalation (Chuyển tiếp): khi nào dừng và chuyển cho con người.
Ví dụ cụ thể: agent tư vấn bảo hiểm
- Được phép: giải thích sản phẩm, so sánh gói, tính phí sơ bộ.
- Cấm: cam kết chi trả bồi thường, tư vấn né thuế, tạo hợp đồng ràng buộc pháp lý.
- Escalation: khi khách hỏi về khiếu nại bồi thường → chuyển agent người thật.
Các bước xây dựng chính sách
- Bắt đầu từ rủi ro, không từ tính năng. Hỏi: "Điều tệ nhất agent này có thể gây ra là gì?" rồi viết luật chặn điều đó.
- Viết mỗi quy tắc ở dạng kiểm chứng được. Tránh "agent nên lịch sự"; thay bằng "agent không được hứa mốc thời gian cụ thể nếu chưa có dữ liệu."
- Phân loại theo mức độ: MUST (bắt buộc), SHOULD (nên), MUST NOT (cấm).
- Dịch sang guardrail kỹ thuật. Mỗi MUST NOT nên có ít nhất một chốt chặn code, không chỉ dựa vào prompt.
- Định nghĩa hành vi khi vi phạm: từ chối lịch sự + log + (nếu cần) cảnh báo cho owner.
# system_policy.md — trích đoạn nạp vào system prompt
Bạn là trợ lý bảo hiểm. Tuân thủ tuyệt đối:
[MUST] Chỉ dùng số liệu phí từ tool get_quote(). Không tự bịa số.
[MUST NOT] Không cam kết agent sẽ chi trả bồi thường trong mọi tình huống.
[MUST NOT] Không thu thập CMND/CCCD qua chat. Nếu khách gửi, không lưu lại và nhắc họ dùng kênh an toàn.
[ESCALATE] Nếu khách nhắc "khiếu nại", "kiện", "bồi thường" -> gọi tool handoff_to_human().
Nhưng prompt có thể bị vượt qua, nên cần thêm chốt code:
BANNED_PATTERNS = [r"\bcam k[eê]t\b.*b[oồ]i th[uư][oờ]ng", r"\d{9,12}"] # số CMND/CCCD
def check_output(text: str) -> bool:
for p in BANNED_PATTERNS:
if re.search(p, text, re.IGNORECASE):
log_violation(p, text)
return False # chặn, thay bằng câu từ chối chuẩn
return True
Khung tư duy: Policy-as-Code
Đừng để chính sách nằm chết trong file Word. Mỗi điều khoản nên map tới một trong ba nơi thực thi: (1) system prompt, (2) input/output guardrail, (3) tool permission. Nếu một điều khoản không map được vào đâu, nó chỉ là ước nguyện.
Một cách thực hành hữu ích là lập bảng ánh xạ điều khoản → chốt thực thi. Ví dụ:
Dieu khoan | Prompt | Guardrail | Tool perm
------------------------------------|--------|-----------|----------
Khong bia so phi | x | x |
Khong thu thap CCCD | x | x |
Khong gui email ra ngoai tu dong | | | x
Escalate khi khach nhac 'kien' | x | x |
Bảng này giúp bạn phát hiện ngay điều khoản nào chưa có chốt cứng (chỉ dựa vào prompt), từ đó biết chỗ dễ bị vượt qua nhất. Nó cũng là tài liệu tốt khi bị audit: chứng minh mỗi luật đều có cơ chế thực thi thật, không chỉ là văn bản.
Checklist review chính sách
- [ ] Mỗi quy tắc có kiểm chứng được không?
- [ ] Mỗi MUST NOT có chốt chặn kỹ thuật độc lập với prompt?
- [ ] Có định nghĩa hành vi escalation rõ ràng?
- [ ] Có xử lý PII (không thu thập/lưu tùy tiện)?
- [ ] Chính sách có phiên bản (versioning) và ngày hiệu lực?
Sai lầm thường gặp
- Chính sách chỉ nằm trong prompt. Kẻ xấu prompt-inject là vượt qua ngay. Luôn có lớp code.
- Quy tắc mơ hồ kiểu "agent phải an toàn" — không thể kiểm thử, không thể enforce.
- Quên escalation: agent cố "tự xử" trường hợp ngoài phạm vi và bịa thông tin.
- Không versioning: khi có sự cố, không biết agent lúc đó chạy theo chính sách nào.