Ada anggota tim yang bertanya "pelanggan mana saja yang belum bayar lebih dari 60 hari", dan alih-alih menunggu laporan, mereka langsung dapat jawabannya. Itulah janji dari integrasi AI ke database, dan menjelang akhir 2024 ini akhirnya benar-benar praktis untuk dibangun, bukan sekadar demo yang lo lihat di Twitter. Masalahnya, menghubungkan language model ke database produksi juga cara tercepat untuk punya minggu yang buruk, jadi yang menentukan bukan prompt-nya, tapi engineering di baliknya.

Saya sudah membangun ini untuk dua klien tahun ini, sebuah perusahaan multifinance dan sebuah tim ops internal, dan kedua proyek itu hidup atau mati berdasarkan prinsip yang sama: AI tidak pernah menyentuh database produksi secara langsung. Semua hal lain hanyalah variasi dari ide ini.

Kenapa "kasih saja akses database" adalah insting yang keliru

Jalan pintas yang menggoda adalah memberikan connection string ke model dan membiarkannya menulis SQL sendiri. Cara ini berhasil di demo. Di produksi, ini gagal dengan tiga pola yang bisa ditebak.

  • Model menulis query yang men-scan seluruh tabel orders karena tidak ada yang memberi tahu bahwa ada index, dan dashboard lo jadi timeout di jam sibuk.
  • Model menampilkan kolom yang seharusnya tidak boleh dilihat, seperti nomor identitas pelanggan atau kolom gaji, karena tidak ada yang memberitahunya bahwa kolom itu terlarang.
  • Model sesekali menulis sesuatu yang destruktif, bukan karena niat jahat, tapi karena model yang bisa membuat SQL bisa membuat SQL apa pun, termasuk UPDATE tanpa klausa WHERE, kalau prompt-nya cukup ambigu.

Ini semua bukan hipotesis. Inilah alasan mengapa proyek "hubungkan AI ke database saya" berhenti di tengah jalan atau ditutup paksa oleh tim IT setelah insiden pertama.

Arsitektur yang benar-benar berhasil

Pola yang saya pakai sekarang, dan yang layak lo tiru, punya empat lapis antara model dan data lo.

  1. Replika read-only. Jangan pernah mengarahkan tooling AI ke database utama. Replika yang delay-nya beberapa menit tidak akan terasa oleh pengguna, tapi menghilangkan satu kategori risiko sepenuhnya.
  2. Lapisan view yang dibatasi. Jangan ekspos tabel mentah. Ekspos view yang sudah mengecualikan kolom sensitif (gaji, NIK, detail pembayaran mentah) dan yang sudah melakukan pre-join pada tabel-tabel yang memang biasa ditanyakan orang. Model bekerja di atas permukaan yang sederhana dan aman, bukan skema lengkap lo.
  3. Query hasil generate yang bisa dilihat manusia. Dukungan structured output di model-model saat ini (baik kelas GPT-4 maupun kelas Claude 3) berarti lo bisa memaksa model mengembalikan query object, bukan sekadar teks, dan menampilkannya ke pengguna sebelum dijalankan. Satu langkah ini saja sudah menangkap kebanyakan kesalahpahaman sebelum berubah jadi jawaban yang salah.
  4. Query logging, setiap saat. Setiap query yang dihasilkan, siapa yang bertanya, apa hasilnya. Ketika ada yang terlihat janggal, dan cepat atau lambat pasti ada, lo perlu bisa menelusurinya dalam hitungan menit, bukan menebak-nebak.

Ini adalah disiplin yang sama dengan yang saya terapkan pada layanan pelanggan berbasis AI: AI adalah lapisan di depan sistem dengan batasan yang tegas, bukan pengganti batasan itu sendiri.

Berapa biaya yang harus dikeluarkan untuk "aman"

Tidak ada yang eksotis dari sisi engineering di sini, dan itu kabar baiknya. Read replica cukup satu centang di kebanyakan layanan database terkelola. Lapisan view adalah SQL yang lo tulis sekali saja. Query logging adalah satu tabel dan satu fungsi middleware. Untuk sistem SME skala menengah, saya akan mengalokasikan sekitar 15 hingga 25 juta Rupiah waktu engineering di luar integrasi AI yang sudah lo kerjakan, sebagian besar untuk mendesain view yang benar bersama pemilik data.

Kesalahan yang sering saya lihat dari para pemilik bisnis adalah memperlakukan lapisan ini sebagai overhead opsional yang dipangkas ketika anggaran menipis. Padahal sebaliknya. Antarmuka AI adalah 20 persen yang mudah. Lapisan akses data yang aman adalah 80 persen yang menentukan apakah ini akan menjadi alat yang dipercaya tim lo, atau insiden yang harus lo jelaskan ke klien.

Apa yang sebenarnya boleh ditanyakan orang

Batasi use case-nya sebelum lo batasi skemanya. Klien multifinance yang saya tangani awalnya membuka scope terlalu lebar ("tanya apa saja soal buku pinjaman kami"), dan kami mempersempitnya dengan tegas menjadi lima kategori pertanyaan: status pembayaran, akun menunggak per cabang, kinerja kolektor, volume pencairan, dan aging portofolio. Setiap kategori dipetakan ke satu atau dua view yang sudah dibuat sebelumnya. Tugas AI menjadi memilih view dan filter yang tepat, bukan mengarang query dari skema kosong. Scope yang lebih sempit berarti lebih sedikit cara untuk salah, dan itu juga jauh lebih mudah diuji.

Tanda bahwa lo sudah membatasi scope dengan benar: lo bisa mendaftar pertanyaan-pertanyaan yang harus dijawab dalam satu halaman, dan setiap satu di antaranya sudah sesuai dengan data yang memang sudah dilaporkan manual oleh tim lo hari ini.

Uji dulu sebelum dipercaya

Sebelum siapa pun diberi akses, jalankan 30 hingga 50 pertanyaan nyata yang benar-benar akan ditanyakan staf lo, dan cek setiap jawaban dengan orang yang paham data itu secara manual. Bukan karena modelnya secara umum tidak bisa diandalkan, tapi karena skema data lo punya keanehan sendiri (field status dengan nilai lama yang sudah usang, tanggal yang tersimpan di timezone yang salah, flag "deleted" yang sudah tidak ada yang ingat) yang tidak bisa diperbaiki hanya dengan kualitas model yang bagus. Fase pengujian inilah tempat lo menemukan keanehan-keanehan itu dengan biaya murah, sebelum seorang manajer mengambil keputusan berdasarkan angka yang keliru.

Biarkan query log tetap berjalan selama bulan pertama setelah peluncuran, dan cek secara acak setiap minggu. Kebanyakan masalah integrasi akan terlihat sejak awal, di beberapa lusin penggunaan pertama, bukan berbulan-bulan kemudian.

Kesimpulannya

Integrasi AI ke database layak dibangun di 2024 karena tooling-nya (structured output, model yang mumpuni, setup replika yang matang) akhirnya membuatnya aman untuk dilakukan dengan benar, bukan sekadar mungkin untuk didemokan. Read-only replica, view yang dibatasi, query hasil generate yang bisa dilihat, dan riwayat yang tercatat, semua ini bukan kehati-hatian demi kehati-hatian, melainkan yang mengubah "tanya apa saja soal data lo" dari liabilitas menjadi alat yang benar-benar diandalkan tim lo. Kalau lo sedang mempertimbangkan apakah membangun ini sendiri atau melibatkan bantuan dari luar supaya lapisan datanya benar sejak awal, ervandra.com adalah tempat yang masuk akal untuk memulai percakapan itu.