Home / Insights / Generative AI and LLMs
Generative AI and LLMs
How to Build an Internal AI Knowledge Assistant for Your Company
A practical plan for an internal AI knowledge assistant: define users and approved sources, design retrieval with citations, preserve access boundaries, evaluate usefulness and failure modes, plan costs and roll out to a bounded group.
TopicsGenerative AI and LLMsBusiness Operations and Integration
Key takeaways
- Start with real questions from a defined user group and a short list of approved sources.
- Permissions are the hardest part: the assistant must never reveal content a user cannot already access.
- Evaluate faithfulness to sources and safe refusal before rollout, and roll out to one group first.
On this page
Most companies have knowledge scattered across shared drives, wikis, ticket systems and inboxes. An internal AI knowledge assistant lets staff ask questions in plain language and get answers with links to the source documents. Building a useful one is less about the model and more about sources, permissions, evaluation and rollout. This guide covers each step.
Define users, questions and approved sources
Start narrow:
- Users: one department or role, for example support agents or HR staff.
- Questions: collect 50–100 real questions from tickets, chats and interviews, with known correct answers.
- Approved sources: the documents that should be used to answer, with owners who keep them current.
- Out of scope: topics the assistant must not answer, such as legal or medical advice, or confidential HR cases.
This scope becomes your evaluation set and your rollout plan.
Design retrieval and source references
The common architecture is retrieval-augmented generation (RAG): the system searches your documents for relevant passages and gives them to the model to answer from, with citations. For background on when to use retrieval versus fine-tuning, see RAG or fine-tuning?.
| Component | Role | Design choices |
|---|---|---|
| Connectors | Pull documents from sources | Which systems, how often, incremental sync |
| Parsing and chunking | Turn documents into searchable passages | Respect headings and tables; keep metadata |
| Index | Store passages for search | Keyword plus vector (hybrid) search |
| Permission filter | Limit results to what the user may see | Filter by user and group at query time |
| Answer generation | Write the answer from retrieved passages | Instructions to cite and to abstain when unsure |
| Interface | Where users ask | Web app, Teams, Slack, intranet |
| Logging and feedback | Learn from use | Ratings, flagged answers, unanswered questions |
Architecture of a permission-aware knowledge assistant.
Architecture diagram (text)
- User asks a question in the assistant interface.
- The system identifies the user and their groups.
- Search retrieves candidate passages filtered by those groups.
- The model drafts an answer using only the retrieved passages and cites them.
- If no relevant passage is found, the assistant says so and suggests who to ask.
- The answer, sources and user feedback are logged for evaluation.
Preserve access boundaries
An assistant must not become a way around document permissions. Practical rules:
- Filter at retrieval time. Search should only return passages from documents the user can access. Microsoft’s documentation for Azure AI Search, for example, describes two approaches: built-in document-level access control lists, and security filters that store group identifiers on each document and filter queries by the user’s groups.
- Synchronise permission changes. When access changes in the source system, the index must update.
- Handle deletion. Removed documents must disappear from the index promptly.
- Avoid over-broad service accounts. Connectors should read only what the assistant is meant to use.
- Log access. Keep an audit trail of questions and sources returned.
Evaluate usefulness and failure modes
| Metric | What it measures | How to test |
|---|---|---|
| Retrieval accuracy | The right passages are found | Check retrieved sources against the expected document |
| Faithfulness | Answers stay true to the sources | Reviewers compare answers to cited passages |
| Safe abstention | Assistant declines when sources do not cover the question | Include unanswerable questions in the test set |
| Permission correctness | No restricted content appears | Test with users from different groups |
| Usefulness | Users find answers helpful | Ratings and task completion in pilot |
| Human handoff | Users can reach a person when needed | Check escalation path and context passed |
Evaluation worksheet. Run before rollout and after every significant change.
Common failure modes include outdated documents, duplicate versions with conflicting answers, tables lost during parsing and questions that need information from several sources. Each one is easier to fix when you can see which passages were retrieved.
Want help building the evaluation set for your assistant?
Plan deployment and operating costs
Decide where the assistant runs and which model it uses based on data policy:
- Hosted model APIs: fastest to start; review data-retention and regional settings.
- Cloud services in your own account: keep indexes and processing within your cloud environment.
- Private deployment: open-weight models hosted in your environment for strict requirements.
Operating costs include indexing and storage, search queries, model usage per question, hosting, monitoring and the time of content owners and reviewers. Check current provider pricing when you calculate, and see AI chatbot development cost for a usage-based cost model.
Roll out to a bounded user group
- Pilot group: 10–30 users from one department.
- Feedback loop: in-app ratings and a way to flag wrong answers.
- Weekly review: unanswered questions, low-rated answers and source gaps.
- Content fixes: update or retire documents that cause wrong answers.
- Expand gradually: add departments and sources once quality targets are met.
Make clear to users that answers include sources for verification and that the assistant can be wrong.
Frequently asked questions
Do we need to train a model on our documents?
Usually not. Retrieval lets the assistant use current documents without training. Fine-tuning may help with format or style later.
Can it work with SharePoint, Google Drive or Confluence?
Yes, through connectors. Check that permissions from each source can be applied in the index.
How do we stop it from making things up?
Instruct it to answer only from retrieved passages, show citations, include unanswerable questions in testing and monitor faithfulness.
Has PoliteTech deployed enterprise knowledge assistants?
We offer enterprise knowledge search as a service. Our public portfolio includes generative AI and natural language processing projects, and a team messaging tool with built-in AI that summarises conversations and drafts replies; ask us for relevant details during a scoping call.
Sources and methodology
Facts in this article were checked against the sources below on 5 November 2026. Directory data (ratings, review counts, rate bands and team sizes) changes over time and is shown as published on the date accessed. Illustrative examples are labelled as such and are not quotes.
- Microsoft Learn: Security filters for trimming results in Azure AI Search — accessed 5 November 2026. Security filter pattern; built-in document-level ACL support recommended where possible
- PoliteTech Insights: RAG or fine-tuning? — accessed 5 November 2026. Retrieval background
- PoliteTech: Enterprise Knowledge Search — accessed 5 November 2026. Service scope
Related reading
Continue your research
Want your team to find answers faster?
Tell us where your knowledge lives and who needs it. We will outline an assistant with permissions, citations and a safe rollout plan.
