If you want to create business value using AI, start your initiative with a clear use case, governed data pathways, and compute costs tied to measurable outcomes.
AI tools in a sandbox can make a capability look inevitable. The model answers a question or a demo succeeds, and teams start looking to scale its use. But not every AI initiative is worth pursuing at production scale.
For data and AI leaders, the harder question is not whether a model works. It is whether the business value of the AI project will exceed the real cost of building it and running it in a production environment.
David Neill has spent more than 20 years in data and analytics, including serving as a chief data officer. During a conversation on Haevek’s The Compute Layer, Neill describes why AI economics are shaped by questions asked and answered well before a model returns an answer.
AI initiatives often begin with a business goal. We want to reduce development costs by 20 percent or increase sales by 30 percent. These are measurable goals, but they do not paint the big picture by themselves. Cost of deployment determines whether an AI project will pay off.
“If you spend $100,000 to reduce your cost $50,000, that’s a negative return on that investment.”
A credible business case needs to connect a defined outcome to the cost of the full project, not just the visible model or the initial build.
The consulting, hardware, cloud storage, data architecture, and the cloud compute costs required to continually run workloads at scale are going to be calculated in. If teams cannot foresee those costs relative to a specific initiative, a promising demo can become an expensive production commitment without a clear path to profitably scaling it.
Discipline is needed to first identify the desired business outcome, establish what it currently costs to achieve, and determine whether AI can improve results enough to justify the added infrastructure and operating expense.
As organizations add tools and agents during an AI initiative, they often unintentionally pay multiple systems to retrieve the same data or produce the same answer. Neill has seen this happen when different AI engines run in parallel without clear direction for what each one should do.
More AI activity does not necessarily equate to more capability. Not if there is repeated computation, repeated data pulls, and unnecessary cloud spend to repeat work that has already been done.
“Probably most important to this conversation is more tools doesn’t always equal better.... More arrows in the quiver means you can shoot a whole lot more, but you’re missing the target a lot more.”
A governed process can help teams decide which workloads belong in the stack, where the authoritative data lives, and how systems should consume it. The goal is not to add controls for their own sake. It is to avoid asking every tool to rediscover, recalculate, or regenerate information that another part of the organization already has.
Connecting a model to every available dataset may feel like a shortcut. But it leaves the model to infer which information matters, how it relates to the business question, and whether it is current or trustworthy.
Neill points out that AI models need context and a deliberate path to the right information. Teams should understand the business question they want to answer, identify the data that can answer it, and make that data available in a form the AI tools can use reliably.
“You need governed, managed, clearly defined data in a platform that can be consumed readily and quickly to come up with good business decisions.”
By now, most teams are familiar with the bronze, silver, and gold layers of medallion data architecture. AI needs that gold layer, and they need it fast. AI tools should be pointed at data that is clean, oriented to business strategy, and ready to consume. They can’t be waiting for a process where calculations or updates are still underway.
Neill recalls a project where an AI model had to wait for someone to send a monthly file because it was reading from the wrong place. The issue was not a lack of data or a more advanced model. The information was not being delivered through a dependable, usable path. As he puts it, “That’s not the way AI should work.”
When an AI initiative misses its expected return, reducing staff or buying another tool can look like the fastest response. Neill argues that the more important work often involves streamlining the operations and architecture that move information from its source to the point where it creates value.
That means monitoring where spend accumulates:
Teams should also separately categorize costs that behave differently. Data platform costs may rise as the organization brings in new data or changes its data model; AI compute costs rise as more people use the AI workload. Tracking both back to the business goal for the initiative makes it easier to measure the system costs and determine whether the desired outcome justifies that cost.
A better stack is not the one with the most tools. It is the one that fits the organization’s real use cases, data, skills, and operating constraints.
A compute platform cannot choose the right business problem or make weak data trustworthy. It can, however, affect how quickly and efficiently worthwhile data and AI workloads run, and how predictable their infrastructure costs are.
Haevek’s Falcon Compute Platform is designed for that layer. It is a Kubernetes-native rebuild of Apache Spark that does not require wholesale replacement. It runs existing batch, streaming, and AI/ML workloads alongside your company’s current lakehouse. Falcon’s capacity-based pricing is intended to make compute spend more predictable than a consumption-based pricing model that incurs more costs as production scales.
Capacity pricing gives teams a way to examine whether the compute portion of a workload’s economics can improve while the surrounding data environment stays in place. The relevant proof is workload specific. Compare the work, performance, and cost in the environment where the organization intends to run it.
AI ROI is not created by connecting more data or deploying more tools. It comes from choosing a business outcome that matters, making the right information reliably usable, avoiding repeated work, and measuring the full cost of the system against the value it returns.
For data leaders, that is an architecture decision more than a model decision. Start with the workload and the outcome. Then make the data path and compute economics strong enough to support them.
If a promising workload is high-centered by a cost or performance question, take a Falcon Test Flight to benchmark it in your own environment or in ours before starting a new AI project.