UK organisations are deploying AI at pace and governing it with paper. When something goes wrong, or a regulator asks a pointed question, the response is a policy update, a new ethics committee, a revised framework. The compliance box gets ticked. The infrastructure problem does not get solved.
The problem is that AI regulation is no longer a paperwork exercise. It is rapidly becoming a question of infrastructure, and most organisations are entirely unprepared for what that means in practice.
The Compliance Illusion
For the past several years, AI governance has been treated predominantly as a soft discipline: responsible use principles, bias frameworks, model documentation, ethical review boards. These things matter, and they should exist. But they have been allowed to stand in place of something harder and more urgent – a genuine understanding of the technical environments into which AI is actually being deployed.
The UK has deliberately avoided standalone AI legislation, empowering existing sectoral regulators to apply principles-based guidance instead. As of April 2026, the DSIT Blueprint for AI regulation centres on an AI Growth Lab model of sectoral sandboxes, and there is still no primary AI Bill on the statute book. The regulatory floor remains in flux, and enterprises are filling the gap with policies rather than controls. That is not a governance strategy. It is a liability in waiting.
Both the EU AI Act and ISO 42001 share a common and important assumption: that organisations understand what AI systems they have deployed, what data those systems are processing, and what infrastructure they are running on. The problem is that assumption is not being met. The frameworks are sound. The foundations they are being applied to are not.
Where the Real Risk Lives
The real risk is not the model. Organisations are deploying AI into infrastructure they do not fully understand, have not adequately mapped, and have no established regulatory footing to manage. They are connecting AI tooling to legacy systems, inconsistent data environments and cloud configurations that were never designed with AI workloads in mind. Traditional security tools were not built for this era. The AI system is not the primary attack surface. The environment it has been dropped into is.
The NCSC has assessed that the growing incorporation of AI models and systems across the UK’s technology base, and particularly within critical national infrastructure, almost certainly presents an increased attack surface for adversaries to exploit. Insufficient cyber security, the agency warns, will almost certainly increase opportunities for capable state-linked actors and cyber criminals to misuse AI in support of offensive activities. The question is whether enterprise security functions are responding with the same urgency that regulators are beginning to apply.
Regulation Is Starting to Demand Technical Answers
The ICO has recently flagged renewed urgency around AI-powered cyber threats and requires organisations processing personal data to implement AI governance, including Data Protection Impact Assessments where AI tools process high-risk personal data. Regulators are no longer simply asking whether an organisation has an AI policy. They are beginning to ask whether it can demonstrate, at a technical level, how AI systems interact with personal data, what controls exist at the infrastructure layer, and what the incident response plan looks like when something goes wrong.
For enterprises touching EU markets, the pressure is more acute still. The EU AI Act’s risk-based classification system means that high-risk AI deployments in areas such as HR decision-making, credit assessment and critical infrastructure management carry mandatory conformity assessment requirements that cannot be satisfied with a policy document alone.
But the Regulatory Framework Has Its Own Gap
To be clear: the problem is not only that enterprises are failing to meet regulatory expectations. The UK’s principles based approach, by design, creates no binding obligation to demonstrate infrastructure-level controls. There is no statutory requirement to inventory AI tooling, map data flows at the infrastructure layer, or submit to technical audit. The DSIT Blueprint and the AI Growth Lab framework are innovation-first instruments; they do not compel organisations to close the gap between what their governance documentation says and what is actually running on their networks. That is a structural weakness, not just a behavioural one. Until the regulatory floor includes mandatory technical accountability, not just principles to which organisations self-attest, the compliance illusion will persist regardless of how well intentioned the policy environment is.
The Shadow AI Problem Nobody Wants to Discuss
Compounding all of this is the quiet proliferation of AI tools being used without IT or security oversight. When employees connect third-party AI tools to corporate systems, use generative platforms to process sensitive client information, or rely on AI-enabled SaaS features that have bypassed procurement entirely, the governance framework sitting on the intranet is irrelevant. The exposure is live and it is happening at the infrastructure layer, not the policy layer. Any audit, regulatory inspection or incident investigation that follows will quickly expose the gap between what the governance documentation says and what is actually running on the network.
What Governance Actually Requires
Governance documentation, acceptable use policies and risk classification processes all have a genuine function. But they need to be built on a foundation of infrastructure understanding, not used as a substitute for it. Which AI tools are in active use, including those that bypassed formal procurement? What data environments are they touching? Do existing penetration testing programmes account for AI workloads specifically? Can the organisation demonstrate those answers to a regulator, not just assert them in a written framework?
The organisations that treat AI regulation as a compliance exercise will be caught out when regulators begin demanding technical accountability. The ones that treat it as an infrastructure problem will be better placed to meet that moment.
The policy document matters. But only if there is something solid underneath it; and right now, for most organisations, there is not. That is a problem enterprises need to fix. It is also a problem that regulation, as currently written, does not force them to.
