AI Technical Debt: Saat Sistem Lama Menghambat Adopsi AI

Banyak perusahaan ingin menambahkan artificial intelligence ke dalam sistem yang sudah berjalan.

Chatbot dipasang pada portal internal. AI assistant dihubungkan dengan dokumen perusahaan. Model forecasting mengambil data transaksi. AI agent mulai diarahkan untuk memeriksa permintaan, membuat rekomendasi, atau menjalankan workflow tertentu.

Pada tahap demo, solusi tersebut dapat terlihat menjanjikan.

Masalah biasanya muncul ketika AI harus digunakan pada proses bisnis sebenarnya.

Data pelanggan tersebar di beberapa aplikasi. Sistem lama tidak memiliki API yang stabil. Hak akses hanya diatur pada level aplikasi, bukan pada data. Business rule tersimpan di dalam kode yang tidak terdokumentasi. Perubahan kecil membutuhkan koordinasi dengan banyak vendor.

Dalam kondisi ini, AI bukan menghapus masalah sistem lama.

AI justru dapat memperluas dampaknya.

Kondisi tersebut dapat disebut sebagai AI technical debt: akumulasi biaya, risiko, dan kompleksitas yang muncul ketika AI dibangun di atas data, integrasi, arsitektur, serta proses yang belum cukup siap.

Google sejak lama mengingatkan bahwa sistem machine learning dapat menciptakan technical debt pada level sistem, bukan hanya pada kode model. Risiko dapat muncul dari data dependency, hidden feedback loop, perubahan kondisi eksternal, dan hubungan antarkomponen yang sulit dipahami. (Google Research)

Apa Itu AI Technical Debt?

Technical debt adalah konsekuensi jangka panjang dari keputusan teknis yang mempercepat delivery hari ini, tetapi membuat perubahan dan pemeliharaan pada masa depan menjadi lebih mahal.

Dalam implementasi AI, technical debt dapat berasal dari dua sumber.

Inherited technical debt

Utang teknis yang sudah ada sebelum AI diterapkan, seperti:

• Legacy system yang sulit dimodifikasi.
• Integrasi point-to-point.
• Data duplikat.
• Dokumentasi tidak lengkap.
• Dependency usang.
• Business rule yang tersembunyi.
• Hak akses yang terlalu luas.
• Proses deployment manual.

AI-generated technical debt

Utang baru yang muncul setelah AI ditambahkan, seperti:

• Ketergantungan pada satu model atau provider.
• Prompt yang tersebar di dalam kode.
• Dataset evaluasi tidak terdokumentasi.
• Output AI tidak memiliki audit trail.
• Biaya token tidak dipantau.
• Tidak tersedia fallback saat model gagal.
• Banyak proof of concept tanpa ownership.
• Agent memiliki akses berlebihan.

Perusahaan perlu mengelola keduanya. Memperbaiki model tanpa memperbaiki sistem yang mendukungnya hanya akan memindahkan masalah.

Bagaimana Sistem Lama Menghambat AI?

1. Data Tersedia, tetapi Tidak Dapat Dipercaya

AI membutuhkan data yang akurat, aktual, dan memiliki konteks.

Namun, banyak sistem enterprise menyimpan informasi yang sama dalam beberapa aplikasi. Data pelanggan dapat berbeda antara CRM, finance, dan sistem operasional. Status transaksi diperbarui pada satu aplikasi tetapi terlambat masuk ke aplikasi lain.

Ketika AI mengakses data tersebut, hasilnya dapat berubah tergantung sumber yang digunakan.

Masalah ini tidak selalu dapat diselesaikan dengan data cleansing sekali di awal. Perusahaan perlu menentukan:

• Sistem yang menjadi source of truth.
• Pemilik setiap domain data.
• Frekuensi pembaruan.
• Aturan validasi.
• Cara menangani duplikasi.
• Hak akses terhadap data.
• Mekanisme monitoring kualitas.

Artikel AI-Ready System membahas bagaimana data, integrasi, keamanan, dan observability menjadi fondasi sebelum AI digunakan dalam proses bisnis.

2. AI Terhubung Melalui Integrasi Sementara

Karena sistem lama tidak memiliki API, tim dapat menggunakan ekspor spreadsheet, akses database langsung, robotic process automation, atau script khusus.

Pendekatan tersebut mungkin cukup untuk pilot, tetapi menjadi rapuh ketika volume dan jumlah use case meningkat.

