Can we keep our data off third-party model providers entirely?

Yes. We run inference, embeddings and vector search on our own hardware and can deploy the same arrangement into yours. It costs more than an API key and it is the only honest answer when the data is regulated.

How do you stop it inventing things?

You constrain it to retrieved material, you make refusal an acceptable outcome, and you measure. Nobody can promise a language model never fabricates. What we can build is a system where fabrication is rare, visible, and cheaper to detect than to ignore.

AI and retrieval systems

Assistants that read your documents, and know what they are not allowed to read

Connecting a language model to an API takes an afternoon. Making it answer correctly from your own material, refuse when it does not know, and never reveal a document the person asking is not entitled to see — that is the project. Retrieval quality decides almost everything and it is unglamorous work: how documents are split, what a four-word question actually means, how results are ranked, and how permissions are enforced at retrieval time rather than hopefully filtered afterwards.

What the work involves

Document ingestion and chunking designed so a retrieved passage still makes sense alone
Embedding and vector search, self-hosted where the data cannot leave
Permission-aware retrieval — the access check happens before the model sees the text, not after
Evaluation against a real question set, so a change can be shown to help rather than assumed to
Graceful refusal, because a confident wrong answer is worse than no answer in every business context
Cost and latency budgets, including the option of a smaller self-hosted model where it suffices

Why we are credible at this

We run the whole chain ourselves: a model server, an embedding model, a vector database, speech recognition and synthesis, and machine translation across twenty-two languages — on our own cluster, for tenants whose data is not permitted to leave it.

What moves the price

We quote after discovery and the number is fixed before anything starts. These are the things that move it, so you can see roughly where your project sits before you talk to us.

Corpus size and, far more importantly, how messy the documents are
Whether inference must be self-hosted for data-residency reasons
How fine-grained the permission model is — per-document access is a different project from per-tenant
Whether you need evaluation infrastructure, which you do if the answers matter

Proof we have done this

Inference we run ourselvesModels, embeddings, vector search, speech and translation — on our own hardware Documents, signatures and the paperwork layerCollaborative editing, e-signature and OCR, built rather than bought A distributed data layer, chosen deliberatelyDistributed SQL, wide-column, cache, object storage and vectors — each for a reason

Questions we get asked

Other App Development work

Custom web applicationsThe system your business actually runs on, built properly API and integration developmentMaking two systems agree, including the one with no documentation Mobile applicationsCross-platform where it makes sense, native where it does not Real-time systemsLive data, messaging, presence and media — the unforgiving end of the web

All App Development

Tell us what you are trying to do

A short conversation is usually enough to tell whether we are the right people. If we are not, we will say so and point you somewhere better.

Start a conversation I already use KamoCRM How we quote