AI · RAG
AI search across internal knowledge and documentation.
A general model doesn't know your contracts, procedures or project history. RAG connects it to your knowledge and requires a cited source.
When clients usually bring us in
- staff hunt for information across documents
- documents are reviewed by hand
- support answers the same questions repeatedly
- you need classification or data extraction
- you want AI inside the business process, not beside it
AI isn't always the right answer
If plain automation solves the process, we don't add AI because it's fashionable. We'll tell you where AI pays off and where it doesn't.
What this means for you
- Less time spent looking for information.
- Less manual retyping of data.
- Faster processing of documents and requests.
- More consistent answers from your team.
- A clear trail of where each answer came from.
Problem → solution
What we can index
- internal procedures and policies
- contracts and quotes
- technical documentation
- project archive
- minutes and reports
- support knowledge base
- web content and catalogues
How we keep it trustworthy
Cited source
Every answer links to the document and section it came from.
Permissions
A user only sees what they're allowed to see anyway.
Fresh data
The index refreshes when documents change.
How a RAG system is built
RAG means the model answers from your documents, retrieved for each question, rather than from general knowledge. The quality of the answer therefore comes mostly from the work done before the model: what is in the index, how it is split, how it is labelled and what actually gets retrieved.
Source inventory
which documents, where they live, who maintains them and which version is current
Access
who may read what; those rights carry into the system and are not lost
Parsing
turning PDFs, Word files, tables and scans into text
Normalisation
removing headers, footers, repeated boilerplate and noise
Chunking
splitting into meaningful passages; too short loses context, too long dilutes retrieval
Metadata
source, date, version, department, validity and confidentiality
Embeddings
converting passages into a form suitable for meaning-based search
Indexing
storing them in the search index together with metadata and permissions
Retrieval
finding the passages that actually matter for the question
Ranking
re-ranking the results so the best passage comes first
Context assembly
what is sent to the model, and how much of it
Generation
an answer with the sources it came from
Evaluation
a set of questions with expected answers, measured regularly
Updates
how new document versions enter the system and how old ones are retired
What RAG does not solve on its own
RAG is not a guarantee of a correct answer
Quality depends on the sources, the way documents are split, the metadata, the retrieval strategy, the access rules and the evaluation. If the sources contain an outdated procedure, the system will faithfully repeat the outdated procedure.
- several versions of the same document with no clear validity
- documents nobody maintains
- poor-quality scans
- tables and annexes that fall apart when converted
- knowledge that exists only in people's heads
Access control in a RAG system
If a user has no right to the source document, the AI must not reveal its content merely because the document is in the index. So permissions are enforced at retrieval - everything the user may not see is excluded during the search step, not filtered out at display time.
Question and answer logs can be sensitive in themselves, so the same retention and access rules apply to them as to other business records.
Measuring quality
It makes no sense to judge an AI system on a handful of random questions. We build an evaluation set from real work, with known correct answers and known sources, and re-run it on every change - a new model, a different chunking strategy, additional sources.
- an evaluation set with known answers
- whether the right source was retrieved
- whether the answer follows from that source
- checks for claims the source does not support
- expert scoring for borderline cases
- re-measurement on every change
How we design the AI
Use case
We start by defining which decision or step the AI takes over, and where it must stop.
Data
We map sources, quality and access. Without organised data, AI cannot produce a dependable result.
Architecture
We choose the model, the retrieval approach and the point where AI plugs into the existing process.
RAG, agents, tools
The agent uses your systems through their APIs, within the permissions you define.
Keeping AI in control
Guardrails
What the AI may and may not do, when it must ask a person and when it stops the process.
Human in the loop
A person approves the sensitive steps. Each approval is logged together with the reason.
Evaluation
Regular checks on sample sets, so we notice when answer quality drifts.
Monitoring and cost
Tracking success rate, failures and cost per task, with alerts when something deviates.
Related work
FAQ
Does our data go into a public model?
No, unless we explicitly agree to it. You define the access and the boundaries.
What if the AI gets something wrong?
A person approves sensitive steps, every step is logged and can be replayed.
When is AI not the right answer?
When plain automation or a system integration solves it. We say so up front.
Related reading
Related solutions
Sounds like your project?
Send us the project description, your existing system, the tender documents or the event date.