Data Provenance untuk AI: Kapan Organisasi Harus Bisa Menjelaskan Asal Informasi

GEO.OR.ID KNOWLEDGE SYSTEM

Data Provenance untuk AI: Kapan Organisasi Harus Bisa Menjelaskan Asal Informasi

FormatPost
Diperbarui31 August 2026
Waktu baca8 menit
KonteksPanduan praktis

Seorang direktur melihat angka di dashboard AI.

“Customer churn kita 8,2 persen.”

Ia bertanya:

“Sumbernya dari mana?”

Analyst menjawab:

“Dari AI.”

Itu bukan provenance.

AI bukan asal informasi.

AI adalah salah satu proses yang mungkin membaca, merangkum, menghitung, atau menghasilkan output dari data lain.

Kalau organisasi tidak bisa menelusuri angka, claim, summary, atau recommendation kembali ke sumber, kita punya provenance gap.

Data provenance adalah kemampuan menjelaskan asal-usul data dan transformasi yang terjadi padanya.

W3C PROV mendefinisikan provenance sebagai informasi tentang entity, activity, dan person/agent yang terlibat dalam menghasilkan sebuah data atau thing, yang dapat digunakan untuk menilai kualitas, reliability, atau trustworthiness.

Definisi tersebut cukup tua, tetapi justru semakin relevan sekarang.

Generative AI membuat transformasi informasi jauh lebih cepat.

Satu report bisa diringkas.

Summary masuk deck.

Deck masuk chatbot.

Chatbot menghasilkan answer.

Answer dicopy ke email.

Seminggu kemudian tidak ada yang tahu source awal.

Provenance memutus rantai “katanya AI”.

Kapan provenance benar-benar dibutuhkan?

Tidak semua output perlu forensic trail lengkap.

Gunakan risk.

Untuk brainstorming headline, provenance detail mungkin tidak material.

Untuk pricing decision, legal claim, medical information, financial reporting, security conclusion, regulatory submission, product specification, atau public evidence, provenance jauh lebih penting.

Buat rule:

Semakin besar consequence jika informasi salah, semakin lengkap provenance yang diperlukan.

Ini practical.

Tidak perlu blockchain.

Tidak perlu knowledge graph canggih.

Mulai dari source.

Provenance minimal punya lima pertanyaan

1. Data berasal dari mana?

2. Siapa yang membuat atau mengumpulkannya?

3. Kapan?

4. Transformasi apa yang terjadi?

5. Siapa yang approve output final?

Contoh:

Claim:
“87 persen customer puas.”

Source:
survey Q2 2026.

Collector:
customer research team.

Sample:
1.204 response.

Transform:
AI membantu coding open-text, metric dihitung dari response terstruktur.

Review:
research lead.

Publication:
annual report.

Sekarang claim bisa diuji.

Tanpa provenance:

“Menurut analisis AI, 87 persen customer puas.”

Tidak cukup.

AI-generated versus AI-derived juga perlu dibedakan

AI-generated:
model membuat output baru.

AI-assisted:
manusia membuat output dengan bantuan model.

AI-derived:
output berasal dari data yang diproses dengan AI.

AI-transformed:
data diubah, diringkas, diterjemahkan, atau diklasifikasi.

Synthetic:
data dibuat secara artificial untuk tujuan tertentu.

Kata “dibuat dengan AI” terlalu luas.

Untuk governance internal, classification lebih presisi membantu.

Contoh synthetic test data tidak boleh tiba-tiba masuk production analytics.

AI-translated legal text tidak boleh dianggap official legal version tanpa review.

AI-summary dari interview tidak boleh dianggap verbatim quote.

Provenance mencegah category error.

Source URL saja belum cukup

URL bisa berubah.

Halaman bisa di-update.

PDF bisa diganti.

API menghasilkan data berbeda besok.

Untuk evidence penting, simpan:

Source identifier.

Retrieval date.

Version.

Hash jika diperlukan.

Effective date.

Original file.

License.

Owner.

Kalau source dinamis, capture snapshot sesuai policy.

Tidak perlu menyimpan seluruh internet.

Pilih evidence yang memang material.

Provenance tanpa retention bisa putus ketika source berubah.

Transformation log adalah bagian yang sering hilang

Data asal bisa benar.

Kesalahan muncul di tengah.

Contoh:

Sales = Rp100 miliar.

AI summary menulis Rp10 miliar.

Atau currency conversion salah.

Atau filter salah.

Atau deduplication menghapus record.

Atau model mengklasifikasikan sentiment dengan label yang tidak konsisten.