Perubahan struktur tabel dapat memutus integrasi. Credential tersimpan pada script. Error sulit dilacak. Data dipindahkan tanpa aturan retry yang jelas.

AI akhirnya berdiri di atas sekumpulan workaround.

Pendekatan API-first architecture dapat membantu memisahkan kemampuan bisnis dari struktur internal aplikasi. Namun, tidak semua sistem harus langsung dibangun ulang. API wrapper atau middleware masih dapat digunakan ketika fungsi inti sistem lama tetap stabil.

3. Business Rule Tidak Terdokumentasi

Sistem lama sering menyimpan pengetahuan operasional di dalam kode.

Contohnya:

• Cara menghitung diskon pelanggan tertentu.
• Urutan approval berdasarkan nilai transaksi.
• Pengecualian untuk cabang atau produk tertentu.
• Aturan pembatalan pesanan.
• Penentuan batas kredit.
• Cara menangani transaksi historis.

Ketika AI diminta memberikan rekomendasi atau menjalankan workflow, aturan tersebut perlu dipahami.

Jika dokumentasinya tidak tersedia, tim dapat membuat logika baru yang berbeda dari proses sebenarnya. AI kemudian memberikan keputusan yang terlihat masuk akal, tetapi tidak sesuai kebijakan bisnis.

Modernisasi sebaiknya tidak hanya memindahkan kode. Tim juga perlu mengekstrak dan memvalidasi business rule bersama pemilik proses.

4. Hak Akses Tidak Mengikuti AI

Aplikasi lama mungkin hanya mengenali bahwa pengguna berhasil login.

Ketika AI assistant menggabungkan informasi dari beberapa sistem, model perlu mengetahui data apa yang boleh dilihat oleh setiap pengguna.

Tanpa kontrol yang tepat, AI dapat menampilkan:

• Informasi gaji.
• Data pelanggan.
• Kontrak.
• Margin produk.
• Dokumen legal.
• Informasi divisi lain.
• Data yang sudah tidak berlaku.

NIST AI Risk Management Framework menempatkan governance sebagai kebutuhan yang harus diterapkan sepanjang lifecycle AI, bukan hanya pemeriksaan setelah deployment. Organisasi perlu memetakan risiko, mengukur dampak, dan mengelola kontrol berdasarkan konteks penggunaan.

AI sebaiknya memiliki identitas, permission, dan batas akses yang dapat diaudit—bukan menggunakan akun administrator umum.

5. Sistem Tidak Memiliki Observability

Ketika aplikasi biasa gagal, tim dapat melihat error pada fungsi tertentu.

AI menambah lapisan baru:

• Data apa yang digunakan?
• Prompt apa yang dijalankan?
• Model mana yang dipilih?
• Tools apa yang dipanggil?
• Mengapa suatu tindakan dijalankan?
• Berapa biaya proses tersebut?
• Apakah manusia mengubah hasilnya?

Jika sistem lama tidak memiliki logging, tracing, dan monitoring yang cukup, AI akan menambah area yang tidak terlihat.

Masalah baru diketahui setelah pengguna menerima jawaban salah, workflow berhenti, atau biaya penggunaan meningkat.

6. Seluruh Sistem Terikat pada Satu Provider

AI sering diintegrasikan langsung menggunakan SDK satu provider.

Business logic, prompt, model, dan workflow kemudian bercampur dalam satu aplikasi. Ketika perusahaan ingin mengganti model, menggunakan model yang lebih murah, atau menambahkan fallback, perubahan menjadi luas.

Ini merupakan bentuk baru vendor lock-in.

Arsitektur yang lebih adaptif memisahkan:

• Business workflow.
• Model interface.
• Prompt management.
• Data retrieval.
• Tools dan integrations.
• Validation.
• Human approval.
• Logging dan evaluation.

Tujuannya bukan agar perusahaan selalu mengganti model, tetapi agar keputusan model tidak mengunci seluruh sistem.

AI Dapat Memperbesar Cost of Change

Pada sistem tradisional, technical debt membuat satu fitur lebih lama dikembangkan.

Dalam sistem berbasis AI, dampaknya dapat menjangkau lebih banyak lapisan.

Perubahan field pada ERP dapat memengaruhi data pipeline, retrieval, prompt, model evaluation, dashboard, dan agent workflow. Perubahan permission dapat memengaruhi jawaban yang tersedia bagi pengguna. Dokumen baru dapat mengubah kualitas rekomendasi.

