An AI hallucination is an output that is stated confidently and is false. In enterprise deployments, most hallucinations are not invented from nothing. They are inherited from the data the system was given, where duplicate records, contradictory field values, and unresolved entities hand the model several incompatible versions of the same fact and no basis for choosing between them.

That distinction decides who owns the fix. A model that invents a citation has a model problem. A model that reports three different exposure figures for the same counterparty has a data problem, and no amount of prompt engineering will correct it.

The controls that prevent this are not new. Profiling, data cleansing, entity resolution, and survivorship rules have been available for twenty years and deferred for nearly as long.

AI did not create the problem. It removed the margin that used to hide it.

‍

What Actually Causes AI Hallucinations

Three distinct failure modes get filed under the same word, and only one of them is a defect in the model.

1. Fabrication is the one everybody pictures. The system invents a fact, a case, or a customer that does not exist. It is embarrassing and it is catchable, because a lookup disproves it in seconds.
2. Misgrounding is subtler. The system cites a real source that does not actually support the claim it is attached to. The citation checks out, the reasoning does not, and a busy reader accepts both.
3. The third mode is the enterprise one, and it is the one nobody buys a tool for. The retrieved sources disagree with each other. The model has to pick, it picks, and it does not tell you it picked.

The scale of the problem is easier to accept once you look at what happens under good conditions. Stanford RegLab and HAI researchers ran the first preregistered evaluation of commercial legal AI tools and found that products from LexisNexis and Thomson Reuters hallucinated between 17% and 33% of the time. Those tools retrieve from curated, professionally maintained caselaw.

Enterprise data is not curated caselaw. It was never assembled with a single-answer system in mind, and nobody ever told it that one was coming.

Why Retrieval Does Not Fix This

Retrieval-augmented generation is sold as the answer to hallucination, and the premise is sound: replace the model's hazy memory with your own records. What the pitch leaves out is where the failure surface goes. It moves from the vendor's training corpus into your record layer, which is a place most enterprises have never audited for internal consistency.

Researchers studying this have a name for it. A survey of knowledge conflicts in large language models separates the failure into three types: conflict between the model's memory and the retrieved context, conflict between the retrieved passages themselves, and conflict inside the model's own memory. The middle one, inter-context conflict, is what a duplicate customer record looks like from inside a retriever.

The follow-up work is not reassuring. On a benchmark built specifically to test how models handle contradictory sources, models frequently failed to resolve the conflicts appropriately. Prompting them to reason explicitly about the contradiction improved matters and did not close the gap.

The system does not abstain. It answers.

Which means the accuracy of your assistant is now a function of the referential integrity of your customer master. That is an uncomfortable sentence for most data teams, and it is a true one.

How Data Defects Become AI Failures

The mapping from a familiar data quality defect to an AI failure is direct enough to be predicted in advance, which is what makes it worth auditing before deployment rather than after.

The Duplicate Record Blind Spot

Consider a specialty chemicals manufacturer with 6,200 employees running three ERP systems retained after two acquisitions. The data team stands up a procurement assistant over 2.4 million supplier, contract, and purchase order records covering eleven years.

A category manager asks the assistant what the company spends annually with one of its solvent suppliers. The assistant returns $4.1 million. Procurement's own reconciliation, done by hand over two weeks, puts the figure at $11.3 million.

The model did not hallucinate in any sense the vendor would recognize. It retrieved a supplier record, read the spend attached to it, and reported that number accurately.

The supplier simply existed four times: once per ERP, plus a fourth record created by a typo during vendor onboarding in 2019. Retrieval found one of the four.

Running entity resolution across the same corpus collapsed 2.4 million records into roughly 88,000 distinct supplier entities, a ratio that surprised nobody who had worked in the ERPs and shocked everybody who had not. Validation against a labeled set of 5,000 supplier pairs produced two false positives. The data matching work was not novel.

It had simply never been prioritized, because reporting had tolerated the mess for a decade.

That tolerance is the whole point. A 3% duplicate rate across 2.4 million records is roughly 72,000 contradictions sitting in the corpus.

A dashboard aggregates over them and lands within a few points of the truth. An assistant answering one question about one supplier retrieves exactly one of them.

Reporting is forgiving because it averages. Retrieval is unforgiving because it selects. Most enterprise data was built for the first and is now being handed to the second.

What AI-Ready Data Actually Means

Gartner predicts that organizations will abandon 60% of AI projects through 2026 where those projects are not supported by AI-ready data, and its survey of 248 data management leaders found 63% either did not have or were not sure they had the right data management practices for AI. The number worth sitting with is the second one. Most organizations funding AI cannot say whether their foundation holds.

AI-ready is a higher bar than report-ready in three specific ways, and none of them are about volume.

The first is resolution. Aggregation hides duplicates; retrieval exposes them. Any system that answers a question about a single entity requires that the entity actually be single.

The second is cadence. Governance that runs on a quarterly audit cycle cannot underwrite a system that answers questions every few seconds. Quality has to be enforced where records enter, not reviewed after they accumulate.

That is a different operating model, and it is why entity resolution has moved from a deferred master data project to a precondition for the AI roadmap.

The third is explainability of the record, not just the model. When an answer is wrong, someone has to trace it back to the record that produced it and explain why that record won. If the merge that created the record cannot be reconstructed, the investigation stops there.

Where AI Belongs in Data Quality

There is an obvious objection to everything above. If AI cannot be trusted on messy data, why would anyone trust AI to clean it?

The objection is fair, and the answer is a boundary rather than a reassurance. What matters is not whether AI is involved. What matters is whether the AI is allowed to write values into records.

