In brief
- A knowledge base with AI searches by meaning and builds an answer from your documents. It does not return a list of files that happen to contain the same words.
- The RAG approach: the system first finds the relevant passages in your documents, then the model answers from them and names the source, so you can check the answer.
- Access rights are applied at the search stage: an employee gets answers only from the materials they are allowed to see.
- The solution is deployed in your company's infrastructure or in an agreed cloud. You choose the setup at the start.
- Start with one source that has a clear owner, and with a set of real employee questions that you use to check the result.
What an enterprise knowledge base is and what AI adds
An enterprise knowledge base is one place that holds the regulations, instructions, product descriptions and answers to common questions that employees use. Usually it is a wiki or a section of an internal portal. The common problem: materials sit in different systems and folders, and you can find what you need only if you know what it is called and where it is stored.
A knowledge base with AI adds a search and answer layer on top of the storage. An employee types a question in plain words, for example "which documents are needed to approve a discount", and gets a short answer that says which document it came from. Keyword search returns a list of files where the same words appear. AI search takes the meaning of the question into account and builds an answer from what it finds.
Such a tool makes sense if you recognize your situation in the signs below. Count how many apply to your company and how often they recur during a working week.
- Employees spend time looking for the right document across different systems and folders.
- There are many regulations, instructions and knowledge bases, and no one can keep them all in their head.
- Newcomers ask colleagues the same questions instead of finding the answer themselves.
- Some materials can't be shown to everyone, and access must be separated by role.
How RAG works: document search and an answer with a source link
RAG (retrieval-augmented generation) is an approach where a language model answers not from memory but from the documents of your company that it has found. Picture an employee who first pulls the right pages from the archive, then writes an answer based on them and notes where each statement came from.
This matters because a model on its own does not know your regulations. When it lacks information, it can write a confident but wrong answer. When an answer is built from found passages and includes a link, you can check it: open the document and read the relevant place. You usually do not need to retrain the model on your documents. The knowledge is kept in a search index, not in the model itself. When a regulation changes, you update the document, and the answers change with it.
The system works in the steps below. You can check each one against test questions from employees before the solution goes into production use:
- Connecting sources: files, knowledge base pages, data from internal systems.
- Preparation: texts are split into small passages, and an index is built for each so the system can search by meaning.
- Search: for a given question, the system finds suitable passages among those this employee is allowed to see.
- Answer: the model writes it only from what was found and attaches links to the sources.
- If there are no suitable passages, a properly configured system says it did not find an answer in the documents.
Access rights and where the system runs
The question managers ask most often: what if AI shows an employee something they are not supposed to see? That is why access rights are applied at the search stage, not after it. The system knows who is asking and searches only among the materials available to that person's role. A passage the employee cannot access appears neither in the answer nor in the list of links.
Rights are either carried over from your systems (the employee directory, permissions in the document storage, roles in corporate services) or set separately by role and department. The principle is the same: minimum necessary rights. It is wiser to open less and expand on request than to fix a mistake after a restricted document has ended up in an answer.
The second question is where all this runs. The solution can be deployed inside your company's infrastructure or in an agreed cloud. If the materials contain personal data, the requirements of Federal Law No. 152-FZ (the Russian personal data law) are built in at the design stage. We decide in advance which fields the system needs at all, and some documents are connected in anonymized form. Choose the setup at the start. It determines access, the scope of work and which models you can use.
Company document search: which sources to connect first
Do not connect everything at once. Pick an area where there are many questions and the answers already exist in documents. The selection criterion is simple: the source has an owner, its content is largely up to date, and access is clear. Poor-quality scans, duplicates and drafts should wait. They make answers worse. Collect real employee questions. This set becomes your checklist for judging whether the system finds the answer and names the source correctly.
A start like this answers the main question, whether the approach works on your materials, before you connect other systems and invest in integrations.
Below are sources that usually suit a first pilot. Choose one of them and connect the others as results come in.
- Regulations and instructions of the department people turn to most often for reference: accounting, HR, IT support.
- An internal wiki or a knowledge base section that is already maintained and updated.
- The history of support questions and answers, a ready set of typical requests.
- Product descriptions, terms and price lists for the sales team.
- Data from accounting systems, such as 1C, as a next step, once work with documents is running well.
How to keep the knowledge base up to date
A knowledge base loses its value the moment people stop trusting it. So keeping it current is a separate task, not a by-product of the launch. You need to define how new and changed documents get into the index, who is responsible for the content, and how you will know the system has started to answer worse.
A log of questions that had no answer is a useful by-product: it shows which company regulations are missing. After launch, either your team runs the solution or a contractor takes over support. Choose the arrangement before launch and put it in writing, not after the first failure.
- Sync with sources: when a document changes, the index updates. When a document is deleted, it stops appearing in answers.
- The owner of each source keeps procedures up to date and withdraws outdated versions.
- Feedback in the interface: an employee flags a wrong or incomplete answer, and these flags are reviewed regularly.
- Query log: you can see what people ask most often and where no answer was found.
- Monitoring and a written procedure for failures, including rollback.
Common mistakes and questions to ask a vendor
Projects usually stumble on the same things. Teams connect all sources at once and get answers based on outdated duplicates. They don't define an acceptance criterion, so it's unclear when the solution counts as done. They put off access rights until later. They expect AI to replace tidying up the documents, when it only makes the mess visible. They don't assign an owner for the knowledge base after launch.
To screen out these risks early, ask your vendor the questions below. The answers will show how well they understand your task and what exactly you will get at the end of the project:
- How does the system handle access rights, and can we check this with test roles?
- Where will the documents and the index be stored, and who will have access to them?
- What does the system answer when the documents contain no answer?
- How is the source shown: as a link to the document or to the specific place in it?
- What criterion do you use to accept the result, and which real questions do you test it on?
- What do we get at the end: code, configurations, documentation, and to what extent?
- How is support organized after launch, and what is written into the contract?
How we approach enterprise knowledge search
We start with free discovery. We look at one of your processes, your sources and your constraints, and we tell you in writing whether AI is needed here. Sometimes it's enough to put the documents in order or to use a ready-made product. In that case, we say so plainly. Discovery takes 3–5 business days. You get a document with the boundaries of the solution and an acceptance criterion, and it stays with you in any case.
If the task is a good fit, we run a pilot on your real data. Enterprise knowledge search starts from $2,300 and from 3 weeks. We give the exact price and timeline after discovery. We check the result against a criterion agreed in advance, and if the solution falls short of it, we fix it at our own cost. We deploy in your infrastructure or in an agreed cloud. After launch, you can get support packages from $400 per month.
If your scenario goes beyond search, for example you need an assistant that answers from the knowledge base and performs routine operations in a CRM or 1C (a Russian ERP platform), that is a separate solution: AI agents and assistants, from $2,400 and from 3 weeks.
