Pada April 2026, pembaruan SAP API Policy mengubah pertanyaan seputar AI agent pihak ketiga. Isunya tidak lagi sebatas apakah konektor teknis bisa dibuat, tetapi apakah arsitektur, kontrak, dan tata kelola data perusahaan memang mengizinkan AI itu mengoperasikan SAP secara langsung.^[5][6][10]

Dalam dokumen kebijakannya, SAP menyatakan API Policy menjelaskan API availability dan API limits, serta menetapkan kontrol untuk menjaga kesehatan solusi, keamanan, akses yang adil, dan mencegah penyalahgunaan API.^[9]

Bagian yang paling memicu perdebatan adalah klausul AI. Analisis eksternal dan laporan media menyebut Bagian 2.2.2 dari SAP API Policy v4/2026 menargetkan sistem AI semi-otonom atau generatif yang dapat merencanakan, memilih, atau mengeksekusi rangkaian API calls. Di luar SAP-endorsed architectures, data services, atau service-specific pathways, jenis interaksi atau integrasi seperti ini dilarang.^[6][8][10]

Garis pemisah: AI memberi saran, atau AI menjalankan SAP?

Pembaruan ini tidak berarti SAP melarang semua penggunaan AI. Pembatasan yang lebih tajam berada pada pola agentic AI: AI agent menjadikan SAP API sebagai lapisan operasi yang bisa disusun bebas, memutuskan sendiri API call berikutnya, menggabungkan beberapa API, lalu menulis kembali hasilnya ke sistem bisnis inti.^[6][8][10]

Jika sebuah alat hanya memakai data yang sudah diekspor untuk membuat ringkasan, prediksi, atau rekomendasi, lalu manusia tetap memeriksa dan mengeksekusi langkah akhir di SAP, risikonya relatif lebih rendah. Sebaliknya, jika AI otomatis mengecek stok, mengubah pesanan, membuat purchase order, menyetujui alur kerja, memperbarui master data, atau merangkai beberapa tindakan SAP menjadi proses ujung-ke-ujung, risikonya naik tajam karena pola itu mendekati orkestrasi API multi-langkah dan perubahan status bisnis yang menjadi fokus kebijakan.^[6][8][10]

Dengan kata lain, kemampuan membuat koneksi API belum tentu sama dengan hak untuk memakai koneksi itu dalam produksi.

Empat batas praktis yang perlu dipahami

1. AI agent pihak ketiga harus melewati jalur yang diakui SAP

The Register melaporkan bahwa SAP melarang penggunaan API untuk mengintegrasikan sistem AI eksternal di luar arsitektur yang diakui SAP, sehingga memunculkan kekhawatiran bahwa alat AI pihak ketiga akan makin sulit mengakses data SAP milik pelanggan.^[10] Fivetran juga menyoroti bahwa kebijakan ini secara eksplisit menyebut sistem AI semi-otonom atau generatif yang merencanakan, memilih, atau mengeksekusi rangkaian API calls.^[8]

Implikasinya jelas: secara teknis bisa tersambung ke API tidak lagi cukup. Untuk membiarkan AI agent pihak ketiga mengoperasikan SAP, perusahaan perlu memastikan apakah solusinya berada dalam SAP-endorsed architecture, data service, atau service-specific pathway yang memang ditujukan untuk penggunaan tersebut.^[10]

2. Published dan documented APIs menjadi syarat dasar

SAPInsider menyebut pembaruan ini memperketat akses sistem ke published dan documented APIs. API yang tidak terdokumentasi berada di luar batas dukungan, sehingga risiko integrasi dan operasional jangka panjang meningkat.^[5] SAP API Policy sendiri mendefinisikan Published APIs sebagai API yang dipublikasikan di SAP Business Accelerator Hub, atau API Hub, maupun yang diidentifikasi dalam dokumentasi spesifik produk.^[9]

Bagi perusahaan yang selama bertahun-tahun mengandalkan konektor khusus, antarmuka lama, atau API tidak resmi, ini berarti inventarisasi integrasi menjadi mendesak. Integrasi yang masih berjalan hari ini belum tentu aman dari sisi dukungan, kepatuhan, dan proses upgrade di masa depan.^[5][9]

3. Ekstraksi dan replikasi data skala besar juga dibatasi

Kebijakan ini tidak hanya membahas AI agent yang merangkai API. Fivetran dan The Register sama-sama mencatat bahwa aturan tersebut juga mencakup scraping, harvesting, serta ekstraksi atau replikasi data secara sistematis dan berskala besar, kecuali melalui arsitektur dan jalur yang dikontrol atau diakui SAP.^[8][10]

