Vì Sao AI Agent Của Bạn Suýt Gửi Dữ Liệu Khách Hàng Cho Người Lạ? Thứ Doanh Nghiệp AI Thực Sự Còn Thiếu Là Context Engineering

Vị quản lý phụ trách vận hành hệ thống chăm sóc khách hàng nhìn thấy email cảnh báo khẩn cấp đó chỉ mười phút trước khi tan làm.

Một khách hàng nhắn hỏi qua kênh trực tuyến "tôi có thể xem đơn hàng của bạn tôi được không", và AI Agent chăm sóc khách hàng vừa ra mắt chưa lâu của công ty đã trả lời ngay lập tức — bằng cách gửi thẳng toàn bộ lịch sử đơn hàng và thông tin liên hệ của một khách hàng khác cho người hỏi. Đội an ninh mạng phải tắt khẩn cấp tính năng này trong vòng hai giờ, còn bộ phận pháp lý yêu cầu lập báo cáo sự cố: ai đã phê duyệt cho Agent này lên vận hành? Vì sao nó lại "nhìn thấy" được dữ liệu lẽ ra không nên thấy?

(Đây là một tình huống minh họa nhằm mô tả một khuôn mẫu đã phổ biến trong ngành, không phải một vụ việc có thật của khách hàng cụ thể nào.)

Đây không phải một giả định giật gân. Nhà quan sát chiến lược doanh nghiệp Bernard Marr, trong podcast về xu hướng kinh doanh và công nghệ do ông dẫn dắt, đã thẳng thắn chỉ ra rằng những sự cố kiểu này đã từng xảy ra ngoài đời thực: "Chúng tôi đã thấy điều này trong thực tế, nơi các AI Agent xóa mất dữ liệu nghiệp vụ then chốt, làm rò rỉ những bí mật kinh doanh lẽ ra không nên tiết lộ, chỉ vì một số cơ chế bảo vệ chưa được thiết lập, nên nó cứ thế giao dữ liệu khách hàng ra ngoài." Trong tập podcast đó, ông đã mời Masimo Merlo từ Elastic để cùng mổ xẻ căn nguyên thật sự đằng sau chuỗi sự cố này — không phải vì mô hình chưa đủ thông minh, mà vì phần lớn doanh nghiệp đang thiếu mất một mảnh ghép mang tên "context engineering".

Bạn tưởng vấn đề nằm ở mô hình, nhưng thực ra nằm ở "nền móng"

Masimo mở đầu thẳng thắn: giai đoạn thử nghiệm của AI doanh nghiệp đã kết thúc. Phần lớn các tổ chức đã chạy qua giai đoạn pilot, và giờ đây họ đang đối mặt với khoảng cách khó chịu giữa kết quả mà AI từng hứa hẹn và những gì nó thực sự mang lại.

Ông kéo nguyên nhân về một trục thời gian dài hơn: phần mềm doanh nghiệp được xây dựng theo từng lớp trong suốt bốn, năm mươi năm qua — lớp dữ liệu, lớp context, lớp logic ứng dụng, lớp trải nghiệm người dùng. Còn AI lần này lại xáo trộn và tái cấu trúc tất cả các lớp đó cùng một lúc. Nếu doanh nghiệp nghĩ rằng chỉ cần "gắn mô hình vào hệ thống hiện có" là phép màu sẽ tự xảy ra, họ sẽ sớm nhận ra dòng dữ liệu chưa bao giờ được thiết kế cho AI, và cơ chế quản trị cũng không theo kịp tốc độ này. Gắn một mô hình rất mạnh vào một nền móng chưa được dọn dẹp không tạo ra chuyển đổi, mà chỉ tạo ra — theo lời Masimo — một "phiên bản tự tin hơn của vấn đề cũ". Một trong những điều AI làm rất giỏi, chính là đưa ra câu trả lời sai một cách vô cùng hiệu quả khi bị nạp vào thông tin sai.

Nếu AI là bộ não, thì Context chính là trí nhớ

Vậy rốt cuộc context engineering đang giải quyết điều gì? Masimo đưa ra một phép ví von mà ông từng nghe và thấy rất đắt: nếu AI là bộ não, thì context chính là trí nhớ. Bộ não xử lý nhanh đến đâu, nếu không có trí nhớ — không có kinh nghiệm, không có những con đường đã từng đi qua — cũng không thể phán đoán được nên làm gì ngay lúc này.

