Master Data Management untuk AI: Mengapa AI Agent Membutuhkan Data Bisnis yang Konsisten?

Perusahaan dapat menggunakan model AI terbaru, membangun AI agent yang mampu melakukan reasoning, dan mengintegrasikannya dengan ERP maupun CRM, tetapi seluruh intelligence tersebut tetap bergantung pada satu hal yang jauh lebih fundamental: apakah sistem mengetahui dengan benar siapa customer yang sedang dibicarakan, produk mana yang dimaksud, supplier mana yang terlibat, dan bagaimana seluruh record tersebut berhubungan satu sama lain. Pertanyaan ini terdengar sederhana, tetapi pada enterprise dengan puluhan aplikasi, beberapa business unit, merger, legacy system, dan bertahun-tahun data historis, satu entitas bisnis sering mempunyai banyak versi yang berbeda. Customer yang sama dapat menggunakan tiga identifier, produk yang sama mempunyai SKU berbeda, supplier tercatat dua kali, sementara nama legal entity pada Finance tidak sama dengan nama account pada CRM.

Masalah tersebut sudah lama menjadi domain Master Data Management atau MDM. Namun kemunculan generative AI dan terutama AI agent membuat konsekuensinya berubah. Sebelumnya data master yang tidak konsisten mungkin menghasilkan dashboard berbeda antar-departemen atau membuat karyawan melakukan reconciliation manual. Ketika AI hanya digunakan untuk membuat summary, konsekuensi data yang salah mungkin berhenti pada jawaban yang tidak akurat. Ketika AI agent mulai diberi kemampuan menggunakan tools dan melakukan action pada ERP, CRM, procurement, customer service, atau system lain, kesalahan identity dan context dapat berubah menjadi kesalahan operasional.

McKinsey pada 2026 menyebut data sebagai salah satu constraint utama ketika perusahaan mencoba membawa AI dari pilot menuju scale. Dalam riset mengenai fondasi agentic AI, McKinsey mencatat hampir dua pertiga enterprise telah bereksperimen dengan agents tetapi kurang dari 10% berhasil melakukan scale dengan tangible value, sementara delapan dari sepuluh perusahaan menyebut keterbatasan data sebagai hambatan terhadap scaling agentic AI. (McKinsey & Company) IBM juga secara eksplisit menempatkan Master Data Management sebagai fondasi untuk menyatukan data lintas silo, membentuk trusted view dari customer, organization, product, atau location, dan menyediakan master data yang konsisten untuk analytics, automation, dan AI. (IBM)

Karena itu problem Master Data Management di era AI tidak lagi hanya dapat dirumuskan sebagai “bagaimana membuat laporan antar-sistem konsisten?”. Pertanyaannya berkembang menjadi:

“Bagaimana memastikan AI melakukan reasoning dan action terhadap business entity yang benar?”

Itulah peran strategis MDM dalam agentic enterprise.

Apa Hubungan Master Data Management dengan AI?

Master Data Management adalah disiplin untuk membuat data mengenai entitas bisnis utama tetap konsisten, terkelola, dan dapat digunakan lintas sistem. Entitas tersebut umumnya mencakup customer, product, supplier, employee, organization, location, chart of account, material, atau entity lain yang digunakan berulang kali pada banyak business processes. IBM menggambarkan MDM sebagai pendekatan untuk menyatukan data lintas silo menjadi single trusted view dengan kemampuan seperti entity resolution, relationship discovery, governance, dan stewardship. (IBM)

Crocodic telah membahas fondasi tersebut secara lebih general pada artikel Master Data Management: Fondasi IT yang Sering Terlewat. Artikel tersebut menjelaskan bagaimana customer, product, atau vendor dapat memiliki record berbeda pada CRM, ERP, warehouse, dan aplikasi lain, sehingga MDM diperlukan untuk memastikan seluruh sistem merujuk pada definisi entitas yang konsisten. Artikel ini sengaja tidak mengulang intent tersebut. Fokusnya adalah konsekuensi berikutnya: apa yang terjadi ketika intelligence layer mulai menggunakan data yang sebelumnya hanya digunakan manusia dan aplikasi deterministic. (Crocodic)

AI membutuhkan data pada beberapa layer. Model dapat menggunakan document dan unstructured knowledge untuk memahami policy, kontrak, email, atau procedure; ia menggunakan operational data untuk mengetahui kondisi transaksi terkini; dan ia membutuhkan master data untuk mengetahui identitas dan hubungan antar-entitas yang sedang dibahas. Master data dengan demikian bukan seluruh data yang dibutuhkan AI, tetapi merupakan salah satu lapisan yang menentukan apakah AI memahami bahwa informasi dari beberapa sistem sebenarnya berbicara mengenai customer, supplier, product, atau organization yang sama.

AI dapat melakukan reasoning terhadap informasi. Master Data Management memastikan reasoning tersebut mempunyai identitas bisnis yang benar.

Distinction ini menjadi semakin penting ketika AI bergerak dari assistant menjadi agent.

