Với các doanh nghiệp đang đưa AI vào hệ thống SAP, điều cần đọc kỹ trong chính sách API mới không phải là câu hỏi “có còn được kết nối công cụ bên thứ ba hay không”. Vấn đề thực tế hơn là SAP đang thu hẹp cách sử dụng API cho dữ liệu và quy trình ERP cốt lõi vào các API đã công bố, tài liệu sản phẩm, kiến trúc được SAP công nhận, dịch vụ dữ liệu hoặc lộ trình dịch vụ được chỉ định.^[1][7][10]

ERP, tức hệ thống hoạch định nguồn lực doanh nghiệp, thường là nơi chứa dữ liệu tài chính, mua hàng, tồn kho, sản xuất, nhân sự và các giao dịch vận hành quan trọng. Vì vậy, khi một AI agent — hay tác tử AI — được kết nối vào SAP, câu chuyện không chỉ là đọc dữ liệu để trả lời câu hỏi. Trong nhiều kịch bản, agent có thể lập kế hoạch, chọn công cụ, gọi nhiều API liên tiếp và thậm chí đề xuất hoặc kích hoạt thay đổi trong quy trình nghiệp vụ. Đó là lý do chính sách mới có thể tác động trực tiếp đến PoC AI, nền tảng dữ liệu, RPA, iPaaS, ETL và các luồng tự động hóa tự xây của doanh nghiệp.^[1][13]

Chính sách mới thực sự siết ở đâu

SAP đang viết ranh giới sử dụng API một cách chính thức hơn. Theo CIO, SAP cho biết chỉ những giao diện được liệt kê trong SAP Business Accelerator Hub hoặc trong tài liệu sản phẩm tương ứng mới được xem là API đã công bố.^[7] The Register cũng đưa tin chính sách mới yêu cầu người dùng chỉ sử dụng API trong giới hạn của

SAP-endorsed architectures, data services, or service-specific pathways

[2]

[10]

Điều này đồng nghĩa doanh nghiệp không nên tiếp tục giả định rằng cứ gọi được một giao diện SAP thì giao diện đó phù hợp để dùng lâu dài. Tài liệu chính sách liệt kê các kiểm soát API như giới hạn chức năng và kỹ thuật, hạn mức sử dụng, lịch ngừng hỗ trợ, hạn mức dữ liệu vào ra, giới hạn và điều kiện cho trích xuất hoặc nhân bản dữ liệu hàng loạt, cùng các yêu cầu bảo mật hoặc kỹ thuật khác.^[9] SAPinsider cũng lưu ý rằng API chưa được tài liệu hóa vẫn đang được dùng rộng rãi, nhưng với chính sách mới, chúng nằm ngoài ranh giới hỗ trợ và làm tăng rủi ro vận hành, tích hợp dài hạn.^[1]

Nói ngắn gọn, đây không chỉ là một điều khoản về AI. Nó là bài toán quản trị tích hợp ERP: API nào được công bố, cách dùng nào được hỗ trợ, việc trích xuất hoặc nhân bản dữ liệu cần điều kiện gì, và tự động hóa nào buộc phải đi theo lộ trình được SAP công nhận.^[7][9][13]

Vì sao AI agent bên thứ ba trở nên nhạy cảm

Phần gây chú ý nhất là điều khoản về AI. Nhiều báo cáo trích dẫn chính sách cho biết, trừ khi đi qua kiến trúc, dịch vụ dữ liệu hoặc lộ trình được SAP công nhận, SAP cấm dùng API để tương tác hoặc tích hợp với các hệ thống AI bán tự chủ hoặc AI tạo sinh có khả năng lập kế hoạch, lựa chọn hoặc thực thi chuỗi lệnh gọi API.^[5][10]

Đây chính là khác biệt giữa tích hợp truyền thống và agentic AI. Một tích hợp truyền thống thường chạy theo luồng đã định sẵn: hệ thống A gọi API B để hoàn thành một tác vụ cụ thể. Trong khi đó, một AI agent có thể tự quyết định bước tiếp theo dựa trên mục tiêu được giao: kiểm tra nhà cung cấp, đối chiếu tồn kho, tạo đề xuất mua hàng, rồi chuyển phê duyệt hoặc cập nhật bản ghi. Nếu agent tự chọn và xâu chuỗi nhiều lệnh gọi SAP API, kịch bản đó có thể rơi vào phạm vi chính sách mô tả về việc điều phối nhiều bước API; việc có tuân thủ hay không còn tùy API, kiến trúc, dịch vụ dữ liệu và cách SAP chấp thuận.^[5][10]

