AI Transformation: A Strategy Guide for Enterprises

• 46% of AI proofs of concept now reach production. The rest usually stall on ownership, not model quality.
• Only 37% of organisations report any profit impact from AI, though 80% say it improves personal productivity.
• AI adoption fails when the tool sits beside the old workflow instead of inside it, however accurate the model is.
• Agree the business metric and baseline before building an AI use case, or nobody can later prove it paid off.
• One MIT study found mid-market firms reach production in about 90 days, large enterprises in nine months or more.

Most mid-market and enterprise companies already run AI pilots. AI transformation is the harder work of getting those pilots into the business. IDC research with Lenovo found that for every 33 AI proofs of concept launched in 2025, only four reached production.

The 2026 edition of the same study reports that 46 percent of proofs of concept have now progressed into production. That's real progress. It still leaves more than half stuck in the demo stage.

Getting the strategy wrong is expensive in a quiet way. Budgets go to pilots that never ship. Teams stop trusting tools they were told would help. And leadership starts treating AI as a cost line instead of a lever for growth.

Most stalled programmes share one cause: the plan was built around models when it needed to be built around production, people and proof of value.

This AI transformation guide is for the CIO, CTO or COO who owns the AI budget, the transformation lead turning pilots into a programme, and anyone presenting an AI plan to a board this year.

AI transformation is the work of changing how a business runs by putting AI into core processes, decisions and products, then measuring what it returns. It's a programme, not a project, and it spans strategy, data, engineering, people and governance.

The word that matters is "runs". Some people call this AI business transformation, and the label fits: it's the business that changes, not just the tooling.

A company that gives its staff a chatbot has adopted AI. A company that rebuilt claims handling around a model, changed who approves what, and tracks the effect on cycle time has changed how it works.

Adoption is a step along the way. Transformation is where the work itself is different.

It also isn't the same as digital transformation, though the two overlap. Digital transformation moved processes onto software: orders went into an ERP, customer records went into a CRM. AI transformation changes the decisions inside those processes.

The ERP stops just holding the order and starts flagging which orders will ship late, with a suggestion for what to do about it. That's why the second depends on the first.

AI needs connected, reasonably clean digital systems to work with, and a company without them has foundation work to do before any model helps.

Four examples show the range:

• A manufacturer reads incoming sales orders and enters them into its ERP without keying.

• An insurer sorts claims by complexity so adjusters start with the hard ones.

• A parcel network predicts which deliveries will miss their window and alerts its partners.

• A clinic group forecasts no-shows and rebooks the empty slots.

Each one touches a core process, changes a decision, and can be measured against a number the business already tracks. None is a chatbot bolted onto a website.

Generative and agentic AI widen what's possible inside that definition. They don't change what the work is. You still need a use case, a data path, an owner and a metric.

The harder part is why so few examples like these make it past the demo.

Most AI transformations stall between the pilot and production, and the reasons are rarely technical.

The gap shows up in the numbers. McKinsey's State of AI 2026 survey found that 80 percent of respondents say AI has improved their own productivity, yet only 37 percent report any EBIT impact at the organisation level, a share essentially unchanged from the year before. People feel the gain. The P&L doesn't show it.

In our experience, the pilots that stall share one trait: nobody owns them once the demo is over. The team that built the pilot moves to the next one, the business unit that asked for it assumes IT is running it, and the model sits there.

Three other causes show up again and again.

The pilot ran on data that production can't reproduce. Someone pulled an extract by hand, cleaned it for a week, and the demo looked great. Nobody built the pipeline that delivers that data every day.

The success metric was never agreed. Without a number and a baseline, a pilot can't fail or succeed. It can only be debated, and debates favour whoever is most senior in the room.

The same few engineers carry everything. When one pilot needs support, the next one slips, and by the third quarter you have five half-finished pilots instead of two live ones.

None of these is a model problem. All of them are decisions about ownership, sequencing and funding, which is why they belong in the strategy.

Strategy is where they get fixed, so it helps to be precise about what one is.

An AI transformation strategy is a plan that ties every AI initiative to a business goal, an owner, the foundation it needs and a way to measure its value. If an initiative is missing any of the four, it's an experiment, not part of a strategy.

