Your CEO Wants AI. Before You Say Yes, Ask These 4 Questions.

Every leadership team we talk to wants the same thing right now: AI on their data. A chatbot that answers business questions. Automated insights. Something to show the board.

The ambition is real. The urgency is real. What's often missing is an honest assessment of whether the foundation is there to actually deliver it.

We've built AI on data at enough companies to know what separates the ones that ship something useful from the ones that spend six months and end up with a prototype nobody trusts. It comes down to four questions — and most companies can't answer all four honestly.

1. Do you know what problem you're trying to solve?

This sounds obvious. It's rarely done well.

"We want AI on our data" is not a use case. It's a direction. The teams that succeed narrow it down before writing a line of code: Which business decision is currently slow or unreliable because someone has to manually pull data? Which team is asking the same questions every week and getting inconsistent answers?

The best AI use cases we've delivered came from a specific pain that already existed — not from a greenfield wish list. For one e-commerce client, it was the regional sales team spending hours every Monday building reports manually. For a SaaS client, it was promoters needing data answers without being able to access the BI tool. Both had a defined problem, a defined user, and a defined success metric.

If you can't answer "who will use this, for what decision, and how will we know if it worked" — you're not ready to build. You're ready to have a longer conversation with your stakeholders.

2. Is your data actually ready?

This is where most AI projects quietly die.

LLMs don't fix bad data. They make bad data sound confident. If your revenue number looks different in three dashboards, if your pipelines run on cron jobs and duct tape, if nobody can trace where a metric comes from — AI will inherit every one of those problems and present them fluently to your users.

The threshold for AI-readiness is higher than most teams expect:

• Consistent definitions — revenue, churn, active user, conversion rate all need to mean the same thing everywhere, encoded in your transformation layer (dbt), not in someone's head

• Reliable ingestion — data needs to arrive on time and in full, with alerts when it doesn't

• Tested models — if you don't have dbt tests catching nulls and duplicates before data hits a dashboard, you can't trust what an AI will say about that data

• A semantic layer — tools like Cube Dev give the AI a clean, consistent view of your business metrics so it's not querying raw tables directly

We've delivered AI on data across 50+ projects. The fastest ones — where clients saw working prototypes in weeks — all had this foundation already in place. The slowest ones spent the first month rebuilding it before we could start.

If your data isn't ready, the answer isn't to skip this step. The answer is to fix it first. It's faster than you think when you do it properly.

3. Does your team have the culture to actually use it?

The technical problem is usually the easier one.

We've seen companies get a working AI prototype into production and then watch adoption flatline — because the team didn't trust it, didn't understand it, or had no incentive to change how they worked. Leaders pushed AI from the top without involving the people who'd actually use it day-to-day.

The organisations that get real value from AI on their data tend to share a few traits: stakeholders from across the business are involved in defining use cases before a tool is chosen; there's tolerance for testing things that might not work; and the people closest to the problem are empowered to shape the solution.

This isn't soft advice. Culture determines adoption, and adoption determines ROI. A technically mediocre solution with strong buy-in will outperform a technically excellent solution that nobody trusts.

4. Do you have — or can you access — the right skills?

You don't need an in-house AI team to ship something useful. But you do need people who understand how to build reliably on top of LLMs — prompt engineering, output validation, evaluation frameworks, and what to do when the model hallucinates.

These skills sit at the intersection of data engineering and AI development. Most companies don't have them in-house yet. That's not a problem — it's why consulting partnerships exist.

What is a problem is assuming that adding an LLM on top of your existing setup is straightforward, or that a junior engineer can figure it out from tutorials. AI on data is a new discipline. It has failure modes that aren't obvious until you've seen them in production.

The teams that succeed are either building this capability internally with a clear training roadmap, or partnering with someone who's already done it at scale.

Where Do You Stand?

Most companies we talk to are strong on ambition and weaker on foundation. That's not a criticism — it's just where the market is right now.

The good news: the foundation gaps are fixable. A clean ingestion layer, tested dbt models, and a semantic layer can be in place in weeks, not months. And once the foundation is there, AI implementation moves fast.

We've helped companies go from "our data is a mess" to "we have a working AI product in production" — but only because we fixed the data before building on top of it.

If you're not sure where your stack stands, that's exactly what a discovery conversation is for.