BigQuery Graphs: Membuat Data Agentic Lebih Tepercaya

AI agent untuk sales, finance, operations, dan reporting akan semakin sering diminta mengambil keputusan berbasis data. Masalahnya, banyak implementasi agent masih bergantung pada potongan tabel, hasil query ad hoc, atau konteks teks bebas yang tidak selalu konsisten.

Di sinilah pendekatan seperti BigQuery Graphs dengan measures menjadi menarik. Berdasarkan tulisan Google Cloud, BigQuery Graphs with measures for trusted agentic workloads, BigQuery Graphs diarahkan untuk membantu workload agentic bekerja dengan relasi data dan metrik yang lebih terstruktur. Dengan kata lain, agent tidak hanya membaca data, tetapi juga bisa memahami hubungan antar entitas dan menggunakan definisi metrik yang lebih jelas.

Bagi saya, ini adalah arah yang penting. AI agent yang dipercaya bisnis tidak cukup hanya pintar menjawab. Ia harus memahami konteks data, batas akses, definisi metrik, dan jejak audit dari keputusan yang dibuat.

Mengapa agent berbasis data sering rapuh

Banyak agent data dimulai dari pola sederhana: user bertanya, agent mencari tabel yang relevan, membuat SQL, lalu merangkum hasilnya. Untuk prototipe, pola ini masuk akal. Namun untuk kebutuhan bisnis yang serius, ada beberapa risiko.

Pertama, agent bisa salah memahami relasi data. Misalnya, customer, invoice, subscription, payment, dan ticket support mungkin tersebar di tabel berbeda. Jika relasinya tidak dimodelkan dengan baik, agent bisa mengambil kesimpulan yang tampak benar tetapi sebenarnya melompati konteks penting.

Kedua, definisi metrik sering tidak seragam. Revenue, active customer, churn, gross margin, inventory available, atau operational SLA bisa memiliki definisi berbeda antar tim. Jika agent mengambil angka dari tabel tanpa memahami definisi measure yang disepakati, hasilnya bisa memicu diskusi yang tidak produktif.

Ketiga, agent dapat menjawab dengan percaya diri meskipun konteksnya kurang. Ini berbahaya untuk finance reporting, sales planning, inventory decision, fraud review, dan operational KPI.

Dari potongan tabel ke pemahaman relasi entitas

Perbedaan utama yang saya lihat adalah ini: agent yang hanya membaca potongan tabel bekerja seperti analis yang diberi spreadsheet tanpa dokumentasi, sedangkan agent yang memahami graph dan measures bekerja dengan peta hubungan bisnis yang lebih eksplisit.

Dalam konteks customer 360, misalnya, agent perlu memahami bahwa satu customer dapat memiliki banyak account, transaksi, komplain, campaign touchpoint, dan kontrak. Pertanyaan seperti pelanggan mana yang berisiko churn tidak cukup dijawab dari satu tabel. Agent perlu melihat relasi antar entitas dan sinyal yang relevan.

Dalam revenue reporting, agent tidak boleh asal menjumlahkan kolom amount. Ia perlu tahu measure mana yang digunakan oleh bisnis: booked revenue, recognized revenue, net revenue, refund-adjusted revenue, atau definisi lain yang sudah divalidasi.

Dalam inventory, agent perlu membedakan stock on hand, reserved stock, in-transit, damaged, dan available to promise. Tanpa relasi dan definisi yang jelas, rekomendasi operasional bisa salah arah.

Dalam fraud signal, agent juga perlu melihat pola relasi: user, device, payment method, alamat, transaksi, dan anomali perilaku. Graph membantu cara berpikir semacam ini karena banyak sinyal fraud memang muncul dari hubungan antar entitas, bukan hanya nilai satu baris data.

Peran measures untuk jawaban yang konsisten

Measures penting karena metrik bisnis harus memiliki definisi yang stabil. Jika sebuah agent menjawab pertanyaan finance atau operations, ia seharusnya memakai definisi yang disetujui, bukan membuat interpretasi sendiri setiap kali query dibuat.

Saya melihat measures sebagai kontrak antara data team, engineering, dan business owner. Kontrak ini menjawab beberapa hal:

Apa arti metrik tersebut?
Tabel dan kolom apa yang menjadi sumbernya?
Filter, agregasi, dan aturan waktu apa yang digunakan?
Siapa pemilik definisinya?
Kapan terakhir divalidasi?
Apakah metrik ini boleh dipakai untuk keputusan otomatis?

