Who Owns This, and Why It Is Contested

Shadow AI sits across security, legal, IT and the business. Each owns part of it, which in practice frequently means nobody owns it.

The recommendations in “Who Owns This, and Why It Is Contested” become easier to sustain when implementation work has visible owners, dates and review time. Teams evaluating workload reporting tools can use it to coordinate the operational side of AI adoption and identify where governance tasks are being missed, without treating activity data as evidence of misconduct or as a substitute for asking people why they chose a tool.

For an independent benchmark, compare the local approach with ICO guidance on AI and data protection; the useful test is whether ownership, access and recovery remain proportionate and explainable when the usual expert is absent.

The four claims

Security owns data leaving the organisation.

Legal owns contracts, regulated data and the liability.

IT owns provisioning, tooling and the approved list.

The business owns the work being done and the productivity at stake.

All four are right, and a programme run by any one of them alone fails in a predictable way.

How each fails alone

Security alone: blocks, measures compliance, loses visibility. The dynamic the bans note describes.

Legal alone: an assessment queue and a policy nobody can apply.

IT alone: a tool rollout with no classification rules and no enforcement.

The business alone: adoption with no risk assessment at all.

What the arrangement needs

A named owner with time allocated, not a committee.

A sponsor senior enough to settle disputes between the four.

And a standing group with one person from each, meeting briefly and regularly, which is where the trade-offs actually get made.

Where it should report

Not inside security, which frames the whole thing as a threat.

Not inside legal, which frames it as an approval queue.

Operations, transformation or the technology executive with a broad remit works better, because the question is as much about enabling as restricting.

The decisions that need settling early

Who approves a new tool, and up to what risk level.

Who can refuse, and who can overrule a refusal.

Who decides what is monitored.

Who speaks to employees about it.

Agreeing these four in advance prevents most of the friction later.

The part-time problem

This is commonly added to somebody's existing role and competes with operational work that has tickets attached.

Half a role is a workable minimum for an organisation of any size.

Nothing allocated produces a policy document and no programme.

The honest sequencing

If there is no owner and no sponsor, say so before starting.

Run the cheap discovery, produce the findings, and use them to argue for the structure.

A list of what is actually happening is a better argument than a proposal, and it costs two days.

What to check

Who owns this here, by name?

How much of their time is allocated?

Where does it report?

And are the four decisions above settled in writing?

The point

Four functions have a legitimate claim and none has the whole picture.

A programme run by any one alone fails in a predictable way.

Underlying all of this

Everything in this collection reduces to four habits: find out what people are doing and why before deciding anything, provide something good enough that the approved route is the easy one, write rules about information rather than about tools, and monitor the destination rather than the content. None requires a product, and a programme doing all four controls more than one built on prohibition.

The recurring pattern

The recurring pattern across every section here is the same: the response that feels like control reduces it. A ban removes visibility rather than use. Content inspection drives activity to personal devices. A discovery exercise with consequences produces quiet answers. In each case the organisation ends up knowing less about a risk it believes it has handled.