Last week, we looked at master data automation that makes sense: the kind that reduces repeat work without removing control. Match and merge logic, data quality checks, and stewardship workflows can all benefit from automation when the rules are clear and the process is well understood. The point was not to automate everything. It was to automate the work that is repetitive, measurable, and safe enough to standardize.

This week, we move into the next layer of that conversation: AI in master data. AI can help with some of the same pain points, but it works differently than traditional automation. Instead of only following fixed rules, it can suggest likely matches, classify records, and enrich missing context from patterns in the data. That makes it useful, but also easy to overstate. Before we talk about risks and guardrails next week, we need to start with where AI actually helps.

The Role of AI in Master Data (Part 1)

The first AI demo usually looks cleaner than the real data.

The sample customer records match neatly, the product categories make sense, and the enrichment suggestions look useful. Then the team loads actual source data from CRM, ERP, supplier feeds, old conversion tables, and spreadsheets someone forgot were still part of the process.

Names are shortened, IDs disagree, and product descriptions mix marketing copy with unit values. Supplier records carry one legal name, one payment name, and three versions of the same address.

AI can still help, but it cannot turn a messy master data program into a clean one by itself.

Start there. AI is becoming useful in master data, but its best role is not replacing MDM. Its best role is helping teams move faster through work that already depends on patterns, similarity, and repeated judgment.

In most MDM programs, the useful AI work starts in three places: matching records, classifying them, and filling in missing context. Those map to entity resolution, classification, and enrichment.

The control questions come later. First, it helps to understand where AI earns its keep.

AI Belongs Inside the MDM Lifecycle

A normal MDM process already has a path. Source data arrives, fields get profiled and cleaned, and records move through standardization, matching, merging, classification, enrichment, review, and publication.

Sometimes that path runs in batches. Sometimes it supports APIs or event-driven updates. Most large environments use both patterns somewhere.

AI works best when it sits inside that lifecycle as another controlled step, with inputs, outputs, thresholds, review rules, and owners.

Trouble starts when teams treat AI like a separate intelligence layer floating above the MDM hub. The output may look impressive, but the decisions become harder to explain. A steward cannot tell why two records matched. A consuming system cannot tell whether a field came from the source, an enrichment provider, or a model suggestion. A business owner cannot tell which rule changed the record.

That design creates a trust problem before the program even scales.

A match model can suggest likely duplicates, a classification model can point to the right taxonomy node, and an enrichment process can fill missing values from trusted sources. Low-confidence cases go to stewards, while approved and rejected decisions flow back into the process.

Most teams discover the real limits after the first pilot. The sample looked good because the sample had structure. Production data usually behaves differently.

One system stores legal names, another stores display names, and a third has abbreviations created years ago to fit a field limit. Address fields are split in one application and free-form in another. Product descriptions include units in one feed, marketing copy in another, and supplier shorthand in a third.

Those records are still workable, but only when the model has enough structure to understand what it is comparing.

Entity Resolution Usually Shows the Value First

The duplicate problem rarely starts as a duplicate problem.

It shows up as two customer counts, two supplier spend totals, or a sales report that finance refuses to use. By the time someone traces the issue back, it is usually buried in identity logic.

Entity resolution is the work of deciding whether multiple records refer to the same real-world entity. That entity might be a customer, supplier, product, employee, asset, location, provider, or organization. In master data, this is often where the value starts, because fragmented identity breaks almost everything downstream.

Take a customer record.

One source has “Acme Federal Services.” Another has “ACME Fed Svcs.” A third has “Acme FSI.” The address is close, but not exact. One record has a billing contact and another has the tax ID. The CRM record carries the sales region, while the ERP record carries payment terms.

An exact-match rule misses the relationship, but a loose fuzzy rule may pull in the wrong company. Someone creates an Excel fix for this month’s report, and the workaround quietly becomes part of the process.

AI-assisted entity resolution can compare several signals at once. Names, addresses, identifiers, phone numbers, domains, relationships, and transaction context can all influence a match score. The model is not just asking whether two names are equal. It is asking whether the full pattern looks like the same entity.

Rules still matter. They move closer to standardization, blocking, thresholds, survivorship, and review routing. AI adds learned similarity and can catch patterns that would be painful to write by hand.

A rules-only system might need dozens of hand-built patterns for abbreviations, punctuation, company suffixes, swapped address lines, or supplier naming habits. AI can learn many of those patterns from examples, especially when steward decisions are captured and reused.

Useful, yes, but still dependent on clean inputs and review paths.

A hospital system gives a different example. Credentialing may store one provider record, scheduling may store another, and claims may store a third. The NPI matches, but the practice location does not. The right match depends on what the hub is mastering: the person, the location, or the provider-location relationship.

AI needs the model design to carry that distinction. If the domain is unclear, the match score becomes a false comfort.

Candidate generation also matters. Comparing every record to every other record does not scale, so the system still needs blocking, indexing, or another way to reduce the comparison space. When that early step misses a real match, the downstream model never gets a chance to score it.

Vendor language needs careful reading here. “AI matching” can mean learned pair scoring, AI-generated rule suggestions, steward assist features, or probabilistic scoring with a better interface.