Dengan measures, agent memiliki landasan yang lebih kuat untuk menjawab pertanyaan seperti pendapatan bulan ini, performa region tertentu, conversion rate campaign, atau backlog operational. Bukan berarti agent pasti benar, tetapi ruang kesalahannya bisa dipersempit karena definisi metrik tidak dibiarkan liar.

Governance adalah syarat, bukan tambahan

Trusted agentic workload tidak bisa hanya mengandalkan model AI yang bagus. Menurut saya, governance justru menjadi lapisan paling penting ketika agent mulai diberi akses ke data perusahaan.

Beberapa prinsip yang sebaiknya diterapkan:

Measure dimiliki dan divalidasi bisnis
Definisi revenue, churn, active user, inventory available, dan KPI lain harus punya owner. Data team bisa membantu implementasi, tetapi validasi makna harus datang dari pihak bisnis yang bertanggung jawab.
Least privilege access
Agent hanya boleh mengakses data yang diperlukan untuk tugasnya. Agent untuk sales tidak otomatis perlu membaca data payroll atau detail sensitif finance.
Row-level dan column-level security
Pembatasan akses perlu diterapkan di level data, bukan hanya di prompt. Jika user hanya boleh melihat region tertentu, agent juga harus tunduk pada batas yang sama.
Query cost control
Agent dapat menghasilkan query yang mahal jika tidak dibatasi. Perlu ada guardrail untuk limit, timeout, budget, sampling bila relevan, dan monitoring biaya.
Freshness dan observability
Jawaban agent harus mempertimbangkan kapan data terakhir diperbarui. Untuk KPI operasional, data yang telat beberapa jam bisa mengubah keputusan.
Audit trail
Setiap query, jawaban, sumber data, dan tindakan penting perlu bisa ditelusuri. Ini penting untuk debugging, compliance, dan post-mortem ketika terjadi kesalahan.
Human approval untuk tindakan berdampak tinggi
Agent boleh membantu analisis dan rekomendasi, tetapi tindakan seperti menghentikan campaign besar, mengubah forecast resmi, memblokir akun bernilai tinggi, atau memicu proses finance sebaiknya tetap membutuhkan persetujuan manusia.
Evaluasi kualitas jawaban agent
Jangan hanya mengevaluasi apakah jawaban terdengar masuk akal. Ukur apakah SQL benar, measure yang dipakai tepat, filter sesuai konteks, data fresh, dan kesimpulan tidak melampaui bukti.

Implikasi untuk engineering leader

Untuk programmer, Head of Software Engineering, manager SDLC, dan calon CTO, pelajaran praktisnya adalah jangan membangun data agent hanya sebagai wrapper LLM di atas data warehouse.

Agent yang aman untuk bisnis perlu arsitektur yang lebih disiplin:

semantic layer atau definisi metrik yang dikelola dengan rapi
model relasi entitas yang mudah dipahami sistem dan manusia
kontrol akses yang mengikuti policy perusahaan
logging dan audit dari query sampai rekomendasi
pipeline evaluasi untuk menguji jawaban agent secara berkala
proses approval untuk tindakan berisiko tinggi

BigQuery Graphs dan measures, seperti yang dibahas Google Cloud, berada di area yang relevan dengan kebutuhan ini. Kekuatan utamanya bukan sekadar membuat agent bisa menjawab lebih banyak pertanyaan, tetapi membantu agent menjawab dengan konteks yang lebih terstruktur.

Penutup

Saya melihat masa depan data automation bukan hanya tentang agent yang bisa membuat SQL otomatis. Nilai sebenarnya ada pada agent yang memahami relasi bisnis, memakai metrik yang disepakati, menghormati permission, dan meninggalkan jejak audit yang jelas.

BigQuery Graphs dengan measures memberi sudut pandang penting untuk membangun trusted agentic workloads: data tidak cukup tersedia, data harus bisa dipercaya, dijelaskan, dan dikendalikan. Untuk organisasi yang ingin memakai AI agent di sales, finance, operations, atau reporting, fondasi seperti ini sebaiknya disiapkan sejak awal, bukan ditempel setelah agent masuk production.

Referensi

BigQuery Graphs with measures for trusted agentic workloads. Penerbit: Google Cloud Blog. URL: https://cloud.google.com/blog/products/data-analytics/bigquery-graphs-with-measures-for-trusted-agentic-workloads. Tanggal publish sumber: 14 Agustus 2026.