AI Agent của bạn chỉ tốt bằng Data Product bạn xây — bài học từ những lỗi đắt giá

Mỗi đội ngũ tôi từng nói chuyện khi bắt tay xây dựng agentic AI đều có chung một giả định: "Chúng tôi có dữ liệu rồi. Sẵn sàng hết."

Họ chỉ vào data lake, warehouse, dashboard BI, kho tài liệu đã index. Với báo cáo truyền thống, như vậy là đủ. Nhưng ngay khi một agent chạm vào đống dữ liệu đó, mọi thứ vỡ vụn. Agent đọc số, đưa ra quyết định — sai một cách tinh vi hoặc thảm khốc.

Không phải vì model kém. Mà vì dữ liệu chưa được đóng gói theo cách agent có thể hiểu một cách an toàn.

Tôi thấy pattern này lặp lại khắp các ngành. Một đội tài chính muốn agent hỗ trợ chốt sổ cuối tháng, nhưng trial balance pha trộn số liệu sơ bộ và chính thức. Một đội procurement muốn agent xử lý yêu cầu mua hàng, nhưng "nhà cung cấp đã phê duyệt" lại mang nghĩa khác nhau giữa hệ thống sourcing và ERP. Một đội customer ops muốn agent xử lý khiếu nại, nhưng "khách hàng đang hoạt động" không có định nghĩa thống nhất giữa các phòng ban.

Dữ liệu có sẵn. Agent không thể dùng đúng cách.

Đây là khoảng trống mà hầu hết tổ chức bỏ qua. Và nó là ranh giới giữa một bản demo ấn tượng và một hệ thống production bạn có thể tin tưởng.

Agent thực sự cần gì? (Gợi ý: không phải raw data)

Sự chuyển dịch từ dữ liệu có sẵn sang dữ liệu có thể dùng được bởi agent là quyết định kiến trúc quan trọng nhất bạn sẽ đưa ra.

Con người phân tích có thể chịu được sự mơ hồ. Họ mở ba dashboard, đối chiếu định nghĩa, dùng kiến thức tổ chức để lấp đầy khoảng trống. Agent thì không. Chúng cần đầu vào rõ ràng: trường này đại diện cho cái gì? Dữ liệu tươi đến đâu? Khi nào an toàn để dùng? Với mục đích gì? Ai chịu trách nhiệm nếu định nghĩa thay đổi?

Đây là lúc khái niệm data product sẵn sàng cho agent trở nên thiết yếu. Một dataset trở thành data product khi nó mang nhiều hơn dữ liệu — nó mang một hợp đồng vận hành. Với agent, hợp đồng đó cần đặc biệt chặt chẽ.

Tối thiểu, một data product sẵn sàng cho agent cần:

• Schema ổn định, rõ ràng
• Ngữ nghĩa được tài liệu hóa (mỗi trường có nghĩa là gì trong ngôn ngữ kinh doanh)
• Chủ sở hữu nghiệp vụ và chủ sở hữu kỹ thuật
• Kỳ vọng về độ tươi và ngưỡng chất lượng
• Lineage cơ bản
• Chính sách truy cập có thể đánh giá tại runtime
• Các hành động hoặc quy tắc sử dụng được phép

Thiếu những yếu tố này, agent không nhìn vào dữ liệu. Nó nhìn vào một đống trường không có ngữ cảnh.

Sự chuyển đổi từ raw data sang product sẵn sàng cho agent yêu cầu một control gate, hợp đồng ngữ nghĩa và retrieval nhận biết quyền — không chỉ index tốt hơn.

Hợp đồng ngữ nghĩa: Ý nghĩa, không chỉ format

Nhiều tổ chức đã có schema registry hoặc tài liệu API. Quan trọng, nhưng chưa đủ.

Agent không chỉ cần biết có một trường tên revenue. Nó cần biết đó là booked revenue, billed revenue, recognized revenue hay net revenue. Nó cần biết margin có thể là gross margin, contribution margin hay margin sau các phân bổ cụ thể. Nó cần biết active customer có nghĩa là "giao dịch trong 90 ngày qua", "có hợp đồng đang hiệu lực" hay "chưa chính thức rời đi".

Đây là hợp đồng ngữ nghĩa — một lớp giải thích ý nghĩa kinh doanh đằng sau mỗi trường, các quy tắc chi phối nó, khi nào nên và không nên dùng, và những giả định nào được tích hợp sẵn.

Không có hợp đồng này, agent lấp đầy khoảng trống bằng suy luận. Và suy luận của chúng thường trông hợp lý nhưng sai về mặt vận hành.