Plenty of companies run AI and digital transformation from one budget, and the AI work usually loses out. A digital programme is judged on systems delivered. An AI programme has to be judged on decisions changed, and the strategy needs to say so.

A workable AI strategy framework fits on one page and rests on three pillars:

• Priorities. Which use cases come first, and why those.

• Foundation. The data, integration and platform those use cases need.

• Ownership. Who answers for results, how work changes, and which rules apply.

Sources define the three pillars differently. This is the version Classic Informatics works with, and it maps to the five stages below.

Priorities means ranking by business value and readiness together. A use case that's valuable but needs data you can't reach for a year is a second-wave project. One that's modest but runs on data you already have is a good first one.

Ranking by how impressive the technology looks is the most common mistake, and it's how companies end up with an agent demo and no order-entry fix.

Foundation is the pillar boards like least, because it produces nothing visible. It decides how far everything else can go.

Ownership covers the sponsor, the programme lead and a business owner for each use case. It also covers the rules: what data a model may use, who reviews its outputs, and what happens when it's wrong.

At enterprise level, this is the part that turns an enterprise AI strategy from a slide into a programme: one sponsor, one set of rules, and a named owner in every business unit.

Stages turn those pillars into a sequence.

AI transformation moves through five stages: assess and prioritise, fix the foundation, build and integrate, adopt and embed, then measure and evolve.

Stage names vary between firms. This is the framework Classic Informatics uses.

This AI transformation framework isn't a straight line. The AI transformation journey loops: stages four and five overlap, and every new wave of use cases sends you back through stage two for the data it needs.

The first two stages together take roughly 6 to 12 weeks. After that, each use case ships on its own clock.

If you're working out how to implement AI in business, this sequence is the short answer: assess first, fix the foundation second, and build only what the foundation can support.

Assess and Prioritise

What happens: Leaders list candidate use cases, then score each one for business value, data readiness, integration effort and risk. The first wave is two or three use cases, not twenty.

What it produces: A ranked roadmap with an owner, a dependency list and a value metric for every use case.

What to watch for: Scoring by excitement. Use cases that need data you don't have rank high on value and last on readiness, and they belong behind the foundation work.

Decision signal: If every top-ranked use case needs data from a system you can't query today, start with stage two. If at least two can run on data you already reach, build them while the foundation work runs alongside.

Fix the Foundation

What happens: Teams make the data the first use cases need reachable, connect the core systems, and set up the platform, access controls and monitoring. The slowest part is almost always AI integration with legacy systems, because the systems holding the data weren't built to be called by a model.

Gartner predicts that through 2026, organisations will abandon 60 percent of AI projects that aren't supported by AI-ready data. It's a prediction, and it's scoped to projects without that data, but it matches the pattern. In our experience, foundation work is the step most often underscoped.

InterDent shows what a durable foundation looks like. Classic Informatics has built three generations of analytics infrastructure for the dental group over 20 years, and the current platform serves 250 clinics with daily operational dashboards. A new use case on a platform like that starts from data that's already collected and checked.

What it produces: Production-ready data and systems.

What to watch for: Treating the foundation as a prerequisite project that must finish before anything ships. Build it alongside the first use case, scoped to what that use case needs.

Decision signal: If an engineer can reach the data a use case needs in about a day, the foundation is ready for that use case. If it takes a week of requests and extracts, it isn't.

Build and Integrate

What happens: Engineers build the use case against real production data, connect it to the system where the decision gets made, and test it with the people who'll use it.

What it produces: A use case live in production.

What to watch for: Prototype shortcuts that don't survive launch: hand-fed data, credentials written into code, no monitoring, no fallback when the model is wrong.

Decision signal: If the pilot ran on an extract someone prepared by hand, treat it as a prototype and budget for a rebuild. If it ran on live pipelines, it's close to production.

Adopt and Embed

What happens: The workflow is redesigned around the AI output, teams are trained on the new process, and a named owner is accountable for results.

What it produces: Teams using AI in daily work.

What to watch for: A tool that sits beside the old workflow, so the old workflow wins. Usage that peaks in launch week and fades by month three.

Decision signal: If usage is still climbing in week eight, adoption is working. If it peaked in week one, rework the workflow, not the training.

Measure and Evolve

What happens: The team tracks the metric agreed at stage one and the running costs, compares both against the baseline, retires what doesn't pay, and chooses the next wave.