Karena itu, rencana menyalin data SAP dalam jumlah besar ke data lake, warehouse, atau platform AI non-SAP tidak bisa dinilai hanya dari sisi kapasitas teknis dan biaya. Perusahaan juga harus memeriksa hak kontraktual, API limits, kebutuhan audit, dan jalur yang diizinkan dalam kebijakan API.^[8][9][10]

4. Ekosistem AI SAP menjadi pilihan yang lebih natural

Dokumentasi SAP menunjukkan bahwa perusahaan dapat membangun AI agents di SAP BTP dan mengintegrasikannya dengan Joule, kopilot AI pusat SAP, serta infrastruktur AI di SAP BTP. SAP Cloud SDK for AI juga dapat terhubung dengan framework agent umum melalui LangChain dan adapter lain.^[1]

SAP juga memosisikan SAP Knowledge Graph sebagai kemampuan yang mendukung Joule dan AI lain, termasuk AI agents, dengan memberi konteks bisnis dari aplikasi SAP agar jawaban AI lebih akurat dan relevan.^[4]

Ini bukan berarti semua solusi pihak ketiga otomatis tidak bisa dipakai. Namun ketika batas kebijakan makin sempit, jalur resmi atau jalur yang diakui SAP cenderung lebih mudah diterima oleh tim arsitektur enterprise, hukum, keamanan, dan risiko.^[1][4][10]

Skenario AI mana yang paling terdampak?

Skenario penggunaan	Tingkat dampak	Mengapa
BI, laporan, atau analisis offline memakai data yang sudah diekstrak secara sah	Rendah hingga sedang	Jika AI tidak langsung mengorkestrasi SAP API, risikonya lebih kecil; tetapi ekstraksi atau replikasi skala besar tetap harus diperiksa terhadap batas kebijakan.[8][10]
Chatbot hanya memberi rekomendasi, lalu manusia mengeksekusi tindakan di SAP	Rendah	Fokus kebijakan berada pada AI yang merencanakan, memilih, atau mengeksekusi rangkaian API calls; alur saran berbeda dari agent yang langsung bertindak.[6][8]
AI otomatis mengecek stok, mengubah order, membuat purchase order, menyetujui proses, atau memperbarui master data	Tinggi	Skenario ini biasanya melibatkan API call multi-langkah, write-back, dan perubahan status bisnis di SAP.[6][8][10]
Data SAP disalin besar-besaran ke platform eksternal untuk dipakai AI	Tinggi	Kebijakan juga menyebut scraping, harvesting, serta ekstraksi atau replikasi data yang sistematis dan berskala besar.[8][10]
Connector lama atau integrasi khusus bergantung pada API yang tidak terdokumentasi	Sedang hingga tinggi	SAPInsider menyatakan API tidak terdokumentasi berada di luar batas dukungan; SAP Policy mendefinisikan Published APIs sebagai API di API Hub atau dokumentasi produk.[5][9]

Dampak bagi inovasi: PoC harus diaudit lebih awal

Dari sudut pandang tata kelola platform, SAP punya alasan untuk mengendalikan agent eksternal yang memanggil API ERP inti tanpa batas, terutama pada skenario yang menulis data, menjalankan transaksi, atau membebani performa sistem. SAP API Policy sendiri menyebut tujuan kontrolnya adalah menjaga kesehatan solusi, keamanan, akses yang adil, dan mencegah penyalahgunaan API.^[9]

Namun bagi tim pengembang, biaya awal AI proof of concept akan meningkat. Dulu eksperimen mungkin cukup dimulai dengan akses API, connector, dan pengujian alur. Sekarang, jika AI menentukan langkah berikutnya sendiri dan menjalankan tugas lintas-API, perusahaan perlu lebih dulu memastikan apakah skenario itu berada dalam arsitektur, data service, atau jalur layanan yang diakui SAP.^[8][10]

Artinya, inovasi tidak berhenti, tetapi harus lebih tertib sejak awal. Baik agent buatan sendiri, produk mitra, maupun platform AI pihak ketiga perlu melewati tinjauan kontrak, arsitektur, dan tata kelola data sebelum terlalu jauh dibangun.^[5][8][10]

Dampak terhadap kontrol data: bisa mengakses tidak sama dengan boleh mengoperasikan

Kebijakan ini terutama mengatur ketersediaan API, batas penggunaan API, dan kontrol operasional; ia bukan dokumen lengkap tentang kepemilikan data.^[9] Namun dalam konteks agentic AI, kontrol tidak hanya berarti bisa mengunduh laporan. Kontrol juga berarti siapa yang boleh membaca, menulis, mengurutkan tindakan, dan mengeksekusi API calls secara real time hingga mengubah status bisnis di dalam SAP.^[6][8][10]

