Your Data Is Not Your Intelligence

The difference between data and knowledge in a business is the difference between what happened and why. Data is the record, meaning the deal, the price, the date and the stage. Knowledge, or intelligence, is the reasoning behind it and the judgement about what to do next time. You can own every row in your CRM and still own nothing that tells a new hire, or an AI, why your business does what it does.

That much is familiar. This blog has already argued it from two directions, in what renting your intelligence actually costs and in what survives when someone leaves, and both conclude that the records and the reasoning need separating. This post asks the harder question underneath. If the reasoning left traces all over the data, why can't you simply work it out from the data, with enough history, clean enough fields and a capable enough AI?

The short answer is that the same record fits more than one reason, and usually fits opposite ones.

What is the difference between data, information and knowledge?

The distinction is old and still useful, as long as you are precise about where each layer comes from.

The first two layers are where almost all business software investment goes, and they earn their keep. Dashboards, reporting and pipeline analytics all live there. The third layer is the one that makes a business distinctive, and it is the only one of the three that cannot be computed.

The same row, two opposite reasons

Take two deals from the same quarter. Both closed at a 15% discount, both in a sector you had not sold into before, both on a 12-month term.

The first was a deliberate decision. The founder wanted a reference client in that sector, agreed the discount in advance, and would do the same again tomorrow. The second happened at six o'clock on the last day of the quarter, when a rep who was short of target gave the discount to get a signature, and the founder found out afterwards and was not pleased.

In the CRM those two rows are identical, with the same discount, sector flag, term and stage history. Half a year later someone asks whether the business discounts to get into new sectors, and the data answers yes, twice, with complete confidence. Half of that answer is policy and the other half is exactly the behaviour the policy exists to stop.

More data does not help. A thousand rows made of both kinds of decision produce an average discount for new sectors that nobody ever chose. Cleaner data does not help either, because both rows are already clean. A mandatory "reason" field helps a little, and in practice it is filled in with one word at the moment somebody is trying to close the record and go home.

Why analysis cannot recover the reason

Analysis finds what tends to happen together, and a reason is something different. It is what the person deciding knew, wanted and weighed at the time, and most of that never entered any system. Think of the phone call in which the buyer said what they really needed, the competitor's offer they mentioned, or the conversation with the board about which sectors matter this year. None of it is in the CRM, so none of it can be calculated out of the CRM, however sophisticated the calculation.

The UK regulator draws the same line in its own field. The ICO's guidance on explaining decisions made with AI identifies six main types of explanation, and two of them sit side by side. One is the data explanation, covering what data has been used in a particular decision and how. The other is the rationale explanation, covering the reasons that led to a decision. That guidance is written for AI-assisted decisions about individuals under data protection law, not for sales teams, but the structure is the point. The regulator treats the data and the reasons as two different explanations, and nowhere suggests the second can be read off the first.

Ask an AI why, and it will tell you

This matters more now than it did a couple of years ago, because the question is increasingly being put to an AI sitting on top of the records. The government's UK Business Data Survey 2026 found that among businesses using AI, 21% said that their AI tools are integrated into existing business systems, with AI embedded in CRM or finance systems among the examples given. The figure was 57% for large businesses and 31% for medium ones, from a base of 1,870 UK businesses that use AI.

Ask an assistant inside the CRM why deals were lost last quarter and it will not say it does not know. It will produce a reason, fluently, with the tone of a finding, and the reason will fit the pattern in the data. It may even be right. The trouble is that you cannot tell from the answer.

There is good evidence that models are unreliable narrators of reasoning even when the reasoning is their own. A NeurIPS 2023 study by Turpin and colleagues looked at the step-by-step reasoning a model writes out before it answers, known as chain-of-thought or CoT. It found that CoT explanations can systematically misrepresent the true reason for a model's prediction, and described those explanations as "plausible yet misleading". Anthropic tested the same question on newer reasoning models in 2025 and found that, averaged across the hint types it planted, Claude 3.7 Sonnet mentioned the hint 25% of the time when the hint had shaped its answer, and DeepSeek R1 mentioned it 39% of the time.

Those studies measure models explaining their own answers to test questions, not models analysing a sales pipeline, so the numbers do not transfer. The direction does. If a model's account of its own reasoning is unreliable, when that reasoning is the one thing it had direct access to, its account of why your team made decisions it never witnessed is a reconstruction. That is useful as a hypothesis and dangerous as a conclusion, and a business that treats it as the second will start setting policy from an average of its own good and bad decisions.

What the record is good for

None of this is an argument against the CRM, or against pointing AI at it. The record is the right foundation for a great deal of useful work, including summarising an account before a call, routing an inbound lead, chasing a stalled deal, and reporting what happened last quarter. The distinction between AI built into one tool and AI working across several is about how much of the record a system can see, and seeing more of it genuinely helps with all of those jobs.

