Project Kasimir: Why we built our own AI platform

For about a year now, we have heard the same sentence in almost every client conversation: "We want to use AI in our company — but our data must not leave the building." Usually a shrug follows. Because the tools everyone knows store data in the US and use input for training by default. For a tax advisor, an engineering office or a machine builder with design data, that is not an option.

We decided to stop shrugging and build our own platform. It is called Kasimir, it runs at kasimir.ai, and it has been in production use at the first companies since the beginning of this year. Time to introduce it properly.

Why we didn't just buy a tool

The market for enterprise AI assistants is crowded. But two designs dominate it.

The first is the American platform with a European coat of paint: a German interface, a data centre in Frankfurt — yet the model itself still runs at a US provider, and the US CLOUD Act still applies. The second is a thin shell around someone else's API: a pretty chat window, no infrastructure of its own. The moment anyone asks where exactly the data sits, the answer gets blurry.

Neither answers the question our clients are asking. So we took the uncomfortable route: our own models, our own servers, our own responsibility.

What Kasimir is

Kasimir is an AI platform for everyone in a company — not for an IT department that knows how to write prompts. Four areas carry the product:

Then there are the things nobody celebrates on a product page and without which no company ever rolls out a platform: roles and permissions, IP allowlists, tenant isolation, a data processing agreement, an analytics area for usage and cost, and a delete function that actually deletes.

The core: our own models, our own data centre

The decisive design decision sits below the surface. By default, every request in Kasimir runs on open models on GPUs in our own German data centre. Not just the chat — the embeddings for document search, the re-ranking of results, the speech recognition for meetings and the text recognition for scanned PDFs as well. On that default path there is simply no third party for data to flow to.

Which models exactly is a moving target. As of today it looks like this:

Model	Job	Where it runs
Gemma 4 (31B)	default model for chat, summaries and reading images and plans	our own data centre, Germany
Jina Embeddings v3	makes documents searchable	our own data centre, Germany
Qwen3 reranker	re-scores search hits before they reach the model	our own data centre, Germany
WhisperX	transcription with speaker recognition	our own data centre, Germany
GPT-5.6, GPT-5.4, Claude Sonnet 4.6, Mistral Large 3, Grok 4.3, DeepSeek V4 Pro	switchable for especially demanding tasks	EU region

If a task needs a frontier model, you can deliberately switch one on; processing then happens in the EU, in line with the GDPR. Every model carries a visible marker in the picker showing where it computes — nobody makes that decision by accident.

That is the difference between a promise and an architecture. A promise lives in the terms and conditions. An architecture makes the data leak impossible, because there is no path to it.

Four things we learned along the way

The chat is the easy part. Hooking a chat window up to a model is a weekend's work. The months go into making the AI find the right passage in your documents. Our first search was purely semantic — and it broke on the German language: ask about "Sockel" (base) and you got no hits for "Sockelhöhe" (base height). Today Kasimir combines semantic and literal search and then re-ranks the candidates with a second model of its own. That gained us more answer quality than any model upgrade before it.

Answers without evidence are worthless. The moment someone uses an AI answer about a building standard or a contract in their actual work, they have to be able to check the source in one click. That is why every answer in Kasimir carries a source strip: document, page, passage. It dampens the euphoria and raises adoption — only then do people dare to pass the result on.

Sovereignty is an operations job, not a checkbox. Running your own models means keeping the GPUs in your own data centre busy, building queues, backing up at night and running monitoring that pushes a real test question through the complete path every five minutes. That is less comfortable than calling someone else's API. But it is the only way to answer the question about where the data sits without an asterisk.

We are our own first customer. Kasimir also works inside our own hub, where it answers questions about projects, clients and proposals. Every flaw hits us first. That is why the product has grown at this pace: recent months brought the shared company notebook, Nextcloud and ownCloud connectors, whole-document translation, Excel in the chat, meeting minutes with real attendee names, a public API, and a memory that remembers your role and ongoing work across chats — transparently, and revocable in one click.

Try it yourself

You can write at length about sovereignty and architecture. Whether Kasimir fits your day-to-day work only becomes clear with your own documents. That is why you can test Kasimir free of charge, no credit card required: sign up at kasimir.ai with a few words about what you have in mind, we activate your access shortly, and from then on you work with your own data, not a demo.

Three things that tell you the most in the first week:

1. Ask a real document. Upload a manual, a contract or a standard and ask the question that would otherwise cost half an hour of searching. Check whether the citation holds up.
2. Record a meeting. Capture your next weekly meeting and see whether you would send out the minutes and tasks as they are.
3. Automate a process. Take something that runs the same way every week and rebuild it as a workflow.

After that you will know whether Kasimir is worth it for you. And if you have questions along the way or want to roll Kasimir out to more than a small team, get in touch with Felix Stürmer directly.