Innovation Moves at the Speed of Governance

Where good AI ideas actually stall

Most AI ideas at work stall in the same place, and it’s rarely the technology. Someone finds a use that saves real time, asks whether they’re allowed to keep doing it, and the question sits in a shared inbox while they go back to the old way or quietly carry on without asking again.

That wait is the real speed limit. People talk about AI governance and innovation speed as if one has to lose for the other to win, with the risk team on the brakes and everyone else on the accelerator. In practice, how fast you can responsibly move is set by how long it takes to get a decision, and that’s a design problem you can fix.

An operations lead builds a prompt that turns supplier delivery notes into a weekly exceptions list. It works on the first real batch. She emails IT to ask whether she can run it on live supplier data, IT forwards it to security, and security asks legal whether supplier names count as confidential. Each step is reasonable. Nobody owns the whole question, nobody has promised an answer by a date, and weeks later the exceptions list is still being built by hand.

The instinct is to read that delay as caution, and caution as safety. The evidence doesn’t line up as neatly as that. In early 2024, Cisco’s privacy benchmark survey of privacy and security professionals found that 27% said their organisation had banned generative AI applications altogether for the time being, and 48% admitted entering non-public company information into those tools.^[1]

Those two figures come from the same survey, and they don’t prove that one caused the other. They do describe a familiar shape: the official route closes or slows down, and the work moves somewhere nobody can see it.

So this guide is about speed, and specifically about a shorter wait for a clear answer rather than fewer rules.

What a slow yes actually costs you

A slow approval process feels safe from the inside, because nothing bad happens on paper. The requests sit in a queue, the register stays tidy, and no incident gets logged. What the queue doesn’t show is everything that went around it.

Late on a Thursday, a marketing coordinator has a campaign brief due and a personal AI account open in another tab. The company tool is still “under review,” so the brief goes into the personal one, along with a paragraph of customer feedback that probably shouldn’t have gone anywhere. Nothing breaks. The brief is good. And the organisation has learned nothing about what its people need, because the one useful signal, a request, never arrived.

That coordinator has plenty of company. Microsoft’s 2024 Work Trend Index found that 78% of AI users were bringing their own AI tools to work.^[2] The figure is from 2024 and it counts people who already used AI, so I’d hold it loosely. The direction is the useful part, and it matches what tends to happen when the sanctioned option is slower than the unsanctioned one.

Here’s where slow governance tends to send the work instead:

• Personal accounts, where the company can’t see what data goes in.
• Approved tools stretched to cover uses nobody approved.
• Shared documents of “unofficial” prompts passed quietly between teams.
• Nowhere at all, because the person with the idea gave up and the time saving never happened.

The last one is the cost leaders tend to miss. Shadow AI at least gets the work done, with risks you can’t see. An idea that dies in the queue costs the time it would have saved, every week, for as long as the queue exists, and it teaches the person who asked not to bother next time.

If you want the hidden-tool side in more depth, our guide to shadow AI covers why people do it and what to do about it. The rest of this piece is about the front door: making the official route fast enough that people use it.

Fast governance decides most things before anyone asks

My read is that teams which move quickly with AI usually haven’t got fewer rules than everyone else. They’ve made more of their decisions in advance, so most requests never need a meeting, and the ones that do get answered on a timetable. That comes down to three levers, and none of them needs a new committee.

There’s a large public example of the first lever. In April 2025, the US Office of Management and Budget sent federal agencies memo M-25-21, titled “Accelerating Federal Use of AI through Innovation, Governance, and Public Trust.” It tells agencies to “cut down on bureaucratic bottlenecks” and says risk management practices “should be proportionate to the anticipated risk from its intended use.”^[3] The detailed minimum practices apply to what the memo defines as high-impact AI: AI whose output is a principal basis for decisions with significant effects on things like people’s rights, access to services, or health and safety.

The memo is strict where it counts. A high-impact use that can’t meet the minimum practices has to be safely discontinued. What it avoids is routing every chatbot experiment through the process built for those cases. I’d read it less as a government story and more as a design choice any organisation can copy, with one caveat: whether it has actually sped agencies up is a separate question, and the memo can’t answer it.

The second lever is, in our view, the one most often skipped. A request with no owner and no date is being stored rather than reviewed, and the person who sent it can’t plan around it.

Here’s what a published clock can look like for a mid-size organisation. The point is that each kind of request has a person and a date attached, and that the requester knows what happens if the date passes.

The clock sits on top of whichever approval model you already have. If you need that model first, our guide to AI governance when you don’t have a legal department sets out who approves what at small-team scale.

Make one yes count for the next team too

