Thử AI agent ở việc lặp lại, đầu vào tương đối rõ, đầu ra kiểm tra được và có người xử lý ngoại lệ, như phân loại ticket. Tránh quyết định liên quan tiền, quyền truy cập hay con người. Chấm tần suất, dữ liệu, rủi ro, khả năng duyệt và đường lui trước khi cấp quyền.

Agent khác tự động hóa theo luật thế nào?
Tự động hóa theo luật thường thực hiện chuỗi bước xác định trước: nếu biểu mẫu có đủ trường thì chuyển sang trạng thái kế tiếp. AI agent thêm khả năng diễn giải nội dung tự do, lập kế hoạch vài bước và gọi công cụ được tích hợp để tiến tới mục tiêu. Trong vận hành, agent có thể đọc yêu cầu qua email, phân loại, tìm tài liệu hướng dẫn và tạo bản nháp phản hồi.
Sự linh hoạt đó cũng tạo thêm tình huống: agent có thể hiểu sai yêu cầu, lấy nguồn không phù hợp, lặp thao tác hoặc chọn công cụ ngoài ý muốn. Vì vậy hãy hỏi liệu tác vụ có thật sự cần diễn giải ngôn ngữ và xử lý biến thiên hay một workflow rule-based đơn giản dễ kiểm soát hơn. Không phải quy trình nào gắn AI cũng tốt hơn.
Một pilot nên làm rõ ba lớp: mô hình đề xuất; hệ thống nghiệp vụ xác minh quy tắc/quyền; con người duyệt hành động có hậu quả. NIST AI RMF gợi ý xác định bối cảnh, quản trị vai trò, đánh giá và quản lý rủi ro xuyên vòng đời. Đây là khung tham khảo, không phải quy định chứng nhận cho một loại agent hay một doanh nghiệp cụ thể.
Chấm quy trình để chọn pilot
Lập danh sách các việc đang tốn thời gian hoặc gây chậm bàn giao. Với mỗi việc, ghi số lượt theo tuần/tháng, dữ liệu đầu vào, mức chuẩn hóa, số ngoại lệ, hậu quả nếu sai, bước kiểm tra hiện hữu, quyền cần thiết và người sở hữu quy trình. Chấm điểm chỉ giúp so sánh cơ hội; không thay đánh giá chuyên môn hay phân tích rủi ro.
- Tần suất: công việc lặp lại thường tạo đủ mẫu để thử và đo. Việc rất hiếm khó chứng minh giá trị qua một pilot ngắn.
- Tính ổn định đầu vào: biểu mẫu, ticket có trường rõ hoặc email theo format dễ xử lý hơn dữ liệu rời rạc từ nhiều kênh.
- Khả năng kiểm tra: có thể đối chiếu đầu ra với quy tắc, nguồn hay người chịu trách nhiệm không?
- Hậu quả sai: liệu lỗi có làm mất tiền, lộ dữ liệu, ảnh hưởng quyền lợi nhân viên/khách hàng hay gián đoạn vận hành?
- Khả năng sửa và hoàn tác: có thể để đầu ra ở dạng nháp, staging, hoặc quay lại trạng thái trước?
- Quyền truy cập: agent cần đọc những nguồn gì, có thực sự cần ghi hay gọi công cụ thực thi?
Một mô hình điểm nội bộ có thể chấm 1–5 cho tần suất, chuẩn hóa và khả năng kiểm tra; chấm cao cho khả năng thuận lợi. Với mức tác động và quyền rộng, chấm rủi ro cao rồi dùng như điều kiện loại hoặc yêu cầu kiểm soát tăng cường. Đừng cộng tất cả thành một số duy nhất nếu điểm rủi ro cao có thể bị điểm tần suất che lấp. Ghi lý do chọn, người duyệt và giả định để đội khác rà lại.
So sánh các tác vụ vận hành
| Tác vụ | Đầu vào/đầu ra | Khả năng thử | Rủi ro và guardrail | Nhận xét pilot |
|---|---|---|---|---|
| Phân loại yêu cầu nội bộ | Ticket → nhóm phụ trách, độ ưu tiên gợi ý | Dễ so với nhãn lịch sử đã rà soát | Không tự đóng; chuyển người nếu mơ hồ hoặc khẩn cấp | Ứng viên tốt khi taxonomy rõ |
| Tóm tắt bàn giao ca | Log vận hành → danh sách việc đang mở, người phụ trách, rủi ro | Đối chiếu được với log gốc | Trích dẫn sự kiện; không tự bỏ việc chưa xác nhận | Thử trên ca đã đóng, giữ link nguồn |
| Tìm SOP nội bộ | Câu hỏi → đoạn hướng dẫn và trích dẫn | Kiểm tra retrieval và grounding riêng | Phân quyền tài liệu trước khi truy xuất | Phù hợp nếu tài liệu có chủ sở hữu, phiên bản |
| Soạn phản hồi nhà cung cấp | Email, hợp đồng → bản nháp | Reviewer sửa/duyệt được | Không gửi tự động, kiểm tra cam kết và dữ liệu | Giữ ở draft, log người phê duyệt |
| Phê duyệt hoàn tiền/chi | Đề nghị và chứng từ → quyết định tiền | Rủi ro cao, tiêu chí có thể phức tạp | Không tự quyết hay giải ngân trong pilot đầu | Chỉ hỗ trợ checklist/tóm tắt bằng chứng |
| Thay đổi quyền tài khoản | Yêu cầu → sửa quyền truy cập | Sai sót có thể ảnh hưởng bảo mật | Người được ủy quyền xác minh độc lập | Không cấp quyền thực thi cho pilot đầu |

