Private and on-premise AI
Keep control.
Keep AI useful.
Small language models, classifiers and task-specific AI. Deployed where your data belongs, evaluated against the work you need done.
Explore the optionsThe right model.
For this job.
Start with the task, not the largest model. These are starting hypotheses to test on your data and hardware.
Language, with a
smaller footprint.
Use a compact language model for a bounded task, with approved knowledge and clear output constraints.
- Good fit
- Drafting, summarisation, extraction and grounded internal answers.
- Test first
- Factuality, source use, difficult examples and response time on the target hardware.
- Trade-off
- A smaller model may need tighter task design or human review. It is not automatically cheaper or good enough.
A decision.
Not a conversation.
Use a classifier when the job is to assign a label, prioritise an item or route work to the right queue.
- Good fit
- Document types, request categories, intent detection and exception triage.
- Test first
- Precision and recall by category, confidence thresholds and the cost of each type of error.
- Trade-off
- Labels and representative examples matter. Low-confidence items need a safe route to review.
Built around
a specific task.
Use a specialised model or a constrained combination of models and software when the workflow has a clear, repeatable goal.
- Good fit
- Structured extraction, document understanding, matching and application-specific predictions.
- Test first
- Quality on the exact workflow, robustness when inputs change, and the data needed to maintain it.
- Trade-off
- Specialisation narrows the job. It adds versioning, evaluation and retraining responsibilities.
Where it runs
is part of the design.
Data location, network access, workload and ownership decide the deployment. No single hosting option wins every trade-off.
Inference inside your environment.
Run a suitable model on infrastructure you control. Design for your network, available hardware and the people responsible for operations.
- Keep inference data within the designed boundary.
- Validate all external dependencies if offline operation is required.
- Budget for hardware utilisation, patching, monitoring and support.
Cloud capacity, under defined controls.
Run a suitable model within a cloud environment you control. Keep its inference endpoint private, connect your identity and data access controls, and plan capacity and operations.
- Use private endpoints and your own access model.
- Keep data flows, logging and retention within the agreed boundary.
- Budget for infrastructure, model serving, updates and monitoring.
Keep sensitive work local. Route deliberately.
Combine local processing with approved cloud services where they add value. Define exactly what may leave the local boundary, and how the system behaves if a service is unavailable.
- Classify or redact data before any permitted external request.
- Allow only approved routes, with auditable policy enforcement.
- Test fallback behaviour, service failures and the cost of routing.
On-premise hosting alone does not guarantee security or compliance. Access controls, encryption, logging, retention and the full data path still need review.
Make the trade-offs
on real work.
Compare candidate approaches on a representative evaluation set. Agree the minimum acceptable quality before optimising speed or cost.
Quality.
Correct outputs, useful source grounding and acceptable error rates. Test the difficult cases, not only a polished demo.
Performance.
Response time, throughput and concurrency on your target infrastructure, under realistic load.
Total cost.
Compute, hardware, integration, maintenance and human review. Compare the cost of a completed task, not just a token.
Control.
Data location, access, logging, licences and update responsibilities. Trace the whole application, not just the model.
Control is
a working system.
Permissions follow the user
Retrieval and application access must respect what each person is allowed to see. A private model must not become a shortcut around the source systems' permissions.
Models need operating owners
Agree who patches the infrastructure, approves model changes, maintains evaluation data and responds to failures. We make these responsibilities part of the handover.
Changes are evaluated before release
A new model, prompt, retrieval index or routing rule can change quality. Version the system, rerun the agreed tests and keep a rollback path.
Your requirements come before the platform
We scope for the task, data boundary and operating constraints. Managed services, open-weight models and on-premise inference each have strengths and costs. The selection follows evidence.