AI Agentik Bertemu Pengembangan Basis Data: Apa yang Berubah Saat AI Benar-Benar Dapat Menjalankan Kueri

Selama beberapa tahun terakhir, pengembangan basis data dengan bantuan AI mengikuti pola yang cukup nyaman. Pengembang menjelaskan kebutuhannya. AI menghasilkan SQL. Pengembang membacanya, memperbaiki bagian yang tampak keliru, lalu memutuskan apakah akan menjalankannya.

Alur kerja itu mempertahankan satu batas penting: AI dapat menyarankan tindakan, tetapi manusia tetap memutuskan apakah tindakan tersebut diterapkan pada basis data.

Namun, batas itu mulai menghilang dengan hadirnya AI agentik. Saat ini, sistem AI dapat memeriksa skema, menjalankan kueri, menafsirkan hasilnya, dan menentukan tindakan selanjutnya. Menurut survei terbaru, 62% organisasi telah bereksperimen dengan agen AI, sementara 23% melaporkan bahwa mereka telah memperluas penerapan sistem agentik di suatu bagian perusahaan.

Karena itu, tim basis data perlu segera menjawab pertanyaan arsitektur yang cukup mendesak. Bukan apakah AI dapat menjalankan SQL. AI memang bisa. Pertanyaan sebenarnya adalah apa yang berubah ketika asisten tidak lagi sekadar menyarankan kode, tetapi mulai bertindak pada basis data, serta seberapa ketat otonomi tersebut perlu dikendalikan.

Dari Saran Menjadi Tindakan

Satu keputusan pengindeksan sederhana menunjukkan mengapa pergeseran ini penting.

Agen melihat kueri yang lambat, memeriksa skema, menyimpulkan bahwa indeks mungkin dapat membantu, membuat indeks tersebut, menjalankan ulang beban kerja, lalu memeriksa hasilnya.

Agen mungkin menjalankan perintah sesederhana:

CREATE INDEX IX_Orders_CustomerId
ON Orders(CustomerId);

Pernyataan itu sama sekali tidak aneh. Asisten AI bisa saja menyarankan hal yang persis sama. Perbedaannya terletak pada siapa yang mengambil keputusan akhir.

Dengan asisten, pengembang meninjau rekomendasi, mengujinya, lalu memutuskan apakah akan menjalankannya. AI memberi saran, tetapi manusialah yang bertindak. Dengan agen yang memiliki hak eksekusi, sistem dapat mengambil keputusan itu sendiri dan melanjutkan tanpa menunggu persetujuan.

Jika keputusan itu tepat, alur kerja menjadi lebih cepat. Namun, agen tidak selalu memiliki gambaran lengkap. Agen mungkin luput memperhitungkan dependensi aplikasi, aturan bisnis, pola beban kerja, jendela pemeliharaan, atau konteks lain yang jelas bagi orang-orang yang mengoperasikan sistem.

Jadi, agen dapat mengambil keputusan yang secara teknis tampak masuk akal, tetapi tetap keliru untuk lingkungan tempatnya bertindak, mengingat batasan dan kebutuhan khusus di lingkungan tersebut.

Risikonya meningkat ketika tindakan-tindakan mulai dirangkai. Kueri yang buruk SELECT mungkin hanya berjalan lambat. Perintah yang buruk UPDATE dapat mengunci seluruh tabel yang besar atau memengaruhi jauh lebih banyak baris daripada yang dimaksudkan. Indeks yang digunakan untuk satu kueri mungkin tidak diperlukan, tetapi menambah beban pada kueri lain. Perubahan skema dapat merusak sesuatu yang bergantung padanya tanpa diketahui agen, karena agen mungkin tidak memiliki konteks operasional yang lengkap dan tidak dapat menguji setiap kemungkinan kasus penggunaan.

Jadi, masalahnya bukan karena agen tidak mampu mengambil keputusan yang baik terkait basis data. Sering kali, mereka mampu. Masalahnya adalah ketika diizinkan bertindak berdasarkan keputusan tersebut, tim harus lebih tegas menentukan sejauh mana wewenang itu berlaku, konteks apa yang dapat dilihat agen, kapan manusia masih perlu turun tangan, dan siapa yang tetap bertanggung jawab atas hasilnya.

Gartner memperkirakan lebih dari 40% proyek AI agentik akan dibatalkan pada akhir 2027, sebagian karena pengendalian risiko yang tidak memadai. Bagi tim basis data, pelajarannya cukup sederhana: berikan hak eksekusi setelah pengendalian diterapkan, bukan sebelumnya.

Apa yang Dapat Didelegasikan dengan Aman?

Sebagian tugas basis data jauh lebih aman untuk diserahkan daripada tugas lainnya.