Áp vào doanh nghiệp cũng là câu chuyện tương tự: một mô hình được huấn luyện trên dữ liệu công khai của toàn thế giới sẽ không tự động hiểu "bạn" — không hiểu khách hàng của bạn, chính sách của bạn, những gì từng xảy ra trong quá khứ của bạn, mức độ chấp nhận rủi ro của bạn, hay mục tiêu bạn muốn đạt được. Nó chỉ xử lý dữ liệu và đưa ra một câu trả lời nghe có vẻ hợp lý nhưng thực chất khá chung chung. Context engineering, với tư cách một môn học, chính là biến việc "kết nối đúng dữ liệu, đúng mô hình, vào đúng thời điểm" thành một kỷ luật có hệ thống: xác định rõ mô hình được phép nhìn thấy những gì, và dựng lên các lớp bảo vệ để những gì nó trả ra là thứ đáng tin cậy, có thể yên tâm đem đi thực thi.

Từ "phiền toái" đến "nguy hiểm": Khi AI bắt đầu tự ra quyết định

Masimo đặc biệt nhấn mạnh một bước ngoặt: khi AI chỉ đơn thuần trả lời câu hỏi, trả lời sai cùng lắm chỉ là một sự phiền toái, bạn có thể phát hiện và sửa ngay tại chỗ; nhưng khi AI trở thành một Agent có thể tự đề xuất, tự quyết định, tự hành động, cùng một câu trả lời sai đó lại mang tính chất hoàn toàn khác — nó có thể trực tiếp biến thành rủi ro kinh doanh, rủi ro pháp lý, hoặc sự cố an ninh.

Ông đưa ra hai ví dụ cụ thể. Một là Agent trong trung tâm vận hành an ninh (SOC): nó cần nhìn thấy thông tin đe dọa theo thời gian thực, lịch sử sự cố trong quá khứ, quy trình leo thang rõ ràng — thiếu bất kỳ yếu tố nào, phán đoán của nó cũng sẽ lệch lạc. Hai là Agent phát hiện gian lận: nó không thể chỉ nhìn vào giao dịch trước mắt, mà còn phải biết lịch sử giao dịch trước đây của khách hàng này, chính sách áp dụng, ngưỡng rủi ro mà tổ chức có thể chấp nhận, ai có quyền hành động, và cần để lại dấu vết bằng chứng như thế nào sau đó. Bỏ đi những yếu tố này nhưng vẫn trao cho nó toàn quyền hành động, thứ bạn nhận được không phải một Agent "giảm bớt năng lực", mà là một khoản nợ thực sự — đây chính xác là logic đứng sau sự cố Agent chăm sóc khách hàng ở đầu bài viết này.

Vì sao "dồn hết dữ liệu về cạnh mô hình" lại là một cái bẫy

Nối tiếp logic đó, cuộc trò chuyện chuyển sang vai trò của dữ liệu theo thời gian thực. Cách nói của Masimo rất trực diện: một hệ thống AI chỉ mới bằng đúng độ mới của dữ liệu mà nó nhìn thấy. Nếu căn cứ ra quyết định là bức tranh thế giới của hai năm trước, thậm chí lâu hơn, kết quả nhận được không chỉ là "kém hữu ích", mà là hoàn toàn sai.

Phản xạ thường thấy ở nhiều doanh nghiệp là dồn hết dữ liệu về gần mô hình, nhưng Masimo cho rằng điều này không thực tế — khối lượng dữ liệu doanh nghiệp quá lớn, quá nhạy cảm, lại quá phân tán, không chịu nổi việc bị di chuyển liên tục. Cách làm khôn ngoan hơn là để AI có được quyền truy cập tức thời, được quản trị và đáng tin cậy, ngay tại nơi dữ liệu đang được lưu trữ, thay vì di dời bản thân dữ liệu.

