The demo is the easy part. Owning what comes next is where firms stall.
|
|
Plus: The escalation rule that was wrong from the start, and ran for six months before anyone noticed
|
|
|
|
|
From the aibl team
|
|
Colin Carmichael works at two ends of the UK AI conversation. At 4most he helps major banks and insurers move from proof of concept into production. At the Business AI Alliance, which he co-founded, he hears the same questions from smaller firms trying to work out where to start.
The standard explanation for why mid-market firms move slower is a skills story: not enough technical talent, not enough people who understand what the models can do. Colin doesn’t buy it, and neither do we.
Most firms can already build a demo. The harder question is who owns what comes next. In a proof of concept, a weak output gets noted and moved past. In production, someone has to stand behind it when it’s wrong, decide what remediation looks like, and carry the risk when a customer is on the other end. Things stall there because the operating model around it never really starts.
Larger firms have at least some chance of carving out the time and attention that takes. For many mid-sized firms, the people closest to the opportunity are already carrying full workloads, often mid-way through other change programmes, and experimentation survives where it can rather than where it should.
It’s the tidier diagnosis, and the one we hear most often. The harder one is that most firms still haven’t worked out who owns the outcome. Colin’s full conversation is below.
|
|
Most firms can build a demo, but few can own what comes next
|
|
Colin Carmichael has spent the past few years watching UK financial services firms try to work out what to do with generative AI. He is a Client Partner at 4most, a specialist risk, data, and analytics consultancy, that works with banks and insurers in the UK and globally. He is also co-founder of the Business AI Alliance, a not-for-profit giving SMEs a voice on national AI policy.
From engaging with both large and small firms, his read is the same: the easy part is over.
Most organisations Colin works with have already built a proof of concept. The problem is what comes next. “Proof of concepts are great. It gets everyone understanding technology, but moving to an operational state is different.”
A hallucinated response in a demo is something you note and move on from. In production it needs to be “more or less right all the time.” That means prompt engineering, model validation, and decisions that most organisations haven’t had to make before. Who signs off the output? Who’s accountable when something goes wrong with a customer? What’s the remediation?
|
|
|
|
Watch the full video interview:
|
|
|
|
News worth reading
|
|
AI is in the building, but it’s not doing much yet
Research conducted by the Centre for Economics and Business Research (Cebr) for HSBC shows AI usage among UK mid-sized firms has jumped from 35% to 55% in two years. But adoption and operationalisation aren’t the same thing. Only 24% are embedding AI into core operations in ways that deliver measurable results. The rest are using it more superficially, say, drafting emails and summarising documents.
The research models a 4% labour productivity uplift for firms that make the shift, around £4.5m in additional revenue per firm over four years. Skills gaps are the primary barrier, cited by 12.5% of firms yet to move. Lack of identified use cases follows at 7–8%. Half of mid-sized firms still don’t plan to adopt in the next three months.
The majority sitting outside productive adoption aren’t short on ambition. They lack use-case clarity, data infrastructure, and internal capability – those aren’t ambition problems, they’re sequencing ones.
|
|
|
AI in practice
|
|
|
AI in Practice: What broke when the checking stopped
This week’s article is based on an interview with the founder of a mid-market logistics firm that had rolled out an AI agent to handle intake for new freight forwarding clients.
The agent’s job was straightforward: collect intake information from new clients, check it against internal templates, flag gaps, and generate a first draft of the setup documents. In the pilot it seemed reliable, with people still close enough to catch what it missed.
When they expanded the rollout, the checkpoint that had kept the pilot honest disappeared, and nobody noticed.
From the start, the escalation rule was wrong. When the agent hit a gap it couldn’t resolve, it was supposed to flag for human review. Instead it marked items as reviewed and moved them forward. Nobody caught it because nobody was looking closely enough.
The issue surfaced six months after the rollout expanded, when an account manager noticed a setup document marked as reviewed at the exact moment it had been generated. The defect had been running for most of that period. The team had stopped checking every output before it moved to the next stage, and the escalation rule had been wrong since the pilot.
|
|
|
|
|
Product spotlight of the week
|
|
|
This week we’ve been tracking NinjaOne, a platform gaining traction with mid-market IT teams managing a growing device estate on a tighter toolkit budget. The pitch is consolidation: endpoint monitoring, patching, remote access, backup and ticketing in one place, so teams aren’t bouncing between four or five tools for work that should be routine.
Many mid-market IT teams still run on a scan-schedule-patch cycle: vulnerabilities get detected, handed off, and sit in a queue while systems remain exposed. NinjaOne’s approach skips the queue. It uses AI to assess vulnerabilities continuously against the device inventory it already holds, linking detection directly to automated patching workflows: no separate scanner, no export, no handoff.
Per-device pricing scales down as device count grows. For a lean IT team replacing multiple tools, the maths tends to work. Worth a look if your IT team is patching across multiple tools and still not sure what’s exposed.
|
|
|
|
Copyright (C) 2026 aibl. All rights reserved.
|
|