Mengapa AI Agent Membuat Masalah Master Data Menjadi Lebih Kritis?

Pada business intelligence tradisional, inkonsistensi data sering menghasilkan dua laporan dengan angka berbeda. Tim kemudian melakukan reconciliation dan mencari sumbernya. Proses tersebut memang tidak efisien, tetapi manusia masih memiliki kesempatan untuk melihat discrepancy sebelum tindakan dilakukan. Pada AI agent, workflow dapat bergerak jauh lebih cepat. Agent mengumpulkan context, memilih tool, melakukan reasoning, dan jika permission mengizinkan dapat menjalankan action dalam satu flow yang hanya berlangsung beberapa detik.

Bayangkan perusahaan memiliki Customer ABC. CRM menyimpannya sebagai PT ABC Indonesia dengan Customer ID CRM-1098. ERP menyimpan ABC Indonesia Tbk dengan ID CUST-4441. Billing platform menggunakan PT ABC Indonesia Tbkdengan ID berbeda, sedangkan customer-service platform hanya mengenalnya melalui email domain. Seorang account manager kemudian meminta AI agent: “Tunjukkan seluruh outstanding invoice Customer ABC, complaint yang belum selesai, dan contract yang akan renewal dalam 60 hari.”

Model dapat memahami objective tersebut dengan sempurna. Problem sebenarnya adalah entity resolution. Jika agent hanya menemukan record CRM dan ERP tetapi gagal memahami relationship dengan billing account, outstanding invoice bisa terlihat lebih kecil dari kondisi aktual. Jika dua customer yang mempunyai nama mirip justru digabung menjadi satu, agent dapat menampilkan informasi perusahaan lain. Jika agent kemudian diperbolehkan membuat collection task atau mengubah account priority, kesalahan data telah berubah menjadi operational action.

McKinsey dalam riset mengenai AI data readiness pada 2026 menekankan bahwa scaling AI membutuhkan structured dan unstructured data untuk menjadi governed, reusable foundation yang dapat diperlakukan sebagai truth sehingga agents dapat bertindak secara bertanggung jawab dan user dapat mempercayai output-nya. (McKinsey & Company) Dalam konteks ini, MDM merupakan salah satu mechanism yang membantu enterprise menentukan truth tersebut pada level business entities.

AI Agent Tidak Hanya Membutuhkan Data yang Akurat, tetapi Entity yang Konsisten

Data quality dan Master Data Management mempunyai hubungan sangat dekat tetapi tidak identik. Sebuah customer record dapat mempunyai alamat yang akurat, nomor telepon benar, dan company name valid. Namun jika customer yang sama mempunyai empat record terpisah pada empat aplikasi, masing-masing record dapat berkualitas tinggi secara individual sementara enterprise tetap tidak mempunyai unified understanding mengenai customer tersebut.

Sebaliknya, perusahaan dapat mempunyai satu customer ID global tetapi beberapa atributnya sudah stale atau salah. Dalam kondisi tersebut entity resolution sudah baik tetapi data quality masih bermasalah. Karena itu enterprise AI membutuhkan keduanya: AI perlu mengetahui entity mana yang benar, lalu perlu mendapatkan atribut yang cukup akurat mengenai entity tersebut.

Crocodic telah membahas quality layer ini pada Data Quality untuk AI: Kenapa Model Bagus Tetap Gagal?. Data quality mencakup dimensi seperti accuracy, completeness, consistency, timeliness, uniqueness, dan validity. MDM mengambil sebagian problem tersebut ke level yang lebih spesifik: bagaimana enterprise mendefinisikan, mencocokkan, mengelola, dan mendistribusikan data mengenai entity inti yang digunakan berulang kali di seluruh proses bisnis. (Crocodic)

Perbedaannya dapat dilihat melalui contoh sederhana.

Perusahaan sebaiknya tidak melihat MDM sebagai pengganti data quality. Keduanya merupakan bagian berbeda dari data foundation yang dibutuhkan enterprise AI.

1. AI Agent Perlu Mengetahui Bahwa Banyak Record Dapat Mewakili Satu Entity

Entity resolution merupakan salah satu capability paling penting dalam hubungan MDM dan AI. Pada organisasi besar, duplicate record bukan exception; ia merupakan konsekuensi natural dari banyak system, merger, acquisition, independent business unit, manual input, perbedaan naming convention, dan berbagai integration yang dibangun pada waktu berbeda.

Satu supplier misalnya dapat tercatat sebagai PT Global Teknologi, Global Teknologi Indonesia, PT. Global Teknologi Indonesia, dan GLOBALTECH-ID. Manusia yang mengenal supplier tersebut mungkin langsung memahami bahwa record itu berhubungan. Software deterministic membutuhkan mapping eksplisit, sedangkan AI mungkin dapat menebak berdasarkan context. Namun enterprise sebaiknya tidak menjadikan kemampuan model menebak sebagai master-data strategy.

