What an Internal AI Assistant Actually Costs in the DACH Region (2026)

A leader asks a simple question: what does an internal AI assistant over our company documents actually cost per person per month? The answer they get back is usually one of two unhelpful things. Either a scary five-figure number that assumes a self-hosted GPU cluster nobody needs, or a hand-wave that says "almost nothing, tokens are cheap now." Both are wrong, because the real cost of a RAG assistant over SharePoint, Confluence, and Google Drive is not one big line. It is several small ones, plus the part everybody forgets: keeping it running.

Engineering and process perspective, not a vendor pitch. This is about rolling AI out internally, a different job than building an AI product for your customers; we do the internal-setup side under AI Enablement. The numbers below are directional, drawn from public 2026 pricing, and your numbers will differ. Re-check current pricing before you budget.

Before pricing retrieval, decide what it will retrieve. Our AI-ready company wiki guide defines the canonical knowledge, permission and review architecture that this cost model assumes.

What actually drives the cost of an internal AI assistant?

Almost everyone fixates on the LLM bill, and for an internal assistant that is rarely the biggest number. The cost is shaped by three things you control before a single token is spent:

• How many people use it, and how hard. Ten power users who query it 30 times a day cost more than 200 occasional users who open it twice a week. The unit that matters is queries per day, not headcount.
• How much it has to read to answer. Every answer pulls retrieved chunks of your documents into the prompt. Stuff ten pages of context into each call and your input-token bill multiplies, even though the question was one line.
• How fresh the index has to be. Re-embedding documents the moment they change costs more than a nightly sync. Most internal knowledge does not change minute to minute, which is a saving most teams leave on the table.

Get those three assumptions on paper first. They move the monthly bill more than any vendor choice you will make later.

What are the cost components, line by line?

Here is an illustrative 2026 budget for a small self-managed RAG assistant. The ranges are scenario assumptions, not market averages or provider quotes. Recalculate them from current prices, measured tokens, storage, requests, replicas, and service levels before committing.

Notice the pattern in this scenario: infrastructure is the smaller subtotal. Maintenance still needs its own measured line, whether it is performed internally or included in a vendor support agreement.

"The vector DB and the tokens are the cheap part. The expensive part is the engineer who keeps the answers correct after the documents change. Budget for that or the project rots."

Build or buy: which is actually cheaper?

The packaged "AI over your knowledge base" products quote a per-seat price, often somewhere in the range of a paid productivity seat. That is clean and predictable, and for a small team with generic documents it can be the right call. The trade-off shows up in two places: you pay per seat whether a user queries it once a month or fifty times a day, and your data routing and retrieval logic are whatever the vendor decided.

A self-managed setup inverts that. The per-query cost is low and you only pay for what runs, but you carry the build and the maintenance. The break-even is not about seat count alone, it is about control. The moment you need permission-aware retrieval that mirrors your SharePoint and Confluence access rules, or the data cannot leave your infrastructure, the off-the-shelf seat price stops being the whole story. We go deeper on the rollout decision in how to roll out AI internally without creating shelfware.

Where does DACH data residency add cost?

For a DACH company, data location is one part of the legal and security design. GDPR does not impose a blanket EU-only processing rule: transfers to third countries may rely on adequacy decisions or safeguards under Chapter V, alongside the rest of the processing assessment. The EU AI Act also does not create a general data-residency mandate. Contracts, sector rules, customer policy, secrecy duties, and the chosen transfer mechanism can still make EU-only processing a requirement for a particular deployment.

• EU-zone or regional model endpoints. Provider controls differ. For example, Microsoft Foundry Data Zone deployments process within a Microsoft-defined EU zone, while single-region deployments process in the selected region. Model availability, quotas, SLA, and price can vary by deployment type, so compare the exact model and region rather than assuming a fixed residency surcharge.
• EU-hosted vector DB and app. Region pinning may be a configuration, a distinct service tier, or unavailable for a chosen product. It can change price, redundancy, egress, capacity, and operational design.
• The compliance work itself. The real residency cost is the review: the data-processing agreement, the records of processing, and confirming no maintenance access reaches the data from outside the EU. That is one-time effort plus a smaller recurring review, and it is far cheaper done at design time than retrofitted.

Designed from the start, residency and transfer controls are explicit budget inputs. Added later, they may require data migration, vendor changes, or an architectural rebuild.

What does it cost per seat, per month, in a worked example?

Illustrative only. Your numbers will differ, and you should re-check current pricing before you trust this. The point is the shape of the bill, not the exact figure.

Assume a DACH company with 50 active users, each running roughly 10 queries a day (about 11,000 queries a month), over a corpus of a few hundred thousand document chunks, answered by a mid-tier EU-region model with tight retrieval (a handful of chunks per answer), nightly re-indexing, and a managed vector DB.

Under these assumptions, the infrastructure subtotal lands around $3 to $10 per active seat each month. That is arithmetic for this 11,000-query scenario, not a DACH benchmark. Maintenance, identity, security, backups, support, taxes, and staff time sit outside the subtotal and may change the annual result substantially.

How do you keep it cheap without letting it rot?

The same discipline that keeps a production AI build affordable applies here. The cost levers, in the order they pay off:

• Route to the cheapest capable model. Most internal questions do not need your most expensive model. Reserve the frontier model for the hard minority and the per-query cost drops sharply.
• Retrieve less, more precisely. The single biggest token waste is stuffing too many chunks into each answer. Good retrieval plus a reranker sends the model a few relevant chunks, not ten pages. This is the lever with the largest effect on the LLM line.
• Cache measured repeats. Cache only when logs show repeatable, permission-safe inputs and define invalidation for changed documents and access rights. The deeper token mechanics are in how to cut LLM token costs in 2026.
• Index to a freshness SLA. Choose nightly, event-driven, or near-real-time synchronization from the business tolerance for stale answers. Embedding cost follows the changed token volume.

One humility note that no cost table captures: a cheap assistant that quietly gives wrong answers is the most expensive outcome of all. You need an eval set, a way to measure answer quality after the documents change, and someone whose job is to watch it. That maintenance line is not optional padding. It is the difference between a tool the team trusts and one they stop opening. We saw the same discipline pay off in production AI work like Twinsoft AI, where the eval harness is what made cost optimisation safe.

Primary sources used in this guide

Re-check these live provider pages before approving a budget; pricing and deployment availability can change.

• OpenAI text-embedding-3-small documentation
• Pinecone pricing
• Microsoft Foundry deployment types and data zones
• GDPR, including Chapter V third-country transfer rules
• EU AI Act