Most conversations about AI in the enterprise start in the wrong place. They talk about the model, the agent vendor, the flagship use case. And they almost never talk about the one thing that determines whether any of it will work: the state the business's data is in.
The pattern repeats everywhere. The pilot impresses. The demo works. And then the move to production never arrives. It isn't a model problem —today's models are extraordinarily capable—. It's that an agent is only as good as the knowledge it operates on, and in most organizations that knowledge is scattered, unrelated, undescribed, and unprotected for a consumer that isn't human.
There are four levers that change this. We lay them out separately to explain them, but it's worth saying the most important thing from the start: they don't work separately. It's a chain, and a chain breaks at whichever link is missing.
1. Centralize: because an agent doesn't know who to ask
In a typical company, a single customer's data lives spread across the CRM, the ERP, the document manager, the call history, email, and several proprietary systems that were never designed to talk to each other.
For decades this was a tolerable cost, because human judgment absorbed it. A person knows which system to check, asks a colleague when in doubt, and fills the gaps with implicit knowledge. An autonomous agent has none of those abilities. It can't call anyone. Faced with scattered, contradictory data, it decides with whatever it finds — and it can reach different conclusions about the same customer on different days, depending on which fragment it hits first.
What was a nuisance for a human is a reliability risk for an agent. That's why the first lever is to centralize: to gather the data in a single point, so the agent receives the context instead of having to reconstruct it. An agent that spends most of its capacity searching for and reconciling information before it even starts is expensive and mediocre. One that asks a single place and receives an answer goes straight to solving.
But centralizing isn't only about efficiency. It's also —and this is less well understood— a security condition. When knowledge sits in one place, access policies are governed from a single point. When it's spread across ten systems, governing access means keeping ten permission models —that don't talk to each other— consistent. Contradictions, gaps, and breaches are born of that dispersion. We'll come back to this in the fourth lever.
2. Relate: because an isolated piece of data doesn't answer a business question
Centralizing without relating is just piling up. Having all the data in one place is worthless if it remains a set of islands: a customer ID in one system, a contract number in another, a call transcript in a third, with nothing joining them.
The second lever is to relate: that from a customer you can reach their order, their case, their contract, their last conversation — without calling five different APIs, without reconciling five different syntaxes. That the data is connected to all the other data that concerns it, regardless of the system it came from.
And here there's a non-negotiable requirement: lineage. Every piece of data must carry with it where it comes from, when it entered, and what transformations it has undergone. This matters because an AI answer without traceability is a claim that floats — it rests on nothing verifiable. An answer anchored in data with lineage can be traced back to the specific piece of data, from the specific system, of the specific date, that supports it. In sectors where you have to demonstrate —not merely assert— why the system holds what it holds, that difference is everything.
3. Describe: because "joining tables" isn't understanding the business
Data that is centralized, related, and carries lineage is a solid foundation. But it isn't knowledge yet. To become knowledge, you have to describe what it represents in business terms.
This is the third lever, and the one most often mistaken for magic. It isn't. It consists of a numeric field ceasing to be a number and becoming "the value of the customer's portfolio in euros." Of two unconnected tables revealing themselves as "the customer who signed this contract." The result is a graph of business entities —customer, portfolio, contract, interaction— and of how they relate. That is, strictly speaking, an ontology: the model of what exists in the business and how it connects.
Here's an important nuance. The usual way to build an ontology is by committee: a group of experts describes from the outside how the business works, before looking at the data. It's a legitimate approach — but it carries a risk. An ontology that isn't radically connected to the truth of the data tends to describe what people believe happens, or what they'd like to happen — very rarely what actually happens. We prefer the reverse path: letting the ontology emerge from the real data the company has, with each relationship preserving the thread that connects it back to its origin. That way it describes the business as it is, not as it's assumed to be — because it's anchored in data with a source.
This has a consequence that solves, almost in passing, a problem many treat as a separate project: memory. No separate system that remembers and compiles summaries is needed. The business's memory is already in the data — every fact, with its date and its source, is memory. When you need to retrieve a customer's history, it's reconstructed from the data, not from a synthesized copy that ages. Memory isn't a module you add. It's a property of having the data well organized.
4. Protect: because giving an agent access isn't like giving it to a person
And we reach the lever that in Europe isn't optional, but the starting point.
Giving an autonomous system access to sensitive information demands a control that permission models designed for people cannot offer: knowing exactly which data each agent can see, for which task, and in which context. "This user has access to this system" isn't enough. You need field-level granularity, and you need every access to be logged in a way you can demonstrate afterward.
Here is our strongest thesis, and we state it without hedging: security is not a layer placed in front. It's a condition inseparable from the data. Most architectures build the system and, at the end, put an access control in front of it. But when security is just one more layer, a single integration, an internal API, or a maintenance process that accesses by another route is enough for the control to be bypassed. A guarantee that depends on no one having forgotten to apply it somewhere isn't a guarantee: it's a good intention.
The alternative is for the data to be accessible only through a single surface of governance, with no alternative routes. Then every access —without exception— is evaluated against a policy, and every query is logged immutably. That's the difference between being able to assert that the system is secure and being able to demonstrate it. And in an environment regulated by GDPR, DORA, and the EU AI Act, you have to be able to demonstrate it.
More still: when the data is centralized and described (levers 1 to 3), data minimization —delivering only the minimum necessary for each purpose— stops being a principle you strive to honor after the fact and starts happening by default, on every access, without anyone having to remember it. Regulation stops being a burden you manage and becomes a property of the system.
Why there are four, and not a list to choose from
Here is the point that holds up the whole argument. These levers aren't four independent improvements you can prioritize and tackle one at a time. They're a chain, and each link depends on the previous one:
- Centralizing without relating is piling up data that still answers no questions.
- Relating without describing is having connections no agent understands in business terms.
- Describing without protecting is exposing all that knowledge, now perfectly legible, without governance — the worst possible scenario.
- And protecting without having centralized is trying to govern ten disconnected systems at once: exactly where every breach slips through.
You can't have a serious enterprise AI strategy with three out of four. An organization that centralizes, relates, and describes but doesn't protect has left all its knowledge, now perfectly legible, exposed without governance. One that protects but doesn't describe governs a system no agent understands. The value isn't in each lever separately: it's in their operating as a single system, designed from the start to work together.
And that's why we believe this isn't assembled from loose parts —an ingestion engine here, a semantic catalog there, an access control on top—. Every joint between independent pieces is a point where lineage is lost, where description degrades, and where governance dilutes. The four levers are only real, and not aspirational, when the system is designed to sustain them at once.
The uncomfortable conclusion
The question worth asking isn't "which agent do we deploy?". It's a prior one, and a more demanding one: is our data centralized, related, described, and protected? If the answer is no on any of the four, the agent —however good the model— will keep shining in the pilot and dying before production.
Building this foundation isn't the boring part you have to get out of the way before reaching the AI. It's the condition that separates an AI that reaches production from one that stays in the pilot.