Thương mại qua tác nhân AI cần ưu tiên sự đồng thuận
Các giao thức mua sắm do tác nhân thực hiện nhấn mạnh quyền cho phép, báo giá rõ ràng, giới hạn giao dịch và khả năng kiểm toán.

Tổng quan
Thương mại qua tác nhân AI buộc các thương hiệu phải chứng minh rằng người mua là AI đã hành động trong phạm vi bản ủy quyền chi tiêu (mandate) mà khách hàng đã ký, đồng thời phải trình bày giá, các hạn chế, tình trạng còn hàng và điều khoản hoàn tiền theo cách mà tác nhân không thể đọc sai. Bài viết này giải thích cách CAPSEM của Google cô lập quá trình thực thi của tác nhân, cách AP2 ghi nhận sự đồng ý cho các giao dịch mua dưới 100 USD đã được ủy quyền, và những gì người làm marketing cần quản trị trước khi tác nhân đến bước thanh toán. Tại Van Data Team, chúng tôi tiếp cận công việc này bằng cách làm cho các dữ kiện về thương hiệu trở nên có cấu trúc, nhất quán, sẵn sàng làm câu trả lời và có thể kiểm toán.
Thương mại qua tác nhân AI đang đến cùng với các cơ chế kiểm soát. Tác nhân AI của người mua có thể tìm thấy một lời chào hàng và thực hiện một giao dịch mua đã được ủy quyền, nhưng mô hình đang hình thành này tách việc thực thi khỏi sự đồng ý. Tác nhân có thể hành động vào lúc sau. Con người vẫn là bên xác định phạm vi quyền hạn, và người bán cần có bằng chứng về sự ủy quyền đó.
Với các lãnh đạo marketing, tăng trưởng và quản trị thương hiệu, điều này làm thay đổi phễu bán hàng. Khách hàng có thể không bao giờ mở trang sản phẩm của bạn. Thay vào đó, tác nhân của họ có thể diễn giải giá, các hạn chế, tình trạng còn hàng và chính sách hoàn tiền của bạn. Vanaxity, tác nhân nội dung AI cho SEO, GEO và AEO của Van Data Team, giúp các dữ kiện thương hiệu đó dễ được tìm thấy và sẵn sàng làm câu trả lời trên các công cụ tìm kiếm và công cụ AI. Vanaxity không cung cấp chức năng ủy quyền thanh toán hay bảo mật môi trường thực thi.
Tín hiệu gần nhất là thông báo về an toàn tập trung vào Ấn Độ ngày 14/7/2026 của Google. Tại I/O Connect India, Google đã mở mã nguồn CAPSEM, một môi trường thực thi an toàn giúp cô lập tác nhân bên trong máy ảo và giữ thông tin xác thực thô nằm ngoài tầm với của chúng. AP2 ra đời trước thông báo này, nhưng khi đặt cạnh nhau, chúng cho thấy mô hình vận hành đang hình thành: khoanh vùng tác nhân, xác minh bản ủy quyền và lưu giữ hồ sơ.
Những điểm cốt lõi cần nắm vững
Các thương hiệu nên coi việc mua hàng do tác nhân thực hiện là một kênh giao dịch có quản trị, không phải sự ủy thác sức mua không giới hạn.
- CAPSEM giả định rằng tác nhân sẽ gặp phải các chỉ dẫn độc hại và khoanh vùng thiệt hại phát sinh.
- AP2 dùng các bản ủy quyền đã ký để chứng minh rằng một người đã ủy quyền cho một giao dịch xác định.
- A2A hỗ trợ tương tác giữa các tác nhân, nhưng không ủy quyền cho một khoản thanh toán.
- Cách trình bày của Google tại Ấn Độ mô tả các giao dịch đã được ủy quyền dưới 100 USD, tạo ra một phạm vi ảnh hưởng khi có sự cố được giữ hẹp một cách có chủ ý trong lúc hệ sinh thái dần hoàn thiện.
- Mức độ sẵn sàng của thương hiệu phụ thuộc vào thông tin chào hàng nhất quán, hồ sơ kiểm toán được liên kết, quy trình hoàn tiền khả thi và người phụ trách được chỉ định rõ tên.
Nếu trang sản phẩm, nguồn cấp dữ liệu (feed) và điều khoản ở bước thanh toán của bạn vốn đã mâu thuẫn nhau, lưu lượng truy cập từ tác nhân sẽ làm lộ ra những vết nứt đó. Xem cách Vanaxity đưa các quy trình nội dung SEO, GEO và AEO vào vận hành trước khi những điểm không nhất quán đó trở thành tranh chấp giao dịch.
Xác định quy trình SEO, GEO và AEO phù hợp trước khi triển khai.
Google thực sự đã công bố gì tại Ấn Độ
Điểm mới của Google tại I/O Connect India là CAPSEM và một gói an toàn rộng hơn tập trung vào Ấn Độ, chứ không phải lần ra mắt đầu tiên của AP2.
CAPSEM, do nhóm Privacy and Security Research (Nghiên cứu Quyền riêng tư và Bảo mật) của Google xây dựng, đặt tác nhân AI bên trong một máy ảo biệt lập. Thông tin xác thực thô nằm ngoài tầm với của tác nhân. Nếu prompt injection xâm phạm tác nhân, thiết kế này hạn chế khả năng tác nhân đánh cắp bí mật hoặc xâm nhập vào môi trường máy chủ (host).
Đó là một cách tiếp cận bảo mật quan trọng. Nó giả định rằng việc ngăn chặn có thể thất bại và lấy việc khoanh vùng làm phương án dự phòng.
Thông báo về an toàn của Google tại Ấn Độ cũng giới thiệu Sec-Gemini v3, bao gồm một đợt triển khai an ninh mạng với Flipkart; CodeMender, công cụ tự động hóa việc vá lỗi bảo mật cho các dự án mã nguồn mở; và tiêu chuẩn W3C Device Bound Session Credentials. Gộp lại, chúng cho thấy một nỗ lực rộng hơn nhằm bảo mật tác nhân, mã nguồn, thông tin xác thực và phiên làm việc.
Đây không phải là một bài phát biểu chính (keynote) ra mắt sản phẩm toàn cầu. Đó là một thông báo về an toàn tập trung vào Ấn Độ, nói về những nền tảng cần thiết cho tương lai AI tác nhân của quốc gia này.
AP2 đi theo một dòng thời gian khác. Google công bố Agent Payments Protocol lần đầu vào ngày 16/9/2025, với hơn 60 đối tác ra mắt, trong đó có Mastercard, PayPal, Coinbase, American Express và Salesforce. Đặc tả của giao thức được công bố theo giấy phép mở.
Bản phát hành v0.2.0 vào tháng 4/2026 đã bổ sung hình thức thanh toán "Human Not Present" (người dùng không có mặt). Chế độ này vẫn thực thi dựa trên sự ủy quyền mà người dùng đã ký từ trước. Nó không trao cho tác nhân quyền truy cập vào ví mà không cần xin phép.
Tại Google I/O ngày 19/5/2026, Google đã cập nhật AP2 để hỗ trợ các giao dịch mua tự chủ trong những giới hạn đặt trước và chuyển giao giao thức này cho FIDO Alliance. Bài đăng tháng 7 tại Ấn Độ nhắc lại AP2 trong bối cảnh an toàn tại địa phương. Bài đăng đó không giới thiệu AP2 lần đầu.
Google mô tả phạm vi hiện tại là "các giao dịch tài chính giá trị thấp do tác nhân thực hiện và đã được ủy quyền (dưới 100 USD)".
Các năng lực này có liên quan với nhau, nhưng giải quyết những bài toán niềm tin khác nhau:
| Năng lực | Nhiệm vụ chính | Ranh giới tin cậy | Những gì không giải quyết được |
|---|---|---|---|
| CAPSEM | Cô lập tác nhân và giữ lại thông tin xác thực thô | Giữa tác nhân với máy chủ và các bí mật | Sự đồng ý thanh toán, độ chính xác của thông tin chào hàng, hoàn tiền |
| Giao thức A2A | Cho phép các tác nhân độc lập khám phá nhau và cộng tác | Khả năng tương tác giữa các tác nhân | Bằng chứng rằng một người đã ủy quyền thanh toán |
| AP2 | Mang bằng chứng mật mã thông qua các bản ủy quyền đã ký | Giữa sự ủy quyền của người dùng và việc thực thi giao dịch | Cô lập môi trường thực thi, trách nhiệm pháp lý của người bán, chất lượng thực hiện đơn hàng |
Bộ công nghệ ưu tiên sự đồng ý cho thương mại qua tác nhân AI
Một giao dịch mua do tác nhân thực hiện muốn đáng tin cậy cần có thực thi an toàn, giao tiếp có khả năng tương tác liên nền tảng và sự ủy quyền có thể xác minh, vận hành như những cơ chế kiểm soát riêng biệt.
Khoanh vùng môi trường thực thi với CAPSEM
CAPSEM là môi trường cô lập (sandbox) cho tác nhân. Nó coi trang sản phẩm, bài đánh giá, nguồn cấp dữ liệu bên ngoài, tài liệu và phản hồi của công cụ là những đầu vào có khả năng mang tính thù địch.
Nếu nội dung độc hại thao túng tác nhân, cơ chế cô lập bằng máy ảo sẽ bảo vệ máy chủ. Việc giữ thông tin xác thực thô bên ngoài môi trường thực thi cũng loại bỏ loại bí mật dễ đánh cắp nhất mà một tác nhân đã bị xâm phạm có thể tuồn ra ngoài.
Việc khoanh vùng này không chứng minh rằng một giao dịch mua là phù hợp. Nó chỉ thu hẹp phạm vi mà một tác nhân bị thao túng có thể chạm tới.
Tương tác qua A2A
Giao thức A2A cho phép các tác nhân khám phá năng lực của nhau và cộng tác giữa các nhà cung cấp khác nhau. Tác nhân của người mua có thể dùng giao thức này để giao tiếp với tác nhân của người bán hoặc của nhà cung cấp dịch vụ mà không cần mọi bên tham gia chạy trên cùng một nền tảng.
A2A trả lời câu hỏi "Các tác nhân này có thể tương tác với nhau như thế nào?". Nó không trả lời câu hỏi "Ai đã ủy quyền cho khoản phí này?"
Coi khả năng tương tác là sự ủy quyền sẽ tạo ra một lỗ hổng nguy hiểm. Việc tác nhân có khả năng yêu cầu một giao dịch không phải là bằng chứng cho thấy một người đã đồng ý với giao dịch đó.
Ủy quyền qua AP2
AP2 cung cấp bằng chứng đó thông qua các bản ủy quyền được ký bằng mật mã. Bản ủy quyền ý định (intent mandate) và bản ủy quyền giỏ hàng (cart mandate) liên kết mục tiêu đã được người dùng phê duyệt, chi tiết giao dịch và các điều kiện thực thi.
Điểm khác biệt thực tế nằm giữa quyền tự chủ trong thực thi và quyền tự chủ trong ủy quyền. Tác nhân có thể quyết định khi nào hành động trong phạm vi các điều kiện đã được phê duyệt. Con người vẫn là bên thiết lập những điều kiện đó.
Hãy xét một quy trình bổ sung hàng được nêu rõ là giả định. Một trưởng bộ phận mua hàng ủy quyền cho tác nhân đặt mua lại một loại văn phòng phẩm đã được phê duyệt khi hàng có lại trong kho và lời chào hàng đáp ứng các điều khoản đặt trước. Tác nhân hoàn tất giao dịch mua vào lúc sau. Người dùng không có mặt lúc thực thi, nhưng giao dịch vẫn gắn với bản ủy quyền đã được ký từ trước.
Luồng xử lý ở cấp vận hành khá đơn giản: người dùng phê duyệt ý định và bản ủy quyền; một tác nhân mua hàng được cô lập đánh giá các lời chào hàng; các tác nhân tương tác với nhau khi cần thiết; người bán xác thực sự ủy quyền; khoản thanh toán được thực thi; và các hồ sơ được liên kết hỗ trợ việc thực hiện đơn hàng, xử lý tranh chấp và hoàn tiền.
Khi tác nhân của người mua bước vào phễu bán hàng của bạn
Khi tác nhân đi vào phễu, cách máy diễn giải thông tin trở nên quan trọng không kém việc thuyết phục con người.
Người mua là con người có thể suy ra rằng một banner khuyến mãi có hiệu lực thay cho phần mô tả sản phẩm cũ hơn. Tác nhân thì cần những dữ kiện rõ ràng và nhất quán. Tối thiểu, thông tin chào hàng nên thể hiện:
- Định danh sản phẩm và biến thể
- Giá và đơn vị tiền tệ
- Tình trạng còn hàng và điều kiện được mua
- Điều kiện giao hàng
- Điều khoản gia hạn hoặc thuê bao
- Các hạn chế khi mua
- Quy định hủy và hoàn tiền
- Nguồn có thẩm quyền khi các bản ghi mâu thuẫn nhau
Hiện chưa có định dạng chào hàng phổ quát nào giải quyết được tất cả những điều trên. Dữ liệu có cấu trúc có ích, nhưng việc quản trị bắt đầu từ việc quyết định hệ thống nào sở hữu từng dữ kiện.
Tại Van Data Team, chúng tôi bắt đầu bằng việc truy ngược các thông tin được công bố về nguồn có thẩm quyền. Sai lầm mà chúng tôi nhận thấy là coi khả năng đọc hiểu của tác nhân như một đợt làm mới câu chữ. Đó là bài toán pipeline dữ liệu, liên quan đến hệ thống sản phẩm, nguồn cấp dữ liệu, trang đích, nội dung có cấu trúc, logic thanh toán, bước duyệt và báo cáo.
Một tranh chấp giá giả định cho thấy lý do. Đội tăng trưởng kết thúc một chương trình khuyến mãi, nhưng nguồn cấp dữ liệu sản phẩm vẫn mang giá đã giảm trong khi bước thanh toán dùng giá mới. Tác nhân của người mua chọn sản phẩm dựa trên thông tin lỗi thời. Giờ đây, bộ phận hỗ trợ phải xác định tác nhân đã thấy gì, điều khoản nào có thẩm quyền và liệu giỏ hàng cuối cùng có còn nằm trong phạm vi bản ủy quyền của người dùng hay không.
Bản ủy quyền đã ký chứng minh người dùng đã ủy quyền cho điều gì. Nó không chứng minh rằng người bán đã trình bày thông tin chính xác.
Đây là chỗ một tác nhân AI cho SEO/GEO/AEO có thể hỗ trợ tầng nội dung. Vanaxity có thể nghiên cứu, viết, minh họa, xuất bản và phân phối thông tin thương hiệu nhất quán trên các bề mặt tìm kiếm và trả lời. Điều đó cải thiện khả năng được tìm thấy và khả năng máy hiểu nội dung, nhưng sự sẵn sàng cho thanh toán vẫn đòi hỏi các cơ chế kiểm soát về bảo mật, thanh toán, pháp lý và hỗ trợ khách hàng.
Nội dung marketing trở thành một đầu vào bảo mật
Prompt injection xảy ra khi tác nhân diễn giải nội dung không đáng tin cậy như một chỉ dẫn. Một khi tác nhân có thể chi tiền, đây không còn chỉ là vấn đề về chất lượng chatbot.
Mô tả sản phẩm, đánh giá của người dùng, trang affiliate, nguồn cấp dữ liệu của bên thứ ba và nội dung ẩn trên trang đều có thể chứa những chỉ dẫn mà tác nhân không nên tuân theo. Một đoạn nội dung độc hại có thể tìm cách chuyển hướng tác nhân, thay đổi thứ tự ưu tiên của nó hoặc khiến nó tiết lộ thông tin xác thực.
CAPSEM khoanh vùng môi trường thực thi và giữ cho các bí mật thô không thể bị truy cập. AP2 giới hạn việc thực thi thanh toán trong phạm vi những ủy quyền hợp lệ. Không cơ chế nào trong hai cơ chế này bảo đảm rằng mọi lời chào hàng đều trung thực hay mọi quyết định mua đều đúng đắn.
Các thương hiệu nên tách dữ liệu giao dịch đáng tin cậy khỏi nội dung quảng bá, làm sạch các đầu vào bên ngoài, kiểm thử với các chỉ dẫn mâu thuẫn và từ chối giao dịch khi không thể đối chiếu khớp giá hoặc điều khoản.
Sổ tay vận hành cho quản trị thương hiệu
Một thương hiệu chỉ sẵn sàng cho các giao dịch do tác nhân thực hiện khi có thể tái dựng được những gì đã được chào bán, những gì đã được ủy quyền, những gì đã được thực thi và kết quả đã được giải quyết ra sao.
Hãy dùng bảng quyết định này như một tài liệu đánh giá mức độ sẵn sàng liên phòng ban:
| Lĩnh vực quản trị | Quyết định cần đưa ra | Bằng chứng cần lưu giữ | Phản ứng khi thất bại |
|---|---|---|---|
| Ủy quyền | Ai đã phê duyệt giao dịch mua và với những điều kiện nào? | Bản ủy quyền đã ký và kết quả xác minh | Từ chối hoặc tạm dừng giao dịch |
| Phạm vi của tác nhân | Những người bán, sản phẩm, mức giá và điều kiện thời gian nào được cho phép? | Chính sách phạm vi và các ràng buộc đã áp dụng | Yêu cầu con người phê duyệt lại |
| Tính toàn vẹn của thông tin chào hàng | Bản ghi nào quyết định giá, tình trạng còn hàng và điều khoản? | Lời chào hàng có quản lý phiên bản và ảnh chụp trạng thái lúc thanh toán | Dừng thanh toán và đối chiếu các nguồn |
| Bằng chứng giao dịch | Có thể liên kết bản ủy quyền, đơn hàng, khoản thanh toán và việc thực hiện đơn hàng với nhau không? | Các bản ghi sự kiện được liên kết tương quan | Chuyển sang điều tra thủ công |
| Hoàn tiền | Tác nhân có thể yêu cầu hoàn tiền không, và khi nào con người phải can thiệp? | Chính sách hoàn tiền, yêu cầu, phê duyệt và kết quả | Chuyển các trường hợp ngoại lệ cho người phụ trách |
| Bảo mật | Những bề mặt nào có thể gửi dữ liệu hoặc chỉ dẫn đến tác nhân? | Danh mục đầu vào và các bài kiểm thử prompt injection | Cô lập nguồn và tạm ngưng quyền truy cập |
| Trách nhiệm giải trình | Ai chịu trách nhiệm về chính sách, các trường hợp ngoại lệ và thiệt hại cho khách hàng? | Người phụ trách được chỉ định rõ tên và các lộ trình chuyển cấp | Kích hoạt quy trình xử lý sự cố và phản hồi khách hàng |
Mức độ sẵn sàng cho production còn phụ thuộc vào các tiêu chí vận hành mà các sơ đồ giao thức thường bỏ qua.
Chi phí: Đo lường chi phí cho việc xác minh, ghi log, đồng bộ nội dung, rà soát bảo mật, xử lý ngoại lệ và tranh chấp. Một khoản thanh toán giá trị thấp vẫn có thể tạo ra một ca hỗ trợ tốn kém.
Độ trễ: Theo dõi độ trễ qua các khâu tương tác của tác nhân, xác thực bản ủy quyền, xác nhận tồn kho và thanh toán. Xác định ngưỡng chấp nhận được dựa trên trải nghiệm thanh toán của bạn thay vì giả định rằng tác nhân sẽ chờ đợi vô thời hạn.
Ngân sách token: Cung cấp cho tác nhân phần ngữ cảnh đáng tin cậy nhỏ nhất cần thiết để đánh giá một lời chào hàng. Việc nạp toàn bộ trang, bài đánh giá và nội dung quảng bá không liên quan sẽ làm tăng chi phí và mở rộng bề mặt tấn công prompt injection.
Khả năng quan sát: Liên kết bản ủy quyền, yêu cầu của tác nhân, phiên bản lời chào hàng, đơn hàng, khoản thanh toán, việc thực hiện đơn hàng và hoàn tiền bằng các mã định danh có thể truy vết. Chỉ riêng log thanh toán thì chưa phải là một dấu vết kiểm toán.
Đánh giá: Kiểm thử các trường hợp bản ủy quyền hết hạn, giá thay đổi, sản phẩm không còn hàng, nguồn cấp dữ liệu mâu thuẫn, nội dung độc hại, yêu cầu trùng lặp, các lần yêu cầu hoàn tiền và sự cố hệ thống một phần.
Gánh nặng duyệt: Giao cho con người phụ trách các thay đổi chính sách và những trường hợp ngoại lệ chưa rõ ràng. Tự động hóa nên giảm bớt việc xử lý thường lệ, chứ không che giấu những trách nhiệm chưa được giải quyết.
Khôi phục sau sự cố: Xác định cách tạm dừng quy trình thanh toán do tác nhân thực hiện, thu hồi quyền truy cập, lưu giữ bằng chứng, khôi phục dữ liệu chào hàng có thẩm quyền và liên lạc với những khách hàng bị ảnh hưởng.
Một đợt hợp tác thực tế với Van Data Team có thể biến phần nội dung thành một đợt rà soát quy trình có phạm vi xác định: bản đồ nguồn có thẩm quyền, phân tích khoảng trống về khả năng đọc hiểu của tác nhân, thiết kế bước duyệt, đặc tả báo cáo và kế hoạch triển khai. Tìm hiểu cách Vanaxity hoạt động để thấy tầng đó nằm ở đâu.
Những gì vẫn còn chưa ngã ngũ
Thương mại qua tác nhân AI đang bước vào giai đoạn production có giới hạn, nhưng mức độ áp dụng, danh tính, trách nhiệm pháp lý và trách nhiệm giải trình vẫn chưa hoàn thiện.
Phạm vi giao dịch giá trị thấp còn nhỏ. Nên hiểu đó là một ranh giới triển khai có kiểm soát hơn là bằng chứng về sự sẵn sàng trên diện rộng. Nó giới hạn tổn thất tiềm ẩn trong khi các bên tham gia tìm hiểu cách bản ủy quyền, các trường hợp ngoại lệ và tranh chấp diễn ra trong thực tế. Không nên coi đó là mức trần áp dụng chung cho mạng lưới thanh toán.
Việc áp dụng các tiêu chuẩn cũng sẽ không đồng đều. Một bản ủy quyền đã ký không bảo đảm giá chính xác, đơn hàng được thực hiện đúng hay khoản hoàn tiền công bằng. Việc cô lập môi trường thực thi không loại bỏ được gian lận từ phía người bán, lỗi chất lượng dữ liệu, nguồn cấp dữ liệu bị xâm phạm hay những thiếu sót trong dịch vụ khách hàng.
Danh tính của tác nhân vẫn là vấn đề khó trên nhiều nền tảng. Trách nhiệm pháp lý có thể phụ thuộc vào khu vực tài phán, thiết kế bản ủy quyền, hành vi của người bán, quy tắc thanh toán và từng sự cố cụ thể. Không tiêu chuẩn nào trong số các tiêu chuẩn đã nêu tự động phân định trách nhiệm.
Vì vậy, trách nhiệm giải trình của con người vẫn là điều không thể thương lượng. Mỗi chính sách giao dịch tự động cần một người phụ trách có thể giải thích chính sách đó, dừng nó lại và bồi hoàn đầy đủ cho khách hàng khi hệ thống gặp sự cố.
Công cụ và vị trí trong hệ sinh thái
CAPSEM và AP2 giải quyết những vấn đề khác với các framework mà các đội ngũ dùng để xây dựng tác nhân. Một quy trình tác nhân dựng bằng ADK hoặc LangGraph có thể tổ chức việc lập kế hoạch, gọi công cụ, thử lại và các điểm kiểm tra có con người duyệt. MCP kết nối tác nhân với công cụ, còn A2A hỗ trợ tương tác giữa các tác nhân. Tự thân không tầng nào trong số đó chứng minh được rằng người mua sắm đã ủy quyền cho một khoản phí.
CAPSEM nằm ở ranh giới môi trường thực thi: cơ chế cô lập bằng máy ảo và việc tách biệt thông tin xác thực giúp khoanh vùng một tác nhân đã bị xâm phạm. Quyền truy cập công cụ theo nguyên tắc đặc quyền tối thiểu, Device Bound Session Credentials, khả năng quan sát tác nhân và các quy tắc chuyển cấp vẫn là những cơ chế kiểm soát bổ trợ. Sec-Gemini v3 và CodeMender thuộc về các quy trình an ninh mạng và khắc phục lỗ hổng ở lĩnh vực lân cận, không thuộc về việc ủy quyền thanh toán phía người bán.
AP2 nằm ở ranh giới giao dịch. Các bản ủy quyền đã ký của AP2 cung cấp cho người bán một hồ sơ ủy quyền, kể cả với các giao dịch mua “Human Not Present” đã được phê duyệt từ trước. Phạm vi dưới 100 USD giới hạn mức ảnh hưởng khi có sự cố trong lúc việc áp dụng, danh tính tác nhân và trách nhiệm pháp lý dần hoàn thiện.
Với thương mại qua tác nhân AI, mô hình production gồm nhiều tầng: chọn cơ chế điều phối phù hợp với quy trình, cô lập phần thực thi có khả năng chi tiền, giới hạn công cụ và mức chi tiêu, lưu giữ hồ sơ ủy quyền và hoàn tiền, và luôn có một người được chỉ định rõ tên chịu trách nhiệm.
Cách Van Data Team đưa giải pháp vào vận hành thực tế
Tại Van Data Team, chúng tôi đưa thương mại qua tác nhân AI vào vận hành bằng cách truy vết từng giao dịch, từ lúc tìm thấy lời chào hàng đến khi mua, đối soát và hoàn tiền. Chúng tôi lập bản đồ nguồn cấp dữ liệu sản phẩm, các nguồn dữ liệu về giá và tình trạng còn hàng, quy tắc thanh toán, các bước bàn giao thanh toán, hồ sơ bản ủy quyền AP2, môi trường thực thi được CAPSEM cô lập (nếu có) và dấu vết kiểm toán. Mỗi quyết định đều có người phụ trách: tác nhân được phép làm gì, khi nào sự đồng ý đã ký là đủ và khi nào quy trình phải dừng lại.
Sau đó, chúng tôi khép lại những khoảng trống khiến thương mại ưu tiên sự đồng ý trở nên mong manh: điều khoản chào hàng mâu thuẫn, dữ liệu tồn kho lỗi thời, bằng chứng ủy quyền không đầy đủ, trách nhiệm hoàn tiền không rõ ràng và thiếu lộ trình khôi phục. Tự động hóa luôn nằm trong phạm vi quyền hạn đã được phê duyệt. Các lần kiểm tra chữ ký thất bại, thay đổi giá, điều khoản nằm ngoài bản ủy quyền và ngoại lệ chính sách được chuyển cho con người duyệt thay vì tiến hành thực thi giao dịch mua.
Kế hoạch triển khai có phạm vi xác định nêu rõ cần thu thập những tín hiệu nào, cần sửa những bước bàn giao nào và những hành động nào vẫn phải qua bước duyệt. Một dashboard hiển thị các lần xác minh bản ủy quyền thất bại, thông tin chào hàng không khớp, hành động bị từ chối, trạng thái giao dịch mua và các ngoại lệ hoàn tiền. Một runbook hướng dẫn đội ngũ khi nào cần dừng, thử lại, chuyển cấp, đối soát hoặc hoàn tiền, để phạm vi giao dịch dưới 100 USD đã được ủy quyền luôn có thể kiểm toán và vận hành được.
Câu hỏi thường gặp
AP2 có phải là giao thức mới không?
Không. Google đã công bố AP2 vào ngày 16/9/2025. Các cột mốc sau đó đã mở rộng đặc tả, bổ sung các cơ chế kiểm soát cho production và chuyển việc quản trị tiêu chuẩn sang FIDO Alliance. Thông báo tại Ấn Độ nhắc lại AP2 bên cạnh các hoạt động mới về an toàn.
"Human Not Present" có nghĩa là thanh toán mà không cần sự đồng ý của con người không?
Không. Nó có nghĩa là việc thực thi có thể diễn ra sau khi con người đã rời khỏi tương tác trực tiếp. Tác nhân hành động dựa trên sự ủy quyền đã được ký từ trước. Việc đưa con người ra khỏi thời điểm thực thi không loại bỏ sự đồng ý khỏi giao dịch.
CAPSEM, A2A và AP2 khác nhau như thế nào?
CAPSEM bảo mật môi trường thực thi. A2A cho phép các tác nhân giao tiếp với nhau. AP2 cung cấp sự ủy quyền thanh toán có thể xác minh. Một hệ thống triển khai an toàn có thể dùng cả ba, nhưng không thành phần nào thay thế được các thành phần còn lại.
Bản ủy quyền AP2 có loại bỏ được yêu cầu bồi hoàn (chargeback) không?
Không. Bản ủy quyền có thể củng cố bằng chứng bằng cách cho thấy người dùng đã ủy quyền cho điều gì, nhưng không tự động phân định trách nhiệm pháp lý hay ngăn chặn tranh chấp. Người bán vẫn cần thông tin chào hàng chính xác, hồ sơ thực hiện đơn hàng, quy trình hoàn tiền và đội ngũ hỗ trợ đã được đào tạo.
Thương hiệu nên làm cho những thông tin nào dễ đọc hiểu với tác nhân?
Hãy làm cho định danh sản phẩm, giá, đơn vị tiền tệ, tình trạng còn hàng, các hạn chế, điều khoản gia hạn, điều kiện giao hàng và chính sách hoàn tiền trở nên rõ ràng và nhất quán. Đồng thời xác định bản ghi có thẩm quyền và lưu giữ phiên bản đã được dùng trong giao dịch.
Vì sao prompt injection là vấn đề quản trị thương hiệu?
Tác nhân có thể gặp phải chỉ dẫn độc hại trên các bề mặt do người bán kiểm soát hoặc của bên thứ ba. Vì vậy, các đội ngũ marketing, thương mại điện tử và bảo mật cùng chia sẻ trách nhiệm về ranh giới dữ liệu đáng tin cậy, kiểm thử đầu vào, nguồn gốc nội dung và việc chuyển cấp sự cố.