Trong doanh nghiệp, hợp đồng ngữ nghĩa nên là một phần của semantic layer rộng hơn, thống nhất ngôn ngữ giữa BI, ứng dụng vận hành, AI agent và người dùng nghiệp vụ. Bởi vì nhiều xung đột dữ liệu không phải vấn đề chất lượng kỹ thuật — chúng là vấn đề định nghĩa. Đội controllership, đội FP&A và agent hỗ trợ chốt sổ của bạn đều có thể dùng "material variance" để chỉ những thứ khác nhau nếu semantic layer không được chuẩn hóa.

Hợp đồng ngữ nghĩa cần nghiêm ngặt nhất với các data product xuyên chức năng, chạm đến giao dịch hoặc phê duyệt, thực thi hành động, hoặc sống trong các lĩnh vực được quản lý như HR, tài chính, pháp lý và dữ liệu khách hàng.

Permission-aware retrieval: Truy cập phải theo ngữ cảnh

Agent không bao giờ nên truy xuất dữ liệu chỉ vì nó tồn tại trong index, lake hay vector store. Truy cập phải tuân theo: người dùng là ai, vai trò của họ, workflow đang chạy, mục đích sử dụng và độ nhạy của dữ liệu.

Đây là cốt lõi của permission-aware retrieval.

Nhiều triển khai RAG bắt đầu với pattern đơn giản: index mọi thứ, truy xuất thứ liên quan nhất về mặt ngữ nghĩa. Trong doanh nghiệp, điều này nguy hiểm. Tài liệu liên quan nhất không phải lúc nào cũng là tài liệu được phép nhất. Một agent onboarding HR có thể tìm thấy tài liệu lương thưởng liên quan đến "phúc lợi" nhưng không nên hiển thị. Một agent hỗ trợ hợp đồng pháp lý có thể tìm thấy hợp đồng liên quan về nội dung nhưng thuộc khu vực pháp lý hoặc đơn vị kinh doanh khác.

Một sai lầm phổ biến là áp dụng kiểm soát truy cập chỉ tại thời điểm index. Nhưng quyền thay đổi dựa trên ai đang gọi agent, kênh nào họ dùng, workflow đang ở giai đoạn nào và họ đang cố gắng làm gì. Permission-aware retrieval phải được đánh giá tại runtime.

Với hệ thống agentic, role-based access thường quá thô. Hai người cùng vai trò không nhất thiết nên dùng cùng dữ liệu cho các mục đích khác nhau. Một manager có thể xem dữ liệu team để đánh giá hiệu suất nhưng không để điều tra lương thưởng. Một agent tài chính có thể đọc chi tiết hóa đơn để xử lý ngoại lệ nhưng không được tổng hợp vendor summary xuyên pháp nhân nếu không có mandate phù hợp.

Điều này thêm phức tạp. Metadata cần phong phú hơn. Tích hợp IAM và policy engine cần chặt chẽ hơn. Độ trễ có thể tăng. Thiết kế index trở nên phức tạp hơn. Nhưng với HR, tài chính, pháp lý, dữ liệu khách hàng và vận hành được quản lý, đây không phải tùy chọn. Đó là yêu cầu tối thiểu để ngăn agent của bạn trở thành một đường rò rỉ dữ liệu mới.

Chất lượng và độ tươi: Agent phải biết khi nào dừng lại

Một trong những rủi ro thực tế nhất trong agentic AI không phải là hallucination. Mà là agent tự tin hành động trên dữ liệu cũ, không đầy đủ hoặc đang chuyển tiếp.

Tôi đã thấy agent procurement đề xuất vendor dựa trên trạng thái phê duyệt chưa đồng bộ từ due diligence. Agent chốt sổ tài chính viết commentary từ số liệu sơ bộ trong khi số cuối đã thay đổi. Agent dịch vụ khách hàng hứa hoàn tiền dựa trên trạng thái đơn hàng chưa cập nhật. Agent IT incident route remediation sai hệ thống vì CMDB đã lỗi thời.

Trong mọi trường hợp, vấn đề không phải model. Mà là data product không mang đủ tín hiệu chất lượng và độ tươi.

Một data product sẵn sàng cho agent cần ít nhất bốn cơ chế:

1. Kiểm tra chất lượng — xác thực cơ bản rằng trường có dữ liệu, schema khớp, referential integrity được giữ
2. Chỉ báo độ tươi — dữ liệu được cập nhật lần cuối khi nào, chu kỳ refresh dự kiến ra sao, còn trong cửa sổ sử dụng được không
3. Phát hiện bất thường — nếu có spike hoặc pattern bất thường, agent không nên cho rằng dữ liệu hợp lệ
4. Hành vi dự phòng — nếu chất lượng hoặc độ tươi không đạt ngưỡng, agent cần biết phải làm gì: dừng lại, yêu cầu thêm dữ liệu, dùng nguồn thay thế, hoặc chuyển cho con người

