Unapproved by Default: A Working Governance Model for Staff AI Use in UK Organisations

There is a predictable pattern in UK organisations right now. A procurement team has signed off one or two AI assistants. The IT service desk supports them. Legal has reviewed the terms. And somewhere in a finance department, three people are pasting supplier contracts into a free browser-based chatbot because it summarises faster than they can read.

The gap between the approved list and the actual list is the whole problem. It is not usually malice, and it is rarely a failure of policy — most organisations have a policy. It is a failure of visibility and of usability. Staff adopt tools that solve an immediate problem, and the rules that were meant to govern them were written by people who have never had to summarise a twelve-page lease by Friday.

What follows is a working model rather than a sermon. It assumes unsanctioned use already exists, that it cannot be eliminated by prohibition alone, and that the objective is a defensible position under UK GDPR and the Data Protection Act 2018 rather than a perfectly clean inventory.

Start by fixing the question you are asking

Most discovery exercises fail at the framing stage. Teams ask "which AI tools are we using?" when the useful question is "where is organisational data leaving our controlled environments, and in what form?" The first question produces a list of vendors. The second produces a risk register.

The distinction matters because AI use is now embedded in tools nobody would describe as AI. A meeting transcription feature inside a video conferencing platform, a summarisation button in a document suite, a suggested-reply function in a helpdesk product. None of these show up if you search your software asset register for "artificial intelligence".

Phase one: discover, but do not surveil

There are four sources of evidence that are proportionate, lawful and cheap to assemble.

Egress and DNS telemetry. Your web gateway and DNS logs already record destinations. Aggregating them by category — generative AI endpoints, browser extensions, unclassified SaaS — gives you a picture of volume and spread before you name a single user.

Identity and access logs. Single sign-on records show which applications staff have self-provisioned where the identity provider permits OAuth consent. Review the consent grants, not just the applications you administer.

Expense and procurement signals. Corporate card data for monthly subscriptions is an honest record of intent. So are the software requests that were declined — people often proceed anyway.

Conversation. A short, blameless survey with three questions will surface more than a month of network analysis, provided the framing is amnesty-adjacent rather than disciplinary.

Be careful with endpoint monitoring. Under UK GDPR, processing employee behaviour at device level requires a lawful basis, a necessity assessment and transparency. A data protection impact assessment is not optional garnish here. Where the same insight can be obtained from aggregate egress data, do that instead.

Phase two: classify what is actually exposed

The useful output of discovery is a two-axis map. On one axis, data sensitivity: public, internal, personal data, special category data, commercially confidential, regulated (financial, health, legal privilege). On the other, tool posture: enterprise terms, consumer terms, unknown terms.

The cells that matter are obvious once drawn. Personal data in a consumer-tier tool with an unverified retention policy is a live incident waiting for a subject access request. Special category data in an unapproved transcription service is worse. Public data in a random tool is a rounding error and should be treated as such — over-classifying low-risk activity is how governance loses credibility.

Cross-reference against your Article 30 records. If a processing activity exists in practice and not in the record of processing activities, the record is wrong and needs updating before any audit finds it for you.

Phase three: write rules with edges, not atmospherics

A rule that says staff must "use AI responsibly" transfers the whole judgement back to the person with the deadline. That is not governance; it is delegation by default.

Usable rules are short, tiered and example-led. A three-tier structure works well in most UK organisations:

• Green: approved tools for internal and low-sensitivity content, no approval needed, listed by name.
• Amber: approved tools for personal data, subject to conditions — no special category data, no bulk uploads, retention settings checked.
• Red: anything not on the list, or any use involving special category data, regulated data or client confidential material.

Attach five worked examples per tier. "Pasting a redacted supplier invoice into the approved assistant to draft a summary" is a better instruction than a paragraph of principle. Publish the list where staff already look — the intranet search results, not a PDF buried three clicks deep.

Phase four: a 48-hour gate, not a six-month committee

Unsanctioned use flourishes where approval is slow. A lightweight intake process removes the main incentive for bypassing it.

A single form, routed to one owner, with a 48-hour decision target and three outcomes — approve, approve with conditions, decline with a named alternative — will handle the vast majority of requests. Reserve full security review for tools that will touch personal data or integrate with core systems.

For anything that proceeds, the contract terms should be non-negotiable rather than aspirational. Confirm whether inputs are used for model training, the retention period for prompts and outputs, the sub-processor list and change notification, the location of processing, and the international transfer mechanism where relevant. Under UK GDPR, the controller–processor relationship needs Article 28 terms in place. Where data leaves the UK, a valid transfer mechanism — an International Data Transfer Agreement or the UK Addendum — must be documented, not assumed.

Phase five: treat the inventory as perishable

Tool adoption moves faster than annual review cycles. Quarterly re-runs of the egress analysis, a monthly reconciliation against the approved list, and a standing agenda item at the information governance forum will keep the picture roughly current. Add a simple metric — percentage of observed AI destinations that are on the approved list — and report it alongside other security indicators.

Finally, plan for the incident. Someone will paste the wrong thing into the wrong tool. The response procedure should already specify who is notified, what is logged, whether an ICO notification assessment is required under the 72-hour rule, and how the affected data subject is informed. A rehearsal of that procedure is worth more than another revision of the policy document.

The organisations handling this well in 2026 are not the ones that banned the most tools. They are the ones that made the approved path faster than the unapproved one — and could prove it when asked.