Ask practical questions:

• How are candidate matches generated?
• Which fields influence the score?
• Can stewards see why two records matched?
• Can thresholds differ by domain or source?
• Can approved and rejected matches improve future scoring?
• What happens when a source changes its format?

Those answers matter more than the feature name.

Classification Is Where Business Meaning Gets Applied

A product may arrive as “BX 100 stainless machine screw, 10mm.” Another supplier may list a similar item as “M10 SS screw box.” A third may bury the useful detail in a PDF or a long description field.

The classification decision depends on how your taxonomy works. Is the hierarchy based on usage, material, size, merchandising, regulatory handling, or some mix of those? Different teams may answer that question differently.

In MDM, classification carries business rules.

Classification can affect pricing, search, reporting, tax treatment, fulfillment, risk review, routing, and analytics. A customer type can change the service path. A supplier category can trigger onboarding steps. A product class can decide where the record rolls up and who owns it.

A clear taxonomy gives the model something useful to learn from.

A model can suggest a product category based on title, description, attributes, images, prior mappings, and similar records. It can also help classify suppliers by industry, customers by segment, assets by type, or locations by service area.

Manual classification gets repetitive fast, and it also gets inconsistent. Two stewards can classify similar records in different ways, especially when the taxonomy has overlapping categories.

I’ve seen product classification pilots work well on common SKUs and fall apart on specialty items. The model was not the only issue. The taxonomy had three categories that meant almost the same thing, and the business had never decided when each one should be used.

AI learns that ambiguity rather than cleaning it up on its own.

The safest classification projects start narrow. Pick one domain, one taxonomy, and one high-value classification problem. Then measure the output against steward decisions and downstream use.

“Classify every master record in the enterprise” usually becomes a large backlog before it becomes a working plan.

The business stakes also matter. A product in the wrong class may roll up to the wrong category manager. A customer in the wrong segment may enter the wrong service queue. A supplier in the wrong risk group may skip a review it should have had.

Classification looks like a data problem. In MDM, it is often a business rule problem with data attached.

Enrichment Can Help, But More Fields Do Not Always Mean Better Data

The supplier profile looked better after enrichment. Every key field was populated, the industry code was filled in, and the parent company was linked. Then procurement asked a simple question: which values were verified, and which ones were inferred?

A record can look better simply because more fields are filled in. That does not mean the record is more trusted.

A supplier record may start with a legal name, tax ID, and payment address. The enrichment feed may add an industry code, a global parent, a website, and a risk flag. Procurement still needs to know which of those values came from a trusted source and which ones were inferred.

A product record may start with a vendor SKU and a description like “M10 SS screw box.” The model may extract size, material, package quantity, and unit of measure, but the product team still has to decide whether “SS” is safe to normalize as stainless steel.

With the right boundaries, the model can read messy descriptions, compare trusted sources, infer likely attributes, and normalize values into the expected format.

The difference usually comes down to scope.

Extracting product attributes from a known set of supplier feeds is a better starting point than asking AI to enrich every product field across every domain. Standardizing business names from trusted external data is safer than letting a model fill unknown company facts. Suggesting an industry code from a governed taxonomy is cleaner than generating free text that no downstream system can use.

A supplier enrichment feed may add the global parent company. Procurement may still need the local operating entity for contracts. Finance may care about the remittance name. Sales may care about the brand name. All of those values can be valid, but they do different jobs.

A consuming system should be able to tell whether a value came from the source, a steward, an enrichment provider, a model suggestion, or a survivorship rule. Without that trace, enriched data can look complete while hiding the fact that some fields are inferred, some are verified, and some are stale.

Part 2 will deal with the risk side of that issue. For now, keep the rule simple: enriched values need labels, sources, and confidence.

The Work Around the Model Decides Whether AI Scales

Teams tend to focus on the model, but trust usually depends on the workflow around it.

Most AI-assisted MDM work starts before the model scores anything. Someone has to decide which fields are reliable enough to compare, which values need cleanup, and which records should never be promoted without review.

After that, the model can suggest likely duplicates, likely categories, or likely enrichment values. Confidence rules decide what moves forward and what lands in a steward queue.

A rejected match, corrected category, or overridden enrichment value should teach the process something, but too often those decisions disappear into tickets, comments, or one-off spreadsheet fixes. Next month, the same bad suggestion comes back.

A working pattern usually looks like this in plain terms: profile the data, standardize the fields, generate the suggestion, score confidence, review the uncertain cases, apply the decision, and capture the feedback.

The phrase sounds simple until the team has to replay a batch, explain a score, or unwind a bad merge.

AI-assisted MDM still needs repeatable pipelines, error handling, idempotent processing, monitoring, versioning, and quality checks. If an enrichment job fails halfway through, the team needs to know what was processed. If a match model changes, someone needs to know which entities changed because of it. If a classification rule is updated, downstream systems need a stable way to absorb the change.

This is the part people underestimate. If stewards have no context, they guess. If their decisions are not captured, the model does not improve. If downstream systems cannot see confidence or lineage, they build workarounds.

A strong MDM team asks operational questions early:

• How do we replay a batch safely?
• How do we avoid duplicate updates?
• How do we track model-driven changes?
• How do we expose confidence to stewards?
• How do downstream systems know a value was enriched?

AI Needs a Master Data Foundation First

AI works better when the master data environment has enough structure to learn from and enough governance to control the result.

That does not require perfect data. Perfect data is not real. It does require fields that mean the same thing from one load to the next, source rules that reflect trust, and metadata that explains where values came from.

A model needs to know what each field means before it can compare or classify records well. Source rules add another layer, since CRM, ERP, supplier portals, and legacy conversion tables rarely deserve equal trust. Metadata gives the decision trail: where the value came from, how it changed, and who should rely on it.

Steward feedback carries more weight than many teams expect.

If a steward rejects a match, that decision should not disappear into a ticket comment. It should become training signal, threshold evidence, or policy input. If reviewers keep correcting the same product category, the taxonomy may be unclear, the source feed may be weak, or the model may need tuning.

Null handling deserves attention too. A missing tax ID does not mean the same thing as a known supplier with no tax ID requirement. A blank address line may be harmless in one country and serious in another. AI will not automatically understand those business differences unless the data model carries that meaning.

Earlier MDM work pays off here. Clear definitions, good reference data, documented survivorship rules, stable identifiers, and field-level policies all make AI more useful.

Weak foundations turn AI into another place for hidden logic to collect.

You can get away with that for a while. Then a migration, audit, report, or integration exposes it.

Some MDM Problems Fit AI Better Than Others

The easiest mistake is to aim AI at the loudest MDM complaint.

That does not always work. A noisy duplicate problem may be a good fit, while a fight over customer ownership is not. One is a pattern problem, while the other is a decision-rights problem.

AI is strongest when the work depends on repeated pattern recognition across messy fields. Duplicate customer detection, product classification, supplier enrichment, and attribute extraction are good examples. These tasks have patterns, outcomes to measure, and review paths.

Authority problems behave differently because they are not pattern problems.

If sales and finance disagree about the customer hierarchy, AI can show the conflict. It cannot decide whose hierarchy should drive billing, quota planning, or executive reporting. If no one owns the supplier domain, AI cannot create accountability. If the business has never defined what a product family means, AI will not settle the argument.

MDM problem	AI fit	Reason
Duplicate customer or supplier records	High	AI can compare messy identity signals across fields.
Product taxonomy assignment	High	AI can learn from descriptions, attributes, and prior labels.
Attribute extraction from product text	High	AI can identify values hidden in unstructured descriptions.
Supplier enrichment from trusted sources	Medium to high	Works well when source trust and lineage are clear.
Survivorship suggestions	Medium	AI can assist, but business rules still decide.
Ownership conflicts	Low	This is a governance issue.
Business definition disputes	Low	AI can surface disagreement, not resolve decision rights.

For most teams, the safer starting point is familiar: match the records, classify the records, enrich the records. Leave authority disputes to governance.

Start With One Painful Workflow

A good pilot does not need to prove that AI can solve every MDM problem. It needs to prove that AI can improve one painful workflow without making the process harder to trust.

Pick one domain first. Customer, supplier, product, or location. Then pick one problem inside that domain.

Duplicate detection is often the easiest place to start because the pain is visible. Product classification is also a strong candidate when taxonomy rules are clear. Enrichment works well when the team already knows which internal or external sources are trusted.

Measure the process before and after the pilot.

Model accuracy matters, but it is not enough. Track duplicate reduction, match rejects, steward review volume, auto-classification rate, enrichment fill rate, reruns, downstream defects, and rework. The goal is not to prove that the model scored well in isolation. The goal is to see whether MDM got better.

I’ve seen teams trust an AI match score too early because the first few hundred records looked clean. The trouble showed up in the edge cases: regional abbreviations, inherited customer IDs, old supplier names, and values shortened to fit legacy fields.

A team may find that the model is accurate, but the review queue is too large. Another may find that classification works well for common products but fails on specialty items. A supplier enrichment pilot may fill more fields while exposing weak lineage.

Evidence like that helps the team decide whether to expand, tune, narrow, or stop.

Stopping is allowed because some AI use cases are not worth scaling.

A practical pilot plan can stay simple:

1. Choose one domain and one use case.
2. Profile the source data.
3. Define the fields that influence the decision.
4. Set confidence bands for approve, review, and reject.
5. Capture steward feedback in a structured way.
6. Track quality and process metrics.
7. Decide whether to expand, tune, or stop.

The pilot should leave the team with more than a demo. It should leave behind better rules, better feedback, and a clearer sense of where AI belongs.

AI Makes MDM Faster, Not Easier

AI can help MDM teams move faster through work that tends to pile up: likely duplicates, unclear categories, missing attributes, and repetitive review queues. For teams buried in manual review, that gain is real.

It does not remove the work around definitions, source trust, stewardship, or governance. Those decisions still belong to people who understand the business process and the consequences of getting it wrong.

The practical pattern is less dramatic: let AI narrow the review burden, let rules enforce known policy, let stewards handle judgment, and let governance decide authority.

That is enough for Part 1. Next week, we’ll look at the guardrails.