MDM menggunakan matching rules, identifiers, stewardship, dan pada modern platform dapat menggunakan machine learning untuk membantu menemukan serta menggabungkan associated records. IBM MDM misalnya menggunakan ML-driven matching untuk membantu menyatukan record yang berkaitan dan menghasilkan unified views terhadap customer, organization, location, dan domain lain. (IBM)

AI agent kemudian tidak perlu menebak apakah PT ABC, ABC Indonesia, dan ABC-ID-019 merupakan entity yang sama pada setiap request. Relationship tersebut sudah disediakan data foundation.

Entity resolution sebaiknya menjadi enterprise capability, bukan reasoning task yang harus ditemukan ulang oleh setiap AI agent.

Jika tidak, setiap agent berpotensi mempunyai versi entity matching sendiri.

2. AI Membutuhkan Golden Record, tetapi Golden Record Bukan Salinan Semua Data

Konsep yang sering digunakan dalam MDM adalah golden record, yaitu representation yang paling dipercaya mengenai satu business entity. Golden record dapat berisi identifier, canonical name, category, relationship, ownership, status, atau critical attributes lain yang perlu digunakan secara konsisten lintas system. Namun golden record bukan berarti seluruh transaksi customer, email, invoice, interaction, dan dokumen harus disalin menjadi satu massive record.

Untuk Customer ABC, golden record dapat menentukan bahwa customer mempunyai global ID CUS-00172, legal name tertentu, tax identity tertentu, dan relationship dengan beberapa subsidiary. CRM tetap menyimpan sales activity. ERP tetap menyimpan invoice. Support platform tetap menyimpan tickets. Contract system tetap menyimpan agreement. Ketika AI agent membutuhkan context, global entity identity tersebut digunakan untuk mengambil informasi yang tepat dari masing-masing source.

Dengan architecture ini MDM berfungsi seperti identity backbone untuk business entities. Ia tidak menggantikan ERP atau CRM. Ia memberikan referensi konsisten agar kedua system dapat berbicara mengenai object bisnis yang sama.

Crocodic sebelumnya menjelaskan beberapa pola MDM seperti registry, consolidation, coexistence, hingga centralized/transactional MDM pada artikel fondasi MDM. Tidak semua enterprise harus langsung memusatkan seluruh master data ke satu platform. Pattern yang digunakan bergantung pada kompleksitas dan kemampuan system existing. (Crocodic)

Untuk AI, yang paling penting adalah agent mempunyai cara authoritative untuk menjawab:

“Entity yang sedang saya proses ini sebenarnya siapa?”

3. Master Data Membantu AI Memahami Relationship, Bukan Hanya Identity

Dalam business operation, satu entity jarang berdiri sendiri. Customer dapat mempunyai parent company, subsidiary, account owner, contract, location, credit account, atau distributor. Supplier dapat menjadi bagian dari corporate group. Product mempunyai category, brand, component, variant, dan material relationship. Employee berada dalam organization hierarchy.

AI agent yang hanya mengetahui ID tetapi tidak memahami relationship dapat menghasilkan analysis yang incomplete.

Misalnya seorang CFO bertanya:

“Berapa total exposure kita terhadap Group ABC?”

ERP mungkin mempunyai enam customer accounts terpisah karena masing-masing subsidiary mempunyai billing entity sendiri. Jika AI menjumlahkan hanya account bernama ABC Holding, jawabannya salah secara business context. Agent perlu memahami bahwa beberapa legal entities merupakan bagian dari corporate group yang sama.

IBM menempatkan relationship discovery sebagai salah satu capability MDM untuk membangun connected views antar-entitas. (IBM) Hal ini sangat relevan terhadap AI karena natural-language query manusia sering mengacu pada business relationship, bukan database structure.

User tidak bertanya:

“Jumlahkan invoice customer ID 100, 103, 982, dan 1121.”

User bertanya:

“Berapa exposure Group ABC?”

MDM membantu bridge antara bahasa bisnis tersebut dan data architecture di bawahnya.

4. Product Master yang Tidak Konsisten Dapat Membuat AI Mengambil Keputusan Inventory yang Salah

Customer merupakan contoh paling mudah dipahami, tetapi product dan material master dapat mempunyai konsekuensi yang bahkan lebih langsung terhadap operasi. Product yang sama dapat mempunyai kode berbeda antar-plant, warehouse, ecommerce, sales system, atau legacy ERP. Unit of measure juga dapat berbeda: satu application menghitung box, system lain menghitung piece, sementara procurement menggunakan carton.

Jika AI agent diminta mencari inventory atau membuat procurement recommendation tanpa konsistensi tersebut, problem dapat muncul meskipun setiap system memberikan data yang technically correct. Agent mungkin melihat 100 unit pada Warehouse A dan 50 box pada Warehouse B tetapi tidak memahami conversion relationship. Product dengan kode lama dapat dianggap berbeda dari kode baru, sehingga company terlihat mengalami shortage padahal stock sebenarnya tersedia.

Dalam context AI seperti ini, MDM tidak hanya mengelola nama product. Ia membantu memastikan identifier, unit, hierarchy, category, lifecycle status, dan relationship penting dapat dipahami secara konsisten.

