Most organisations debating whether to adopt AI have already adopted it. Not through
procurement — through staff who found the tools useful and started using them, in many
cases believing they were not supposed to.
That gap between what policy says and what people do is the real starting condition for
most AI transformation programmes, and it changes what the programme
is for. You are not introducing AI to the organisation. You are deciding whether the AI
already in the organisation is governed.
What the evidence shows
The most useful survey data available comes from Wakefield Research's Shadow AI Survey,
published by PagerDuty: n = 1,250 office professionals at companies with at least $500M in
annual revenue, excluding IT and technology roles, fielded 9–20 April 2026.
An honesty requirement before the numbers: the survey covers Australia, Japan, the UK and
the US. It does not cover India. It should not be presented as Indian data and the
percentages should not be extrapolated to this market. Cite it as what it is — evidence of
the pattern in comparable large enterprises.
With that stated:
| Figure | What it measures |
|---|---|
| 66% | Used AI at work despite believing it was not permitted under company policy |
| 72% | Same, at organisations with 1,500+ employees |
| 43% | Entered work-related correspondence into public AI tools |
| 34% | Entered customer data into public AI tools |
| 31% | Input financial information or disclosed confidential documents |
| 89% | Of those using AI for work, adopted it outside work first |
| 39% | Would use AI without disclosing it |
| 72% | Believe they understand AI use better than their company's AI management team |
Two of these deserve more attention than they usually get.
The adoption path is inverted. 89% of workplace AI users encountered the tools
personally before professionally. This is not how enterprise software normally arrives, and
it explains why policy is a weak instrument here — the behaviour was established before any
policy existed, in a context where no policy applied.
Smaller organisations are more exposed, not less. 40% of staff at organisations under
1,500 people entered customer data into public AI tools, against 27% at larger ones. The
common assumption runs the other way. Fewer controls, fewer sanctioned alternatives, and
more roles where an individual holds a lot of sensitive material at once.
The incident that makes the argument
In May 2023, Samsung Electronics restricted employee use of generative AI tools after three
separate incidents within roughly twenty days at one division. An engineer pasted
proprietary source code into a public tool while debugging. Another transcribed a recorded
internal meeting and pasted the transcript in to generate notes. A third used it to
optimise a chip test sequence. The events were reported by Bloomberg and Forbes.
The reason this is the right case to cite, and not one involving misconduct, is that all
three were ordinary work performed competently. Nobody was careless. Nobody was
malicious. An engineer debugging faster, a colleague writing up a meeting, an engineer
improving a test sequence — this is what you want your staff doing.
That is the entire argument. If the failure mode required negligence, training would fix
it. It does not, so training does not.
Why policy does not solve it
A prohibition creates three predictable effects, none of which is compliance.
It moves the activity to personal devices. The work still gets done. It now happens
somewhere with no logging at all, which is a worse position than the one you started from.
It removes your visibility. 39% would use AI without disclosing it. Once the activity
is undisclosed, you lose the ability to know which data classes are exposed — the thing you
most need to know.
It creates a competence gap you cannot close. 72% of respondents believe they
understand AI use better than their organisation's AI management team. Whether or not that
belief is accurate, staff who hold it will not surface their usage for guidance.
Prohibition without a sanctioned alternative is a policy that reports success by going
unmentioned.
What actually works
The pattern that resolves shadow AI is displacement, not enforcement: make the governed
path better than the ungovernable one for the work people are actually doing.
That requires the internal tool to be good enough to win on merit. Staff moved to public
tools because those tools were useful. An internal system that is slower, worse at the
task, or restricted to a narrow set of use cases will lose the comparison, and the shadow
usage continues alongside it.
Concretely, four properties decide whether displacement works.
It has to be grounded in the material people actually work with. A general-purpose
assistant that cannot see the contract, the SOP or the record is less useful than the
public tool the employee pastes the document into. Retrieval over the real document estate
is what makes the internal option the better one.
It has to reach people where they work. Chat, messaging and email surfaces the staff
already use. A separate portal requiring a separate login loses to a browser tab.
The data path has to be structurally closed, not policy-closed. The distinction
matters: in a fail-closed on-premise mode there is no egress path and a misconfiguration
cannot silently transmit data, because the failure mode is refusal. That is a different
kind of assurance from a rule stating what staff should not do.
Detection has to be built in. A privacy filter that recognises Indian identifiers —
Aadhaar, PAN, mobile numbers — alongside international PII, with pseudonymisation that
keeps records linkable without exposing the originals, converts a class of incident into a
logged event.
The reframe worth taking to the board
Shadow AI is usually presented to leadership as a discipline problem. It is more accurately
a demand signal — an unusually clear one, because staff adopted these tools voluntarily,
often against policy, at personal effort, because they made the work better.
That signal tells you two useful things. There is real productivity available, and the
organisation's current provision is not delivering it. Both are arguments for proceeding
with a transformation programme, not for restriction.
The uncomfortable corollary is that the clock is not set by your roadmap. The exposure is
accruing now, in whatever tools your staff chose. The relevant question is not whether to
adopt AI. It is how much longer the ungoverned version runs before the governed one is
ready to replace it.
Next: What DPDP 2027 means for your architecture
· From answers to actions
