Internal AI Assistant: How to Connect Claude to Your ERP, Teams and Wiki

Your team already uses ChatGPT. But ask it "what's the delivery date on this order?" or "how does our warranty process work?" and the AI goes silent. It doesn't know your data — and that's exactly where the real value sits.

This is the question we hear most often after companies run their first AI experiments: how do we get AI to answer from our own data? In this article we explain, in plain language, how an internal AI assistant works. As an example, we'll use the solution we're currently building for Kodumaja.

Why ChatGPT can't answer your questions

ChatGPT and other public AI tools are trained on the public internet. They write a decent email and summarize a document. But they have no idea what's in your warehouse, what your quality manual says, or what price you agreed with a client.

In most companies, finding that information still works the old way. An employee digs through the ERP, hunts around the file server, asks a colleague on Teams. An experienced employee knows where to look. A new hire burns half a day on the same answer.

AI adoption among Estonian companies rose from 14% to 22% in a year. But most of that is generic conversational AI that never sees company data. The next step is connecting AI to your own systems.

What is an internal AI assistant?

An internal AI assistant is a system where an AI model — in our projects, usually Claude — is connected to the company's own data sources. An employee asks a question in plain everyday language and gets an answer grounded in your ERP, your documents and your knowledge base.

Kodumaja is a good example. In a large manufacturing company, knowledge is scattered: some of it in the ERP, some in Teams conversations, some in the wiki, some in the heads of experienced employees. We're building them an assistant that connects Claude to three sources: the ERP, Microsoft Teams, and the company knowledge base. The result: you ask a question and get an answer, without needing to know which system the information lives in.

One important distinction: this is not yet an AI agent that completes tasks on its own. An assistant answers questions and finds information. An agent acts. In practice, most companies start with an assistant — and that's the right order.

How it works: the architecture in five steps

The technical term is RAG (retrieval-augmented generation). The name sounds complicated, but the principle is simple: search first, then answer based on what you found. Step by step, it looks like this:

1. An employee asks a question — in Teams or a web window, in plain language. For example: "What's the next delivery for project X?"
2. The system searches your company data — the ERP, the wiki, documents. The search works by meaning, not just keywords.
3. The retrieved information is handed to Claude together with the original question.
4. Claude composes an answer based only on that information, in clear language.
5. The employee gets the answer with source references — they can see which document or record it came from.

Here's what that looks like in daily work. A project manager types in Teams: "Have the windows ordered for site Z arrived?" The system pulls the order and delivery status from the ERP, and Claude writes the answer: "The order arrived in the warehouse yesterday, two line items are still in transit, expected Friday." Attached is a reference to the ERP record. Previously, the same answer would have meant logging in, searching, and probably a phone call.

Two things here are fundamental. First: the AI model is not trained on your data. The system reads the data fresh at the moment of each question. If a delivery date changes in the ERP, the next answer is immediately correct. Second: source references. The employee can always check where an answer came from. That preserves trust and reduces the risk of errors.

What to connect: ERP, Teams and the knowledge base

In the Kodumaja project we're connecting three sources. The same trio covers the needs of most companies.

ERP. This is where orders, stock levels, deadlines and prices live. It's the most valuable connection — and the most labor-intensive, because every ERP is a little different. The result is worth it: "what's the status of order Y?" gets answered in seconds, without logging into the ERP.

Microsoft Teams. The assistant has to live where the work happens. If getting an answer requires opening a separate app, nobody will use it. A chat window inside Teams means asking is as easy as messaging a colleague.

Wiki and knowledge base. Manuals, standards, process descriptions, frequently asked questions. Often this information exists — nobody can find it. The assistant makes years of accumulated knowledge usable again.

The same logic extends to other sources later: file server, CRM, email, production data. The smart move is to start with two or three sources that cover the most frequent questions.

What the company actually gains

The benefits are concrete and measurable:

• Answers in your team's language, straight from your data. Employees don't need to know where the information lives or how to query the ERP.
• Less time lost to searching. Typically, an employee saves 1–2 hours a day with AI. A large share of that comes precisely from information retrieval.
• Faster onboarding. A new hire asks the assistant what they would otherwise ask an experienced colleague. It costs the colleague nothing.
• Knowledge stays in the company. When an experienced employee leaves, their written-down manuals and decisions remain findable. The assistant keeps them alive.

A rough rule of thumb: if 30 employees each save even 30 minutes a day, that's over 300 working hours a month. Measure the investment against that.

When an off-the-shelf tool is enough — and when you need custom

Honest answer: you don't always need custom development. The choice depends on where your data lives.

Off-the-shelf connectors are quick to launch and cheap. But the moment an answer has to come from an ERP, a specialized database, or several systems at once, they hit a wall. In Kodumaja's case, the ERP connection was exactly why an off-the-shelf solution wasn't enough.

Our recommendation: start by mapping where your most valuable questions and answers live. Only then decide whether to build or buy. That mapping is part of our AI audit, which gives you a clear plan before you put a cent into development.

Security: who controls the data?

This is the most justified concern leaders raise. Three principles every internal assistant must follow:

The data stays under your control. AI services under business contracts don't use your data to train models. And if even that's not acceptable, the entire solution can run on your own server. Open-source models are genuinely ready for this — TildeOpen, for example, is a large model built for European languages, including Estonian. Cost ballpark: cloud AI roughly €300–800 per month, your own GPU server €2,000–5,000 one-off.

Permissions carry over. The assistant may only show what the person asking is allowed to see. Salary data and board documents must not leak into general search. This is a matter of architecture, not good intentions.

A human stays in charge of decisions. The assistant answers and cites; a person decides. Source references make verification easy. And before launch, we test the system against attacks — we described what those look like in our article on the OWASP LLM Top 10 security risks.

How we build a project like this

Our approach has three steps: Map → Build → Adopt (Kaardistame → Ehitame → Juurutame).

1. Map. We find out which questions employees actually ask and where the answers live. That determines which systems get connected first.
2. Build. We connect Claude to the chosen sources, configure permissions, and test answer quality against real questions.
3. Adopt. We bring the assistant into Teams, train employees to use it, and measure whether time spent searching actually goes down.

The last step is the most underrated. A tool nobody uses saves nothing. That's why every development project we run comes with adoption and training built in.

The rough timeline: mapping takes a couple of weeks; the first working version with two or three sources is typically ready in a few months. We don't recommend starting with a two-year megaproject. Better to launch a narrow, working version, measure the result, and expand from there. That way leadership makes decisions based on real usage data, not promises.

Start with one question

Ask your team: "What information do we spend the most time hunting for?" That one question shows where your internal AI assistant should start.

If you want to know how a solution like this would work with your ERP, Teams and knowledge base, let's talk for half an hour. We'll look at your systems and tell you honestly whether an off-the-shelf tool is enough or whether it's worth building your own.

Book a free consultation →