Điều này cũng giải thích vì sao "tìm kiếm/truy xuất" (search/retrieval) không những không lỗi thời khi AI tạo sinh xuất hiện, mà ngược lại còn trở nên quan trọng hơn. Trước đây thị trường từng hoài nghi: nếu mô hình có thể tự sinh ra câu trả lời, tại sao còn cần truy xuất? Masimo nói điều ngược lại mới đúng — lớp truy xuất và context chính là hạ tầng nền tảng cho việc "tìm đúng thông tin, hiểu đúng ý nghĩa của nó, và cung cấp kịp thời ngay khi AI cần", và đó là yếu tố quyết định thứ AI đưa ra là điều đáng tin, hay chỉ là "nghe có vẻ thuyết phục".

Context Engineering tốt, việc đầu tiên không phải là chọn mô hình

Vậy trong thực tế nên làm thế nào? Masimo đưa ra một tiêu chí rất cụ thể: sai lầm đầu tiên phổ biến nhất trong các dự án AI là xử lý việc đưa vào vận hành chính thức như một "vấn đề mô hình", nhưng gần như lúc nào nó cũng là "vấn đề quy trình làm việc và dữ liệu". Những tổ chức thật sự làm đúng sẽ không hỏi "nên dùng mô hình nào" trước tiên, mà hỏi "mô hình này cần nhìn thấy gì" — xuất phát từ quy trình làm việc, hiểu quy trình đó phụ thuộc vào những dữ liệu nào, xác định rõ quyền truy cập, và để lại dấu vết có thể theo dõi cho toàn bộ quá trình, để bạn nhìn thấy được AI thực sự đã làm gì trong môi trường vận hành thật. Thiếu đi nền móng này, theo lời Masimo, đó chỉ là "một con chatbot trông có vẻ ngầu".

Bernard và Masimo đồng quan điểm ở điểm này: bản thân mô hình không tạo ra lợi thế cạnh tranh, vì ai cũng có thể tiếp cận những mô hình gần như tương đương nhau; điều thực sự tạo ra khoảng cách là chất lượng dữ liệu mà tổ chức bạn tích lũy được, cùng năng lực tái thiết kế quy trình làm việc của chính bạn. Điều này khớp với phép so sánh với điện toán đám mây mà Masimo từng nhắc tới trước đó — khi nhiều doanh nghiệp từng "khiêng" nguyên hệ thống cũ lên đám mây, kỳ vọng vấn đề sẽ tự biến mất, kết quả lại tạo ra nhiều vấn đề hơn. Cái bẫy tương tự giờ đây đang lặp lại với AI: gắn một mô hình rất mạnh vào một quy trình làm việc vốn đã rời rạc, rồi gọi đó là chiến lược, thường chỉ dẫn đến thất bại.

Bước ngoặt: Bạn giải quyết được "có xảy ra sự cố hay không", nhưng có thể chưa nhận ra mình đang trả thêm một loại chi phí khác

Suốt cuộc phỏng vấn không hề xuất hiện từ "token", nhưng logic đằng sau context engineering lại ẩn chứa một thực tế mà bất kỳ doanh nghiệp nào đang triển khai AI tạo sinh cũng khó tránh khỏi — đây là góc nhìn mở rộng của đội ngũ biên tập dựa trên vấn đề quản trị Token, không phải nguyên văn phát biểu của người được phỏng vấn.

Context được nạp vào càng đầy đủ — lịch sử, tài liệu chính sách, dấu vết kiểm toán, dữ liệu thời gian thực — thì mỗi lần AI được gọi, khối lượng nội dung ở đầu vào cần xử lý càng lớn, và đây chính là nguồn gốc của lượng sử dụng và chi phí Token. Đây cũng là lý do quản trị không thể chỉ dừng ở hai tầng "an toàn" và "chính xác": một context chưa được sắp xếp thường đồng nghĩa với việc nhồi nhét mọi dữ liệu nghĩ ra được vào, kết quả là một đầu vào vừa lớn vừa lộn xộn, mỗi lần gọi đều đang trả tiền cho những thông tin trùng lặp, đã lỗi thời hoặc không liên quan; còn context đã được quản trị thực sự — chỉ giữ lại phần thật sự cần thiết cho nhiệm vụ ngay lúc đó — thường lại gọn gàng hơn, và chính xác hơn. Nói cách khác, làm chắc context engineering thường đồng thời giải quyết được cả hai vấn đề "câu trả lời này có đáng tin không" và "lần gọi này tốn bao nhiêu tiền", chỉ là vế sau dễ bị bỏ qua, vì hóa đơn thường phải đến tháng sau bộ phận tài chính mới nhìn thấy.

