From Data to Knowledge: The Real Challenge of Enterprise AI

A company can have terabytes of data and, still, have no access to almost any of its knowledge. For an AI agent, that is not a minor problem: it is the problem.

Introduction

Yesterday we said the procurement agent did not fail because of the model, but because the company had not given it a layer of comprehension. To build it, you have to start from the ground. And at the ground there is a distinction that almost every AI project confuses because, day to day, no one uses it: the difference between data, information, and knowledge.

This is not academic pedantry. It is the difference between “the system has the data” (almost always true) and “the agent can act on what that data means” (almost always false).

The problem

Imagine the typical company where we are going to deploy AI agents. Its data is in:

  • the ERP: orders, invoices, accounts, suppliers, inventory, work orders;
  • the CRM: opportunities, contacts, sales tickets, follow-up notes;
  • documents: contracts, policies, manuals, technical specifications, committee minutes, quality reports;
  • APIs: third-party, partners, internal services;
  • subject-specific databases that no one has cataloged;
  • emails and tickets: where many of the decisions are actually made; and
  • legacy systems that no one knows when they will be replaced and that contain the oldest, sometimes most valuable knowledge.

Together, they form an enormous asset. The CFO can say “we have all the data” and be right about the gigabytes. But ask your AI agent three things:

  1. “What is the current situation of customer X?” — The agent finds “X” in five different systems, each with a piece of the story, none with the whole.
  2. “What happens if supplier Y raises the price of component Z?” — The agent does not know which products depend on Z, which contracts cover it, or which customers would be affected.
  3. “How was the similar case last year decided?” — The decision exists, probably in an email and in the head of the person who made it. It is not in any place the agent can read.

All three failures have the same origin: the data exist, but the knowledge is not accessible to the agent. The knowledge is not “out there,” distributed across the systems, because knowledge is not a collection of records: it is meaning, relations, and experience.

The concept

The hierarchy we use in this series is the classic one formulated by Russell Ackoff in 1989, which is still the most useful:

DATA  →  INFORMATION  →  KNOWLEDGE
  • Data. A symbol or record without agreed meaning. 49281 in a cell. 0x3F in a log. ACME LTD in a text field. On its own, it says nothing: it is a token waiting to be interpreted.
  • Information. Data organized and given a minimal context that makes it readable: “order number 49281 from ACME LTD, issued on March 12, for €14,300.” Information answers who, what, when. It is what a dashboard, a well-written SQL query, or a well-tagged ticket produces.
  • Knowledge. Interpreted information: meaning, relations, rules, and experience that allow you to decide and act. “ACME LTD is the same customer as Customer #49281, its current master contract is B, discounts above 15% require the director’s approval, and the last time we accepted an exception was for a documented delivery incident.” Knowledge answers what it means and what to do.

Three properties of knowledge that distinguish it from data:

  1. It requires interpretation. The same record 49281 is a different thing depending on the system, the date, and the person reading it.
  2. It lives in relations. An isolated datum almost never suffices: knowledge is, for the most part, between the data.
  3. It is temporal and situational. Knowledge that was valid yesterday (master contract A) can be false today (B replaced it). Data does not expire; knowledge does.

And a fourth, decisive for this series: knowledge is not something you “have” or “don’t have”; it is made accessible or it is not. The organization produces it continuously (every decision, every negotiation, every incident generates it), but if there is no representation that makes it retrievable and verifiable, for the agent it is the same as not existing.

This explains the pattern we saw yesterday: the company had the data (ERP, CRM, PDFs), and yet the agent knew nothing. Because between “the data exist” and “the agent can reason about them” there is a space that no one fills by default: the deliberate construction of knowledge.

Architecture

In the series diagram, today we only deal with the ground:

                KNOWLEDGE        ← what the agent needs
                     ↑
        ┌────────────┴────────────┐
        ↑                         ↑
    SEMANTICS                 (relations, rules,
   (meaning)                   experience)
        ↑
       DATA                   ← what the company has today
        ↑
  ENTERPRISE SYSTEMS
  (ERP, CRM, docs, APIs, legacy, emails, tickets)

The DATA → KNOWLEDGE jump is not a pipeline: they are two different problems that are usually confused. The first is technical (extract, move, and transform data, which is what a data warehouse or a lakehouse does). The second is cognitive (endow the data with meaning, identify entities, express relations, fix rules, preserve experience), and it is the one that no data integration tool solves on its own.