What it produces: Reported return and the next wave of use cases.

What to watch for: Measuring usage instead of value. Logins aren't ROI. Model costs that creep up with volume are the other quiet risk.

Decision signal: If a use case hasn't moved its metric within two quarters, fix it or stop it. If it has, pick the next use case from the same workflow family.

Stage three is where most programmes get stuck, so it earns a closer look.

A pilot reaches production when it has a business owner, clean data access, a path into existing systems and a success metric agreed before launch. Miss one and the pilot stays a demo, however good the model is.

A business owner. Someone whose numbers should move, not someone in IT. Without one, nobody decides what happens when the demo ends.

Clean data access. Pilots often run on an extract someone prepared by hand. Production needs live pipelines with quality checks, so the model sees the same data the business does.

A path into existing systems. The output has to land where the decision gets made: the claims screen, the ERP, the dispatcher's console. A dashboard nobody opens doesn't count.

A success metric agreed before launch. One number, a baseline, and a date to review it.

Scaling AI is mostly this plumbing. The model gets the attention, but the engineering around it decides whether it keeps working. Google Cloud's MLOps guidance describes automating continuous integration, continuous delivery and continuous training for machine learning systems, so a model is tested, released and retrained like any other production software.

Production-grade also means monitoring, a fallback for when the model is wrong, and a way to roll back a bad release. None of that shows up in a demo. All of it shows up in month three.

The AI transformation playbook is short: pick the use case, assign the owner, fix the data path, wire it in, measure it. When an AI pilot to production effort stalls, one of those four conditions is usually the one missing.

Once one pilot ships, the next job is deciding who owns the second, the third and the tenth.

The right AI operating model depends on how many teams use AI and how much central control your risk profile needs. Three models cover most companies.

A centralised model, the classic AI center of excellence, puts one team in charge of standards, tooling and delivery for every AI use case. It suits companies in their first year of AI, and regulated businesses where a single team can answer for risk.

The trade-off is that it becomes a queue: business units wait, and the team drifts away from the workflows it serves.

If fewer than four business units need AI in the next year and risk sign-off is strict, start here. If a backlog of more than a quarter's work builds up, move toward hub-and-spoke.

Hub-and-spoke keeps a central hub for the platform, standards and governance, and embeds teams in each business unit to build and run the use cases. It fits mid-size and large companies with several business units and some AI skill outside IT.

The cost is that two groups have to agree on standards, and the spokes drift when the hub is thinly staffed.

If three or more business units have their own AI backlog and could each host a data scientist, this is the one. If they couldn't, the spokes will stay empty.

A federated model lets business units run AI largely on their own, with light shared guardrails. It suits conglomerates whose units operate almost like separate companies. The price is duplicate tooling, duplicate spend and uneven risk control.

If your units already run separate technology stacks and budgets, federation reflects reality. If they share core systems, it will fragment the foundation you're trying to build.

Most mid-market companies don't need to choose yet. One small team with a named business owner for each use case is enough until the second or third business unit asks for AI.

Whichever model you pick, it only works if the people on the receiving end actually use what it produces.

People use AI when it's built into the workflow they already follow, not when it's added as one more tool beside it.

A claims adjuster won't open a second screen to check a model's suggestion. She'll use it if the suggestion appears in the screen she already works in, with the reason beside it.

A planner won't log into a new portal for a demand forecast, but he'll use the forecast if it lands in the planning sheet he opens every morning.

That's why adoption is a design problem before it's a training problem. Training tells people the tool exists. Design decides whether using it is easier than not using it. Good AI change management is mostly workflow design, not announcements.

Involve the people who do the job when you choose the use case. They know which step wastes the most time, and they'll defend a tool they helped shape.

Two things help more than any launch event. First, remove the old path once the new one works, so there's one way to do the job. Second, have managers, not the AI team, track use and ask about it in team meetings. People follow what their manager inspects.

BCG's 10-20-70 rule puts a ratio on this. It suggests leaders spend ten percent of their effort on algorithms, twenty percent on technology and data, and seventy percent on people and processes.

BCG offers it as a guide to where effort goes, not a measured law, and the exact split will vary by company. The direction matches what we see: most of the work sits in the part that isn't code.

