Private AI deployment is the practice of running AI models inside infrastructure your organisation controls, giving you greater control over data, identity, auditing and operational risk. It is not a single deployment model but a spectrum, ranging from hosted private AI through to on-premise and fully air-gapped environments. Each option changes who controls the infrastructure, how data moves, how updates are managed and how compliance can be evidenced.
That distinction matters now. The UK’s Critical Third Parties regime has been live since January 2025 and as of the January 2026 Treasury Select Committee reporting, no organisations had yet been designated under it. That does not mean the risk is overstated. It means regulated organisations still have a window to make AI deployment a strategic governance decision, aligning security, resilience and regulatory obligations before external scrutiny forces reactive change.
What Private AI deployment actually means
Private AI means running AI on infrastructure your organisation controls, rather than relying on infrastructure managed by a third-party provider. That does not necessarily mean servers in your own data centre. A private LLM can run inside a tightly controlled Virtual Private Cloud (VPC) on AWS, Microsoft Azure or Google Cloud. What defines private AI is control over the runtime environment, the data boundary, identity, governance and the audit trail.
Organisations adopt private AI when they need greater control over sensitive information or greater confidence in how AI is governed. The driver may be regulatory compliance, protection of intellectual property, customer confidentiality, operational resilience or the ability to deploy AI more widely without exposing critical information to public services.
Private AI deployment sits on a spectrum, with each model offering a different balance of control, operational responsibility and security.
- Hosted private AI. Infrastructure you control within a cloud provider’s environment. It is isolated and access-controlled but may retain tightly governed external connectivity for updates, licensing or telemetry.
- On-premise AI. Infrastructure hosted within your own environment, giving you direct responsibility for patching, capacity planning, resilience, monitoring and hardware lifecycle management.
- Air-gapped AI. Infrastructure with no external network connectivity. There is no NAT, no external DNS resolution and no route by which data can leave the environment.
This distinction matters because not all ‘private’ environments provide the same level of isolation. A hosted private AI platform running in a Virtual Private Cloud (VPC) may tightly control external connectivity, but it can still communicate with approved external services. An air-gapped environment cannot. There is no external network path at all. That difference affects how the platform is secured, updated, governed and maintained.
There is no universally correct deployment model. The right architecture depends on the workload, the regulatory context and the organisation’s risk profile.That is why Catapult CX supports hosted private, on-premise and air-gapped deployments, selecting the architecture that best matches each client’s security, compliance and operational requirements.
Deployment Control. What changes
| Control area | Hosted private AI | On-premise AI hosting | Air-gapped AI |
|---|---|---|---|
| Data movement | Controlled ingress and egress with monitored network boundaries. | Internal ingress and egress controls, with monitored transfer paths. | Manual or tightly governed offline transfer only. |
| Updates | Cloud-provider-managed infrastructure with customer-controlled deployment and maintenance windows. | Organisation-owned patch windows, testing and rollback processes.. | Signed offline update bundles, verified before import. |
| Monitoring and logs | Centralised observability, security logging and model performance monitoring within the private environment. | Internal observability, security logging and model performance monitoring. | Local-only logging, with controlled export into evidence packs where permitted. |
| Access control | Integrated with enterprise identity, privileged access management and data classification controls. | Integrated with existing identity, privileged access and data classification controls. | Strict role-based access with no external administration route. |
| Audit evidence | Centralised audit logs, model versioning, access records and operational evidence. | Change records, access logs, model versioning and incident records. | Same evidence, but generated and retained inside the isolated environment. |
| Operational responsibility | Shared responsibility between the organisation and cloud provider. | Organisation responsible for infrastructure, resilience, capacity and lifecycle management. | Organisation responsible for all infrastructure, operational processes and offline maintenance. |
Why this is a 2026 decision, not a 2027 one
Regulatory scrutiny of where AI runs, who controls it and how it is governed is no longer a future concern. It is already influencing how regulated organisations assess operational resilience, third-party dependency and technology risk.
Since January 2025, the Bank of England, PRA and FCA have had statutory powers to designate suppliers, including AI and cloud providers, as Critical Third Parties (SS6/24, Bank of England). The 2023 consultation behind the regime estimated a population of around 20 such suppliers (Lexology, citing CP26/23), yet, as of the January 2026 Treasury Select Committee reporting, none had been designated. That should not be interpreted as an absence of risk. It simply means organisations still have an opportunity to review how AI is deployed before regulatory expectations become enforcement activity.
The FCA has also been clear that technology resilience is now a board-level issue.
In June 2026, Chief Executive Nikhil Rathi reported that 98% of operational incidents notified to the FCA during the previous year related to technology and cyber issues. He also stated that dependencies on AI model providers and other third parties need to be ‘properly mapped and governed’, describing the Critical Third Parties regime as ‘more important than ever.’
PRA Supervisory Statement SS1/23 already requires in-scope banks to manage model risk, including AI and machine learning models, regardless of whether they are developed internally or supplied by external vendors. Although its formal scope is limited, its principles are increasingly influencing governance expectations across the wider financial services sector.
None of this means every regulated organisation should deploy AI on-premise. It means deployment architecture has become a governance decision rather than simply an infrastructure decision. The right approach depends on the business processes being supported, the regulatory environment and the level of operational resilience the organisation requires.
On-premise AI deployment. What it involves
Choosing an on-premise deployment does not simply relocate the workload. It transfers responsibility. Functions that are partly managed by a cloud provider become the organisation’s responsibility, including infrastructure operations, resilience, security, maintenance and ongoing lifecycle management.
An effective on-premise AI deployment typically requires:
- Capacity planning. GPU and compute resources sized and provisioned ahead of demand rather than relying on elastic scaling.
- Patch governance. Controlled update windows, regression testing and documented rollback procedures owned by your team.
- Identity and access management. Privileged access, user permissions, retrieval controls and data classification defined before production deployment.
- Monitoring and observability. Continuous monitoring of model performance, drift, failed retrievals, prompt and response logging, security events and operational health, providing evidence for governance and audit.
- Resilience planning. Backup, failover, disaster recovery and business continuity arrangements tested in the same way as any other business-critical platform.
The National Cyber Security Centre (NCSC) treats AI security as a continuous lifecycle covering:
- Secure design
- Secure development
- Secure deployment and
- Secure operation and maintenance
Many organisations invest heavily in the first three stages but under-estimate the operational discipline required after go-live. Monitoring model drift, deploying updates safely, maintaining performance and preserving governance controls are ongoing operational responsibilities, not one-off implementation tasks. This is where mature MLOps capabilities become essential, ensuring AI remains secure, reliable and compliant throughout its lifecycle rather than simply functioning on launch day.
Air-gapped AI. What It involves
Air-gapped AI is the most restrictive deployment model and should be reserved for systems where even tightly controlled external connectivity presents an unacceptable level of risk. It is typically appropriate for highly sensitive intellectual property, critical national infrastructure, defence, government and the most tightly regulated workloads. However, an air gap is not a security shortcut. It reduces one class of risk while increasing operational responsibility.
A genuinely air-gapped environment has no external network connectivity. There is no NAT, no external DNS resolution and no route by which data can leave the environment. Every aspect of secure design, development, deployment and operation must therefore assume zero external connectivity rather than simply restricted connectivity, as reflected in the NCSC’s Guidelines for Secure AI System Development.
This shift is also reflected in the latest ETSI AI security standard, highlighted by the NCSC, which places increasing emphasis on measurable lifecycle controls, governance and operational assurance rather than broad statements of security best practice.
The greatest operational challenge is maintaining the platform over time. Without external connectivity there is no automatic patching, no live model updates, no vendor telemetry and no remote administration. Every change must be deliberately planned, controlled and evidenced.
Update cadence, software signing, offline media transfer, integrity verification, testing and rollback procedures should all be agreed before the system enters production. Without disciplined operational processes, an air-gapped environment can become increasingly difficult to maintain, creating reliability and governance risks that eventually outweigh the security benefits it was designed to provide.
When private AI may not be necessary
Not every AI workload requires private deployment. Many organisations can safely use approved public or enterprise AI services for generic productivity tasks, low-sensitivity internal documents, meeting summaries or non-confidential research. Applying the highest level of security to every use case can add unnecessary cost, complexity and operational overhead without delivering meaningful additional protection.
Private AI becomes appropriate when organisations need greater control over sensitive information, regulatory compliance or operational risk. Common drivers include:
- Protecting customer data
- Safeguarding intellectual property
- Meeting jurisdictional requirements
- Maintaining explainability
- Producing audit evidence and
- Reducing dependency on third-party AI services
The objective is not to deploy every AI workload privately. It is to match the deployment model to the sensitivity of the data, the criticality of the workload and the level of governance the organisation requires. Over-protecting low-risk use cases wastes resources. Under-protecting high-risk ones creates unnecessary exposure.
Sovereign AI UK. Two different things
If you are researching ‘sovereign AI UK’, it is important to distinguish between two very different concepts.
The first is the UK government’s Sovereign AI Unit, a state-backed investment initiative within the Department for Science, Innovation and Technology (DSIT), supported by up to £500 million to help UK AI companies grow. It is an economic investment programme rather than a deployment architecture or security framework.
The second is enterprise sovereign AI, which describes AI infrastructure that operates under the laws, regulatory requirements and governance controls of a specific jurisdiction. Organisations may also introduce procurement, ownership and operational constraints to reduce reliance on external providers and strengthen data sovereignty.
For regulated organisations, this is the more relevant definition. Sovereign AI is less about where infrastructure is physically located and more about maintaining control over data, governance and legal jurisdiction. As organisations place more critical workloads into AI systems, these considerations are becoming increasingly important. Gartner predicts that by 2027, 35% of countries will rely on region-specific AI platforms, reflecting the growing emphasis on sovereignty, resilience and regulatory control.
Matching deployment model to data sensitivity
Treating private AI as an all-or-nothing decision often results in organisations over-engineering low-risk workloads while under-protecting their most sensitive ones. The deployment model should always reflect the organisation’s risk profile, governance requirements and the potential business impact if something goes wrong.
| Data type | Typical sensitivity | Suitable deployment model |
|---|---|---|
| Internal HR or general operational data | Moderate | Hosted private AI may be appropriate |
| Customer PII or regulated operational data | High | Hosted private AI or on-premise AI, depending on regulatory and governance requirements |
| Proprietary trading models, intellectual property or mission-critical workflows | Highest | Air-gapped AI, where any external exposure presents an unacceptable level of risk |
This reflects the principle behind PRA Supervisory Statement SS1/23. The regulation does not prescribe a specific deployment architecture. Instead, it requires organisations to apply governance and model risk controls that are proportionate to the risks they are managing.
Before selecting a deployment model, organisations need a clear understanding of what data they hold, where it resides, who needs access to it and the potential consequences if it were exposed, manipulated or used to generate incorrect or unexplainable outcomes. Only then can they determine whether hosted private, on-premise or air-gapped deployment is the most appropriate choice.
That is why many organisations begin with an AI readiness or risk assessment before making architectural decisions. Understanding the data, governance requirements and operating constraints first leads to more proportionate, secure and sustainable AI deployments.
Executive readiness questions before deployment
| Question | Why it matters |
|---|---|
| What data can the model access, retrieve and generate? | Ensures sensitive information is protected and prevents inappropriate access or disclosure. |
| Where are prompts, outputs, embeddings and audit logs stored? | Supports governance, regulatory compliance, investigations and forensic analysis. |
| Who approves changes to models, data sources and configurations? | Establishes clear accountability, change control and operational governance. |
| How are updates tested, verified and rolled back if necessary? | Reduces operational, security and compliance risks throughout the AI lifecycle. |
| How is model performance monitored over time? | Detects drift, degradation and emerging risks before they affect business operations. |
| Can the system explain its answers or acknowledge when it does not know? | Improves trust, reduces hallucination risk and supports regulated decision-making. |
| How will the platform continue to operate during outages or cyber incidents? | Ensures resilience, business continuity and recovery arrangements are in place before deployment. |
What to expect from a private AI deployment partner
A deployment partner should be able to explain its approach in operational terms, not simply claim that the platform is secure. Security, governance and resilience should be built into every stage of the deployment lifecycle, from initial architecture through to long-term operation and maintenance.
At a minimum, you should expect a deployment approach that aligns with secure design, secure development, secure deployment and secure operation and maintenance, while reflecting emerging AI security standards and regulatory expectations.
This should include:
- Use case assessment to confirm technical feasibility, business value and regulatory suitability before implementation begins.
- Model selection aligned to data sensitivity, performance requirements and operational constraints, rather than simply choosing the largest or newest model.
- Deployment architecture matched to the workload, whether hosted private AI, on-premise or fully air-gapped, based on risk rather than preference.
- Identity, governance and privacy controls embedded into the platform from the outset, including access management, audit logging and change control.
- Operational readiness covering monitoring, observability, incident management, resilience, rollback procedures and ongoing MLOps throughout the AI lifecycle.
- Documentation and evidence that supports internal governance, regulatory assurance and future audits, rather than relying on undocumented operational knowledge.
Proof it Works. Secure AI in regulated environments
These principles are already being applied across regulated industries where AI must operate within strict security, governance and compliance requirements.
One example is Catapult CX’s deployment of AnswerVault within a highly regulated pharmaceutical environment. Embedded directly into Microsoft Teams, the platform retrieves information from approved internal knowledge repositories and produces grounded, referenced responses without requiring users to move into a separate application.
The deployment was designed around ISO 27001 controls, data classification policies, secure development practices and tightly governed access to sensitive information. Rather than exposing proprietary knowledge to public AI services, the organisation retained control over its data while giving employees faster access to trusted information.
The same principles apply within financial services. Use cases such as regulatory evidence packs, complaint investigations, KYC and AML quality assurance and compliance reporting require AI responses that are explainable, auditable and traceable back to approved source material. The objective is not simply to generate answers, but to generate answers that can withstand regulatory scrutiny.
Catapult CX’s work on an identity verification platform used within GOV.UK services provides a second example of the same operational approach. Verification accuracy increased from 50% to 97%, infrastructure costs reduced by more than 96%, throughput increased by 3,100% and model training time fell from two days to 1.5 hours.
Although this engagement focused on MLOps and AI platform engineering rather than private AI deployment itself, it demonstrates the same underlying principle, namely, security, governance, operational resilience and performance should reinforce one another rather than competing for priority. Well-designed AI platforms deliver all four.
Getting started
The first question is not whether your organisation needs on-premise or air-gapped AI. It is whether the data, decisions or business processes involved require greater control than public AI services can provide.
Once that has been established, the deployment model becomes much clearer. Hosted private AI, on-premise AI and air-gapped AI each have a role, depending on the workloads being supported, the governance requirements and the degree of operational resilience your organisation needs.
The most successful deployments begin with governance rather than infrastructure. Understanding what data you hold, where it resides, who needs access to it and how it will be governed provides the foundation for selecting the right architecture and operating model.
For broader context, explore why many AI initiatives fail without regulation-led governance, why private AI is becoming increasingly important in high-security environments and why moving from pilot to production requires more than simply deploying a model.
If you are assessing private AI for your organisation, Catapult CX can help evaluate your data, governance requirements and operational constraints, then recommend the deployment model that best balances security, compliance, resilience and long-term maintainability.
Frequently Asked Questions
What is the difference between private AI and public AI?
Private AI runs on infrastructure your organisation controls, whether hosted in a private cloud, on-premise or in an air-gapped environment. Public AI sends data to infrastructure managed by a third-party provider. The key difference is the level of control you have over data, governance, security and auditability.
Can private AI run in the cloud?
Yes. Private AI is defined by who controls the infrastructure and data boundary, not where the infrastructure is physically located. A properly isolated Virtual Private Cloud (VPC) can provide private AI while remaining distinct from on-premise or air-gapped deployments.
What is the difference between hosted private AI, on-premise AI and air-gapped AI?
Hosted private AI runs in a dedicated cloud environment under your control. On-premise AI runs within infrastructure you own or manage directly. Air-gapped AI has no external network connectivity at all. The appropriate model depends on data sensitivity, regulatory requirements and operational risk rather than one approach being universally better than another.
What is the difference between isolated and truly air-gapped AI?
An isolated environment, such as a VPC with restricted outbound access, still has controlled network connectivity. A truly air-gapped system has no NAT, no external DNS resolution and no route by which data can leave the environment. Removing that connection fundamentally changes how the platform is secured, updated and operated.
When should an organisation choose air-gapped AI?
Air-gapped AI is appropriate where any external connectivity presents an unacceptable level of risk, such as highly sensitive government, defence, critical infrastructure or tightly regulated environments. For many organisations, hosted private AI or on-premise AI provides an appropriate balance between security, governance and operational flexibility.
Is private AI more secure than public AI?
Not automatically. Private AI gives organisations greater control over security, governance, identity, data handling and audit evidence, but it also places greater operational responsibility on the organisation. Security depends on how the platform is designed, deployed and managed throughout its lifecycle.
Is sovereign AI the same as the UK Government’s Sovereign AI Unit?
No. The Sovereign AI Unit is a UK Government investment programme designed to support the growth of UK AI companies. Enterprise sovereign AI refers to AI infrastructure that operates under a specific jurisdiction’s legal, governance and data sovereignty requirements.
Has the UK designated any Critical Third Parties yet?
As of the January 2026 Treasury Select Committee reporting, no organisations had been designated under the Critical Third Parties regime. However, the regulatory framework is already in force and organisations are expected to manage third-party technology risk accordingly.
Does UK financial services regulation require on-premise AI?
No. UK regulation does not mandate a specific deployment model. Frameworks such as PRA Supervisory Statement SS1/23 require organisations to apply model risk management and governance controls that are proportionate to the risks involved. The deployment model should reflect the sensitivity of the data and the operational risk, rather than a regulatory requirement to use on-premise infrastructure.
How do you decide which private AI deployment model is right?
The decision should be based on the sensitivity of the data, regulatory obligations, operational resilience requirements and governance needs. Many organisations begin with a structured AI risk assessment before deciding whether hosted private AI, on-premise AI or air-gapped AI is the most appropriate deployment model.