Most data architectures from 2015–2025 solved the first one very well and barely touched the second. Most AI projects from 2024–2026 discovered the second one the hard way, through failures.

Use case

An industrial components manufacturer, a typical company about which we need no further details. We break it down with the order of the series:

  1. Problem. The average time to respond to a customer request demanding a technical modification is two days: you have to locate the current specification, the customer history, the available materials, and the order status.
  2. Decision. Accept, modify, or reject the modification, and with what impact on lead time and cost.
  3. Necessary knowledge. What each material code means; which specification is current versus the previous ones; which materials substitute for others; what agreements exist with that customer; what capacity production has this week.
  4. Data. Everything is spread out: the ERP has materials and orders; a document manager has specifications (some in versions); the CRM has the commercial history; the engineers have the agreements in emails.
  5. Relations. Material → current specification; material → substituted by → material; customer → agreement → terms; order → line → material. None of these relations exists as such in any system: they are implicit in the processes and in people’s heads.
  6. Context. The request arrives on the 18th of a month with capacity already committed; the customer is strategic; the modification affects a certified component.
  7. Memory. The customer asked for something similar in 2024 and it was resolved with a substitute material accepted by quality; the decision is in an email from an engineer who has retired.
  8. Reasoning. Cross the modification with the current specification, check the approved substitution, estimate the impact on lead time with real capacity.
  9. Action. Reply to the customer with the decision, update the order in the ERP, notify production.
  10. Infrastructure. For an agent to do this, each of layers 5 to 9 has to exist as a system: not as an Excel, not as an email, but as represented, retrievable, and verifiable knowledge.

What is notable about the case: the failure was not one of data volume. It was that the meaning layer (what a material code means) and the relations layer (what substitutes for what) were not represented. The agent had more than enough information and more than enough knowledge in the company: the problem was that it was not in any place the system could use.

Trade-offs

  • Cost. Making knowledge accessible costs more than moving the data. It requires modeling decisions (which entities, which relations, which rules) that are business decisions, not engineering ones.
  • Complexity. Each source system has its own logic. Unifying meaning across five systems is a project, not a configuration.
  • Source quality. If the ERP has doubtful data, the knowledge built on it inherits it. The cognitive infrastructure amplifies what is there: for good and for bad.
  • Latency. Building knowledge is slower than extracting a datum. You have to decide what is precomputed and what is computed on demand.
  • Maintenance. Knowledge expires. If the company changes its discount policy and the knowledge layer is not updated, the agent will start applying the old policy with all the confidence of a verified answer, which is worse than a doubtful one.
  • Honest limitation: not everything the company “knows” is representable. The veteran’s judgment that says “this smells bad” is not going to make it into a graph. The cognitive infrastructure captures the expressible part, which is already enormous, but it is not a collective mind.

Implication for the business

For the CDO, the message is direct: the asset the AI agent consumes is not the data lake. It is the knowledge layer on top of the data lake. And that layer, today, in most organizations, is half-built, with inconsistent names, no owner, and not being updated.

For the CIO, there is a budget consequence: “data for AI” projects that limit themselves to putting an API on top of the ERP will reproduce the failure of the procurement agent. The investment that distinguishes a successful project from one that dies in the pilot is the investment in meaning and relations, which does not appear in any traditional data integration RFP.

For operations, the implication is the most concrete: the knowledge that today lives in emails, in Excel, and in people’s heads will have to exist somewhere systematic. Not because the agent demands it, but because the company that does not have it is already losing it: every retirement, every departure, every reorganization takes it with it.

Conclusion

The jump from data to knowledge is the first step of the cognitive infrastructure, and it is where enterprise AI projects are won or lost. We have seen the hierarchy (data → information → knowledge) and why current systems solve the first half and neglect the second.

But there is a first problem that has to be solved before any knowledge layer can be built: the systems do not understand each other. Not only because they have different formats, but because they do not speak the same language.

Next article

Tomorrow: Data does not speak the same language: the problem of enterprise semantics. We will see why “customer,” “account,” “client,” and “party” can be four names for three different things, and why the problem is not one of technical integration. It is one of comprehension.

Sources

  • Ackoff, R. (1989). “From Data to Wisdom.” Proceedings of the 14th Annual Computer Software Applications Conference. — The data → information → knowledge (→ wisdom) hierarchy.
  • Working definition of the ECI: see the series, Day 1.

Related Posts