Getting people to use AI is half the job. Proving it paid off is the other half.

Measure AI against the business metric it was meant to move, set before the build, and track running costs from the first day in production.

Start with a baseline. If a use case is meant to cut claim handling time, measure today's handling time before anything ships. Without that number, any later result is an opinion.

Pick one primary metric per use case: cycle time, cost per transaction, error rate, revenue per account. A second metric is fine. A dashboard of ten means nobody agreed what success meant.

Keep usage and value apart. Logins, prompts and active users show whether people are trying the tool. They don't show whether the business improved. Report both, and count only value as return.

A global industrial manufacturer we worked with automated sales order processing and integrated it with its ERP. Order processing time fell by 60 percent, manual ERP data entry was eliminated, and the launch produced no errors afterwards.

It was process automation rather than a machine-learning model, but the principle carries over: the result is quotable because it's tied to one operational number.

Running costs are the second ledger. A traditional application usually costs about the same to run whether ten people use it or ten thousand. AI doesn't behave that way. Model usage fees, data storage, monitoring, retraining and support all rise with volume.

Meter cost per transaction from the first week and put it in the business case as a line, not a footnote. That discipline is the starting point for AI cost optimization for enterprises, because you can't cut a cost you haven't metered.

Review at a fixed point, usually one or two quarters after launch. Some benefits resist measurement, such as a bad decision avoided that nobody sees. Estimate those separately and label them as estimates. Don't blend them into the headline return.

Your size changes how you apply all of this, which is the next question.

Mid-market companies usually win on speed, while enterprises win on scale, and the strategy should play to whichever advantage you have.

Speed figures come from MIT's NANDA study. The other rows reflect Classic Informatics delivery experience and will vary by company.

MIT's NANDA study found that mid-market firms moved from pilot to full implementation in about 90 days, against nine months or longer for large enterprises. The sample was modest and definitions of "enterprise" vary between studies, so read the gap as directional.

The counter-position deserves weight. McKinsey's 2026 survey found that 40 percent of organisations with $1 billion or more in revenue are scaling AI agents in at least one function, against about 22 percent of smaller organisations. Both findings can hold at once.

In our reading, mid-market companies get a first use case live faster because fewer approvals stand in the way, while large enterprises get more use cases live across more functions because they have more people to run them.

AI transformation for mid-market companies works best as a time-boxed plan, not a multi-year roadmap. For an enterprise, the priority is a shared data and integration layer, so each business unit isn't rebuilding the same foundation.

Industry matters as much as size when you choose the first use case.

The best first use case depends on where your industry loses the most time or money to manual work. Four industries show the pattern.

Manufacturing

In AI transformation in manufacturing, the first payoff usually comes from predictive maintenance on machines that already produce sensor data, visual quality inspection, and sales order entry into the ERP.

What usually blocks it is sensor data trapped in plant systems that don't connect to the ERP, and plants that each run their own process.

If your plants already log machine data somewhere queryable, start with maintenance or inspection. If orders still arrive as PDFs and emails, start with order entry.

Logistics

The early wins for AI in logistics and supply chain are predicting which shipments will miss their window, route and load planning, and demand forecasting. The usual blocker is event data split across carriers and partner locations in different formats.

Classic Informatics built the unified parcel platform for Hubbed, an Australian logistics network with 1,700+ partner locations and five carrier integrations, now processing 10,000+ transactions a day. That wasn't an AI project, but it's the groundwork one needs: every parcel event lands in one place.

If shipment events from all carriers land in one system, start with exception prediction. If they sit in five carrier portals, unify them first.

Insurance

For AI transformation in insurance, claims intake and document extraction, underwriting support and fraud flags pay off first. Policy administration systems older than the use case, and regulators who expect an explanation and a human sign-off, tend to slow things down.

If claims arrive as documents and adjusters retype them, start with intake. If your policy system can't expose data through an API, start with integration.

Healthcare

Documentation and coding support, appointment scheduling and no-show forecasting, and operational reporting come first. Patient data rules, clinical safety review and systems that were never connected are the usual blockers.

Classic Informatics built clinical systems and an Azure analytics platform across nine departments for Chris O'Brien Lifehouse, a specialist cancer centre in Australia. A connected base like that is what makes later AI use cases possible.

