AI Agent của bạn chỉ thông minh bằng hệ thống lõi mà nó kết nối

Phòng tài chính của bạn triển khai một AI agent để hỗ trợ chốt sổ cuối tháng. Agent đọc hóa đơn, đối chiếu với đơn mua hàng, và đánh dấu các điểm bất thường. Mọi thứ đang tốt. Cho đến khi nó cần kiểm tra xem biên nhận hàng đã được ghi nhận chưa, nhà cung cấp còn hoạt động không, hay hóa đơn có đang nằm trong quy trình khiếu nại không. Đột nhiên, agent "đứng hình".

Đây không phải câu chuyện về một mô hình AI yếu kém. Đây là câu chuyện về kiến trúc hệ thống.

ERP, CRM, HRIS và các hệ thống lõi khác không chỉ đơn thuần là những cơ sở dữ liệu lớn mà bạn có thể truy vấn tùy ý. Chúng là bản ghi chính thức về trạng thái doanh nghiệp — đơn hàng, hóa đơn, dữ liệu khách hàng, trạng thái nhân viên — tất cả đều đã được xác thực và kiểm soát. Các agent không thể hoạt động tốt nếu không hiểu được trạng thái đó. Nhưng hầu hết các doanh nghiệp đều phát hiện ra rằng hệ thống lõi của họ được xây dựng để chuẩn hóa và kiểm soát giao dịch, chứ không phải cho tương tác bán tự động linh hoạt.

Kết quả? Những thử nghiệm agent đầy hứa hẹn đâm vào tường. CIO thấy vấn đề kiến trúc. COO thấy vấn đề thiết kế quy trình. CFO và CHRO thấy vấn đề kiểm soát và trách nhiệm giải trình. Ai cũng đúng.

Lộ trình thực tế từ insight chỉ-đọc đến hành động có giới hạn trong các hệ thống lõi doanh nghiệp.

Nút thắt thực sự không phải là AI

Trước khi đổ lỗi cho mô hình, hãy nhìn vào những gì xảy ra khi một agent cố gắng làm việc thực tế.

Truy cập thời gian thực thường không khả dụng. Nhiều hệ thống vẫn dựa vào xử lý batch hoặc tích hợp point-to-point chậm chạp. API có tồn tại, nhưng chúng được thiết kế cho các ứng dụng có cấu trúc, do con người vận hành — không phải cho các agent cần gọi nhiều endpoint theo trình tự, tạm dừng để xác thực chính sách, hoặc tiếp tục sau khi được phê duyệt.

Kiểm soát truy cập là một cái bẫy khác. Hệ thống lõi định nghĩa quyền cho vai trò con người, không phải cho các "digital worker" với phạm vi hẹp, cụ thể. Các công ty thường kết thúc với việc cấp cho agent quá nhiều quyền hoặc không có quyền nào cả.

Rồi còn lớp ngữ nghĩa. Các quy tắc kinh doanh thực sự không chỉ nằm trong ERP hay CRM. Chúng sống trong bảng tính, SOP nội bộ, email, cơ sở tri thức và thói quen vận hành không được ghi chép. Một agent chỉ kết nối với hệ thống lõi sẽ liên tục hiểu sai ngữ cảnh.

Sai lầm là cho rằng các hệ thống đã sẵn sàng. Hầu như không bao giờ.

Mô hình trưởng thành duy nhất bạn cần: Đọc, Đề xuất, Hành động

Sai lầm phổ biến nhất là vội vàng để agent thực thi giao dịch trực tiếp. Một cách tiếp cận theo giai đoạn lành mạnh hơn nhiều. Mô hình Đọc, Đề xuất, Hành động không chỉ là lộ trình kỹ thuật — nó là cách để quản lý rủi ro, xây dựng niềm tin và làm chín muồi mô hình vận hành của bạn.

Giai đoạn 1: Đọc — Hiểu mà không chạm

Bắt đầu với quyền truy cập chỉ-đọc. Công việc của agent là hiểu ngữ cảnh giao dịch, phát hiện ngoại lệ, tóm tắt trạng thái và cung cấp insight hoặc ưu tiên. Giai đoạn này mang lại giá trị nhanh vì rủi ro thấp.

• Phòng tài chính có thể dùng agent để đọc dữ liệu sổ cái, trạng thái đối chiếu và lịch sử ngoại lệ nhằm đánh dấu các tài khoản có nguy cơ chốt sổ muộn.
• Phòng mua hàng có thể đọc yêu cầu nhập hàng, trạng thái nhà cung cấp, hợp đồng và lịch sử mua để hướng dẫn người yêu cầu đi đúng quy trình.
• Vận hành khách hàng có thể chuẩn bị tóm tắt vụ việc trước khi nhân viên trực tiếp bắt máy.
• HR có thể gửi thông báo chủ động về onboarding bị đình trệ.

