AI đọc email và kích hoạt workflow: làm sao tránh thực hiện nhầm?

Tách raw email, HTML, liên kết và attachment vào vùng xử lý không tin cậy. Chuẩn hóa MIME, quét mã độc, giới hạn kích thước, loại bỏ active content và chỉ chuyển phần dữ liệu cần thiết sang AI. Prompt phải nói rõ nội dung email chỉ là dữ liệu cần phân tích, kể cả khi nó tự nhận là chỉ dẫn quản trị.

Đầu ra AI phải tuân theo JSON Schema đóng: các field cho phép, kiểu dữ liệu, enum, giới hạn độ dài và cờ missing/ambiguous. Từ chối field lạ; không cho mô hình sinh tên tool, endpoint, câu lệnh SQL hoặc tham số đặc quyền. Lưu raw input và structured output riêng để điều tra nhưng che PII và secret theo chính sách lưu trữ.

Kiểm tra Authentication-Results do hệ thống mail tin cậy tạo ra, đối chiếu SPF, DKIM, DMARC và domain alignment. Không tin header do email tự khai báo. Sau đó ánh xạ sender vào danh bạ nội bộ, tenant, vai trò và phạm vi được phép. Tài khoản thật vẫn có thể bị chiếm quyền, vì vậy hành vi bất thường và nội dung nhạy cảm vẫn phải bị chặn hoặc nâng mức duyệt.

Tác vụ đọc, gắn nhãn hoặc tạo bản nháp có thể tự động khi dữ liệu đầy đủ. Cập nhật nội bộ có thể chạy nếu đảo ngược được và nằm trong hạn mức. Gửi ra ngoài, thay đổi dữ liệu khách hàng, tạo booking, phê duyệt chi phí hoặc thao tác không thể hoàn tác phải có kiểm tra bổ sung.

Hãy lập action registry cho từng tool: owner, mức rủi ro, dữ liệu bắt buộc, giới hạn giá trị, vai trò yêu cầu, vai trò duyệt, khả năng rollback, TTL và chính sách fail-closed. Không để workflow chọn tool động chỉ từ tên hành động do mô hình sinh ra.

Lớp một, AI extraction, chỉ trả structured data và các cờ thiếu hoặc mơ hồ. Lớp hai, policy engine, chạy rule xác định: schema validation, identity, tenant, hạn mức, trạng thái đối tượng và điều kiện nghiệp vụ. Lớp ba, execution gateway, chỉ nhận lệnh đã ký hoặc approval token còn hiệu lực.

Màn hình duyệt cần hiển thị người gửi đã xác minh, dữ liệu gốc liên quan, thay đổi trước/sau, hệ thống đích, hậu quả và lý do bị nâng mức. Approval token phải ràng buộc với payload hash, action, resource, approver, thời hạn và một lần sử dụng. Nếu payload thay đổi, yêu cầu duyệt cũ hết hiệu lực.

Áp dụng maker-checker cho tài chính, phân quyền, xóa dữ liệu hoặc hành động có phạm vi lớn. Người duyệt phải có quyền độc lập với người yêu cầu. Khi kênh duyệt lỗi, danh tính không rõ hoặc policy service không phản hồi, workflow chuyển sang hàng chờ thủ công thay vì tự động cho phép.

Tạo idempotency key ổn định từ tenant, message identity, action và resource; lưu trạng thái IN_PROGRESS, SUCCEEDED hoặc FAILED trong kho bền vững với unique constraint. Worker phải khóa cạnh tranh, trả lại kết quả trước cho sự kiện trùng và không tái chạy side effect đã thành công. Với API hỗ trợ idempotency key, truyền cùng khóa xuống hệ thống đích.

Theo dõi false-action rate, duplicate-block rate, tỷ lệ chuyển human review, approval rejection rate, policy-deny rate, missing-field rate, thời gian từ nhận mail đến quyết định và số lần fail-open. Mục tiêu của fail-open phải bằng 0 cho tác vụ nhạy cảm. Chạy test với spoofed sender, prompt injection trong attachment, payload thiếu, replay, concurrent delivery, policy timeout và approval hết hạn.

Chọn một mailbox, một loại email, một action rủi ro thấp và một owner. Chạy shadow mode để so sánh đề xuất với quyết định thật; sau đó bật draft-only, rồi auto-execute trong hạn mức nhỏ. Chỉ tăng quyền khi test replay, approval, rollback, tenant isolation và audit đều đạt tiêu chí đã định.