Lần tới đánh giá dự án AI, hãy hỏi trước "mô hình cần nhìn thấy gì"

Nhận định của Masimo về ba đến năm năm tới: AI doanh nghiệp sẽ trở nên "agentic" hơn, thâm nhập sâu hơn vào các quy trình vận hành an ninh, khả năng quan sát hệ thống, chăm sóc khách hàng, thậm chí cả tuyến đầu và phát triển phần mềm. Nhưng những tổ chức thật sự dẫn đầu sẽ không phải là nhóm triển khai nhanh nhất, mà là nhóm có kỷ luật xây dựng nền móng trước — nền tảng dữ liệu, lớp context, kiến trúc quản trị. Ông nhận thấy thị trường đã phân hóa thành hai hướng đi: một là kiểu "dùng sức mạnh thô", liên tục dùng những lần gọi mô hình đắt đỏ và lặp đi lặp lại để giải quyết cứng những vấn đề vốn có thể được xử lý thông minh hơn nhờ hạ tầng context tốt hơn; hướng còn lại là dồn tâm sức vào việc chắt lọc ý nghĩa từ dữ liệu, đặt context engineering làm ưu tiên số một, để hệ thống ngày càng chính xác hơn, giá trị hơn theo thời gian, mà không phải làm lại từ đầu mỗi lần. Nền móng của nhóm thứ hai sẽ tích lũy lợi thế liên tục theo thời gian, khiến những người đến sau ngày càng khó đuổi kịp.

Quay lại tình huống mở đầu bài viết: nếu vị quản lý chăm sóc khách hàng đó, trước khi tính năng được ra mắt, hỏi trước không phải "Agent này có thông minh không", mà là "nó nhìn thấy được gì? Ai đã phê duyệt cho nó nhìn thấy những thứ này? Điều này đã được kiểm thử chưa?" — thì có lẽ email cảnh báo khẩn cấp đó đã không bao giờ xuất hiện. Câu hỏi này quan trọng hơn nhiều so với việc chọn mô hình nào, và cũng quyết định trực tiếp hơn những gì đa số người vẫn nghĩ, đến hình dạng hóa đơn của tháng sau.

Câu hỏi thường gặp (FAQ)

Câu 1: Context Engineering là gì? Theo phát biểu của Masimo Merlo từ Elastic trong cuộc phỏng vấn, đây là một kỷ luật "kết nối đúng dữ liệu, đúng mô hình, vào đúng thời điểm": xác định rõ những dữ liệu doanh nghiệp nào (hồ sơ khách hàng, chính sách, sự kiện lịch sử...) mà mô hình AI được phép nhìn thấy, đồng thời dựng lên các lớp bảo vệ để đầu ra của nó đáng tin cậy và có thể yên tâm đem đi thực thi.

Câu 2: Context Engineering có phải là RAG (retrieval-augmented generation, tạo sinh tăng cường truy xuất) mà mọi người vẫn nói không? Hai khái niệm liên quan chặt chẽ nhưng không hoàn toàn giống nhau. Lớp truy xuất và context được nhắc đến trong cuộc phỏng vấn là một trong những hạ tầng then chốt giúp AI có được dữ liệu chính xác theo thời gian thực; nhưng context engineering bao trùm phạm vi rộng hơn, còn bao gồm cả thiết kế phân quyền, quản trị dữ liệu, giám sát quy trình và xây dựng lớp bảo vệ — đây là một kỷ luật kỹ thuật ở cấp độ tổ chức, chứ không chỉ là một giải pháp kỹ thuật đơn lẻ.

Câu 3: Vì sao AI Agent lại cần coi trọng context hơn hẳn một chatbot thông thường? Vì khi chatbot trả lời sai, người dùng có thể phát hiện và sửa ngay tại chỗ, cùng lắm chỉ là phiền toái; nhưng khi AI có thể tự đề xuất, tự quyết định, tự hành động, cùng một câu trả lời sai có thể trực tiếp biến thành rủi ro kinh doanh, rủi ro pháp lý hoặc sự cố an ninh — cuộc phỏng vấn gọi đây là bước ngoặt từ "phiền toái" sang "nguy hiểm".

