Ditulis oleh Tim Langit Kreasi Solusindo  |  5 Mei 2026

Ketika AI Menulis Kode Salesforce, Siapa yang Menanggung Risikonya?

Bayangkan seorang admin Salesforce yang baru bergabung di tim Anda. Dalam hitungan menit, ia berhasil menghasilkan puluhan baris Apex code, membangun sebuah Lightning Web Component, bahkan menyusun logika Flow yang kompleks — semua dengan bantuan AI.

Hasilnya terlihat sempurna. Berjalan mulus di sandbox. Masuk production.

Lalu dua minggu kemudian: data pelanggan bocor karena komponen tersebut berjalan di konteks yang salah, mengekspos field yang seharusnya terbatas.

Pertanyaannya sederhana tapi jawabannya tidak: siapa yang bertanggung jawab?

Inilah diskusi yang kini mulai muncul di komunitas Salesforce global — dan sudah saatnya kita bahas dengan jernih di konteks bisnis Indonesia.

AI dalam Pengembangan Salesforce: Peluang yang Juga Membawa Risiko Tersembunyi

Tidak ada yang perlu diperdebatkan soal manfaat AI dalam ekosistem Salesforce. Tugas-tugas yang dulu memakan berjam-jam kini bisa diselesaikan dalam hitungan menit — mulai dari menulis formula, membuat Apex trigger, hingga membangun proof of concept Flow.

Ini adalah percepatan nyata. Aksesibilitasnya meningkat. Bahkan orang-orang yang sebelumnya tidak punya kapasitas teknis cukup kini bisa membangun sesuatu yang fungsional.

Namun, di balik kecepatan itu, ada trade-off yang jarang dibicarakan secara terbuka:

“AI menurunkan hambatan untuk membangun sesuatu, tapi tidak menurunkan hambatan untuk memahami apa yang sedang dibangun.”

Kalimat ini bukan sekadar retorika. Ini adalah akar dari hampir semua masalah yang muncul ketika AI digunakan tanpa pengawasan yang tepat dalam pengembangan Salesforce.

Tiga Risiko Nyata yang Sering Diabaikan

1. Risiko Keamanan yang Tidak Terlihat dari Permukaan

Ini adalah risiko paling berbahaya karena ia tidak tampak. Sebuah Lightning Web Component bisa menampilkan data dengan benar di UI — terlihat berfungsi sempurna — namun jika ia berjalan di konteks yang keliru, seseorang dengan niat buruk yang memahami struktur sistem dapat melakukan query terhadap data apa pun yang mereka inginkan.

Masalahnya: developer yang tidak memahami apa yang dihasilkan AI tidak akan tahu harus memeriksa bagian mana. Kode terlihat benar. Hasilnya terlihat benar. Risikonya tersembunyi di lapisan yang tidak diperiksa.

2. Technical Debt yang Menumpuk Diam-Diam

AI tidak menciptakan technical debt — orangnya yang menggunakannya yang berpotensi melakukannya. Ketika tim membangun lebih cepat dari sebelumnya menggunakan AI, volume output meningkat drastis. Lebih banyak kode, lebih banyak Flow, lebih banyak komponen — yang masing-masing bisa membawa duplikasi, inkonsistensi, dan keputusan arsitektur yang buruk.

Dalam jangka pendek semuanya tampak baik. Dalam jangka panjang, org Salesforce menjadi sulit di-maintain dan mahal untuk diperbaiki.

3. Erosi Pemahaman Tim

Jika tim mulai terlalu bergantung pada AI untuk menghasilkan solusi, semakin sedikit orang yang benar-benar memahami bagaimana sistem bekerja. Di Salesforce — di mana kompleksitas sudah tinggi secara alami — hilangnya pemahaman ini adalah risiko operasional yang serius.

Dokumentasi yang ditulis oleh manusia, dipahami oleh manusia, tetap tidak tergantikan.

“Ini Salah AI” — Argumen yang Tidak Berlaku

Saat sesuatu berjalan salah, ada godaan kuat untuk menunjuk ke tool. Tapi ini bukan argumen yang valid.

AI adalah tool. Bukan pengambil keputusan. Ia tidak memiliki konteks bisnis Anda, tidak memahami compliance requirements industri Anda, tidak tahu siapa yang seharusnya bisa mengakses data apa di org Anda.

Analogi yang tepat: jika Anda menggunakan gergaji listrik tanpa pelatihan yang memadai dan melukai diri sendiri, kesalahannya bukan pada gergaji. Tapi dalam kasus Salesforce, “lukanya” bisa berupa eksposur data ribuan pelanggan, atau sistem yang berhenti bekerja saat momen paling kritis.

Tanggung jawab atas output AI tetap sepenuhnya ada pada manusia yang menggunakannya.

Tapi Bukan Hanya Individu — Ini Soal Organisasi dan Sistem