Cùng nhóm hạn chế này cũng bao gồm scraping, harvesting, cũng như trích xuất hoặc nhân bản dữ liệu có hệ thống hoặc ở quy mô lớn.^[5][10] Vì vậy, không chỉ các agent có quyền ghi vào SAP mới bị ảnh hưởng. Những thiết kế đọc dữ liệu SAP hàng loạt để đưa sang nền tảng AI bên ngoài, lakehouse hoặc lớp điều phối agent cũng cần được rà soát lại.^[9][13]

PoC AI không nhất thiết phải dừng, nhưng sẽ bớt tùy hứng

Với đội đổi mới, nhà tích hợp hệ thống và nhà cung cấp phần mềm độc lập, thay đổi lớn nhất là trước khi thử nghiệm sẽ có thêm một cổng quản trị. Trước đây, một AI agent bên thứ ba có thể được kết nối nhanh vào ERP để thử đối soát tự động, trợ lý mua hàng, phân tích tồn kho hoặc tự động hóa dịch vụ khách hàng. Theo chính sách mới, nhóm triển khai cần xác nhận API có nằm trong SAP Business Accelerator Hub hoặc tài liệu sản phẩm hay không, kiến trúc có thuộc lộ trình được SAP công nhận hay không, mức dùng có chạm hạn mức hoặc điều kiện trích xuất hàng loạt hay không, và agent có tự lập kế hoạch cho nhiều lệnh gọi API hay không.^[5][7][9]

Điều này không có nghĩa các PoC AI không thể thực hiện. Nhưng PoC sẽ giống một dự án tích hợp chính thức hơn: cần kiểm kê API, thiết kế phân quyền, ước lượng lưu lượng, xem xét luồng dữ liệu và xác nhận tuân thủ. ERP Today nhận định chính sách này biến một vấn đề vốn thiên về kỹ thuật tích hợp thành vấn đề kiến trúc ERP rộng hơn, vì các tích hợp hiện hữu có thể đang dựa vào giao diện chưa được tài liệu hóa, trong khi ứng dụng AI mới lại cần truy cập có kiểm soát vào dữ liệu doanh nghiệp và workflow giao dịch.^[13]

Sự không rõ ràng cũng có thể làm chậm đổi mới. The Register đưa tin DSAG đã chỉ trích chính sách vì tạo ra bất định; cùng bài viết cũng nêu ý kiến phê bình rằng danh sách giao diện được SAP phê duyệt có thể chưa được quản lý tốt hoặc cập nhật kịp thời.^[2]

Kiểm soát dữ liệu: không chỉ là chuyện ai sở hữu dữ liệu

Tranh luận quanh chính sách này không dừng ở câu hỏi khách hàng có sở hữu dữ liệu của mình hay không. Điểm nhạy cảm hơn là khách hàng có thể dùng nền tảng AI, data stack và công cụ tự động hóa do chính họ lựa chọn để truy cập trực tiếp, liên tục và gần thời gian thực vào dữ liệu cùng quy trình giao dịch trong SAP hay không. The Register mô tả vấn đề là một số công cụ AI bên thứ ba có thể bị loại khỏi khả năng tiếp cận dữ liệu SAP của khách hàng; ERP Today đặt vấn đề trong bối cảnh rộng hơn về tuyến tích hợp ERP, nhân bản dữ liệu và quyền truy cập của AI.^[10][13]

Nếu doanh nghiệp muốn đồng bộ dữ liệu SAP sang lakehouse bên ngoài, nền tảng AI, lớp điều phối agent hoặc hệ thống tự động hóa của bên thứ ba, các hạng mục cần kiểm tra gồm hạn mức dữ liệu vào ra, điều kiện trích xuất hoặc nhân bản hàng loạt, phạm vi API đã công bố và việc có bắt buộc phải đi theo lộ trình được SAP công nhận hay không.^[7][9][10]

Những giới hạn như vậy có thể giúp tập trung kiểm soát về bảo mật, kiểm toán, hiệu năng và quản trị. Đổi lại, mức tự chủ của kiến trúc AI đa nền tảng có thể giảm, nhất là với các use case cần đọc ghi nhiều dữ liệu giao dịch SAP.^[9][13]

Rủi ro khóa nhà cung cấp tăng lên, nhưng không phải kết cục tất yếu

