AI Policy Enforcement Needs Runtime Controls, Not Just Acceptable Use Documents

AI Trust & Governance

10 June 2026 | By Ashley Marshall

Most AI policies fail at the exact moment they are needed: when a busy employee pastes live data into a tool, connects an agent to a system, or accepts an output without evidence.

The policy gap is operational, not grammatical

The common mistake is treating an AI acceptable use document as if it were a control. It is not. It is a statement of intent. It tells people what the organisation expects, but it does not stop a recruiter uploading candidate data to an unapproved summarisation tool, a developer pasting production logs into a public chatbot, or a sales team using a browser extension that reads every page in the CRM. The gap is not usually that the policy is badly written. The gap is that the policy does not exist at the point where data moves, permissions are granted or outputs become business records.

That distinction matters because AI usage is no longer theoretical. The DSIT AI Adoption Research found that around 1 in 6 UK businesses were already using at least one AI technology, and among adopters 85% were using natural language processing and text generation. YouGov reported in April 2026 that 64% of UK enterprises were using AI to some extent, with 10% saying they had fully embraced it and 22% experimenting. Those figures describe a market where AI is already in everyday work, not one waiting for a governance pack to be approved.

A policy still has value. It defines approved use cases, prohibited data, human accountability, supplier requirements and escalation routes. But if the organisation cannot see which tools are in use, cannot distinguish a corporate AI account from a personal one, cannot inspect sensitive prompts, and cannot prove who approved high-risk outputs, it has governance in wording only. A useful way to think about the problem is this: the document says what should happen, while runtime controls determine what can happen. For UK leaders, the job is to connect the two. The policy should become a set of technical, procedural and evidential gates inside real workflows.

UK regulators are asking for evidence, not good intentions

The UK does not currently have one single horizontal AI Act equivalent to the EU model, but that does not mean AI governance is optional. UK organisations still sit under UK GDPR, the Data Protection Act 2018, sector rules, contract duties, employment law, consumer protection expectations and board accountability. The practical message from regulators is increasingly consistent: you need to show how risks are managed in context, not merely assert that people have been told to behave responsibly.

The ICO audit toolkit on governance and accountability in AI expects risk assessment, DPIA processes where needed, audit programmes, change management and information flow mapping. Those are evidence mechanisms. They ask whether risks are tracked, whether changes are logged, whether audits reach senior management and whether supply chain processing is understood. The ICO also warned in May 2026 that AI-powered phishing, deepfake social engineering, automated vulnerability scanning, adaptive malware, credential attacks and data poisoning are practical threats, not abstract future scenarios. A static policy does not respond to any of those at runtime.

The FCA position points in the same direction for financial services. In its June 2026 note on AI in financial services, the regulator said it was not planning new AI-specific regulations and would instead rely on existing frameworks such as Consumer Duty, the Senior Managers and Certification Regime, governance and controls. That is an important business signal. If a regulated firm uses AI to support customer communications, triage vulnerability, draft advice, summarise complaints or screen transactions, the question will not be whether a PDF policy exists. The question will be whether the firm can evidence oversight, testing, monitoring, fair treatment and accountable decision making inside the workflow. That is why the next practical step after an AI policy is an enforcement design.

Runtime controls turn policy into enforceable business behaviour

Runtime controls are the mechanisms that apply policy while AI is being used. They include identity checks, model routing, prompt inspection, data loss prevention, retrieval permissions, approval queues, output filters, logging, rate limits, tool restrictions, human review and incident triggers. They do not replace policy. They convert policy from advice into operating conditions. If the policy says customer records must not enter public AI tools, a runtime control can block or redact that content. If the policy says only the legal team can use AI on privileged material, role-based access can enforce that. If the policy says high-impact outputs need review, workflow approvals can stop the output becoming a record until a named person signs off.