The third lever is where governance starts paying you back. Most approval processes treat each request as new, so the fifth team asking to summarise meeting notes waits as long as the first. If the first answer had been written down as a reusable pattern, the fifth team could have read it and started.

Morgan Stanley’s AI rollout is a public example of a reusable yes, with the caveat that the account comes from OpenAI’s own customer story. According to that story, the firm built an evaluation framework to test every AI use case before deployment, folded daily regression testing of sample questions into its quality assurance, and found that the framework “unlocked a flywheel for future solutions and services.”^[4] For a company that isn’t a bank, the shape is what matters. The expensive work of deciding what good enough looks like was done once, as a standing test, so each new use arrived at a gate that already existed rather than a blank page.

A finance analyst wants to use the company’s AI assistant to draft variance commentary from the monthly pack. She checks the pattern list, finds one that covers drafting internal commentary from internal numbers, reads its conditions and starts that afternoon. The one thing she does need to ask about, putting the draft straight into the board pack, goes to the clock with a date on it.

Here’s what that pattern looks like written down. One card per pattern is enough, and a short list of them answers most requests before anyone sends one.

You probably have the raw material for these cards already, scattered across past approvals and refusals. AI is useful for the first draft, as long as a person with authority signs off every card before it’s published.

If you don’t have a policy to feed it yet, start with our guide on how to write an AI acceptable use policy, then come back for the cards.

Where AI can speed up the approval itself, and where it can't

There’s an irony in a slow AI approval process that doesn’t use AI anywhere in it. A fair amount of governance work is preparation: reading the request, checking it against what’s already allowed, writing up what’s being asked. Preparation is something these tools do reasonably well. The decision stays with people, and this is how I’d split it.

It also helps to be clear about the job governance speed does in a rollout, because it gets blamed for things it doesn’t control. Training builds capability, so people can use the tool well in principle. Workflow design gives that capability a real, recurring task to land in, and governance speed decides how quickly that task can be signed off. Reinforcement, from managers who check and teams who repeat the work, turns it into behavior. Adoption is what you see when all of that sticks.

A fast yes doesn’t make anything stick on its own, but a slow one can stall everything that comes after training.

This is also where structured training pays off from the other end of the queue. People who’ve practised on their own real workflows recognise which pattern their work fits, and they write clearer requests when it doesn’t. A team can build the pattern list internally, and training gets people using it well much sooner than a policy email will.

The same setup feels different depending on where you sit:

• A team lead mostly needs the pattern list, so they can say yes to their own people without escalating.
• A risk or data protection owner needs the high-consequence requests kept few enough to review properly.
• An IT lead needs the approved tools list kept current, because a stale list sends people back to personal accounts.
• An executive sponsor needs one number above the rest: how many requests are past their promised date.

How to tell whether your governance is getting faster

Most governance reporting counts what was reviewed. For speed, you want to know what happened to the people who asked, and whether the work they asked about is still running. I’d use the same lens we use for adoption: use, then persistence, then impact.

Start with a warning sign that’s easy to misread. When request volume drops after a new policy goes out, it’s tempting to take that as compliance.

Fewer requests can mean people found what they needed in the pattern list, which is good. It can also mean they stopped asking. The scorecard below is built to tell those two apart.

The persistence rows are the ones that get skipped, because they mean going back and asking. They’re also the rows that tell you whether a fast yes turned into a lasting way of working or just a quicker form. If approved pilots keep stopping at the same point, our piece on why AI pilots never scale covers what usually sits behind that.

What I'd do this month

I wouldn’t start by rewriting the policy. I’d start by finding out how long a yes takes right now, because that number tells you how fast your organisation can actually move with AI.

1. Pull the last few months of AI requests from wherever they live: inboxes, tickets, chat threads. Note when each was asked and when it was answered, if it was.
2. Group the ones you approved into patterns, and write the first three as pattern cards with a named owner.
3. Publish a clock for the kinds of request that remain: who answers, and by when.
4. Tell people in one message what’s already allowed and where to ask about everything else.
5. After a month, check the scorecard, starting with whether requests went up or down.

None of that needs a new committee. It needs one person who owns the queue and is willing to put a date on every answer. For the sorting of individual uses into what’s fine, what needs a check and what’s off limits, our guide to managing the responsible use of AI goes through it step by step.

Find out how long a yes takes in your organisation this week. That’s your current speed limit, and it’s one you’re allowed to change.

Sana Mian, Co-Founder of Future Factors AI

Sana is an AI educator and learning designer specialising in making complex ideas stick for non-technical professionals. She has trained 2,000+ learners across corporate teams, bootcamps, and keynote stages. Future Factors offers AI Bootcamps, Corporate Workshops, and Speaking & Consulting for businesses ready to adopt AI without the overwhelm.

More about Sana →