Your bright employee built an AI tool the business now depends on. Who is responsible for it next year?

The government-backed Made Smarter programme published a manufacturing AI toolkit at the start of May. Its framework is sensible. Scan, Pilot, Scale. Identify a real task. Run a contained pilot. Scale only what proves out.

What it doesn't address, because no toolkit really does yet, is what comes after Scale.

A pattern is starting to show up in the SMEs I speak with that wasn't there eighteen months ago. People who aren't tech-native, but who've seen the possibilities and rolled their sleeves up, are building small AI-assisted tools that quietly become part of how the business runs. A quotation generator inside the sales workflow. A Zapier flow that drafts the monthly reporting pack. A Copilot-backed assistant that triages support tickets before a human sees them.

Many start as an experiment. Given how capable the tools have become, plenty of them work. Some work well enough that the team stops thinking of them as experiments at all and quietly slots them into a new AI-assisted workflow.

For the AI-native software companies, the question of what to build has been answered for a while. For a typical UK SME, which relies on SaaS products rather than develops them, it's still a live conversation. For the businesses that have got past it, the harder question arrives later.

Who keeps it running?

I encountered a small personal version of this just last week.

I'd built two small software tools for my own use. Both ran daily. Both were working reliably until I migrated from an iMac to a MacBook Air. Intel to Apple Silicon. Neither survived the transition. I knew enough to rebuild them, and it cost me a few hours rather than a few days. But the point isn't the time. It's that two software tools I'd built and depended on broke without warning because something within the operating environment had changed.

The small AI tools that matter most inside a contemporary SME are now often ones the leadership didn't commission. A bright operations person built the quotation tool. A finance lead set up the reporting workflow. A salesperson wired Copilot or Claude into the CRM and now drafts follow-ups in seconds. Each saves time. Each works. None are documented, and almost none have a named owner once the build is finished.

Even people who don't write code know that software needs patching. APIs deprecate. Models get retired or repriced. A library update breaks a dependency.

There's a second risk that's particular to this new in-house AI-assisted development arena. The person who built the thing can leave. The workflow still runs, but the only mind that understood how it was assembled has gone. This is where the commercial picture has changed. The web app I built earlier this year took a weekend and cost me nothing beyond an AI subscription I already had. That is the new baseline. The cost of building has collapsed.

The cost of ownership hasn't. And the responsibility of ownership has transferred.

When you buy SaaS, maintenance is priced into the subscription. Security patches, model updates, integration fixes, version compatibility. None of it is your problem. When your team builds the tool instead, that cost moves inside the business. Some of it is financial. Most of it is operational time you weren't planning to spend. It's no longer on a supplier invoice. It's an unpredictable demand on your team's bandwidth, invisible until the day the tool fails, which is usually at a highly inconvenient moment.

The decision worth making isn't which tool to adopt or which model to use. It's smaller and more practical. For every AI-assisted tool the business has come to rely on, who is responsible for noticing when it breaks, and for deciding whether it gets rebuilt, replaced, or quietly retired?

The useful conversation in your next leadership meeting probably isn't what to build with AI next. It's a quieter one. Which of the things you've already built has the business come to depend on, and who in the room owns them?