Rủi ro vendor lock-in — phụ thuộc sâu vào một nhà cung cấp — đến từ một câu hỏi rất thực tế: nếu AI agent bên thứ ba không thể tự do tương tác với SAP API, khách hàng sẽ có xu hướng phụ thuộc nhiều hơn vào kiến trúc được SAP công nhận, dịch vụ dữ liệu chính thức hoặc các cách tích hợp mà SAP cho phép rõ ràng. The Register đã mô tả điều khoản AI này là nguyên nhân làm dấy lên lo ngại về lock-in, vì nó có thể khiến một số công cụ AI bên thứ ba không tiếp cận được dữ liệu SAP của khách hàng.^[10]

Phản ứng của DSAG cho thấy cộng đồng khách hàng không chỉ quan tâm đến chi tiết kỹ thuật. E3 Magazine đưa tin DSAG cho rằng việc SAP siết chặt sử dụng API cho mục đích chưa được tài liệu hóa, trích xuất dữ liệu hàng loạt có hệ thống và tương tác với hệ thống AI tạo sinh tự chủ của bên thứ ba là không thể chấp nhận.^[11]

Tuy vậy, lock-in không phải kết quả duy nhất. Tác động thực tế sẽ phụ thuộc vào việc SAP có định nghĩa rõ lộ trình được công nhận hay không, có duy trì danh sách API đầy đủ và cập nhật kịp thời hay không, có cung cấp quy trình ngoại lệ hoặc phê duyệt có thể kiểm toán hay không, và có cho phép nhà cung cấp bên thứ ba tiếp tục đổi mới dưới các quy tắc rõ ràng hay không. Những phê bình về việc danh sách giao diện được phê duyệt có thể chưa được quản lý tốt chính là câu hỏi doanh nghiệp nên đặt ra trong quá trình mua sắm và thiết kế kiến trúc.^[2][7]

5 việc doanh nghiệp nên làm ngay

1. Kiểm kê toàn bộ tích hợp SAP. Gắn nhãn từng giao diện: API đã công bố, API nằm trong tài liệu sản phẩm, giao diện chưa được tài liệu hóa, trích xuất hàng loạt, đọc ghi thời gian thực, RPA, iPaaS, ETL hoặc luồng workflow và agent bên ngoài.^[1][7][13]

2. Rà soát riêng các use case AI. Bất kỳ quy trình nào để mô hình hoặc agent tự lập kế hoạch, lựa chọn hoặc thực thi nhiều lệnh gọi SAP API đều nên được đánh giá rủi ro chính sách trước khi mở rộng.^[5][10]

3. Kiểm tra trích xuất và nhân bản dữ liệu. Các hoạt động extraction, replication, scraping hoặc harvesting ở quy mô lớn đã được đặt trong phạm vi hạn chế; data lake, lakehouse, BI, AI training hoặc kiến trúc đồng bộ dữ liệu hiện hữu đều cần xác nhận lại hạn mức, điều kiện và lộ trình được phép.^[5][9][10]

4. Yêu cầu xác nhận bằng văn bản từ SAP hoặc đối tác triển khai. Với các kịch bản rủi ro cao như agentic AI, cập nhật giao dịch tự động, điều phối xuyên hệ thống hoặc xuất dữ liệu hàng loạt, không nên chỉ dựa vào diễn giải miệng. Việc DSAG chỉ trích sự bất định cho thấy ranh giới bằng văn bản quan trọng đến mức nào.^[2]

5. Giữ quyền lựa chọn trong kiến trúc. Ngay cả khi cuối cùng doanh nghiệp dùng lộ trình được SAP công nhận, nên thiết kế lớp điều phối AI, quản trị dữ liệu, phân quyền, nhật ký kiểm toán và quy tắc nghiệp vụ theo hướng mô-đun, để tránh toàn bộ logic đổi mới bị khóa cứng vào một tuyến tích hợp duy nhất.

Kết luận

Chính sách API SAP 2026 không có nghĩa là AI không được chạm vào SAP. Thông điệp thực tế là AI agent bên thứ ba không còn có thể mặc định tự do điều phối SAP API. Chính sách này nâng ngưỡng an toàn, kiểm soát và quản trị, nhưng đồng thời làm tăng chi phí tuân thủ, có thể khiến thử nghiệm chậm hơn và làm rõ hơn rủi ro phụ thuộc nhà cung cấp.^[10][13] Trong ngắn hạn, cách tiếp cận thực dụng nhất là kiểm kê tích hợp, phân loại rủi ro của AI agent, xác nhận lộ trình được SAP công nhận và chủ động giữ lại khả năng lựa chọn đa nền tảng trong kiến trúc mới.