This is not exotic technology. Most medium-sized firms already own part of the control stack. Microsoft Purview can support sensitivity labels and DLP. Microsoft Defender for Cloud Apps, Zscaler, Netskope and Cisco Secure Access can help with cloud app visibility and policy enforcement. Cloudflare AI Gateway, Portkey, LiteLLM and similar gateway patterns can centralise model access, rate limits, observability and routing. Okta, Microsoft Entra ID, CyberArk and BeyondTrust can anchor identity, privileged access and non-human identity controls. On the model side, Azure AI Content Safety, Amazon Bedrock Guardrails, Google Vertex AI controls and OpenAI enterprise administration features can support content rules, logging and managed access. The exact mix depends on the environment, but the principle is stable: AI usage should pass through governed routes wherever possible.

The practical business angle is speed. Runtime controls let teams use AI with fewer meetings because the common risks are handled by design. A support team should not have to ask legal every time it summarises a customer ticket if the system already masks protected fields, logs the request, restricts the model and routes edge cases to review. A procurement team should not manually police every supplier trial if the gateway already distinguishes approved tools from unknown ones. Good controls make responsible adoption easier, not slower. This connects directly with AI inference audit trails because enforcement and evidence are two sides of the same operating model.

Shadow AI exposes the weakness of paper-only governance

Shadow AI is where the misconception becomes expensive. Employees rarely set out to create risk. They are trying to move faster: draft a proposal, summarise a spreadsheet, debug an error, clean meeting notes, compare contract clauses or prepare a customer response. The problem is that many of those actions involve confidential, personal or regulated data. If they happen through personal accounts or unsanctioned tools, the organisation may lose visibility, supplier assurance, retention control and audit evidence at the same time.

Security vendors are now seeing the scale. Zscaler wrote in its May 2026 shadow AI guidance that ChatGPT alone generated more than 410 million DLP policy violations in 2025, each representing sensitive data attempting to leave an organisation through an AI tool. Cyberhaven reported in March 2026 that employees input sensitive information into AI tools on average once every three days, and that 32.3% of enterprise ChatGPT usage, 58.2% of Claude usage and 60.9% of Perplexity usage happened through personal rather than corporate accounts. Those numbers should make any board pause. A policy telling staff not to paste sensitive data into unauthorised AI is useful, but it is weak evidence that it did not happen.

Blanket blocking is tempting, but it often makes the evidence problem worse. If people move to phones, home devices or obscure tools, the organisation has less visibility than before. A more workable approach is to create approved routes and inspect the risky moments. That means discovery of AI tools in use, SSO for sanctioned services, prompt and upload DLP, warnings for borderline actions, blocks for restricted data, and a route for requesting exceptions. For smaller UK firms, the starting point can be modest: approved tools, account ownership, browser or network visibility, DLP for obvious personal data and central logging for high-risk use cases. The aim is not to criminalise staff curiosity. It is to stop normal productivity behaviour becoming unmanaged data transfer.

Agentic AI raises the stakes from answers to actions

The runtime control argument becomes stronger when AI systems can act, not just answer. Agentic AI can query tools, retrieve files, update records, send messages, create tickets, trigger workflows and call APIs. At that point the risk moves from inaccurate text to operational change. A badly governed chatbot may produce a poor summary. A badly governed agent may alter a customer record, expose a dataset, approve an exception or trigger downstream work before a human has meaningfully reviewed what happened.

The NCSC’s May 2026 blog on thinking carefully before adopting agentic AI is blunt about this. It says agentic systems increase risk because they can access broader data and tools, behave unpredictably, make problems harder to spot and make explanations more difficult. Its practical advice is familiar but important: start small, use tightly bounded pilots, apply least privilege, limit scope, avoid long-lived credentials, monitor behaviour, threat-model deployments and plan for incidents. That is runtime governance language. It is about what the system is allowed to do in the moment, who can stop it and what evidence remains afterwards.

