Three Questions Before You Build the AI Layer

A lot of the conversations I’ve been in over the last few years start the same way.

“We want to use AI to surface insights from our data.” “We’re building an AI layer on top of our CRM.” “We want to automate reporting with AI.”

My first question is always the same: tell me about the data underneath.

Teams get drawn to the AI layer because that’s where the outcome lives, and the outcomes are real. I’ve seen AI cut segment-building workflows from five days to an hour. I’ve seen retrieval pipelines surface patterns that would have taken an analyst weeks to find. The promise of reducing manual work and getting to better answers faster is not hype. The outcomes track with how much trust you can put in the data feeding the model. When the inputs are clean and well-governed, the results are genuinely impressive.

The readiness conversation

The gap between wanting AI and having AI that produces reliable outputs usually comes down to data readiness. Most teams sense this, and the pull toward a demo is strong because the work that closes the gap doesn’t make for a compelling board slide.

The pattern I keep seeing: leadership sees adjacent companies shipping AI features and wants to capture that same value. A pilot gets funded. A proof of concept gets built. It works in the demo, then stalls before production.

The diagnosis usually lands on the technology. Wrong model, wrong vendor, someone with more AI experience. The real opportunity is usually further upstream, in making the inputs the model is working with reliable enough for the outputs to be trusted. That’s where the work becomes the thing that makes the AI layer possible.

Three questions worth answering honestly

Three questions tend to show you where to invest first.

Do you trust this data? Is there a single, clean source of truth for the entities the model will reason about, customers, products, transactions? Or are there five systems with five different customer IDs that don’t fully agree? On one project we found that around thirty-five percent of the customer records a churn model was training on were duplicates. The model was technically impressive. It was predicting churn for customers who didn’t exist. Resolving identity across those systems was the real project. The model surfaced the need.

Can you trace where the data came from? If the model produces an output and someone asks “why?”, can you walk that back to the source events? Lineage tells you whether the model is reasoning on current data or on data from a system that stopped syncing months ago. Traceability is what lets the people downstream trust the output enough to act on it.

Do the right people have access to validate it? Not just API access. Does the team that needs to check the model’s outputs have enough context about the underlying data to know when something is off? The review layer matters as much as the model layer, because it’s where the quality gets held.

What the readiness work looks like

On a recent project a client wanted to build AI-assisted churn prediction. The data spanned three years of customer records from two CRMs that had been partially merged after an acquisition. Some customers appeared twice with different IDs. The company’s definition of “active customer” had changed twice in two years. There was no systematic event tracking for product engagement, which is the primary signal for churn risk.

We spent three months on foundations before writing a line of model code. Customer identity resolution across the two CRMs. Event tracking implementation. A single agreed definition of “active.” A clean daily snapshot of account health metrics. When we built the model, it worked. The time on readiness was what made the AI layer possible.

The sequence that keeps working

The order that produces reliable AI deployments is data foundations, then data trust, then the AI layer.

Teams sometimes compress or skip the first two steps because the incentive structure rewards the visible part. An AI agent you can demo in twenty seconds gets budgeted. Three months of entity resolution does not. One data leader I worked with put it plainly: “If I go to the board and ask for six figures to clean up Salesforce, I get cut. If I ask for the same budget for an AI agent, I get a round of applause.”

That’s a real constraint. The teams I’ve seen ship AI reliably share one thing in common. They treat the foundation as the project, and the AI layer as what becomes possible once the foundation is solid.

If you’ve got a pilot stuck in proof of concept, here’s where I’d start. Pick the single output your stakeholders care about most. Trace it back through your sources to where the data originates. Run good exploratory analysis so you understand where things sit. You’ll usually find the gap is further upstream than expected, and the real work is a conversation with the person who owns that source.

Then have that conversation. That’s almost always where AI starts to ship.