Analisis eksternal menggambarkan isu ini sebagai momen peninjauan ulang integrasi data perusahaan: pertanyaannya bukan hanya apakah perusahaan bisa mengakses data SAP, tetapi apakah AI agent pilihan perusahaan boleh langsung mengambil tindakan atas data dan proses tersebut.^[6]

Perlu dicatat secara adil, analisis Kai Waehner mengutip klarifikasi CEO SAP Christian Klein bahwa niat kebijakan adalah melindungi domain know-how SAP dan mencegah penurunan performa, bukan menghalangi pelanggan mengakses data mereka sendiri.^[6] Bagi perusahaan, klarifikasi seperti ini tetap perlu diterjemahkan ke dalam kontrak, kebijakan API, daftar arsitektur yang diakui, dan izin eksplisit untuk setiap use case.^[6][9][12]

Dampak vendor lock-in: penguncian bisa terjadi di lapisan orkestrasi

Vendor lock-in tidak selalu berarti data sama sekali tidak bisa diekspor. Di era AI agent, penguncian bisa muncul di lapisan orkestrasi proses: jika jalur otomatisasi yang paling aman, paling mudah diaudit, dan paling minim sengketa adalah menaruh agent di SAP BTP, Joule, AI Core, atau Knowledge Graph, maka arsitektur AI jangka panjang perusahaan akan makin bergantung pada ekosistem SAP.^[1][4][10]

The Register secara eksplisit menyebut klausul AI baru ini memunculkan kekhawatiran lock-in karena alat AI pihak ketiga dapat menjadi lebih sulit mengakses data dan proses SAP pelanggan secara langsung.^[10] Fivetran juga menilai kebijakan ini menaikkan taruhan dalam strategi AI perusahaan, khususnya ketika perusahaan ingin memberi AI agents akses ke data ERP.^[8]

Lima langkah yang sebaiknya dilakukan perusahaan

1. Pisahkan use case AI secara rinci. Bedakan skenario read-only, write-back, persetujuan manusia, dan eksekusi multi-langkah oleh AI. Risiko kebijakan biasanya melonjak pada dua skenario terakhir.^[6][8][10]
2. Minta konfirmasi jalur yang diakui SAP. Untuk setiap skenario, tanyakan apakah implementasi dapat dilakukan melalui SAP-endorsed architecture, data service, service-specific pathway, atau arsitektur terkait SAP BTP dan Joule.^[1][10]
3. Periksa apakah API sudah published dan documented. Jika integrasi lama memakai API tidak terdokumentasi, siapkan rencana refactoring dan evaluasi risiko dukungan jangka panjang.^[5][9]
4. Tulis hak data dan tanggung jawab AI ke dokumen kontrak serta tata kelola. Perjelas penggunaan AI pihak ketiga, ekstraksi dan replikasi data, API limits, audit, tanggung jawab insiden, serta batas tanggung jawab saat AI menulis balik ke SAP.^[8][9][10]
5. Pantau FAQ dan pembaruan kebijakan SAP. Dokumen FAQ SAP menyatakan berisi jawaban atas pertanyaan umum terkait API Policy dan dapat diperbarui dari waktu ke waktu; perusahaan sebaiknya tidak hanya bergantung pada interpretasi lisan satu kali.^[12]

Kesimpulan

Pesan utama SAP API Policy terbaru adalah: AI agent pihak ketiga tidak bisa lagi berasumsi bebas mengorkestrasi SAP API. Untuk alat yang hanya membuat laporan, analisis offline, atau rekomendasi dengan persetujuan manusia, dampaknya mungkin terbatas. Tetapi bagi perusahaan yang ingin AI langsung menjalankan proses inti SAP, menulis balik ke ERP, atau menyalin data skala besar ke platform eksternal, kebijakan ini menjadi titik pemeriksaan besar di level arsitektur, kontrak, dan tata kelola data.^[8][10]

Jika perusahaan sudah menaruh strategi pada SAP BTP, Joule, dan SAP AI Core, kebijakan ini dapat membuat jalur resmi tampak lebih jelas.^[1][4] Sebaliknya, jika perusahaan ingin membangun lapisan AI agent terbuka yang melintasi ERP, CRM, supply chain, dan platform data lain, pemeriksaan terhadap arsitektur yang diakui SAP, hak penggunaan API, dan batas ekstraksi data perlu dilakukan sebelum investasi pengembangan berjalan terlalu jauh.^[5][10]