An AI that edits records directly inherits every problem described in this article and adds a worse one. A value changes, the change is plausible, and nobody can reconstruct the reason. That is silent corruption, and it scales at machine speed.

An AI that proposes configuration does not carry that risk. It reads the data, works out what each column actually holds even when the column is named cust_ref_2, and drafts a cleansing plan or a match definition.

A person reviews the plan, edits it, and approves it. A deterministic engine then executes the approved rules. Every value that changes traces back to a rule a human signed.

That is the line MatchLogic draws through its two engines. MatchCore runs fuzzy and deterministic matching rules that can be read, weighted, and tuned by the people responsible for the result. MatchSense applies pre-trained entity resolution that groups records without requiring anyone to assemble labeled training data, and it reports the attributes and scores behind each grouping.

The cleansing and match definition recommenders sit on the proposal side of that line. They study a dataset, name what each field contains, and return a step-by-step plan with a plain-language reason and a confidence rating attached to every step.

Nothing runs until someone approves it. In air-gapped environments the models run locally, and the recommenders can be switched off entirely without losing the engine underneath.

Two Ways to Use AI Here

The difference between the two patterns is not a matter of degree. They fail differently, they audit differently, and only one of them survives a regulator asking why a record changed.

Compliance Makes This Non-Optional

For regulated industries the argument stops being about accuracy and starts being about exposure. EU AI Act Article 10 requires that training, validation, and testing data for high-risk systems be relevant, sufficiently representative, and to the best extent possible free of errors and complete, with obligations for high-risk systems beginning to apply from August 2026. Credit scoring, employment screening, and biometric identification all sit inside that scope.

Read that requirement as a data engineer rather than a lawyer and it describes a deduplicated, standardized, entity-resolved dataset with documented provenance. It is a data quality mandate wearing regulatory clothing.

The same logic lands harder in healthcare and banking, where the records feeding a model are protected health information or customer financial data. Sending them to a third-party cleaning service to make them AI-ready reintroduces the residency problem the compliance team spent years closing.

On-premise processing keeps the records inside the network, which is the only version of this a HIPAA or SOX control owner will sign. MatchLogic was built on-premise for that reason, and the recommenders run locally when the environment is air-gapped.

Five Steps to AI-Ready Data

None of this requires a new category of tool. It requires doing the unglamorous work in the right order, before the assistant goes live rather than after it embarrasses someone in a QBR.

1. Profile before promising anything. Measure the actual duplicate rate, null rate, and format variance in the systems the AI will read from. Data profiling tools give you the baseline in minutes, and the baseline is usually worse than the sponsor believes.
2. Standardize the fields that matching depends on. Names, addresses, and identifiers carry most of the matching signal, and they carry most of the format chaos. Normalize them before comparison, not during it.
3. Resolve entities and eliminate duplicates. This is the step that removes inter-context conflict from the corpus. Data deduplication at this stage is not a hygiene exercise. It is the difference between one answer and four.
4. Define survivorship explicitly. When two records disagree, something decides which value wins. That decision should be a documented rule with an owner, not an accident of whichever passage the retriever ranked first.
5. Monitor continuously rather than quarterly. New records arrive dirty and existing records decay. A data quality program that runs at reporting cadence cannot support a system that answers questions hourly.

Steps three and four are where most programs stall, because they require somebody to make a decision about which system is authoritative. That decision is political, not technical, and no amount of tooling will make it for you.

Conclusion

The phrase "garbage in, garbage out" was always a little too comfortable, because garbage out is visible. What comes out of a language model reading a dirty database is not visibly garbage. It is fluent, sourced, specific, and wrong, and it arrives with a confidence score that the underlying data has not earned.

The organizations that get value from enterprise AI over the next two years will not be the ones with better prompts. They will be the ones who did the entity resolution work first, while everyone else was still tuning the retriever.

Frequently Asked Questions

Does bad data cause AI hallucinations?

Yes, and in enterprise deployments it is the most common cause. When a system retrieves duplicate or contradictory records for the same entity, the model has to choose between them and typically does so without flagging the conflict. The output is confident, traceable to a real record, and still wrong.

Does retrieval-augmented generation eliminate hallucinations?

No. Stanford RegLab researchers tested commercial legal AI tools built on retrieval and found hallucination rates between 17% and 33%, despite vendor claims of hallucination-free citations. Retrieval reduces fabrication but it cannot repair a corpus that contradicts itself.

What is AI-ready data?

AI-ready data is data that supports a single correct answer about a single entity. In practice that means duplicates resolved, formats standardized, survivorship rules documented, and quality enforced continuously rather than audited quarterly. It is a higher bar than report-ready data, because reporting averages over defects that retrieval exposes.

Why do duplicate records break AI assistants?

Because retrieval selects rather than aggregates. If one customer exists as four records with different addresses and different balances, the assistant retrieves one of the four and answers from it. Researchers call this inter-context conflict, and models resolve it unreliably.

Can you use AI to clean data for AI?

Yes, provided the AI proposes and a human approves. An AI that writes values directly into records creates changes nobody can explain later. An AI that reads the data and drafts a cleansing plan or a match definition, which a person then reviews and approves before a deterministic engine executes it, keeps every change traceable to a rule someone signed.

What does the EU AI Act require about data quality?

Article 10 requires that training, validation, and testing data for high-risk AI systems be relevant, sufficiently representative, and to the best extent possible free of errors and complete, with documented governance over how the data was collected and prepared. Obligations for high-risk systems begin to apply from August 2026.

‍