Khả năng bị bỏ qua nhiều nhất là agent nói "Tôi không có đủ dữ liệu." Nhiều đội quá tập trung vào việc bắt agent luôn trả lời. Nhưng trong doanh nghiệp, hành vi đúng thường là dừng lại. Một agent xử lý ngoại lệ AP không nên phân loại mismatch nếu goods receipt chưa được nhập. Một agent HR không nên trả lời câu hỏi về phúc lợi nếu dữ liệu eligibility chưa chốt. Một agent supply chain không nên đề xuất rerouting nếu shipment feeds chưa cập nhật.

Về mặt governance, một agent biết khi nào dừng lại có giá trị hơn một agent luôn tỏ ra tự tin.

Hệ quả kiến trúc

Xem dữ liệu và kiến thức như product cho agent thay đổi cách bạn xây dựng.

Đầu tiên, quyền sở hữu phải rõ ràng. Mỗi data product cần một chủ sở hữu nghiệp vụ cho định nghĩa và cách sử dụng được phép, một chủ sở hữu kỹ thuật cho phân phối và chất lượng, và có thể một chủ sở hữu rủi ro/tuân thủ cho các lĩnh vực nhạy cảm. Không có chủ sở hữu, agent sẽ dùng bất cứ dữ liệu nào có sẵn, nhưng không ai chịu trách nhiệm khi định nghĩa thay đổi hoặc chất lượng giảm.

Thứ hai, catalog trở thành control plane. Bạn cần một catalog theo dõi không chỉ data product tồn tại ở đâu, mà còn hợp đồng ngữ nghĩa, kỳ vọng độ tươi, trạng thái chất lượng, chính sách truy cập và cấp độ rủi ro. Điều này cho phép agent platform coi data product như các dependency có thể quản lý, không phải kết nối ad-hoc.

Thứ ba, đánh giá agent phải kiểm tra cả data product. Khi agent thất bại, đừng luôn đổ lỗi cho model. Thường nguyên nhân gốc là sự mơ hồ ngữ nghĩa, thiếu metadata, độ tươi kém hoặc quyền không theo kịp runtime. Đánh giá của bạn nên hỏi: data product có phù hợp không? Hợp đồng ngữ nghĩa có đủ rõ không? Fallback có hoạt động khi chất lượng giảm không? Retrieval có tôn trọng policy không?

Áp dụng vào hệ thống thật: Bắt đầu từ một domain

Đừng cố làm tất cả cùng lúc. Chọn một domain — chốt sổ tài chính, hỗ trợ khách hàng hoặc procurement — và audit các data product hiện tại của bạn dựa trên ba yêu cầu: hợp đồng ngữ nghĩa, permission-aware retrieval và tín hiệu chất lượng/độ tươi.

Bạn sẽ thấy lỗ hổng. Không sao. Mục tiêu là làm cho một data product sẵn sàng cho agent, test với một workflow agent thực tế, sau đó mở rộng. Pattern này scale tốt hơn là cố retrofit toàn bộ data lake cùng lúc.

Đầu tư vào metadata layer của bạn. Một catalog theo dõi ngữ nghĩa, độ tươi, quyền sở hữu và chính sách truy cập không phải nice-to-have — đó là hạ tầng mà agent platform của bạn sẽ phụ thuộc vào. Không có nó, mỗi agent mới trở thành một dự án tích hợp bespoke.

Checklist triển khai cho đội ngũ của bạn

• [ ] Xác định một data product "mẫu" trong domain ưu tiên
• [ ] Ghi lại hợp đồng ngữ nghĩa cho mọi trường: ý nghĩa kinh doanh, phạm vi sử dụng, giả định
• [ ] Thiết lập freshness indicator và quality threshold cho data product đó
• [ ] Xây dựng cơ chế permission-aware retrieval: runtime evaluation, không chỉ index-time
• [ ] Định nghĩa fallback behavior: agent dừng lại, hỏi thêm, hay escalate khi data không đủ tin cậy
• [ ] Test agent với kịch bản data cũ, data thiếu, data sai — không chỉ happy path
• [ ] Gán business owner và technical owner cho data product

Câu hỏi quan trọng nhất

Xây dựng một doanh nghiệp agentic không chỉ là về model, orchestration hay tool calling. Nó là về đóng gói dữ liệu doanh nghiệp thành các product mà agent có thể dùng với cùng kỷ luật bạn áp dụng cho API, workflow và kiểm soát bảo mật.

Các tổ chức hiểu điều này sẽ di chuyển nhanh hơn từ những bản demo ấn tượng đến các hệ thống vận hành thực sự có thể tin cậy.

Vậy đây là câu hỏi để mang về cho đội của bạn: Agent của bạn có biết khi nào dừng lại vì dữ liệu không đủ tin cậy không?

Nếu câu trả lời không phải "có", bạn