KyperX AI / Australia / AI services / Private AI
Private AI
AI infrastructure designed around your information, systems and security requirements.
For organisations that need more control over where information goes, who can reach it and how AI is deployed. KyperX designs and implements private AI environments, from retrieval over internal documents to models served inside your own boundary, and chooses the architecture from your requirements rather than from a preferred platform.
- Pricing
- Scoped to requirements
- Starts with
- Discovery and architecture
- Architectures
- Private cloud, on-premises, hybrid or controlled APIs
- Decided by
- Your information, access and deployment requirements
Outside Australia? Private AI with USD pricing →
Why private AI
Why organisations consider private or controlled AI.
Usually because one or two requirements rule out the default hosted service. Identifying which ones genuinely apply decides the architecture.
01
Sensitive or confidential information
Client records, commercial documents or personal information that cannot be sent to a general-purpose AI service on standard terms.
02
Residency and supplier boundaries
Requirements about where information is processed and stored, and which suppliers may handle it, including logs and backups.
03
Intellectual property exposure
Designs, source material or methods the organisation does not want leaving an environment it controls.
04
Access control and auditability
A need for AI to respect existing permissions, and to keep a record of who asked what and what the system returned.
05
Integration with internal systems
AI that has to reach internal document stores, databases and business systems that are not exposed to the internet.
06
Predictable capacity
Workloads where dedicated capacity may be easier to plan and govern than usage-based services. Whether it costs less depends on the workload.
Deployment options
Architecture options and their trade-offs.
Private AI does not always mean on-premises. The right position is the least complex one that satisfies the requirements that genuinely bind.
| Option | What it means | Trade-offs |
|---|---|---|
| Controlled commercial APIs | Commercial models used under enterprise terms with defined data handling, and regional processing where the provider offers it. | Quickest to stand up and access to capable models. Relies on the provider’s terms and regional availability; the provider remains in the access path. |
| Private cloud | Models, retrieval and supporting services in your own isolated cloud tenancy, in Australian regions where the required services are available. | Strong control without owning hardware. Costs scale with use, and model choice is limited to what can be hosted or licensed there. |
| Dedicated capacity | Hardware allocated to your organisation alone, hosted in a data centre. | Isolation without ownership. Longer lead times and a capacity commitment. |
| On-premises | Hardware you own, inside your own network and physical boundary. | The most physical control. Capital cost, space, power and cooling, and operational responsibility sit with you or an agreed operator. |
| Hybrid | Sensitive workloads kept private; less sensitive workloads routed to controlled APIs. | Balances capability and control. Adds design complexity, and the routing rules themselves must be governed. |
How deployment and ownership change row by row, including hardware you own: Infrastructure and owned deployment →
Reference architecture
The layers of a private AI environment.
A way of reasoning about the environment, layer by layer. Which components exist, and where each one runs, is decided for the engagement.
Users and applications
Search and question interfaces, assistants embedded in existing tools, and APIs for other systems.
Identity and access
Integration with your identity provider, role-based permissions, and document-level access carried through to results.
Orchestration and retrieval
Retrieval over approved sources, prompt and policy controls, and tightly scoped tool access.
Models
Open-weight models served privately, controlled commercial APIs, or a combination, selected by evaluation.
Information sources
Document stores, databases and business systems, connected through governed connectors.
Infrastructure
Private cloud, dedicated capacity, on-premises hardware or a hybrid of these.
Reference layering, not a fixed product. Layers read top to bottom from the user to the infrastructure.
Design choices
Knowledge, models and infrastructure.
Three sets of decisions that are made from evidence during discovery and architecture.
01
Private knowledge and document intelligence
Retrieval over internal documents and records, with answers that reference their sources and respect existing permissions. Quality depends heavily on how documents are prepared, divided and indexed, so this is evaluated on your own material.
02
Model selection
Chosen by the task, the accuracy required, the languages and document types involved, context requirements and licence terms, and compared on representative tasks before a decision is made.
03
Infrastructure sizing
Derived from the workload: number of users, concurrency, document volumes, response-time expectations and availability requirements. Compute and infrastructure covers how this scales.
04
Integration with existing systems
Connectors to document stores, databases and line-of-business systems, designed so that a failed connection is visible and permissions are not widened in the process.
Controls
Controls designed to your requirements.
Documented so your own security, privacy and risk teams can review them. KyperX does not certify security or compliance.
| Control area | What is designed and documented |
|---|---|
| Identity and access | Authentication through your identity provider, roles and permissions, and how source-level access is enforced in results. |
| Audit and logging | What is logged, where logs are stored, who can read them and how long they are kept. |
| Data handling | Which information may enter the environment, what is retained, and where backups and caches reside. |
| Network boundaries | Inbound and outbound paths, including whether any call leaves the environment and under what terms. |
| Evaluation and monitoring | How output quality is measured on representative tasks, and how drift or failure is detected after deployment. |
| Operations | Who patches, updates models, responds to incidents and approves changes, whether that is your team or a separate operating arrangement. |
Engagement
From discovery to deployment.
Each stage is scoped and quoted before it begins, and the architecture is agreed before anything is procured or built.
01
Discovery
Requirements, constraints, information flows, users and the systems involved.
Output: requirements and constraints record
02
Architecture
Options compared, trade-offs stated, and a recommended design with indicative costs.
Output: architecture decision
03
Build
The environment, connectors, controls and applications, as agreed.
Output: working environment
04
Validate
Evaluation on representative tasks and documentation for your security review.
Output: evaluation results
05
Deploy and hand over
Rollout, documentation and training. Ongoing operation is available as a separate arrangement.
Output: operable system
Have requirements that rule out a default AI service?
Describe what the environment needs to do and the constraints that apply. We will outline the options that are worth considering.
Questions
Questions about private AI.
What technical and risk stakeholders ask first.
Does private AI mean on-premises?
Not necessarily. Many requirements can be met in a private cloud tenancy or with controlled commercial APIs. On-premises hardware is justified when the requirements call for it, and the architecture phase sets out why.
Can our information stay in Australia?
Where required, the architecture can use Australian cloud regions, dedicated capacity or infrastructure you own. Whether information stays in Australia also depends on model providers, supporting services, logging, backups and support access, all of which are mapped during discovery.
Are open-weight models capable enough?
It depends on the task. For some tasks they perform well; for others a commercial model is materially better. Candidates are compared on representative tasks from your own work before a model is chosen.
Is a private AI environment secure?
Security depends on the design, configuration and operation of the whole environment, not on where it runs. KyperX designs controls to your requirements and documents them for your review; it does not provide a security guarantee or certification.
Can KyperX operate the environment after deployment?
Yes, as a separate arrangement on its own terms. Handover is designed so your team can operate it if you prefer.
Enquiry
Plan a private AI deployment.
Describe what the AI environment needs to do, the information involved and the requirements that rule out a default hosted service.
What happens next
- We review your enquiry. We read what you have described and check whether it is work KyperX can usefully do.
- We reply by email. Usually with a few questions, or a suggested time for a short conversation where there appears to be a fit.
- Scope is confirmed in writing. If an engagement is appropriate, you receive a written scope and fee before any work begins. There is no commitment until then.
Prefer email? Write to ai@kyperx.com.
Thank you. Your enquiry has been received.
It has reached KyperX AI with the context of this page. We aim to reply by email within two business days.
- We review what you have described.
- We reply with questions, or suggest a short conversation where there appears to be a fit.
- If an engagement is appropriate, we send a written scope and fee. Nothing proceeds without your agreement.
If you have not heard from us, check your junk folder or write to ai@kyperx.com.