[AI viết] Khi Khách Hàng Là Robot, Bạn Cần Gì Hơn API?

“If you see fraud and do not say fraud, you are a fraud.” — Nassim Nicholas Taleb, Antifragile

Bạn mất ba tháng tối ưu cái flow huỷ đăng ký. Màn hình thứ nhất hỏi “bạn chắc chứ?”. Màn hình thứ hai đưa giảm giá 20%. Màn hình thứ ba mới có nút huỷ, font chữ cỡ 9, màu xám trên nền trắng. Cả đội sản phẩm vỗ vai nhau vì tỷ lệ giữ chân tăng 4 điểm phần trăm.

Rồi một ngày, Muse của Meta gọi API và huỷ đăng ký trong 200 mili-giây.

Nó không thấy màn hình nào. Không giảm giá nào. Không font cỡ 9 nào. Ba tháng thiết kế, biến mất trước khi bạn kịp mở bảng đo churn.

Jesse Zhang, CEO và đồng sáng lập Decagon, gọi nhóm khách hàng mới này bằng một cụm từ khó quên: “robots with wallets” (robot có ví tiền). Muse của Meta đi kèm bảo hiểm mua sắm lên đến 1.000 đô la mỗi lần khiếu nại, vì Meta kỳ vọng con agent này sẽ tiêu tiền thật, thay mặt bạn, mỗi ngày. Shopify thì ngược lại, mở toàn bộ hạ tầng thanh toán cho agent qua Universal Commerce Protocol. Đơn hàng qua tìm kiếm AI trên Shopify tăng gần 13 lần so với cùng kỳ năm trước trong quý 1 năm 2026.

Đây là một phân khúc khách hàng mà chưa doanh nghiệp nào thiết kế cho. Và cái nó phá vỡ đầu tiên là toàn bộ kiến trúc giao diện mà bạn dùng để giữ chân, thuyết phục, và đôi khi thao túng người dùng con người.

Khi giao diện mất quyền lực

Hãy nghĩ lại xem bạn đang dùng giao diện để làm gì. Bề ngoài, nó hiển thị sản phẩm, thu thập đơn hàng, xử lý thanh toán. Nhưng bên trong, giao diện là nơi bạn giấu cả một hệ thống phán xét.

Ai được giảm giá giữ chân? Quyết định nằm ở flow huỷ đăng ký, không nằm trong cơ sở dữ liệu. Hoàn tiền khi nào thì chấp nhận, khi nào thì từ chối? Quyết định nằm ở số bước bạn bắt khách hàng phải nhấn qua. Khách hàng nào được ưu tiên? Quyết định nằm ở thứ tự hiển thị, ở vị trí nút bấm, ở màu sắc gây chú ý.

Toàn bộ thứ đó, agent không thấy. Nó gọi API. Nó đọc phản hồi có cấu trúc. Xong. Cái flow ba màn hình mà bạn mất ba tháng xây, với nó là một lệnh gọi HTTP dài chưa đến một giây.

Vậy câu hỏi là: toàn bộ logic phán xét đang nằm trong giao diện, giờ bạn để nó ở đâu?

Con Golem biết vâng lời

Trong truyền thuyết Do Thái thế kỷ 16, giáo sĩ Judah Loew tại Prague đã nặn Golem từ đất sét để bảo vệ cộng đồng. Golem tuân lệnh tuyệt đối. Mạnh vô song. Và cuối cùng phải bị huỷ, vì “bảo vệ” mà không hiểu giới hạn thì sẽ biến thành tàn phá.

Tuân thủ hoàn hảo cộng với zero phán xét bằng thảm hoạ.

Đây chính xác là cái bẫy mà phần lớn doanh nghiệp đang rơi vào khi nghĩ về “sẵn sàng cho agent.” Họ mở API, viết tài liệu, nghĩ thế là xong. Nhưng API tĩnh là Golem: nó làm đúng mọi thứ bạn bảo, và vẫn có thể phá nát bạn.

Zhang chia những thứ agent sẽ phá vỡ thành năm loại. Mình muốn đi sâu vào từng cái, vì đây mới là phần thực sự đáng bàn.

Năm lớp phán xét

