The most common question I get from UK mid-market boards in 2026 is some version of how do we actually do this? They have heard the AI strategy pitch, they have funded a pilot or two, they have read the McKinsey report, and they still do not feel they have a working answer. They are right not to. The market has spent two years selling the why of AI and barely ten minutes explaining the how.
This article is the how. It is the same conversation I have at Cybix when a new engagement begins, distilled into something a board can read on a Sunday evening. It is not a strategy. It is a field guide, written from the inside of dozens of Cybix engagements across six regulated and unregulated sectors.
Step 1: Pick a workflow, not a use case
The first instinct, when starting an AI programme, is to pick a use case. Customer service. Document processing. Lead qualification. This is the wrong granularity. Use cases are too abstract to ship.
The right unit of work is a specific workflow with a specific operational metric. Not “improve customer service” but automate the resolution of inbound returns enquiries for orders under £500. Not “use AI in finance” but reconcile supplier invoices against purchase orders without manual touch. The Cybix engagement framework starts every project at this level of specificity, because the difference between a workflow and a use case is the difference between something that ships and something that stalls.
Three criteria for a good first workflow: it produces a measurable operational metric (volume, time, cost, error rate); it is contained enough that one team owns it end-to-end; and it currently consumes meaningful human effort that would notice the change.
Step 2: Build the data layer before you build the model
Almost every AI engagement Cybix runs spends more time on data than on modelling, and the data work happens before the model work. This is unintuitive, because the model feels like the point. It is not. The model is the smallest part of the project.
The data layer needs three things in place before any model goes near it: structured access to the data the workflow depends on (often spread across an ERP, a CRM and a few SaaS tools); a clean schema the model can rely on; and a permissions and logging layer that tells you, after the fact, exactly what data was passed to the model and what came back.
If any of these is missing, the project is going to stall at integration time. Most failed AI projects Cybix has been called in to recover discovered this in month four, not month one, and never recovered. At Cybix we now scope the data layer as a project in its own right, with its own budget and its own deliverables, because pretending otherwise has cost too many programmes too much.
Step 3: Engineer for production from day one
The single largest difference between AI projects that ship and AI projects that don’t is that the ones that ship were engineered for production from the very first commit. The ones that stall were engineered as proofs-of-concept that somebody hoped to “productionise later”.
Production-grade engineering means: version-controlled prompts, audit logging on every model call, a deterministic test suite, observability into latency and cost, a rollback plan for when the model misbehaves, and explicit data contracts between the AI system and the systems it integrates with. None of this is exotic. All of it is routinely skipped in pilot mode.
The Cybix model treats production-grade engineering as the default scope from day one. It is not a phase the project gets to later. It is what we are building from the first sprint, because the Cybix experience — and the wider industry experience — is that retrofitting it costs three to five times as much as building it in.
Step 4: Deploy progressively, not in a big bang
A common adoption mistake is to build for six months and then go live in a single Tuesday-morning event. This is high-risk for any kind of software, and especially so for AI, where behaviour at production scale can differ materially from behaviour in test.
The Cybix deployment model favours a progressive rollout: shadow mode (the AI runs alongside the existing process and outputs are compared but not actioned), then assisted mode (a human reviews each AI decision before it ships), then auto mode with manual override, then auto mode with monitoring. Each phase produces data that improves the next. Each phase is a safe-to-fail step.
Done well, this is how you get from zero to genuinely autonomous operation in 8 to 16 weeks per workflow, depending on complexity. Done badly, it is how you get to a frozen pilot in month nine.
Step 5: Operate the system as software, not a project
The phase nobody warns you about is the operating phase. Once an AI system is live and automating part of an operation, it needs the same kind of attention as any other production software: monitoring, incident response, prompt updates as the underlying model changes, regression testing when integrations move.
The cost of operating an AI system is real but predictable. Cybix engagements that are still running automation work we deployed two years ago consume a fraction of the cost of the original build, but they still consume something. Boards that budget for “the AI project” and not “the AI system” will find themselves surprised, then frustrated, then disappointed.
Treating AI as a product, not a project, is what keeps the up-to-84% automation figure Cybix posts intact over time. The number is not a launch metric. It is a steady-state metric.
Step 6: Compound from the second workflow onwards
The reason mid-market AI adoption is so under-invested in is that most boards are looking at the cost of the first workflow and assuming the second, third and fourth will cost the same. They will not. They will cost considerably less, because the data work is reusable, the integration patterns are reusable, and the operating model is reusable.
This is the compounding logic Cybix has watched play out across our most mature client engagements. The first workflow is hard. The fifth workflow is fast. By the time a business has automated a half-dozen related workflows, the marginal cost of the next one has typically dropped by half or more. Cybix’s internal benchmark on this — across engagements in financial services, healthcare and retail — is that engagement four onwards is consistently shipping at less than 50% of the cost of engagement one.
What to ask a delivery partner
If you are choosing an AI partner for the journey above, three questions cut through the noise.
First: how many of the workflows you have built are still in production a year later? Anyone can ship something for a launch. Operating it is harder.
Second: what does your engineering process look like — version control, testing, monitoring, rollback? If they cannot answer this in software-engineering vocabulary, they are an advisory firm dressed up as a delivery firm.
Third: how do you measure success? If the answer is “deliverables shipped” or “milestones hit”, look elsewhere. The Cybix answer — and the right answer, in my view — is operations automated, in production, surviving at least 90 days.
Adopting AI well is not a strategy problem. It is a software-delivery problem with unusual characteristics, and the businesses that treat it that way are the ones that ship. The Cybix view, distilled into one line, is that the how of AI adoption is built, not designed — and the field guide above is the route Cybix has walked enough times to know it works.
—
Dan Spence is the CEO of Cybix, a London-based AI consultancy that helps UK and international businesses adopt AI as production software, not strategy theatre. The Cybix engineering team — drawn from former Apple and Google language-model engineers alongside compliance, automation, recruitment and software specialists — has automated up to 84% of operational workloads for clients across banking, healthcare, telecoms, retail, oil and gas, and fashion. Cybix engagements are scoped, built, deployed and operated as software systems, with measurable operational outcomes as the only success metric. More at cybix.ai.
