The security owner carries the risk of yes. The operating owner carries the cost of no.

Almost every stalled AI decision I have been asked to look at turns out to be the same shape. It is not a budget problem and it is rarely a technology problem. It is two people inside one organization, both doing their jobs properly, whose jobs point in opposite directions. Until you can see that clearly, every piece of evidence you send lands on the wrong desk.

Two people, both right

On one side is the person accountable for security, privacy or risk. If they approve an AI deployment and something goes wrong, the consequence is theirs: the incident, the regulator's questions, the board's questions, the conversation about why customer data ended up somewhere it should not have been. Their instinct to slow down is not obstruction. It is the job, performed correctly.

On the other side is the person accountable for operations, revenue or delivery. Their consequence arrives more slowly and is harder to attribute, but it is just as real: the work that took three days instead of one, the proposal that went out late, the analyst hired to do something a model could have drafted, the competitor who moved first. Nobody writes an incident report about a quarter of lost velocity.

The security owner carries the risk if they say yes. The operating owner carries the cost of saying no. That standoff is the opportunity.Why this is a design problem, not a persuasion problem

The reason this does not resolve itself is that the two costs are not comparable in the same meeting. One is concentrated, attributable and career-relevant. The other is diffuse, deniable and shared. A rational security owner defaults to no. A rational operating owner keeps asking. And the organization quietly picks a third option that neither of them chose.

The demand is already there

Before arguing about whether to allow AI, it is worth establishing what is already happening. The surveys here come from different sponsors, different countries and different populations, and I would not average them into one headline number, because they are not measuring the same thing. Taken separately, they point the same way.

MIT's Project NANDA found what it called a shadow AI economy: "While only 40% of companies say they purchased an official LLM subscription, workers from over 90% of the companies we surveyed reported regular use of personal AI tools for work tasks." The report describes employees using "personal ChatGPT accounts, Claude subscriptions, and other consumer tools to automate significant portions of their jobs, often without IT knowledge or approval."¹ That report calls itself preliminary findings, built on 52 organizational interviews and 153 survey responses, and its own caveat on the pilot figures is that they are "directionally accurate based on individual interviews rather than official company reporting." Read it as a direction, not a measurement.

A UK survey of 2,003 employees found 71% had used unapproved consumer AI tools at work and 51% continue to do so every week, with 22% using them for finance-related tasks.² A 2025 survey across the United States, the United Kingdom, Canada and Asia-Pacific reported 80% of employees using unauthorized AI tools, and, more pointedly, 68% of security leaders admitting to building unauthorized AI into their own daily workflows.³ Both are vendor-commissioned, and both vendors sell something adjacent to the problem. Note that and keep reading, because the next one is harder to dismiss.

Cisco asked 2,600 security and privacy professionals in 12 countries what they had personally entered into generative-AI applications. 46% had entered employee names or information, 42% non-public information about their own company, and 31% customer names or information.⁴ These are the people who write the policy. If the profession that owns the control is doing it at those rates, an internal memo is not going to hold the line.

And the outcomes are now measurable. IBM's 2025 breach study reports that one in five studied organizations experienced breaches linked to shadow AI, adding as much as USD 670,000 to the average breach cost, and that among organizations reporting AI-related breaches, 97% said they lacked proper access controls.⁵ Separately, a survey of 302 cybersecurity leaders found 69% suspect or have evidence that employees are using prohibited public generative-AI tools.⁶

A ban does not produce zero AI

The security owner's default answer is defensible on its own terms and it has one specific flaw: it does not do what it appears to do.

Every organization wants AI, and many have banned it. Not because it does not work, but because using it means sending their data to somebody else's computer. So the work goes on anyway, in browser tabs, with no governance at all.The third option nobody chose

A ban removes the sanctioned path. It does not remove the deadline, the workload or the fact that a model drafts a decent first version of most documents in fifteen seconds. What it removes is visibility. The same work continues in a personal account, on a personal subscription, with no content policy, no per-person record of what was asked, no retention election, and no way to answer a regulator's question about where a given piece of information went.