“Thử nghiệm được” không có nghĩa “được phép dùng dữ liệu”. Trước khi nạp lịch sử ticket, email hay tài liệu hợp đồng, xác minh mục đích, quyền, lưu trữ, nhà cung cấp và chính sách tổ chức. Nếu chưa xử lý được điều kiện dữ liệu, dùng bộ dữ liệu giả lập hoặc trì hoãn pilot.
Thiết kế pilot giới hạn
- Chọn một quy trình và chủ sở hữu: mô tả điểm vào, điểm kết thúc, người dùng, tình huống ngoài phạm vi và cách quay lại quy trình cũ.
- Đóng vai trò agent: ví dụ “đề xuất phân loại và tóm tắt ticket”, không cho tự assign hoặc đóng nếu chưa cần.
- Giới hạn nguồn: chỉ kết nối kho tài liệu cần thiết, kiểm soát quyền ở tầng connector và lọc quyền từng người dùng nếu phù hợp.
- Định dạng đầu ra: loại yêu cầu, lý do, nguồn, trường chưa rõ, mức cần con người xem. Đừng yêu cầu model tự đưa ra phán quyết cuối không giải thích.
- Tạo đường chuyển người: quy định rõ trường hợp mơ hồ, khẩn cấp, dữ liệu nhạy cảm, thiếu nguồn, lỗi tích hợp hoặc nghi ngờ prompt injection.
- Chạy chế độ shadow: agent xử lý bản sao hoặc tạo gợi ý nhưng không tác động hệ thống thật; so kết quả với người xử lý.
- Kiểm tra trước mở rộng: rà sai lệch theo nhóm, quyền, latency, log, chi phí và khả năng rollback. Chủ quy trình ký chấp nhận tiêu chí.
Không dùng prompt làm hàng rào duy nhất. Với hệ thống đọc email hoặc web, nội dung có thể chứa chỉ dẫn làm agent lệch mục tiêu; OWASP khuyến nghị nhiều lớp như quyền công cụ tối thiểu, xác thực đầu vào/đầu ra và phê duyệt người đối với hành động có tính phá hủy. Guardrail cũng có thể sai, nên không thay kiểm soát deterministic.
Hồ sơ đầu ra nên lưu gì?
- Mã yêu cầu và thời điểm xử lý; không cần đưa mọi dữ liệu cá nhân vào log.
- Phân loại/đề xuất cùng lý do ngắn và link tới nguồn đã dùng.
- Trường còn thiếu, mức bất định được diễn giải và điều kiện chuyển người.
- Phiên bản workflow/prompt/model nếu có thể truy xuất.
- Quyết định người duyệt, sửa đổi, lý do và thời gian hoàn thành.
- Trạng thái trước/sau nếu có cập nhật; cách rollback khi lỗi.
Đo hiệu quả và rủi ro
Chốt baseline trước khi bật agent: thời gian xử lý, backlog, tỷ lệ phân loại phải đổi, lỗi chuyển sai nhóm và mức hài lòng nội bộ nếu có phương pháp đo. Sau đó chạy trên tập kiểm thử được phép, giữ nguyên định nghĩa chỉ số và theo dõi kết quả theo từng nhóm ca. Không chỉ so độ chính xác tổng: một agent có thể đạt điểm cao nhờ nhóm phổ biến nhưng bỏ sót ca ít gặp, tác động lớn.
Tính thời gian nhân viên kiểm tra, sửa và xử lý lỗi cùng chi phí hạ tầng, kết nối, bảo mật, quản trị prompt và vận hành. Nếu công việc được chuyển từ người nhập liệu sang người kiểm tra mà vẫn phải đọc lại toàn bộ hồ sơ, lợi ích có thể thấp hơn dự kiến. Không đưa ra phần trăm tiết kiệm nếu chưa đo trên điều kiện tương đương.
Dùng tiêu chí dừng định trước: lỗi nghiêm trọng, truy cập vượt quyền, mất nguồn dẫn, không đạt tỷ lệ chuyển người mong muốn, latency vượt ngưỡng nghiệp vụ hoặc không thể rollback. Nếu agent xử lý ổn trong phạm vi hẹp, có thể mở rộng từng bước; mỗi connector hoặc công cụ mới là bề mặt rủi ro mới và cần kiểm thử riêng.
Ba tình huống quyết định
- Ticket lặp, taxonomy rõ, người dùng duyệt: chọn làm pilot shadow, đo phân loại theo nhóm và thời gian reviewer; chỉ tự chuyển nhóm sau khi tiêu chí vận hành được phê duyệt.
- Kho SOP rối, tài liệu hết hạn: chưa bắt đầu với agent trả lời tự động. Làm chủ sở hữu/versioning tài liệu, phân quyền và loại bỏ mâu thuẫn trước; nếu không, câu trả lời có nguồn vẫn có thể dựa vào chính sách cũ.
- Agent cần quyền hoàn tiền hoặc cấp quyền: không dùng làm thử nghiệm đầu tiên. Có thể để agent tóm tắt hồ sơ và checklist; người có thẩm quyền kiểm tra rồi thực hiện trong hệ thống hiện hữu.
Kết thúc pilot bằng quyết định có điều kiện: mở rộng, thu hẹp, sửa lại hoặc dừng. Ghi cả ca thất bại, giả định sai và nhóm chưa có đủ dữ liệu. Thành công không đồng nghĩa cấp rộng quyền; quy mô mới cần đánh giá lại mục tiêu, dữ liệu, người bị ảnh hưởng và cơ chế giám sát.

