When AI comes up in the boardroom, many organisations arrive at the same conclusion: ‘We can’t use AI’.
The reasons often sound sensible, even responsible. Data sensitivity. Intellectual property. Regulatory pressure. Jurisdictional risk. Sovereign control. In heavily regulated sectors such as financial services and the public sector, those constraints become obvious quickly. But the same questions increasingly affect any organisation looking to use AI with commercially sensitive data or business-critical processes.
In many cases, the problem is not AI itself.
What private AI means for a business
Private AI means running AI within an environment where your organisation has greater control over the runtime, data boundary, identity, governance and audit trail.
That does not necessarily mean putting servers inside your own building. Private AI can range from isolated cloud environments through to on-premise and fully air-gapped infrastructure. What matters is the level of control the organisation retains over how data is accessed, processed and governed.
The NCSC’s guidance for secure AI systems reinforces the importance of controlling access to models, APIs, data and processing pipelines, protecting sensitive information and understanding where and how organisational data can be used, accessed and stored.
| Public or managed AI services | Private AI | |
|---|---|---|
| Infrastructure | Primarily operated by an external provider | Operated inside a defined environment controlled by the organisation |
| Data boundary | Data handling depends on the provider, product and contractual terms | Data flows and external access can be deliberately restricted |
| Governance | Relies partly on provider controls and assurances | Greater ability to define access, logging and operating policies directly |
| Best fit | Generic productivity and lower-sensitivity workloads | Sensitive data, valuable IP, high-control or business-critical workloads |
Neither approach is automatically right.
The useful question is not “public or private?” in isolation. It is what level of control does this particular workload require?
For organisations that have already established a need for greater control, our guide to Private AI Deployment in Regulated Environments explains the differences between hosted private AI, on-premise and air-gapped architectures.
Why private AI matters beyond regulated sectors
Regulated industries often encounter the problem first because their constraints are explicit. But the underlying issue is cross-sector.
What organisations usually mean when they say they cannot use AI is often something more specific: they assumed AI required a SaaS-first delivery model and that delivery model was never viable for the workload they had in mind.
A delivery mechanism was mistaken for the technology itself.
This isn’t necessarily a lack of ambition or a skills gap. It can be a hosting decision, made early, left unexamined and only recognised once it becomes difficult to reverse.
That decision can stall AI initiatives long before models, data or capability become the real constraint.
The quiet killer of AI initiatives. The default SaaS model
AI didn’t enter most organisations as infrastructure. It entered as a product.
Chat interfaces, third-party APIs and vendor-managed platforms became the default mental model. Data goes out, an answer comes back and much of the complexity sits behind the service.
For generic productivity and low-sensitivity workloads, that model can work extremely well.
Problems start when the same architecture is applied to workloads involving commercially sensitive data, valuable intellectual property, demanding audit requirements or business-critical processes without first questioning whether the operating model is appropriate.
Once AI is framed simply as something to buy, everything downstream can inherit that assumption. Pilots are built on external platforms. Workflows depend on third-party APIs. Governance gets considered after the architecture rather than as part of it.
When friction appears, it gets labelled an AI problem instead of an architectural one.
That’s when programmes stall.
‘We can’t use AI’ is usually shorthand for something else
Look closely at AI initiatives that never move beyond early exploration and the pattern is often consistent.
Security teams hesitate once data flows are fully mapped. Legal teams struggle to sign off where processing arrangements or jurisdiction are unclear. Architects discover that core systems cannot integrate safely without introducing exposure. Senior stakeholders become uneasy when sovereignty, third-party dependency or intellectual property enter the discussion.
None of these mean AI itself is technically impossible.
They usually mean the operating model does not meet the organisation’s risk, security or governance requirements.
At that point organisations can feel trapped between two unattractive options: accept risk they cannot justify or stop entirely.
A third option is to reconsider where the AI runs.
The risk of doing nothing. Shadow AI
When an organisation officially declares ‘we can’t use AI’, that rarely guarantees employees stop using it.
More often, usage becomes harder to see.
This is how Shadow AI emerges. Without approved ways to use AI safely, employees can turn to unmanaged tools, personal accounts or unsanctioned services to get their work done.
Microsoft reported in October 2025 that 71% of UK employees surveyed had used unapproved consumer AI tools at work and 51% were continuing to do so every week.
That matters because an organisation can only govern what it understands.
Sensitive information may be submitted to tools without appropriate oversight, auditability or consistent controls. Depending on the provider and product involved, data retention, external access, processing location and model-improvement terms may also differ.
The NCSC specifically recommends transparency about where and how organisational data may be used, accessed or stored, including whether it may be used for retraining or reviewed by employees or partners.
Private AI is therefore not only an innovation decision. In the right environment it can provide an approved boundary within which employees can use AI without pushing sensitive workloads towards unmanaged alternatives.
Data residency, jurisdiction and the AI sovereignty question
A useful distinction for UK organisations is that data residency does not, by itself, answer every sovereignty question.
Knowing that information is stored in the UK or EU is important. But organisations also need to understand who can access it, which organisations are involved in processing it, what contractual arrangements apply and whether information can be accessed from another jurisdiction.
The ICO’s updated international-transfer guidance makes the distinction particularly clear: a transfer can involve making UK-held personal information accessible to a separate organisation outside the UK, not simply physically sending the data abroad.
That makes AI sovereignty broader than server location alone.
Organisations need to understand the complete operating boundary: where data is stored, who can access it, where processing takes place, how access is controlled and what third parties are involved.
Private AI can reduce some of those dependencies by bringing more of the processing under organisational control.
It does not make privacy, security, governance or regulatory obligations disappear. It changes which risks need to be managed and who has direct control over them.
The economics most teams discover too late
Private AI is often assumed to be slower, heavier or more expensive than consuming AI through external APIs.
Sometimes it is.
But the economics can change as workloads grow.
At low volumes, usage-based AI services can provide an extremely attractive way to experiment without infrastructure investment. As throughput, latency requirements and repeated usage increase, however, infrastructure architecture becomes part of the commercial decision.
The correct answer depends on the workload rather than a universal rule.
We have seen how significant that difference can become.
In one Catapult identity-verification project, re-architecting the client’s AI infrastructure and ML workflows reduced infrastructure costs by more than 96%, from approximately $1.2 million per month to $45,000. Verification accuracy increased from around 50% to 97% and platform throughput increased by 3,100%.
That project does not prove private AI will always be cheaper.
It demonstrates something more useful: AI infrastructure economics should be tested against the real workload rather than assumed from the initial delivery model.
The benefit of greater infrastructure control can therefore extend beyond security. Depending on the use case, it may also improve performance, scalability and cost predictability.
When private AI makes sense for a business
Private AI is not necessary for every AI workload.
Many businesses can use approved public or enterprise AI services perfectly well for generic productivity tasks, low-sensitivity research, meeting summaries and other workloads where the risk profile is modest.
Adding private infrastructure where it is not required can increase cost, complexity and operational responsibility without creating sufficient additional value.
Private AI becomes worth considering when one or more of the following materially affects the business case:
- Sensitive customer or organisational data needs stronger boundaries.
- Proprietary information or intellectual property is central to the workload.
- The organisation needs tighter control over access, logging and audit evidence.
- Third-party or jurisdictional dependency creates unacceptable risk.
- AI sits directly inside a high-volume or business-critical operational process.
- Latency, throughput or usage-based pricing materially affects the economics.
The objective is not to move everything into private AI.
It is to match the operating model to the data, workload and risk.
Once that need has been established, the next question is architectural: whether hosted private AI, on-premise infrastructure or an air-gapped environment provides the right balance. Our Private AI Deployment in Regulated Environments guide examines those deployment choices in detail.
What changes when hosting is decided first
When organisations stop starting with AI tools and begin by asking what operating boundary the workload requires, the conversation changes.
Security, architecture and governance teams can engage before choices become difficult to reverse. Use cases can be shaped around viable data flows and acceptable controls rather than retrofitting governance to whichever platform was chosen for the pilot.
The NCSC’s secure-AI guidance follows the same underlying principle: security should be considered across design, development, deployment and ongoing operation rather than added at the end.
Most importantly, AI can move from being an isolated experiment towards becoming a capability the organisation understands and controls.
The hosting decision does not solve every AI problem.
It can prevent the wrong architecture from becoming one.
The strategic takeaway
Organisations that say they ‘can’t use AI’ may be telling the truth within the operating model they have assumed is mandatory.
Changing that assumption can open up options that were previously dismissed.
Private AI is not automatically safer, cheaper or better than public AI. Nor should every workload be moved into a private environment.
Its value is control.
For organisations where data sensitivity, intellectual property, sovereignty, auditability, operational dependency or infrastructure economics materially constrain adoption, that additional control can make previously impractical AI use cases viable.
The strategic question therefore comes before the technical one:
Where should this AI run given the data it will use, the job it will perform and the consequences if something goes wrong?
Answer that before deciding which tool or model to buy.
Private AI works best when it solves a real control or operating constraint rather than becoming an objective in its own right.
Discover how Catapult’s Private AI services help organisations assess whether private AI is appropriate and deploy secure, production-ready AI with the level of control the workload actually requires.