Kalau kita hanya menyimpan source awal dan output akhir, sulit diagnosis.

Untuk high-impact workflow, simpan transformation.

Raw data.

Cleaning rule.

Model/tool.

Prompt atau configuration yang material.

Code version.

Output.

Human adjustment.

Approval.

Tidak harus semua input conversation disimpan jika privacy melarang.

Governance harus menyeimbangkan provenance dengan data minimization.

Provenance bukan alasan mengumpulkan semua.

NIST Generative AI Profile menempatkan content provenance sebagai area penting dalam pengelolaan risiko generative AI.

Organisasi bisa memakai principle tersebut tanpa menganggap ada satu format universal yang wajib.

Provenance harus sesuai purpose.

Marketing mungkin perlu source ledger.

Finance mungkin perlu audit trail.

Engineering perlu trace.

Legal perlu versioned document.

AI team perlu prompt/model/tool lineage.

Context menentukan kedalaman.

Public provenance dan internal provenance berbeda

Internal bisa sangat detail.

Data source.

System ID.

Owner.

Transformation.

Reviewer.

Incident.

Public tidak perlu melihat semua.

Untuk pembaca, mungkin cukup:

Source.

Method.

Period.

Last updated.

Reviewer.

Limitation.

Contoh public evidence note:

“Data berasal dari 1.204 respons survey customer yang dikumpulkan April sampai Juni 2026. Analisis kategori open-text menggunakan bantuan AI dan direview tim research. Persentase utama dihitung dari response terstruktur.”

Jelas.

Tidak membanjiri user dengan technical log.

Provenance juga penting untuk AI Search

Brand membuat claim:

“Dipercaya 10.000 bisnis.”

AI mengulang.

Media mengutip.

Agency memasukkan ke case study.

Enam bulan kemudian finance bilang customer aktif sebenarnya 4.800.

Dari mana 10.000?

Ternyata angka tersebut adalah total signup sepanjang sejarah.

Bukan active business.

Claim awal punya provenance yang lemah.

AI hanya memperbesar distribution.

AI trust program harus bertanya:

Claim berasal dari mana?

Definition apa?

Period apa?

Owner siapa?

Source current?

Kalau tidak tahu, jangan optimasi distribution.

Perbaiki evidence dulu.

Knowledge graph tanpa provenance mudah menjadi rumor database

Internal knowledge graph terlihat sophisticated.

Node.

Edge.

Entity.

Relationship.

Tetapi kalau edge “Brand A owned by Company B” tidak punya source, graph hanya menyimpan assertion.

Tambahkan:

Source.

Effective date.

Confidence.

Owner.

Last verified.

Superseded status.

Sekarang graph menjadi evidence-aware.

Ini sangat penting ketika data berubah.

CEO.

Subsidiary.

Partnership.

Product availability.

License.

Semua punya time.

Provenance membuat knowledge graph tidak membekukan dunia.

Provenance juga harus mencatat unknown

Kadang source tidak bisa ditemukan.

Jangan isi.

Status:

Unverified.

Unknown origin.

Legacy record.

Needs review.

Lebih baik daripada membuat source baru demi kelengkapan.

Salah satu bentuk trust adalah berani punya null.

Database yang setiap field penuh belum tentu lebih benar.

Bisa jadi lebih banyak assumption.

Machine-readable provenance tidak otomatis dipercaya machine

W3C PROV menyediakan model dan ontology untuk pertukaran provenance.

Bagus.

Tetapi penggunaan vocabulary tidak membuat claim benar.

Markup bisa berisi data salah.

JSON bisa rapi tetapi provenance palsu.

Structured provenance membantu interoperability.

Truth tetap membutuhkan governance.

Siapa yang boleh menulis?

Apa evidence?

Apa review?

Apakah source legitimate?

Jangan menyamakan machine-readable dengan machine-trusted.

Agentic workflow membuat provenance makin penting

Kalau AI hanya membuat summary, error mungkin berhenti di text.

Kalau agent boleh mengambil action, provenance bisa menjadi input authorization.

Contoh:

Agent menerima invoice.

Siapa issuer?

Data dari email mana?

File asli?

Sudah diverifikasi?

Vendor ID cocok?

Bank account berubah?

Kalau provenance lemah, jangan langsung approve payment.

Source context menjadi bagian dari risk decision.

Begitu AI bergerak dari answer ke action, “dari mana informasi ini?” berubah dari pertanyaan audit menjadi control operasional.

Provenance untuk model output juga perlu boundary

Model bisa menghasilkan reasoning atau summary yang tidak punya source per kalimat.