Masalah ini menunjukkan alasan enterprise sebaiknya tidak memberikan AI instruction sederhana seperti:

“Gabungkan saja data dari semua sistem.”

Menggabungkan data tanpa semantic consistency hanya membuat inconsistency tersedia lebih cepat.

AI tidak menghilangkan data silo jika setiap silo tetap mempunyai definisi berbeda terhadap object bisnis yang sama. AI hanya membuat perbedaan tersebut lebih mudah dikonsumsi—dan dalam beberapa kasus lebih mudah disebarkan.

5. Vendor Master yang Buruk Dapat Mengubah Procurement Agent Menjadi Risk

Procurement merupakan use case agentic AI yang menjanjikan karena banyak pekerjaan melibatkan quotation, policy, supplier history, price comparison, inventory, dan contract. Namun procurement juga menunjukkan kenapa master data sangat penting.

Agent dapat menerima request:

“Cari supplier terbaik untuk material X berdasarkan price, delivery performance, dan historical transaction.”

Jika satu vendor mempunyai beberapa records, historical spending dapat terpecah. Supplier yang sebenarnya mempunyai nilai pembelian Rp10 miliar dapat terlihat hanya Rp3 miliar karena transaction tersebar pada beberapa vendor IDs. Delivery history juga dapat terpisah. Satu record mungkin menunjukkan bank account lama sementara record lain menggunakan account baru.

Masalah ini tidak dapat diselesaikan hanya dengan model yang lebih kuat.

AI membutuhkan supplier identity yang konsisten dan relationship yang dapat dipercaya. Bahkan ketika final decision tetap berada pada Procurement Manager, recommendation yang dibangun di atas fragmented master data akan menghasilkan comparison yang bias.

Karena itu MDM untuk AI tidak boleh dipandang hanya sebagai project analytics. Saat AI mulai masuk ke operational workflows, master-data accuracy menjadi bagian dari business control.

6. AI Agent Membutuhkan Master Data dan Operational Data Secara Bersamaan

Satu misconception yang perlu dihindari adalah menganggap golden record cukup untuk menjawab seluruh pertanyaan AI. MDM mengetahui siapa customer dan bagaimana relationship-nya, tetapi tidak selalu mengetahui invoice terbaru, current stock, atau shipment yang sedang berjalan. Informasi tersebut adalah operational state yang seharusnya tetap diambil dari system of record.

Contohnya, customer master mengatakan Customer ABC aktif dan memiliki global ID tertentu. Ketika agent diminta mengetahui outstanding invoice, agent menggunakan global ID tersebut untuk memanggil ERP dan mengambil current transaction. Ketika agent diminta melihat complaint, identifier yang sama digunakan untuk mencari ticket pada customer service platform.

Architecture sehatnya bukan:

Semua data → MDM → AI

tetapi lebih dekat kepada:

Master Identity → MDM

Operational State → ERP / CRM / WMS / Application

Knowledge → Documents / Knowledge Platform

kemudian:

AI Agent → menyatukan ketiganya pada waktu dibutuhkan.

MDM memberikan identity consistency. Operational systems memberikan current state. Knowledge systems memberikan semantic context.

Ketiga layer tersebut mempunyai responsibility berbeda.

7. RAG Tidak Menggantikan Master Data Management

Retrieval-Augmented Generation atau RAG memungkinkan model mengambil informasi dari enterprise knowledge source sebelum memberikan jawaban. Ini sangat efektif untuk policy, manuals, contracts, reports, procedure, atau dokumen perusahaan. Namun RAG bukan replacement untuk MDM.

Vector database dapat menemukan dokumen yang secara semantic relevan terhadap “Customer ABC”, tetapi tidak otomatis mempunyai authority untuk menentukan apakah ABC Indonesia, ABC Holdings, dan PT ABC adalah entity yang sama atau berbeda. Model dapat mencoba menyimpulkan hubungan tersebut dari text, tetapi relationship yang mempunyai business consequence sebaiknya tidak bergantung hanya pada semantic similarity.

AWS menjelaskan bahwa generative AI enterprise sering perlu menggunakan structured maupun unstructured data, dan fragmented data sources serta inconsistent governance menjadi challenge ketika company membawa use case menuju production. AWS juga menekankan pentingnya quality, access control, ownership, dan governance sepanjang AI data workflow. (Amazon Web Services, Inc.)

Karena itu enterprise AI architecture dapat membutuhkan keduanya:

RAG untuk menemukan knowledge yang relevan.

MDM untuk menentukan identity dan master relationship yang authoritative.

Mencampur dua responsibility tersebut dapat membuat AI architecture sulit dikendalikan.

8. AI Tidak Boleh Menentukan Sendiri Source of Truth

Large language model sangat baik menggabungkan context dari beberapa source, tetapi kemampuan tersebut tidak berarti model seharusnya menentukan source mana yang lebih authoritative berdasarkan reasoning sendiri.

