All articles
·9 min

An internal AI assistant over your company's documents (RAG): how to cut the time your team wastes searching for information

The problem: the information exists, but nobody finds it in time

In a company of 80 people, knowledge isn't missing. There are procedures, contracts, old quotes, product manuals, decisions buried in email, files on SharePoint, and a Confluence nobody has touched since 2023. The problem isn't that the information doesn't exist. The problem is that nobody finds it in the 3 minutes when it would actually be useful.

The numbers we see at clients are remarkably consistent:

  • 20-30% of an office worker's time goes to searching for, verifying, or reconstructing information that already exists somewhere
  • 4-6 hours/week per support or operations person spent answering the same internal questions
  • A "does anyone know where the EU returns procedure is?" on Slack costs, on average, 15 to 40 minutes across 2-3 people

For a company with 50 office employees and a loaded cost of €18/hour, 20% of time lost to searching means roughly €300,000/year of evaporated productivity. Not in one spectacular loss, but in thousands of tiny interruptions.

In 2026, the most concrete way to recover part of that money is not "yet another wiki". It's an AI assistant that searches your documents and answers with sources.

What a RAG assistant actually is (no hype)

RAG stands for *Retrieval-Augmented Generation*. In plain terms: an AI model that, before answering, searches your documents and builds its answer based on what it found, with citations.

The difference from a generic ChatGPT is fundamental:

  • A generic LLM answers from what it "learned" during training — it knows nothing about your contract with supplier X
  • A RAG assistant first searches your document base, then answers only based on what it found there, with a link to the source

Technically, the flow has 4 steps:

1. Ingestion — documents (PDF, Word, wiki pages, tickets, emails) are split into "chunks" and turned into numeric vectors

2. Indexing — the vectors are stored in a vector database (pgvector, Qdrant, Weaviate)

3. Retrieval — for a given question, the system finds the 5-10 most relevant chunks

4. Generation — the LLM receives the question + relevant chunks and writes the answer, with citations

The counterintuitive part: the value isn't in the model, it's in the retrieval. An excellent GPT with bad retrieval gives confident, wrong answers. An average model with good retrieval and clean sources is dependable.

Why a wiki isn't enough (and why ChatGPT isn't either)

A classic wiki has two problems: someone has to write it, and someone has to know *which term* to search for. A RAG assistant solves the second part — it understands the question in natural language, even when the phrasing doesn't contain the exact words in the document.

Off-the-shelf ChatGPT or Copilot solve natural language but can't see your internal documents — or, if they can via a generic connector, you have no control over what gets indexed, where the data goes, and who is allowed to see what. For an EU company, data governance is not optional: a contract with confidentiality clauses has no business being routed through a service without a data processing agreement.

Case study: a services firm with 120 employees

A client we worked with at NEXVA SYSTEM — a B2B services firm of 120 people — had the classic setup:

  • ~14,000 documents across SharePoint, Google Drive, and a half-abandoned Confluence
  • The support team fielded 30-40 repetitive internal questions daily ("what's the SLA for client X?", "where's the recurring-services contract template?")
  • Onboarding a new hire took 6-8 weeks before they were autonomous on procedures

What we built:

  • An ingestion pipeline that syncs documents daily from all 3 sources, respecting existing permissions (a person can't "ask about" what they're not allowed to see)
  • A vector store on PostgreSQL + pgvector (no exotic new infrastructure)
  • Hybrid retrieval: semantic search + keyword search, to catch both code names and meaning
  • An assistant available directly in Slack and in an internal web panel, with mandatory citations to the source
  • A "refusal threshold": if the system doesn't find sufficiently relevant sources, it says "I couldn't find that in the documents" instead of making something up

Results after 4 months:

  • Repetitive internal questions to the support team: -62%
  • Average time to find a procedure: from 8-12 min → under 40 seconds
  • Onboarding to autonomy: from 6-8 weeks → ~4 weeks
  • Investment ROI: 7 months

The detail that matters: real adoption only came once we added clickable citations. People don't trust an AI answer without seeing the source document. Without citations, usage was 15%. With citations, it climbed past 70% within two months.

The data you need and how to prepare it

The good news: you don't need a data lake. You need:

  • Access to the sources where the information already lives (SharePoint, Drive, Confluence, a folder of PDFs)
  • A clear permission model — who is allowed to see what
  • A bit of hygiene: remove old versions and obvious duplicates from the index

The most common mistake is indexing "everything", including 5 versions of the same contract. The assistant will inevitably cite the wrong version. Clean sources beat any model tuning.

Where a RAG assistant fails

Be honest when evaluating the technology:

Contradictory documents

If you have two procedures saying different things, the AI will cite both and confuse the person. The fix isn't technical, it's organizational: a single source of truth per topic.

Questions that need computation, not retrieval

"What's the margin on order 4471?" is not a RAG question, it's an ERP query. RAG is for textual knowledge, not for live numbers from transactional databases.

Tables and badly scanned PDFs

A crookedly scanned PDF or a complex table extracts poorly. This is where you need good OCR at ingestion, otherwise retrieval runs on corrupted data.

Expecting "zero mistakes"

A good RAG assistant reaches 85-92% correct and useful answers on questions covered by the documents. The rest must fail *gracefully* ("I couldn't find it"), not make things up. A system that can't say "I don't know" is more dangerous than useful.

The real cost of implementation

For a company with 50-200 employees and 5,000-30,000 documents:

| Component | Cost |

|-----------|------|

| Source audit + permission model | €3,000-6,000 |

| Ingestion pipeline + vector store | €6,000-11,000 |

| Hybrid retrieval + tuning + refusal threshold | €5,000-9,000 |

| Slack/Teams integration + web panel + citations | €4,000-7,000 |

| Initial total | €18,000-33,000 |

| Infrastructure + monthly LLM calls | €200-600 |

| Re-indexing and maintenance | €400-800/month |

The cost of LLM calls scares many decision-makers for no reason: for a volume of 2,000-4,000 questions/month, the inference bill is under €300. Retrieval filters the context, so you're not sending whole documents on every question.

How to start practically

1. Pick a single department — usually support or operations, where repetitive questions are densest

2. Measure now — how many internal questions circulate on Slack/email per day and how much time they eat

3. Index one source, not all — start with the procedures folder, not the entire Drive

4. 6-week pilot — 10-15 users, with mandatory citations and feedback on every answer

5. Expand after validation — add sources and departments only once the first group uses it daily

The biggest mistake is "let's index the whole company at once". Start narrow, earn trust with citations, then expand.

Conclusion

An internal AI assistant is not a research project, and it's not a gadget. For any company with more than 40 office employees and knowledge scattered across several systems, it's today one of the most concrete ways to recover time — with ROI visible in under a year.

The key isn't the model, it's the discipline around it: clean sources, respected permissions, mandatory citations, and a system that knows how to say "I don't know". The rest is predictable engineering.

Want us to estimate how much time your team loses searching for information and which part can be automated? Book a free consultation.

Want to discuss automating your processes?

Book a consultation