Internal knowledge assistant
Policies, procedures, contracts and manuals, answered with citations and respecting who is allowed to see what.
AI Capabilities & Services
Generative AI & AI Agents (RAG)
Generative assistants and autonomous AI agents grounded in your own knowledge via retrieval-augmented generation.
The problem
A general AI assistant knows the internet and nothing about your organisation. It will answer a question about your policy confidently and wrongly, and the person who asked has no way to tell. Meanwhile the answer usually does exist — in a contract, a manual, a procedure or a ticket history — and finding it takes a person who knows where to look and has half an hour.
Who this is for
- Operations and support teamsThe right answer from the current document, not the one someone remembers
- Legal, compliance and policy ownersAnswers that cite the clause, so they can be checked
- Technical and field staffA manual that answers questions instead of one that must be read
What people use it for
Customer-facing assistant
Grounded answers on your published material, with a defined handover to a person the moment it is out of scope.
Document-heavy workflows
Extracting and comparing terms across tenders, claims, contracts or reports that nobody has time to read in full.
Agents that take an action
Where an answer alone is not enough: raising the ticket, drafting the reply, or fetching the record — inside defined permissions.
What it needs to work
- The documents themselves, and clarity on which version is authoritative
- Your existing permissions model — who may see which document
- Scanned material where it exists; OCR handles paper, with Arabic and English both supported
- A named owner per document set, because a knowledge base with no owner goes stale within a quarter
How it works
-
Ingest and structure
Documents are parsed, OCR'd where needed, and split into passages that keep their meaning — chunking badly is the most common reason these systems answer poorly.
-
Index with permissions
Passages are indexed together with who may see them, so retrieval cannot surface a document the asker has no right to read.
-
Retrieve, then answer
The question retrieves the relevant passages first; the model answers from those, not from memory. That order is what makes the answer checkable.
-
Cite the source
Every answer names the document and passage it came from. An answer without a source is not usable in a regulated process.
-
Decline when unsupported
Where retrieval finds nothing adequate, the assistant says so and routes onward. A system that always answers is a system that sometimes invents.
-
Evaluate continuously
Answers are scored against a held-out question set, and low-confidence or corrected answers are reviewed by the document owner.
How we deliver it
-
Scope and source review
Which questions matter, which documents answer them, and who owns each. Most failures here are content problems, not model problems.
-
Pilot on one corpus
One document set, one audience, with a real evaluation set written by the people who will use it.
-
Permissions and integration
Wiring to your identity provider and your document stores, so access is inherited rather than re-declared.
-
Rollout with ownership
Extending the corpus, with a named owner per set and a review rhythm — this is what stops it decaying.
Where it runs
- Fully on-premises, where documents cannot leave your network at all
- Private cloud on your own tenancy, with your own keys
- Open-weight models where a hosted API is not acceptable to your risk team
Security and governance
- Retrieval respects your permissions — the index cannot leak what the asker cannot open
- Every answer is traceable to its source passage
- Questions and answers are logged for review, with retention you set
- Human review on any answer that leaves the organisation or triggers an action
Timeline
A pilot on a clean, well-owned document set moves quickly, because the hard work is content rather than modelling. Where documents are scattered, contradictory or of unclear version, that is the project — and it is worth doing regardless, because no assistant can be more consistent than the material behind it.
What you receive
- A working assistant over your corpus, with citations and permission-aware retrieval
- An evaluation set and measured answer quality you can re-run after any change
- The ingestion pipeline, documented, so you can add sources yourselves
- Logging, review workflow and the escalation path for unsupported questions
- Guidance on ownership and review rhythm per document set
Related work
Published projects where we did this.
What this does not do
It answers from documents. It cannot know what was never written down, it cannot resolve two documents that contradict each other — it will show you both — and it is not a substitute for a decision that a person is accountable for. It also will not rescue a corpus nobody maintains: retrieval is only ever as current as the material behind it.
Questions we are asked
How do you stop it making things up?
By retrieving first and answering only from what was retrieved, citing it, and declining when retrieval finds nothing adequate. That is the architectural answer; the operational one is an evaluation set you re-run after every change.
Will our documents be used to train a model?
No. Retrieval does not train on your content, and where a hosted model is unacceptable we deploy open-weight models inside your environment so nothing leaves it.
Does it work in Arabic?
Yes, including mixed Arabic and English documents and scanned Arabic material through OCR. Mixed-script corpora need their retrieval tested specifically, and that is part of the evaluation set rather than an assumption.
About the figures on this page
This page describes capability and method. It does not publish accuracy figures, throughput numbers or delivery dates, because those depend on your data, your systems and your scope — and a number published here would be wrong for most readers. You get them, in writing and against your own data, at scoping.
A first call is a technical conversation, not a pitch: what you have, what you need, and whether this is the right approach at all.
Built on the Unified Intelligence Layer
Every InsAI product runs on the same four-stage backbone.
- 1
Data Integration
ERP · IoT · BIM · CRM
- 2
AI Models & Predictive Engines
Forecasting, detection, optimization
- 3
Automation & AI Agents
Acting on predictions, end to end
- 4
Real-time Dashboards & Decision Systems
From the floor to the boardroom
Generative AI & AI Agents (RAG)
Generative assistants and autonomous AI agents grounded in your own knowledge via retrieval-augmented generation.