# Đặt người duyệt ở đâu khi agent chạy trong phòng tài chính của khách

> Ở CrossCountry Consulting, tin tuyển FDE ghi rõ một yêu cầu: chọn bước nào cần con người ký, bước nào chỉ cần có người giám sát, và cân nhắc lựa chọn ấy theo rủi ro và mức độ trọng yếu.

Bản gốc: https://fdetimes.net/vi/bach-khoa/fde-crosscountry-consulting-agentic-workflow-engineer/

Thử hình dung tuần đầu tiên bạn ngồi ở văn phòng khách. Agent đọc hóa đơn đã chạy được trên dữ liệu mẫu. Rồi kế toán trưởng hỏi một câu không liên quan gì tới model: "Nếu nó ghi sai một bút toán thì ai ký?"

Ở các dự án tài chính, câu hỏi kiểu đó quyết định agent có lên production hay không. CrossCountry Consulting gọi mình là đối tác chuyển đổi cho Office of the CFO, tức khối tài chính của doanh nghiệp.

Vì vậy FDE của hãng làm việc chủ yếu với đội tài chính và vận hành phía khách. Tin tuyển vị trí Forward Deployed Engineer & Agentic Workflow Engineer nêu một yêu cầu rất cụ thể: thiết kế điểm kiểm soát HITL/HOTL tương xứng với rủi ro và mức độ trọng yếu của từng bước workflow.

Đây là kỹ năng nằm ngoài chuyện viết prompt hay chọn model: biết đặt con người vào đúng chỗ trong một quy trình có tiền và có kiểm toán. Và nó học được, nếu bạn tập trên một workflow cụ thể.

## Khách hỏi về trách nhiệm trước, về model sau

CrossCountry mô tả cách làm AI của mình là đặt quy trình lên trước công nghệ, và dịch vụ của hãng đi từ pilot tới production, có cả việc điều phối nhiều agent. Thứ tự đó có lý do. Trong phòng tài chính, sản phẩm thật sự là một quy trình mà kiểm toán chấp nhận được. Agent chỉ là một phần trong đó.

Áp lực thời gian cũng lớn. Tin tuyển yêu cầu FDE triển khai gói AI Jumpstart ngay trong tuần đầu của dự án. Đây là những đợt triển khai nhỏ, nhanh, tạo giá trị ngay mà không cần đầu tư ban đầu lớn hay thay đổi hạ tầng phức tạp.

Chỉ có một tuần, bạn không thể đợi kiểm toán duyệt từng dòng code. Thiết kế kiểm soát phải có từ ngày đầu và phải đủ rõ để người ngoài ngành phần mềm đọc hiểu.

## HITL bắt workflow chờ, HOTL để nó chạy

Với HITL, workflow dừng hẳn và chờ. Agent đề xuất, con người bấm duyệt, rồi bước tiếp theo mới chạy. Với HOTL, agent tự đi tiếp. Con người theo dõi qua dashboard hoặc cảnh báo và có quyền chặn khi thấy bất thường.

Hai loại khác nhau ở chi phí. HITL an toàn nhưng tốn công người và làm chậm quy trình. Nếu đặt HITL ở mọi bước, bạn chỉ dựng lại quy trình thủ công cũ, thêm vài bước bấm nút. HOTL nhanh, nhưng chỉ hợp khi một lỗi có thể phát hiện và sửa được trước khi gây hại.

Vì thế câu hỏi cần đặt cho mỗi bước có hai phần. Sai ở đây thì hậu quả lớn đến mức nào (mức độ trọng yếu)? Và có sửa lại được không, sửa trước khi tiền đi hay số liệu lên báo cáo?

**Điểm mấu chốt:** Hãy đặt con người ở chỗ cái sai không thể rút lại, đừng rải đều ở mọi bước.

## Thử chấm từng bước của workflow công nợ phải trả

Lấy một ví dụ giả định quen thuộc với mọi khối tài chính: xử lý hóa đơn nhà cung cấp. Bạn chia workflow thành từng bước, rồi chấm từng bước theo hai câu hỏi ở trên.

| Bước | Rủi ro nếu sai | Sửa lại được? | Mức kiểm soát |
|---|---|---|---|
| Agent đọc hóa đơn, trích số tiền, nhà cung cấp, ngày | Sai số liệu đầu vào | Được, trước khi ghi sổ | Tự động, kèm kiểm tra định dạng |
| Đối chiếu với đơn mua hàng và phiếu nhập kho | Duyệt nhầm hóa đơn không khớp | Được | HOTL: tự chạy, chênh lệch thì báo cảnh báo |
| Đề xuất tài khoản hạch toán | Ghi sai tài khoản, lệch báo cáo | Được, nhưng tốn công khi đã khóa sổ | HOTL nếu dưới ngưỡng, HITL nếu trên ngưỡng |
| Nhà cung cấp mới hoặc đổi số tài khoản ngân hàng | Chuyển tiền cho kẻ gian | Gần như không | HITL bắt buộc, hai người duyệt |
| Lệnh thanh toán | Tiền đã đi | Không | HITL cho mọi lệnh |

Bảng này cho thấy hai điều. Mức kiểm soát có thể thay đổi ngay trong một bước, tùy giá trị giao dịch, và ngưỡng đó phải do controller của khách đặt, không phải bạn. Bước rủi ro nhất cũng không nằm ở chỗ AI dễ sai nhất.