Misalnya CRM mengatakan alamat customer di Jakarta, sedangkan ERP mengatakan Surabaya. Model dapat memilih salah satu berdasarkan recency atau context, tetapi mungkin terdapat business reason mengapa kedua alamat tersebut berbeda: satu merupakan billing address, satu shipping address.

Resolution rule perlu berada pada data governance dan MDM, bukan improvisasi model.

Enterprise harus menentukan apakah customer legal identity dikelola MDM, billing detail berasal ERP, contact detail berasal CRM, atau product data dimiliki Product Information Management. Ketika conflict muncul, stewardship process menentukan rule untuk resolving data.

Inilah hubungan erat antara Master Data Management dan Data Governance. Crocodic telah membahas distinction tersebut dalam Data Governance vs Master Data Management: Apa Bedanya?. Data Governance menentukan ownership, policy, definition, dan authority; MDM menjadi salah satu capability untuk menerapkan aturan tersebut terhadap master entities. (Crocodic)

AI boleh menggunakan data dari banyak sumber. AI tidak seharusnya menciptakan aturan sendiri mengenai sumber mana yang menjadi kebenaran perusahaan.

Crocodic Perspective: AI Context Integrity

Pada traditional AI discussion, perhatian besar diberikan kepada model accuracy. Untuk enterprise agent, Crocodic melihat satu layer tambahan yang sama pentingnya: context integrity. Sebuah jawaban dapat memiliki reasoning yang masuk akal tetapi tetap salah jika identity, relationship, state, atau policy yang menjadi context-nya keliru.

Crocodic dapat menggambarkan AI Context Integrity melalui enam layer:

Entity Identity → Golden Record → Business Relationship → Operational State → Policy Context → Agent Action

Entity Identity menjawab siapa atau apa object yang sedang diproses. Golden Record memastikan critical attributes konsisten. Business Relationship memberikan context mengenai parent company, supplier relationship, product hierarchy, atau organization structure. Operational State mengambil transaksi terkini dari system of record. Policy Context menentukan constraint dan authority. Agent Action baru dilakukan setelah lima layer sebelumnya cukup reliable.

Framework ini menunjukkan bahwa AI agent tidak seharusnya melompat langsung dari natural-language request menuju action.

AI agent yang reliable bukan hanya agent yang mampu memilih action dengan benar. Ia harus memilih action terhadap entity yang benar, berdasarkan state yang benar, dalam policy context yang benar.

Dalam banyak enterprise, MDM membantu menyelesaikan dua layer pertama sekaligus memperkuat relationship layer.

MDM Bukan Hanya “Single Source of Truth”

Istilah single source of truth sering digunakan terlalu sederhana, seolah enterprise cukup membuat satu database besar lalu semua problem selesai. Pada kenyataannya, MDM dapat menggunakan beberapa architecture pattern. Registry MDM dapat mempertahankan source systems sambil membuat mapping entity. Consolidation dapat membentuk trusted view secara berkala. Coexistence memungkinkan master hub dan source systems saling menyinkronkan data. Centralized atau transactional MDM menempatkan master system sebagai creation dan distribution point utama.

Tidak ada satu architecture yang selalu paling benar. Organization dengan puluhan legacy applications mungkin lebih realistis memulai dari registry atau consolidation daripada memaksa seluruh systems menerima centralized master sekaligus. Perusahaan baru dengan architecture lebih sederhana mungkin dapat menerapkan centralized model lebih cepat.

Untuk AI, objective pertama bukan harus memusatkan semua data. Objective yang lebih fundamental adalah membuat intelligence layer memiliki consistent entity reference.

Dengan kata lain:

Physical centralization tidak selalu prerequisite. Semantic consistency jauh lebih penting.

Kapan AI Membutuhkan Real-Time Master Data?

Tidak semua master data berubah dengan frekuensi tinggi. Legal company name, product category, supplier relationship, atau organization hierarchy dapat relatif stabil. Namun beberapa attribute seperti customer risk category, vendor eligibility, product lifecycle status, atau account ownership dapat berubah lebih sering dan memengaruhi keputusan agent.

Karena itu latency requirement harus mengikuti use case.

AI yang membuat monthly market segmentation mungkin cukup menggunakan master snapshot harian. Procurement agent yang mengevaluasi supplier sebelum purchase request mungkin perlu memastikan supplier status masih valid pada saat action. Customer-service agent dapat membutuhkan customer entitlement yang sangat aktual sebelum menawarkan replacement.

Prinsipnya sama dengan operational data:

data tidak hanya harus benar; data harus cukup aktual untuk consequence dari decision.

Article Crocodic mengenai data quality juga menempatkan timeliness sebagai salah satu dimensi penting karena informasi yang akurat tetapi terlambat masih dapat menghasilkan keputusan yang salah. (Crocodic)

MDM architecture perlu menentukan attribute mana yang dapat disinkronkan batch dan attribute mana yang perlu event-driven atau near-real-time.

Data Governance, MDM, Data Quality, dan AI Governance Memiliki Scope Berbeda

Ketika enterprise mulai membangun AI, banyak istilah governance dapat terdengar tumpang tindih. Padahal masing-masing mempunyai responsibility berbeda.

