AI dalam Alur Kerja Data Analyst: Di Mana Membantu, Di Mana Gagal

Seorang VP of Sales mengirim pesan di Slack pukul 08.47 pagi. Isinya hanya satu baris: "AI bilang pendapatan naik 14%, bisakah kamu cek ulang?"

Anda membuka copilot dari BI tool, menempel prompt yang sama dengan yang digunakan VP tersebut, dan mendapat balasan berupa kueri yang berjalan dalam 1,2 detik. Angka yang dikembalikan adalah 14%. Kuerinya juga salah. Kueri itu menggabungkan tabel orders ke customers menggunakan email, bukan customer_id, sehingga menghitung ganda siapa saja yang pernah memperbarui alamat email mereka. Kueri itu memperlakukan status = 'completed' sebagai pendapatan tanpa menyaring pengembalian dana. Angka 14% adalah hasil perhitungan yang benar secara aritmatika dari dataset yang salah.

VP tersebut tidak mengetahui hal itu. Copilot tidak mengetahuinya. Anda mengetahuinya, karena Anda sudah bekerja di gudang data ini selama sembilan bulan dan pernah terjebak oleh kedua penggabungan tersebut sebelumnya.

Inilah pekerjaan yang sebenarnya di tahun 2026. Bukan menulis SQL lebih cepat. Memverifikasi SQL yang sudah ditulis, dengan meyakinkan, oleh sesuatu yang tidak memahami bisnis ini.

Mengapa ini penting sekarang

Setiap vendor BI dan setiap IDE telah meluncurkan fitur "tanya dalam bahasa biasa". Pimpinan perusahaan sudah memperhatikannya. CFO membaca artikel McKinsey tentang produktivitas AI dan kini mengharapkan analitik menghasilkan lebih banyak dengan jumlah tenaga kerja yang sama. Menolak menggunakan AI membuat Anda terlihat lambat. Mempercayainya secara membabi buta menjadikan Anda stempel manusia pada angka-angka yang dihasilkan oleh halusinasi dan masuk ke dalam deck presentasi dewan direksi.

Satu-satunya posisi yang berkelanjutan adalah posisi ketiga: gunakan AI sebagai pengganda kekuatan pada bagian pekerjaan yang bersifat mekanis, dan jadilah lapisan tata kelola pada bagian yang tidak. Analyst yang dapat dengan percaya diri menjelaskan mengapa kueri yang dibuat AI salah, memperbaikinya dalam dua menit, dan mengirimkan jawaban yang benar adalah orang yang lebih bernilai di tahun 2026, bukan lebih sedikit. Analyst yang menempel hasil copilot ke dalam dasbor dan langsung pergi hanyalah junior dengan langkah tambahan.

Di mana AI benar-benar membantu

Mari berbicara spesifik. "AI membantu produktivitas" adalah kalimat yang ingin saya hapus dari artikel ini. Berikut ini tempat-tempat di mana AI benar-benar memberikan manfaat, disebutkan dengan nama.

Draf SQL untuk diperbarui

Cursor dengan Claude sebagai model adalah pilihan aman saat ini bagi para analyst. Keunggulannya ada pada draf kedua, bukan draf pertama. Anda menulis kueri 200 baris dengan lima CTE untuk menghitung retensi kohort bulan per bulan. Kueri itu berfungsi. Tapi juga tidak dapat dibaca. Masukkan ke Cursor, minta refactor yang menggabungkan CTE dan menambahkan komentar, dan Anda akan mendapat sesuatu yang lebih bersih dalam 30 detik. Anda membacanya, menolak dua perubahan yang merusak logika, menerima sisanya, dan Anda menghemat sore hari penuh untuk pembersihan kode.

Hal yang sama berlaku untuk fungsi window yang Anda tulis dua kali setahun, self-join yang rumit untuk data hierarkis, dan logika pivot. Perlakukan hasilnya sebagai draf pertama dari junior yang cerdas namun belum pernah melihat gudang data Anda. Berguna, belum selesai.

Dokumentasi skema dasbor

