Knowledge management is one of the oldest promises in enterprise software, and one of the most often broken. Generative AI has revived it: for the first time, a machine can read an organisation’s policies and manuals and answer a question in a sentence. The research from the large analyst and consulting firms says the opportunity is real, and also explains why so many projects stall between the pilot and the people who need the answers. This is a summary of that evidence, and a practical specification for what an enterprise answer engine has to do before you can trust it.
A note before we begin. Figures below are cited to their source with the year, so you can judge how current each one is. This is an architectural view, not legal advice, and it stays at the category level rather than scoring named products.
The oldest problem in the office
Every organisation writes down how it works: leave rules, travel limits, delegation of powers, product warranties, credit procedures, academic regulations. Then the writing becomes the problem. The answer to a simple question sits on page 14 of a PDF in a folder that three people know about, so staff ask a colleague, call the HR desk or guess.
This has been measured for a long time. A 2012 McKinsey Global Institute report, The social economy, estimated that knowledge workers spent close to a fifth of their working week looking for internal information or tracking down colleagues who could help. It is an old estimate, built on earlier survey data, and it is often restated as a precise number of hours a day, so treat it as an order of magnitude rather than a measurement. The newer evidence says the problem hasn’t gone away. Gartner’s survey of 4,861 employees across countries including India found that 47% of digital workers struggle to find the information or data they need (May 2023).
Earlier generations of knowledge management tried to fix this with portals, taxonomies and enterprise search. They helped people find documents. They didn’t answer the question, and that last step is the one people actually need.
From finding documents to answering questions
Generative AI changes that last step. Gartner now tracks enterprise AI search as a market of its own, and its Market Guide for Enterprise AI Search (September 2025) describes the shift as a move from retrieving information to synthesising it: answers first, not lists of documents.
The technique behind most of these systems is retrieval-augmented generation, usually shortened to RAG. Instead of relying on what a language model learned in training, the system first retrieves passages from the organisation’s own documents and then asks the model to answer from those passages. Done well, the answer is grounded in your policy, not in the internet’s average opinion of what a policy usually says.
Why so many knowledge projects stall
If the technique works, why do so many projects stop at the pilot? The research points to four recurring reasons.
1. The data isn’t ready. Gartner warned in February 2025 that organisations will abandon 60% of AI projects that aren’t supported by AI-ready data through 2026. For knowledge use cases, “ready” is concrete: the current version of each policy, superseded versions retired, scans readable, and the right documents grouped for the people who should see them.
2. The answers are sometimes wrong. Retrieval reduces errors; it doesn’t remove them. Stanford RegLab and HAI tested commercial legal research tools built on retrieval and found they still produced hallucinated answers more than 17% of the time (2024), well below a general chatbot but far from zero. A system that never admits it doesn’t know is a liability in a policy context.
3. Permissions leak. A knowledge assistant that can read everything will happily answer anyone with anything. The OWASP Top 10 for LLM Applications (2025) lists sensitive information disclosure and weaknesses in retrieval stores among the main risks, and recommends permission-aware retrieval. Many rollouts pause at exactly this point, when the security team asks who can see what.
4. The documents leave the building. When the sanctioned tool is slow to arrive, people use whatever is open in their browser. The 2025 KPMG and University of Melbourne study of 48,000+ people in 47 countries, Trust, attitudes and use of artificial intelligence, found that 48% of employees admit using AI in ways that break company policy, including uploading sensitive company information into free public AI tools. Leadership has noticed. In Deloitte’s State of AI in the Enterprise (January 2026, 3,235 leaders in 24 countries), 77% said they factor an AI solution’s country of origin into vendor selection, and 83% rated data residency and in-country compute at least moderately important.
Seven requirements for an enterprise answer engine
Put the evidence together and a specification falls out. Before an answer engine goes in front of staff, students or customers, it should meet all seven of these.
- Answers only from approved documents. Facts come from the organisation’s material, not from the model’s general knowledge or an uninvited web search.
- An explicit, machine-readable “not found”. When the documents don’t say, the system says so, in a form software can check, so no application has to guess whether the model guessed.
- Sources with every answer. The reader can open the document and verify anything that matters.
- Permissions that follow the person. The engine sees exactly what the asker could open themselves, and loses access the moment they do.
- No retention. Questions often reveal more than documents do: a planned restructuring, a customer complaint, a disciplinary case. The engine shouldn’t keep them.
- Numbers computed, not read. A total over a spreadsheet should be calculated from the data, not lifted from whatever text happened to match.
- Reach into every application, inside your boundary. A chat window is one place people ask. The intranet, the help desk, the branch app and the team chat bot are others. The engine should be callable from all of them, and run where your documents already live.
Build the pipeline, or call an answer API?
You can meet these requirements by building a RAG pipeline: a document parser and OCR for scans, a chunking strategy, an embedding model, a vector database, a permission layer that mirrors your access rules, prompts, a model to host, an evaluation set and the monitoring to keep it honest. Teams with unusual retrieval needs and engineers to spare sometimes should. For most organisations, the pipeline is not the point. The answer is.
The alternative is an answer API: the documents live in a governed workspace, and applications send a question and get back an answer, its sources and a flag that says whether the documents covered it. The platform owns the retrieval, the permission checks and the model, and the application owns the experience around the answer.
How ZenithAI’s Enterprise Knowledge API meets the seven
ZenithAI runs on an organisation’s own servers. Its Enterprise Knowledge API, the /workspace endpoint released on 15-10-2026, answers from the same workspaces people already use in ZenithAI chat. Here is how it lines up against the specification.
| Requirement | What /workspace does |
|---|---|
| Approved documents only | Answers come only from the workspace’s documents. The endpoint never searches the web, even if the question asks it to. |
| Machine-readable “not found” | found: false, with an answer that says the documents don’t cover the question and names the documents checked. |
| Sources | Every answer lists its source documents. Ask a single document and its source is marked as definitely used. |
| Permissions follow the person | An API key answers as its owner and sees exactly the workspaces they can open in the app; removing their access removes the key’s access at once. |
| No retention | No chat is saved and the question and answer aren’t kept on the server. Logs hold ids, counts and timings, not content. |
| Computed numbers | Totals and averages over a CSV or Excel file in the workspace are calculated, and the answer is marked as computed. |
| Every application, inside the boundary | A REST call with JSON, plain text or streaming responses, served by your own ZenithAI deployment with no external model API in the path. |
The limits are stated plainly too. Today a call asks the whole workspace or exactly one document; choosing several at once is planned. The API honours your existing sharing, including any mistakes in it, so review workspace membership before connecting an application. And it isn’t in the 4.6.0 installer: it ships with the next installer. Developers can read the guide with working code and the full API reference.
The India lens
For Indian organisations, two regulatory threads make the “inside your boundary” requirement more than a preference. Under the Digital Personal Data Protection Act, 2023, the organisation stays responsible for reasonable security safeguards over personal data, including data handled by its processors. The DPDP Rules were notified on 13-11-2025, with most obligations applying from 13-05-2027. Every document sent to an outside AI service adds a processor to that chain of accountability. The law doesn’t forbid that, but it does make each one something to contract for, secure and answer for. (Our DPDP countdown checklist covers the dates in detail.)
For banks and NBFCs, the RBI’s FREE-AI committee report of August 2025 brought AI inventories, audits and oversight of AI vendors into the governance conversation. An answer engine that runs inside the institution, keeps no questions and names the circular it quoted is simpler to inventory and audit than one that doesn’t. Our RBI AI readiness checklist maps those expectations in more depth.
When a cloud tool is still the right call
If the documents are already public, if no personal or confidential material is involved, or if you are still testing whether people will use an answer engine at all, a hosted tool can be the faster first step. The case for an on-premises answer API is strongest when the documents are confidential or regulated, when the questions themselves are sensitive, or when the knowledge is a large part of why customers and citizens trust the organisation. Many organisations will run both, deliberately, for different workloads. Our private AI vs cloud AI framework walks through that choice.
A practical first 30 days
- Pick one workspace with a clear owner, such as HR policies or a product manual set. Remove superseded versions.
- Collect 50 real questions from the people who answer them today: the HR desk, the help desk, the branch operations team.
- Run them and record three numbers: how often the answer was found, how often a found answer was right, and how often the right document was cited.
- Fix the gaps. Most “not found” answers point to a missing or out-of-date document, which is a useful audit in itself.
- Review access to the workspace, then connect one application, usually the intranet or the help desk, with a key from an account that sees only that workspace.
- Watch the not-found list every week. It is the most honest backlog your knowledge team will ever get.
Questions
What is AI for enterprise knowledge management?
Why do enterprise AI knowledge projects fail?
Is RAG enough to stop AI from making things up?
Should an enterprise answer engine run on its own servers?
How does ZenithAI answer questions from company documents?
/workspace endpoint. Both answer only from the workspace’s documents on the organisation’s own servers, list the sources, return found false when the documents do not say, follow the asker’s access and keep no record of the question or answer.Where to take it
If your organisation’s knowledge is the kind that can’t leave the building, request a demonstration and bring a handful of real documents and the questions your staff ask about them, including one the documents can’t answer. For the people side of the same idea, read One company, one answer: a private internal knowledge base, and for why every application should be able to call your AI, Private AI is an API, not just a chatbot.