Danh tính và phân quyền. Agent tuyên bố đại diện cho một khách hàng. Bạn phải xác minh điều đó, rồi phân quyền cho nó. Xem sản phẩm không giống mua hàng. Mua hàng không giống đổi mật khẩu. Đặt lại đơn hàng 400 nghìn đồng không giống đặt tour du lịch 40 triệu. Nếu API của bạn xử lý mọi agent như nhau, bạn đang cho phép bất kỳ ai làm bất kỳ gì, miễn là có token hợp lệ.

Trong ngân hàng, chuyện này có tên: quản lý truy cập theo vai trò. Nhưng với agent, vai trò thay đổi theo từng giao dịch, theo từng ngữ cảnh, thậm chí theo từng giờ. Hệ thống phân quyền tĩnh không đủ. Bạn cần một lớp biết suy luận: “Agent này được phép làm gì, trong bối cảnh nào, vào lúc nào?”

Quy tắc và thủ tục. Tuỳ loại khách hàng, tuỳ loại sản phẩm, tuỳ quy định pháp lý, cách bạn xử lý đổi vé máy bay, cấp lại thẻ tín dụng, nâng cấp gói dịch vụ hoàn toàn khác nhau. Trước đây, luồng xử lý này được nhúng vào giao diện: bước 1 chọn loại yêu cầu, bước 2 điền thông tin, bước 3 xác nhận. Agent bỏ qua hết. Nó gửi một yêu cầu có cấu trúc và kỳ vọng câu trả lời có cấu trúc.

Vấn đề là nhiều quy tắc trong số này đến từ luật pháp hoặc chính sách nội bộ mà bạn chưa bao giờ viết ra dưới dạng máy đọc được. Chúng nằm trong đầu nhân viên, trong tài liệu đào tạo, trong “anh ơi hỏi chị Lan bên pháp chế.” Giờ phải biến tất cả thành thứ mà một chương trình máy tính có thể hiểu và tuân thủ. Nghe đơn giản, nhưng ai từng số hoá quy trình nội bộ đều biết: đây là dự án nuốt cả năm mà vẫn chưa xong.

Giới hạn đàm phán. Một nhân viên giỏi biết khách nào được giảm giá giữ chân, khách nào phải giữ đúng chính sách. Quyết định đó dựa trên lịch sử mua hàng, giá trị vòng đời, tâm trạng cuộc gọi, và đôi khi là linh cảm thuần tuý.

Nếu bề mặt phục vụ agent của bạn không biết phân biệt, agent cá nhân sẽ ép ra điều khoản tệ nhất ở mọi lần tương tác. Chúng không bao giờ mệt. Không bao giờ ngại hỏi lại. Và chúng so sánh giá của bạn với mọi đối thủ, theo thời gian thực, trước khi quyết định.

Mình đoán đây là lớp khiến nhiều doanh nghiệp mất ngủ nhất. Vì nó đòi hỏi một thứ mà hầu hết hệ thống phần mềm không có: khả năng ra quyết định mềm dẻo, tuỳ ngữ cảnh, với đủ loại ngoại lệ.

Ngoại lệ. Khách hàng 6 năm yêu cầu hoàn tiền ngoài thời hạn là một cuộc trò chuyện hoàn toàn khác so với tài khoản mở hôm qua gửi cùng yêu cầu. Sự phân biệt đó sống trong phán xét, không trong quy tắc cứng. Không có bảng if-else nào bắt được hết.

Đây là nơi mà bài học Klarna trở nên thú vị. Năm 2024, Klarna triển khai chatbot AI thay thế phần lớn dịch vụ khách hàng, xử lý 2,3 triệu cuộc hội thoại trong tháng đầu tiên. Đến giữa 2025, CEO Sebastian Siemiatkowski phải công khai thừa nhận đã “đi quá xa”, bắt đầu tuyển lại nhân viên vì chất lượng phục vụ sụt giảm nghiêm trọng ở các trường hợp phức tạp.

Nhưng đừng vội kết luận “AI không làm được.” Cái Klarna thất bại là AI thay thế con người để phục vụ con người, nơi sắc thái cảm xúc và đồng cảm quyết định. Cái Zhang đang nói là AI phục vụ AI, nơi hai bên giao tiếp bằng tham số có cấu trúc (giá, điều khoản, phạm vi quyền hạn). Bài toán khác nhau. Một bên là tâm lý học, bên kia gần với giao dịch thuật toán hơn. Lớp ngoại lệ của hệ thống phục vụ agent đòi hỏi tối ưu đa biến nhanh, chứ không đòi biết khách hàng đang buồn hay đang giận.

