Cara AI Agent Terhubung ke Sistem Perusahaan: Arsitektur, Alur, dan Praktik Keamanan

Pahami dulu arti “integrasi”: model tidak seharusnya memiliki izin langsung ke sistem

Ketika perusahaan menghubungkan AI Agent dengan ERP, CRM, OA, tiket layanan, atau basis pengetahuan, intinya bukan menghubungkan model ke basis data, melainkan memungkinkannya menjalankan kueri, membuat penilaian, atau melakukan eksekusi terbatas melalui alat yang terkontrol dan dengan otorisasi yang jelas. Model bertugas memahami kebutuhan dan mengusulkan langkah berikutnya; lapisan alat mendefinisikan serta memvalidasi tindakan; sistem perusahaan tetap menjadi sumber otoritatif untuk data dan aturan bisnis.

Rekomendasi Agent tidak berarti sistem sudah menjalankan tindakan, dan keberhasilan pemanggilan alat juga tidak berarti hasil bisnisnya benar. Keduanya perlu diverifikasi. Untuk memahami mekanisme pemanggilan alat, lihat dokumentasi pemanggilan fungsi OpenAI: model menghasilkan informasi pemanggilan alat sesuai definisinya, sedangkan eksekusi aktual tetap ditangani oleh aplikasi.

Inventarisasi tugas terlebih dahulu, lalu tentukan sistem yang akan dihubungkan

Mulailah dari proses bisnis, bukan istilah teknis. Catat tugas yang perlu ditangani, sistem yang terlibat, data masukan dan keluaran, langkah yang saat ini dilakukan manusia, konsekuensi kegagalan, serta tindakan yang harus disetujui karyawan. Kemudian pilih skenario pertama berdasarkan nilai bisnis, sensitivitas data, kematangan antarmuka, dampak kegagalan, dan kebutuhan persetujuan.

Sebagai contoh, evaluasi terlebih dahulu “pengarahan tiket layanan pelanggan”: Agent membaca tiket baru dan pengetahuan internal, lalu mengusulkan kategori serta kelompok penanggung jawab; lapisan alat memvalidasi nomor tiket, nilai kategori, dan keabsahan kelompok; untuk skenario berisiko rendah, Agent pada awalnya hanya menghasilkan rekomendasi, kemudian agen layanan pelanggan mengonfirmasi sebelum tiket diperbarui. Contoh ini tidak mengasumsikan kemampuan sistem tertentu; sebelum diterapkan, antarmuka dan izin aktual tetap harus diperiksa.

Memilih antara API, Webhook, pemanggilan fungsi, dan RPA

API cocok untuk kueri dan operasi bisnis yang jelas. Lapisan alat dapat membungkus antarmuka sistem menjadi tindakan yang sempit dan mudah dipahami, seperti “memeriksa status tiket”, sehingga tidak perlu membuka kemampuan kueri umum yang terlalu luas. Periksa metode autentikasi, definisi bidang, respons kesalahan, dan lingkungan pengujian.

Pemanggilan fungsi adalah cara interaksi ketika model memilih dan mengisi parameter alat yang telah ditentukan, bukan antarmuka baru untuk sistem perusahaan. Pemanggilan ini harus dipadukan dengan validasi sisi server: parameter tidak boleh dianggap tepercaya atau tindakan dianggap telah disetujui hanya karena model memberikan parameter tersebut. Dokumentasi pemanggilan fungsi OpenAI menjelaskan bahwa setelah model memberikan permintaan pemanggilan alat, aplikasi perlu menjalankan kode yang sesuai dan mengembalikan hasilnya ke dalam alur percakapan.

Webhook cocok untuk memicu proses lanjutan berdasarkan peristiwa bisnis, misalnya ketika sistem menghasilkan tugas yang perlu ditangani dan memberi tahu layanan integrasi. Pengiriman peristiwa harus mempertimbangkan duplikasi, keterlambatan, urutan, dan percobaan ulang setelah kegagalan; semantik aktual bergantung pada sistem yang terhubung. Dokumentasi Webhook GitHub menjelaskan penanganan seperti kegagalan pengiriman dan pengiriman ulang, sehingga dapat digunakan sebagai contoh untuk memeriksa perilaku platform tertentu, bukan sebagai jaminan umum untuk semua layanan.