If clinicians already trust your reporting data, start with operational use cases like scheduling before anything touching care decisions. If reporting numbers are still disputed, fix data trust first.

Whatever the industry, four failure patterns show up again and again.

Four failure patterns account for most stalled AI programmes, and each has a fix that starts with the organisation rather than the technology. They sit underneath many of the common AI adoption challenges leaders report.

Pilot Sprawl

A dozen pilots run in a dozen teams, with no shared data, no shared owner and no end date. It happens because pilots are cheap to start and nobody has the authority to stop one, which is an organisational gap, not a technical one.

Cap the number of active pilots, require an owner and a success metric before one starts, and review them all on a fixed cadence.

Foundation Debt

Every new use case spends its first two months finding and cleaning data. The foundation was skipped to show quick wins, and each pilot built its own extract. Fund shared data access and integration as its own line in the programme, scoped by the use cases lined up behind it.

Orphaned AI

A model sits in production that nobody monitors, built by a team that has moved on. The project team was disbanded at launch and no business owner was named. Name the owner before the build starts, and budget for run-and-improve work as part of the original case.

The Adoption Gap

The tool works, usage is high in week one, and by month three the team is back on the old process. AI was added beside the workflow instead of into it. Redesign the workflow around the AI output, retire the old path, and have managers track use.

Spotting these early is half the battle. The other half is choosing who builds the fix.

Build when AI is your competitive edge, buy when the problem is common, and partner when you need production experience your team doesn't have yet. Most programmes end up mixing all three by use case, which makes build vs buy AI a decision you repeat for every use case, not a one-off choice.

Building means your own team designs, trains and runs the AI system. It fits use cases where the model or the data is your edge and you can hire and keep the engineers to run it.

It's the slowest to start, and your team carries running costs and maintenance indefinitely. If competitors can't buy what you're building and you already employ the engineers to run it, build. If either is missing, look at buying or partnering.

Buying means licensing a finished product or platform for a common problem such as document processing or customer support. It fits problems every company in your industry shares, where the process matters more than the technology.

It's fast to start, but you adapt to the product's design, and integrating it with your core systems is still your job.

If several companies in your sector solve this problem with the same off-the-shelf tool, buy. If integration with your core systems is the hard part, buying alone won't fix it.

Partnering means an engineering firm builds and integrates the system with your team, then hands it over or keeps running it. It fits teams that have the use case and the data but haven't taken AI into production in their own systems before.

Results depend on the partner's quality, and you still need an internal owner. If your first production use case is due within a year and you haven't shipped one before, partner. If you've shipped several, build the next ones in house.

MIT's NANDA study found that external partnerships reached deployment about 67 percent of the time, against 33 percent for internal builds. The same caveat applies: the sample was modest, so treat it as directional. It fits what we see, though. Production experience is the scarce input, not ideas.

A partner worth hiring has put AI into production in systems like yours, shows you running costs as well as build costs, and names who owns the result after launch.

Choosing an AI transformation partner is mostly a matter of checking production references, not watching demos. AI transformation cost and budgets vary with scope, so ask for fixed-scope phases and for running costs to be quoted separately.

Shortlists of top AI transformation companies are a starting point, not a verdict, because production references matter more than a ranking. If you want delivery as well as a plan, Classic Informatics runs enterprise AI transformation services from assessment to production.

The companies getting value from AI aren't the ones with the most pilots. They're the ones that finished a few.

That's the shift this whole guide points to. Stop counting experiments and start counting use cases that run in production, with an owner, a metric and a cost line. The programmes that do this tend to look boring from the outside, and they're the ones the board keeps funding.

If you remember only a few rules, make them these:

• Rank use cases by value and readiness, never by novelty.

• Fund the foundation before you fund the fourth pilot.

• Assign a business owner before any build starts.

• Build AI into the existing workflow, then remove the old path.

• Set the value metric before the build and meter running costs from day one.

• Play to your size: move fast if you're mid-market, share the foundation if you're enterprise.

• Build when AI is your edge, buy when the problem is common, partner when you need production experience.

Classic Informatics has spent 23+ years putting software into production for mid-market and enterprise companies, and AI follows the same rule as the rest of that work: it counts once it runs. If you want to talk through where your AI programme should start, we're here to help.