Agent AI của bạn chỉ thông minh bằng nền tảng dữ liệu của bạn

Phòng tài chính của bạn vừa xây một agent giúp chốt sổ cuối tháng. Nó kết nối vào ERP, đọc các bút toán, và tự động soạn báo cáo đối chiếu. Trong bản demo, mọi thứ chạy như mơ.

Rồi đến kỳ chốt sổ thật. Agent đọc sai trạng thái hóa đơn. Nó đề xuất sai tài khoản hạch toán. Nó leo thang các ngoại lệ đã được giải quyết từ trước. Cả team phải thức cuối tuần để kiểm tra lại từ đầu.

Vấn đề không nằm ở model. Cũng không phải framework agent. Vấn đề là dữ liệu.

Hầu hết các công ty đều mải mê chọn model nào, dùng agent platform nào, hay cách orchestrate workflow ra sao. Nhưng trong bối cảnh doanh nghiệp, các model ngày càng trở nên dễ thay thế. Thứ không thể mua hay copy được là bối cảnh riêng của công ty bạn: cách bạn định nghĩa "khách hàng", luồng phê duyệt của bạn vận hành thế nào, thế nào là một ngoại lệ chính sách, và các thực thể kinh doanh liên quan với nhau ra sao.

Không có nền tảng dữ liệu vững chắc, agent của bạn sẽ nói rất tự tin nhưng sai. Nó sẽ đưa ra các đề xuất trông có vẻ hợp lý nhưng vi phạm quy tắc kinh doanh thực tế. Đây không phải là ảo giác (hallucination) của model — đây là thứ nguy hiểm hơn nhiều cho vận hành.

Ba lớp phân tách một agent demo khỏi agent sản xuất: nền tảng dữ liệu, tầng thực thi, và runtime quản trị.

Cái giá thực sự của "ảo giác vận hành"

Chúng ta thường nói về AI hallucination — model tự bịa ra thông tin. Trong môi trường doanh nghiệp, một vấn đề âm thầm hơn xuất hiện: ảo giác vận hành (operational hallucination). Đầu ra của agent nghe có vẻ đáng tin, nhưng nó sai so với thực tế kinh doanh của bạn.

Agent tài chính của bạn bảo một hóa đơn chưa thanh toán — nhưng trạng thái trong ERP đã thay đổi. Agent nhân sự trích dẫn chính sách nghỉ phép từ một tài liệu đã bị thay thế sáu tháng trước. Agent chuỗi cung ứng chuyển hướng lô hàng mà không hiểu ràng buộc tồn kho thực tế.

Vấn đề không chỉ là độ chính xác. Vấn đề là các agent bắt đầu ảnh hưởng đến hành động, ưu tiên, và quyết định. Mỗi câu trả lời sai tạo ra công việc làm lại, chậm trễ, hoặc rủi ro tuân thủ.

Đây là lý do khoảng cách giữa một pilot thành công và một production rollout thất bại hầu như không bao giờ đến từ chất lượng hội thoại. Nó đến từ sự sẵn sàng của dữ liệu.

Dữ liệu có cấu trúc: Xương sống vận hành

Nếu agent của bạn cần hành động trong các hệ thống doanh nghiệp — kiểm tra trạng thái, xác thực điều kiện, kích hoạt workflow — nó phụ thuộc vào dữ liệu có cấu trúc. Hồ sơ khách hàng, đơn hàng, hóa đơn, dữ liệu master nhà cung cấp, hồ sơ nhân viên, hợp đồng, ticket.

Nhưng có ERP hay CRM không có nghĩa dữ liệu của bạn đã sẵn sàng cho agent. Dữ liệu có cấu trúc cần sáu đặc tính sau để hữu dụng:

Định nghĩa kinh doanh nhất quán. "Khách hàng đang hoạt động" nghĩa là gì? Khi nào một đơn hàng được "hoàn thành"? Nếu định nghĩa khác nhau giữa các phòng ban hoặc quốc gia, agent của bạn sẽ đưa ra quyết định không nhất quán.