The financial sector warning is equally direct. In May 2026, the FCA, Bank of England and HM Treasury joint statement said current frontier AI cyber capabilities are already exceeding what a skilled practitioner could achieve, and at greater speed, greater scale and lower cost. It urged firms to strengthen governance, vulnerability management, third-party risk, access management, data protection, response and recovery. For any business deploying agents, that maps to concrete controls: each agent needs an owner, a purpose, scoped permissions, short-lived credentials, tool allowlists, action logs, kill switches, rollback plans and review thresholds. This is the natural extension of AI incident response playbooks: you design the stop button before the incident.

What leaders should implement before AI use scales

The right sequence is policy, inventory, control, evidence and review. First, define the acceptable use position in plain English: approved tools, prohibited data, high-risk use cases, human accountability, supplier conditions and escalation routes. Second, build an inventory of AI systems and AI-enabled features, including copilots embedded in SaaS products. Third, map each policy requirement to a runtime control. If the policy says personal data must be protected, where is DLP or masking applied? If the policy says outputs must be reviewed, where does the workflow pause? If the policy says suppliers must meet security requirements, where is procurement evidence stored and who can approve exceptions?

Fourth, decide what evidence the board, customers or regulators would need after a problem. This usually includes who used the system, what data category was involved, which model or tool was called, what retrieval sources were used, what output was produced, who approved it, what downstream action occurred and whether any exception was granted. Those evidence requirements should shape logging from day one. It is much harder to reconstruct AI evidence after a complaint, breach or failed customer outcome.

Fifth, make controls proportionate. Not every AI task needs a committee. Low-risk drafting can be logged with light-touch guidance. Customer-impacting outputs may need review. Sensitive data may need masking or approved enterprise tools only. Agents that can write to business systems need stronger identity, permission and rollback controls. The commercial benefit is that leaders can say yes to useful AI faster because they know where the boundaries are. That is the business case for runtime controls: they reduce risk, but they also remove uncertainty. Staff know which route to use, managers know what they can approve, security teams see the data flows and boards get evidence instead of anecdotes. A written policy starts the conversation. Runtime controls make it real.

Frequently Asked Questions

Is an AI acceptable use policy still worth having?

Yes. The policy sets the organisation's intent, approved use cases, prohibited data and accountability model. The problem is assuming the document enforces itself. It should be the source for runtime controls, training, procurement checks and audit evidence.

What is a runtime AI control?

A runtime AI control is a guardrail that operates while AI is being used. Examples include SSO, role-based access, prompt inspection, DLP, model gateways, approval workflows, output filters, logging, tool allowlists, rate limits and kill switches for agents.

Which runtime controls should a UK SME start with?

Start with an approved tool list, managed accounts, central logging for high-risk AI use, basic DLP for personal and confidential data, and named owners for any AI workflow that touches customers, finance, HR or regulated data.

Is blocking public AI tools enough?

Usually not. Blocking can reduce obvious risk, but it may push use to personal devices or unknown tools. A better pattern is to provide approved routes, monitor usage, block genuinely high-risk data flows and give staff a clear way to request exceptions.

How does this connect to UK GDPR?

If AI use involves personal data, organisations need a lawful basis, transparency, data minimisation, security and accountability. Runtime controls help prove that personal data was restricted, logged, protected and processed through approved suppliers.

Do Microsoft Copilot or ChatGPT Enterprise remove the need for controls?

No. Enterprise tools help because they offer stronger administration, contractual terms and account controls, but organisations still need data classification, permissions, logging, output review and clear rules for what users may do inside those tools.

Who should own AI runtime controls?

Ownership is usually shared, but accountability should not be vague. Security, data protection, IT, legal, risk and business owners all have roles. Each material AI system should have a named business owner and a named technical control owner.

How can a board tell whether AI controls are working?

Ask for evidence: inventory coverage, approved versus unapproved tool use, DLP events, exception volumes, model gateway logs, review outcomes, supplier changes, incidents, near misses and whether high-risk workflows have tested stop and rollback procedures.