Masukkan file model dbt Anda, LookML, atau JSON dasbor ke Claude, lalu minta tuliskan entri kamus data. Hasilnya akan berupa prosa yang dapat ditinjau dan 80% akurat. Anda mengedit 20% di mana AI membuat tebakan. Total waktu: 10 menit per dasbor dibandingkan dua jam, dan mode kegagalannya adalah "deskripsi salah", bukan "angka salah." Jauh lebih mudah terdeteksi saat ditinjau.

Ini adalah penggunaan AI dengan leverage tertinggi yang saya temukan. Dokumentasi adalah hal yang selalu dikatakan setiap tim analitik akan dikerjakan "kuartal depan" dan tidak pernah dilakukan. AI menghilangkan hambatan untuk memulai.

Persiapan wawancara kebutuhan

Sebelum bertemu pemangku kepentingan tentang dasbor baru, tempel thread Slack mereka, rangkaian email, dan permintaan kasar ke Claude. Beri prompt: "Apa lima pertanyaan yang harus saya klarifikasi sebelum menulis SQL untuk permintaan ini?" Anda akan mendapat daftar. Setengah pertanyaannya akan jelas. Dua akan menangkap ambiguitas yang Anda lewatkan. Satu tidak berguna. Tetap positif dalam 90 detik.

Intinya bukan bahwa AI mengenal bisnis Anda. Intinya adalah AI adalah rubber duck yang kompeten dan mengajukan pertanyaan lanjutan yang lebih baik daripada yang Anda lakukan pukul 9 pagi hari Selasa.

Narasi deteksi anomali

Anda menemukan lonjakan tersebut. Konversi turun 23% di wilayah tenggara, minggu ke minggu. Anda tahu itu adalah uji coba harga baru. Sekarang Anda perlu menulis pesan Slack dalam suara tim Anda, dengan bahasa lindung yang tepat, langkah selanjutnya yang tepat, dan panggilan kepada pemangku kepentingan yang terdampak. AI menyusun pesan itu dalam 15 detik. Anda mengedit nadanya, mengirimkannya, dan melanjutkan pekerjaan.

Perhatikan urutannya. Anda yang melakukan analisis. AI yang menulis. Balikkan urutan itu dan Anda kembali ke "AI bilang pendapatan naik 14%."

Pemeliharaan kamus data

Sebagian besar tim tidak memiliki deskripsi kolom apa pun di gudang data mereka. Nol. String kosong. Menghasilkan deskripsi secara otomatis dari nama kolom ditambah nilai sampel ditambah tabel induk tidaklah sempurna, tetapi "deskripsi tidak sempurna" mengalahkan "tidak ada deskripsi" setiap saat. Jalankan sebagai batch job sekali per kuartal, edit secara manual yang jelas salah, kirimkan.

Di mana AI gagal

Ini adalah mode kegagalan yang mengirimkan angka salah kepada para eksekutif. Hafalkan semuanya.

Semantik data

orders.status = 'completed' tidak berarti "pendapatan" di gudang data Anda. Mungkin mengecualikan pesanan yang dikembalikan, atau mungkin tidak. Mungkin menghitung perpanjangan langganan sebagai pesanan terpisah, atau menggabungkannya. Mungkin menggunakan gross_amount atau net_amount atau amount_after_tax_and_discount. AI tidak mengetahui mana yang benar. AI akan menebak. Tebakannya akan masuk akal. Tebakannya sering kali salah, dan salah dengan cara yang hampir tidak mungkin diketahui hanya dari melihat kueri. SQL-nya sempurna secara sintaksis, penggabungannya berhasil dikompilasi, angkanya dikembalikan. Anda harus mengenal gudang data untuk menangkapnya.

Penanganan NULL

COUNT(column) mengecualikan NULL. COUNT(*) tidak. SUM pada kolom yang berisi NULL mengembalikan NULL jika setiap nilainya NULL, tetapi sebuah angka jika ada nilai yang tidak NULL. LEFT JOIN pada relasi satu ke banyak meledakkan jumlah baris jika Anda lupa melakukan agregasi. AI melakukan kesalahan ini sekitar setengah dari waktu pada skema nyata, karena setengah dari waktu data pelatihan publik juga mengandung bug tersebut. Jika dasbor Anda tiba-tiba menampilkan 4x jumlah pelanggan dari kemarin, periksa penggabungan tabelnya.

Logika bisnis