Quyền sở hữu rõ ràng. Mỗi lĩnh vực dữ liệu cần một chủ sở hữu kinh doanh, không chỉ một quản trị viên kỹ thuật. Không có quyền sở hữu, các vấn đề chất lượng dữ liệu bị gán nhãn "lỗi hệ thống" trong khi agent của bạn tiếp tục thất bại.

Dòng dõi có thể truy vết. Agent của bạn cần biết dữ liệu đến từ đâu. Nếu một trường trong dashboard đến từ nhiều lớp biến đổi, bạn có chắc agent đang đọc trạng thái kinh doanh hiện tại?

Chất lượng được giám sát. Tính đầy đủ, tính duy nhất, tính nhất quán, tính kịp thời — những điều này không thể được giả định. Danh sách nhà cung cấp trùng lặp hay sơ đồ tổ chức lỗi thời sẽ phá vỡ workflow của agent.

Ngữ nghĩa mạnh mẽ. Dữ liệu cần ý nghĩa có thể đi xuyên qua các hệ thống. Đây là lúc các mô hình dữ liệu doanh nghiệp và quản lý dữ liệu master trở nên quan trọng.

Truy cập an toàn. Agent không nên đọc trực tiếp các bảng core. Chúng cần các interface thực thi quyền, duy trì audit trail, và cung cấp schema ổn định.

Dữ liệu phi cấu trúc: Nơi bối cảnh thực sự sống

Nhiều tổ chức chỉ nhận ra giá trị của dữ liệu phi cấu trúc khi bắt đầu xây dựng agent. Chính sách, hợp đồng, email, bản ghi cuộc gọi, SOP, bài viết kiến thức — trước đây chúng là kho lưu trữ thụ động. Trong agentic AI, chúng trở thành các tầng bối cảnh chủ động.

Trạng thái ticket khách hàng của bạn sống trong CRM, nhưng bối cảnh thực sự — những gì khách hàng đã được hứa, giọng điệu cảm xúc, nguyên nhân gốc rễ — sống trong bản ghi và lịch sử chat. Dữ liệu master nhà cung cấp sạch sẽ, nhưng các điều khoản thương mại và ngoại lệ hợp đồng sống trong PDF. Dữ liệu nhân viên ở HRIS, nhưng chính sách địa phương và ngoại lệ FAQ sống trong cổng thông tin và email.

Dữ liệu phi cấu trúc yêu cầu một pipeline có kỷ luật, không chỉ "upload tài liệu vào vector store." Bạn cần: ingestion có kiểm soát từ các nguồn có thẩm quyền, phân loại để tách chính sách khỏi bản nháp, chunking thông minh với metadata, retrieval tôn trọng quyền và bối cảnh, và quản lý vòng đời để tài liệu hết hạn không còn hoạt động.

Sự cám dỗ là đổ tất cả vào. Hãy chống lại nó. Bắt đầu với các kho dữ liệu có giá trị cao, có thẩm quyền: SOP chính thức, hợp đồng đang hiệu lực, bài viết kiến thức đã xác thực, tài liệu chính sách đã được quản lý. Không phải mọi file công ty bạn từng tạo ra.

Quản trị phải chuyển từ văn bản chính sách sang runtime

Quản trị dữ liệu truyền thống dừng lại ở tài liệu, ủy ban, và kiểm soát thủ công. Đối với agentic AI, quản trị phải thực thi tại runtime.

Câu hỏi chuyển từ "ai có thể truy cập dữ liệu này?" thành "ai có thể truy cập dữ liệu này thông qua agent, cho mục đích gì, trong workflow nào, với mức độ tự chủ nào, và truy cập này dẫn đến insight hay hành động?"

Quyền phải được kiểm tra tại thời điểm retrieval, không phải sau khi câu trả lời được sinh ra. Agent nhân sự của bạn không được kéo dữ liệu lương cho người dùng không được ủy quyền. Agent mua sắm của bạn không được phơi bày hợp đồng chiến lược cho người hỏi thông thường. Agent tài chính của bạn không được hiển thị dữ liệu thực thể ngoài phạm vi của người dùng.