What the record cannot do is answer questions that start with why, or questions about what to do in a case that has not come up before. Those need reasoning, and reasoning has to come from someone who had it.

Record the reason when the decision is made

The fix is not a bigger data project. It is a small change in timing.

The full reason for a decision exists at one moment, which is when the decision is made. A week later the person who made it is already reconstructing, and a year later they are telling a story that fits how things turned out. So the reasoning has to be written down then, by the person deciding, in a few lines, somewhere it will be read again.

That sounds like a burden until you narrow it. Most decisions do not need it. The ones that do are the recurring decisions that set precedent, where the next person to face the same situation will look at what happened last time and copy it.

• A discount outside your normal range
• Walking away from a deal, or turning a client down
• An exception to your usual process or terms
• Choosing one supplier, partner or approach over another

For each, two or three lines are enough, covering what was decided, why, and what would change your mind. That last line is the one people skip and the one that does the most work, because it tells the next reader when the precedent stops applying. Rejections deserve particular attention, because nobody records what did not happen, which is the argument behind why your AI sounds like everyone else's. The habit is the same for every decision type on the list.

We run our own business this way. Each decision note in our internal knowledge base records the date, who decided, the options we considered and why we chose the one we did, and several also carry the condition that would make us revisit it. When a question comes up months later, the answer is what we actually thought at the time, not what we now think we must have thought.

The same division shows up in client work. When we automated partner onboarding for a UK construction platform, the automation took over the research, asset capture, summary writing and formatting checks, and the platform saved 25 hours a month while taking on more than 100 partners a month. The decision about which partners to add stayed with the team. That split is the right one, and it is also a precise map of where the reasoning lives. The automation produces records. The selection decisions are where two lines of why would be worth keeping.

Once those notes exist, the rest follows. They can sit alongside the records rather than inside them, and they become the thing an AI reads before it answers why, which is the shift from a store of records to an intelligence system.

Practical takeaways

1. Stop expecting the reasoning to be in the data. The same row fits opposite reasons, so more history, cleaner fields and better analysis will not recover it.
2. Treat an AI's answer to a why question as a hypothesis. It will always give you a reason. Check it with the people who were there before it becomes policy.
3. Keep using the record for what it is good at. Summaries, routing, chasing and reporting all work well from CRM data.
4. Pick the three or four decision types that set precedent. Discounts, walk-aways, exceptions and supplier choices are the usual candidates.
5. Write the reason at the time, in three lines. Cover what was decided, why, and what would change your mind, and keep it where every tool and every new hire can read it.

Frequently asked questions

What is the difference between data and intelligence?

Data is the record of what happened, such as the deal value, the discount, the close date and the stage it passed through. Intelligence is the reasoning about why it happened and what to do next time. The two are easy to confuse because the reasoning leaves traces in the data, but the traces do not identify it. The same discount can record a deliberate move into a new sector or a rep panicking at quarter end, and nothing in the row tells you which. That is why intelligence has to be written down by someone who knows, rather than worked out from the records afterwards.

Is our CRM data enough for AI?

It is enough for AI to work on what happened, and not enough for it to work out why. A CRM holds good material for summarising accounts, routing leads, chasing follow-ups and reporting on the pipeline, and pointing AI at it for those jobs is sensible. It is not enough for questions like why deals were lost or whether you should discount into a new sector, because the reasons behind past decisions were mostly never entered. AI asked those questions will still answer, and the answer will be a plausible reconstruction rather than a finding.

Can AI work out why something happened from our data?

It can suggest reasons, and it cannot confirm them, because the deciding facts are usually not in the data. The phone call with the buyer, the competitor's offer and the instruction from the board never reached the CRM, so no analysis of the CRM can recover them. A model will still produce an explanation that fits the pattern, and research on models explaining their own answers has found those explanations can be plausible yet misleading. Treat an AI's account of why as a hypothesis to check with the people involved, never as a finding.

What is the difference between data, information and knowledge?

Data is the individual entries, such as one deal at one price on one date. Information is data arranged to answer a question about what happened, such as the win rate falling in the third quarter. Knowledge is the understanding of why it happened and what to do about it, such as knowing the fall came from one competitor's new pricing in one sector. Each layer can be built from the one below it except the last. Knowledge needs a fact the records do not hold, which is the reason somebody had at the time.

How do you capture reasoning?

At the moment the decision is made, because that is the only time the full reason exists. A week later the person who decided is already reconstructing it, and a year later it is a story that fits how things turned out. Pick the few decision types that recur and matter, such as a discount beyond your normal range, walking away from a deal or making an exception to process, and write two or three lines each time saying what was decided, why, and what would change your mind. Keep those notes where every tool and every new hire can read them.