Tidak realistis memaksa citation setiap kata.

Gunakan material claim approach.

Claim factual yang menjadi dasar keputusan harus traceable.

Opinion atau draft language tidak selalu.

Jika output menyebut angka, legal requirement, product capability, medical fact, security status, atau financial consequence, source requirement naik.

Policy seperti ini lebih usable daripada “semua output harus cited”.

Provenance debt mirip technical debt

Hari pertama, team pakai spreadsheet.

Tidak masalah.

Bulan keenam, ada 200 claim tanpa owner.

Tahun kedua, nobody knows origin.

Itulah provenance debt.

Tanda:

“Angka ini sudah lama dipakai.”

“Kayaknya dari report lama.”

“Dulu agency yang kasih.”

“Data di deck CEO.”

“ChatGPT bilang begitu.”

Semua adalah alarm.

Buat cleanup berdasarkan risk.

Jangan audit semua record.

Mulai dari claim yang dipakai untuk:

Public marketing.

Regulatory.

Financial.

Product.

Security.

AI knowledge base.

High-value sales.

Executive decision.

20 claim penting dengan provenance lengkap lebih berguna daripada 20.000 field yang tidak pernah diverifikasi.

Kapan organisasi harus bisa menjelaskan asal informasi?

Ketika informasi digunakan untuk membuat claim, keputusan, transaksi, atau tindakan yang consequence-nya cukup besar sehingga salah source akan menimbulkan masalah.

Itu threshold yang masuk akal.

Semakin critical use case, semakin kuat provenance.

Data provenance bukan dokumen tambahan untuk compliance.

Ia adalah memory system.

Menjawab:

Ini berasal dari mana.

Siapa yang menyentuh.

Kapan berubah.

Versi apa.

Bagaimana dihitung.

Siapa approve.

Apa limitation.

Di era AI, pertanyaan tersebut bukan semakin tidak penting karena model “pintar”.

Justru semakin penting karena AI membuat informasi bergerak lebih cepat daripada memory manusia.

Kalau organisasi tidak bisa menjelaskan asal sebuah claim, mesin tidak seharusnya diberi authority lebih besar hanya karena outputnya terdengar yakin.

Mulai dari provenance.

Baru bicara trust.

Ada satu use case yang makin penting: provenance untuk training dan evaluation dataset internal.

Organisasi sering membuat dataset dari ticket customer, transcript meeting, CRM note, public website, atau synthetic example. Beberapa bulan kemudian dataset dipakai untuk fine-tuning, evaluation, atau RAG tanpa ada yang ingat origin record.

Ini berisiko.

Buat field:

Dataset source.

Collection purpose.

Consent/legal basis jika relevan.

Data classification.

Preprocessing.

De-identification.

Synthetic versus real.

Reviewer.

Allowed use.

Expiry atau retention.

Sekarang tim model tidak hanya tahu file mana yang tersedia, tetapi apakah file tersebut memang boleh dipakai untuk tujuan tertentu.

Provenance juga membantu ketika organisasi harus menghapus atau mengoreksi data.

Kalau satu source ternyata salah atau tidak boleh digunakan, lineage menunjukkan derivative asset mana yang terdampak.

Tanpa lineage, correction hanya menyentuh source awal sementara copy, embedding, summary, feature, atau report turunannya tetap hidup.

Inilah alasan provenance dekat dengan dependency management.

Satu fakta masuk.

Lalu menyebar.

Governance perlu tahu jalurnya.

AI agent juga bisa membawa provenance ke user experience.

Misalnya internal research agent memberikan answer dan menampilkan:

Source system.

Document date.

Owner.

Confidence status.

Last verified.

User tidak perlu melihat seluruh chain-of-thought model. Mereka hanya perlu enough evidence untuk menilai apakah answer layak dipakai.

Ini distinction penting.

Provenance bukan private reasoning.

Provenance adalah trace terhadap source dan transformation yang memang dapat diaudit.

Kalau organization membangun RAG, provenance sebaiknya melekat pada chunk atau document ID, bukan baru dicari setelah output salah.

Design dari awal.

Lebih murah daripada forensic investigation setelah incident.

Pada akhirnya, provenance yang bagus membuat organisasi bisa melakukan sesuatu yang sederhana tetapi powerful: mengatakan “kami tahu kenapa sistem mengatakan ini.”

Bukan karena model menjelaskan dirinya secara filosofis.

Karena source, version, transformation, dan approval memang tercatat.

Leave a Comment

Your email address will not be published. Required fields are marked *