Giá trị kinh doanh đến từ việc giảm thời gian tìm kiếm dữ liệu, ưu tiên xử lý ngoại lệ và giảm bàn giao thủ công. Nhưng chỉ-đọc thôi sẽ không chuyển đổi cấu trúc chi phí của bạn. Con người vẫn cần đưa quyết định vào hệ thống, tạo giao dịch, gửi follow-up và đóng vòng lặp.

Giai đoạn 2: Đề xuất — Chuẩn bị, sau đó xin phê duyệt

Bây giờ agent không chỉ đọc. Nó soạn thảo giao dịch, tạo yêu cầu workflow, soạn các đề xuất hành động hoặc kích hoạt bước tiếp theo — tất cả đều cần phê duyệt của con người. Đây thường là điểm ngọt ngào cho các chức năng doanh nghiệp.

• Tài khoản phải trả: Agent phát hiện hóa đơn không khớp, chuẩn bị phân tích nguyên nhân gốc rễ và soạn thảo một case giải quyết để xem xét.
• Bán hàng: Agent chuẩn bị các hành động tiếp theo tốt nhất cho account manager hoặc soạn thảo cập nhật cơ hội.
• HRIS: Agent soạn thảo thay đổi dữ liệu nhân viên nhưng để HR hoặc quản lý trực tiếp phê duyệt.
• IT Ops: Agent thu thập telemetry, gợi ý nguyên nhân gốc rễ và chuẩn bị các hành động runbook — nhưng kỹ sư vẫn phê duyệt việc khắc phục.

Con người giữ điểm kiểm soát. Chất lượng đề xuất có thể được đánh giá. Tổ chức học được nơi agent thực sự giúp ích và nơi nó vẫn sai.

Cảnh báo: Nếu quy trình phê duyệt được thiết kế kém, bạn chỉ đơn giản là chuyển nút thắt từ việc tìm dữ liệu sang việc phê duyệt bản nháp của agent. Phê duyệt phải có kỷ luật — chỉ cho những hành động thực sự cần, với đủ ngữ cảnh và SLA rõ ràng.

Giai đoạn 3: Hành động — Tự chủ có giới hạn

Giai đoạn trưởng thành nhất là khi agent có thể hành động trực tiếp trong hệ thống lõi. Từ khóa là có giới hạn. Không phải tự do tạo giao dịch, mà là tự chủ trong khuôn khổ:

• Các kịch bản cụ thể và chính sách rõ ràng

• Ngưỡng và giới hạn được định nghĩa

• Ghi log đầy đủ và audit trail

• Hành động rollback hoặc bù trừ

• Kill switch nếu hành vi đi chệch hướng

• Dịch vụ khách hàng: Agent có thể cập nhật trạng thái ticket, gửi truyền thông tiêu chuẩn hoặc xử lý thay đổi đơn hàng không quan trọng đáp ứng chính sách.

• Thu hồi nợ: Agent có thể gửi follow-up tự động hoặc tạo lời nhắc promise-to-pay.

• IT Ops: Agent có thể chạy các biện pháp khắc phục rủi ro thấp như khởi động lại một dịch vụ cụ thể.

• Mua hàng: Agent có thể soạn thảo đơn mua hàng cho các danh mục được tiêu chuẩn hóa cao.

Đừng ép Giai đoạn 3 cho các lĩnh vực liên quan đến kiểm soát tài chính quan trọng, tác động pháp lý hoặc quy định cao, dữ liệu không ổn định hoặc cơ chế rollback không rõ ràng. Các bút toán trọng yếu, thay đổi master vendor nhạy cảm, quyết định lương nhân viên, phê duyệt tín dụng và thay đổi chính sách khách hàng giá trị cao nên giữ con người trong vòng lặp lâu hơn nhiều.

Đừng đợi agent của bạn được hỏi

Hầu hết các triển khai agent ban đầu đều thụ động — chúng chỉ hoạt động khi ai đó đặt câu hỏi hoặc nhấn nút. Điều đó ổn cho một copilot. Nhưng cho một mô hình vận hành agentic, mẫu hình mạnh mẽ hơn là các agent phản ứng với các thay đổi kinh doanh ngay khi chúng xảy ra.

