Your AI pilot had beautiful data.
Of course it did.
Someone picked the right tables.
Someone selected the right columns.
Someone cleaned up the duplicates.
Someone explained what the important fields meant.
Someone made sure the demo questions had enough context to produce useful answers.
And then the AI worked.
Wonderful.
Now connect it to Production.
Because Production has customers that exist multiple times.
And that’s where things get interesting.
The Question Should Be Easy
Imagine asking your shiny new AI assistant a very simple question:
How many active customers do we have?
Nothing exotic.
No predictive analytics.
No complicated financial modeling.
No request to analyze ten years of customer behavior and predict next quarter’s revenue.
Just How many active customers do we have?
Surely AI can answer that.
After all, we’ve connected it to the company’s data.
There’s just one problem.
The company’s data doesn’t actually contain the answer.
The Sherpa’s Notebook
I’m working in a client environment currently where customer data is… interesting.
There is a primary client table.
Except many of the customers in that table don’t appear once.
They appear six times.
Seven times.
Sometimes eight times.
Then there are multiple transaction tables representing different types of business activity.
Each of these tables stores customer information.
Each of these tables stores it slightly differently.
Customer names.
Customer numbers.
Transaction information.
And none of those transaction tables share customer information with the others.
There is no authoritative customer record sitting in the middle of the architecture saying:
These seven records are actually the same customer.
There isn’t a mastered customer identifier connecting everything together.
There isn’t a reliable relationship between all of these representations.
The systems simply evolved independently.
For years, humans have learned how to work around that.
Now imagine giving all of it to AI.
Just Match the Customers
That sounds easy enough.
Surely AI can figure out which records belong to the same customer.
Maybe.
Based on what?
Customer number?
Which customer number?
Customer name?
What happens when one system says: ABC Manufacturing
another says: ABC Manufacturing, Inc.
and another says: ABC Mfg
Are those the same customer?
Maybe.
What about two locations of the same company?
What about a company that moved?
What about organizations with similar names?
What about subsidiaries?
What about acquisitions?
What about a customer whose phone number changed?
What about a recycled phone number?
What about a record somebody entered incorrectly fifteen years ago?
AI can calculate similarity.
It can suggest relationships.
It can tell us two records look like they might represent the same organization.
What it cannot do is invent the organization’s rules for customer identity.
That rule has to come from somewhere.
Then We Get to “Active”
This environment gets even better.
Several of those transaction tables have an Active flag.
Excellent.
Question solved, right?
Find the customers where Active = 1.
Except that’s not what the field means.
The flag describes whether that particular type of customer relationship or transaction is active.
A customer might be inactive in one area of the business while still actively doing business somewhere else.
In other words, Active = 0 does not necessarily mean “inactive customer.”
And Active = 1 does not necessarily define the organization’s concept of an “active customer.”
The data contains an answer.
It just doesn’t contain the answer to the question we asked.
That’s a very important distinction.
So What Is AI Supposed to Do?
Let’s give our AI access to everything.
- Every customer table.
- Every transaction table.
- Every active flag.
- Every customer number.
- Every customer name.
- Every historical record.
Now ask again:
How many active customers do we have?
The AI has plenty of data.
What it doesn’t have is meaning.
It doesn’t know which duplicate customer records represent the same organization.
It doesn’t know which customer identifiers are authoritative.
It doesn’t know how identities should be reconciled across transaction systems.
It doesn’t know what the organization means by an “active customer.”
It doesn’t know how the different active flags contribute to that definition.
It doesn’t know which rule wins when systems disagree.
And there is absolutely no reason it should know any of those things.
Nobody ever taught it.
More importantly, nobody ever taught the architecture.
There Is Nothing for AI to Discover
This is where I think organizations can dramatically overestimate what AI can do with enterprise data.
We hear phrases like:
“AI will find patterns in the data.”
And it can.
“AI can connect information across systems.”
Sometimes it can.
But there is an enormous difference between discovering a pattern and establishing a business truth.
AI might determine that two customer records are 97% similar.
That does not mean they are the same legal customer.
AI might discover that a customer has Active = 0 in one table and Active = 1 in another.
That doesn’t tell it which status represents the customer.
It might notice that several records share an address.
That doesn’t establish the organization’s rules for customer identity.
There is no hidden answer buried in the database waiting for a sufficiently advanced model to uncover it.
The business rule simply isn’t there.
AI Cannot Invent Missing Architecture
That’s the real lesson from this environment.
We don’t have an AI problem.
We have a customer identity problem.
We have a business definition problem.
We have a data architecture problem.
Potentially, we have a Master Data Management problem.
Those problems existed long before anyone started discussing AI.
People compensated for them.
Reports embedded assumptions.
Employees learned which systems to trust.
Departments developed their own interpretations.
Maybe someone kept a spreadsheet.
Maybe Jeannine just knew which customers were actually active because she’s been there for twenty-two years.
Humans are remarkably good at filling gaps in poorly documented systems.
AI doesn’t have twenty-two years of institutional memory.
Unless we capture that knowledge, it has the database.
And the database says there are eight customers.
This Is Why Pilots Can Be Deceptive
Now think about how easily this problem disappears during an AI pilot.
We select a small subset of customers.
We remove duplicates.
We reconcile the identifiers.
We explain what “active” means.
We provide a clean dataset.
Then someone asks:
How many active customers do we have?
And AI gives the correct answer.
Everyone is thrilled.
The AI didn’t solve the customer problem.
We solved the customer problem for the AI.
That’s perfectly acceptable for proving a concept.
But it’s dangerous if we forget that happened.
Because when we connect the same system to Production, all of those assumptions come rushing back.
Six customer records.
Eight customer records.
Different identifiers.
Different transaction systems.
Different active flags.
Different interpretations.
Welcome to the real world.
The Answer Isn’t “Clean All the Data”
At this point, someone inevitably concludes:
We can’t use AI until all of our data is perfect.
That’s not the lesson either.
Enterprise data is probably never going to be perfect.
What we need is an authoritative layer of understanding.
Maybe that’s a mastered customer model.
Maybe it’s governed business rules.
Maybe it’s metadata describing which systems are authoritative for which attributes.
Maybe it’s identity-resolution logic with appropriate human review.
Usually it’s some combination of these.
But somewhere in the architecture we need to establish:
- This is how we identify a customer.
- This is how records across these systems relate.
- This is what “active customer” means.
- These are the exceptions.
- This is who owns that definition.
Now AI has something to work with.
Not because AI suddenly became smarter.
Because the organization finally captured what it knows.
More Data Would Actually Make This Worse
There’s an uncomfortable irony here.
If our AI doesn’t understand customer identity, giving it more customer data doesn’t necessarily help.
We may simply give it more duplicates.
More conflicting identifiers.
More active flags.
More historical variations.
More opportunities to reach the wrong conclusion.
This is why “we need more data” is often the wrong reaction when AI struggles with enterprise information.
Sometimes AI doesn’t need more data.
It needs a better representation of reality.
The Sherpa’s Lesson
Your AI pilot probably worked with the best version of your data.
Production will work with the version you actually have.
And sometimes the problem isn’t that Production data is dirty.
Sometimes the answer you want simply doesn’t exist anywhere in the architecture.
No authoritative customer identity.
No shared definition of active.
No rule connecting systems together.
No captured business logic explaining what everything means.
Sadly, you cannot prompt your way out of that.
You cannot buy a larger model and expect it to know.
And you cannot throw every table into a vector database and hope truth emerges from the embeddings.
- AI can find data.
- AI can identify patterns.
- AI can suggest relationships.
But AI cannot invent the business rule your architecture never captured.
Before your AI can answer, “How many active customers do we have?”
Your organization has to be capable of answering it first.
That’s the difference between giving AI access to your data…
and giving AI an understanding of your business.
Leave a Reply
You must be logged in to post a comment.