Intelligence over your data, not over the internet
BiltIQ AI · · ~5 min summary
General knowledge is not what limits enterprise AI value. The constraint is access to your own unstructured data.
Frontier models have read the public internet. They have not read your master services agreements, your maintenance logs, your claims files, your drawing revisions, or eleven years of correspondence with your largest account. That material is where your operational knowledge lives, and it is in no training corpus anywhere — because you would have had to give it away first.
The comparison everyone runs is on the wrong axis
The instinctive question is which model is best. It produces a clean answer, and it measures a capacity that is not the bottleneck in enterprise work.
Consider what your organisation actually wants to ask. What did we agree with this supplier about price escalation? Which of our open claims have missed their SLA? What changed between revision 4 and revision 7 of this drawing? Every one is bounded by access to a specific private record. Not one is bounded by reasoning capability.
Give a competent mid-size model the supplier agreement and it answers correctly. Give the most capable model in the world no agreement and it produces a fluent, confident, wrong answer — which in a contractual context is worse than no answer.
The gap is structural, not temporal
A model can only know what was in its training corpus, and your material is not in one. Nor can it be: the moment it enters a public corpus it has stopped being private, which for most of it means it has stopped being valuable.
This is why the objection "models are improving, won't retrieval stop mattering?" has the answer backwards. As frontier models improve, what improves is their ability to reason over material you supply — which makes the supply mechanism more valuable, not less. Every capability gain accrues to whoever controls what goes into the context window.
Why model-first pilots disappoint
The standard pilot selects the strongest available model, connects it to a chat interface, and invites staff to try it. It reliably produces two findings: people were impressed by general tasks, and nobody could use it for the work that actually costs the organisation money — because that work requires knowing things the model has no way to know.
The pilot then gets written up as "the technology isn't ready." It demonstrated nothing of the kind. It demonstrated that a model with no access to your material cannot perform work that depends on your material.
There is a reliable tell: if every success story is a task where the user supplied the context by pasting it in, you have built a general assistant, not an enterprise system. The pasting is the retrieval layer, performed manually, by your most expensive staff.
Retrieval-first is a design brief, not a feature
If access to private, unstructured material is the constraint, every significant architectural decision follows from handling that material well:
- Business documents are hostile — scanned PDFs, merged spreadsheet cells, nested archives, quoted email history. So: 30+ format parsers with layout-aware chunking, which keeps a table a table and a clause attached to its heading. A naive extractor damages the document silently, and every downstream answer inherits it.
- Two kinds of question need two kinds of search — "find policy AB-4471" is lexical; "where did we agree to indemnify them?" is semantic and may never use the word. So: hybrid retrieval, BM25F plus dense vectors fused by reciprocal rank fusion, re-scored by a multimodal reranker.
- Business knowledge has structure and history — a question about a customer is a question about an entity, not a document. So: five layers of memory, from working memory through a knowledge graph to an immutable audit trail.
- Real work is multi-step — so: specialist agents with explicit budgets, circuit breakers, and per-project scope isolation. A single general agent with every tool and no limit is the most common failure mode in agentic deployments.
- The answer has to be defensible — so: citations to your own sources and a hash-chained record of what was retrieved, which model answered, and what was returned.
The economics point the same way
Retrieval-grounded and agentic workloads consume tokens by construction — the retrieved passages are the context. Under metered pricing your bill therefore scales with how useful the system has become.
Modelled at 700 tokens per query, $4 per million tokens and ₹88/USD, our mid-enterprise reference fleet costs ₹41.7 lakh and overtakes cloud API spend at 18 months at one million queries per month, 12 months at 1.5 million, and 9 months at two million. An entry deployment at ₹8.1 lakh crosses at four months.
Context length moves that further than hardware price does. At the same fleet and the same volume, a 1,500-token average context crosses at eight months and a 4,000-token context at three — while a 300-token workload never pays back inside 36 months. The architecture that makes the system valuable is the same one that makes owning it pay.
Where this is the wrong answer
Low volume that isn't growing, workloads that genuinely need frontier-only capability, and organisations with no platform capability and no appetite to acquire one should stay on cloud. Mixed sensitivity usually means a hybrid split, enforced in code rather than by staff discipline. And being a regulated organisation does not make every workload regulated — classify the workload, not the logo.
We decline build engagements where the right answer is a pure-cloud setup.
The question to take into the room
Not which model is best, but what does this system need to have read in order to be useful — and who is allowed to hold it.
Book an Architecture Consultation →
Companion pieces: The anatomy of an on-premise AI deployment · Multi-agent architecture for unstructured business data