Di sinilah diskusi ini menjadi lebih kompleks. Mudah untuk mengatakan “developer yang pakai AI harus bertanggung jawab.” Tapi kenyataannya tidak sesederhana itu.

Di banyak organisasi saat ini, penggunaan AI sedang didorong dari atas ke bawah. Ada target produktivitas yang dikaitkan dengan seberapa banyak AI digunakan. Ada tekanan untuk deliver lebih cepat, lebih banyak, lebih sering.

Ketika kecepatan menjadi prioritas utama dan proses review mulai dikesampingkan, risiko tidak lagi hanya milik developer atau admin yang menulis kode-nya. Risiko itu juga menjadi milik organisasi yang menciptakan lingkungan tersebut.

Salesforce sendiri beroperasi di bawah Shared Responsibility Model — sebuah kerangka yang menegaskan bahwa tanggung jawab keamanan dan keberhasilan implementasi terbagi antara Salesforce sebagai platform dan pelanggan sebagai pengguna. Model ini tidak berubah hanya karena ada AI di tengah-tengahnya.

Artinya: bahkan jika seorang junior admin yang menggunakan AI menghasilkan kode bermasalah, organisasi yang mendorongnya menggunakan AI tanpa governance yang memadai juga menanggung bagian dari risiko tersebut.

Skill Boundary: Batas yang Tidak Boleh Diabaikan

Ada analogi yang sangat tepat untuk menggambarkan situasi ini: mempersiapkan ikan blowfish. Ada bagian kecil yang aman dimakan, tapi sebagian besar dagingnya beracun. Jika Anda tidak terlatih, Anda tidak seharusnya menyentuhnya.

Hal yang sama berlaku untuk AI dalam pengembangan Salesforce. Jika Anda menggunakannya untuk menghasilkan sesuatu yang tidak sepenuhnya Anda pahami, maka tugas Anda adalah membawa seseorang yang memahaminya — bukan langsung mendeploy ke production.

  • Junior admin menggunakan AI untuk menghasilkan Apex? Perlu review dari senior developer.
  • Developer menggunakan AI untuk membangun integrasi dengan sistem eksternal? Perlu sign-off dari architect.
  • AI menghasilkan logika pricing atau permissioning? Perlu validasi dari business stakeholder dan security reviewer.

AI mempercepat build. Tapi governance tidak boleh ikut dipercepat — governance harus diperketat seiring meningkatnya kecepatan output.

Konteks Indonesia: Mengapa Ini Lebih Relevan dari yang Terlihat

Di Indonesia, adopsi Salesforce terus meningkat — terutama di sektor perbankan, asuransi, telekomunikasi, dan perusahaan teknologi. Banyak di antaranya beroperasi di bawah regulasi ketat: OJK, POJK terkait keamanan data, hingga implikasi UU PDP yang mulai berlaku efektif.

Dalam konteks ini, kode yang dihasilkan AI tanpa review yang memadai bukan hanya risiko teknis — ia bisa menjadi risiko kepatuhan yang berujung pada sanksi regulatori.

Tim yang menggunakan AI secara produktif di lingkungan ini adalah tim yang:

  • Memiliki pemahaman mendalam tentang platform Salesforce — bukan sekadar pengguna tools-nya
  • Menerapkan review process yang ketat sebelum setiap deployment
  • Mampu membedakan mana output AI yang aman digunakan langsung dan mana yang perlu dimodifikasi signifikan
  • Menjaga dokumentasi yang ditulis dan dipahami oleh manusia

AI Hanya Sepowerful Tim yang Menggunakannya

AI dalam pengembangan Salesforce adalah multiplier — ia mengalikan kapabilitas tim yang menggunakannya. Tim yang kuat dan berpengalaman akan menjadi lebih produktif. Tim yang lemah atau kurang terstruktur akan membuat lebih banyak masalah dengan lebih cepat.

Di Langit Kreasi Solusindo, kami memahami bahwa mengadopsi AI dalam pengembangan Salesforce bukan sekadar soal mengaktifkan fitur atau mempercepat delivery. Ini soal memastikan setiap output AI dievaluasi oleh orang yang tahu apa yang seharusnya dicari — dari sisi keamanan, performa, arsitektur, dan compliance.

Kami tidak sekadar menggunakan AI. Kami memastikan AI digunakan dengan tepat.

Jika organisasi Anda sedang dalam proses mengadopsi atau memperluas implementasi Salesforce — dan ingin memastikan AI menjadi aset bukan liability — mari berdiskusi. Tim kami siap membantu Anda membangun sistem yang tidak hanya cepat, tapi juga aman dan berkelanjutan.

 

Cari Tahu Bagaimana Kami Menggunakan AI

 

Artikel ini diadaptasi dari: Who Owns the Risk When AI Writes Your Salesforce Code? — Salesforce Ben, Thomas Morgan, 4 Mei 2026.