Enterprise tidak perlu membangun semuanya sekaligus untuk satu pilot sederhana. Namun semakin besar authority yang diberikan kepada AI, semakin banyak layer tersebut mulai saling bergantung.

Inilah alasan AI readiness perlu dinilai dari foundation secara keseluruhan. Artikel AI Readiness Assessment untuk Enterprise menempatkan data readiness bersama system & integration, security & governance, operation, business readiness, dan economics sebagai dependency untuk membawa AI dari experiment menuju production. (Crocodic)

Architecture MDM untuk AI Agent

Secara konseptual, architecture dapat dibangun seperti berikut:

Source Systems
CRM • ERP • WMS • Procurement • Billing • HRIS
↓
MDM / Entity Resolution Layer
Global ID • Matching • Golden Record • Relationship
↓
Enterprise Integration / Tool Layer
Controlled API • Permission • Validation
↓
AI Orchestration
Context • Tool Selection • Workflow
↓
AI Agent / Model
Reasoning • Recommendation • Action
↓
Human / Business System

Hal yang penting adalah direction of responsibility. MDM tidak perlu mengambil alih transaction systems. AI tidak perlu mengambil alih MDM. Integration layer tidak menentukan business meaning. Setiap component mempunyai boundary.

McKinsey pada 2026 mendorong enterprise untuk membangun shared, governed, dan reusable data foundations agar agentic systems dapat menggunakan data dengan lebih konsisten dalam skala besar. (McKinsey & Company) Architecture di atas menerjemahkan prinsip tersebut pada salah satu domain paling fundamental: master entities.

MDM Menjadi Lebih Penting Ketika Banyak AI Agent Digunakan

Satu AI agent dapat saja mempunyai custom logic untuk menggabungkan record tertentu. Namun ketika organization mulai mempunyai Procurement Agent, Finance Agent, Customer Service Agent, Sales Agent, dan Operations Agent, membiarkan setiap agent mempunyai entity resolution sendiri akan menciptakan inconsistency baru.

Procurement Agent dapat menganggap dua vendor sebagai satu entity.

Finance Agent menganggapnya dua.

Sales Agent menggunakan customer grouping berbeda.

Executive Agent kemudian menggabungkan semua output tersebut.

Enterprise akhirnya menciptakan AI data silo, hanya dalam bentuk baru.

Central master-data capability mengurangi risiko tersebut karena identity dan relationship dapat digunakan ulang oleh banyak agents. Sama seperti API layer membuat business capability reusable, MDM membuat business identity reusable.

Semakin banyak AI agent yang digunakan perusahaan, semakin sedikit alasan membiarkan setiap agent mendefinisikan customer, product, supplier, atau organization secara independen.

Ini merupakan salah satu alasan authority MDM justru dapat meningkat pada agentic era, bukan berkurang karena model semakin pintar.

Apakah AI Dapat Membantu Master Data Management?

Hubungan AI dan MDM bersifat dua arah. MDM memberikan data yang lebih konsisten untuk AI, sementara AI dan machine learning juga dapat membantu MDM melakukan entity matching, anomaly detection, classification, enrichment, atau memberikan recommendation terhadap potential duplicates.

IBM misalnya menggunakan machine learning pada MDM untuk membantu matching records dan relationship discovery. (IBM) IBM juga mulai membahas agentic data management, yaitu penggunaan agents untuk membantu mengelola dan mengorkestrasi pekerjaan data dengan tingkat automation yang lebih tinggi. (IBM)

Namun final business authority tetap perlu dibedakan berdasarkan risk. AI dapat menyarankan bahwa dua supplier records kemungkinan duplicate, tetapi merge dapat membutuhkan data steward apabila consequence-nya besar. AI dapat menemukan product naming anomaly, tetapi Product Owner mungkin tetap menjadi pihak yang menentukan canonical representation.

Dengan demikian:

AI can assist MDM.

Tetapi:

MDM governance tetap menentukan business truth.

Jangan Menggunakan AI untuk Menutupi Master Data yang Buruk

Salah satu temptation terbesar adalah menganggap modern models cukup pintar untuk mengerti messy data. Dalam beberapa kasus memang benar: LLM dapat mengenali bahwa PT. ABC, ABC Indonesia, dan P.T. ABC Indonesia mungkin berkaitan. Namun capability tersebut seharusnya digunakan untuk membantu remediation, bukan menjadi alasan mempertahankan fragmentation secara permanen.

Jika setiap request membutuhkan AI melakukan entity matching dari awal, hasil dapat berubah berdasarkan context dan model version. Cost inference bertambah. Latency bertambah. Auditability turun. Dan agent yang berbeda dapat menghasilkan keputusan matching berbeda.

Master data yang terstruktur mengubah problem tersebut menjadi deterministic enterprise capability.

Gunakan AI untuk membantu menemukan inkonsistensi data, bukan menjadikan kemampuan AI menebak sebagai pengganti konsistensi data.

Ini distinction yang penting agar enterprise tidak membangun technical debt baru atas nama AI flexibility.