Đọc hóa đơn mới là chỗ model hay nhầm, nhưng lỗi ở đó sửa được. Đổi số tài khoản ngân hàng là thao tác đơn giản, nhưng sai một lần thì không lấy lại được tiền.

Mỗi điểm HITL cần thêm hai thứ, nếu thiếu thì kiểm toán sẽ gạt đi. Trước hết, người duyệt phải nhìn thấy đủ bằng chứng: hóa đơn gốc, dòng đơn mua hàng tương ứng, lý do agent đề xuất.

Kế đến là log ghi lại ai duyệt, lúc nào và đã thấy gì. Khi số lượng agent tăng lên, CrossCountry dùng nền tảng CrossCoreAI của mình để điều phối, giám sát và quản trị agent. Dù dùng công cụ nào, bạn vẫn cần nghĩ ra trước những gì sẽ được giám sát.

## Năm đến bảy người cùng ký vào một bảng kiểm soát

Theo CrossCountry, quản trị AI đòi hỏi phối hợp giữa 5-7 bên liên quan. Với FDE, con số này nghĩa là bảng ở trên phải đi qua nhiều người với mối lo khác nhau: tài chính muốn quy trình nhanh, IT lo quyền truy cập hệ thống, kiểm toán cần dấu vết.

Cách làm hiệu quả là đưa bảng kiểm soát cho họ trước khi đưa demo. Cột "Mức kiểm soát" là cột họ sẽ tranh luận nhiều nhất, và nên để họ tranh luận sớm. Nếu kiểm toán muốn bước đối chiếu chuyển từ HOTL sang HITL, bạn sửa một dòng trong bảng, không phải viết lại agent.

Vai trò này cũng đòi hỏi có mặt trực tiếp. Tin tuyển ghi mức đi lại trong nước 20%–40%, tùy giai đoạn dự án của khách. Ngồi cạnh người kế toán xử lý hóa đơn trong một buổi chiều cho bạn biết nhiều về rủi ro thật hơn mọi tài liệu quy trình.

## Ba lỗi khiến thiết kế bị trả về

Lỗi thường gặp nhất là chấm rủi ro theo độ khó kỹ thuật thay vì theo hậu quả với doanh nghiệp. Engineer hay đặt kiểm soát ở chỗ model yếu và bỏ qua những thao tác đơn giản nhưng không đảo ngược được, như thanh toán hay đổi dữ liệu gốc của nhà cung cấp.

Lỗi thứ hai là tự đặt ngưỡng trọng yếu. Ngưỡng đó thuộc về chính sách kiểm soát nội bộ của khách. Việc của bạn là làm cho ngưỡng thành tham số cấu hình được, rồi hỏi đúng người để lấy con số.

Lỗi thứ ba là coi HITL như một nút "OK". Nếu người duyệt chỉ thấy một dòng tóm tắt, họ sẽ duyệt hết theo phản xạ, và điểm kiểm soát chỉ còn trên giấy. Một điểm HITL tốt cho người duyệt đủ thông tin để từ chối.

## Cách đưa kỹ năng này vào hồ sơ

CrossCountry có thể tuyển vị trí này ở cấp Manager hoặc Associate Director. Như vậy đây là vai senior, và người tuyển muốn thấy phán đoán, không chỉ thấy code.

Khi đọc tin tuyển FDE ở mảng tài chính, bảo hiểm hay y tế, hãy để ý các cụm như "human-in-the-loop", "governance", "materiality". Gặp những cụm đó, bạn nên chuẩn bị sẵn một ví dụ thiết kế kiểm soát để mang vào phỏng vấn.

Trong CV, đừng chỉ viết "xây agent xử lý hóa đơn". Hãy viết workflow có bao nhiêu bước, bao nhiêu điểm kiểm soát, bước nào chuyển từ thủ công sang HOTL, và ai phía khách đã ký duyệt. Khi phỏng vấn, mang theo một bảng như bảng ở trên và giải thích vì sao bạn đặt HITL ở dòng thanh toán mà không đặt ở dòng đọc hóa đơn.

Ở phòng tài chính, agent được tin dùng không phải vì nó không bao giờ sai. Nó được tin dùng vì ai cũng biết khi nó sai thì lỗi sẽ dừng lại ở đâu.

**Thử ngay tuần này:**

- Chọn một quy trình tài chính bạn biết (công nợ phải trả, đối chiếu ngân hàng, hoàn ứng chi phí), chia thành 5-7 bước và gán cho mỗi bước một mức: tự động, HOTL hoặc HITL, mỗi lựa chọn kèm một câu lý do.
- Với từng bước HITL, viết rõ người duyệt nhìn thấy gì trên màn hình và log lưu lại những gì để kiểm toán đọc được.
- Viết lại một gạch đầu dòng trong CV theo mẫu: workflow nào, có bao nhiêu điểm kiểm soát, ai đã ký duyệt thiết kế.

## Nguồn

- [We are the transformation partner for the Office of the CFO](https://crosscountry-consulting.com/)

- [Technology-Enabled Transformation](https://www.crosscountry-consulting.com/solution/technology-enabled-transformation/ai-transformation/)

- [Forward Deployed Engineer & Agentic Workflow Engineer – AI Innovation & Transformation (CrossCountry Consulting, Built In)](https://builtinottawa.com/job/forward-deployed-engineer-agentic-workflow-engineer-ai-innovation-transformation/10674896)

- [Forward Deployed Engineer & Agentic Workflow Engineer (CrossCountry Consulting, Blind)](https://www.teamblind.com/jobs/325319890)