RPA dapat menjadi opsi transisi ketika tidak tersedia antarmuka yang dapat digunakan, dengan mengoperasikan sistem lama melalui antarmuka pengguna. Namun, perubahan antarmuka, status login, dan jendela pop-up yang tidak terduga dapat memengaruhi proses. Karena itu, stabilitas, pemantauan operasional, dan biaya pemeliharaan harus dievaluasi, serta mekanisme verifikasi perlu dipertahankan untuk penulisan data yang kritis. Penjelasan UiPath tentang pemilih dan pengenalan elemen antarmuka menunjukkan bahwa penentuan lokasi antarmuka itu sendiri perlu diverifikasi dan dipelihara dalam aplikasi target.

Orkestrasi lapisan perantara cocok untuk skenario yang memerlukan koneksi ke beberapa sistem serta penyatuan identitas dan aturan. Lapisan ini dapat menangani konversi, validasi, dan audit secara terpusat, tetapi juga menambah tanggung jawab terkait komponen dan operasional. Saat memilih, yang perlu dibandingkan bukan hanya kecepatan integrasi, tetapi juga pelacakan sumber masalah, isolasi hak akses, dan pemeliharaan jangka panjang.

Arsitektur yang direkomendasikan: pisahkan perencanaan, eksekusi, dan tata kelola

1. Lapisan Agen: memahami permintaan, menyusun konteks, dan mengusulkan rencana pemanggilan alat; tidak menyimpan kredensial basis data.
2. Lapisan alat: menetapkan tujuan, tipe parameter, kolom wajib, rentang yang diizinkan, dan struktur hasil untuk setiap tindakan; validasi dilakukan kembali di sisi server.
3. Lapisan integrasi: menghubungkan sistem ERP, CRM, OA, dan sistem lainnya, serta menangani autentikasi, adaptasi protokol, batas waktu, dan pemetaan kesalahan.
4. Lapisan hak akses dan persetujuan: mengaitkan identitas karyawan, identitas layanan, dan hak akses tindakan; konfirmasi diperlukan untuk operasi yang berdampak besar.
5. Lapisan log dan evaluasi: mencatat pihak yang melakukan pemanggilan, alat, ringkasan permintaan yang diperlukan, hasil, dan pengecualian, serta mendukung peninjauan dan pengumpulan metrik.

Batasnya harus jelas: model bertanggung jawab untuk “mengusulkan apa yang perlu dilakukan”, layanan alat bertanggung jawab untuk “menentukan apakah tindakan diizinkan dan apakah parameter valid”, sedangkan sistem bisnis bertanggung jawab untuk “menentukan status akhirnya”. Jangan biarkan model melewati lapisan alat dan langsung memegang akun basis data produksi. Pemisahan lapisan merupakan rekomendasi desain implementasi; batas komponen yang sebenarnya harus ditentukan berdasarkan kemampuan sistem dan persyaratan pengendalian organisasi. Lihat Penjelasan tentang identitas kerja agen Gemini tingkat perusahaan untuk memahami peran identitas dan hak akses dalam agen perusahaan; halaman tersebut merupakan pengenalan produk dan tidak menggantikan evaluasi arsitektur lokal.

Dari uji coba hingga peluncuran: perluas secara bertahap berdasarkan risiko

Langkah pertama, pilih skenario yang terbatas. Tentukan kondisi pemicu, definisi selesai, dan penanganan kegagalan dengan jelas. Jangan menggantikan tujuan bisnis dengan sekadar “berhasil terhubung ke sistem”.

Langkah kedua, tulis kontrak alat. Jelaskan tujuan, parameter, hak akses, potensi efek samping, jenis kesalahan, dan cara memverifikasi hasil untuk setiap alat. Utamakan pemisahan menjadi satu tindakan, dan hindari satu alat yang sekaligus melakukan kueri, perubahan, dan penghapusan.

Langkah ketiga, hubungkan ke lingkungan pengujian terlebih dahulu. Lakukan pengujian dengan input yang representatif, nilai batas, kolom yang hilang, dan respons yang tidak terduga. Periksa apakah Agen akan meminta informasi tambahan ketika data tidak mencukupi, bukan menebak parameter.