Kapan Enterprise Perlu Memprioritaskan MDM Sebelum Memperluas AI?

Tidak setiap company membutuhkan enterprise MDM platform sebelum menggunakan AI. Internal assistant yang hanya membaca employee handbook mungkin tidak membutuhkan customer golden record. Use case harus menjadi starting point.

Namun MDM mulai menjadi priority ketika AI harus menggabungkan entity dari beberapa operational systems, customer atau product mempunyai banyak identifiers, reporting sudah mengalami duplicate/conflict, workflow memerlukan entity-level action, beberapa business unit mempunyai master masing-masing, atau organization berencana menggunakan banyak agents terhadap domain yang sama.

Beberapa signal yang cukup kuat antara lain:

Jika hanya satu use case sederhana dengan satu system of record, MDM mungkin terlalu besar sebagai prerequisite. Jika AI harus bekerja lintas banyak systems dan menghasilkan action, investment pada master-data foundation menjadi jauh lebih masuk akal.

Crocodic MDM-for-AI Readiness Framework

Untuk assessment awal, enterprise dapat mengevaluasi lima area.

1. Entity Consistency

Apakah customer, product, supplier, employee, dan entity penting mempunyai identifier yang dapat dipetakan lintas system?

2. Source Authority

Apakah perusahaan mengetahui system atau owner mana yang menentukan canonical attributes?

3. Relationship Integrity

Apakah parent-child, product hierarchy, customer group, supplier relation, atau organization structure tersedia secara cukup reliable?

4. Distribution & Accessibility

Apakah master data dapat digunakan ERP, CRM, analytics, API, dan AI melalui interface yang terkontrol?

5. Stewardship & Monitoring

Apakah duplicate, conflict, merge, lifecycle change, dan exception mempunyai owner serta process?

Scoring sederhana dapat digunakan:

Nilai rendah tidak otomatis berarti seluruh AI project harus dihentikan. Enterprise dapat membatasi use case ke data domain yang reliable sambil memperbaiki foundation secara bertahap.

KPI MDM untuk AI Sebaiknya Tidak Hanya Mengukur Duplicate Record

MDM traditional sering diukur melalui duplicate reduction, completeness, atau number of golden records. Untuk AI, perusahaan dapat menambahkan metric yang lebih dekat terhadap quality of context dan business workflow.

Metric terakhir sangat penting. Untuk AI assistant, wrong entity mungkin menghasilkan jawaban salah. Untuk agent dengan action authority, wrong-entity action harus diperlakukan sebagai failure class tersendiri.

Roadmap Membangun Master Data Foundation untuk AI

Enterprise tidak perlu memulai dengan seluruh domain sekaligus. Pendekatan yang lebih sehat adalah mengikuti use case. Jika priority AI berada pada customer service, mulailah dari customer domain. Jika procurement agent menjadi target utama, supplier dan product/material dapat lebih penting. Jika AI digunakan untuk workforce operation, employee dan organization master mungkin menjadi domain pertama.

Tahap pertama adalah menentukan critical entity dan source yang saat ini menggunakannya. Setelah itu identifikasi duplicates, identifier conflict, naming difference, ownership, dan relationship. Organization kemudian menentukan matching rule, canonical attributes, dan global identifier. Setelah golden record cukup stabil, capability tersebut perlu dibuat consumable oleh aplikasi dan AI melalui integration interface. Stewardship dan monitoring kemudian memastikan kualitas tidak kembali menurun ketika data baru terus masuk.

Roadmap sederhananya:

Use Case → Critical Entity → Source Inventory → Matching → Golden Record → Governance → Distribution → AI Integration → Monitoring

Urutan tersebut lebih realistis daripada membuat program “bersihkan semua data perusahaan sebelum AI”. Data modernization harus mengikuti business value.

MDM Tidak Perlu Menjadi Project Terpisah dari System Modernization

Dalam banyak enterprise, master-data problem sebenarnya berasal dari architecture system. Customer harus diketik ulang karena aplikasi tidak terintegrasi. Product master mempunyai duplicate karena setiap department mempunyai aplikasi sendiri. Vendor data berbeda karena procurement dan finance memiliki database yang tidak sinkron.

Dalam kondisi seperti itu, MDM tidak seharusnya menjadi project cleansing yang berdiri sendiri. Ia perlu menjadi bagian dari system integration dan modernization.

Artikel MDM Crocodic sebelumnya memang menempatkan master-data foundation sebagai salah satu prerequisite agar integration sistem dan AI dapat berkembang lebih mudah. (Crocodic) Jika data tersebar pada aplikasi existing yang masih mempunyai business value, pendekatan Enterprise System Upgrade Crocodic dapat digunakan untuk memperkuat API, integration, workflow, dan data foundation tanpa harus mengganti seluruh core system sekaligus.

Prinsipnya adalah memperbaiki flow dan ownership, bukan sekadar memindahkan duplicate data ke database baru.

Master Data Management Akan Menjadi Bagian dari Agentic Infrastructure