Analisis kueri adalah contoh yang baik. Agen dapat memeriksa statistik kueri, mengambil rencana eksekusi, memeriksa indeks dan struktur tabel, serta menyarankan perbaikan yang mungkin dilakukan tanpa mengubah data produksi.

Agen mungkin menemukan kueri yang berulang kali memindai tabel besar Orders tersebut:

SELECT OrderId, OrderDate, Total
FROM Orders
WHERE CustomerId = @CustomerId
ORDER BY OrderDate DESC;

Setelah itu, agen dapat menjelaskan pemindaian tersebut, menyarankan indeks, dan membuat DDL. Agen tidak perlu mendapat izin untuk menjalankan CREATE INDEX agar tetap berguna.

Hal yang sama berlaku untuk tugas seperti:

• Menjelaskan rencana eksekusi;
• Mengidentifikasi indeks yang hilang atau tidak diperlukan;
• Menandai SELECT * kueri atau predikat yang tidak SARGable;
• Meninjau penerapan join dan filter secara lebih awal;
• Meninjau dependensi dan skema;
• Memecahkan masalah galat SQL;
• Mengoptimalkan skrip SQL.

Pembagian praktisnya sederhana: berikan akses yang cukup kepada agen untuk memahami masalah, tetapi jangan otomatis memberinya akses yang cukup untuk mengubah basis data. Visibilitas luas dapat berguna, tetapi pemberian hak eksekusi yang luas merupakan keputusan berbeda.

Saat Kendali Manusia Tetap Penting

Beberapa keputusan terkait basis data tetap memerlukan keterlibatan manusia. Misalnya, agen menemukan sebuah tabel AuditLog yang berisi ratusan juta baris dan memutuskan bahwa catatan lama harus dihapus:

DELETE FROM AuditLog
WHERE CreatedAt < DATEADD(year, -2, GETDATE());

SQL-nya bisa saja sepenuhnya valid, tetapi keputusannya tetap sangat buruk.

Mungkin kebijakan regulasi mewajibkan penyimpanan selama tujuh tahun. Bisa jadi suatu aplikasi bergantung pada catatan tersebut. Mungkin penghapusan perlu dilakukan secara bertahap untuk menghindari pertumbuhan log transaksi. Bisa jadi catatan harus diarsipkan sebelum dihapus.

Tidak satu pun persyaratan tersebut selalu tercantum dalam skema.

Inilah salah satu keterbatasan jika pekerjaan basis data diperlakukan sebagai masalah pembuatan kode. Basis data memiliki struktur teknis, tetapi keputusan terkait sering kali merupakan keputusan bisnis yang diwujudkan melalui operasi teknis. Kehati-hatian yang sama perlu diterapkan pada operasi seperti:

• DROP dan destruktif ALTER pernyataan;
• produksi UPDATE dan DELETE operasi;
• migrasi data berskala besar;
• perubahan peran dan izin;
• perubahan batasan;
• perubahan yang memengaruhi replikasi atau ketersediaan;
• penerapan prosedur tersimpan yang memuat logika bisnis.

Tindakan yang benar secara teknis belum tentu tepat. Karena itu, persetujuan manusia tidak seharusnya dipandang sebagai batasan yang merepotkan bagi AI agentik. Untuk operasi basis data berdampak tinggi, persetujuan tersebut merupakan bagian dari arsitektur.

AI Agent Juga Membutuhkan Hak Akses Minimum

Salah satu jalan pintas yang perlu dihindari oleh tim basis data adalah membiarkan agen menggunakan kredensial yang sudah dimiliki pengembang. Cara ini memang mudah, tetapi agen tersebut akan memperoleh semua akses yang dimiliki pengembang itu.

Pendekatan yang lebih aman sama dengan yang digunakan untuk pengguna dan layanan: hak akses minimum. Microsoft menyarankan pemberian hanya izin yang diperlukan untuk tugas tersebut serta pemantauan aktivitas dengan hak istimewa.

Misalnya, agen analisis kinerja mungkin memerlukan:

CONNECT
SELECT
VIEW DATABASE STATE
VIEW DEFINITION

Agen tersebut mungkin tidak memerlukan:

ALTER ANY TABLE
CONTROL DATABASE
db_owner
sysadmin

Agen yang berbeda juga dapat memiliki identitas yang berbeda. Agen pelaporan mungkin memperoleh SELECT akses ke beberapa skema. Agen migrasi mungkin hanya bekerja di lingkungan pengembangan atau staging. Agen produksi mungkin diberi izin dengan cakupan sangat terbatas dan tetap harus memperoleh persetujuan sebelum dapat menjalankan operasi.

OWASP menyarankan pola dasar yang sama untuk AI agent: pisahkan akses baca dan tulis, batasi alat dan sumber daya, serta wajibkan otorisasi eksplisit untuk tindakan sensitif.