That last point is not theoretical in Canada. A joint investigation by the federal Privacy Commissioner and the privacy regulators of Quebec, British Columbia and Alberta into a major consumer AI provider found the initial collection of personal information for training was "overbroad and therefore inappropriate" and that the company "failed to obtain valid consent." The detail worth carrying into a risk conversation is what the company told investigators: that untraining a model so it no longer generates specific personal information "is not currently feasible."⁷

Read that alongside the Cisco numbers. Information that employees paste into a consumer tool may not be retrievable in any meaningful sense. A ban that is 80% effective still leaves that exposure, and it removes the logging that would have told you it happened.

Why an attestation does not settle it

The standard vendor response to a nervous security owner is to send documents: a SOC 2 Type II report, an ISO certificate, a completed questionnaire, a penetration-test summary. This is a reasonable thing to send and it does not resolve the standoff, for a reason that is structural rather than a matter of quality.

SOC 2 is an attestation report. A licensed accounting firm examines a service organization's controls against the Trust Services Criteria and issues an opinion about that organization's controls.⁸ It describes the vendor. The security owner is not accountable for the vendor's controls. They are accountable for their own organization's handling of its own data, and no third party's report transfers that accountability, however thick the report is.

You can watch this play out in the largest deployment of governed AI in the market. A survey of 132 IT leaders found that concerns about data oversharing caused 40% to delay a major assistant rollout by three months or more, 57% managed the risk by limiting the rollout to low-risk or trusted users, and only 1% had completed deployment to all eligible office workers.⁹ Those organizations had the vendor's attestations. The attestations were not the blocker. The blocker was that the buying organization could not answer questions about its own permission model, and nobody else's audit could answer them for it.

What actually resolves it

The move that breaks the standoff is counter-intuitive if you have been treating the security owner as the obstacle: give them more control, not more assurance. Assurance asks them to accept somebody else's word. Control lets them answer the question themselves, which is the thing they are actually accountable for.

In practice that means three things.

An environment they own. The platform runs in a cloud account the organization opened and is billed for directly. Isolation is the account itself. When the security owner wants to know what is configured, they look at their own account rather than requesting a document. When they want to end it, they can.

Controls they can inspect, enforced where an application cannot reach them. The content policy is attached to every inference call and enforced as a deny in cloud identity policy, not as a setting in an application that a future integration can route around. Inference outside the configured endpoint regions is denied. Inference that bypasses the governed route is denied. Widening the account's data-retention election is denied. Tests fail the build if any of those denies is weakened. And the policy itself is a pinned, numbered version, so the question "which policy applied to this answer last quarter" has an answer.

The questions before the call. A security owner's worst experience is being asked to approve something on a schedule set by someone else, with information arriving in the order a salesperson chose. The posture questionnaire is published so they can read every question first, in their own time, including the ones where our answer is not flattering. The limits page exists for the same reason.

None of this makes the security owner's risk disappear. It changes what they are being asked to trust: not a vendor's continuing good behaviour, but a configuration in their own account that they can read.

What each of them should ask for

If you are one of the two people in this standoff, here is the ask that moves it, and the ask from the other side that you should expect to concede.

Every row in the middle column is a control the security owner can verify in their own account after deployment. That is the test to apply to any vendor's version of this table: can the buyer check it without asking the seller.

The standoff is the opportunity

It is worth naming why this matters commercially rather than just organizationally. The same MIT study that found the shadow AI economy also found that, despite tens of billions in enterprise spending, 95% of organizations were getting zero return, with the divide determined by approach rather than by model quality or regulation.¹⁰ The organizations getting nothing are not the ones with the wrong model. They are frequently the ones stuck exactly here, spending a year negotiating between two people who are both right.

The way out is not to win the argument. It is to change the thing being argued about, from "do you trust this vendor" to "do you own this environment and can you inspect it." Those are different questions, and only one of them has an answer that survives a change of vendor, a change of staff or a change of law.

If you are the security owner, the honest version of our pitch is: read the limits first, then ask for the configuration. If you are the operating owner, it is: stop asking for permission in the abstract and ask for a bounded first step with a named exit. The strategic assessment is built to be exactly that, and there is a longer treatment of the ownership question in why your models run inside your cloud.

Sources