Classify AI Workloads Before Choosing Cloud or On-Premise

The Sovereign Cloud

18 May 2026 | By Ashley Marshall

The wrong AI hosting decision usually starts before procurement. UK firms are choosing cloud or on-premise before they have classified the workload.

Classification comes before infrastructure

The choice between on-premise AI and cloud AI is often framed as a technology preference. It is not. For most UK firms, it is a workload classification problem that has been dressed up as a hosting debate. Before a board approves GPUs in a server room, a sovereign cloud contract, or a new managed AI platform, it needs to know what the workload actually touches: regulated personal data, commercial secrets, operational systems, client records, employee data, intellectual property, or public information. Those categories change the answer.

The latest government signals make this more urgent, not less. The Department for Work and Pensions cloud computing security policy says cloud decisions must be risk-informed, must evaluate data sensitivity and jurisdictional risks, and must align to the NCSC cloud security principles. It also requires cloud providers to identify embedded AI services that may access, process, or analyse departmental data, and prohibits using DWP data for AI model training unless explicitly authorised by contract. That is a practical model private firms should copy, even if they are not public sector bodies.

The Deloitte AI Institute describes a secure AI backbone as central to privacy protection and agile experimentation, which is another way of saying that workload placement has to be designed rather than improvised. Classification gives leaders a shared language. A low-risk marketing summarisation tool can usually sit in a mainstream cloud service if procurement, retention and access controls are sensible. A client due diligence assistant that ingests passports, bank statements and litigation records needs a different placement decision. A safety-critical model linked to operational technology may need isolation, strict logging and an exit route before anyone discusses vendor preference. The point is not that every sensitive workload belongs on-premise. The point is that no workload should be placed before the risk class is known.

Sovereignty is about leverage, not isolation

Sovereign AI is sometimes misread as a call to abandon public cloud and build everything locally. That is the wrong lesson. In an April 2026 speech reported by GOV.UK, the Technology Secretary said AI sovereignty is not about isolationism or pulling up the drawbridge. The stated aim was reducing over-dependencies and increasing resilience in strategic priorities. The same article noted that 70 per cent of global AI compute is controlled by just five companies. That is the relevant business risk: concentration, dependency and limited negotiating power.

For a UK firm, classification turns sovereignty from a slogan into a set of operating choices. Some workloads need UK data residency, contractual restrictions on support access, customer-managed keys, clear subprocessors and tested exit procedures. Some need a provider with UK-based support staff and no routine offshore access. Some need private cloud or on-premise deployment because the consequence of exposure is too high, the data cannot be separated cleanly, or latency and availability requirements make remote dependency unacceptable. Other workloads can safely use hyperscale AI services because the data is already public, has been minimised, or can be processed through a privacy-preserving design.

What this means in practice is simple: build a placement matrix before buying infrastructure. One axis should classify data sensitivity. Another should classify operational criticality. A third should classify model interaction, from simple retrieval-augmented generation to fine-tuning, agentic workflow execution and autonomous decision support. A fourth should assess dependency risk, including portability, contractual exit, and whether the vendor can train on prompts or outputs. The matrix does not remove judgement, but it stops the decision being based on whichever supplier has the strongest sales deck.

Cloud can be secure, but only for the right class of workload

The strongest counterargument is fair: major cloud providers usually invest more in security, resilience and monitoring than an individual mid-market firm can afford. AWS, Microsoft Azure and Google Cloud offer mature identity controls, hardware security modules, confidential computing options, private networking, key management, logging and regional data controls. For many AI projects, rejecting cloud by default would slow adoption, increase cost and push teams towards unmanaged shadow AI.

The problem is not cloud. The problem is pretending that cloud is a single risk category. A cloud-hosted chatbot that summarises public policy documents is not the same as an AI assistant connected to a case management system, a finance ledger or a customer data lake. The DWP policy makes this distinction explicit by covering IaaS, PaaS, SaaS, public, private and hybrid deployment types, and by requiring formal risk assessment for services that process, store or transmit departmental data. That is exactly the level of granularity most companies still lack.

Practical classification should separate at least five classes: public or low sensitivity workloads, internal productivity workloads, regulated personal data workloads, commercially sensitive workloads, and mission-critical workloads. Each class should have minimum controls. For example, internal productivity may require SSO, audit logs, data retention settings and disabled model training. Regulated data may require a DPIA, UK or approved jurisdiction processing, encryption key control, supplier due diligence, and human review. Mission-critical AI may require isolation, rollback, observability, incident playbooks and supplier evidence that logs, prompts and outputs can be retrieved during an investigation.

This is where tools help. Microsoft Purview, Google Cloud Data Catalog, AWS Macie, BigID, Cyera, Varonis and Collibra can help discover and classify data before it enters an AI workflow. They do not decide strategy for you, but they reduce guesswork. Without discovery and classification, cloud security architecture is mostly theatre.

On-premise AI has a role, but it is not a magic shield

On-premise AI is attractive because it sounds controllable. Data stays inside the building or within a private hosting environment. Network routes are easier to understand. Procurement can point to owned hardware. Security teams can apply familiar controls. For workloads involving defence supply chains, high-value intellectual property, sensitive legal records, health data, manufacturing telemetry or operational technology, those advantages can be real.

Yet on-premise does not automatically solve sovereignty, privacy or security. It introduces new responsibilities: GPU supply, patching, model updates, vulnerability management, physical security, backup, disaster recovery, monitoring, inference cost management, and specialist skills. DSIT's 2026 cyber security sectoral analysis underlines why capability matters. It estimates the UK cyber security sector now includes 2,603 active firms, nearly 69,600 full-time equivalent roles and £14.7 billion in annual revenue, but those numbers also show the scale of expertise required to secure modern digital systems. Running AI infrastructure safely is not a side project for an already stretched IT team.

