Skip to main content
Possible SetupAI & Knowledge

Internal Knowledge AI: On-Premise RAG Assistant

A RAG chatbot answers team questions from Confluence, Jira and Git repos, fully on-premise, with source citations. Demo reference architecture.

Industry
Engineering · Knowledge management
Build, estimated
8 weeks

At a glance

It starts with
Employee Question
The machine handles
9 of 9 steps
A person keeps
Nothing — it runs end to end
Bottom line
<30 secSearch Time per Question

The problem

"Ask Markus, he knows." — Markus is on vacation. Or left the company three months ago.

The knowledge exists: in Confluence pages, Jira tickets, README files, old architecture decisions. But nobody finds it. So the same question gets asked in the team chat for the fourth time, the senior developer gets interrupted for the fourth time — and the documentation that would have answered it stays unread.

The obvious shortcut — pasting internal docs into a public AI tool — is off the table for many companies. Source code, customer data, trade secrets in someone else's cloud? Exactly.

This showcase demonstrates the other way: a knowledge AI that runs inside your own network, only states what it can back up with sources, and only shows what the person asking is allowed to see.

Development and engineering teams lose time every day searching for knowledge: the answer exists somewhere in Confluence, Jira, GitLab or on network drives — but the search takes 20 to 30 minutes or ends at the most experienced colleague, who then can't get their own work done. For new hires, onboarding drags on for months because knowledge is only passed on by word of mouth.

At the same time, data protection and IP protection rule out the easy solution: internal documentation, source code or customer data must not be copied into public AI services. In regulated or safety-critical environments there's an additional constraint: not everyone is allowed to see everything. A knowledge chatbot that ignores permissions would be a bigger risk than no chatbot at all. And a chatbot that invents convincing-sounding answers when it lacks knowledge destroys trust faster than it creates value.

A woman reads a printed guide by the window, a highlighter in her hand.

Staged scene

Wednesday, 2:40 pm

Where was the travel expense rule again?

The answer is somewhere in the wiki, a PDF or an email from 2023. The knowledge AI finds it and says where it comes from.

The process, step by step

Scroll through. The diagram stays put and highlights the step you are on.

The workflow01 / 09
  1. 01

    Employee Question

    Slack / Web UI

    An employee asks a question — directly in the Slack channel or via the internal web interface. For example: "How do we deploy service X to the staging environment?"

  2. 02

    SSO & Permissions

    Keycloak

    The system verifies who is asking via single sign-on (Keycloak) — and loads their groups and permissions. These determine which knowledge sources are eligible for the answer at all.

  3. 03

    Vector Search

    Qdrant, ACL-filtered

    The question is converted into a vector and searched against the Qdrant database. Crucially: the search is hard-filtered to documents the person asking would be allowed to see in the source system.

  4. 04Branch

    Sources found?

    The system decides: are there enough relevant, reliable text chunks for a well-founded answer — or not?

  5. 05

    On-Prem LLM

    Generate answer

    The locally hosted LLM (Ollama on your own GPU hardware) formulates the answer exclusively from the retrieved chunks. It must not invent anything — every statement has to be backed by a source.

  6. 06

    Honest Gap

    Name the expert

    No reliable source? Then the system doesn't make something up — it answers honestly: "I don't have a documented answer for that" — and names the responsible subject-matter expert.

  7. 07

    Answer + Sources

    Links & dates

    The answer is delivered with citations: links to the Confluence pages, Jira tickets or READMEs, including the date of their last update. Every statement is verifiable.

  8. 08

    Audit Log

    GDPR retention

    Question, answer and the sources used are recorded in the audit log — with defined retention periods under GDPR. It stays traceable who retrieved which knowledge and when.

  9. 09

    Complete

    Feedback captured

    The employee rates the answer with one click. The feedback improves retrieval quality and systematically reveals documentation gaps.

What changes

Possible setup, not a packaged product

The figures are modelled target values for a possible setup, derived from industry benchmarks and our own tests. They do not come from a customer project; real values depend on your business. We do not sell this setup as a finished product: we measure where your bottleneck is, then build with your team. For systems that require certification (e.g. HIS, gematik, DATEV-certified) we work with specialised partners.

Before vs. After

AspectBeforeAfter
Knowledge SearchBefore: 20–30 min across Confluence, Jira, chatsAfter: One question, answer in seconds
Data FlowBefore: Copy-paste into external AI toolsAfter: 100% on-premise, nothing leaves the network
ReliabilityBefore: Outdated docs, hearsayAfter: Every answer with source link and date
Access ControlBefore: Knowledge shared ad hoc, uncontrolledAfter: Answers respect permissions

Technology

Technology Stack

n8nOllama (On-Premise LLM)Qdrant Vector DBConfluence APIJira APIGitLabKeycloak SSODocker

Integrations

Systems this setup can connect to

Ollama (On-Premise LLM)AI Engine
Locally hosted open language model on your own GPU hardware — answer generation without external APIs
QdrantVector Database
Semantic search across all indexed knowledge sources with per-request ACL filtering
Confluence & JiraKnowledge Sources
Nightly synchronization of pages and tickets, including their original permissions
GitLabCode & Docs
READMEs, architecture decisions and wikis from the repositories — with secrets filtering
KeycloakSSO & Permissions
Single sign-on and group resolution — determines which sources are searched per user

Security & Compliance

What the setup takes care of

100% On-Premise
LLM, vector database and workflows run entirely on your own infrastructure. No external AI APIs; deployable even in air-gapped networks.
Permission Inheritance
Access rights from Confluence, Jira and GitLab are enforced on every search. Nobody gets answers from documents they couldn't open themselves.
Secrets Redaction
API keys, tokens and credentials are detected and removed before indexing — they never reach the search index at all.
Audit Log & GDPR
Every question and answer is logged in an audit-proof way, with defined retention periods and GDPR information-request capability.

Frequently Asked Questions

No. The language model runs via Ollama on your own hardware, as do the vector database and all workflows. There are no API calls to external AI services — neither during indexing nor when answering. The architecture also works in networks without internet access.
Through three mechanisms: the LLM may only answer from the retrieved document chunks (retrieval-augmented generation), every statement requires a source citation with a link, and if the search yields no reliable source, the system honestly answers "I don't know" instead of guessing. Answer quality is additionally monitored via spot-check reviews and user feedback.
Before indexing, every document passes through a redaction pipeline that identifies and removes API keys, tokens, credentials and personal data using pattern- and AI-based detection. Sensitive content never reaches the search index in the first place — which is more robust than filtering it at output time.
In this reference architecture: Confluence, Jira and GitLab. In principle, any source with an API or file access — SharePoint, network drives, internal databases or requirements management systems. The n8n indexing pipeline is modular; new sources are added as an additional sync branch.
Less than commonly assumed. For teams of up to around 200 users, a single server with a current GPU is usually sufficient, since requests are short and queue well. The model size is matched to the hardware — for knowledge questions with source context, mid-sized open models already deliver very good results.