MDM #4. Self-Healing Master Data — What AI Can Fix Automatically and What Still Needs Human Review
“Self-healing master data” sounds as if an AI system can detect a bad record, understand what went wrong, repair it and continue operating without human involvement.
Some parts of that vision are already technically possible.
Others are not.
A system can automatically reject an invalid country code.
It can standardize an address using trusted reference data.
It can derive a value from an approved rule.
It can identify anomalous records, recommend data-quality rules and surface suspected duplicates.
But should it automatically merge two major suppliers because an AI model believes they are the same company?
Should it change a product classification when two business units disagree about the correct taxonomy?
Should an AI system decide which customer record becomes authoritative when the evidence conflicts?
Those are different types of decisions.
Self-healing master data should not mean “AI fixes everything automatically.” A more useful definition is a controlled data-quality loop that detects problems, determines what can be corrected safely, executes approved actions and learns from the outcome.
This distinction matters because automation can reduce repetitive stewardship work — but an incorrect automated correction can also spread faster than a manual error.
The objective should therefore be controlled autonomy, not maximum autonomy.
Self-healing is better understood as an operating loop
There is no single universally accepted enterprise-MDM standard called “Self-Healing Master Data.”
The term is more useful as an architectural and operating concept.
I would describe the loop in five stages:
Each stage answers a different question.
| Stage | Question | Typical capability |
|---|---|---|
| Detect | What is wrong or unusual? | Validation rules, profiling, anomaly detection, duplicate detection and monitoring |
| Diagnose | Why did it happen and what else may be affected? | Source analysis, lineage, rule context, relationship analysis and recurring-pattern detection |
| Decide | Can the system act safely? | Policy evaluation, evidence scoring, risk classification and human escalation |
| Correct | What action should be taken? | Validation, derivation, standardization, enrichment, correction, routing or governed merge |
| Learn | How do we reduce recurrence? | Steward feedback, rule improvement, threshold tuning and root-cause remediation |
The value of this model is that automation can stop at any stage.
A system may detect and diagnose a problem automatically but still require a steward to approve the correction.
That is not a failure of self-healing.
It is good control design.
Much of the foundation already exists in enterprise MDM
The underlying capabilities are not entirely new.
SAP Master Data Governance already supports validation rules, derivation scenarios, data-quality KPIs, monitoring and remediation processes.
SAP also supports machine-learning-based rule mining that can analyze master data and suggest new validation rules for assessment.
SAP Help Portal — Working with MDG, Data Quality Management
This is an important point.
AI does not have to replace established quality controls.
It can extend them.
For deterministic problems, business rules remain extremely effective.
For ambiguous or previously unseen patterns, AI can provide additional detection, recommendation and contextual analysis.
The strongest design is usually not rules versus AI. It is rules plus AI, with each used where it is strongest.
The easiest problems to heal are the ones with an authoritative answer
Consider an address.
If a user enters a postal address in an inconsistent format, trusted reference data may provide the correct standardized representation.
SAP MDG supports address enrichment through Data Quality Management services that can validate and correct addresses using reference data and format them according to country-specific conventions.
SAP Help Portal — Address Enrichment
This is a strong candidate for automated correction because:
- the problem can be detected reliably,
- an authoritative or trusted reference exists,
- the target value can be explained,
- the action is usually reversible, and
- the business meaning is not being redefined.
Compare that with a different problem:
An AI model may provide useful evidence.
It should not automatically assume that the correct action is to merge the suppliers.
The technical similarity is only one part of the business decision.
A useful rule: automate corrections, not ambiguity
I would classify quality issues according to the strength of available evidence and the consequence of a wrong action.
| Issue | Typical treatment | Why |
|---|---|---|
| Invalid reference code | Reject or replace using an approved mapping | Authoritative reference set exists |
| Formatting inconsistency | Automatic standardization | Transformation is deterministic and reversible |
| Derivable value | Automatic derivation | Approved business rule determines the value |
| Likely duplicate | Recommend, then apply domain-specific policy | False merges can be more harmful than missed duplicates |
| Conflicting authoritative values | Human review | The system cannot infer legitimate business authority from similarity alone |
| Policy or taxonomy disagreement | Business decision | The issue concerns meaning and governance, not data correction |
This gives us a more useful definition of “auto-healable.”
A problem is not auto-healable simply because AI can generate a proposed answer. It is auto-healable when the organization has enough evidence and control to let the system act safely.
AI is becoming more useful in the detection and recommendation layers
One of the clearest changes in modern data quality is the use of AI to reduce the work required to create and operate quality rules.
Informatica's current Data Quality and Observability offering includes AI-assisted profiling, anomaly detection, rule generation, cleansing, standardization and validation. Its CLAIRE Data Quality Agent is designed to help automate data-quality activities.
Informatica — Data Quality & Observability
In its Spring 2026 release, Informatica also described the generally available CLAIRE Data Quality Agent as allowing users to describe quality expectations in natural language and generate the corresponding rule logic.
Informatica — IDMC Spring 2026 Data Quality and MDM Capabilities
This is where generative AI is useful without being given uncontrolled authority.
A business user might describe a requirement such as:
An AI assistant can help turn that intent into rule logic.
But the business owner should still determine whether the requirement itself is correct.
Generating the rule and approving the policy are two different actions.
The most important stage is not correction — it is recurrence prevention
Imagine that the same missing attribute appears every week.
An automated process fills it every week.
The quality dashboard looks excellent because every error is repaired quickly.
But the process creating the bad record has not changed.
Is that self-healing?
Technically, the system is recovering.
Operationally, it may be hiding a broken upstream process.
I would therefore separate two concepts:
| Type | Meaning |
|---|---|
| Record healing | Correct the current defective record. |
| Process healing | Remove or reduce the cause that keeps producing the defect. |
For example:
Record healing: Add a missing country code from an authoritative address service.
Process healing: Modify the onboarding process so new records cannot be submitted without a valid country assignment.
The second delivers more durable improvement.
AI can help identify recurring patterns, but business and process owners still have to change the process when the cause is organizational.
The blast radius should affect the automation policy
Not every master-data change has the same consequence.
Correcting capitalization in a descriptive field is different from merging two customer identities.
Changing a supplier payment-related attribute is different from standardizing a postal code.
I would therefore consider at least five factors before allowing automatic correction.
| Factor | Question |
|---|---|
| Evidence strength | Do we have an authoritative source, deterministic rule or only probabilistic evidence? |
| Business impact | What happens if the correction is wrong? |
| Propagation | How many systems and processes consume the value? |
| Reversibility | Can the original state be restored reliably? |
| Accountability | Who owns the policy allowing the automated decision? |
The result should not simply be a confidence percentage.
It should be a policy decision.
A safer decision model for automated correction
I would divide actions into four operating bands.
| Decision band | System behavior | Typical condition |
|---|---|---|
| Auto-correct | Apply correction and retain audit history | Authoritative evidence, low impact and reversible change |
| Correct & notify | Apply approved low-risk correction and inform steward | Strong evidence but operational visibility is still useful |
| Recommend | Prepare proposed correction and evidence for review | Ambiguity, moderate impact or entity-resolution judgment |
| Human decision | AI assists with analysis only | High impact, conflicting authority, policy change or non-reversible action |
This four-band model is a Digital Future & Strategy practitioner framework. It is not a vendor standard or universal automation threshold.
Notice that no fixed percentage appears in the model.
A 95% model confidence score does not necessarily justify a merge.
Confidence estimates, business impact and quality of evidence are separate concepts.
Self-healing needs a memory of what it changed
An automated correction without traceability creates a governance problem.
For every material change, I would want to retain at least:
- the original value,
- the corrected value,
- the issue that triggered the action,
- the rule, model or evidence used,
- the automation policy applied,
- the identity of the system or agent that executed the change,
- the time of the action,
- whether a human reviewed or overrode it, and
- whether the change was later reversed.
This record is useful for more than audit.
It creates the feedback data needed to determine whether automation is actually improving.
If stewards repeatedly reverse one type of automated correction, the system should not continue making the same decision indefinitely.
A self-healing system that cannot learn from human overrides is only automated correction.
Rollback is not optional
The more autonomous the correction, the more important reversibility becomes.
This is particularly true for:
- entity merges,
- hierarchy changes,
- mass updates,
- reference-data replacements, and
- changes propagated to multiple downstream systems.
A safe design should be able to answer:
What was the state before the automated action?
Which systems received the changed value?
Can the action be reversed without creating another inconsistency?
If rollback is difficult or impossible, the approval threshold should become correspondingly stricter.
Domain context changes what “safe” means
The same automation policy should not be applied equally to every master-data domain.
Consider these examples.
Product and material data
Automatic formatting, unit normalization and approved reference-code derivation may be good candidates for automation.
Changing an engineering classification or deciding that two components are interchangeable is a different decision and may require domain expertise.
Customer data
Standardizing addresses and contact formatting may be relatively controlled.
Automatically merging identities can have privacy, service and analytical consequences and deserves stricter evidence requirements.
Supplier data
Address enrichment or standardized country information may be appropriate for automated correction when trusted reference data exists.
Changes involving legal identity, corporate ownership, payment attributes or compliance status require a different control level.
The automation boundary should follow business risk, not the availability of an AI feature.
A phased rollout: earn autonomy rather than assume it
I would not begin a self-healing initiative with automatic corrections.
I would begin with observation.
| Stage | Operating mode | What must be proven |
|---|---|---|
| 1. Observe | Detection and classification only | Do we understand what errors actually occur? |
| 2. Recommend | AI or rules propose corrections; humans approve | Are recommendations consistently useful and explainable? |
| 3. Automate low risk | Approved deterministic cases execute automatically | Do monitoring, audit and rollback work reliably? |
| 4. Expand selectively | Additional cases move into governed automation | Does evidence justify expanding autonomy? |
There is no universal number of months for each stage.
Progression should be based on exit criteria.
Useful criteria include:
- accuracy by error category,
- human override rate,
- wrong-correction severity,
- rollback success,
- quality of audit evidence,
- stability across countries and source systems, and
- business-owner approval.
This is safer than deciding in advance that an organization will reach a specific automation percentage by a specific date.
Do not measure success only by how many corrections AI performs
An automation program can look impressive while the underlying data process remains poor.
Suppose the system automatically fixes 100,000 errors per month.
Is that success?
Maybe.
Or it may mean the enterprise is producing 100,000 preventable errors every month.
I would monitor three layers of performance.
| Layer | Example measures |
|---|---|
| Detection quality | Issues detected, false alarms, missed issues and emerging anomaly patterns |
| Correction quality | Accepted recommendations, overrides, reversals and correction errors |
| Prevention | Recurrence rate, source-process improvement and decline in repeated error categories |
The third layer is especially important.
A mature self-healing capability should eventually reduce the need to heal the same problem repeatedly.
Where the Data Steward fits
Self-healing does not make the Data Steward irrelevant.
It changes the distribution of work.
Routine checking and deterministic correction can increasingly move toward automated processes.
The steward becomes more important for:
- ambiguous entity decisions,
- policy exceptions,
- automation oversight,
- root-cause analysis,
- rule approval,
- quality-risk prioritization, and
- business interpretation.
This connects directly to the previous article in this series on the Data Steward Agent.
The stronger model is not:
It is:
My practical takeaway
Self-healing master data is becoming more realistic because several previously separate capabilities are converging.
Enterprise platforms can monitor data quality continuously.
Rules can detect invalid states.
Reference data can validate and enrich records.
AI can generate rule recommendations, identify anomalies and assist stewardship.
Entity-resolution models can identify likely duplicates.
Workflow can route ambiguous decisions to the right owner.
But the ability to generate a correction does not automatically justify executing it.
I would use four principles:
1. Automate where the evidence is authoritative.
2. Escalate where the business meaning is ambiguous.
3. Preserve audit and rollback for every material automated action.
4. Fix recurring causes, not only recurring records.
The long-term goal should not be autonomous correction for its own sake.
The strongest self-healing system is not the one that makes the most automatic changes. It is the one that prevents bad data from spreading, makes safe corrections quickly, explains what it did and learns when human judgment says it was wrong.
That is a more realistic path from traditional data-quality management toward Agentic Data Management.
Sources & Further Reading
- SAP Help Portal — Working with MDG, Data Quality Management
- SAP Help Portal — Address Enrichment
- SAP Help Portal — Master Data Governance
- Informatica — Data Quality & Observability
- Informatica — IDMC Spring 2026 Data Quality and MDM Capabilities
“Self-Healing Master Data” is used in this article as a practitioner operating concept rather than a universal MDM product category or industry standard. The five-stage healing loop, four automation bands and rollout model are Digital Future & Strategy frameworks. Automation policies should be calibrated to each organization's evidence quality, business impact, regulatory requirements, reversibility and governance model.
Reviewed: September 2026
Global MDM Strategy Series
Part 1 — AI & Agentic MDM
MDM #3. The Core of Agentic Data Management: The Role and Future of the Data Steward Agent
MDM #4. Self-Healing Master Data — What AI Can Fix Automatically and What Still Needs Human Review
MDM #5. Knowledge Graph-Based Entity Resolution — Beyond Fuzzy Matching for Enterprise MDM
Previous: The Core of Agentic Data Management: The Role and Future of the Data Steward Agent
Next: Knowledge Graph-Based Entity Resolution — Beyond Fuzzy Matching for Enterprise MDM
Comments
Post a Comment