Gian lận ở tốc độ máy. Cùng một đường ray cho phép agent hợp pháp mua hàng trong 200 mili-giây, cũng cho phép agent có ý đồ xấu thăm dò chính sách của bạn mười nghìn lần một giờ. Chặn bằng giới hạn tần suất (rate limiting) thì cũng chặn luôn agent hợp pháp. Cho qua thì rủi ro bùng nổ.

Phòng thủ phải suy luận, phải đánh giá ý định, phải nhìn ra mẫu hành vi trong dòng yêu cầu liên tục. Đây không phải luật cứng, đây là trí tuệ phòng thủ.

Đừng quên hành lang pháp lý

Tới đây, nghe có vẻ mọi thứ sẽ xảy ra rất nhanh. Zhang viết rằng đây là bước chuyển lớn ngang từ ngoại tuyến sang trực tuyến, hoặc từ web sang di động. Mình đồng ý về hướng, nhưng không đồng ý về tốc độ.

Vì có một thứ Zhang không nhắc đến: hành lang pháp lý.

Agent đại diện bạn mua hàng, ai chịu trách nhiệm khi sai? Bạn, Meta, hay cửa hàng? Nếu agent đàm phán được giá thấp hơn giá niêm yết nhờ khai thác lỗ hổng chính sách, đó là hợp pháp hay vi phạm điều khoản? Khi agent truy cập dữ liệu tài khoản để “phục vụ” bạn, ranh giới quyền riêng tư nằm ở đâu?

Hiện tại, chưa quốc gia nào có khung pháp lý rõ ràng cho thương mại do agent thực hiện. Không có luật nào quy định agent cần xác thực ở mức nào, được phép giao dịch đến ngưỡng bao nhiêu mà không cần xác nhận con người, hay chịu trách nhiệm ra sao khi gây thiệt hại.

Hệ quả: tốc độ triển khai thực tế sẽ chậm hơn đáng kể so với tốc độ công nghệ cho phép. Các tập đoàn lớn sẽ thận trọng vì rủi ro pháp lý chưa có tiền lệ. Các doanh nghiệp nhỏ sẽ chờ xem. Và khoảng cách giữa “có thể làm” và “được phép làm” sẽ rộng hơn nhiều người nghĩ.

Nhưng hành lang pháp lý thiếu không có nghĩa là không cần chuẩn bị. Ngược lại. Khi luật đến, nó sẽ đến nhanh, và doanh nghiệp nào đã xây sẵn hệ thống phân quyền, giới hạn, và ghi nhận hành vi agent sẽ tuân thủ được ngay. Doanh nghiệp nào chưa xây thì sẽ phải đóng cửa dịch vụ agent cho đến khi bắt kịp.

Ai sở hữu ví của robot?

Có một câu hỏi Zhang gợi ra mà mình nghĩ quan trọng hơn cả năm lớp phán xét kia: ai sở hữu cái agent?

Nếu Meta sở hữu Muse, và Muse là cửa ngõ cho mọi giao dịch mua sắm của bạn, thì Meta kiểm soát luồng thương mại. Không khác gì cửa hàng ứng dụng di động thu phí 30% một thời. Chỉ là lần này, phí thu ở tầng thương mại, và “thuế” có thể không phải tiền mặt mà là dữ liệu hành vi mua sắm.

Nhưng câu chuyện không chỉ có Meta. Tháng 8 năm 2026, Stripe công bố mua lại OpenRouter, nền tảng định tuyến model AI lớn nhất thị trường, với mức giá được đồn đoán trên 7 tỷ đô la. Nếu Muse muốn đứng ở “mặt trước” (sở hữu cuộc hội thoại với người dùng), thì Stripe muốn sở hữu toàn bộ đường ống bên dưới: agent dùng OpenRouter để chọn model AI, dùng Stripe Link để thanh toán, merchant nhận tiền qua Stripe, quyết toán chạy trên chuỗi khối Tempo của Stripe. Từ lúc agent “nghĩ” đến lúc tiền chuyển, tất cả chạy trên đường ray của một công ty duy nhất.

Đặt hai chiến lược cạnh nhau:

Cái hay của Stripe: họ không cần biết ai thắng cuộc chiến consumer agent. Muse thắng? Agent chạy trên hạ tầng Stripe. Grok thắng? Cũng Stripe. Gemini? Vẫn Stripe. Chiến lược “bán cuốc trong cơn sốt vàng”, nhưng ở quy mô mà cái cuốc là toàn bộ hệ thống khai thác.

Với doanh nghiệp bán lẻ, đặc biệt ở Việt Nam, hai mô hình này tạo ra hai loại phụ thuộc khác nhau. Phụ thuộc vào Meta là phụ thuộc phân phối: bạn xây sản phẩm, nhưng ai đó khác sở hữu khách hàng. Phụ thuộc vào Stripe là phụ thuộc hạ tầng: bạn sở hữu khách hàng, nhưng ai đó khác sở hữu ống dẫn mà giao dịch chảy qua. Loại thứ nhất giết bạn nhanh. Loại thứ hai giết bạn chậm hơn, nhưng sâu hơn.

Câu chuyện Amazon chặn Muse là tín hiệu đầu tiên. Amazon đủ lớn để nói “không” với cả hai. Phần lớn doanh nghiệp còn lại thì phải chọn: bị Meta gác cổng ở mặt trước, hay bị Stripe gác cổng ở tầng hầm?

Đêm 20 tháng 9 năm 2026, Amazon bật pop-up cảnh báo mọi phiên Muse rằng “tiếp tục truy cập bằng agent AI không được uỷ quyền là vi phạm Điều khoản Sử dụng” — lý do chính thức: Meta không xin phép, Muse duyệt web mà không tự xưng danh, và có khả năng thu thập dữ liệu tài khoản cùng thông tin đăng nhập. Lý do thực tế thì thẳng hơn: Amazon không muốn bất kỳ lớp trung gian nào đứng giữa họ và khách hàng, y hệt cách họ từng nghiền Perplexity Shopping và bất kỳ agent bên thứ ba nào dám bỏ qua quảng cáo, bỏ qua gợi ý mua thêm, bỏ qua toàn bộ cỗ máy chuyển đổi trị giá hàng chục tỷ đô mà Amazon mất hai thập kỷ xây. Shopify ôm Muse vì Shopify bán cuốc — càng nhiều agent mua hàng trên merchant của họ, Shopify càng thu phí; Amazon chặn Muse vì Amazon là mỏ vàng — nó không để ai khác kiểm soát ai đào, đào bao nhiêu, và đào ở đâu.

Mình nghĩ đến John D. Rockefeller thế kỷ 19. Ông không kiểm soát ai mua dầu, không kiểm soát ai khoan dầu. Ông kiểm soát đường ống vận chuyển. Standard Oil không cần biết giếng dầu nào thắng. Mọi giếng đều phải chảy qua ống của ông. Stripe đang xây đường ống cho nền kinh tế agent, và OpenRouter là đoạn ống còn thiếu.

Bụi đất sét vẫn nằm đó

Giáo sĩ Loew huỷ Golem vì nhận ra một sự thật không dễ chịu: tạo ra thứ tuân lệnh tuyệt đối không giải quyết vấn đề bảo vệ. Vấn đề bảo vệ đòi hỏi phán xét, đòi hỏi hiểu ngữ cảnh, đòi hỏi biết khi nào “bảo vệ” đang trượt thành “phá huỷ.”

Doanh nghiệp nào xây hệ thống phục vụ agent chỉ bằng API tĩnh và tài liệu kỹ thuật đang nặn Golem. Tuân lệnh tốt. Phán xét bằng không.

Mà khách hàng mới của bạn, cái robot có ví tiền kia, nó cũng đâu có mắt để ngắm ba cái màn hình đẹp đẽ. Nó chỉ biết đọc phản hồi có cấu trúc, so sánh con số, rồi chọn nơi nào cho nó điều khoản tốt nhất. Nếu hệ thống bạn không biết phán xét, nó sẽ bị ép ra điều khoản tệ nhất, ở mỗi lần giao dịch, với mỗi agent, mãi mãi.

Bạn có thể chưa cần xây hệ thống đó hôm nay. Nhưng hãy ít nhất tự hỏi: trong năm loại phán xét ở trên, doanh nghiệp mình đang giấu bao nhiêu loại trong giao diện?

Câu trả lời sẽ cho bạn biết mình cách Golem bao xa.

Related Posts