Câu hỏi thường gặp
Quy trình nào phù hợp nhất để làm pilot đầu tiên?
Thường là việc lặp lại, đầu vào có thể giới hạn, đầu ra đối chiếu được và có nhân viên duyệt trước tác động. Phân loại ticket hoặc tóm tắt bàn giao có thể là ứng viên nếu dữ liệu và quyền sử dụng đã được xác minh.
Có nhất thiết phải dùng AI agent không?
Không. Nếu quy tắc rõ và ít biến thiên, workflow thông thường, biểu mẫu hoặc script có thể dễ kiểm thử và rẻ vận hành hơn. Chỉ dùng agent khi khả năng diễn giải hay xử lý ngoại lệ tạo giá trị đo được.
Có thể để agent tự gửi email?
Pilot ban đầu nên tạo bản nháp để người phụ trách kiểm tra nội dung, người nhận, dữ liệu và cam kết. Chỉ xem xét gửi tự động cho phạm vi hẹp sau đánh giá rủi ro, quyền và cơ chế dừng riêng.
Làm sao tránh dữ liệu nhạy cảm bị dùng sai?
Xác minh quyền và điều khoản trước khi kết nối; giảm dữ liệu, giới hạn quyền truy cập và lưu giữ; dùng môi trường thử phù hợp. Không dựa vào câu “không tiết lộ dữ liệu” trong prompt để thay kiểm soát kỹ thuật.
Có thể chấm điểm quy trình bằng một công thức chung?
Có thể lập rubric nội bộ để so sánh nhưng không có trọng số phổ quát. Hãy giữ rủi ro nghiêm trọng như điều kiện loại hoặc cổng kiểm soát, tránh để tần suất cao bù trừ cho quyền quá rộng.
Khi nào phải dừng pilot?
Dừng nếu agent vượt quyền, gây lỗi nghiêm trọng lặp lại, nguồn không truy nguyên được, không có người sở hữu xử lý ngoại lệ hoặc đội không thể quay về trạng thái cũ. Xác định tiêu chí này trước khi thử.
Nguồn tham khảo
- NIST AI RMF Core — quản trị, xác định bối cảnh, đo lường và quản lý rủi ro.
- OWASP LLM Prompt Injection Prevention Cheat Sheet — quyền tối thiểu, nhiều lớp phòng vệ và phê duyệt hành động rủi ro.
Bình luận (0
)