“We’ll get to AI once we’re ready for it.” If you run a business, or sit on the board of one, you’ve either said this in the last year or you’ve nodded while somebody else did. But, it’s mid-October 2026 and I’m hearing it more, not less, which feels really telling. The lists of what an “AI-native” company looks like have been doing the rounds again this month, and every one of them assumes your company has: A) already got its data captured in a way that’s readable, B) got the operational processes (architecture) written down, and C) has an engineering team ready to make the changes.
Most of the businesses I talk to don’t have that in place. Status quo and commercial stability are powerfully distracting boardroom fodder, before ever tackling how AI could help the business. Some are starting from nothing. Most are content with trading well, with a bit of automation that levelled up over the years, with no ‘official’ position on AI at all, beyond what’s happening quietly under the desks.
So, in this article, I wanted to look at: how you instigate ‘AI in a business’ that’s struggling with ‘AI freedoms’ or compliance, and what usually ends up blocking the integration? This is a live case study, but the pattern isn’t theirs directly, and if it’s yours, you’ll recognise it by the second paragraph - trust me on that.
The ‘stable point’ you’re waiting for
“We need more visibility, but we need to get operationally stable first. Then we’ll take a proper look at AI.” It came up more than once in each of the meetings I had with this client, and I get it. It’s completionish theatre in action: we crave balance and conclusions. But a proper look at AI feels like something you do from a settled and rested position.
Most of us are never going to get to the stage where we’re comfortably happy with the status quo and ready to tackle the next evolution. The people who’d tackle the stabilising are the people doing the work, and the people who’d do the AI discovery are running the business. The desire and the opportunity are at odds with each other, and the can keeps getting kicked.
It’s easy to feel like you can’t get to ‘completing AI’ without getting through automation first. Digitise, then automate, then AI. That’s the sequence everyone assumes, and I’d say it’s a fair expectation, but not a law. It was inherited from how the last 20 years of technology dropped into the business, one layer at a time - with a stage gate and a well trodden heritage map to advocate with. AI integration should work that way too…but it doesn’t have to.
Leapfrog the churn
Half the world never laid the copper. They went straight to mobile, and the landline stage just became unnecessary. That’s the move here: you don’t need to be in a position of data readiness to explore what happens after it.
I keep leapfrogging the automation stage altogether and jumping head first into opportunity planning, with the automation coming as an offshoot of the AI-induced infrastructure process mapping. These days the agents ARE the automation layer. For example: instead of automating the invoice chasing this year and then, next year, thinking about a tool to chase debtors, and only then getting round to asking what the business could do that it can’t today, you go after the ‘big reach opportunity’ first, and the invoice chase gets automated because the infrastructure you built is already able to do it.
This only works if you assess risk, keep it structural, understand the foundational control, and work in parallel with solid ‘evaluations’ from day one. In practice that’s good asset management, context planning, and a single application layer of knowledge and control. Or, viewed as questions: where are your assets and who owns them? What do you actually know that’s written down somewhere an agent could read it, with someone accountable and liable at each stage, rather than living in someone’s head or a side chat? And is there one place the business’s knowledge and decisions live, rather than forty? I’ve built all of this into a solid thirty-step plan I use to take an enterprise, or even a single department, to AI-native.
Without that structure, the leapfrog is too bitty, and jumping in blind is how businesses end up with a pile of pilots that aren’t connected to the bottom line. With it, you’re building the foundation the “AI-native” plans assume is already there, except that instead of applying layers of ‘gate controls’, you’re building it for agents from the start rather than retrofitting it for them afterwards, which is cheaper and, in my experience, a lot faster.
If you’re the running business rather than the standing start, you’re in better shape here than you think. You’ve already got automation. You just never called it that, and you never decided what it was for.
The main risk in doing this
This is where it usually stalls with me initially, and it’s got nothing to do with the AI technology. When I ask a board why AI hasn’t happened yet, you’ll hear some version of the same three things: fear of autonomy (what if it does something we didn’t ask for), fear of cyber control (every agent is an attack surface) and, in fairness, an element of gatekeeping. It’s easier to limit permissions, because limiting permissions limits risk, and a good share of the staff wouldn’t yet be safe in a freer landscape. So every widening of that landscape adds to the risk and liability profile of the IT department should something go wrong, which pushes them to withhold a wider spectrum of permissions from everyone. I want to be fair to IT here, because that logic is sound from where they sit. Nobody thanks the IT director for doing their job well!
What I don’t think is the blocker yet, is governance. Which is odd. The blocker is usually people overthinking risk: not just in AI, but in ESG, CSR, HR and IT, where the risk framing gets applied across the whole business rather than describing any one part of it accurately. The real risk, the one that belongs to one function, gets inherited by every function, and the answer to everything becomes “not yet”.
This is because the term AI is ubiquitous! AI is Terminator as much as it’s a chatbot on your computer, as much as it’s a system for evaluating the quality of the assembly line product, or a toothbrush in your bathroom. These are all technically ‘AI enabled’ and none of them are anywhere near the same thing. Treat them as one risk and you get one answer.
So the useful question for IT, ESG or the AI enablement team is: what would you need to see to say YES, without carrying the liability alone? That’s where the opportunity comes in.
The opportunity
Autonomy has to be earned, per workflow, per action, one step at a time. An agent starts by watching the work and capturing it. Then it gets to suggest, and a person decides if it’s right. Then it acts, and a person signs off each action. Only after that does it act alone, inside a boundary a named person has set and checks, with regular evaluation and refinement. Nothing moves to ‘end to end’ without adequate evidence that it’s ready, and every step has a human role in it, and that constant evaluation and categorisation sits at the back end.
Which means the security lead gets asked to sign off a step, with the evidence in front of them, rather than to trust the technology in general. This is the same way we treat new staff, right? In my experience the person who came into the room braced for a fight to block the hiring or the automation becomes the most useful person with it, because they’re the one who knows what evidence they’d need, and what they can do to improve it, once they’re not stuck in the operational day job.
Ownership runs through all of it
The leapfrog works when each workflow that’s getting jumped has someone who owns the automation (and the result), with a measurable goal, a lineage of process, and a name against it when it fails. The ladder only climbs if someone really owns the evidence. And the gatekeeping loosens, because the liability now sits with whoever owns the workflow rather than with a global policy. What if everyone is a builder now, including the C-suite? Then the liability gets shared the same way the building does.
Where I’ve seen this fail is when ownership stays with the incumbent department or the commissioning executive who sponsored the programme. They own the budget, and they can’t own forty workflows and the innovation on top. The moment the people doing the work get to trial and play, with triggers they can pull and a boundary they understand, the thing moves leaps and bounds. This is extremely common in enterprise SaaS, by the way: capability ringfenced behind layers of complexity and permissions, waiting for someone senior to unlock it.
Who’s in the room?
So if you’re commissioning something like this, the first thing I’d want to know is who’s in the room, long before anyone says the words “use case”. The commissioning executive, Ops, IT, the AI team and security from the first session, and never as a review stage at the end. Finance, because the opportunity lane and the efficiency lane need different maths, and if you judge experiments on efficiency ROI in month two you’ll kill the only ones worth having! And the reluctant middle: the managers whose teams would be the ones trialling, who are usually the last to be asked and the first to slow it down.
Then two questions: who currently holds the permissions, and who carries it when something goes wrong? The answers tell you where the ladder has to start and who has to be able to say yes at each rung.
That’s the discovery. The audit that follows is scored work, and it’s the work I do, so I won’t hand you a worksheet that would be wrong for your business anyway. What I’d want you to leave with is what to do next week. Put the foundations in: assets, context, one place the knowledge lives. Give the work to the people who do it, with a name against every workflow and a rung they’re allowed to climb. And let the automation arrive as the exhaust of something more interesting than automation. If you’re waiting to be stable first, you’re waiting for a date that isn’t coming. The ones that move didn’t get stable first, they got started.