Audit trail phải giải thích không chỉ rằng truy cập đã xảy ra, mà còn dữ liệu nào được lấy, từ nguồn nào, dưới quyền gì, trong workflow nào, và nó ảnh hưởng thế nào đến quyết định của agent. Khi một agent đưa ra đề xuất sai, bạn cần truy vết xem vấn đề là chất lượng dữ liệu, retrieval sai, thiếu metadata, hay chính sách không được thực thi.

Trước khi mở rộng, hãy tự hỏi những câu này

Sự khác biệt giữa pilot và production là sự sẵn sàng của dữ liệu. Trước khi mở rộng dấu chân agentic AI, hãy kiểm tra xem:

• Các lĩnh vực dữ liệu có cấu trúc ưu tiên đã có định nghĩa kinh doanh nhất quán chưa
• Dữ liệu khách hàng, nhà cung cấp, nhân viên, và hóa đơn đã có chủ sở hữu rõ ràng chưa
• Chất lượng dữ liệu có được giám sát về tính đầy đủ, nhất quán, và kịp thời không
• Agent truy cập dữ liệu có cấu trúc thông qua các interface thực thi quyền không
• Kho dữ liệu phi cấu trúc đã được quản lý và phân biệt với bản nháp chưa
• Metadata như phiên bản, ngày hiệu lực, khu vực, và phân loại đã tồn tại chưa
• Retrieval có tôn trọng quyền nhất quán với hệ thống nguồn không
• Chính sách lưu giữ đã tồn tại cho tài liệu, bản ghi, và lịch sử tương tác không
• Bạn có thể truy vết agent đã dùng dữ liệu nào để đưa ra đề xuất không

Hãy cảnh giác với các dấu hiệu cảnh báo: "Chúng ta sẽ dọn dẹp dữ liệu sau." Dữ liệu master cốt lõi vẫn đang tranh cãi giữa các phòng ban. Agent kéo câu trả lời từ tài liệu không rõ thẩm quyền. Service account có quyền truy cập quá rộng. Không có metadata phiên bản trên chính sách. Retrieval bỏ qua quyền người dùng.

Đây không phải là nợ kỹ thuật. Chúng là các rào cản mở rộng.

Áp dụng vào hệ thống thật

Đối với engineering leader và platform team, điều này chuyển thành các quyết định kiến trúc cụ thể. Framework agent của bạn không nên truy vấn trực tiếp production database. Thay vào đó, hãy xây một tầng truy cập dữ liệu (data access layer) phơi bày các view đã được quản lý với quyền được thực thi. Sử dụng metadata registry để gắn thẻ tài liệu với phiên bản, ngày hiệu lực, và khu vực. Triển khai kiểm soát truy cập tại thời điểm retrieval để kiểm tra phạm vi người dùng trước khi trả về bối cảnh. Và thiết kế observability ghi log mọi điểm chạm dữ liệu — không chỉ các cuộc gọi model.

Data engineer của bạn nên coi sự sẵn sàng cho agent là một yêu cầu hạng nhất, ngang hàng với báo cáo và phân tích. Team quản trị của bạn nên định nghĩa các chính sách runtime, không chỉ tài liệu tĩnh. Và product owner của bạn nên xác thực hành vi của agent dựa trên trạng thái kinh doanh thực tế, không phải dữ liệu demo.

Kết luận

Câu hỏi trung thực nhất bạn có thể tự hỏi trước khi xây thêm agent không phải là "dùng model nào?" Mà là "nguồn sự thật nào cho dữ liệu của chúng ta, ai sở hữu nó, và làm thế nào để đảm bảo agent của chúng ta chỉ hành động dựa trên những gì có thật?"

Để tìm hiểu sâu hơn về kiến trúc và các mẫu quản trị được thảo luận ở đây, hãy xem bài viết gốc về nền tảng dữ liệu cho agentic AI.