Local AI Suite: GDPR-Compliant AI on Your Own Hardware
The local AI suite is an AI assistant for sales and customer communication that runs entirely on servers inside your own building. CRM records, email threads and internal documents never leave it. You buy the hardware it runs on, so there is no provider your data travels to for an answer, and no contract that would have to cover it.
The suite is cut into modules that are sold and go live one at a time. The order is not free, though. Until the base of CRM ETL and vector index is in place, the other modules have no data to work with.
Base: CRM ETL and vector index
Before anything can answer a question, the data has to come across from the CRM and become searchable. This module reads records, notes and attached documents, splits them into passages, computes embeddings and puts both into a Qdrant instance on your network. A delta sync then keeps the index current instead of reloading everything overnight. Nobody sees this module day to day. It gets noticed the first time an answer cites a case from 2019 that everyone had forgotten about.
Chatbot on your CRM data
Someone in sales with a question about a customer pieces the answer together from the CRM today, out of contact history, quotes, open items and notes going back three years. The chatbot answers the same question in one sentence and names the records the answer came from. That keeps it checkable even when the model gets it wrong, and it does get things wrong.
Email module
For incoming mail the module produces a draft reply before anyone opens the message. It draws on the CRM record for the sender, the thread so far, the files kept against the case, and the writing style of the person who will answer. That style is learned from their own sent mail, not from a house tone. So you read a draft and correct it instead of sitting in front of an empty window.
Operations and compliance package
Your works council and your data protection officer want to see paperwork before the suite goes into production. This module supplies it: a sample Betriebsvereinbarung, a template for the data protection impact assessment, building blocks for your record of processing activities, and the transparency notices that Article 50 of the AI Act has required since 2 August 2026 for systems people interact with directly. The negotiating and the signing happen at your end. We supply the drafts, not legal advice.
What carries these modules is in none of the cards. Local inference on your GPUs, acceptance against test cases agreed in advance, the access and the documentation, all of that belongs to the introduction. Monitoring of response times and load comes with the higher maintenance tier. And whether we run operations or your own IT does is your call.
Why local hardware settles the data protection question
Most routes to GDPR compliance run through paperwork: processing agreements, standard contractual clauses, assurances about training. The local suite takes the other route and leaves the data where it already sits.
If a customer record never leaves the server room, there is no processor for it, no third-country transfer, and no question about whether a provider trains its models on it. Not because we handled those points cleanly. They do not arise for that data in the first place. That is a decision in the architecture, not something bolted on at the end of a project.
The price for that has two parts you should know about before committing. Open models running on your own hardware are generally weaker than the large commercial ones. On narrow tasks, questions against a CRM record or drafts in a familiar tone, the gap barely shows. On open-ended reasoning across long documents you notice it. Then there is the hardware, which is a capital expense and not a monthly invoice. Servers and GPUs get bought, depreciated and eventually replaced. If you would rather pay per request and keep nothing in your own server room, EU-hosted operation is the better fit. We build that too.
Running locally does not by itself make something lawful. Access rights, retention periods and the question of which staff may see which records still have to be settled. The suite moves that work out of contract law and into your own configuration.
Pricing
We sell the suite as a licensed product, not as work billed by the day. The one-off introduction is made of two items that add up: the setup work, priced by company size, and the modules you actually take. After that you pay the licence every year.
AI suite: introduction priced by company size
Segment
Users
Introduction (one-off)
Annual licence
S
up to 20
9,000 €–15,000 €
4,000 €–6,000 €
M
20–50
15,000 €–25,000 €
7,000 €–12,000 €
L
50–150
25,000 €–40,000 €
14,000 €–24,000 €
XL
from 150
from 40,000 €
from 30,000 €
Introduction in this table means the setup work: installation, configuration, data connection, go-live, acceptance. Which functions you then run is in the module table further down, and that comes on top. The annual licence covers:
Updates and new versions
Security patches
Bug fixes
Model maintenance incl. one re-indexing per year
Email support (2 business days response)
One model review per quarter
It does not cover maintenance of your own connectors, new features, on-call standby or running the system. What connectors and the higher maintenance tiers cost is in the tables below. New features are in no table, because they run as change requests billed by time.
Segment S only with a standard CRM, no custom connector.
These prices are added to the setup work in the table above, not substituted for it. A company of 15 people taking the base and RAG pays the segment S figure plus both module prices. Pricing is per module, whether you take one of them or all of them.
Mailbox connection, history indexing per user, reply generation with local models
14,000 €–22,000 €
Operations & compliance package
Sample Betriebsvereinbarung, DSFA template, Verarbeitungsverzeichnis building blocks, AI Act transparency notices
3,500 €–6,000 €
Every CRM needs a connector. If yours is already in the catalogue, that is configuration work. If it is not, one gets built, and how involved that turns out depends on the interface. A documented REST API at one end, direct access to the database of a legacy system at the other.
Connectors
Type
Introduction
Maintenance p.a.
Standard connector (already in the catalogue, configuration only)
1,500 €–3,000 €
included in the licence
Custom connector, SaaS CRM with documented API
6,000 €–10,000 €
2,000 € flat
Custom connector, on-premise / legacy system, direct DB access
10,000 €–15,000 €
20–25 %, min. 2,500 €
Undocumented / unofficial interface
only after individual review
30 %, liability excluded for outages
Maintenance for a custom connector is always billed separately. It absorbs what the vendor changes in its API and tells you when a daily contract test breaks. That percentage is calculated on what the connector cost to build, not on the licence sum. New fields, changed business logic, a move to a different CRM or a major release on your side run as change requests instead.
Maintenance is mandatory, not optional. There is no support without a running contract, and anyone who suspends one and comes back later pays for the suspended periods.
Maintenance & operations (from year 2)
Tier
Scope
Price p.a.
Base
included in the annual licence (see 2.)
included in the annual licence
Extended
additionally monitoring, 4-hour response, 3 change-request days included
3,500 € flat
agreed individually in segment XL
Operations
additionally on-call standby, 1-hour response, ongoing further development
8,000 € flat
agreed individually in segment XL
You buy the hardware. ARSoftware supplies neither servers nor GPUs, so the table gives reference figures to shop against and not an offer. What sizes the machine is concurrent use, not headcount. Twenty people who rarely overlap ask less of it than five who live in the chat all day.
Hardware (customer procures)
Segment
Configuration
Reference price
up to 20 users
GPU workstation, one card
4,000 €–7,000 €
20-80 users
Server, one to two GPUs
8,000 €–15,000 €
from 80 users
Server, multiple GPUs, redundant
from 18,000 €
All prices are net and exclude VAT.Last updated: August 2026
A configuration recommendation, including where to buy, can be part of the introduction.
Design partners and reference customers
The first installation is already running. One customer is putting the suite into operation now. While that project runs and the clearance for a reference is still pending, they stay unnamed here. For the modules still ahead of us, ARSoftware is looking for further companies that would rather build part of the suite with us than buy it finished. A design partner brings a component out of its own need, we build it, and afterwards it becomes part of the product.
What a partner contributes is the part we cannot invent: requirements out of daily work, and the special cases that never make it into a specification. In exchange they work on a product that is not finished yet, and they take its detours with them. Reference customers take the shorter route and release operating figures we are allowed to quote. Terms are agreed individually in both cases.
Frequently asked questions about the local AI suite
What hardware does the local AI suite need?
Concurrent use decides it, not the number of people in the company. The pricing part of the local AI suite page lists three reference configurations with guide prices: GPU workstation, one card (up to 20 users); server, one to two GPUs (20-80 users); server, multiple GPUs, redundant (from 80 users). You buy the machine yourself. ARSoftware does not supply it. The exact configuration falls out of discovery, from the volume of data in the CRM and the response time your people will still accept. If servers are already in the building, we check those first.
How good are local models compared with ChatGPT or Claude?
On open-ended work, worse, and there is no point pretending otherwise. The large commercial models are ahead of the open models that fit on a single machine, in size and in what went into training them. How wide the gap is in practice depends on the task. When an answer is supposed to come out of a CRM record and an email thread anyway, what matters most is whether retrieval finds the right passages, not how clever the model is on its own. So before anything goes live we build an evaluation from your own questions and the answers you expect. If the result does not hold up, we say so.
Which CRM systems can the suite connect to?
In principle any system with an API or database access. The base of the integration covers ingestion, chunking, embeddings and delta sync, and it does not depend on the particular CRM. Each system then needs a connector that maps its fields and relationships onto that schema. The price table lists four connector types instead of one row per CRM, because what a connector costs is decided by the state of the interface. For systems with a documented REST API this step is manageable. For older installations without an API it comes down to database access or scheduled exports, and that gets more involved.
How long does the rollout take?
From discovery to acceptance of the base build we plan for three to six months, assuming one person owns the project on your side and the hardware arrives on time. Discovery and the architecture concept together are scoped at three to five working days, though far more calendar time sits between them and acceptance. The longest item is usually not the engineering but the data: incomplete CRM fields, duplicates, ten years of accumulated special cases. We normally do the email module after the chatbot, because it sits on the same data.
What happens if we want to develop the suite further ourselves later?
Then you take it over. Source code, infrastructure definitions and documentation go to you, and the building blocks are openly licensed, the models as much as the vector database and the orchestration. There is no licence key we could switch off and no component that only runs on our side. We would still advise keeping the evaluation cases up to date. They are the most reliable way to tell whether a change to the model or the prompt actually improved anything.
Let's talk about your use case.
Tell us briefly what you are working on. You get an honest assessment of whether AI is the right fit, and what a sensible first step looks like.