Agent hoạt động tốt hơn nhiều khi chúng nhận được tín hiệu: đơn hàng thay đổi, ticket được leo thang, hóa đơn quá hạn, thanh toán thất bại, ngoại lệ tồn kho, onboarding nhân viên bị trì hoãn, lô hàng gặp rủi ro. Với những sự kiện như vậy, agent không cần phải poll hệ thống liên tục hoặc đợi con người nhận ra vấn đề.

Hai mẫu hình quan trọng ở đây:

• Event bus: Các hệ thống doanh nghiệp publish các sự kiện vận hành lên một nền tảng chia sẻ, và agent đăng ký nhận những gì liên quan.
• Change Data Capture (CDC): Ghi lại các thay đổi trong dữ liệu giao dịch khi sự kiện gốc không khả dụng.

Thiết kế hướng sự kiện cũng cải thiện khả năng quan sát. Mọi trigger, quyết định và hành động trở thành một chuỗi sự kiện có thể truy vết: sự kiện xảy ra, agent được kích hoạt, dữ liệu bổ sung được lấy, chính sách được kiểm tra, hành động được thực hiện hoặc leo thang. Cho các đội vận hành, rủi ro và kiểm toán, điều này lành mạnh hơn nhiều so với agent làm việc âm thầm trong nền.

Bắt đầu trước khi hệ thống của bạn hoàn hảo

Một lý do khiến các công ty tiến triển chậm là giả định rằng tất cả các hệ thống lõi phải được hiện đại hóa trước khi có thể sử dụng agent. Điều đó không thực tế. Cách tiếp cận tốt hơn là hiện đại hóa có chọn lọc dựa trên những gì các use case ưu tiên của bạn thực sự cần.

Đối với các hệ thống legacy khó động đến, hãy xây dựng một API facade hoặc lớp dịch vụ phía trước chúng. Điều này đơn giản hóa độ phức tạp, chuẩn hóa schema, giới hạn những gì agent có thể làm và tránh phụ thuộc vào screen scraping hoặc truy cập cơ sở dữ liệu trực tiếp. Agent không bao giờ được phụ thuộc vào việc click qua giao diện người dùng, truy vấn trực tiếp bảng lõi hoặc dựa vào logic ẩn mà chỉ một số ít người hiểu.

API facade cũng giúp ích cho governance: bạn có thể quyết định rằng agent chỉ được tương tác thông qua các dịch vụ đã được xác thực, thực thi chính sách và ghi log đầy đủ, có thể tắt nếu cần.

Áp dụng vào hệ thống thật: Checklist cho đội kỹ thuật

Nếu bạn đang có kế hoạch kết nối agent vào ERP/CRM, đây là những việc cần làm ngay:

1. Audit khả năng tích hợp hiện tại: Hệ thống của bạn có API real-time không? Hay chỉ có file dump hàng đêm? Nếu là legacy, hãy ưu tiên xây API facade trước.
2. Phân loại use case theo mô hình Đọc-Đề xuất-Hành động: Vẽ ma trận. Use case nào chỉ cần đọc? Use case nào có thể đề xuất? Use case nào thực sự cần tự động hành động? Đừng để một team tự quyết định mức độ tự chủ.
3. Triển khai event-driven ngay từ đầu: Đừng đợi agent bị hỏi. Hãy thiết lập event bus hoặc CDC để agent có thể phản ứng với thay đổi. Điều này cũng giúp observability tốt hơn.
4. Xác định business owner và technical owner cho mỗi kết nối: Agent chạm vào hệ thống lõi là chuyện lớn. Cần có người chịu trách nhiệm về mặt nghiệp vụ và kỹ thuật.
5. Thiết kế audit trail xuyên hệ thống: Mọi hành động của agent phải được ghi lại và có thể truy vết từ đầu đến cuối.

Điều này có nghĩa gì trong thực tế

Kết nối agent với hệ thống lõi không phải là một dự án middleware. Một khi agent chạm vào ERP, CRM hoặc HRIS, các hàm ý về governance xuất hiện ngay lập tức.

• Mọi kết nối cần một business owner và một technical owner.
• Ranh giới giữa Đọc, Đề xuất và Hành động phải được chính thức hóa — đừng để mỗi team tự quyết định mức độ tự chủ một cách độc lập.
• Audit trail phải xuyên suốt các hệ thống.
• Tác động đến lực lượng lao động phải được xem xét từ đầu: khi agent đọc và hành động trong hệ thống lõi, công việc của con người chuyển từ nhập liệu và theo dõi trạng thái sang xử lý ngoại lệ, phê duyệt và cải tiến chính sách.

Cho CIO: Lõi số của bạn đã sẵn s