"Pelanggan aktif" memiliki arti yang berbeda di setiap perusahaan. Di perusahaan B2B SaaS mungkin berarti "login dalam 30 hari terakhir." Di marketplace mungkin berarti "menyelesaikan transaksi dalam 90 hari terakhir." Di fintech mungkin berarti "saldo di atas $0 dan tidak ada tanda penipuan." AI default ke definisi yang paling umum dalam data pelatihannya, yang hampir pasti bukan definisi Anda. Begitu pula dengan "MRR," "churn," "engagement," "retention." Setiap metrik memiliki lima definisi yang masuk akal. Tim Anda menggunakan satu di antaranya. AI tidak tahu yang mana.

Tata kelola dan silsilah data

AI dengan senang hati menulis kueri terhadap customers_legacy_v2, sebuah tabel yang sudah tidak digunakan dan belum diperbarui sejak November. AI tidak tahu tentang SLA kesegaran dbt Anda. AI tidak tahu bahwa tim marketing mem-fork tabel pelanggan setiap hari Selasa untuk ekspor kampanye dan fork tersebut memiliki logika yang sedikit berbeda. AI tidak tahu bahwa Anda memigrasikan pelacakan pendapatan ke tabel baru enam minggu lalu dan yang lama sudah berstatus hanya-baca.

Ini adalah mode kegagalan yang paling buruk skalanya. Seiring gudang data Anda berkembang, model mental AI tentangnya semakin tertinggal, dan kueri yang dibuatnya menjadi semakin salah dengan penuh keyakinan dari waktu ke waktu.

Jebakan "AI yang menghasilkan kueri ini"

Ini adalah garis keras. Jangan pernah menempelkan kueri yang dihasilkan AI ke dalam dasbor, laporan pemangku kepentingan, atau deck eksekutif tanpa melakukan keempat pemeriksaan ini:

1. Jalankan terhadap hasil yang diketahui. Pilih irisan yang sudah Anda validasi sebelumnya (angka bulan lalu yang sudah disetujui CFO) dan konfirmasikan bahwa kueri AI mereproduksinya.
2. Periksa jumlah baris secara visual. Jika Anda memperkirakan sekitar 10.000 pelanggan dan kueri mengembalikan 47.000, Anda mengalami penggandaan baris. Jika mengembalikan 12, Anda memiliki filter yang terlalu agresif.
3. Periksa penggabungan tabel untuk penggandaan baris. Perhatikan setiap JOIN. Apakah sisi kanan dijamin unik pada kunci penggabungan? Jika tidak, Anda perlu DISTINCT atau agregasi.
4. Konfirmasi filter tanggal melakukan apa yang diklaim. "Bulan lalu" di BI tool A mungkin berarti "30 hari terakhir." Di tool B mungkin berarti "bulan kalender sebelumnya." Dalam SQL yang ditulis AI, bisa keduanya, ditambah kesalahan satu hari.

Pola yang perlu diinternalisasi adalah: AI menulisnya, saya memverifikasinya, saya yang bertanggung jawab. Bukan: AI bilang angkanya adalah X. Jika Anda tidak bisa mempertahankan kueri baris per baris di hadapan VP Finance, Anda tidak bisa mengirimkan jawabannya. Jika Anda mengirimkannya tetap dan ternyata salah, "AI yang menulisnya" bukanlah pembelaan. Anda yang menulisnya, dengan menerimanya.

Tata kelola dan kontrol versi

Perlakukan SQL yang dibantu AI seperti kode lainnya. Commit ke repositori dbt atau GitHub analitik Anda. Gunakan tinjauan pull request, bahkan jika satu-satunya peninjau adalah Anda sendiri 24 jam kemudian dengan pikiran yang segar. Tandai model dan prompt dalam pesan commit jika itu secara material membentuk logikanya, sehingga Anda di masa depan tahu dari mana struktur CTE yang aneh itu berasal.

Buat file forbidden_patterns.md kecil di repositori tim Anda. Sepuluh hingga dua puluh entri, masing-masing adalah jebakan yang pernah Anda alami sendiri:

• Penggabungan yang terlihat benar tetapi tidak (email vs customer_id seperti contoh di atas)
• Kolom yang telah berubah artinya (status dulu mencakup "shipped", sekarang tidak)
• Tabel yang tidak boleh dikueri langsung (raw.events adalah firehose, gunakan analytics.sessions)
• Definisi metrik yang berbeda dari default publik (definisi "pengguna aktif" Anda)
• Tabel yang sensitif terhadap SLA (yang ini memiliki lag 24 jam, yang itu real-time)

Masukkan file tersebut ke dalam konteks Cursor untuk setiap sesi SQL. Ini adalah alat tata kelola termurah dan paling berdampak yang saya temukan. AI jauh lebih kecil kemungkinannya untuk masuk ke jebakan yang sudah diketahui jika Anda telah memberitahunya di mana jebakan-jebakan itu berada.

Rencana 30 hari mengintegrasikan AI tanpa kehilangan keahlian

Jangan mencoba menggunakan AI untuk seluruh alur kerja Anda pada hari pertama. Lakukan secara bertahap.

Minggu 1, kalibrasi. Pilih satu tool. Cursor plus Claude adalah pilihan aman; jika perusahaan Anda sudah menggunakan Copilot, gunakan itu. Gunakan hanya untuk refactoring SQL pada kueri yang sudah Anda pahami dan sudah Anda validasi. Bandingkan setiap hasil dengan apa yang akan Anda tulis sendiri. Bangun pemahaman tentang di mana AI dapat diandalkan dan di mana ia berhalusinasi. Tujuannya adalah kalibrasi, bukan produktivitas.

Minggu 2, dokumentasi. Tambahkan tugas-tugas berisiko rendah namun berdampak tinggi. Buat draf entri kamus data secara otomatis. Hasilkan README dasbor. Tulis draf runbook untuk permintaan berulang tim Anda. Mode kegagalan di sini adalah kalimat yang perlu ditulis ulang, bukan angka yang salah di meja CFO.

Minggu 3, persiapan kebutuhan. Sebelum setiap pertemuan pemangku kepentingan, jalankan AI terlebih dahulu pada thread tersebut. Minta lima pertanyaan klarifikasi. Catat mana yang benar-benar menghemat penulisan ulang. Setelah dua minggu, Anda akan memiliki pola tentang apa yang AI tangkap dan apa yang dilewatkannya.

Minggu 4, kodifikasi. Tulis ai-usage.md tim Anda. Tiga bagian: apa yang boleh AI buat secara mandiri, apa yang harus diverifikasi manusia sebelum digabung, dan apa yang terlarang. Titik awal yang wajar:

• Diizinkan: draf dokumentasi, saran refactor, draf narasi anomali setelah analisis manusia, pertanyaan klarifikasi kebutuhan.
• Verifikasi sebelum digabung: SQL apa pun yang menyentuh dasbor produksi, perubahan definisi metrik apa pun, model dbt baru apa pun.
• Terlarang: menjalankan SQL yang dibuat AI terhadap prod secara otomatis tanpa LIMIT 100 dan tinjauan manusia, menempel kolom apa pun yang mengandung PII ke alat AI pihak ketiga yang belum menandatangani Perjanjian Pemrosesan Data (DPA), menggunakan AI untuk menulis SQL dalam dialek yang tidak Anda baca dengan lancar.

Yang terakhir adalah yang paling sering dilewatkan orang. Jika Anda tidak bisa membaca sintaks fungsi window khusus Snowflake, Anda tidak bisa meninjau apa yang ditulis Cursor. Anda mempercayainya berdasarkan iman. Jangan.

Opsional: sudut pandang ACE Framework

Jika perusahaan Anda menerapkan AI Operating Model berdasarkan ACE Framework, alur kerja analyst dapat dipetakan dengan rapi ke dalamnya. AI menangani Generate (menulis SQL, menulis dokumentasi, menulis pembaruan Slack) dan membantu Analyze (rangkuman anomali, saran refactor). Manusia yang memiliki Ingest (semantik data, apa arti sebenarnya setiap kolom dalam bisnis ini), Predict (interpretasi kausal mengapa sebuah metrik bergerak), dan Execute (mengirimkan jawaban kepada pemangku kepentingan dengan keyakinan dan jejak logika yang dapat dipertahankan).

Itulah versi satu paragraf. Intinya adalah bagian pekerjaan yang memerlukan kepercayaan tinggi dan konteks bisnis yang kaya tetap ada pada manusia untuk waktu yang lama. Bagian yang mekanis diberikan kepada AI. Karir Anda dibangun pada paruh pertama.