What this means in practice is that on-premise should be justified by workload class, not instinct. It may be the right answer where the data cannot leave a controlled environment, where audit obligations demand direct control over logs and keys, where latency to local systems is critical, or where long-running inference at predictable volume changes the cost model. It is weaker where workloads are experimental, volatile, compute-heavy for short bursts, or dependent on fast access to frontier models that will change every few weeks.

A sensible classification process can recommend hybrid patterns. Keep the sensitive corpus inside a private environment. Use retrieval controls and redaction before sending limited context to a cloud model. Run open-weight models such as Llama, Mistral or Qwen locally for specific tasks, while using managed cloud models for lower-risk generation. The best architecture is rarely pure cloud or pure on-premise. It is matched to the workload.

Regulation makes the evidence trail as important as the hosting choice

UK firms need to think beyond where the server sits. Regulators care about accountability, fairness, security, purpose limitation and evidence. The ICO's 2026 guidance plan says general data protection guidance is being updated to include amendments from the Data (Use and Access) Act, with a final version due in summer 2026. Existing UK GDPR duties still apply: organisations need a lawful basis, data minimisation, transparency, security, retention control and, for high-risk processing, a data protection impact assessment. AI workload placement has to support those duties.

This is why classification should create an evidence trail. For each AI use case, record the data categories, lawful basis, model type, hosting option, supplier, subprocessors, data retention settings, prompt and output logging, human oversight, transfer risks, and decision rationale. If the workload later moves from prototype to production, the classification should be revisited. If the model gains tool access, autonomous action or access to additional datasets, the workload class may change.

The NCSC and wider government position also points towards secure-by-design controls rather than blanket prohibitions. The DWP policy refers to the shared responsibility model, least privilege, phishing-resistant authentication for privileged access, encryption at rest and in transit, customer control of keys for sensitive data, logging, monitoring, incident handling, supplier obligations and secure exit. Those are not abstract security phrases. They are placement criteria.

For example, if a vendor cannot provide evidence about where prompts are processed, who can access support logs, whether customer data is used for training, and how incident evidence can be retrieved, then the workload class should be capped at low sensitivity until those questions are answered. If a supplier can provide clear contractual assurances, regional controls, audit evidence and technical safeguards, a higher class may be acceptable. The evidence decides the placement.

Build a workload placement process your teams will actually use

The mistake is making classification so heavy that teams avoid it. A useful AI workload process should be short enough to use before a pilot, but strong enough to stop obvious mistakes. Start with a one-page intake: business purpose, data inputs, expected outputs, users, affected customers, systems connected, model or vendor, retention needs, and whether the tool can take actions. Then score the workload across sensitivity, criticality, autonomy, external exposure and reversibility.

From there, assign a placement pattern. Class 1 might be public data and low-risk experimentation in approved SaaS tools. Class 2 might be internal productivity with SSO, no training on customer data and retention controls. Class 3 might be regulated or confidential data in approved UK or equivalent regions with DPIA, supplier review and audit logging. Class 4 might be high-risk workloads requiring private cloud, customer-managed keys, security review, human approval and tested rollback. Class 5 might be restricted or mission-critical workloads that require on-premise, private hosting or a bespoke architecture approved by legal, security and operations.

Make procurement part of the process. Every AI supplier questionnaire should ask about model training, data residency, support access, subprocessors, deletion, audit logs, encryption, incident notification, portability and exit. Make architecture part of the process too. A workload classified for cloud today may need different controls once it is connected to CRM, HR, finance or operational systems. Agentic AI raises the stakes because the system may not just read information. It may trigger emails, update records, buy services or make recommendations that affect people.

The outcome is faster adoption, not slower adoption. Teams get pre-approved patterns instead of bespoke arguments for every tool. Boards get a defensible reason for cloud, on-premise or hybrid. Security gets controls tied to actual risk. And the business avoids the most expensive mistake of all: choosing infrastructure first, then discovering the workload was never suitable for it.

Frequently Asked Questions

What is AI workload classification?

It is the process of categorising an AI use case by the data it uses, the systems it touches, the decisions it supports, the level of autonomy it has and the consequences if it fails or leaks information.

Does sensitive AI data always need to stay on-premise?

No. Some sensitive workloads can run in cloud if the region, contract, encryption, key control, access logging, retention and supplier assurance are strong enough. Others genuinely need private or on-premise deployment.

What should be classified before an AI pilot starts?

At minimum, classify data sensitivity, business purpose, user groups, connected systems, output use, model or vendor, data retention, training permissions and whether the AI can take actions.

How does UK GDPR affect AI hosting decisions?

UK GDPR requires accountability, security, data minimisation, lawful basis, transparency and appropriate risk assessment. The hosting model must support those duties, especially for personal data or high-risk processing.

What is the main risk of choosing cloud first?

The business may later discover that prompts, outputs, logs, support access or subprocessors create regulatory, contractual or client confidentiality problems that should have been identified before deployment.

What is the main risk of choosing on-premise first?

The firm may take on infrastructure, patching, monitoring, model maintenance, resilience and specialist skills costs without a workload that truly needs that level of control.

Which teams should own workload classification?

Business owners should describe the use case, security should assess controls, legal and privacy should review data and contracts, and architecture should decide placement patterns. It should not sit with IT alone.

How often should AI workloads be reclassified?

Reclassify whenever the workload moves from prototype to production, adds new datasets, gains tool access, affects customers or employees, changes supplier, or becomes operationally critical.