British companies are moving artificial-intelligence workloads into production faster than they are building the systems needed to explain why those workloads fail, creating a gap between executive confidence in AI infrastructure and what engineering teams say they can actually diagnose.

A survey published by Virtana found that 59% of 238 UK enterprise decision-makers said their organisations were scaling AI across teams, while another 17% reported early production workloads. Yet 53% were operating infrastructure that they could not fully observe across all the systems involved.

The difference becomes sharper when responses are separated by role. Virtana found that 59% of executives believed their organisation could automatically identify the root cause of a failure across systems, whereas only 34% of infrastructure engineers agreed, leaving the people approving investment considerably more confident than those responsible for diagnosing problems when systems break.

Only 47% of respondents overall said root causes could be identified automatically across all infrastructure domains. Another 32% could see only a single domain, 12% needed to correlate information manually across tools, and 8% said diagnosis could require several teams working for hours or days.

The vendor-sponsored research should not be treated as a census of UK enterprise AI, although the gap it identifies points towards an increasingly practical deployment problem. AI workloads depend simultaneously on models, accelerators, storage, networks, data pipelines, cloud services, and application infrastructure, which means monitoring divided between separate technical domains can generate plenty of alerts without explaining the service failure a user actually experiences.

That fragmentation becomes expensive when the underlying hardware is costly. Two-thirds of respondents said the price of premium AI hardware had changed their investment approach, while only 26% described AI workload performance as highly predictable.

Production AI exposes infrastructure gaps

Enterprise AI has moved far enough beyond isolated demonstrations that its operational characteristics are beginning to resemble those of other production systems, albeit with a more complicated dependency chain. Organisations need to know whether a slowdown comes from a model, data pipeline, network bottleneck, storage layer, accelerator, application, or another shared service before engineers can decide whether the remedy is technical, architectural, or simply more capacity.

Virtana’s survey found cost and efficiency metrics, data-pipeline visibility, storage and throughput, network bottleneck detection, and GPU utilisation among the hardest monitoring problems. Those are infrastructure questions rather than model-evaluation questions, showing how quickly enterprise AI is becoming an operations discipline as well as a software-development programme.

The same progression has already exposed problems higher up the stack. Recent research on enterprise AI and organisational context found that companies can struggle to translate operational definitions, rules, and knowledge into AI workflows even while increasing expenditure. Observability creates a parallel challenge underneath those systems because, once the workflow exists, somebody still has to determine why it becomes slow, expensive, unavailable, or unreliable.

Cost pressure is complicating that work. Among Virtana’s respondents, 54% said AI infrastructure demands were causing cost-optimisation work to be deprioritised, 48% cited delays to legacy-infrastructure modernisation, and 43% reported less emphasis on training and upskilling. More concerningly, 39% said security and compliance reviews were being deprioritised.

Those trade-offs suggest that AI infrastructure budgets cannot be understood simply by counting expenditure on accelerators or cloud capacity. If teams postpone platform modernisation, training, security review, or optimisation to keep new workloads running, some of the cost is being displaced into the surrounding technology estate rather than removed.

Governance depends on operational evidence

The executive-engineering gap also complicates governance because boards and senior technology leaders can approve spending or accept operational risk using information that engineering teams consider incomplete. An organisation that believes failures can already be traced across its environment may see little reason to invest in observability until an incident demonstrates otherwise.

That weakness becomes harder to tolerate as AI is integrated into processes with service commitments, financial consequences, or regulatory scrutiny. Governance policies can define who approves a model and what data it may use, but those controls provide only part of the evidence needed after an outage or unexpected result. Teams also need to reconstruct which infrastructure was running, which dependencies were degraded, and how the failure propagated.

Traditional monitoring products have long promised unified visibility across technology estates, usually with mixed results, and AI infrastructure does not remove the organisational boundaries that made that aspiration difficult. Cloud teams, network specialists, application engineers, data teams, and model developers may own different pieces of the same service, while each technical layer produces its own metrics and alerts.

Observability vendors consequently have a commercial opportunity to extend their platforms into the AI stack, which also makes vendor research on the subject worth treating cautiously. Virtana sells infrastructure-observability software, so the survey is naturally aligned with a market in which weak cross-system visibility appears as an urgent enterprise problem.

The underlying numbers remain useful because they describe organisations making explicit compromises as deployment grows. Fifty-nine per cent say they are already scaling AI across teams, yet fewer than half report automatic root-cause visibility across the entire infrastructure involved, leaving a substantial distance between putting AI into production and operating it with confidence.

As expenditure moves from experiments into recurring infrastructure, the quality of AI operations will be measured through familiar operational metrics: utilisation, latency, service availability, predictable cost, recovery time, and the ability to explain failures. None is as conspicuous as a new model release, but together they determine whether an AI system remains a useful production service once the demonstration ends.