Trước khi đưa tác nhân AI vào, hãy hỏi một câu quê mùa: dữ liệu khách hàng của bạn có mấy phiên bản?
Báo cáo tính sai thì họp một buổi là qua; tác nhân AI cầm dữ liệu khách hàng sai đi thực thi hành động thì thật sự sẽ có sự cố. Một khảo sát năm 2026 phỏng vấn một nghìn lãnh đạo cấp C toàn cầu cho thấy quản lý dữ liệu đã vượt chi phí và nhân tài, trở thành thách thức lớn nhất khi đưa AI vào. Bài này bàn về những kỹ năng dữ liệu cơ bản doanh nghiệp cần chuẩn bị trước khi cho tác nhân lên làm việc.
Phó tổng phụ trách kinh doanh của một nhà máy cơ khí, trong buổi trình diễn trợ lý AI đã hỏi một câu rất đơn giản: "Năm ngoái chúng ta làm ăn với Minh Phát bao nhiêu?"
Hệ thống trả về một con số. Phó tổng nhíu mày: "Không đúng, con số này nhỏ quá."
Về sau tra ra, trong ERP có ba mục khách hàng "Minh Phát", "Công ty TNHH Minh Phát" và "Minh Phat Co.", đơn hàng nằm rải ở ba mã khác nhau. AI không sai, nó thành thật cộng tổng số tiền của riêng mục "Minh Phát" và báo cho bạn. Cái sai là dữ liệu.
Kết luận của buổi trình diễn này là "AI còn chưa trưởng thành". Tôi thấy kết luận này đưa ra quá vội.
Bối cảnh sự kiện
Một khảo sát năm 2026 phỏng vấn 1.000 lãnh đạo cấp C toàn cầu đưa ra một con số rất thú vị: quản lý dữ liệu đã là thách thức lớn nhất khi đưa AI vào, chiếm 51%, vượt cả chi phí và nhân tài.
Điều này hoàn toàn khác với câu chuyện hai năm trước. Năm 2023, 2024 ai cũng lo "không tìm được người biết làm AI", "GPU quá đắt". Hai năm trôi qua, mô hình rẻ đi, công cụ dễ dùng hơn, rồi mọi người phát hiện chỗ kẹt nằm ở phía trước hơn — dữ liệu lấy không ra, đối không khớp, không ai dám đứng ra bảo đảm.
Cùng thời kỳ, một thay đổi khác đẩy mức nghiêm trọng của việc này lên một bậc: AI chuyển từ "trả lời câu hỏi" sang "thực thi hành động".
Đây là khác biệt bản chất. Trước đây AI cho bạn một bản tóm tắt, sai thì bạn tự phát hiện. Nay tác nhân đi thẳng vào CRM mở đơn, vào ERP tạo khách hàng, đi gửi thư cho khách — sai là việc đã xảy ra, bạn chỉ có thể khắc phục về sau.
Trọng điểm
Để tác nhân lên làm việc an toàn, có ba kỹ năng dữ liệu cơ bản không né được:
- Quản lý dữ liệu chủ (MDM): đảm bảo cùng một khách hàng, sản phẩm, nhà cung cấp trong mọi hệ thống là cùng một mục. Đây là cái cơ bản nhất, cũng hay bị bỏ qua nhất.
- Phân giải thực thể (entity resolution): phán đoán "Nguyễn Văn Minh", "Ông Nguyễn Văn Minh", "NGUYEN VAN MINH" có phải cùng một người không, và phải nói được vì sao. Khả năng giải thích ở ngành chịu quản lý không phải điểm cộng, mà là điều kiện bắt buộc.
- Nguồn gốc dữ liệu và quản trị truy cập: dữ liệu này từ đâu ra, ai đã động vào, tác nhân thấy được những cột nào. Không có lớp này, khi có sự cố bạn thậm chí không truy được.
Phân tích tác động thị trường
Với người dùng: Cảm nhận trực tiếp nhất của người đi làm là AI "nói rất tự tin nhưng câu trả lời sai". Phản ứng của đa số là không tin, rồi không dùng. Đây thực ra là phản ứng lý trí — một trợ lý biết bịa số còn nguy hiểm hơn không có trợ lý.
Muốn phán đoán trợ lý AI của công ty bạn có đáng tin không, có một phép thử rất quê: hỏi nó một câu bạn tự biết đáp án. Nếu đến câu này còn trả lời sai, thì khi nó trả lời câu bạn không biết, bạn dựa vào đâu để tin?
Với ứng dụng doanh nghiệp: Hiện trạng dữ liệu của doanh nghiệp có vài vấn đề đặc thù.
Thứ nhất là chồng lấn thế hệ hệ thống. Nhiều công ty đồng thời có ERP chạy mười lăm năm, CRM đưa vào năm năm trước, công cụ đám mây lên năm ngoái, ba hệ định nghĩa "khách hàng" hoàn toàn khác nhau — ERP dùng mã số thuế, CRM dùng tên công ty, công cụ marketing dùng Email. Muốn hợp thành một người, quy tắc đối chiếu ở giữa không ai nói rõ được.
Thứ hai là các công ty con trong tập đoàn mạnh ai nấy làm. Cùng một khách hàng mở tài khoản riêng ở ba công ty con, đàm phán giá riêng, cấp tập đoàn căn bản không nhìn ra "khách hàng này tổng cộng đóng góp bao nhiêu". Việc này trước khi đưa AI vào chỉ là báo cáo khó coi, sau khi đưa vào sẽ thành tác nhân báo giá sai.
Thứ ba là vấn đề biến thể của tên gọi. Có hay không "Công ty TNHH" hoặc "Công ty Cổ phần", tên tiếng Việt hay tên tiếng Anh, có hay không dấu, viết hoa toàn bộ hay viết đúng chuẩn — những vấn đề này là chuyện thường ngày. Đây cũng là lý do áp thẳng công cụ phân giải thực thể của Âu Mỹ thường không hiệu quả như kỳ vọng, nhất định phải lấy dữ liệu của mình ra kiểm.
Công cụ xử lý lớp này khá nhiều: Reltio đi hướng AI tức thời và kiểu tác nhân, Semarchy chủ đạo kỷ luật DataOps, Profisee gắn sâu với hệ sinh thái Microsoft, CluedIn dùng cơ sở dữ liệu đồ thị và tính phí theo mức dùng để hạ rào cản. Chuyên về so khớp thì có Senzing và Data Ladder. Câu hỏi đầu tiên khi chọn không phải so sánh chức năng, mà là "nó có hợp với ngăn xếp dữ liệu hiện có của tôi không".
Với lập trình viên: Nếu bạn làm tác nhân AI nội bộ doanh nghiệp, có một nguyên tắc thiết kế tôi cho là bắt buộc phải tuân theo: mỗi dữ liệu tác nhân đọc được đều phải trả lời được "cái này từ đâu ra".
Trên thực tế điều này có nghĩa vài việc. Nội dung công cụ trả về cho mô hình phải kèm dấu nguồn; mỗi lần tác nhân ghi vào phải để lại vết đầy đủ; và quan trọng nhất — khi dữ liệu có xung đột (cùng một khách hàng có hai hạn mức tín dụng khác nhau), tác nhân nên dừng lại hỏi người, chứ không tự chọn một cái.
Thiết kế này làm tác nhân trông "hơi ngốc", vì nó sẽ thường nói "tôi tra được hai dữ liệu không nhất quán, xin xác nhận". Nhưng cái ngốc này là đúng. Tác nhân biết tự đoán mới là rủi ro thật sự.
Xu hướng phát triển tương lai
Tôi quan sát thấy hai hướng.
Thứ nhất, những thứ như MDM vốn bị xem là việc nội bộ của IT đang trở thành điều kiện tiền đề của AI. Trước đây dự án MDM khó nhất là thuyết phục sếp vì sao phải bỏ tiền làm việc không nhìn thấy; nay cách nói đổi thành "tác nhân cầm dữ liệu sai sẽ có sự cố", lập luận này mạnh hơn nhiều.
Thứ hai, bản thân công cụ đang chuyển sang "cung cấp ngữ cảnh có quản trị cho tác nhân". Đầu ra của MDM truyền thống là bản ghi vàng cho người xem, đầu ra hiện nay là dịch vụ dữ liệu cho tác nhân gọi. Thay đổi này sẽ định nghĩa lại thị trường, và khiến một loạt công cụ cũ chỉ làm xử lý theo lô bị đào thải.
Nhưng tôi phải dội một chút nước lạnh: công cụ không giải quyết được vấn đề quản trị. "Dữ liệu khách hàng lấy phiên bản của ai làm chuẩn", "định nghĩa cột ai nói mới tính", "sai thì ai chịu" — ba câu này là chính trị tổ chức, không phải chức năng phần mềm. Mua nền tảng nhưng không có một vai trò quản trị dữ liệu có thực quyền thì dự án sẽ thành các cuộc họp phối hợp liên phòng ban vô tận. Đây là nguyên nhân thất bại phổ biến nhất của dự án MDM, hai mươi năm nay không đổi.
Học viện TheAI tổng kết và nhận định
Quay lại ví dụ nhà máy cơ khí ở đầu. Việc họ làm sau đó rất đơn giản: bỏ ra sáu tuần, khử trùng lặp và chuẩn hóa một lần dữ liệu chủ khách hàng trong ERP, đặt ra quy tắc "mã số thuế là mã định danh duy nhất", và chỉ định bộ phận tài chính làm chủ sở hữu dữ liệu chủ khách hàng.
Trình diễn lại lần nữa, con số đúng.
Nhận định: thành bại của dự án AI, tám mươi phần trăm quyết định trước khi bạn mở mô hình. Hãy xác nhận dữ liệu khách hàng của bạn chỉ có một phiên bản, rồi mới bàn dùng mô hình nào.
Gợi ý cụ thể cho bạn đọc, tôi nói ba việc có thể bắt đầu ngay tuần tới:
Một, làm một lần "phép thử tự hỏi tự đáp". Chọn năm câu hỏi vận hành mà bạn tự biết đáp án đúng, đi hỏi công cụ AI của công ty hoặc tra thẳng cơ sở dữ liệu. Những câu trả lời sai chính là lỗ hổng dữ liệu của bạn. Việc này không cần ngân sách, một buổi chiều là xong.
Hai, chỉ định "nguồn sự thật duy nhất" trước, rồi mới bàn mua công cụ. Dữ liệu khách hàng lấy ERP làm chuẩn hay CRM làm chuẩn? Dữ liệu sản phẩm lấy của ai làm chuẩn? Quyết định này không tốn tiền, nhưng là tiền đề cho mọi việc phía sau. Quyết không nổi thì mua hệ thống nào cũng vô ích.
Ba, phạm vi phải nhỏ. Đừng mở một dự án "quản trị dữ liệu toàn công ty", cái đó chắc chắn làm ba năm rồi chìm xuồng. Chọn một lĩnh vực dữ liệu tác nhân hay dùng nhất (thường là khách hàng), ba tháng làm ra phiên bản sạch, dùng nó chứng minh giá trị, rồi mới mở rộng.
Đọc thêm: Khả năng quan sát và quản trị tác nhân AI bàn về giám sát sau khi tác nhân lên; Ai kiểm mã do AI tạo là phiên bản của cùng logic này ở phía phát triển.
Nguồn tham khảo
- McKinsey: The State of AI (Global Survey)
- Gartner Magic Quadrant for Master Data Management Solutions (đăng lại trên website các hãng)
- Thuyết minh khảo sát chính thức của Semarchy
Tổng hợp theo thông tin công khai, các con số khảo sát căn cứ theo báo cáo gốc.
Câu hỏi thường gặp
Quản lý dữ liệu chủ (MDM) là gì? Khác kho dữ liệu ở đâu?
Kho dữ liệu giải quyết việc "gom dữ liệu lại để phân tích", MDM giải quyết việc "cùng một khách hàng trong năm hệ thống rốt cuộc có phải cùng một người". Cái trước để phân tích, cái sau để vận hành. Bạn có thể có kho dữ liệu rất đẹp mà dữ liệu chủ khách hàng vẫn hỗn loạn — hai việc này không tự giải quyết cho nhau.
Doanh nghiệp nhỏ có cần làm không?
Cần, nhưng quy mô hoàn toàn khác. Cách làm của doanh nghiệp nhỏ không phải mua một bộ nền tảng MDM, mà làm trước hai việc: chỉ định một hệ thống làm "nguồn sự thật duy nhất của dữ liệu khách hàng", và đặt ra ai có quyền thêm và sửa dữ liệu khách hàng. Hai việc này không tốn tiền, nhưng chặn được tám mươi phần trăm hỗn loạn dữ liệu.
Tác nhân AI đọc dữ liệu sai thì sao? Tình huống tệ nhất là gì?
Điển hình nhất là khách hàng trùng lặp: tác nhân phán đoán đây là khách mới, mở tài khoản thứ hai, gửi hợp đồng thứ hai, gửi thư chào mừng lần hai. Nghiêm trọng hơn là trộn dữ liệu của hai khách trùng tên — gửi sai báo giá, tiết lộ lịch sử giao dịch sai, việc này trong tài chính và y tế là sự cố mức phải khai báo.
Nên bắt đầu từ lĩnh vực dữ liệu nào?
Bắt đầu từ lĩnh vực AI hay dùng nhất, thường là khách hàng hoặc sản phẩm. Đừng làm hết mọi lĩnh vực một lúc, đó là dự án ba năm. Chọn một cái phạm vi rõ, điểm đau rõ (ví dụ "dữ liệu khách hàng mà tác nhân bán hàng cần tra"), ba tháng làm ra một phiên bản sạch, rồi mới mở rộng.