Artificial intelligence is frequently discussed as a technology revolution. Less attention is given to the operational environment required to make that technology useful, dependable and commercially sustainable.
That environment is becoming significantly more complex.
Behind an apparently simple AI-enabled business service may sit an application, one or more models, retrieval services, corporate data, autonomous agents, APIs, identity platforms, cloud services, networks and third-party suppliers. Beneath those logical components sit increasingly concentrated physical dependencies: specialist processors, data centres, cooling systems, connectivity and electricity.
This matters because organisations do not experience technology architectures. They experience services and business outcomes. If an AI platform is technically available but produces unreliable results, if a cloud service cannot be moved economically, if an autonomous agent acts using inappropriate authority, or if a critical service ultimately depends upon one physical location, the wider service may fail even when individual technology components appear to be functioning correctly.
This is where service architecture and service design become increasingly important.
The physical infrastructure can no longer remain invisible
The scale of infrastructure being built to support AI makes its relationship with business services difficult to ignore.
The International Energy Agency's 2026 outlook estimates that global data-centre electricity consumption will almost double from approximately 485 TWh in 2025 to 950 TWh by 2030, equivalent to around 3% of global electricity demand. Electricity consumption specifically from AI-focused data centres is expected to triple over the same period. Source: International Energy Agency, 2026.
The UK's own ambitions illustrate the scale of the change. The Government's UK Compute Roadmap forecasts a requirement for at least 6 GW of AI-capable data-centre capacity by 2030, approximately three times the capacity available when the roadmap was published. It envisages nationally significant sites capable of supporting at least 500 MW each, with at least one AI Growth Zone exceeding 1 GW. Source: UK Compute Roadmap.
Data centres were also designated UK Critical National Infrastructure in September 2024, recognising their importance to economic activity and public services. Source: UK Government.
These are not simply infrastructure statistics. They expose dependencies that need to be understood at service level.
For years, an architectural diagram ending with the words "cloud provider" or "data centre" may have been considered sufficient. Increasingly, that is not enough. Critical services may share cloud regions, connectivity providers, identity services or underlying physical facilities without business owners appreciating the concentration of risk.
Multiple applications and multiple suppliers do not necessarily provide resilience if they ultimately converge on the same underlying dependency.
Service architecture therefore needs to expose not simply what technology a service uses, but what the service ultimately depends upon to continue delivering its business outcome.
What changes for service architecture
The implications extend across resilience, service measurement, identity, data, suppliers, cost and support. The following view provides a concise summary of the design challenge and the corresponding mitigation.
| Challenge | Service design / architecture implication | Mitigation |
|---|---|---|
| Physical infrastructure becomes part of the dependency chain | Power, cooling, connectivity, cloud regions and physical location can constrain the business service. | Extend dependency modelling beyond applications and suppliers. Design geographic and capacity diversity according to business criticality. |
| Infrastructure density creates concentration risk | Apparently separate services may share the same cloud region, identity platform, DNS, connectivity or facility. | Model correlated failure and shared dependencies. Define degraded operating modes as well as recovery arrangements. |
| AI behaviour is probabilistic | A service may be technically available while producing unacceptable or unreliable outcomes. | Add outcome-quality measures such as groundedness, accuracy, intervention rate, drift, latency and successful-task rate. |
| AI agents introduce autonomous actors | Ownership, authority, segregation of duties and traceability become harder when agents invoke tools and other systems. | Give significant non-human actors distinct ownership and identity, apply least privilege, retain audit trails and require human control for consequential actions. |
| Data becomes part of the service architecture | Service behaviour may change because data, prompts or model versions changed even when no conventional software release occurred. | Control model, prompt and data lineage. Record provenance, classification, residency, ownership and lifecycle alongside other service assets. |
| Supplier concentration and lock-in | Cloud, model, SaaS and identity dependencies can combine into a much larger switching and continuity risk. | Design and test exit architecture, including data extraction, interfaces, licensing, model substitution and knowledge transfer. |
| Cost becomes an architectural characteristic | Agentic workflows can multiply model calls, searches and downstream actions from a single request. | Measure cost per transaction and business outcome; use quotas, routing, caching and proportionate model selection. |
Resilience is about the service, not merely the infrastructure
Modern data centres are extraordinarily resilient pieces of engineering, but resilient infrastructure does not automatically produce a resilient business service.
Uptime Institute's 2026 outage analysis found that 57% of respondents said their most recent major outage cost more than $100,000, while one in five reported costs exceeding $1 million. Power remained the leading cause of impactful data-centre outages, while grid constraints, high-density workloads and external connectivity were creating additional pressures. Uptime also reported that failures to follow established procedures remain the leading driver of outages associated with human error. Source: Uptime Institute, Annual Outage Analysis 2026.
There is an important service-design lesson in those findings. Technology resilience, operational process, people, suppliers and external infrastructure cannot sensibly be considered independently.
A business service may have redundant servers but a single network path. It may operate across multiple applications but rely upon one identity platform. It may use several SaaS providers which themselves operate from the same hyperscale cloud. It may have technical recovery arrangements without anybody having defined how the organisation operates while recovery takes place.
Good service architecture should reveal those relationships before an incident does.
That means understanding failure domains, correlated dependencies, recovery priorities and degraded operating models at the level of the business service, rather than relying solely upon component-level availability figures.
AI challenges what we mean by a service being 'available'
AI introduces another complication because an AI-enabled service can be technically available while still failing to provide an acceptable outcome.
Traditional measures of service performance are predominantly deterministic. The application responds, the transaction completes and the infrastructure is available. AI systems introduce probabilistic behaviour into that model.
The US National Institute of Standards and Technology describes generative-AI "confabulation", commonly called hallucination, as the generation and confident presentation of erroneous or false content. NIST notes that this behaviour arises from the way generative models produce statistically generated outputs and can be particularly important where decisions require contextual or specialist knowledge. Source: NIST AI 600-1.
This creates an obvious question for service management.
For AI-enabled services, technology availability and successful service outcomes can no longer be treated as the same measure.
Availability alone therefore becomes an incomplete description of service quality. Service architecture increasingly needs to consider measures such as successful business outcomes, accuracy, groundedness, confidence, model drift, human intervention, response latency and the frequency with which an AI-generated decision must be corrected.
The key shift is from measuring whether the technology responded to measuring whether the service delivered an acceptable outcome.
Agentic AI creates a new accountability problem
The growth of agentic AI makes this issue more significant again.
AI is moving from generating information to taking action. Agents can query systems, retrieve information, invoke tools, update records, trigger APIs and interact with other agents.
The UK's National Cyber Security Centre has warned organisations adopting agentic AI to consider what happens if an agent misunderstands its task, exceeds its intended scope or is manipulated. Its 2026 guidance recommends tightly bounded deployment, meaningful human oversight, clear ownership, least privilege and limits on what agents can access and do. Source: NCSC, 2026.
This changes the architecture of accountability.
A conventional transaction might involve a user authenticating to an application which performs an action through a controlled service account. An agentic workflow might instead pass through a user, an AI assistant, several specialist agents, external tools, APIs and service identities before anything happens to the business record.
If that action is wrong, who authorised it? Which identity performed it? What information was available to the agent? Which model and instructions influenced the decision? Can the organisation reconstruct the transaction afterwards?
These questions are not simply cyber-security questions. They concern service ownership, operating models, authority, auditability and operational control.
NCSC secure-design guidance recommends restrictions where AI components can trigger actions and the application of least-privilege principles. OWASP guidance similarly recommends minimum necessary privileges and human approval for high-impact actions. Source: NCSC secure AI system development guidance; Source: OWASP.
In practical service terms, non-human actors increasingly need the same disciplines organisations should already apply to people and system accounts: a defined owner, purpose, permissions, lifecycle, controls and an auditable record of activity.
Supplier concentration becomes a service risk
AI also accelerates an existing dependency on a comparatively small number of major technology platforms.
The UK's Competition and Markets Authority concluded its cloud services market investigation in July 2025 and found that Amazon and Microsoft held positions of significant market power. It identified data-egress fees, interoperability barriers and licensing practices as factors restricting customers' ability to switch provider or operate effectively across multiple clouds. Source: CMA / UK Government.
In March 2026, the CMA reported that Amazon and Microsoft had taken material steps relating to interoperability and cloud-egress charges, while the regulator continued work intended to improve choice and switching for UK customers. Source: Competition and Markets Authority, March 2026.
The implication for architecture goes beyond procurement.
A service may appear to involve several independent suppliers while retaining a critical dependency upon one cloud ecosystem, model provider, identity platform or proprietary data architecture.
Supplier exit therefore needs to become an architectural design consideration rather than wording buried within a commercial contract.
Can the service genuinely move? Can its data be extracted in a usable form? Could another model be substituted? What interfaces would need to change? How long would transition take? What knowledge exists only with the incumbent supplier?
Commercial exit clauses matter, but so does the practical ability to move the service, data, interfaces, knowledge and operating responsibilities.
Cost and sustainability become service characteristics
AI also makes consumption itself an architectural concern.
One user request may generate multiple model calls, searches, tool invocations and agent interactions. A service can therefore remain technically healthy while its operating cost grows far beyond the value it creates.
At the same time, dense AI infrastructure places new demands on power and cooling. The UK Government's Compute Evidence Annex states that cooling can account for up to 40% of a data centre's total energy consumption, with GPU power requirements and higher-density server arrangements making the challenge more significant for AI facilities. Source: UK Government Compute Evidence Annex, 2026.
Cost, capacity and sustainability should consequently be treated as service characteristics rather than concerns to be examined after deployment.
The appropriate model is not necessarily the largest model, the most capable platform or the most sophisticated infrastructure. It is the architecture that provides the required business outcome at an acceptable level of risk, resilience and cost.
That is ultimately an investment decision.
Technology is becoming easier to consume. Services are becoming harder to govern.
One of the paradoxes of AI is that powerful technology is becoming extraordinarily easy to acquire.
A team can provision cloud capacity, access a sophisticated language model or deploy an AI agent in a fraction of the time previously required to procure and implement major enterprise technology.
The risk is that dependencies, costs, supplier relationships, data flows and operational responsibilities can accumulate just as quickly.
This changes the role of service architecture.
Its value is not in producing additional technical documentation or imposing another framework around delivery. Its value lies in maintaining sight of the business service while the technology beneath it becomes more distributed, autonomous and commercially interdependent.
That means understanding what the service depends upon, who owns those dependencies, what happens when they fail, how AI decisions can be traced, how suppliers can be changed, what degraded operation looks like, how much the service costs to run and whether the expected business benefit is actually being realised.
AI and the rapid expansion of data-centre capacity therefore do not make service design less relevant.
They raise the stakes.
As technology becomes easier to deploy, the differentiator will increasingly be whether organisations can turn that technology investment into services that are operable, resilient, accountable, economically sustainable and capable of delivering the intended business outcome over time.
That is not primarily a technology problem.
It is a service architecture problem.