What is data intelligence?
Data intelligence makes enterprise data understandable to machines, alongside analysts. It captures meaning, relationships, freshness, and permitted use, right alongside the data itself. The practical test is whether a system that has never seen your business could act on that data correctly, without a person interpreting it first.
Most organizations already know where their data is. They have a warehouse or a lakehouse, a catalog listing the tables, and pipelines keeping them fed. What they generally do not have is a written answer to what any of it means, because until recently the person reading the data supplied that themselves.
That is the gap data intelligence fills. It is the layer of understanding on top of stored data: not the bytes, and not the inventory of where the bytes live, but the meaning attached to them.
Metadata tells you the mechanics. Semantics tell you the meaning
This distinction is the whole subject, and it is easiest to see in one field. Suppose a table has a column called cust_rev_ttm.
- Metadata tells you it is a decimal, refreshed nightly at 02:00, sourced from the billing system, and queried by fourteen dashboards. All true, all useful, and none of it tells you what the number is.
- Semantics tell you it means trailing-twelve-month customer revenue, net of returns, excluding intercompany transactions, denominated in reporting currency, and that it is deliberately not comparable to the field called revenue in the CRM.
An analyst who has worked there three years knows the second paragraph without being told. They carry it, undocumented, and they apply it every time they use the field. A system has access only to what was written down. Data intelligence is the discipline of writing down what the analyst knows, in a form a system can act on.
A note on the term itself
Data intelligence is used in two related but distinct ways, and it is worth separating them. As a general capability it means what is described above. As a product category, Data Intelligence Platform is a term introduced by Databricks to describe platforms that use AI models to understand the semantics of enterprise data, built on a lakehouse foundation; Collibra and others also market platforms under the same name. This entry describes the capability. When a specific platform is meant, the vendor name belongs in front of it.
How is data intelligence different from a data catalog or data governance?
A catalog records where data is. Governance records who is accountable for it. Data intelligence records what it means and whether a system can rely on it. The three overlap in tooling and answer different questions, and most enterprises need all of them.
These terms are used interchangeably in vendor material, which is expensive during evaluation because two products described in the same language may solve different problems. The distinctions below are drawn by the question each one answers.
| Term | What it establishes, and the question it answers |
|---|---|
| Data intelligence | The meaning, relationships, reliability, and permitted use of data, expressed so a system can act on it. Could something that has never seen our business use this correctly? |
| Data catalog | An inventory of data assets, where they live, and their technical description. Where is the data, and what is in it? |
| Data governance | Ownership, policy, and controls over data assets. Who is accountable for this, and what are the rules? |
| Metadata management | The technical and operational facts: schemas, types, refresh schedules, usage. What are the mechanics of this dataset? |
| Business intelligence | Analysis and reporting for human decision-makers. What happened, and why? |
| Data observability | Monitoring of pipeline and data health, including freshness, volume, and schema drift. Did the data arrive correctly today? |
| Master data management | One authoritative record per core entity such as customer, product, or supplier. Which of these records is the real one? |
Two relationships are worth holding onto. Data intelligence depends on the others rather than replacing them: it needs the catalog to know what exists, governance to know who decides, observability to know whether today's copy is sound, and master data management to know that one customer is one customer. And business intelligence is the closest historical relative, which is why the shift is easy to underestimate. Both are about understanding data. They differ in who is doing the understanding, and that changes what has to be written down.
Why do AI agents raise the bar on data?
An analyst resolves ambiguity from experience, notices numbers that look wrong, and inspects a handful of results. An agent has none of that. It carries only what was documented, applies it at scale without supervision, and may act on a wrong premise before anyone reviews the output.
This is the reason data intelligence has moved from a data-office concern to an AI programme dependency. The data did not get worse. The consumer changed.
| Difference | An analyst using the data | An agent using the data | The consequence |
|---|---|---|---|
| Ambiguity | Resolves it from experience, or asks a colleague | Has no colleague to ask, and proceeds anyway | A wrong answer arrives with full confidence |
| Context | Carries years of knowledge nobody wrote down | Carries only what was written down | Undocumented knowledge becomes a defect |
| Scale | Inspects a few results before acting on them | Processes thousands, unattended | One bad definition propagates everywhere |
| Errors | Notices when a number looks implausible | Has no intuition for what looks wrong | Detection has to move earlier, into the data |
| Access | Sees what their own login permits | Sees what its service identity inherited | Over-broad access becomes invisible |
| Recovery | Re-runs the query and moves on | May already have taken an action | Correcting the answer is no longer enough |
The last row is the one that changes the economics. When an analyst misreads a field the cost is a wrong slide. When an agent misreads the same field it may have already issued a credit, sent a notice, or closed a case. That is why data intelligence stops being a documentation exercise and becomes a control: an agent acting on stale definitions or unresolved entities is operating outside its intended scope, which is a governance problem before it is a data problem. See AI governance.
What makes data AI-ready?
Six requirements decide whether data is usable by an agent: resolved semantics, entity resolution, certified quality with declared freshness, traceable lineage, machine-readable access policy, and a change contract. Failing any one of the six means the agent acts on a wrong premise rather than failing visibly.
The phrase "AI-ready data" is used widely and rarely defined, which makes it hard to assess whether a dataset qualifies. The six below are stated as a gate on purpose. They are cumulative rather than a maturity scale, because a dataset that satisfies five of them still produces confidently wrong output.
- 01
Resolved semanticsWhat each field means in business terms, stated unambiguously, including what it excludes and what it is not comparable to. Without it: the agent guesses, and a guess about a definition is indistinguishable from an answer.
- 02
Entity resolutionOne customer, product, or supplier is one thing across every system that references it. Without it: the same entity is counted several times, and totals are wrong in a direction nobody notices.
- 03
Certified quality and declared freshnessQuality is measured and then stated, and the data carries how current it is. Without it: the agent cannot tell whether to trust today's copy, so it treats stale data as authoritative.
- 04
Traceable lineageWhere the data came from and what transformed it on the way. Without it: a wrong output cannot be traced to a source, so the same error recurs after being corrected downstream.
- 05
Machine-readable access policyWho and what may use each field, expressed so a system enforces it rather than so a person reads it. Without it: permissions depend on whatever identity the agent inherited, which is rarely the intended one.
- 06
A change contractA stated agreement on what may change in a dataset, and with what notice. Without it: a schema or definition change breaks downstream agents silently, and the failure surfaces as bad answers rather than as an error.
Requirement six is the one most overlooked, and the toughest to add in after the fact. When something small changes, a human reading the data usually notices and adjusts. An agent doesn't. If a definition it was relying on changes quietly, the agent keeps producing output as usual, except now that output is wrong in a way that looks perfectly normal. This is exactly why data contracts exist, and why they matter so much once the one consuming the data is a machine, not a person.
How do you build data intelligence?
Build it in six steps: connect and profile what exists, resolve semantics rather than only schema, resolve entities, certify quality and declare freshness, express access policy machine-readably, then hold the change contract. Start with the data one specific use case needs rather than the whole estate.
The order follows the dependencies. Semantics cannot be resolved for data nobody has profiled, and a policy cannot be enforced on entities that have not been reconciled.
-
Connect and profile what you actually have
Reach the systems that hold the data, including the ones outside the warehouse, and profile what is in them rather than what the documentation claims. Profiling routinely surfaces fields that are unused, duplicated, or populated differently from their name, and it is cheaper to find that now than during a failed agent deployment.
-
Resolve semantics, not just schema
Capture what each field means in business terms, sourced from the people who use it rather than from the table definition. Modern approaches infer much of this automatically from the data and its relationships, which makes the task tractable at enterprise scale; the remaining work is confirming the inferences with an owner who can be held to them.
-
Resolve entities across systems
Establish that one customer is one customer whether it appears in the CRM, the billing platform, or the support system. This is unglamorous and it determines whether any aggregate an agent produces is correct.
-
Certify quality and declare freshness
Measure quality, then publish the result alongside the data so a consuming system can read it. The important shift is from a quality dashboard a person checks to a quality signal a system consumes, because an agent will not go and look.
-
Express access policy so a machine can enforce it
Convert who-may-see-what from a document into an attribute a system reads at query time. Policy that exists only in prose is applied by whoever remembers it, and an agent remembers nothing it was not given.
-
Hold the change contract
Agree what may change in each dataset and with what notice, then enforce it. Without this, everything built in the five previous steps degrades quietly, and the degradation is discovered through wrong answers rather than through alerts.
One approach is deliberately absent. There is no step for documenting the entire data estate before starting. Estate-wide semantic projects are the classic way this work stalls, because the effort is enormous, the value arrives only at the end, and the definitions age while the project runs. Resolving the data one real use case depends on produces something usable in weeks, and the second use case is cheaper because the entities and policies already exist.
What does data intelligence look like in practice?
Two failures show it clearly. An agent aggregating two revenue fields that were never comparable, and an agent treating one customer as three because no entity resolution existed. Both produce plausible output, and neither raises an error, which is what makes them expensive.
The revenue field that was never comparable
A finance team asks an agent for revenue by customer for the quarter. Two systems hold something called revenue: the billing platform records invoiced amounts net of credits, and the CRM records booked contract value at signature. A human analyst knows never to add these together. Nothing in the data says so.
The agent produces a total. It is internally consistent, formatted correctly, and wrong by whatever the difference between bookings and billings happens to be that quarter. Nobody catches it, because the output looks exactly like a correct answer. The fix is not a better model. It is a semantic definition on both fields recording what each measures and that they are not additive.
One customer counted three times
A support agent is asked to summarize a customer's history before a renewal conversation. The account appears in the CRM under a trading name, in billing under a registered entity name, and in the support system under an acquired subsidiary. Without entity resolution, the agent finds one of the three and reports confidently on a third of the relationship.
Both examples share a shape worth noticing. The failure is not that the agent could not find data. It found data, reasoned over it correctly, and reached a wrong conclusion because the premise was wrong. That class of failure is invisible to model evaluation and to agent testing, which is why it belongs to the data layer.
Which category of tooling provides data intelligence
No single category covers all six requirements. Lakehouse and data platforms increasingly build in semantic and governance features alongside storage and compute. This suits organizations consolidating around one platform. Data catalog and governance vendors are strong on business context, ownership, and regulatory classification. These are often deployed alongside a platform, not instead of it. Master data management handles entity resolution specifically. Data observability covers freshness and quality signals. Agentic data platforms combine semantic discovery with an agent layer that uses it. Most enterprises end up assembling two or three of these. The real evaluation question is which of the six requirements a given tool satisfies.