Kesalahan umum

Beberapa jebakan yang saya lihat para analyst masuki, kira-kira berdasarkan frekuensi:

• Membiarkan pemangku kepentingan melayani diri sendiri dengan copilot BI dan memperlakukan tinjauan analyst sebagai opsional. Copilot mengirimkan angka yang salah; analyst tetap disalahkan.
• Menempel skema prod dengan PII ke alat AI pihak ketiga yang tidak memiliki DPA. Ini adalah alasan pemecatan di sebagian besar perusahaan. Periksa sebelum menempel.
• Menggunakan AI untuk menulis SQL dalam dialek yang tidak Anda baca dengan lancar. ARRAY_AGG di BigQuery berbeda dengan di Postgres, QUALIFY di Snowflake tidak ada di Redshift. Anda tidak bisa meninjau apa yang tidak bisa Anda baca.
• Melewatkan langkah "bandingkan dengan hasil yang diketahui" karena kuerinya "terlihat benar." Inilah cara pertumbuhan pendapatan 14% dikirimkan padahal pertumbuhan sebenarnya hanya 3%.
• Memperlakukan kepercayaan diri copilot BI sebagai bukti kebenaran. Ia akan mengatakan "pendapatan naik 14%" dengan nada yang sama baik kuerinya benar maupun salah secara fatal.

Template dan alat

Tiga artefak yang perlu dibangun dalam 30 hari pertama Anda. Simpan di repositori analitik tim Anda.

1. forbidden_patterns.md: mulai dengan sepuluh entri dari gudang data Anda. Penggabungan nyata yang pernah merugikan seseorang. Tambahkan satu per bulan saat Anda menemukannya.
2. Daftar periksa tinjauan SQL: delapan item yang dijalankan pada kueri apa pun yang dibuat AI sebelum digabung: pemeriksaan hasil yang diketahui, kewarasan jumlah baris, pemeriksaan penggandaan baris, pemeriksaan filter tanggal, pemeriksaan penanganan NULL, pemeriksaan logika bisnis (apakah "aktif" berarti apa yang kita maksud?), pemeriksaan tata kelola (apakah tabel ini terkini?), pemeriksaan keterbacaan.
3. Prompt persiapan wawancara pemangku kepentingan: prompt Claude yang tersimpan yang Anda tempel thread Slack ke dalamnya, mendapatkan kembali lima pertanyaan klarifikasi. Perbarui setiap bulan.
4. ai-usage.md: kebijakan tim Anda. Dokumen hidup. Tinjau setiap kuartal.

Mengukur keberhasilan

Anda akan tahu ini berhasil ketika tiga hal terbukti nyata. Anda mengirimkan lebih cepat pada sisi dokumentasi dan refactoring, dan Anda dapat menunjukkan deliverable spesifik yang sebelumnya tidak ada. Pemangku kepentingan mempercayai angka Anda lebih banyak, bukan lebih sedikit, karena Anda secara rutin menangkap kesalahan copilot BI sebelum mendarat di Slack. Dan Anda dapat mengartikulasikan, dalam satu kalimat per kueri, mengapa draf pertama AI salah.

Kalimat terakhir itulah yang membuat Anda lebih senior di tahun 2026, bukan lebih mudah digantikan. "Ia melakukan penggabungan pada email bukan customer_id." "Ia melewatkan filter pengembalian dana." "Ia menggunakan tabel pendapatan yang sudah tidak digunakan." Setiap kalimat adalah sepotong pertimbangan spesifik gudang data yang AI tidak miliki dan tidak bisa miliki tanpa Anda. Itulah benteng pertahanan Anda. Bangunlah.

Pekerjaan ini bukan lagi mengetik kueri. Pekerjaan ini adalah memiliki jawabannya. AI menulisnya, Anda memverifikasinya, Anda yang bertanggung jawab. Itulah garisnya. Itulah keseluruhan artikel ini.

Pelajari Lebih Lanjut

• Sehari dalam Kehidupan Data Analyst
• 30/60/90 Hari Pertama Anda sebagai Data Analyst Baru
• Template Job Description Data Analyst
• ACE Framework