Private and on-premise AI

Use AI without giving up control of sensitive data.

AI does not have to mean sending company information to a public external service. Modern models can run in private cloud, dedicated infrastructure, on-premise systems or, in specialized cases, air-gapped environments.

Underlabs designs AI architecture around the level of privacy, control and operational independence each workload actually requires.

The central idea

Private AI is a deployment spectrum.

The right choice is not automatically the one with the most control. It is the one that matches the data, capability, budget and responsibilities the organization can realistically support.

Lower operational burdenGreater infrastructure control
  1. 01
    Managed APIThe provider operates the model and infrastructure.
  2. 02
    Dedicated or single-tenant AIAn isolated environment is reserved for one customer.
  3. 03
    Private cloud or VPCInference runs inside the organization’s private cloud environment.
  4. 04
    Customer-controlled Canadian cloudThe customer controls deployment in Canadian infrastructure.
  5. 05
    On-premise AIThe model runs on hardware controlled by the organization.
  6. 06
    Air-gapped AIA specialized environment runs without an external runtime network dependency.
Greater control may improve

privacy, isolation, customization, governance visibility and deployment independence.

It may also increase

cost, hardware requirements, maintenance, capacity planning and operational responsibility.

When a public AI API is not the right fit

Managed APIs are often an excellent choice.

They are frequently the fastest and most economical way to deploy AI, with rapid access to new models, elastic capacity and little infrastructure to operate. They are not inherently insecure.

Some organizations, however, have contractual, regulatory, governance or internal-policy reasons to require stronger control for particular workloads.

  • Confidential corporate documents
  • Proprietary research
  • Internal financial information
  • Legal documents
  • Sensitive customer data
  • Regulated workloads
  • Industrial information
  • Healthcare-related systems
  • Critical internal operations
  • Government information
  • Valuable intellectual property

Where the AI actually runs

The model has to run somewhere.

When someone asks an AI model a question, the model performs computation on physical hardware. That processing is called inference.

The architecture question is simple: where does that middle step happen?

An inference path
  1. 01Your application
  2. 02Prompt or documents
  3. 03Model inference
  4. 04Response

It may run on AI-provider infrastructure, in a dedicated environment, a private VPC, Canadian cloud infrastructure, a customer data centre, a local server or edge hardware.

Deployment models

Different boundaries for different needs.

These patterns are reference points, not security or compliance tiers. Their suitability depends on the complete system.

01

Managed AI

  1. 01Application
  2. 02External AI provider
  3. 03Response

Good for: Speed, experimentation, elasticity and low operational burden.

02

Private cloud AI

  1. 01Application
  2. 02Private network
  3. 03Private model and data

Good for: Stronger control without owning the physical hardware.

03

On-premise AI

  1. 01Internal application
  2. 02Internal network
  3. 03Local model and data

Good for: Direct operational control, low latency or local operation.

04

Air-gapped AI

  1. 01Isolated application
  2. 02Isolated model
  3. 03Isolated data

Good for: Highly sensitive environments where isolation is genuinely required.

Two important distinctions

Private, on-premise and open-weight are not synonyms.

01

Private does not necessarily mean local

Private AI can run in a private cloud, dedicated environment or customer-controlled Canadian infrastructure. On-premise describes the location and control of physical hardware. Private primarily describes control and isolation. They overlap, but they are not the same.

02

Self-hosted does not necessarily mean open source

A private deployment may use open-weight models, commercially licensed models or proprietary models available under an enterprise agreement. Licensing and deployment rights vary. Conversely, open weights do not automatically make the complete system private.

The real boundary

The whole AI pipeline matters, not only the LLM.

A company can self-host its model while still sending sensitive information to an external document parser, embedding service, vector database or logging tool.

Private AI is an architectural property of the system, not merely a property of the language model.

Every component may process data
  1. 01User
  2. 02Application
  3. 03Document parser
  4. 04Embedding model
  5. 05Vector database
  6. 06LLM
  7. 07Logging and monitoring

Internal data and RAG

