Trong hệ thống ERP truyền thống, doanh nghiệp luôn biết:
- user nào đăng nhập;
- user thuộc bộ phận nào;
- user được xem dữ liệu gì;
- user được tạo giao dịch gì;
- hạn mức phê duyệt bao nhiêu;
- giao dịch nào cần cấp trên duyệt;
- khi nhân viên nghỉ việc thì tài khoản được khóa.
Đó là những nguyên tắc kiểm soát rất quen thuộc.
Nhưng khi AI Agent bắt đầu:
- đọc dữ liệu ERP;
- tạo purchase request;
- đề xuất payment;
- cập nhật forecast;
- tạo journal proposal;
- gửi email cho khách hàng;
- hoặc ghi dữ liệu trở lại hệ thống,
một câu hỏi mới xuất hiện:
> **AI Agent này là ai?**
Và tiếp theo:
> **Nó đại diện cho ai?**
> **Nó được phép làm gì?**
> **Hạn mức bao nhiêu?**
> **Ai chịu trách nhiệm nếu nó hành động sai?**
Đây là lý do khái niệm **Know Your Agent — KYA** đang bắt đầu xuất hiện trong lĩnh vực tài chính.
Visa, Mastercard và Ant International đã công bố hợp tác xây dựng framework để nhận diện và xác minh AI Agent trong các giao dịch. State Bank of India cũng nêu nhu cầu về một lớp kiểm soát tương tự KYC nhưng dành cho Agent, bao gồm identity, authentication, consent, transaction limit, audit trail và revocation.
Đối với Finance và Internal Control, đây không chỉ là vấn đề cybersecurity.
Đây là một thay đổi trong:
**mô hình phân quyền và kiểm soát nghiệp vụ.**
## 1. Khi Agent trở thành “non-human user”
Một nhân viên kế toán có thể có user ERP:
`NGUYEN.VAN.A`
Một AI Agent cũng cần được nhìn như một identity riêng:
`FIN-AP-AGENT-01`
hoặc:
`MFG-COST-AGENT-02`.
Khác biệt là Agent có thể:
- hoạt động 24/7;
- chạy hàng nghìn transaction;
- truy cập nhiều hệ thống;
- gọi nhiều tool;
- phối hợp với Agent khác;
- hành động nhanh hơn con người rất nhiều.
Vì vậy nếu quyền được cấp quá rộng, rủi ro cũng có thể lan rộng nhanh hơn.
Một Agent không nên tồn tại trong hệ thống dưới dạng:
> “API key dùng chung của phòng Finance.”
Nó cần một:
**identity độc lập, truy vết được và revoke được.**
## 2. Từ KYC sang KYA
KYC — Know Your Customer — đặt câu hỏi:
- khách hàng là ai?
- danh tính có xác thực không?
- mức rủi ro thế nào?
- giao dịch có phù hợp không?
KYA có logic tương tự nhưng áp dụng cho Agent.
Doanh nghiệp cần biết:
### Agent Identity
Agent nào đang hoạt động?
### Agent Owner
Ai chịu trách nhiệm nghiệp vụ?
### Agent Purpose
Agent được tạo để làm gì?
### Agent Authentication
Nó xác thực với hệ thống bằng cách nào?
### Agent Authority
Nó được đọc, ghi hay execute?
### Agent Limit
Hạn mức giao dịch bao nhiêu?
### Agent Evidence
Mọi hành động có log không?
### Agent Revocation
Có thể tắt quyền ngay lập tức không?
Đây là nền tảng tối thiểu của KYA.
## 3. Agent Identity không phải tên hiển thị
Đặt tên:
> “AP Agent”
chưa phải identity management.
Một identity đúng nghĩa phải được gắn với:
- credential riêng;
- permission riêng;
- system access riêng;
- business owner;
- lifecycle;
- log.
Ví dụ:
`Agent ID: FIN-AP-001`
`Business Owner: AP Manager`
`Technical Owner: IT Automation`
`Purpose: Invoice exception handling`
`ERP Access: AP module`
`Bank Access: None`
`Write Permission: Draft only`
`Execution Permission: No`
Nếu agent bị lỗi, doanh nghiệp có thể xác định:
> chính xác Agent nào đã làm gì.
## 4. Không dùng credential của con người cho Agent
Một anti-pattern nguy hiểm là:
AI Agent dùng account của nhân viên Finance.
Ví dụ:
Agent đăng nhập ERP bằng:
`ketoan01@company.com`.
Khi đó audit trail sẽ cho thấy:
> kế toán01 thực hiện giao dịch.
Trong khi thực tế:
> AI Agent thực hiện.
Điều này phá vỡ accountability.
Nguyên tắc nên là:
> **Human Identity khác Agent Identity.**
ERP và các hệ thống tích hợp nên biết actor là:
`HUMAN`
hay:
`AGENT`.
## 5. Mỗi Agent cần một Business Owner
AI Agent không thể tự chịu trách nhiệm.
Do đó mỗi Agent cần một:
**Business Owner.**
Ví dụ:
### AR Agent
Owner:
Credit Control Manager.
### Costing Agent
Owner:
Management Accounting / Costing Manager.
### MRP Agent
Owner:
Supply Chain Planning Manager.
### Tax Agent
Owner:
Tax Manager.
Owner chịu trách nhiệm về:
- mục đích;
- scope;
- KPI;
- quyền;
- exception;
- periodic review.
IT quản lý kỹ thuật.
Nhưng business phải sở hữu:
**business risk.**
## 6. Action Authority Profile
Một cách đơn giản để phân quyền Agent là chia thành sáu mức.
### READ
Chỉ đọc dữ liệu.
### ANALYZE
Phân tích.
### RECOMMEND
Đề xuất hành động.
### PREPARE
Tạo draft transaction.
### WRITE
Ghi vào hệ thống.
### EXECUTE
Thực hiện transaction.
Ví dụ Costing Agent:
`READ ✓`
`ANALYZE ✓`
`RECOMMEND ✓`
`PREPARE ✓`
`WRITE ✗`
`EXECUTE ✗`
AP Agent trưởng thành hơn có thể:
`READ ✓`
`ANALYZE ✓`
`RECOMMEND ✓`
`PREPARE ✓`
`WRITE ✓`
`EXECUTE có điều kiện`.
Quyền Agent nên tăng theo:
**maturity + evidence + risk tolerance.**
## 7. Principle of Least Privilege vẫn đúng với Agent
Nhân viên chỉ nên có quyền cần thiết để làm công việc.
Agent cũng vậy.
Một AR Collection Agent không cần:
- sửa bank account supplier;
- post journal;
- thay BOM;
- xem payroll.
Một MRP Agent có thể cần:
- đọc inventory;
- đọc BOM;
- đọc PO;
- đọc production plan.
Nhưng không nhất thiết được:
- release payment;
- sửa GL;
- tạo customer refund.
AI thông minh hơn không có nghĩa:
**cần quyền rộng hơn.**
Ngược lại, Agent càng mạnh càng cần least privilege nghiêm hơn.
## 8. Segregation of Duties phải mở rộng sang Agent
Trong Internal Control truyền thống:
người tạo vendor không nên đồng thời:
- sửa bank account;
- approve invoice;
- release payment.
Khi có AI Agent, SoD phải xem cả:
**Human + Agent.**
Ví dụ:
AP Agent:
- tạo payment proposal.
AP Manager:
- review.
Treasury:
- release payment.
Không nên để một Agent:
`Create Vendor`
+
`Change Bank`
+
`Approve Invoice`
+
`Execute Payment`.
Đó là một SoD conflict dù actor không phải con người.
## 9. Agent-to-Agent cũng tạo ra SoD Risk
Agentic system có thể có:
`Procurement Agent`
→ gửi cho
`AP Agent`
→ gửi cho
`Payment Agent`.
Nếu cả ba dùng cùng một policy engine hoặc cùng quyền unrestricted, doanh nghiệp có thể vô tình tạo ra một chuỗi tự phê duyệt.
Ví dụ:
Procurement Agent tạo PO.
AP Agent match invoice.
Payment Agent release tiền.
Nếu không có independent control:
**không còn maker-checker thực sự.**
Vì vậy SoD tương lai phải xem:
- human-human;
- human-agent;
- agent-agent.
## 10. Transaction Limit cho Agent
Mỗi Agent nên có transaction limit.
Ví dụ:
AR Agent:
- reminder tự động: không giới hạn;
- credit-term proposal: ≤ 30 ngày;
- credit limit change: không được phép.
AP Agent:
`<10 triệu`
→ straight-through nếu 3-way match hoàn chỉnh.
`10–50 triệu`
→ AP Manager approval.
`>50 triệu`
→ CFO/Treasury approval.
Agent không nên tự suy luận rằng:
> “Khoản này tuy lớn nhưng có vẻ hợp lý.”
Threshold phải deterministic.
## 11. Consent và Delegation
Một Agent thực hiện action phải có bằng chứng rằng:
**nó được ủy quyền.**
Trong ERP doanh nghiệp, delegation có thể là:
`Business Owner`
→ cho phép Agent
→ thực hiện scope cụ thể
→ trong thời gian cụ thể
→ với transaction limit cụ thể.
Ví dụ:
> FIN-AR-001 được quyền gửi collection reminder cho customer overdue từ 1–30 ngày, từ 01/09 đến 31/12/2026.
Đây là machine-readable delegation.
Không nên chỉ tồn tại trong email hoặc prompt.
## 12. Revocation phải tức thời
Nếu một nhân viên nghỉ việc, IT khóa account.
Agent cũng cần cơ chế tương tự.
Khi phát hiện:
- hành vi bất thường;
- lỗi model;
- credential leak;
- policy violation;
- transaction bất thường,
doanh nghiệp phải có thể:
**revoke credential ngay.**
Không cần:
- sửa prompt;
- deploy version mới;
- chờ AI “hiểu”.
Đó là lý do mỗi Agent cần:
**Kill Switch.**
## 13. Audit Trail cho Agent phải sâu hơn User Log thông thường
ERP truyền thống có thể log:
`User A posted Journal 123`.
Với Agent, audit trail lý tưởng cần thêm:
- Agent ID;
- workflow ID;
- input data;
- model/version;
- tool calls;
- proposed action;
- policy result;
- human approval;
- final transaction;
- override;
- timestamp.
Không nhất thiết lưu toàn bộ chain-of-thought của model.
Nhưng cần đủ evidence để trả lời:
> **Tại sao transaction này xảy ra và ai chịu trách nhiệm?**
## 14. Agent Register: “Danh sách nhân sự số”
Doanh nghiệp có Employee Master.
Trong tương lai nên có thêm:
**Agent Register.**
Mỗi Agent gồm:
### Identity
- Agent ID;
- Agent Name.
### Ownership
- Business Owner;
- Technical Owner.
### Purpose
Agent làm nghiệp vụ gì?
### Systems
Agent truy cập hệ thống nào?
### Data
Agent đọc loại dữ liệu nào?
### Tools
Agent được gọi tool nào?
### Authority
READ / ANALYZE / RECOMMEND / PREPARE / WRITE / EXECUTE.
### Limits
Transaction threshold.
### Approvals
Khi nào cần human approval?
### Credentials
Authentication mechanism.
### Monitoring
Log nằm ở đâu?
### Lifecycle
Active / Suspended / Retired.
### Kill Switch
Ai được quyền tắt?
Đây chính là:
**IAM cho Digital Workforce.**
## 15. Agent Onboarding nên giống Employee Onboarding
Khi tuyển một nhân viên mới:
- xác định role;
- tạo account;
- cấp permission;
- training;
- manager approval.
Agent cũng nên có onboarding.
### Bước 1
Business case approved.
### Bước 2
Agent Owner assigned.
### Bước 3
Identity created.
### Bước 4
Permission granted.
### Bước 5
Policy configured.
### Bước 6
Test/UAT.
### Bước 7
Production approval.
### Bước 8
Continuous monitoring.
Agent không nên chỉ được developer:
**“deploy vào production.”**
## 16. Agent Offboarding cũng quan trọng
Agent có thể bị:
- thay bằng phiên bản mới;
- không còn cần thiết;
- thay model;
- dừng use case.
Khi đó phải:
- revoke credential;
- remove system access;
- disable API;
- archive logs;
- transfer unresolved cases;
- cập nhật Agent Register.
Nếu không, doanh nghiệp sẽ có:
**orphan agent.**
Tương tự orphan user account trong cybersecurity.
## 17. Periodic Access Review
Doanh nghiệp thường review ERP user access:
- hàng quý;
- sáu tháng;
- hàng năm.
Agent cũng cần review.
Câu hỏi:
- Agent còn cần quyền này không?
- volume có thay đổi không?
- transaction limit có phù hợp không?
- exception rate bao nhiêu?
- có quyền nào chưa từng dùng?
- model đã thay đổi chưa?
- scope có drift không?
Least privilege không phải thiết lập một lần.
Nó là:
**continuous governance.**
## 18. Continuous Monitoring thay cho kiểm soát định kỳ
Agent hoạt động nhanh hơn con người.
Nếu chỉ review hàng quý có thể quá muộn.
Một số control cần real-time:
### Cost anomaly
Agent usage tăng bất thường.
### Transaction anomaly
Agent tạo volume giao dịch tăng đột biến.
### Permission anomaly
Agent gọi tool ngoài scope.
### Behavioral anomaly
Agent lặp action hoặc retry quá nhiều.
### Financial anomaly
Transaction tổng ngày vượt threshold.
Khi đó:
`Detect`
→ `Block`
→ `Alert`
→ `Investigate`.
## 19. KYA không thay thế Internal Control
Know Your Agent không phải một framework hoàn toàn mới tách khỏi KSNB.
Có thể coi nó là phần mở rộng của các control hiện có:
### Access Control
→ thêm Agent Identity.
### Segregation of Duties
→ thêm Agent-Agent conflict.
### Approval Authority
→ thêm Agent transaction limit.
### Change Management
→ thêm Agent/model/workflow version.
### Monitoring
→ thêm Agent behavior.
### Audit Trail
→ thêm AI-generated action evidence.
Tức là:
**Internal Control không biến mất trong kỷ nguyên AI.**
Nó chỉ cần mở rộng đối tượng kiểm soát.
## 20. Liên hệ với COSO
Có thể nhìn Agentic AI qua logic COSO truyền thống.
### Control Environment
Ai chịu trách nhiệm Agent?
### Risk Assessment
Agent có thể gây financial risk gì?
### Control Activities
Permission, approval, SoD, threshold.
### Information & Communication
Agent log, exception, reporting.
### Monitoring
Agent performance, policy violation, access review.
Do đó CFO, Controller và Internal Audit không cần học lại mọi thứ từ đầu.
Họ có thể:
**mở rộng framework hiện hữu sang non-human actors.**
## 21. Agent Control Matrix đơn giản cho SME
SME chưa cần mua một AI governance platform.
Có thể bắt đầu bằng Google Sheets.
Với mỗi Agent, ghi:
### Agent
Tên và ID.
### Owner
Ai chịu trách nhiệm?
### Process
Agent tham gia quy trình nào?
### Data
Đọc dữ liệu gì?
### System
Truy cập hệ thống nào?
### Authority
Mức quyền cao nhất.
### Transaction Limit
Hạn mức.
### Approval
Ai duyệt?
### Log
Evidence ở đâu?
### Kill Switch
Ai có thể tắt?
Chỉ cần bảng này cũng đã tốt hơn rất nhiều so với:
> “Agent dùng API key của hệ thống và chạy tự động.”
## 22. Ví dụ: AP Agent Control Design
Giả sử doanh nghiệp triển khai AP Agent.
Agent được phép:
- đọc invoice;
- đọc PO;
- đọc goods receipt;
- kiểm tra duplicate;
- tạo payment proposal.
Agent không được phép:
- tạo vendor;
- sửa bank account;
- tự release payment.
Workflow:
`Invoice`
↓
`AP Agent analyzes`
↓
`3-way match`
↓
nếu match hoàn chỉnh:
`Payment Proposal`
↓
Policy Gate kiểm tra:
- vendor active;
- bank verified;
- amount;
- duplicate;
- authority.
↓
Human approval theo threshold.
↓
Treasury release.
Như vậy Agent tạo productivity nhưng không phá SoD.
## 23. Ví dụ: Costing Agent Control Design
Costing Agent được quyền:
- đọc BOM;
- đọc Production Actual;
- đọc inventory;
- phân tích variance;
- tạo variance case.
Không được:
- sửa BOM;
- thay standard cost;
- post journal.
Workflow:
`Variance detected`
↓
`AI reasoning`
↓
`Recommended root cause`
↓
`Production verifies`
↓
`Costing approves`
↓
nếu cần:
authorized user sửa BOM.
Agent hỗ trợ intelligence.
System và human giữ authority.
Đây chính là:
**Probabilistic Reasoning, Deterministic Execution.**
## 24. KYA và Agent Economics liên quan trực tiếp
Governance không chỉ là cost.
Nhưng control kém cũng tạo economic loss.
Ví dụ:
- agent retry vô hạn;
- agent gọi model quá đắt;
- agent duplicate transaction;
- agent tạo false exception;
- agent tạo payment sai.
Do đó Agent Governance giúp cải thiện:
**Agent Economics.**
Một Agent có ROI cao nhưng control risk quá lớn:
không phải một Agent tốt.
CFO cần tối ưu:
`Economic Value`
cùng với:
`Control Effectiveness`.
## 25. Một Agent Scorecard hoàn chỉnh hơn
Có thể đánh giá Agent theo bốn lớp.
### Performance
- success rate;
- resolution rate;
- STP.
### Economics
- cost per case;
- net value;
- ROI.
### Control
- policy violation;
- unauthorized attempts;
- overrides;
- failed actions.
### Governance
- identity current?
- owner current?
- access reviewed?
- credential valid?
- audit logs complete?
Đây là management reporting cho:
**digital workforce.**
## 26. KYA trong framework Finance AI tổng thể
Chuỗi framework hiện tại có thể mở rộng như sau:
`Finance Value Leakage`
→ tìm vấn đề kinh tế đáng giải quyết.
`Business Objects / Ontology`
→ xác định business context.
`Trusted Data`
→ tạo dữ liệu đủ tin cậy.
`Exception / Event`
→ phát hiện case cần xử lý.
`Probabilistic AI Reasoning`
→ phân tích và đề xuất.
`Know Your Agent`
→ xác định Agent là ai và được quyền gì.
`Deterministic Policy & Control`
→ kiểm tra authority.
`Human Judgment`
→ phê duyệt khi cần.
`Business Transaction`
→ thực hiện action.
`Audit Trail`
→ tạo evidence.
`Financial Outcome`
→ đo kết quả.
`Agent Economics`
→ đánh giá ROI.
KYA chính là lớp nối giữa:
**AI Intelligence**
và
**Enterprise Authority.**
## 27. 10 câu hỏi CFO/Internal Audit nên hỏi trước khi Agent vào ERP
1. Agent này có unique identity không?
2. Business Owner là ai?
3. Agent đại diện cho business process nào?
4. Agent truy cập hệ thống và dữ liệu nào?
5. Quyền cao nhất là READ, WRITE hay EXECUTE?
6. Transaction limit là bao nhiêu?
7. Có SoD conflict với human hoặc Agent khác không?
8. Approval gate nằm ở đâu?
9. Audit trail có đủ để reconstruct action không?
10. Có thể revoke Agent ngay lập tức không?
Nếu chưa trả lời được 10 câu này:
**Agent chưa nên có quyền ghi vào hệ thống tài chính.**
# Kết luận
Trong nhiều năm, doanh nghiệp xây Internal Control dựa trên một giả định:
> **Actor trong hệ thống là con người.**
Giả định này đang thay đổi.
Trong tương lai ERP có thể đồng thời có:
- human users;
- service accounts;
- RPA bots;
- AI Agents.
Và mỗi actor đều có khả năng tạo business transaction.
Do đó Finance cần mở rộng câu hỏi quen thuộc:
> “Ai được quyền làm gì?”
thành:
> **“Human hoặc Agent nào được quyền làm gì, trong điều kiện nào, với hạn mức bao nhiêu và bằng chứng ở đâu?”**
Đó chính là tinh thần của:
**Know Your Agent.**
Agent cần có identity.
Agent cần có owner.
Agent cần có least privilege.
Agent cần có transaction limit.
Agent cần tuân thủ Segregation of Duties.
Agent cần audit trail.
Và quan trọng nhất:
**Agent phải có thể bị revoke.**
Khi AI chỉ đưa ra câu trả lời, governance có thể nhẹ.
Nhưng khi AI trở thành một người dùng của ERP và có khả năng tác động tới transaction:
> **Agent Identity trở thành một phần của Internal Control.**
Đây có thể là một trong những thay đổi quan trọng nhất mà CFO, Controller và Internal Audit cần chuẩn bị trong quá trình chuyển từ:
**AI Assistant**
sang:
**Agentic Enterprise.**
## Nguồn tham khảo
- Reuters, *Payment firms Visa, Mastercard and Ant International team up on AI agent trust framework*, 10/09/2026.
- Reuters, *India plans AI registry as it looks to roll out agentic payments*, 10/09/2026.
- PwC, *AI agents as workforce counterparts — what governance should look like*, 17/07/2026.
- KPMG, *Agentic AI workflows in financial reporting*, April 2026.
- Deloitte, *Agentic AI in Banking: Building the Auditable Bank*, 31/08/2026.
- Deloitte, *Automating Agentic AI Governance for Banks*, 31/08/2026.
- Deloitte, *AI Operating Models in Banking: The Case for Useful Friction*, 31/08/2026.
- user nào đăng nhập;
- user thuộc bộ phận nào;
- user được xem dữ liệu gì;
- user được tạo giao dịch gì;
- hạn mức phê duyệt bao nhiêu;
- giao dịch nào cần cấp trên duyệt;
- khi nhân viên nghỉ việc thì tài khoản được khóa.
Đó là những nguyên tắc kiểm soát rất quen thuộc.
Nhưng khi AI Agent bắt đầu:
- đọc dữ liệu ERP;
- tạo purchase request;
- đề xuất payment;
- cập nhật forecast;
- tạo journal proposal;
- gửi email cho khách hàng;
- hoặc ghi dữ liệu trở lại hệ thống,
một câu hỏi mới xuất hiện:
> **AI Agent này là ai?**
Và tiếp theo:
> **Nó đại diện cho ai?**
> **Nó được phép làm gì?**
> **Hạn mức bao nhiêu?**
> **Ai chịu trách nhiệm nếu nó hành động sai?**
Đây là lý do khái niệm **Know Your Agent — KYA** đang bắt đầu xuất hiện trong lĩnh vực tài chính.
Visa, Mastercard và Ant International đã công bố hợp tác xây dựng framework để nhận diện và xác minh AI Agent trong các giao dịch. State Bank of India cũng nêu nhu cầu về một lớp kiểm soát tương tự KYC nhưng dành cho Agent, bao gồm identity, authentication, consent, transaction limit, audit trail và revocation.
Đối với Finance và Internal Control, đây không chỉ là vấn đề cybersecurity.
Đây là một thay đổi trong:
**mô hình phân quyền và kiểm soát nghiệp vụ.**
## 1. Khi Agent trở thành “non-human user”
Một nhân viên kế toán có thể có user ERP:
`NGUYEN.VAN.A`
Một AI Agent cũng cần được nhìn như một identity riêng:
`FIN-AP-AGENT-01`
hoặc:
`MFG-COST-AGENT-02`.
Khác biệt là Agent có thể:
- hoạt động 24/7;
- chạy hàng nghìn transaction;
- truy cập nhiều hệ thống;
- gọi nhiều tool;
- phối hợp với Agent khác;
- hành động nhanh hơn con người rất nhiều.
Vì vậy nếu quyền được cấp quá rộng, rủi ro cũng có thể lan rộng nhanh hơn.
Một Agent không nên tồn tại trong hệ thống dưới dạng:
> “API key dùng chung của phòng Finance.”
Nó cần một:
**identity độc lập, truy vết được và revoke được.**
## 2. Từ KYC sang KYA
KYC — Know Your Customer — đặt câu hỏi:
- khách hàng là ai?
- danh tính có xác thực không?
- mức rủi ro thế nào?
- giao dịch có phù hợp không?
KYA có logic tương tự nhưng áp dụng cho Agent.
Doanh nghiệp cần biết:
### Agent Identity
Agent nào đang hoạt động?
### Agent Owner
Ai chịu trách nhiệm nghiệp vụ?
### Agent Purpose
Agent được tạo để làm gì?
### Agent Authentication
Nó xác thực với hệ thống bằng cách nào?
### Agent Authority
Nó được đọc, ghi hay execute?
### Agent Limit
Hạn mức giao dịch bao nhiêu?
### Agent Evidence
Mọi hành động có log không?
### Agent Revocation
Có thể tắt quyền ngay lập tức không?
Đây là nền tảng tối thiểu của KYA.
## 3. Agent Identity không phải tên hiển thị
Đặt tên:
> “AP Agent”
chưa phải identity management.
Một identity đúng nghĩa phải được gắn với:
- credential riêng;
- permission riêng;
- system access riêng;
- business owner;
- lifecycle;
- log.
Ví dụ:
`Agent ID: FIN-AP-001`
`Business Owner: AP Manager`
`Technical Owner: IT Automation`
`Purpose: Invoice exception handling`
`ERP Access: AP module`
`Bank Access: None`
`Write Permission: Draft only`
`Execution Permission: No`
Nếu agent bị lỗi, doanh nghiệp có thể xác định:
> chính xác Agent nào đã làm gì.
## 4. Không dùng credential của con người cho Agent
Một anti-pattern nguy hiểm là:
AI Agent dùng account của nhân viên Finance.
Ví dụ:
Agent đăng nhập ERP bằng:
`ketoan01@company.com`.
Khi đó audit trail sẽ cho thấy:
> kế toán01 thực hiện giao dịch.
Trong khi thực tế:
> AI Agent thực hiện.
Điều này phá vỡ accountability.
Nguyên tắc nên là:
> **Human Identity khác Agent Identity.**
ERP và các hệ thống tích hợp nên biết actor là:
`HUMAN`
hay:
`AGENT`.
## 5. Mỗi Agent cần một Business Owner
AI Agent không thể tự chịu trách nhiệm.
Do đó mỗi Agent cần một:
**Business Owner.**
Ví dụ:
### AR Agent
Owner:
Credit Control Manager.
### Costing Agent
Owner:
Management Accounting / Costing Manager.
### MRP Agent
Owner:
Supply Chain Planning Manager.
### Tax Agent
Owner:
Tax Manager.
Owner chịu trách nhiệm về:
- mục đích;
- scope;
- KPI;
- quyền;
- exception;
- periodic review.
IT quản lý kỹ thuật.
Nhưng business phải sở hữu:
**business risk.**
## 6. Action Authority Profile
Một cách đơn giản để phân quyền Agent là chia thành sáu mức.
### READ
Chỉ đọc dữ liệu.
### ANALYZE
Phân tích.
### RECOMMEND
Đề xuất hành động.
### PREPARE
Tạo draft transaction.
### WRITE
Ghi vào hệ thống.
### EXECUTE
Thực hiện transaction.
Ví dụ Costing Agent:
`READ ✓`
`ANALYZE ✓`
`RECOMMEND ✓`
`PREPARE ✓`
`WRITE ✗`
`EXECUTE ✗`
AP Agent trưởng thành hơn có thể:
`READ ✓`
`ANALYZE ✓`
`RECOMMEND ✓`
`PREPARE ✓`
`WRITE ✓`
`EXECUTE có điều kiện`.
Quyền Agent nên tăng theo:
**maturity + evidence + risk tolerance.**
## 7. Principle of Least Privilege vẫn đúng với Agent
Nhân viên chỉ nên có quyền cần thiết để làm công việc.
Agent cũng vậy.
Một AR Collection Agent không cần:
- sửa bank account supplier;
- post journal;
- thay BOM;
- xem payroll.
Một MRP Agent có thể cần:
- đọc inventory;
- đọc BOM;
- đọc PO;
- đọc production plan.
Nhưng không nhất thiết được:
- release payment;
- sửa GL;
- tạo customer refund.
AI thông minh hơn không có nghĩa:
**cần quyền rộng hơn.**
Ngược lại, Agent càng mạnh càng cần least privilege nghiêm hơn.
## 8. Segregation of Duties phải mở rộng sang Agent
Trong Internal Control truyền thống:
người tạo vendor không nên đồng thời:
- sửa bank account;
- approve invoice;
- release payment.
Khi có AI Agent, SoD phải xem cả:
**Human + Agent.**
Ví dụ:
AP Agent:
- tạo payment proposal.
AP Manager:
- review.
Treasury:
- release payment.
Không nên để một Agent:
`Create Vendor`
+
`Change Bank`
+
`Approve Invoice`
+
`Execute Payment`.
Đó là một SoD conflict dù actor không phải con người.
## 9. Agent-to-Agent cũng tạo ra SoD Risk
Agentic system có thể có:
`Procurement Agent`
→ gửi cho
`AP Agent`
→ gửi cho
`Payment Agent`.
Nếu cả ba dùng cùng một policy engine hoặc cùng quyền unrestricted, doanh nghiệp có thể vô tình tạo ra một chuỗi tự phê duyệt.
Ví dụ:
Procurement Agent tạo PO.
AP Agent match invoice.
Payment Agent release tiền.
Nếu không có independent control:
**không còn maker-checker thực sự.**
Vì vậy SoD tương lai phải xem:
- human-human;
- human-agent;
- agent-agent.
## 10. Transaction Limit cho Agent
Mỗi Agent nên có transaction limit.
Ví dụ:
AR Agent:
- reminder tự động: không giới hạn;
- credit-term proposal: ≤ 30 ngày;
- credit limit change: không được phép.
AP Agent:
`<10 triệu`
→ straight-through nếu 3-way match hoàn chỉnh.
`10–50 triệu`
→ AP Manager approval.
`>50 triệu`
→ CFO/Treasury approval.
Agent không nên tự suy luận rằng:
> “Khoản này tuy lớn nhưng có vẻ hợp lý.”
Threshold phải deterministic.
## 11. Consent và Delegation
Một Agent thực hiện action phải có bằng chứng rằng:
**nó được ủy quyền.**
Trong ERP doanh nghiệp, delegation có thể là:
`Business Owner`
→ cho phép Agent
→ thực hiện scope cụ thể
→ trong thời gian cụ thể
→ với transaction limit cụ thể.
Ví dụ:
> FIN-AR-001 được quyền gửi collection reminder cho customer overdue từ 1–30 ngày, từ 01/09 đến 31/12/2026.
Đây là machine-readable delegation.
Không nên chỉ tồn tại trong email hoặc prompt.
## 12. Revocation phải tức thời
Nếu một nhân viên nghỉ việc, IT khóa account.
Agent cũng cần cơ chế tương tự.
Khi phát hiện:
- hành vi bất thường;
- lỗi model;
- credential leak;
- policy violation;
- transaction bất thường,
doanh nghiệp phải có thể:
**revoke credential ngay.**
Không cần:
- sửa prompt;
- deploy version mới;
- chờ AI “hiểu”.
Đó là lý do mỗi Agent cần:
**Kill Switch.**
## 13. Audit Trail cho Agent phải sâu hơn User Log thông thường
ERP truyền thống có thể log:
`User A posted Journal 123`.
Với Agent, audit trail lý tưởng cần thêm:
- Agent ID;
- workflow ID;
- input data;
- model/version;
- tool calls;
- proposed action;
- policy result;
- human approval;
- final transaction;
- override;
- timestamp.
Không nhất thiết lưu toàn bộ chain-of-thought của model.
Nhưng cần đủ evidence để trả lời:
> **Tại sao transaction này xảy ra và ai chịu trách nhiệm?**
## 14. Agent Register: “Danh sách nhân sự số”
Doanh nghiệp có Employee Master.
Trong tương lai nên có thêm:
**Agent Register.**
Mỗi Agent gồm:
### Identity
- Agent ID;
- Agent Name.
### Ownership
- Business Owner;
- Technical Owner.
### Purpose
Agent làm nghiệp vụ gì?
### Systems
Agent truy cập hệ thống nào?
### Data
Agent đọc loại dữ liệu nào?
### Tools
Agent được gọi tool nào?
### Authority
READ / ANALYZE / RECOMMEND / PREPARE / WRITE / EXECUTE.
### Limits
Transaction threshold.
### Approvals
Khi nào cần human approval?
### Credentials
Authentication mechanism.
### Monitoring
Log nằm ở đâu?
### Lifecycle
Active / Suspended / Retired.
### Kill Switch
Ai được quyền tắt?
Đây chính là:
**IAM cho Digital Workforce.**
## 15. Agent Onboarding nên giống Employee Onboarding
Khi tuyển một nhân viên mới:
- xác định role;
- tạo account;
- cấp permission;
- training;
- manager approval.
Agent cũng nên có onboarding.
### Bước 1
Business case approved.
### Bước 2
Agent Owner assigned.
### Bước 3
Identity created.
### Bước 4
Permission granted.
### Bước 5
Policy configured.
### Bước 6
Test/UAT.
### Bước 7
Production approval.
### Bước 8
Continuous monitoring.
Agent không nên chỉ được developer:
**“deploy vào production.”**
## 16. Agent Offboarding cũng quan trọng
Agent có thể bị:
- thay bằng phiên bản mới;
- không còn cần thiết;
- thay model;
- dừng use case.
Khi đó phải:
- revoke credential;
- remove system access;
- disable API;
- archive logs;
- transfer unresolved cases;
- cập nhật Agent Register.
Nếu không, doanh nghiệp sẽ có:
**orphan agent.**
Tương tự orphan user account trong cybersecurity.
## 17. Periodic Access Review
Doanh nghiệp thường review ERP user access:
- hàng quý;
- sáu tháng;
- hàng năm.
Agent cũng cần review.
Câu hỏi:
- Agent còn cần quyền này không?
- volume có thay đổi không?
- transaction limit có phù hợp không?
- exception rate bao nhiêu?
- có quyền nào chưa từng dùng?
- model đã thay đổi chưa?
- scope có drift không?
Least privilege không phải thiết lập một lần.
Nó là:
**continuous governance.**
## 18. Continuous Monitoring thay cho kiểm soát định kỳ
Agent hoạt động nhanh hơn con người.
Nếu chỉ review hàng quý có thể quá muộn.
Một số control cần real-time:
### Cost anomaly
Agent usage tăng bất thường.
### Transaction anomaly
Agent tạo volume giao dịch tăng đột biến.
### Permission anomaly
Agent gọi tool ngoài scope.
### Behavioral anomaly
Agent lặp action hoặc retry quá nhiều.
### Financial anomaly
Transaction tổng ngày vượt threshold.
Khi đó:
`Detect`
→ `Block`
→ `Alert`
→ `Investigate`.
## 19. KYA không thay thế Internal Control
Know Your Agent không phải một framework hoàn toàn mới tách khỏi KSNB.
Có thể coi nó là phần mở rộng của các control hiện có:
### Access Control
→ thêm Agent Identity.
### Segregation of Duties
→ thêm Agent-Agent conflict.
### Approval Authority
→ thêm Agent transaction limit.
### Change Management
→ thêm Agent/model/workflow version.
### Monitoring
→ thêm Agent behavior.
### Audit Trail
→ thêm AI-generated action evidence.
Tức là:
**Internal Control không biến mất trong kỷ nguyên AI.**
Nó chỉ cần mở rộng đối tượng kiểm soát.
## 20. Liên hệ với COSO
Có thể nhìn Agentic AI qua logic COSO truyền thống.
### Control Environment
Ai chịu trách nhiệm Agent?
### Risk Assessment
Agent có thể gây financial risk gì?
### Control Activities
Permission, approval, SoD, threshold.
### Information & Communication
Agent log, exception, reporting.
### Monitoring
Agent performance, policy violation, access review.
Do đó CFO, Controller và Internal Audit không cần học lại mọi thứ từ đầu.
Họ có thể:
**mở rộng framework hiện hữu sang non-human actors.**
## 21. Agent Control Matrix đơn giản cho SME
SME chưa cần mua một AI governance platform.
Có thể bắt đầu bằng Google Sheets.
Với mỗi Agent, ghi:
### Agent
Tên và ID.
### Owner
Ai chịu trách nhiệm?
### Process
Agent tham gia quy trình nào?
### Data
Đọc dữ liệu gì?
### System
Truy cập hệ thống nào?
### Authority
Mức quyền cao nhất.
### Transaction Limit
Hạn mức.
### Approval
Ai duyệt?
### Log
Evidence ở đâu?
### Kill Switch
Ai có thể tắt?
Chỉ cần bảng này cũng đã tốt hơn rất nhiều so với:
> “Agent dùng API key của hệ thống và chạy tự động.”
## 22. Ví dụ: AP Agent Control Design
Giả sử doanh nghiệp triển khai AP Agent.
Agent được phép:
- đọc invoice;
- đọc PO;
- đọc goods receipt;
- kiểm tra duplicate;
- tạo payment proposal.
Agent không được phép:
- tạo vendor;
- sửa bank account;
- tự release payment.
Workflow:
`Invoice`
↓
`AP Agent analyzes`
↓
`3-way match`
↓
nếu match hoàn chỉnh:
`Payment Proposal`
↓
Policy Gate kiểm tra:
- vendor active;
- bank verified;
- amount;
- duplicate;
- authority.
↓
Human approval theo threshold.
↓
Treasury release.
Như vậy Agent tạo productivity nhưng không phá SoD.
## 23. Ví dụ: Costing Agent Control Design
Costing Agent được quyền:
- đọc BOM;
- đọc Production Actual;
- đọc inventory;
- phân tích variance;
- tạo variance case.
Không được:
- sửa BOM;
- thay standard cost;
- post journal.
Workflow:
`Variance detected`
↓
`AI reasoning`
↓
`Recommended root cause`
↓
`Production verifies`
↓
`Costing approves`
↓
nếu cần:
authorized user sửa BOM.
Agent hỗ trợ intelligence.
System và human giữ authority.
Đây chính là:
**Probabilistic Reasoning, Deterministic Execution.**
## 24. KYA và Agent Economics liên quan trực tiếp
Governance không chỉ là cost.
Nhưng control kém cũng tạo economic loss.
Ví dụ:
- agent retry vô hạn;
- agent gọi model quá đắt;
- agent duplicate transaction;
- agent tạo false exception;
- agent tạo payment sai.
Do đó Agent Governance giúp cải thiện:
**Agent Economics.**
Một Agent có ROI cao nhưng control risk quá lớn:
không phải một Agent tốt.
CFO cần tối ưu:
`Economic Value`
cùng với:
`Control Effectiveness`.
## 25. Một Agent Scorecard hoàn chỉnh hơn
Có thể đánh giá Agent theo bốn lớp.
### Performance
- success rate;
- resolution rate;
- STP.
### Economics
- cost per case;
- net value;
- ROI.
### Control
- policy violation;
- unauthorized attempts;
- overrides;
- failed actions.
### Governance
- identity current?
- owner current?
- access reviewed?
- credential valid?
- audit logs complete?
Đây là management reporting cho:
**digital workforce.**
## 26. KYA trong framework Finance AI tổng thể
Chuỗi framework hiện tại có thể mở rộng như sau:
`Finance Value Leakage`
→ tìm vấn đề kinh tế đáng giải quyết.
`Business Objects / Ontology`
→ xác định business context.
`Trusted Data`
→ tạo dữ liệu đủ tin cậy.
`Exception / Event`
→ phát hiện case cần xử lý.
`Probabilistic AI Reasoning`
→ phân tích và đề xuất.
`Know Your Agent`
→ xác định Agent là ai và được quyền gì.
`Deterministic Policy & Control`
→ kiểm tra authority.
`Human Judgment`
→ phê duyệt khi cần.
`Business Transaction`
→ thực hiện action.
`Audit Trail`
→ tạo evidence.
`Financial Outcome`
→ đo kết quả.
`Agent Economics`
→ đánh giá ROI.
KYA chính là lớp nối giữa:
**AI Intelligence**
và
**Enterprise Authority.**
## 27. 10 câu hỏi CFO/Internal Audit nên hỏi trước khi Agent vào ERP
1. Agent này có unique identity không?
2. Business Owner là ai?
3. Agent đại diện cho business process nào?
4. Agent truy cập hệ thống và dữ liệu nào?
5. Quyền cao nhất là READ, WRITE hay EXECUTE?
6. Transaction limit là bao nhiêu?
7. Có SoD conflict với human hoặc Agent khác không?
8. Approval gate nằm ở đâu?
9. Audit trail có đủ để reconstruct action không?
10. Có thể revoke Agent ngay lập tức không?
Nếu chưa trả lời được 10 câu này:
**Agent chưa nên có quyền ghi vào hệ thống tài chính.**
# Kết luận
Trong nhiều năm, doanh nghiệp xây Internal Control dựa trên một giả định:
> **Actor trong hệ thống là con người.**
Giả định này đang thay đổi.
Trong tương lai ERP có thể đồng thời có:
- human users;
- service accounts;
- RPA bots;
- AI Agents.
Và mỗi actor đều có khả năng tạo business transaction.
Do đó Finance cần mở rộng câu hỏi quen thuộc:
> “Ai được quyền làm gì?”
thành:
> **“Human hoặc Agent nào được quyền làm gì, trong điều kiện nào, với hạn mức bao nhiêu và bằng chứng ở đâu?”**
Đó chính là tinh thần của:
**Know Your Agent.**
Agent cần có identity.
Agent cần có owner.
Agent cần có least privilege.
Agent cần có transaction limit.
Agent cần tuân thủ Segregation of Duties.
Agent cần audit trail.
Và quan trọng nhất:
**Agent phải có thể bị revoke.**
Khi AI chỉ đưa ra câu trả lời, governance có thể nhẹ.
Nhưng khi AI trở thành một người dùng của ERP và có khả năng tác động tới transaction:
> **Agent Identity trở thành một phần của Internal Control.**
Đây có thể là một trong những thay đổi quan trọng nhất mà CFO, Controller và Internal Audit cần chuẩn bị trong quá trình chuyển từ:
**AI Assistant**
sang:
**Agentic Enterprise.**
## Nguồn tham khảo
- Reuters, *Payment firms Visa, Mastercard and Ant International team up on AI agent trust framework*, 10/09/2026.
- Reuters, *India plans AI registry as it looks to roll out agentic payments*, 10/09/2026.
- PwC, *AI agents as workforce counterparts — what governance should look like*, 17/07/2026.
- KPMG, *Agentic AI workflows in financial reporting*, April 2026.
- Deloitte, *Agentic AI in Banking: Building the Auditable Bank*, 31/08/2026.
- Deloitte, *Automating Agentic AI Governance for Banks*, 31/08/2026.
- Deloitte, *AI Operating Models in Banking: The Case for Useful Friction*, 31/08/2026.