Your AI Is Only as Good as Your Master Data

Why duplicate customers, inconsistent product codes, and stale prices quietly break enterprise AI

A sales manager asks the new AI assistant a simple question:

"Which of my customers haven't ordered anything in the last 90 days?"

The answer comes back in a few seconds. It is well written, nicely formatted, and wrong.

Three of the customers on the list ordered last week. They just ordered under a different customer record. One was created by the field team, one came from the e-commerce integration, and one was opened by finance when the customer changed its billing address.

The model didn't hallucinate. It read the data correctly.

The data was the problem.

This is a hypothetical example, but anyone who has worked on ERP or CRM integrations will recognize it immediately.

When I started building mobile sales applications connected to ERP systems, the mobile screen was rarely the hard part. The hard part was making sure the customer was correct, the product was correct, and the price was correct. That hasn't changed.

What has changed is that AI makes bad master data much more convincing.

AI Doesn't Fix Data. It Narrates It.

In an earlier article, I wrote that data ownership is part of the AI architecture, not administrative housekeeping. This article goes one level deeper, into the data that almost every enterprise workflow depends on: master data.

Master data is the shared reference information that the rest of the business is built on:

• Customers and their locations
• Products, units, and variants
• Price lists and discount rules
• Employees, territories, and sales representatives
• Suppliers, warehouses, and cost centers

Transactions change every minute. Master data changes slowly. But every transaction points to it.

Traditional software has always suffered from bad master data. A report showed a duplicate customer twice. An integration failed because a product code didn't exist. Someone noticed, complained, and fixed it.

AI changes the failure mode.

A report with duplicates looks like a report with duplicates. An AI answer built on duplicates looks like an insight.

The model takes inconsistent data and turns it into fluent, confident language. It summarizes, explains, and recommends. The errors don't disappear. They become harder to see.

Where Bad Master Data Breaks AI

The problems are rarely dramatic. They are small inconsistencies that every enterprise has, and that AI quietly amplifies:

Notice that none of these are AI problems.

They are data problems that existed long before the model. The difference is that a human user often knew the workarounds. They knew that "ACME Ltd." and "Acme Limited" were the same company. They knew that the old price list was still in the system but no longer used.

The model doesn't know any of this.

Unless the system tells it.

Retrieval Can't Fix What Identity Breaks

A common reaction is to give the model more context. Put the customer records, orders, and notes into a retrieval system, and let the model figure it out.

That works for text. It doesn't work well for identity.

Semantic search is good at finding things that are similar. Master data problems are usually about things that are the same but don't look the same, or look the same but aren't.

"Acme Ltd., Istanbul" and "ACME Limited Şti., İstanbul" are probably one customer. "Acme Ltd., Istanbul" and "Acme Ltd., Izmir" may be two branches of one customer, or two unrelated companies with similar names.

A vector similarity score can't make that decision reliably. And it shouldn't.

Whether two records represent the same customer is a business decision with consequences: credit limits, payment terms, sales commissions, and legal entities all depend on it.

This leads to a simple rule:

The model can suggest that two records might be the same. The system decides whether they are. 

AI can be very useful in finding likely duplicates, inconsistent names, and suspicious records. But the result should feed a matching and review process, not silently rewrite customer identity at query time.

Make the Source of Truth Explicit

Most enterprise data problems become worse when multiple systems hold the same information and nobody has decided which one wins.

The CRM has one address. The ERP has another. The e-commerce platform has a third. The AI assistant can access all three.

Which one should it use?

If the answer is "whichever the retrieval step happens to return first", the system is not making a decision. It is making a random choice and presenting it as a fact.

Before connecting AI to enterprise data, it helps to write down a few things explicitly:

• Which system is authoritative for each entity and field? Customer legal name from ERP, contact person from CRM, delivery address from the logistics system.
• What is the stable identifier? A customer code, a tax number, or a global ID that all systems share.
• How fresh must the data be? A product description can be a day old. A stock level or a price usually cannot.
• What happens when systems disagree? Prefer one source, flag the conflict, or ask a person.