AI agent membuat user experience enterprise terlihat semakin sederhana. Seorang manager dapat bertanya dengan natural language tanpa mengetahui database, application, atau report apa yang harus dibuka. Tetapi semakin sederhana interface di atasnya, semakin disiplin infrastructure di bawahnya harus bekerja.

McKinsey menggambarkan kondisi ini dengan cukup jelas: AI dapat membuat enterprise data terlihat deceptively simple karena contract berubah menjadi summary, transcript menjadi recommended action, dan policy menjadi answer; tetapi di belakang interface tersebut system terus mengambil, menggabungkan, dan menafsirkan data lintas documents, systems, prompts, dan workflows. (McKinsey & Company)

MDM adalah salah satu mechanism yang menjaga simplification tersebut tidak mengorbankan business meaning.

Agent dapat mengatakan:

“Customer ABC mempunyai outstanding invoice Rp2 miliar.”

Namun sebelum kalimat tersebut dapat dipercaya, infrastructure harus mengetahui siapa Customer ABC, account mana yang termasuk group tersebut, currency apa yang digunakan, system mana yang memiliki invoice, dan state transaksi mana yang dianggap outstanding.

Interface semakin sederhana.

Foundation justru harus semakin jelas.

Crocodic Perspective: AI Does Not Need More Data, It Needs Reliable Business Context

Diskusi enterprise AI sering dimulai dari jumlah data. Perusahaan merasa perlu menghubungkan lebih banyak documents, databases, applications, dan data lakes agar AI menjadi semakin pintar. Tetapi volume bukan satu-satunya constraint. AI yang mendapatkan seratus sumber dengan identity dan meaning yang bertentangan dapat menghasilkan context yang lebih buruk daripada AI yang menggunakan lima source dengan ownership yang jelas.

Karena itu Crocodic menggunakan prinsip:

AI tidak selalu membutuhkan lebih banyak data. AI membutuhkan business context yang cukup, konsisten, aktual, dan authoritative untuk keputusan yang sedang dibuat.

Master Data Management berperan khusus pada bagian consistent dan authoritative entity context tersebut. Data Quality menjaga reliability attributes. Operational system menjaga current state. Governance menjaga ownership. Integration membuat capability dapat digunakan. AI kemudian melakukan reasoning di atas foundation tersebut.

Pemisahan ini penting agar perusahaan tidak memperlakukan model sebagai alat yang akan memperbaiki seluruh kekacauan data secara otomatis.

Dari Master Data Management Menuju Trusted AI Action

AI assistant dapat memberikan jawaban berdasarkan enterprise data. AI agent membawa konsep tersebut satu langkah lebih jauh karena hasil reasoning dapat berubah menjadi action. Perubahan inilah yang membuat MDM semakin strategis.

Jika customer identity salah, assistant memberi informasi yang salah.

Jika customer identity salah dan agent membuat action, perusahaan mungkin menghubungi customer yang salah, memberikan discount pada account yang salah, membuka collection case yang salah, atau membuat transaction menggunakan supplier yang salah.

Dengan kata lain:

Semakin dekat AI dengan business action, semakin mahal konsekuensi dari master data yang tidak konsisten.

Perusahaan tidak harus menyelesaikan seluruh Master Data Management sebelum bereksperimen dengan AI, tetapi MDM seharusnya menjadi bagian dari roadmap ketika use case mulai lintas-sistem, menggunakan business entity yang sama berulang kali, atau memberikan AI authority terhadap operational workflow.

Fondasi dapat dimulai dari satu domain yang paling penting, satu golden record, ownership yang jelas, dan interface yang dapat digunakan ulang. Dari sana organization dapat memperluas capability berdasarkan kebutuhan.

Crocodic telah membahas fondasi umum melalui Master Data Management: Fondasi IT yang Sering Terlewat, hubungan rule dan ownership pada Data Governance vs Master Data Management, serta requirement kualitas data pada Data Quality untuk AI. Ketiganya membentuk foundation sebelum enterprise memperluas AI ke workflow dengan authority yang lebih tinggi. (Crocodic)

AI model akan terus berubah. Agent framework akan berkembang. Protocol integration dapat berganti. Namun customer, product, supplier, organization, dan business relationships tetap menjadi object yang digunakan perusahaan untuk menjalankan keputusan.

Jika enterprise tidak dapat menjelaskan secara konsisten siapa customer-nya, produk apa yang dimiliki, supplier mana yang digunakan, dan bagaimana seluruh entity tersebut berhubungan, memberikan AI kemampuan reasoning yang lebih tinggi tidak menghilangkan problem tersebut. AI hanya akan mengambil keputusan lebih cepat di atas business context yang belum dapat dipercaya.

Master Data Management untuk AI pada akhirnya bukan project untuk membuat database terlihat lebih rapi. Ia adalah upaya memastikan bahwa ketika AI mulai memahami, merekomendasikan, dan pada akhirnya bertindak terhadap bisnis, AI selalu mengetahui entity bisnis mana yang sebenarnya sedang ia proses.