A common mistake in enterprise AI and data projects is to assume that adopting the right technology automatically leads to solving the right problem. In practice, that is rarely true. Whether the technology in question is Retrieval-Augmented Generation (RAG), a knowledge graph, or another modern data/AI approach, simply applying a standard implementation pattern is usually not enough to address a real business need.
The reason is straightforward: business problems are not abstract technical challenges. They are shaped by specific users, specific decisions, and specific workflows. A solution only becomes valuable when it fits the context in which people actually work.
Too often, teams begin with the technology rather than the problem. They ask, “How do we use RAG here?” or “Can we build a knowledge graph for this?” when the more important question is, “What exactly are users trying to do, and what information or capability would make that easier, faster, or more reliable?” Without that grounding, even a technically impressive solution can fail to gain traction.
Take knowledge graphs as an example. On paper, the idea seems broadly applicable: extract entities and relationships from free-form text, structure them, and enable richer search, reasoning, or discovery. But once you move from concept to implementation, the real complexity appears. What information should actually be extracted? Which entities matter? Which relationships are meaningful? What level of granularity is useful? The answers vary dramatically across organisations, domains, and even teams within the same company.
For one organisation, the priority may be to identify products, suppliers, contractual obligations, and delivery risks from documents. For another, it may be to map scientific concepts, experimental results, and citations across research literature. Even within a single business, different departments may care about entirely different views of the same source material. A legal team may focus on obligations, liabilities, and clauses. A compliance team may care about controls, exceptions, and policy mappings. An operations team may look for process dependencies, bottlenecks, and escalation paths. The same document can produce very different “knowledge” depending on who needs to use it and why.
This is why building useful knowledge systems often involves far more than implementing a generic extraction pipeline. In practice, much of the real work lies in defining schemas, scopes, and taxonomies that reflect the business problem accurately. These are not merely technical design decisions; they are interpretations of what the organisation considers important. They determine what gets captured, what gets ignored, and what users are ultimately able to ask or discover.
That tailoring work is often ongoing rather than one-off. As use cases mature, teams learn that initial schemas may be too broad, too narrow, or not aligned with how users actually think. Taxonomies evolve. Definitions need refinement. Edge cases emerge. Stakeholders disagree on terminology. What looked like a straightforward information extraction task turns into a deeper exercise in understanding the business itself.
The same principle applies beyond knowledge graphs. RAG systems, for example, are often presented as if the main challenge is chunking, embedding, retrieval, and prompting. Those are important components, but they are only part of the picture. A useful RAG application depends on knowing what users are trying to retrieve, what counts as a trustworthy answer, how much context they need, how the output fits into their workflow, and what risks exist if the answer is incomplete or wrong. The technical pattern may be reusable, but the business solution never is in a fully standardised way.
This is why successful AI and knowledge solutions tend to be designed from the use case outward, not from the technology inward. The most valuable work often happens before implementation: identifying users, understanding their decisions, mapping their workflows, and clarifying what “better” actually means in their context. Only then does it become possible to decide how a technology such as RAG or a knowledge graph should be configured, constrained, and evaluated.
In other words, the challenge is not simply to deploy a technology. It is to shape that technology into something that reflects the reality of the business. Standard methods can provide a starting point, but they are rarely the finished answer. Real value comes from adaptation: translating messy, domain-specific, human workflows into systems that support actual work.
That is why projects in this space so often involve repeated schema design, taxonomy refinement, and scope definition. These activities are not side tasks or implementation details. They are central to solving the business problem itself. The technology may be the enabler, but the real solution lies in how well it is aligned with the people, processes, and decisions it is meant to support.