This sounds like old-fashioned data governance. It is.

The difference is that the AI system makes it visible. Every unanswered question about ownership eventually appears as an inconsistent answer in front of a user.

Give the Model Clean Context, Not Raw Tables

Even with good master data, the way it reaches the model matters.

Many AI implementations pass raw records into the prompt: database rows, internal codes, abbreviations, and fields that only the original developers understood.

The model will try to interpret them. Sometimes it will be right.

A more reliable approach is to prepare the context:

Source systems ↓ Identity resolution (which records belong together) ↓ Source-of-truth rules (which value wins) ↓ Business view (clean, named, current fields) ↓ Model 

In practice, this means:

• Resolve identity before retrieval. Give the model one customer, not three partial records.
• Use business names, not internal codes. "Payment terms: 60 days" is clearer than "PT_CD: 060".
• Include freshness. "Price list valid from 1 November" tells the model and the user what they are looking at.
• Separate facts from notes. Structured fields are facts. Free-text notes are context and should be labeled as such.
• Let the model say "unknown". If a value is missing or conflicting, say so in the context instead of hiding it.

This is not prompt engineering. It is data modeling.

And it is usually the part of the system that improves answer quality the most.

Use AI to Improve the Data, Carefully

There is a positive side to this story.

AI is genuinely useful for master data work that has always been tedious:

• Finding likely duplicates across systems
• Normalizing company names, addresses, and units
• Extracting structured attributes from product descriptions
• Classifying products or customers into categories
• Spotting records that look inconsistent with their history

These are exactly the ambiguous, language-heavy tasks where models create leverage.

But the same principle from earlier articles still applies: a recommendation is not an authorization.

Merging two customer records, changing a product hierarchy, or updating a price list affects invoices, reports, commissions, and integrations. These changes should go through validation and, where the impact is high, human review. The model can prepare the change. The system and its owners decide.

The strongest argument against all of this

There is a fair objection.

Data is never perfect. If every company waited for clean master data before using AI, nobody would ever start. And sometimes an AI project is exactly what finally forces the business to fix its data.

That is true.

The answer is not to wait for perfect data. It is to be honest about which use cases can tolerate imperfect data and which cannot.

Summarizing support conversations can work with messy customer data. Recommending credit limits cannot. Drafting a sales email can tolerate a duplicate customer. Calculating commissions cannot.

Start where the data is good enough. Use the AI project to expose the gaps. Fix the data that the next use case depends on.

That is a much better plan than hoping the model will be smart enough to work around the problems.

A Practical Checklist

Before connecting an AI feature to enterprise data, it is worth asking:

• Which master data entities does this use case depend on?
• Is there a stable identifier for each of them across systems?
• Have we decided which system is authoritative for each important field?
• Do we know how many duplicates we have, roughly?
• Are prices, discounts, and hierarchies current, and does the context show their validity date?
• Does the model receive resolved business entities, or raw records from several systems?
• Are free-text notes clearly separated from structured facts?
• Can the model say a value is unknown or conflicting?
• Do AI-suggested data changes go through validation and review?
• Which use cases can tolerate imperfect data, and which cannot?

If most of the answers are unclear, the first AI project might need to be a data project.

Conclusion

For years, bad master data was an annoyance. It made reports harder to trust and integrations harder to maintain, but people learned to work around it.

AI removes the people who knew the workarounds from the middle of the process.

It reads every record literally, combines information from systems that disagree, and presents the result as a clear answer. When the data is good, that is powerful. When the data is inconsistent, it is dangerous precisely because it sounds right.

The model is not the foundation of an enterprise AI system.

The data is.

And in most companies, the most important data isn't in documents or knowledge bases. It is in the customer, product, and price records that every transaction depends on.

Before asking what the model can do with your data, ask whether your data can tell the truth.