Ground answers in company knowledge.

Organizations often want AI to answer using internal documents, policies, databases and knowledge rather than relying only on what the model already knows.

This architecture is commonly called retrieval-augmented generation, or RAG. Its privacy boundary extends to storage, indexing, embeddings, retrieval, inference and logs.

A simplified RAG path
  1. 01Internal documents and data
  2. 02Search and retrieval
  3. 03Relevant information
  4. 04AI model
  5. 05Grounded response

Fit the system to the work

Private AI does not require the biggest model.

Some workloads can be solved with smaller language models, specialized models, embedding models, rerankers, classifiers, vision models or deterministic automation combined with AI.

Small private model+retrieval+business rules+existing APIs

The goal is to solve the business problem with sufficient capability, not to maximize parameter count.

Hybrid AI

Not everything has to be public or private.

An architecture can route each task according to sensitivity, capability, cost, latency, residency and availability.

Separate data from the task

  1. 01Sensitive internal data
  2. 02Private AI environment
  3. 03Sanitized non-sensitive task
  4. 04External frontier AI

Limit the context shared

  1. 01Internal knowledge
  2. 02Private retrieval
  3. 03Approved context only
  4. 04External model

Route by capability

Routine tasksPrivate modelComplex non-sensitive tasksExternal frontier model

Model routing and portability

Avoid unnecessary dependence on one model.

An intentional service layer can route requests to a private, external or specialist model and make future changes easier.

This does not promise complete vendor independence. Models differ in APIs, tool use, context limits, capabilities and output formats. Portability requires interfaces, evaluations and testing.

A service layer between the application and models
ApplicationAI service layer
Private LLMExternal LLMSpecialist model

Operational reality

Control also transfers responsibility.

On-premise AI introduces decisions about GPU memory, compute capacity, power, cooling, redundancy, storage, networking, monitoring and model updates.

Economics depend on request volume, predictable utilization, data movement, latency, connectivity and the value of long-term control. At sufficient scale, dedicated infrastructure can have different economics from per-token pricing.

Private AI is not always cheaper. It is often more expensive. The decision should reflect the complete requirements, not only the unit price of inference.

A Canadian example, not a prescription

Enterprise model providers support private deployment.

Canadian AI company Cohere, for example, documents managed, dedicated, private-cloud or VPC, and on-premise options, including isolated environments that can run without runtime network access. Availability and terms vary by product and agreement. Read Cohere’s official deployment documentation.

Cohere is one example among several. The model and provider should be selected after defining the workload, data and control boundary.

The Underlabs approach

Start with the requirement, not the hardware.

You do not need to choose a model, orchestrator or GPUs before talking to us. A requirement such as “use AI on sensitive internal information without sending everything to a public service” is enough to begin.

  1. 01

    Define the workload

    What are we actually asking AI to do?

  2. 02

    Classify the data

    What information enters the system, and what is genuinely sensitive?

  3. 03

    Set the control boundary

    What may leave the environment, and what must remain private?

  4. 04

    Benchmark models

    Compare private and managed options against the real workload, not model branding.

  5. 05

    Choose the architecture

    Managed API, dedicated environment, private cloud, Canadian infrastructure, on-premise or hybrid.

  6. 06

    Build the complete application

    Interfaces, APIs, retrieval, integrations, automation, permissions, workflows and monitoring.

  7. 07

    Measure and evolve

    Design the system so it can change with models and requirements.

The next decisions

Which model, then which infrastructure?

Once the deployment boundary is clear, model selection depends on capability, language, reasoning, latency, hardware, cost, licensing and deployment rights. Canadian-developed models, international open-weight models and commercial private deployments are all possible options.

Private operation still needs somewhere to run: GPU capacity, Canadian cloud, data centres, storage, networking and orchestration. Those infrastructure choices are a separate decision.

From requirement to deployment

Set the right boundary for your workload.

Share the workflow, sensitive data, existing systems and constraints. Underlabs can take the work from architecture and model selection through prototyping, benchmarking, deployment and integration.