Use case tốt vẫn thất bại nếu không có tổ chức và quản trị đỡ phía sau. Bài này thiết lập những thứ phải có trước khi agent chạm dữ liệu thật.
Mô hình tổ chức: CoE + đội sản phẩm
Mô hình phổ biến nhất là Center of Excellence (CoE) mỏng ở giữa + đội sản phẩm ở từng phòng ban:
- CoE (3–6 người): sở hữu nền tảng dùng chung, tiêu chuẩn guardrail, eval, chọn model, đào tạo.
- Đội sản phẩm/phòng ban: sở hữu use case cụ thể, hiểu nghiệp vụ, nghiệm thu kết quả.
- Product owner (nghiệp vụ): định nghĩa "xong đúng".
- Kỹ sư AI/tích hợp: dựng agent, nối tool.
- SME/reviewer nghiệp vụ: người phê duyệt các ca agent escalate.
Guardrail nhiều lớp
Lớp 1 - Phạm vi hành động: agent chỉ được gọi tool trong allowlist.
Lớp 2 - Ngưỡng tự chủ: hành động > X triệu đồng phải human duyệt.
Lớp 3 - Kiểm output: lọc PII, kiểm chính sách trước khi gửi khách.
Lớp 4 - Kill switch: tắt agent tức thời khi có sự cố.
Lớp 5 - Audit log: lưu mọi bước để truy vết & giải trình.
Nguyên tắc: mức tự chủ tỷ lệ nghịch với chi phí sai. Việc rủi ro thấp (gắn nhãn ticket) cho agent tự chủ hoàn toàn; việc rủi ro cao (hoàn tiền lớn) giữ human-in-the-loop.
Ví dụ cụ thể về ngưỡng tự chủ
Agent hoàn tiền: tự động duyệt hoàn ≤ 500.000đ nếu đơn khớp chính sách; từ 500.000đ đến 5 triệu → đề xuất cho nhân viên bấm duyệt; trên 5 triệu → chuyển thẳng quản lý. Cấu hình rõ ràng như vậy giúp mở rộng tự chủ dần theo niềm tin. Khi agent chạy ổn định vài tháng với tỷ lệ lỗi thấp, bạn có thể nâng ngưỡng tự động từ 500.000đ lên 1 triệu — tự chủ tăng dần theo dữ liệu, không theo cảm tính.
Cấu hình mẫu cho ngưỡng tự chủ có thể viết dưới dạng luật rõ ràng để dễ kiểm toán:
refund_policy:
auto_approve_max: 500000 # tự động nếu <= mức này
human_review_max: 5000000 # nhân viên duyệt tới mức này
above: escalate_to_manager # trên nữa chuyển quản lý
require_order_match: true # phải khớp chính sách đơn
Quản trị dữ liệu & tuân thủ
- Phân loại dữ liệu agent được đọc (công khai / nội bộ / nhạy cảm).
- Ẩn/tối thiểu hóa PII trước khi đưa vào prompt.
- Ghi rõ dữ liệu có rời khỏi hạ tầng công ty (gọi API LLM ngoài) không.
- Lưu nhật ký để đáp ứng kiểm toán và quy định (vd nghị định dữ liệu cá nhân).
Checklist "sẵn sàng lên production"
[ ] Allowlist tool đã cấu hình, không có quyền dư thừa
[ ] Ngưỡng human-in-the-loop đã đặt theo chi phí sai
[ ] Kill switch test thành công
[ ] Audit log ghi đủ input/hành động/output
[ ] Có người trực nhận escalate trong giờ vận hành
[ ] Bộ eval đạt ngưỡng chất lượng tối thiểu (bài 7)
[ ] Kế hoạch rollback nếu tỷ lệ lỗi vượt ngưỡng
Các bước làm
- Lập CoE mỏng, phân định rõ CoE sở hữu gì vs phòng ban sở hữu gì.
- Gán 3 vai trò tối thiểu cho use case đầu tiên.
- Định nghĩa allowlist tool và ngưỡng tự chủ theo chi phí sai.
- Cài audit log + kill switch trước khi chạm dữ liệu thật.
- Duyệt checklist sẵn sàng production trước ngày go-live.
- Chỉ định người trực escalate và quy trình báo sự cố.
Sai lầm thường gặp
- Cho agent tự chủ tối đa từ ngày đầu: một lỗi hoàn tiền hàng loạt đủ giết cả chương trình.
- Không có kill switch/audit log: khi sự cố xảy ra, không tắt được và không giải trình được.
- CoE ôm hết use case: nút thắt cổ chai, phòng ban mất quyền sở hữu nghiệp vụ.
- Bỏ qua tuân thủ dữ liệu cá nhân: rủi ro pháp lý lớn hơn nhiều lợi ích tự động hóa.
- Cấp quyền tool dư thừa "cho tiện": agent chỉ nên có đúng quyền cần cho công việc; quyền dư là bề mặt rủi ro khi agent hành xử ngoài dự kiến.
Tóm tắt
Kỹ thuật xây agent chỉ là một nửa; nửa còn lại là tổ chức và quản trị. Một CoE mỏng sở hữu tiêu chuẩn dùng chung, các đội phòng ban sở hữu nghiệp vụ, guardrail nhiều lớp với mức tự chủ tỷ lệ nghịch chi phí sai, cùng kill switch và audit log — đó là bộ khung tối thiểu để agent chạm dữ liệu thật một cách an toàn và giải trình được.
Bài 7 sẽ dạy cách đo lường: làm sao biết agent thật sự chạy tốt và khi nào đủ tin cậy để mở rộng lưu lượng.