← Blog · Engineering · 10 min read
Kapabilitas AI tidak hidup di ruang hampa; ia harus berbicara dengan sistem lama Anda. Artikel ini memetakan pola integrasi LLM ke lanskap legacy enterprise.
A 30-minute scoping call. We listen, ask three questions, tell you if we can help.
Book a callDemo LLM selalu terlihat mulus karena ia hidup di ruang hampa. Ada prompt, ada respons, semua bersih. Tetapi nilai bisnis sebenarnya tidak lahir dari LLM yang menjawab pertanyaan di playground — ia lahir ketika LLM bisa membaca data nasabah dari core banking yang dibangun dua dekade lalu, mengambil status klaim dari sistem AS/400, atau menulis kembali catatan ke ERP yang antarmukanya hanya SOAP. Di sinilah banyak proyek AI enterprise tersandung. Kapabilitas AI yang menjanjikan harus berbicara dengan lanskap sistem legacy yang rumit, rapuh, dan sering kali tanpa dokumentasi.
Bagi enterprise Indonesia — bank dengan core banking lama, BUMN dengan sistem warisan puluhan tahun, perusahaan asuransi dengan mainframe — integrasi adalah medan tempur yang sebenarnya. Bukan kualitas model yang menjadi penghambat, melainkan bagaimana menyambungkannya ke sistem yang tidak pernah dirancang untuk era AI. Artikel ini memetakan pola-pola integrasi yang terbukti, dari API gateway hingga anti-corruption layer, beserta pertimbangan keamanan dan strategi migrasi bertahap yang menjaga risiko tetap terkendali.
Sebelum membahas solusi, pahami mengapa sistem legacy menjadi tantangan khusus bagi integrasi LLM.
Sistem legacy sering tidak punya API modern. Antarmukanya mungkin berupa SOAP, file batch yang dipertukarkan tengah malam, koneksi database langsung, atau bahkan layar terminal yang harus di-scrape. Skema datanya idiosinkratik, dibentuk oleh keputusan bisnis lama yang tidak lagi ada yang ingat alasannya. Dokumentasinya tipis atau usang. Dan yang paling menakutkan: sistem ini sering kali menjalankan operasi inti yang tidak boleh terganggu sama sekali — satu kesalahan integrasi bisa menghentikan transaksi perbankan atau pemrosesan klaim.
Tantangan terbesar mengintegrasikan AI ke enterprise bukanlah membuat model lebih pintar, melainkan membuatnya berbicara dengan sistem yang dibangun ketika smartphone belum ada — tanpa meruntuhkan apa pun.
Ditambah lagi, LLM punya karakteristik yang asing bagi sistem legacy: ia non-deterministik, bisa berhalusinasi, latensinya bervariasi, dan outputnya berupa teks bebas yang harus divalidasi sebelum disentuhkan ke sistem transaksional. Menjembatani dua dunia ini — yang deterministik dan yang probabilistik — adalah inti pekerjaan integrasi.
Prinsip arsitektur pertama: jangan pernah menyambungkan LLM langsung ke sistem legacy. Selalu sisipkan lapisan perantara.
API gateway menjadi titik masuk tunggal yang mengelola autentikasi, rate limiting, logging, dan routing. Semua permintaan dari aplikasi AI melewati gateway, yang memberi Anda satu tempat untuk menegakkan kebijakan keamanan, memantau penggunaan, dan mengisolasi sistem belakang dari perubahan.
Di belakang gateway, bangun lapisan layanan (service layer) yang membungkus sistem legacy dengan API modern. Jika core banking hanya bicara SOAP, buat layanan REST atau gRPC yang menerjemahkannya. Aplikasi AI berbicara dengan layanan modern ini, tidak pernah menyentuh sistem lama secara langsung. Keuntungannya berlipat: Anda bisa mengganti atau memodernisasi sistem belakang tanpa menyentuh logika AI, dan sebaliknya.
Pola ini juga memungkinkan tool use yang aman. Ketika LLM atau agent perlu mengambil data atau melakukan aksi, ia memanggil tool yang terdefinisi rapi — masing-masing dengan skema input/output yang ketat, validasi, dan otorisasi — bukan mengeksekusi kueri mentah ke sistem produksi. Setiap tool menjadi gerbang terkontrol antara dunia probabilistik LLM dan dunia deterministik sistem bisnis.
Konsep dari domain-driven design ini sangat relevan untuk integrasi AI: anti-corruption layer (ACL). Idenya adalah lapisan penerjemah yang memetakan model data legacy yang berantakan menjadi model bersih yang dipahami sistem AI Anda — dan mencegah keanehan sistem lama "merembes" ke seluruh arsitektur baru Anda.
Sistem legacy sering punya kode kriptik (status "07" berarti "klaim ditangguhkan menunggu dokumen"), field yang dipakai ulang untuk dua tujuan berbeda, dan konvensi penamaan yang membingungkan. Tanpa ACL, kekacauan ini menyebar ke prompt, ke logika aplikasi, dan ke setiap tempat yang menyentuh data tersebut.
ACL melakukan beberapa hal penting:
Menerjemahkan kode dan enum legacy menjadi label yang bermakna sebelum diserahkan ke LLM, sehingga model bekerja dengan "klaim ditangguhkan" bukan "07".
Menormalkan format: tanggal, mata uang Rupiah, nomor identitas, sehingga konsisten.
Menyaring dan membatasi data yang keluar — memastikan field sensitif tidak pernah ikut terkirim ke model jika tidak diperlukan.
Memvalidasi data yang masuk kembali ke legacy, sehingga output LLM yang mungkin keliru tidak pernah langsung menulis ke sistem inti tanpa pemeriksaan.
ACL adalah tempat strategis untuk menegakkan kepatuhan UU PDP No. 27/2022: di sinilah Anda memutuskan data pribadi mana yang boleh atau tidak boleh keluar ke layanan AI, dan di sinilah Anda menerapkan masking serta minimisasi data.
Tidak semua integrasi perlu real-time dan sinkron. Untuk banyak kasus, arsitektur berbasis event memberi keandalan dan kelonggaran yang lebih baik.
Alih-alih aplikasi AI memanggil sistem legacy dan menunggu, sistem berkomunikasi lewat antrian pesan atau event stream. Ketika sebuah peristiwa terjadi di sistem legacy — klaim baru masuk, transaksi tercatat — ia memublikasikan event. Layanan AI berlangganan event itu, memprosesnya secara asinkron, dan memublikasikan hasilnya kembali.
Keuntungan pola ini signifikan untuk enterprise:
Decoupling: sistem legacy tidak perlu tahu apa pun tentang AI; ia hanya memublikasikan event seperti biasa.
Ketahanan: jika layanan AI sedang down atau lambat (latensi LLM bisa fluktuatif), event menumpuk di antrian dan diproses ketika layanan pulih, alih-alih menghentikan operasi inti.
Skalabilitas: beban diproses sesuai kapasitas, bukan memaksa sistem legacy menunggu respons LLM yang lambat.
Pola ini sangat cocok untuk kasus seperti pemrosesan dokumen, pengayaan data, atau analisis yang tidak harus terjadi dalam milidetik. Untuk interaksi yang benar-benar butuh respons langsung (copilot agen yang menjawab pertanyaan), gunakan pola sinkron lewat gateway — pilih sesuai kebutuhan, jangan dogmatis.
Mengintegrasikan LLM membuka permukaan serangan yang asing bagi tim keamanan enterprise. Beberapa prinsip non-negosiabel.
Least privilege secara ketat. Tool dan layanan yang dipanggil AI hanya boleh punya akses minimum yang diperlukan. Jika sebuah agent hanya perlu membaca status klaim, ia tidak boleh punya kemampuan mengubah data nasabah. Identitas dan otorisasi harus mengalir hingga ke setiap pemanggilan tool, bukan satu kredensial sakti yang bisa segalanya.
Validasi output sebelum aksi. Output LLM tidak boleh dipercaya buta. Sebelum hasil model menulis ke sistem transaksional, validasi terhadap skema, aturan bisnis, dan batas wajar. Untuk aksi berisiko tinggi — transfer dana, persetujuan kredit — sisipkan human-in-the-loop yang menyetujui sebelum eksekusi.
Waspadai prompt injection. Jika LLM membaca data dari sistem legacy (misalnya catatan yang dibuat pengguna), data itu bisa berisi instruksi jahat yang membajak perilaku model. Perlakukan semua data eksternal sebagai tidak tepercaya dan pisahkan dengan jelas antara instruksi sistem dan konten data.
Audit trail menyeluruh. Setiap interaksi — prompt, konteks yang diambil, tool yang dipanggil, output, dan aksi — harus tercatat. Ini wajib untuk kepatuhan (regulator OJK akan menanyakannya untuk sektor keuangan), untuk debugging, dan untuk investigasi insiden.
Godaan terbesar dalam proyek integrasi adalah "big bang" — mengganti banyak hal sekaligus. Untuk lanskap legacy enterprise, ini resep bencana. Pendekatan bertahap jauh lebih bijak.
Mulai dengan use case berisiko rendah dan bernilai jelas yang hanya membaca, tidak menulis, ke sistem inti. Misalnya copilot internal yang membantu staf mencari informasi dari beberapa sistem, tanpa kewenangan mengubah apa pun. Ini membuktikan integrasi, membangun kepercayaan, dan mengasah arsitektur sebelum taruhannya tinggi.
Terapkan strangler fig pattern: alih-alih mengganti sistem legacy sekaligus, bungkus fungsionalitasnya dengan lapisan baru dan secara bertahap arahkan lebih banyak alur lewat lapisan modern, hingga sistem lama akhirnya bisa dipensiunkan tanpa pernah ada momen pemadaman besar.
Gunakan teknik shadow mode sebelum go-live: jalankan integrasi AI secara paralel dengan proses lama tanpa memengaruhi produksi, bandingkan hasilnya, dan baru beralih setelah yakin. Untuk aksi yang menulis ke sistem inti, tingkatkan kewenangan AI secara bertahap — dari menyarankan, ke menyiapkan untuk persetujuan manusia, hingga (jika risiko membenarkan) eksekusi otomatis dengan pengawasan.
Selalu sediakan jalan mundur (rollback) dan kill switch. Jika integrasi berperilaku tidak terduga, harus ada cara cepat dan bersih mematikannya tanpa meruntuhkan operasi.
Integrasi LLM ke legacy bukan semata masalah rekayasa. Sistem legacy biasanya "dijaga" oleh tim yang memahami kerentanannya dan wajar bersikap protektif. Libatkan mereka sejak awal — mereka tahu di mana ranjau tersembunyi. Pemilik sistem core banking yang merasa diabaikan bisa, dengan alasan yang sah, memblokir proyek integrasi.
Tetapkan kepemilikan yang jelas atas setiap lapisan: siapa yang bertanggung jawab atas gateway, atas ACL, atas tiap tool. Sepakati SLA dan prosedur insiden lintas tim. Dan kelola ekspektasi: integrasi ke legacy hampir selalu memakan waktu lebih lama daripada perkiraan optimistis, karena penemuan masalah tak terduga adalah aturan, bukan pengecualian.
Salah satu aspek paling membingungkan bagi tim engineering yang terbiasa dengan sistem deterministik adalah sifat probabilistik LLM. Sistem legacy mengembalikan jawaban yang sama untuk input yang sama, setiap kali. LLM tidak. Menjembatani perbedaan fundamental ini membutuhkan pola desain khusus.
Structured output yang ditegakkan. Jangan biarkan LLM mengembalikan teks bebas yang lalu di-parse dengan harapan. Paksa output dalam skema terstruktur (JSON dengan field yang ditentukan), validasi terhadap skema, dan tolak atau ulangi jika tidak sesuai. Ini mengubah keluaran yang tidak dapat diprediksi menjadi sesuatu yang bisa diandalkan sistem hilir.
Retry dan fallback yang elegan. Karena LLM kadang gagal atau memberi hasil di luar batas wajar, rancang mekanisme percobaan ulang dengan prompt yang disesuaikan, dan fallback ke jalur deterministik (aturan klasik atau eskalasi ke manusia) ketika AI tidak memberi hasil yang dapat dipercaya. Sistem tidak boleh runtuh hanya karena satu pemanggilan LLM meleset.
Idempotensi pada aksi. Karena percobaan ulang mungkin terjadi, pastikan aksi yang menulis ke sistem legacy bersifat idempoten — menjalankannya dua kali tidak menghasilkan transaksi ganda. Ini krusial di perbankan, di mana pemanggilan berulang yang tidak terkendali bisa menyebabkan pendebetan ganda.
Manajemen latensi. Respons LLM bisa memakan beberapa detik, jauh lebih lambat dari panggilan database biasa. Untuk antarmuka yang dipakai langsung oleh staf, gunakan streaming agar respons terasa cepat, dan untuk proses batch, manfaatkan pola asinkron agar latensi tidak menghambat alur lain.
Integrasi yang berhasil secara teknis masih bisa gagal secara ekonomi jika biaya tidak dikelola. Setiap pemanggilan LLM punya biaya, dan di enterprise dengan volume transaksi tinggi, biaya ini bisa membengkak cepat.
Beberapa strategi menjaga biaya tetap terkendali sambil melayani skala enterprise. Caching adalah yang pertama: banyak pertanyaan dan konteks berulang, dan menyimpan hasil untuk input yang identik atau mirip secara semantik memangkas biaya signifikan. Routing model adalah yang kedua: gunakan model yang lebih kecil dan murah untuk tugas sederhana, sisakan model besar untuk kasus yang benar-benar menuntutnya. Dan kompresi konteks adalah yang ketiga: mengirim hanya potongan informasi yang relevan ke model, bukan seluruh dokumen, mengurangi token sekaligus meningkatkan kualitas jawaban.
Penting juga menetapkan batas anggaran yang keras dan observability biaya per use case. Tanpa pemantauan, tagihan LLM bisa naik diam-diam hingga mengejutkan tim finance di akhir bulan. Perlakukan biaya token seperti metrik produksi penting lainnya — pantau, beri alert, dan optimalkan secara berkelanjutan.
Nilai sebenarnya dari AI di enterprise tidak terkunci oleh kualitas model, melainkan oleh seberapa rapi ia terintegrasi ke sistem yang sudah menjalankan bisnis Anda. Membangun jembatan yang benar — dengan gateway, anti-corruption layer, keamanan yang ketat, dan migrasi bertahap yang menjaga operasi inti tetap aman — adalah pekerjaan yang membedakan demo yang mengesankan dari sistem yang benar-benar dipakai setiap hari.
Sainskerta Solusi Nusantara berpengalaman mengintegrasikan kapabilitas AI ke lanskap sistem enterprise Indonesia yang kompleks, dari core banking hingga ERP dan mainframe warisan, dengan mengedepankan keamanan, audit trail, dan kepatuhan OJK serta UU PDP. Kami mendampingi dari fase strategi hingga operasi. Jika tim Anda menghadapi tembok integrasi antara ambisi AI dan realitas sistem legacy, hubungi tim kami lewat halaman Kontak untuk menjadwalkan sesi diskusi arsitektur. Kami akan membantu memetakan jalur integrasi yang aman, bertahap, dan dapat dieksekusi — tanpa mempertaruhkan sistem yang menjadi tulang punggung operasi Anda.
