Shadow AI is a measurement of how long the official path takes

There’s a guilty kind of relief in getting an answer from the tool that wasn’t supposed to be open.

The customer email has been waiting. The official request is somewhere between an intake form and a governance workshop.

The browser tab gives you the sentence back in time.

You copy it. You send it.

For a moment the work stops pressing on your ribs.

You weren’t trying to make anything unsafe. You were trying to meet a deadline using the path that was actually open.

There are messages to answer, a manager wanting an update, a customer who has already waited, a train to catch, someone to collect.

The rulebook matters. So does the unanswered email.

Taking the available help isn’t a small act of sabotage. It’s what people do when work can’t wait for the process built to govern it.

And nobody here is worried about a machine with intentions.

The thing worth noticing is duller.

Your unauthorised flow is a stopwatch pointed at the sanctioned one.

2003 — You keep a private list because the request form is too slow.

2013 — The spreadsheet starts sending the reminders.

2024 — You ask AI to rewrite the customer email.

2026 — The official programme is still choosing a governance framework.

Each claim can be true

The usual story makes one side irresponsible and the other side responsible.

That’s too easy, and it’s why nothing changes.

Your undocumented flow usually gets found the same few ways. Its creator leaves. A connector hits a limit. A shared file gets renamed by somebody tidying up. A record nobody should have seen turns up in the wrong mailbox.

Then three things get said at once.

The business team says it cleared a backlog nobody else would touch. Security says it moved data without authorization. The process owner says nobody mentioned it was making a material decision.

Each claim can be true.

So shadow AI isn’t a rebellion to admire.

It’s evidence to read.

It tells you a piece of work had a purpose, users, systems, a credential of some kind, a data class, a run volume, and possibly the authority to decide something.

Your first account of it needs eight facts. Owner, purpose, users, systems, credential, data class, run volume, decision authority.

Add dependencies and the last successful run, because the thing that looks like a private convenience may be holding up payroll.

Deleting it on discovery can be as careless as leaving it alone.

The choice was never safety or speed. It’s retire, contain, migrate, or formally accept it for a short period with controls.

And a migration that rebuilds a screenshot in an approved platform has learned nothing. It copied the appearance of your flow without preserving its test cases or its business outcomes.

The need then surfaces somewhere else. Usually on another personal account, with less visibility than before.

The risk is not imaginary

None of that makes your workaround safe because it had a reason.

A bad workflow can expose the wrong fields of a customer record you’re allowed to see. Or it can reach an entirely wrong customer record.

OWASP calls those property-level and object-level authorization failures, and adds function-level failure alongside them.

Different defects, different affected populations, different evidence.

An approval screen placed upstream can’t make a connector with broad access safe.

The same bluntness applies to your data.

A cross-system flow needs a data owner who can define meaning, quality, permitted purpose, classification, retention and correction.

Its mapping needs five attributes for every field it moves. Source. Target. Transform. Owner. And what happens when the input arrives blank or invalid.

It should request the minimum data the step requires.

Because a lawful HR connection plus a lawful ticketing connection doesn’t become a lawful combined exposure just because the connector in between feels neutral.

And it has to preserve what happened. Your evidence is the request, the source version, the rule version, approvals, delegations, command ID, result, retries, exceptions, and any human override.

Two stores, usually. Short-lived operational diagnostics, and approval or transaction evidence kept for as long as the rules require.

The person quietly building an alternative isn’t being asked to think about any of this.

The official service is. And if it can’t expose a supported connector, review it, test it, and help you recover from a failure, then it has made the safe route slower without making the unsafe route disappear.

The pilot is not the service

Here’s the part a sincere committee still gets wrong.

An authorised AI service isn’t produced by finding a suitable model and attaching a policy document.

It starts with a bounded queue. Password resets and billing explanations. Not “improve customer service with AI.”

It says which sources may be used, what the system must never answer, what stays human-only, and what event ends the pilot.

And before the first draft appears, it records your weekly volume, median handling minutes, recontact rate, quality score, escalation rate and cost per completed case.

Miss that and you’ll never prove anything afterwards.

A stopped pilot can be a good decision. It may have discovered missing data, a rule that won’t hold, or a benefit that evaporates under measurement.

Stopping isn’t the failure. The failure is pretending a demonstration was an operating service, and making you wait for something that was never ready to arrive.

Test the configured service against the awkward cases before you meet them. A request for another customer’s data. A prompt buried inside a source document. A stale policy. A case that needs a human.

None of that makes a committee meeting useless. It makes one insufficient.

Governance isn’t the meeting that permits your release. It’s the continuing arrangement that keeps the release safe enough to use when sources change, a browser times out, someone edits a draft, or the manual fallback has to carry the queue.

Which is why an official path shouldn’t be judged by how fast it produces an approved pilot.

Judge it by whether you can use it on eligible cases. Whether drafts get shown. Whether they’re accepted unchanged, materially edited, overridden, or sent in time. Whether quality and customer outcome hold.

A high acceptance rate can mean trust. It can also mean exhaustion.

A low rate with useful tags can reveal one stale source, or a miserable interface. The work has to be watched as work.

The correction

You’re not the compliance problem. You’re evidence that the sanctioned path has a latency problem.

That doesn’t absolve anyone of controlling data, credentials, change, evidence or supplier boundaries.

It makes those controls answer the question that produced your workaround in the first place. How long does it take to deliver an approved alternative for work that can’t wait?

That’s the measure nobody puts on the slide. Time-to-deliver of the sanctioned alternative.

Not whether the committee wrote an AI policy. Not how many frameworks got compared. How long until a legitimate need gets a safe, usable answer.

Your unofficial answer may still be wrong. It may expose a record, make a decision nobody authorised, or fail the day its creator leaves.

The official answer may be genuinely slower, because it has to do things your browser tab conceals.

Both of those are true at once, and you shouldn’t have to pick one.

But once your employer reads the shadow flow as a map instead of a moral failure, it can finally see the distance between what it told you to use and what it made possible to use.

That distance is where your next workaround is already forming.