Aturannya sederhana: berikan agen izin yang diperlukan untuk tugasnya, bukan izin milik orang yang meluncurkannya.

Libatkan Manusia dalam Alur Kerja

Model yang lebih baik untuk pekerjaan basis data agentik adalah alur kerja yang terkendali:

Amati → Analisis → Ajukan → Tinjau → Jalankan → Validasi → Catat

Misalkan sebuah agen sedang menyelidiki titik akhir API yang lambat. Agen itu menemukan SQL yang mendasarinya, memeriksa rencana eksekusi dan statistik tabel, mengidentifikasi kemungkinan indeks yang hilang, lalu menyiapkan skrip migrasi.

Skrip tersebut dapat dijalankan terlebih dahulu di staging. Agen itu menjalankan kembali beban kerja, memeriksa hasilnya, lalu menyiapkan perubahan untuk produksi.

Lalu, agen itu berhenti.

Pengembang atau DBA meninjau migrasi, memeriksa dependensi dan dampak bisnisnya, lalu menyetujuinya sebelum perubahan apa pun diterapkan di produksi.

Agen tetap dapat menangani banyak pekerjaan berulang. Tanggung jawab akhir atas perubahan berdampak tinggi tetap berada di tangan manusia.

Kontrol transaksi dapat menambahkan lapisan keamanan lain. Misalnya, savepoint PostgreSQL memungkinkan sebagian transaksi dibatalkan tanpa membuang semua yang telah dilakukan sebelumnya. Hal ini dapat membantu dalam perubahan otomatis yang saling terkait erat, tetapi pembatalan bukan pengganti izin dan persetujuan yang tepat.

Di sinilah alat seperti dbForge AI Assistant juga cocok digunakan. Alat ini dapat memanfaatkan konteks skema untuk membuat dan menjelaskan SQL, mengatasi masalah, membandingkan DDL, mendeteksi indeks yang tidak efisien, serta menyiapkan skrip pengoptimalan, sambil tetap menampilkan SQL yang dihasilkan agar dapat ditinjau oleh pengembang.

Tujuannya adalah mengotomatiskan pekerjaan rutin sambil memastikan keputusan penting tetap dibuat oleh manusia.

Tujuan Sebenarnya adalah Otonomi yang Terkendali

AI agentik tidak harus berarti memilih antara “AI hanya memberi saran” dan “AI menjalankan basis data”. Ada banyak kemungkinan di antaranya.

Tim dapat memulai dengan tugas berisiko rendah, seperti menjelaskan SQL, meninjau skema, dan melakukan pemeriksaan hanya-baca. Setelah itu, agen dapat secara bertahap menangani lebih banyak pekerjaan di lingkungan pengembangan dan staging.

Akses tulis sebaiknya diberikan jauh belakangan, dengan batasan yang jelas terkait baris yang terdampak, transaksi, pembatalan, pemantauan, dan persetujuan. Perubahan yang sepenuhnya otonom di lingkungan produksi seharusnya jarang terjadi.

Hal ini juga sejalan dengan panduan Deloitte: mulailah dengan alur kerja berisiko lebih rendah dan data nonkritis, libatkan orang-orang dalam proses, serta perkuat tata kelola seiring bertambahnya kemampuan agen.

Tujuannya bukan otonomi mutlak. Tujuannya adalah memberi agen cukup keleluasaan untuk membantu, tetapi tidak memberinya akses melebihi yang dibutuhkan.

Intinya: Pengembangan Basis Data Tetap Membutuhkan Pertimbangan

Agen AI dapat mengambil alih banyak pekerjaan berulang dalam rekayasa basis data. Agen dapat melihat beban kerja, memeriksa kueri, menghubungkan skema, rencana, kesalahan, dan data kinerja, lalu bertindak berdasarkan apa yang mereka lihat.

Namun, begitu sistem AI dapat mengubah keadaan basis data, persoalannya pun berubah. Tim memerlukan aturan yang jelas mengenai identitas, izin, batas transaksi, persetujuan, observabilitas, pemulihan ke kondisi sebelumnya, dan jejak audit.

Itulah sebabnya, dari 88% organisasi yang menggunakan AI pada 2025, hanya 7% yang menyatakan bahwa AI telah diterapkan sepenuhnya di seluruh organisasi. Tantangan yang lebih berat adalah membuat AI cukup andal untuk beroperasi dalam skala besar.

Pengembangan basis data bergerak ke arah yang sama. Agen yang paling berguna bukanlah agen yang diizinkan melakukan paling banyak hal, melainkan agen yang kewenangannya dipahami dan dikendalikan dengan jelas.

Pertanyaannya bukan lagi apakah AI dapat menjalankan tugas-tugas basis data, melainkan tugas mana yang sebaiknya kita percayakan kepadanya, dan dengan batasan seperti apa.