Technical debt membuat tim sulit memprediksi dampak perubahan.

Hubungan tersebut juga dibahas dalam artikel Technical Debt: Mengapa Kode Buruk Menggerogoti Profit?: semakin banyak dependency yang tidak terlihat, semakin mahal dan berisiko setiap perubahan.

AI tidak selalu menciptakan masalah baru. Namun, AI dapat membuat dependency lama bekerja dengan kecepatan dan skala yang lebih besar.

Haruskah Sistem Lama Dibangun Ulang?

Tidak selalu.

Modernisasi sistem memiliki beberapa pilihan. Google Cloud dan Microsoft menggambarkan modernisasi sebagai spektrum yang dapat mencakup rehosting, replatforming, refactoring, rearchitecting, atau penggantian aplikasi berdasarkan kondisi dan tujuan bisnis. Tidak ada satu pendekatan yang tepat untuk seluruh sistem.

Gunakan API wrapper ketika:

• Sistem inti masih stabil.
• Business rule masih relevan.
• Kebutuhan AI hanya membaca fungsi tertentu.
• Perubahan pada sistem inti terlalu berisiko.
• Volume dan latency masih dapat diterima.

Lakukan refactoring ketika:

• Kode masih dapat dipelihara.
• Masalah hanya berada pada modul tertentu.
• Dependency dapat dipisahkan bertahap.
• Testing dan dokumentasi masih dapat dibangun.
• Perusahaan membutuhkan delivery tanpa downtime panjang.

Lakukan replatforming ketika:

• Infrastruktur atau database menjadi hambatan.
• Teknologi mendekati end-of-support.
• Sistem membutuhkan scalability dan observability lebih baik.
• Arsitektur aplikasi masih dapat dipertahankan.

Pertimbangkan rebuild ketika:

• Business rule lama sudah tidak relevan.
• Perubahan kecil selalu merusak bagian lain.
• Tidak tersedia dokumentasi dan test.
• Security tidak dapat diperbaiki secara memadai.
• Data model tidak mendukung proses masa depan.
• Biaya mempertahankan sistem lebih tinggi daripada membangunnya kembali.

Keputusan sebaiknya dibuat berdasarkan assessment, bukan hanya umur teknologi.

Checklist Mengurangi AI Technical Debt

Perusahaan tidak perlu menyelesaikan seluruh technical debt sebelum memulai AI.

Namun, utang yang menyentuh data kritis, hak akses, transaksi, dan integrasi utama perlu diprioritaskan sebelum otonomi AI diperluas.

Kesimpulan

AI technical debt muncul ketika perusahaan menambahkan AI di atas fondasi yang sulit dipahami, diubah, dan dikendalikan.

Masalahnya dapat berasal dari sistem lama, data yang terfragmentasi, integrasi sementara, business rule tersembunyi, akses berlebihan, observability yang lemah, atau ketergantungan pada satu provider.

AI tidak otomatis membuat legacy system menjadi modern.

AI dapat menjadi lapisan baru yang menutupi masalah lama—hingga volume, pengguna, dan tingkat otonominya meningkat.

Pendekatan yang lebih aman adalah menilai setiap use case, dependency, data, permission, dan risiko operasional. Setelah itu, perusahaan dapat memilih apakah sistem cukup diintegrasikan, diperkuat, di-refactor, di-replatform, atau dibangun kembali.

Tujuan modernisasi bukan menggunakan teknologi terbaru.

Tujuannya adalah membangun fondasi yang membuat AI dapat menghasilkan nilai tanpa menambah kompleksitas yang tidak dapat dikendalikan.

Kurangi AI Technical Debt Bersama Crocodic

Crocodic membantu perusahaan mengevaluasi kesiapan sistem sebelum AI dihubungkan dengan proses operasional.

Melalui layanan Enterprise System Upgrade, sistem yang masih bernilai dapat ditingkatkan melalui API integration, perbaikan scalability, multi-user access, observability, serta AI automation tanpa selalu dibangun ulang dari awal.

Untuk kebutuhan sistem inti baru, Crocodic menyediakan layanan Custom Enterprise Software yang disesuaikan dengan workflow, struktur data, hak akses, dan kebutuhan integrasi perusahaan.

Proses dimulai melalui strategic discovery untuk memetakan technical debt, business rule, dependency, data, serta risiko sebelum menentukan roadmap modernisasi.

Diskusikan kesiapan sistem dan strategi pengurangan AI technical debt bersama Crocodic.