When this works
- Every processing step has a local or approved alternative. OCR, embeddings and re-ranking are often overlooked.
- Existing document permissions can be read and enforced at query time, not only at ingestion.
- There is a named IT owner and a sponsor for one specific workflow.
- You can assemble 30–100 representative questions with known good answers for testing.
The questions to settle before you buy
What leaves the network?
Nothing should, by design, but that has to be verified, not assumed. We map documents, prompts, embeddings, logs, outputs, telemetry, update checks and any optional cloud features, such as hosted models or web search in some runtimes, and test the deployed system with egress blocked.
How are existing access permissions respected?
Retrieval is filtered by the requesting user's identity and group memberships before anything reaches the model. Permission tests check that a user cannot surface content from documents they cannot open directly. This is a release gate, not a nice-to-have.
What happens when it cannot answer?
It should say so and show which sources it searched, rather than guess. We test refusal and "not found" behaviour explicitly, and require citations to source documents for answers that matter.
How is answer quality measured?
Against an agreed test set of your questions, scored for correctness, citation accuracy and completeness, with retrieval quality measured separately so problems can be traced to the right component.
Who maintains it?
Your team, us, or a partner, but it must be someone named, with a regression suite that runs before any model, runtime or index change.
Where processing happens
On-device
Processing happens on the user's own computer or phone. Nothing is shared between users unless you build that in.
On-premises
Processing happens on infrastructure your organisation owns and operates, in your building or your colocation space.
Private hosted or hybrid
Explicitly approved external infrastructure, or a defined mix, with every external flow named in writing.
How we evaluate it
- Map the data boundary and every external dependency
- Build an agreed question set with expected answers and permission cases
- Compare two or three candidate configurations (model, embeddings, chunking, runtime) on the same set
- Measure answer quality, permission leakage, time to first token, end-to-end latency and resource use
- Record versioned configurations so results can be reproduced
Every published result is labelled measured, reproduced, vendor-reported or estimated. Client data and results stay private unless the client approves publication.
When local is not the answer
- Your approved hosted provider already meets your contractual and residency requirements, and the blocker is something else
- The document corpus is small and rarely queried, so a hosted service with a suitable data-processing agreement costs less to run
- You cannot staff an owner for updates and incidents, and no managed option fits
Ways to engage
Private AI Fit Assessment
Find out whether, and how, a specific AI workload can run within your constraints, before you buy hardware or sign an implementation contract.
From $1,500Typically 1–2 weeksWorkload Proof Pilot
A bounded implementation of one workload, tested against examples and acceptance criteria you agree up front.
From $8,000Typically 3–6 weeksProduction Deployment
A hardened deployment with integrations, access controls, operational documentation, training and acceptance testing.
From $20,000Typically 6–12 weeksDipankar Sarkar · Engagement owner, Neul Labs Limited
One named person is accountable for scope, commitments and acceptance on every engagement, including work delivered with specialist partners.
Further reading
- Build a local RAG chatbot
- Vector databases compared
- Local AI privacy audit
- Deployment-boundary checklist
Sources
- OWASP GenAI: LLM02 Sensitive Information Disclosure
- ICO: Guidance on AI and data protection
- Ollama FAQ: cloud features and how to disable them
Frequently Asked Questions
What leaves the network?
Nothing should, by design, but that has to be verified, not assumed. We map documents, prompts, embeddings, logs, outputs, telemetry, update checks and any optional cloud features, such as hosted models or web search in some runtimes, and test the deployed system with egress blocked.
How are existing access permissions respected?
Retrieval is filtered by the requesting user's identity and group memberships before anything reaches the model. Permission tests check that a user cannot surface content from documents they cannot open directly. This is a release gate, not a nice-to-have.
What happens when it cannot answer?
It should say so and show which sources it searched, rather than guess. We test refusal and "not found" behaviour explicitly, and require citations to source documents for answers that matter.
How is answer quality measured?
Against an agreed test set of your questions, scored for correctness, citation accuracy and completeness, with retrieval quality measured separately so problems can be traced to the right component.
Who maintains it?
Your team, us, or a partner, but it must be someone named, with a regression suite that runs before any model, runtime or index change.
Does running the model locally make us GDPR compliant?
No. Keeping processing in-house can remove a third-party transfer and simplify your position, but accountability, lawful basis, transparency, security and individual rights still apply. We document the technical controls; your advisers own the compliance opinion.
Can it run fully offline?
It can, provided every required component, including extraction, embeddings, retrieval, inference, authentication, updates and support access, is available inside the offline environment. We check each one.
How many users can one server support?
It depends on model size, context length, concurrency and latency targets, not staff count. Use the sizing calculator for a provisional range, then validate it under a measured load.