Most portfolio companies don't need an AI transformation programme. They need one senior technical judgement call: which two or three back-office jobs would repay automation this year, and which of the ideas on the board slide would quietly fail. Buy that judgement with delivery attached: a plan first, then small builds the company owns, shipped in two-week sprints.
Why is AI now on every board agenda?
Because the investors got there first. AI has moved from a portfolio-company operations question to a deal question: 86% of corporate and private equity organisations have integrated generative AI into their M&A workflows, and 35% already use it for target screening and due diligence, according to Deloitte's 2025 study of a thousand senior corporate and PE leaders. If AI capability is being weighed when your company is bought, it will be weighed again when it is sold. The board slide is not a fashion. It's the exit multiple asking a question early.
Meanwhile the operating reality is thinner than the headlines suggest. A quarter of UK businesses report currently using some form of AI, rising to 44% among large businesses, per the ONS at the end of 2025. Adoption is real and climbing, but it is nowhere near universal, and in mid-market companies it is often one enthusiastic manager and a stack of unmanaged subscriptions rather than anything a board could point to at exit.
That gap, between what the deal environment expects and what the company actually runs, is the real agenda item. It won't be closed by a policy document or a pilot that never leaves the innovation deck. It gets closed by a small number of working systems in the parts of the business where time and error cost money, plus a defensible answer to "what did you automate, what did it return, and who owns it?" The rest of this guide is about getting to that answer without burning a year and a seven-figure budget on the way.
Why do most corporate AI projects fail?
They fail before the technology gets a chance to: wrong problem, no owner, no route from pilot to production. The numbers are blunt. By some estimates, more than 80% of AI projects fail, twice the failure rate of comparable non-AI IT projects, per RAND's 2024 study built on interviews with 65 experienced AI practitioners. An MIT-affiliated study of enterprise deployments put it more sharply for generative AI specifically: about 95% of enterprise pilots deliver little or no measurable impact on profit and loss. And S&P Global Market Intelligence found the share of companies abandoning most of their AI initiatives jumped from 17% to 42% in a single year, with the average organisation scrapping 46% of AI proof-of-concepts before they reached production.
Those studies measure different things with different bars, and each has its critics. Read together, though, they describe one consistent pattern, and it matches what we see inside companies. The failures share three causes, none of them technical.
The wrong problem gets picked. Projects start from "we should do something with AI" rather than from a costed view of where the company's weeks actually go. RAND's interviewees put misunderstood or miscommunicated problem choice at the top of their failure causes. A pilot aimed at an impressive demo rather than a P&L line was never going to survive contact with a budget review.
Nobody senior owns the judgement. Mid-market companies rarely have a CTO, so the evaluation of vendors, feasibility and risk lands on whoever is nearest: a COO with a full plate, an IT manager priced out of saying no, or the vendor's own sales engineer. Nobody in that arrangement is paid to say "this particular idea will not work here", which is the single most valuable sentence in an AI programme.
Pilots aren't built to become production. A proof-of-concept that ignores data access, error handling, audit and who-does-what-when-it's-wrong isn't an early version of a system. It's a demo, and demos get scrapped: that's the 46% in the S&P figure. The fix is unglamorous: build the smallest version of the real thing, in the real workflow, with the real data constraints, from the first sprint.
What does "CTO-grade judgement plus delivery" actually mean?
It means the two things a portfolio company usually lacks, supplied together: a senior technologist who has carried commercial outcomes deciding what's worth building, and a team that then builds it, in the same engagement, accountable for both. Judgement without delivery is a strategy deck. Delivery without judgement is how the failure statistics in the last section get made.
On judgement: the person doing the deciding should have done this before, at consequence. Our CTO, Jim Beattie, has 25 years in tech, three exits: Just Eat (IPO), Time Out (IPO), @Leisure (sold to OYO). That history matters for one specific reason: someone who has taken companies through scale and exit evaluates AI proposals the way your investment committee would, in terms of payback, risk and what survives diligence, not in terms of what makes an exciting pilot.
In practice the engagement runs on four commitments:
- A plan before a line of code. A paid mapping phase first: where the company's weeks actually go, which jobs would repay automation, which wouldn't, and the arithmetic behind both. Killing weak ideas at this stage costs days. Killing them after a build costs quarters.
- Two-week sprints, working software each time. No long dark period between kickoff and reveal. The exec team sees the real system every fortnight and can redirect or stop. Stopping early on evidence is a feature of the model, not a failure of it.
- Co-ownership, no lock-in. The company owns what's built, can see inside it, can host it in its own cloud, and keeps it if we part ways. At exit, that's an asset on the right side of the diligence table rather than a dependency on a supplier.
- Honesty as a deliverable. Part of the job is the written "no": the list of proposed AI ideas we recommend against, with reasons. Boards find this the most useful page in the pack more often than not.
Where does AI earn its keep in a portfolio company?
In the back office and the operational middle: the repetitive, rule-heavy work that scales with headcount today and doesn't need to. That's where the credible evidence of return sits, and where returns arrive inside a hold period rather than at the end of one.
The strongest field evidence comes from operational support work: in one large field study published through NBER, customer support staff given a generative AI assistant resolved 14% more issues per hour on average, with the newest staff improving by 34%. Two things in that result matter for an operating partner. The gain is real but bounded: 14% is a meaningful margin improvement, not a headcount overhaul. And the gain concentrates in less experienced staff, which is exactly the profile of a scaling portfolio company's operations team.
The same logic applies across the functions that quietly absorb margin. Finance: half of finance teams take six or more business days to close the books each month, per a 2025 survey of finance professionals reported by CFO.com, and most of that time is gathering and checking rather than judging. Reporting: one team we work with loses eight to ten days, every single month, building one report by hand. Checking and compliance: a payroll team's system, built by us, now checks every payslip line and flags exceptions, runs in the client's own cloud with a full audit trail, and the client owns it. None of these is a moonshot. Each is a named job, a measurable before and after, and a system the company keeps.
Two places we'd counsel scepticism. Customer-facing AI carries brand and compliance risk that back-office work doesn't, and the failure statistics above are heavily populated with chatbots that met the public too early. And anything sold as replacing judgement, in pricing, credit, hiring or advice, deserves a hard look: the systems that work keep a person on every decision that matters and automate the assembly and checking around it. There's also a cheaper first win worth taking: most companies are already paying for software nobody uses, with nearly half of paid applications underutilised or unused per Zylo's 2026 index. Sometimes the best AI decision in month one is cancelling licences, and an honest reviewer will tell you so.
What should you ask before you spend anything?
Five questions, and any vendor or internal champion who can't answer them plainly hasn't earned budget yet. Which job, in whose week, does this remove, and what does that time cost today? What happens when the system is wrong, and who catches it? Where does our data go, and what trains on it? Who owns what we're paying for if the relationship ends? And what would make us stop: what result, at which review, kills the project?
The last one is the least asked and the most valuable. A project with no defined stopping condition is how a 17% abandonment rate becomes 42%: money follows momentum instead of evidence. Insist on the stopping condition in writing before the first sprint, and the whole engagement changes character.
We keep a fuller list, with the answers you should expect to hear and the ones that should worry you, in AI due diligence questions. It's written for boards and operating partners, and it works equally well pointed at us.
What should the first 90 days look like?
Map, build one thing, measure it: that's the whole programme. In the first weeks, a paid mapping phase puts numbers on where the company's time actually goes and returns a ranked list: jobs worth automating, jobs that aren't, and the arithmetic behind both. The exec team picks one, the one with the clearest payback and a willing owner inside the business.
The middle weeks are the build, shipped in two-week sprints with the real workflow and real data constraints from sprint one. By the end of the period the company has a working system in production on one job, a measured before-and-after, and a decision framework for the next candidate. What it doesn't have is a steering committee, a tooling estate, or a transformation brand. Those can come later if the evidence justifies them; usually the evidence justifies building the next system instead.
We've laid the whole sequence out, week by week, with the decisions and the failure points marked, in the first 90 days: an AI plan.
How does an engagement actually run?
Deliberately unlike a transformation programme: smaller, shorter, senior people only, and structured so you can stop at every stage. The comparison is worth making explicit, because the programme shape is the default your board will be offered elsewhere.
| Question | Typical transformation programme | Our engagement shape |
|---|---|---|
| Starts with | A strategy phase and a target operating model. | A paid mapping phase: where the weeks go, what's worth building, in numbers. |
| First working software | After the roadmap, often quarters in. | Inside the first build sprint cycle: something real every fortnight. |
| Who you deal with | Partners sell it, junior teams staff it. | The founders who scope the work build the work. |
| Commitment shape | Long programme, hard to stop mid-way. | Stop at every stage: after mapping, after any sprint. |
| What you own at the end | Documents, licences, and a dependency on the integrator. | The systems themselves: co-owned, inspectable, hosted in your cloud. |
| The "no" you'll hear | Rarely: scope grows to fit the budget. | Built in: a written list of what we'd not build, and why. |
Commercially, the shape is the one we use everywhere: a paid mapping phase, then builds quoted per project and shipped in two-week sprints, then optional monthly support the company can cancel. Pricing depends on the jobs chosen, so we put numbers on it after mapping, not before; the honest general comparison of routes is in build or buy.
The first conversation is free and specific. An operating partner or CEO brings one portfolio company and a rough sense of where its weeks go; we bring the arithmetic and a straight answer about whether there's anything worth building. If the answer is "not yet, fix the data first" or "cancel the unused licences and revisit in a year", that's the answer that gets given.
Sources
Figures and claims in this guide draw on our own delivery work and the sources below. We only publish numbers we can stand behind.
- Deloitte, 2025 M&A Generative AI Study (survey of 1,000 senior corporate and PE leaders), deloitte.com, published 2025. Accessed 8 July 2026.
- Office for National Statistics, Business Insights and Conditions Survey, Wave 147, ons.gov.uk, published 8 January 2026. Accessed 8 July 2026.
- RAND Corporation, "The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed", rand.org, published 13 August 2024. Accessed 8 July 2026.
- MIT NANDA initiative, "The GenAI Divide: State of AI in Business 2025", via Fortune coverage, fortune.com, published 18 August 2025. Accessed 8 July 2026.
- S&P Global Market Intelligence, 451 Research, "Voice of the Enterprise: AI & Machine Learning, Use Cases 2025" (survey of 1,006 IT and business leaders), spglobal.com, published 2025. Accessed 8 July 2026.
- Brynjolfsson, Li & Raymond, "Generative AI at Work", NBER Working Paper 31161, nber.org/papers/w31161, published April 2023 (revised November 2023). Accessed 8 July 2026.
- CFO.com (CFO Dive network), "50% of finance teams take a week to close the books" (Ledge survey of finance professionals), cfo.com, published 23 April 2025. Accessed 8 July 2026.
- Zylo, SaaS Management Index (2026 edition), zylo.com/blog/unused-software-cut-costs/, updated 2 April 2026. Accessed 8 July 2026.
- AI Nativ.es delivery experience, 2026: the payroll checking build and the reporting build described are real client projects, told without names until we have written permission to use them.