Langkah keempat, lakukan peluncuran bertahap setelah perlindungan diterapkan. Mulailah dengan mode hanya baca atau mode rekomendasi, lalu buka akses untuk penulisan berisiko rendah yang telah disetujui. Tetapkan batas panggilan, batas waktu, dan peringatan; aturan tentang kapan harus berhenti, mencoba lagi, atau menyerahkan proses kepada manusia saat terjadi kegagalan harus jelas.

Langkah kelima, lakukan evaluasi sebelum memperluas cakupan. Catat kesalahan klasifikasi, parameter yang tidak valid, panggilan berulang, dan alasan pengambilalihan oleh manusia. Perluasan cakupan tindakan hanya dipertimbangkan jika hasil dapat diverifikasi, batas kewenangan jelas, dan tersedia jalur penanganan untuk kondisi abnormal.

Sebagai contoh, untuk pengalihan tiket, penerapan dapat dilakukan secara bertahap: pertama, membaca tiket dan memberikan saran klasifikasi; kemudian, menulis klasifikasi setelah dikonfirmasi oleh karyawan; terakhir, mengevaluasi apakah tiket dengan aturan yang jelas dan dapat dibatalkan dapat ditugaskan secara otomatis. Tetapkan kondisi penghentian pada setiap tahap. Jika kesalahan penugasan meningkat atau proses tidak dapat diaudit, kembalikan proses ke konfirmasi manusia. Jika perlu mengevaluasi risiko agent melampaui kewenangannya, lihat pembahasan tentang insiden keamanan agent di situs ini, dan jadikan pengujian pada sistem nyata sebagai acuan utama.

Keamanan dan tata kelola: terapkan pengendalian dalam bentuk daftar pemeriksaan

• Hak akses minimum dan identitas terpisah: Berikan identitas layanan Agent hanya akses ke sistem dan tindakan yang diperlukan untuk menyelesaikan tugas; sebelum peluncuran, periksa apakah kredensial bersifat khusus, dapat dirotasi, dan tidak memiliki hak tulis yang tidak relevan.
• Pengendalian bidang sensitif: Berikan model hanya informasi yang diperlukan untuk menyelesaikan tugas; periksa setiap bidang dalam input, output, dan log, serta verifikasi bahwa aturan penyamaran data telah diterapkan dengan benar.
• Perlindungan terhadap injeksi prompt dan akses melampaui kewenangan: Perlakukan teks eksternal seperti email, tiket, dan halaman web sebagai data, bukan instruksi yang memberikan kewenangan. Gunakan konten pengujian yang berisi upaya mendorong panggilan tambahan atau ekspor data untuk memastikan aturan hak akses tetap menolak permintaan atau meminta konfirmasi. Materi keamanan aplikasi LLM dari OWASP mencantumkan injeksi prompt sebagai kategori risiko yang perlu diperhatikan.
• Perlindungan penulisan: Untuk perubahan pada sistem produksi, terapkan validasi parameter, pratinjau dampak, persetujuan, dan pembacaan ulang hasil; verifikasi bahwa konten yang disetujui sesuai dengan konten yang benar-benar dikirim.
• Idempotensi dan penanganan kondisi abnormal: Untuk tindakan yang mungkin dikirim berulang kali, rancang kunci deduplikasi atau pemeriksaan status; uji batas waktu, percobaan ulang, dan keberhasilan sebagian secara terpisah untuk memastikan status aktual sistem dapat ditentukan setelah kegagalan.
• Audit dan akuntabilitas: Catat identitas, tindakan, waktu, hasil, dan informasi persetujuan yang diperlukan, serta batasi akses ke log; lakukan pemeriksaan sampel untuk memastikan suatu perubahan bisnis dapat ditelusuri hingga panggilan dan dasar kewenangannya.

Hak akses minimum, pemberian kewenangan, dan kemampuan audit juga dapat dibandingkan dengan materi OWASP tentang ancaman dan mitigasi Agentic AI, lalu diterapkan bersama pengelolaan identitas dan kebijakan audit organisasi; materi tersebut tidak menggantikan penilaian keamanan terhadap sistem tertentu.

Cara mengukur efektivitas integrasi

