AI Doesn’t Need More Data. It Needs a Business Model.
There is a pattern in how organisations adopt AI. It starts with excitement. The technology can summarise documents, answer questions, draft emails, generate reports. It feels transformative. Teams spin up pilots. Early wins come quickly.
Then comes the plateau.
Why can’t it make actual decisions about our business? Why does it hallucinate about our customers? Why does it give confident answers that are completely wrong in the context of how we operate? Why does every new use case require weeks of prompt engineering and manual context assembly?
The answer is always the same: AI doesn’t understand your business. Not because it isn’t smart enough. Because nobody gave it the map.
The smartest person in the room, with no context.
Imagine dropping the smartest person you have ever met into the middle of your organisation. They have exceptional reasoning ability, deep general knowledge, the capacity to process enormous amounts of information. They can read faster than anyone, write better than most, and spot patterns that others miss.
But they have no context. No org chart. No understanding of how departments relate to each other. No knowledge of which KPIs actually matter and which are vanity metrics. No history of what has been tried and what has failed. No sense of which customers are strategic and which are transactional. No understanding of the rules — written and unwritten — that govern how things actually get done.
This person would be brilliant and completely useless. They would generate plausible-sounding recommendations that ignore critical constraints. They would suggest strategies that conflict with commitments already made. They would treat every customer the same, every department the same, every decision the same — because they have no way to know the difference.
That is exactly what we do with AI every day. We give it world-class reasoning capability and zero business context. Then we wonder why it can’t make real decisions.
What “business model” actually means.
When we say AI needs a business model, we do not mean a revenue model or a financial projection or a pitch deck with a TAM slide. We mean a structural model — a representation of how your business actually works.
What objects exist in your business? Customers, products, teams, campaigns, accounts, contracts, projects, facilities, suppliers. These are the nouns of your organisation — the things that matter.
How do they relate to each other? A customer has contracts. Contracts contain products. Products are supported by teams. Teams report into departments. Departments own budgets. Budgets fund campaigns. Campaigns target segments. Segments are defined by product usage. This web of relationships is the structure of your business.
What metrics matter and what drives them? Revenue per customer is driven by contract value, product adoption, and expansion rate. Customer health is driven by NPS, ticket volume, product usage trends, and stakeholder engagement. Operational efficiency is driven by cycle time, error rate, and resource utilisation. These metrics do not exist in isolation — they form dependency chains that explain how your business performs.
What rules govern operations? Contracts above a certain value require legal review. Customers in regulated industries need specific compliance workflows. Renewal discussions must begin 90 days before expiration. Discounts above 20% require VP approval. These are the constraints that define what is possible and what is not.
What thresholds trigger action? When NPS drops below 30, escalate to the customer success director. When product usage declines for three consecutive weeks, initiate a health check. When pipeline coverage falls below 3x, shift marketing spend to demand generation. When a key stakeholder leaves a strategic account, alert the account team immediately.
This is the ontology. The structured representation of how your business works. And it is the infrastructure that AI needs to reason about your specific business — not businesses in general, but yours.
Why RAG, fine-tuning, and prompt engineering are not enough.
The AI industry has developed three main approaches to giving AI business context. All three are useful. None of them solve the fundamental problem.
Retrieval-augmented generation retrieves text fragments from your documents and feeds them to the model alongside a query. This is excellent for question-and-answer use cases — finding information in policy documents, surfacing relevant paragraphs from contracts, answering questions about procedures. But RAG retrieves text. It does not understand structure. It cannot reason across relationships. Ask it “which customers are at risk of churning and what should we do about it?” and it will search for documents containing the word “churn.” It will not traverse the actual relationships between customer health scores, product usage patterns, stakeholder changes, and contract timelines that would answer the question properly.
Fine-tuning teaches a model patterns from your data. It can learn your writing style, your terminology, your industry conventions. But it creates a static snapshot. It does not know that Customer A’s NPS dropped last week, that your largest deal is stuck in legal review right now, that the marketing team shifted strategy yesterday. Fine-tuning teaches the model what your business looked like when the training data was collected. It does not give the model access to what your business looks like today.
Prompt engineering is manual context injection. A skilled engineer writes a detailed prompt that includes business rules, definitions, constraints, and examples. This works for individual tasks — a well-crafted prompt can produce impressive results for a specific use case. But it does not scale. Every new use case needs its own prompt. Every change in business context requires updating prompts across every application. The business context is encoded in text strings scattered across dozens of systems, maintained by whoever remembers to update them. It is fragile, inconsistent, and impossible to govern.
None of these approaches give AI a structured understanding of your business. They are workarounds for the missing infrastructure. They try to compensate for the absence of a business model by injecting fragments of context at the point of use. And they will always be limited by the fact that fragments are not structure, text is not relationships, and static snapshots are not living models.
What changes when AI has a business model.
When AI has structured access to your business ontology, everything changes. The nature of what AI can do shifts fundamentally.
It does not search for answers. It reasons across relationships. Ask it about customer risk and it traverses the connections between customer health, contract terms, stakeholder engagement, product usage, support history, and market conditions. It does not find a document about churn. It evaluates the actual state of the actual customer across every dimension that matters.
It does not generate plausible output. It generates informed output. When it recommends an action, it knows the constraints. It knows that this customer requires a specific approval workflow. It knows that this product has a dependency on another product that is being deprecated. It knows that this team is already at capacity and cannot take on additional work without trade-offs. The output is not generically correct — it is specifically right for your business.
It does not need you to explain your business every time. It already knows. You do not write a 500-word prompt explaining your customer segmentation model, your pricing tiers, your escalation procedures, and your renewal process. That understanding is embedded in the ontology. Every AI interaction starts with full context, every time, automatically.
It can reason about cascading effects. Change a pricing rule and the model can trace the impact across every affected contract, every affected customer segment, every affected revenue forecast. Lose a key team member and the model can identify every account that depends on them, every project at risk, every handover that needs to happen. This is not search. This is structural reasoning — understanding how changes propagate through a connected system.
It can act, not just answer. Because the ontology includes rules and thresholds, AI can take action when conditions are met. Not generic actions. Specific actions defined by your business logic, executed through your systems, governed by your policies. The model does not just tell you what is happening. It does something about it.
The infrastructure gap.
Over the past two decades, we have built incredible infrastructure for data. Databases, data warehouses, data lakes, data lakehouses, streaming platforms, ETL pipelines, data catalogs. The technology for storing, moving, and transforming data is mature and powerful.
Over the past five years, we have built incredible infrastructure for AI models. Training frameworks, serving infrastructure, fine-tuning pipelines, evaluation harnesses, model registries, inference optimisation. The technology for building and deploying AI models is advancing at unprecedented speed.
But we have not built the infrastructure that connects them — that gives AI structured access to what the data means in a business context. The data infrastructure knows how to store a number. The model infrastructure knows how to generate text. Neither knows that the number is a customer health score, that it has been declining, that the customer is strategic, that their contract renews in 45 days, and that the appropriate response is to trigger a specific escalation workflow.
That is the gap. The missing layer between data and AI. The infrastructure that translates raw information into business meaning. The structured model that gives AI the ability to reason about your business the way an experienced executive does — with full context, with understanding of relationships, with knowledge of constraints, with awareness of consequences.
Every organisation that is serious about deploying AI beyond simple automation will eventually need this layer. The question is not whether. It is when — and whether you build it deliberately or let it emerge as an ungovernable mess of prompts, retrieval hacks, and one-off integrations.
The organisations that build this infrastructure intentionally — that model their business as a structured ontology, connect it to their systems, and give AI the ability to query, reason, and act — will be the ones where AI actually works. Not as a novelty. Not as a productivity tool for individual tasks. As a fundamental capability that changes how the business operates.
The infrastructure gap is the only thing standing between today’s AI and tomorrow’s. It is time to close it.