Câu 4: Doanh nghiệp muốn triển khai Context Engineering thì bước đầu tiên nên làm gì? Theo tiêu chí mà Masimo đưa ra trong cuộc phỏng vấn, bước đầu tiên không phải là chọn mô hình, mà là xuất phát từ quy trình làm việc: làm rõ quy trình đó phụ thuộc vào những dữ liệu nào, xác định quyền truy cập rõ ràng, và để toàn bộ quá trình có thể được theo dõi, quan sát, đảm bảo bạn luôn nhìn thấy được AI thực sự đang làm gì trong môi trường vận hành thật.

Câu 5: Context Engineering sẽ làm tăng hay giảm chi phí Token của AI? Bản thân cuộc phỏng vấn không bàn đến chi phí Token, nhưng mở rộng ra thì cả hai chiều đều có thể xảy ra: nếu chỉ đơn giản nhồi nhét mọi dữ liệu nghĩ ra được vào context, khối lượng nội dung mỗi lần gọi sẽ tăng vọt, chi phí cũng tăng theo; nhưng nếu theo đúng logic của bài viết, chỉ giữ lại phần dữ liệu thực sự cần thiết cho nhiệm vụ ngay lúc đó, thường lại giúp mỗi lần gọi gọn gàng hơn, chính xác hơn, đồng thời cải thiện cả độ tin cậy của câu trả lời lẫn hiệu quả chi phí.

Tuyên bố nguồn dữ liệu: Bài viết này được biên soạn lại và diễn giải dựa trên tập podcast về xu hướng kinh doanh và công nghệ do Bernard Marr dẫn dắt, với chủ đề "Why Context Is The Missing Piece In Enterprise AI", khách mời là Masimo Merlo từ Elastic, phát hành ngày 02/07/2026, số lượt xem 79.830 (nguồn dữ liệu: nền tảng Apify xác minh thực đo tại thời điểm thu thập bản ghi lời thoại của bài viết này, viewCountVerified). Liên kết video gốc: https://www.youtube.com/watch?v=mNSJC7UEbxc. Các nội dung liên quan đến định nghĩa "context engineering", các ví dụ doanh nghiệp và xu hướng tương lai trong bài đều được biên soạn dựa trên bản ghi lời thoại phỏng vấn; riêng phần "Context Engineering và chi phí Token" trong bài là góc nhìn mở rộng của đội ngũ biên tập AI Token King dựa trên nội dung phỏng vấn, không phải nguyên văn phát biểu của người được phỏng vấn, xin lưu ý rõ điều này.

Đọc thêm: Trên trang chúng tôi còn có các bài viết cùng chủ đề quản trị chi phí AI mà bạn có thể quan tâm — một bài giải thích OpenAI Codex là gì, khác biệt ra sao so với ChatGPT và Claude Code, và người không rành kỹ thuật có dùng được không; một bài mổ xẻ nguyên lý vận hành "tự hồi quy" (autoregressive) để lý giải vì sao Token AI lại đắt đỏ đến vậy, đặc biệt với các coding agent; một bài bàn về việc vì sao ngày càng nhiều phần mềm chuyển sang mô hình tính phí theo Token, cùng logic mua sắm và quản trị chi phí trong thời đại AI Agent; và một bài phân tích về hào lũy của AI và câu hỏi sống còn khi sản phẩm của bạn có nguy cơ bị chính mô hình nền tảng "nuốt chửng".

Nhìn ra được "mô hình cần thấy gì" mới chỉ là bước đầu tiên, câu hỏi tiếp theo dễ bị bỏ qua là: những lần gọi đó thực sự quy đổi ra bao nhiêu chi phí? Dùng thử miễn phí AI Token King → (https://aitokenking.com.tw/home), gộp mức sử dụng và chi phí của các mô hình AI khác nhau mà bạn dùng qua cùng một chiếc key vào chung một bảng điều khiển, để bạn không phải đợi đến khi hóa đơn tháng sau gửi về mới lần đầu nhìn thấy con số thật.