Jangan hanya menilai apakah respons terdengar lancar. Dari sisi teknis, amati tingkat penyelesaian tugas, tingkat kegagalan validasi parameter, tingkat kesalahan panggilan, latensi respons, eksekusi berulang, dan tingkat pengambilalihan oleh manusia; dari sisi operasional, amati waktu pemrosesan, perubahan jumlah pekerjaan tertunda, beban kerja peninjauan, dan biaya panggilan per tugas. Definisi setiap metrik harus ditetapkan terlebih dahulu. Misalnya, apakah “selesai” berarti alat mengembalikan status berhasil, atau status sistem bisnis telah dikonfirmasi melalui pembacaan ulang?

Catat baseline proses yang ada sebelum uji coba, lalu bandingkan dengan cakupan tugas yang sama setelahnya, sambil membedakan kesalahan penilaian model, kegagalan antarmuka, dan perubahan aturan bisnis. Jika otomatisasi meningkatkan beban peninjauan manusia, tingkat keberhasilan panggilan yang baik tetap tidak cukup untuk menyimpulkan adanya perbaikan. Jangan menetapkan persentase manfaat terlebih dahulu; gunakan data operasional aktual perusahaan untuk menentukan apakah cakupan perlu diperluas.

FAQ

Sistem lama tidak memiliki API, apakah Agent tetap dapat diintegrasikan? Dapat dipertimbangkan penggunaan lapisan perantara yang terkontrol, platform integrasi yang sudah ada, atau RPA, tetapi pastikan terlebih dahulu stabilitas operasi, observabilitas, dan tanggung jawab pemeliharaan. Jika alurnya melibatkan penulisan berisiko tinggi, sebaiknya tetap ada konfirmasi manusia; otomatisasi antarmuka jangan dianggap setara dengan API yang stabil.

Apakah integrasi Agent mengharuskan sistem yang ada dimodifikasi? Tidak selalu. Jika sistem sudah memiliki API atau mekanisme peristiwa yang dapat digunakan, biasanya lapisan alat dan hak akses dapat dibangun di luar sistem terlebih dahulu; jika antarmukanya belum memadai, evaluasi penambahan API hanya-baca, adaptor integrasi, atau modifikasi terbatas sesuai tugas tertentu. Validasi skenario sebaiknya dimulai dengan perubahan minimum yang diperlukan.

Bagaimana mencegah Agent melakukan kesalahan atau melampaui wewenang? Batasi tujuan, parameter, dan objek yang dapat diakses untuk setiap alat, serta gunakan identitas layanan terpisah dengan hak akses minimum; tetapkan persetujuan atau konfirmasi sebelum penulisan ke sistem produksi, dan catat pihak yang melakukan pemanggilan, input, hasil, serta anomali. Uji juga skenario ketika instruksi berbahaya atau konten tidak tepercaya mendorong alat untuk dipanggil.

Tugas apa yang tidak cocok untuk langsung dijalankan secara otomatis? Tugas dengan konsekuensi yang sulit dibatalkan, aturan yang tidak jelas, ketergantungan pada banyak penilaian tersirat, atau tidak adanya metode verifikasi yang andal tidak cocok dijadikan tahap awal tanpa pengawasan. Agent dapat terlebih dahulu menghasilkan rekomendasi untuk ditinjau karyawan, lalu cakupan otomatisasi diperluas berdasarkan jenis kesalahan dan risiko bisnis.

Penutup: Mulai dari tindakan kecil yang dapat diverifikasi

Kunci integrasi AI Agent dengan sistem perusahaan yang ada adalah menetapkan batas kemampuan yang jelas: model menyusun rencana, alat yang terkontrol memvalidasi dan menjalankannya, mekanisme hak akses serta audit membatasi risiko, dan sistem bisnis mengonfirmasi hasil akhir. Memulai dari skenario berisiko rendah yang dapat diverifikasi, seperti akses hanya-baca atau pemberian rekomendasi, lalu secara bertahap memperkenalkan operasi tulis dengan persetujuan, membantu tim menemukan masalah antarmuka, hak akses, dan tata kelola dalam alur nyata, alih-alih langsung menyerahkan tindakan berisiko tinggi kepada otomatisasi.