Tháng 4/2026, SAP cập nhật chính sách API, khiến câu hỏi “AI agent bên thứ ba có thể trực tiếp thao tác SAP hay không?” không còn là chuyện kết nối kỹ thuật đơn thuần. Với nhiều doanh nghiệp đang dùng SAP cho ERP và các quy trình lõi, đây trở thành bài toán về kiến trúc hệ thống, quyền sử dụng theo hợp đồng và quản trị dữ liệu.[5][
6][
10]
Chính sách API của SAP nói rõ mục tiêu là xác định mức độ sẵn có của API, giới hạn API và các biện pháp kiểm soát nhằm bảo vệ sức khỏe giải pháp, an ninh hệ thống, quyền truy cập công bằng và ngăn lạm dụng API.[9] Điểm gây tranh luận nằm ở điều khoản AI: các phân tích bên ngoài và truyền thông cho biết mục 2.2.2 của API Policy v4/2026 nhắm đến các hệ thống AI bán tự chủ hoặc AI sinh tạo có khả năng tự lập kế hoạch, lựa chọn hoặc thực thi chuỗi lệnh gọi API; trừ khi đi qua kiến trúc, dịch vụ dữ liệu hoặc lộ trình dịch vụ được SAP công nhận, kiểu tương tác hoặc tích hợp này sẽ bị cấm hoặc bị giới hạn.[
6][
8][
10]
Không phải cấm AI, mà là siết quyền tự hành của AI đối với SAP
Cách hiểu chính xác hơn là: SAP không tuyên bố cấm doanh nghiệp dùng AI. Điều bị siết là mô hình trong đó AI agent coi SAP API như một lớp thao tác tự do, có thể tự quyết định bước tiếp theo, gọi nhiều API liên tiếp và thậm chí ghi kết quả trở lại hệ thống nghiệp vụ lõi.[6][
8][
10]
Nếu một công cụ AI chỉ dùng dữ liệu đã được xuất ra để tóm tắt, dự báo hoặc đưa khuyến nghị, còn người dùng vẫn đăng nhập SAP để kiểm tra và thực hiện thao tác cuối cùng, rủi ro chính sách thường thấp hơn. Ngược lại, nếu AI tự kiểm tra tồn kho, sửa đơn hàng, tạo đơn mua, phê duyệt quy trình, cập nhật dữ liệu chủ hoặc nối nhiều hành động SAP thành một luồng end-to-end, rủi ro sẽ tăng đáng kể vì thiết kế đó gần với mô hình AI tự điều phối nhiều API và làm thay đổi trạng thái nghiệp vụ.[6][
8][
10]
Bốn ranh giới thực tế doanh nghiệp cần nhìn rõ
1. AI agent bên thứ ba cần đi qua lộ trình được SAP công nhận
The Register tóm lược rằng SAP cấm dùng API để tích hợp với hệ thống AI bên ngoài các kiến trúc được SAP công nhận, làm dấy lên lo ngại rằng công cụ AI bên thứ ba có thể bị chặn khỏi dữ liệu SAP của khách hàng.[10] Fivetran cũng chỉ ra rằng chính sách nêu đích danh các hệ thống AI bán tự chủ hoặc AI sinh tạo có khả năng tự lập kế hoạch, lựa chọn hoặc thực thi chuỗi lệnh gọi API.[
8]
Nói ngắn gọn: gọi được API về mặt kỹ thuật không còn đồng nghĩa với được phép để AI agent tự do điều phối API. Với mỗi use case, doanh nghiệp cần hỏi rõ giải pháp đó có thuộc kiến trúc được SAP công nhận, dịch vụ dữ liệu được phép hay lộ trình dịch vụ được chỉ định hay không.[10]
2. API được công bố và có tài liệu trở thành yêu cầu nền tảng
SAPInsider cho biết bản cập nhật này siết quyền truy cập hệ thống vào các API đã được công bố và có tài liệu; API không được tài liệu hóa rơi ra ngoài ranh giới hỗ trợ, làm tăng rủi ro tích hợp và vận hành dài hạn.[5] Chính sách của SAP cũng định nghĩa Published APIs là các API được công bố trên SAP Business Accelerator Hub, còn gọi là API Hub, hoặc được nhận diện trong tài liệu riêng của sản phẩm.[
9]
Điều này đặc biệt quan trọng với các doanh nghiệp đang dùng connector cũ, tích hợp tùy biến hoặc API chưa chính thức. Ngay cả khi kết nối hiện tại vẫn chạy, rủi ro về hỗ trợ, tuân thủ và nâng cấp trong tương lai có thể tăng lên.[5][
9]
3. Trích xuất và sao chép dữ liệu quy mô lớn cũng bị soi kỹ hơn
Chính sách không chỉ nhắm vào AI agent tự gọi API nhiều bước. Fivetran và The Register đều cho biết điều khoản mới còn đề cập đến scraping, harvesting, cũng như trích xuất hoặc sao chép dữ liệu có hệ thống hay quy mô lớn; trừ khi đi qua kiến trúc và lộ trình do SAP kiểm soát hoặc công nhận, các cách làm này có thể bị hạn chế.[8][
10]
Vì vậy, nếu doanh nghiệp muốn đưa dữ liệu SAP sang data lake, data warehouse hoặc nền tảng AI không thuộc SAP, bài toán không chỉ là băng thông, chi phí lưu trữ hay độ trễ. Cần kiểm tra cả API policy, quyền sử dụng, API limits, yêu cầu kiểm toán và lộ trình được phép.[8][
9][
10]
4. Hệ sinh thái AI của SAP trở thành lựa chọn “dễ qua cửa” hơn
Tài liệu chính thức của SAP cho biết doanh nghiệp có thể xây AI agent trên SAP BTP và tích hợp với Joule, trợ lý AI trung tâm của SAP, cùng hạ tầng AI nền tảng trên SAP BTP; SAP Cloud SDK for AI cũng có thể kết nối với các framework agent phổ biến thông qua LangChain và adapter khác.[1] SAP cũng định vị SAP Knowledge Graph là năng lực hỗ trợ Joule và các AI khác, bao gồm AI agent, bằng cách đặt AI vào ngữ cảnh nghiệp vụ từ ứng dụng SAP để tăng độ chính xác và liên quan của phản hồi.[
4]
Điều này không có nghĩa mọi giải pháp bên thứ ba đều không thể dùng. Nhưng khi ranh giới chính sách hẹp hơn, các lộ trình chính thức hoặc được SAP công nhận thường sẽ dễ được đội kiến trúc, pháp chế và quản trị rủi ro chấp thuận hơn.[1][
4][
10]
Những dự án AI nào chịu tác động mạnh nhất?
| Tình huống sử dụng | Mức ảnh hưởng | Vì sao |
|---|---|---|
| Dùng dữ liệu đã được trích xuất hợp lệ để làm BI, báo cáo hoặc phân tích ngoại tuyến | Thấp đến trung bình | Nếu AI không trực tiếp điều phối SAP API, rủi ro agentic AI thấp hơn; nhưng trích xuất hoặc sao chép dữ liệu quy mô lớn vẫn cần kiểm tra chính sách.[ |
| Chatbot chỉ đưa khuyến nghị, người dùng tự xác nhận và thao tác trong SAP | Thấp | Trọng tâm của điều khoản là AI có khả năng lập kế hoạch, chọn hoặc thực thi chuỗi lệnh gọi API; luồng chỉ tư vấn khác với agent trực tiếp vận hành.[ |
| AI tự kiểm tra tồn kho, sửa đơn hàng, tạo đơn mua, phê duyệt hoặc cập nhật dữ liệu chủ | Cao | Các quy trình này thường gồm nhiều bước API, ghi ngược dữ liệu và thay đổi trạng thái nghiệp vụ, sát với mô hình agentic AI mà chính sách nhắm tới.[ |
| Sao chép dữ liệu SAP quy mô lớn sang nền tảng bên ngoài để dùng cho AI | Cao | Chính sách cũng nêu scraping, harvesting, trích xuất hoặc sao chép dữ liệu có hệ thống và quy mô lớn.[ |
| Connector cũ hoặc tích hợp tùy biến dựa vào API không có tài liệu | Trung bình đến cao | SAPInsider cho biết API không tài liệu hóa nằm ngoài ranh giới hỗ trợ; chính sách của SAP định nghĩa Published APIs là API trên API Hub hoặc trong tài liệu sản phẩm.[ |
PoC AI cần được rà soát kiến trúc sớm hơn
Từ góc độ vận hành nền tảng, SAP có lý do để kiểm soát việc agent bên ngoài gọi không giới hạn vào API của hệ thống ERP lõi, nhất là các tình huống có ghi dữ liệu, chạy giao dịch hoặc ảnh hưởng hiệu năng. Chính sách API của SAP nêu rõ các biện pháp kiểm soát nhằm bảo vệ sức khỏe giải pháp, an ninh, quyền truy cập công bằng và ngăn lạm dụng API.[9]
Nhưng với đội phát triển, chi phí chuẩn bị cho một proof of concept, tức thử nghiệm ý tưởng, sẽ tăng. Trước đây, một nhóm có thể chỉ cần xin quyền API, dựng connector và thử luồng nghiệp vụ. Nay, nếu AI có thể tự quyết định bước kế tiếp và gọi nhiều API để hoàn thành việc, nhóm dự án phải kiểm tra sớm xem mô hình đó có thuộc kiến trúc, dịch vụ dữ liệu hoặc lộ trình dịch vụ được SAP công nhận hay không.[8][
10]
Nói cách khác, đổi mới không dừng lại, nhưng cần quản trị từ đầu. Dự án tự xây agent, dùng sản phẩm của đối tác hay kết nối với nền tảng AI bên thứ ba đều nên được rà soát đồng thời về kiến trúc, dữ liệu, pháp lý và vận hành trước khi viết quá nhiều mã tích hợp.[5][
8][
10]
Dữ liệu: có quyền xem không đồng nghĩa quyền cho agent tự hành
Bản chính sách này chủ yếu nói về mức độ sẵn có của API, giới hạn API và cơ chế kiểm soát, không phải một tuyên bố đầy đủ về quyền sở hữu dữ liệu.[9] Tuy nhiên, trong bối cảnh agentic AI, quyền kiểm soát không chỉ là có tải được báo cáo hay không. Vấn đề còn là ai được đọc tức thời, ghi dữ liệu, sắp xếp lệnh gọi API và thực thi hành động làm thay đổi trạng thái nghiệp vụ trong SAP.[
6][
8][
10]
Một phân tích bên ngoài của Kai Waehner mô tả đây là thời điểm doanh nghiệp phải rà soát lại chiến lược tích hợp dữ liệu: không chỉ hỏi có lấy được dữ liệu SAP hay không, mà còn phải hỏi AI agent do doanh nghiệp chọn có được trực tiếp hành động trên dữ liệu và quy trình đó hay không.[6]
Cũng cần nhìn nhận công bằng rằng phân tích này dẫn lại phần làm rõ từ CEO SAP Christian Klein: mục đích của chính sách là bảo vệ domain know-how của SAP và tránh suy giảm hiệu năng, không phải ngăn khách hàng truy cập dữ liệu của chính họ.[6] Với doanh nghiệp, phần quan trọng là biến cách hiểu đó thành điều khoản cụ thể trong hợp đồng, tài liệu quản trị, danh sách kiến trúc được công nhận và giấy phép rõ ràng cho từng use case.[
6][
9][
12]
Vendor lock-in có thể xuất hiện ở lớp điều phối quy trình
Vendor lock-in không nhất thiết nghĩa là dữ liệu hoàn toàn không thể xuất ra. Trong kỷ nguyên AI agent, điểm khóa chặt có thể nằm ở lớp điều phối quy trình: nếu con đường an toàn nhất, ít tranh cãi nhất và dễ tuân thủ nhất là đặt agent trong SAP BTP, Joule, SAP AI Core hoặc các năng lực liên quan đến Knowledge Graph, kiến trúc AI dài hạn của doanh nghiệp sẽ tự nhiên phụ thuộc nhiều hơn vào hệ sinh thái SAP.[1][
4][
10]
The Register nêu rõ điều khoản AI mới đã tạo lo ngại về lock-in vì công cụ AI bên thứ ba có thể khó tiếp cận trực tiếp dữ liệu và quy trình SAP của khách hàng hơn.[10] Fivetran cũng cho rằng chính sách này làm tăng mức độ rủi ro và đánh đổi trong chiến lược AI của doanh nghiệp, đặc biệt khi doanh nghiệp muốn cho AI agent truy cập dữ liệu ERP.[
8]
Năm việc doanh nghiệp nên làm ngay
- Tách nhỏ từng use case AI. Phân biệt rõ luồng chỉ đọc, luồng ghi ngược, luồng có người xác nhận và luồng AI tự thực thi nhiều bước; rủi ro chính sách thường tăng mạnh ở hai nhóm sau.[
6][
8][
10]
- Yêu cầu SAP, đối tác hoặc đơn vị tích hợp xác nhận lộ trình được phép. Hỏi cụ thể use case có thể triển khai qua kiến trúc được SAP công nhận, dịch vụ dữ liệu, lộ trình dịch vụ chỉ định hoặc kiến trúc liên quan SAP BTP/Joule hay không.[
1][
10]
- Kiểm kê API đang dùng có được công bố và có tài liệu hay không. Nếu đang dựa vào API không tài liệu hóa, cần dự trù chi phí tái cấu trúc và rủi ro hỗ trợ dài hạn.[
5][
9]
- Đưa quyền dữ liệu và trách nhiệm vận hành vào tài liệu quản trị. Đặc biệt cần làm rõ việc AI bên thứ ba sử dụng dữ liệu, trích xuất hoặc sao chép dữ liệu, API limits, kiểm toán, xử lý sự cố và trách nhiệm khi AI ghi ngược vào SAP.[
8][
9][
10]
- Theo dõi FAQ và cập nhật chính sách của SAP. Tài liệu FAQ của SAP nói rằng nội dung trả lời các câu hỏi thường gặp về API Policy có thể được cập nhật theo thời gian; doanh nghiệp không nên chỉ dựa vào một lần giải thích miệng hoặc một bản đánh giá duy nhất.[
12]
Kết luận
Thông điệp chính của chính sách API mới là: AI agent bên thứ ba không nên mặc định rằng mình có thể tự do điều phối SAP API. Với công cụ chỉ làm báo cáo, phân tích ngoại tuyến hoặc khuyến nghị có người xác nhận, tác động có thể hạn chế. Nhưng với dự án để AI trực tiếp vận hành quy trình SAP, ghi ngược vào ERP hoặc sao chép dữ liệu quy mô lớn, đây là điểm kiểm tra lớn về kiến trúc, quyền sử dụng và quản trị dữ liệu.[8][
10]
Nếu doanh nghiệp đã đặt cược vào SAP BTP, Joule và SAP AI Core, chính sách mới có thể làm lộ trình chính thức trở nên rõ hơn.[1][
4] Ngược lại, nếu doanh nghiệp muốn xây một lớp AI agent mở, kết nối nhiều hệ thống nghiệp vụ và nền tảng dữ liệu, cần xác nhận trước kiến trúc được SAP công nhận, quyền dùng API và ranh giới trích xuất dữ liệu — trước khi dự án đổi mới được xây trên một cách tích hợp có thể khó vận hành hợp lệ về sau.[
5][
10]
