AI Transformation: A Practical Framework for 2026

2026-08-15 · Tommaso Maria Ricci

Enterprise spending on generative AI passed 30 billion dollars, and 95 percent of the organizations doing the spending got nothing measurable back. That number comes from the MIT Media Lab Project NANDA study The GenAI Divide: State of AI in Business 2025, based on 150 executive interviews, 350 employee surveys and 300 public deployments. It is the single most useful data point available to anyone planning an AI transformation right now, because it tells you the failure is not technical.

I run companies. I am a founder who does advisory work, not a career consultant, and I have sat on both sides of this: the side that writes the check for the AI program, and the side that has to make the program produce something a CFO will accept. The pattern is consistent. Companies that treat AI transformation as a technology rollout stall inside twelve months. Companies that treat it as an operating model change produce results in one or two quarters and then compound.

This guide is about the second kind. It covers what AI transformation actually means, why the majority stall, how to sequence the first three moves, what it costs, who owns it, and how to measure it in terms that survive a board meeting. It includes a self assessment you can run this week and a 30/60/90 day roadmap you can execute without hiring anyone.

What AI Transformation Actually Means

AI adoption and AI transformation are different things, and confusing them is the most expensive mistake in this space.

Adoption means people have access to tools. You bought seats. Employees paste things into a chat window and get useful output. Adoption is cheap, fast, and mostly invisible in the P&L, because the time it saves gets absorbed into slack rather than converted into throughput, margin or revenue.

Transformation means the shape of the work changed. A process that took five people and four days now takes two people and six hours, and the other three people are doing something the company could not do before. A service you sold at 40 percent gross margin now runs at 60 because delivery is machine assisted. A sales team that could handle 200 accounts now handles 600 with the same headcount.

The test is blunt. If you removed the AI tomorrow, would anything in your operating model break? If the answer is no, you have adoption. If the answer is yes, you have transformation.

Three consequences follow from that definition, and each one shapes everything later in this guide:

Transformation requires process redesign. You cannot bolt a model onto a workflow that was designed around human handoffs and expect the economics to change.
Transformation requires a decision about the freed capacity. Time saved is not value created. Somebody has to decide, in advance, where that time goes.
Transformation shows up in one of three places or it did not happen: revenue, cost, or cycle time. Everything else is a proxy.

Most of what gets sold as AI transformation is adoption with a bigger invoice. If your program plan is a list of tools and a training calendar, you are buying adoption. If it is a list of processes with named owners, target economics and a redesign date, you are buying transformation.

The Evidence: Why Most AI Transformations Stall

The data on this is unusually clear for a field this young, and it converges from three independent directions.

The value gap is widening, not closing. Boston Consulting Group surveyed executives across major economies for its 2025 study on AI value creation and found that only 5 percent of companies qualify as "future built," meaning they systematically generate value from AI across functions. Another 35 percent are scaling and beginning to see returns. The remaining 60 percent report minimal gains. The performance spread is not marginal: future built companies show roughly 1.7 times the revenue growth, 1.6 times the EBIT margin and 3.6 times the three year total shareholder return of the laggards, according to the BCG announcement of the findings.

Adoption is nearly universal, impact is not. McKinsey's 2025 global AI survey found that 88 percent of organizations now use AI in at least one business function, up from 78 percent the year before, but that the share reporting AI fully scaled across the enterprise sits at 7 percent. Around 39 percent attribute any EBIT impact at all to AI, and most of those put the effect below 5 percent of EBIT. Near universal usage, single digit transformation.

The failure is organizational. The MIT NANDA researchers were explicit that the divide between the 5 percent that extract value and the 95 percent that do not is "not driven by model quality or regulation" but by approach. Same models, same vendors, same regulatory environment, radically different outcomes. That is the definition of an execution problem.

Put those three together and the diagnosis is uncomfortable but actionable. The technology works. The vendors are largely interchangeable at this level of maturity. What separates the two groups is whether the company was willing to change how work gets done, who does it, and how it is measured.

In practice I see five recurring stall patterns:

The pilot museum. Twelve proofs of concept, all technically successful, none in production. Nobody owned the transition from demo to daily operation.
The tool sprawl. Fourteen subscriptions, no process redesign, no measurement. Spend is visible, value is not.
The shadow deployment. Employees use consumer AI tools on company data without governance. Real productivity gains, real exposure, zero institutional learning.
The IT-only program. AI owned entirely by technology, with no operating owner in the business. Solutions get built for problems nobody in the P&L cared about.
The capacity leak. Genuine time savings that never got converted, because no one decided in advance what the freed hours were for.

If you recognize your own company in more than one of these, you are not behind. You are average. The interesting question is what the 5 percent do differently.

The Four Layers of an AI Transformation

Every durable AI transformation I have seen or run operates on four layers at once. Skip a layer and the program reverts to adoption within two quarters.

Layer 1: The Work

This is the process level. Pick a workflow, map it end to end, and identify which steps are judgment, which are retrieval, which are generation and which are pure coordination. Retrieval, generation and coordination are where machines are strong today. Judgment stays human, at least for decisions with legal, financial or reputational weight.

The work layer output is not a tool selection. It is a redesigned process diagram with fewer steps, fewer handoffs and explicit quality gates.

Layer 2: The Workforce

Every redesigned process changes somebody's job. Pretending otherwise is how programs die quietly, sabotaged by the people who understood before management did that the pilot was a headcount study.

The honest position is the one that works commercially and ethically: state up front what happens to freed capacity. In my experience the highest return answer is almost never reduction. It is coverage. The same team serves more customers, responds faster, opens a channel it could not staff before. Reduction gives you a one time cost cut. Coverage gives you a growth curve.

Layer 3: The Operating Model

Who decides what gets built, who owns the outcome, how spending is approved, how risk gets reviewed, how a working solution moves from one team to the rest of the company. This is the layer most companies skip and the one that predicts scaling.

Layer 4: The P&L

Every initiative gets a target expressed in revenue, cost or cycle time, with a baseline measured before anything is built. No baseline, no claim. This layer is what turns an AI program into a business case that survives a change of CFO. I go deeper on measurement design in the guide to AI ROI for business.

A useful sanity check: for any initiative in your plan, you should be able to name the process owner, the affected roles, the approval path and the target metric in one sentence. If you cannot, the initiative is not ready to fund.

Where the Money Actually Goes: The 10/20/70 Rule

BCG popularized a budget heuristic that matches what I see in practice: roughly 10 percent of the effort in an AI transformation goes to algorithms, 20 percent to technology and data plumbing, and 70 percent to people and process change.

Most companies invert it. They spend 70 percent on technology, 20 percent on data, and treat change management as a training webinar. Then they wonder why usage flatlines eight weeks after launch.

What the 70 percent actually buys:

Process redesign. Somebody senior enough to change how work is done, with the authority to remove steps.
Role redefinition. Updated job descriptions, updated performance metrics, updated incentives. If a salesperson is still measured on activity volume, an AI tool that reduces activity volume is a threat, not a help.
Trust building. Documented accuracy rates, escalation paths, and a clear statement of what the machine decides versus what it recommends.
Internal enablement. Not generic prompt training. Function specific, workflow specific, built on the company's own documents and cases.
Governance that does not block. Fast approval for low risk use cases, real review for high risk ones.

Budget planning follows from this. If your AI transformation budget is 200,000 euros and 160,000 of it is software licenses, the plan is wrong regardless of how good the software is. For a fuller breakdown of realistic budget ranges and where costs hide, the practical framework for AI implementation in business covers the cost side in detail.

Choosing the First Three Initiatives

The single highest leverage decision in an AI transformation is what you do first. Choose badly and you spend nine months proving to your own organization that this does not work.

Score every candidate process on four dimensions, one to five each:

| Dimension | Question | Score 5 looks like |

|---|---|---|

| Value density | How much money or time sits in this process annually? | Six figures or more of loaded cost |

| Data readiness | Is the input digital, structured and accessible today? | Already in a system with API access |

| Error tolerance | What happens if the output is wrong 5 percent of the time? | A human reviews before anything leaves |

| Ownership clarity | Is there one person accountable for this process? | Named owner with budget authority |

Anything scoring below 12 out of 20 goes to the backlog. Anything above 16 is a candidate for the first wave. Then apply three filters:

One customer facing, one internal. The customer facing one creates commercial evidence. The internal one creates organizational belief.
Nothing that requires a data migration first. If the initiative depends on cleaning three years of records, it is a data project wearing an AI costume. Sequence it later.
Nothing that depends on a single vendor's roadmap. Build on capabilities that exist today, not on a feature promised for next quarter.

The processes that most consistently clear this bar across industries: quote and proposal generation, customer support triage and first response, sales research and account prioritization, document review and extraction, scheduling and dispatch optimization, and internal knowledge retrieval.

The Operating Model: Who Owns AI Transformation

The ownership question decides whether you scale. Four models are common, and only two work.

The IT owned model. Technology builds, the business receives. Fast to start, reliably stalls. IT does not own the P&L line the initiative is supposed to move, so the business treats delivery as optional.

The federated free for all. Every function does its own thing. Produces useful experiments and zero institutional learning. Six teams solve the same retrieval problem six different ways.

The center of excellence with business owners. A small central team owns platform, standards, security review and reusable components. Business units own initiatives and their outcomes. Central team's success metric is how many business initiatives ship, not how many models it builds. This works.

The executive sponsor with a transformation office. For larger organizations, the same structure plus a single executive whose bonus depends on the portfolio. This works better, and it is the configuration I see most often among companies that got past the pilot stage.

Two structural details matter more than the org chart:

Approval speed for low risk use cases. If a manager needs a committee to test a tool on internal documents, you have built a system that guarantees shadow deployment. Set a risk tier where approval takes under a week.
A reuse obligation. Anything built in one unit must be documented and offered to the others within 30 days. Without this, your marginal cost per initiative never falls, and scaling economics never arrive.

If you are weighing whether to build this capability internally or bring in outside help for the first cycle, the comparison of AI consulting versus hiring in house lays out the cost structures side by side.

Data and Technology Foundations That Actually Matter

There is a persistent myth that you need a modern data platform before you can do anything with AI. It has cost companies years.

What you actually need for the first wave:

Access, not architecture. Can the system read the documents, tickets, emails or records the process uses? An API and permissions beat a warehouse migration.
A retrieval layer over your own content. The single highest return technical investment for most mid sized companies. Your policies, contracts, product documentation and past cases, indexed and searchable by a model. This turns generic capability into company specific capability.
Logging. Every generation, every input, every human correction. Without logs you cannot measure quality, you cannot improve, and you cannot defend a decision to a regulator.
An evaluation set. Fifty to two hundred real cases with known good answers. This is how you compare vendors honestly and how you detect quality drift after a model update.

What you can defer: a data lake, a unified customer data platform, a full model ops stack, fine tuned proprietary models. These become relevant at scale, not at the start. Companies that sequence them first spend eighteen months building foundations for a house they have not designed.

One firm rule from experience: never let the first wave depend on data your company does not already produce. If the initiative requires new data collection, it is a second wave initiative.

Workforce: Roles, Skills and the Redeployment Question

Every AI transformation is a labor conversation whether you name it or not. Naming it early costs less.

Three roles change first in most companies:

Coordinators and schedulers. Highly automatable, and usually the people with the deepest process knowledge. Move them into quality assurance and exception handling.
Analysts and researchers. Output volume increases several fold. Their value shifts from producing analysis to framing questions and validating conclusions.
First line customer contact. Volume handled per person rises sharply. The job becomes escalation judgment rather than transaction processing.

New roles you will need, usually part time before they are full time: a process owner for each redesigned workflow, an evaluation owner who maintains the test set and quality metrics, and a governance reviewer with real authority to stop a deployment.

The skills question is narrower than the discourse suggests. Most employees do not need to understand model architecture. They need three things: knowing what the system is reliably good at, knowing how to check output against a source, and knowing when to escalate. That is a half day of training reinforced by two weeks of supervised use, not a certification program.

On redeployment, be direct with your teams. Ambiguity produces quiet resistance that is very hard to diagnose and very effective at killing programs. If the plan is coverage expansion, say so and show the growth math. If the plan is attrition based reduction, say that instead. Both are defensible. Silence is not. The structured approach to this is covered in the AI change management framework.

Governance, Risk and the EU AI Act Reality Check

Governance kills more AI transformations through excess than through absence. The goal is a system that says yes quickly to low risk work and applies real scrutiny where it matters.

A workable three tier structure:

Tier 1, low risk. Internal productivity, no personal data, human reviews everything before it leaves the company. Manager approval, logged in a register, no committee.

Tier 2, medium risk. Customer facing output, or processing of personal data, still with human review. Requires a documented process owner, a data protection assessment, an evaluation set and a rollback plan.

Tier 3, high risk. Automated decisions affecting individuals, including credit, employment, insurance and access to services, or anything in a regulated safety domain. Full review, legal sign off, documented testing for bias, monitoring in production.

For European companies, the EU AI Act sets obligations on a phased timetable. The prohibitions on unacceptable risk practices and the AI literacy obligation applied from 2 February 2025. General purpose AI model obligations applied from 2 August 2025. The bulk of the high risk system obligations follow in 2026 and 2027. The practical implication for a transformation plan is simple: know which tier each initiative falls into before you build it, because retrofitting documentation is far more expensive than producing it as you go.

Two governance mistakes I see repeatedly. The first is treating every use case as high risk, which pushes employees toward unmanaged consumer tools. The second is confidential data flowing into unreviewed systems because nobody offered a sanctioned alternative. Both are solved by making the approved path faster than the unapproved one.

Measuring an AI Transformation

If you cannot defend the numbers in a hostile CFO review, you do not have a transformation, you have a story.

Measure at three levels.

Level 1: Process metrics. Cycle time, throughput per person, error and rework rate, cost per transaction. These need a baseline captured before anything changes. Two weeks of manual measurement now saves you a year of arguing later.

Level 2: Business metrics. Revenue per employee, gross margin on affected services, customer response time, win rate on quoted work, retention. These move one to two quarters after process metrics.

Level 3: Portfolio metrics. Percentage of initiatives that reached production, time from approval to production, reuse rate of built components, share of employees using approved tools weekly.

Three measurement rules that keep the numbers honest:

Count only realized value. Hours saved are not money until the hours were converted into output or removed from cost. Track the conversion explicitly.
Report failures. A portfolio where everything succeeds is a portfolio that is not being measured. Expect a third of initiatives to underperform, and kill them fast.
Attribute conservatively. If revenue rose and you also hired two salespeople, do not attribute the increase to AI. Credibility compounds, and one inflated claim contaminates the entire program.

Ranges I consider realistic for a well run first year in a company between 20 and 500 employees: 15 to 40 percent cycle time reduction in the redesigned processes, 5 to 15 percent cost reduction in the affected functions, and, where the transformation reaches customer facing work, revenue effects in the high single digits to low twenties. Anything above that is possible but should be treated as an outlier until you have proven it twice.

If you want an outside read on where your organization actually sits before committing budget, this is exactly the sort of diagnostic conversation worth having with someone who has run these programs rather than only advised on them.

AI Transformation Self Assessment

Score each statement 0 (false), 1 (partly true), 2 (true). Maximum 40.

Strategy and ownership

We can name the three business outcomes our AI program is supposed to move.
One executive is accountable for the AI portfolio's results.
Every initiative has a named business owner outside of IT.
We have killed at least one AI initiative in the last six months.

Work and process

We have mapped and redesigned at least one end to end process, not just added a tool to it.
We measured a baseline before deploying anything.
We know where the freed capacity goes.
At least one redesigned process is running in production daily.

Data and technology

Our systems can be read programmatically by the tools we use.
We have a retrieval layer over our own documents.
We log inputs, outputs and human corrections.
We maintain an evaluation set of real cases with known good answers.

People

Affected employees were told what happens to their roles.
Function specific training was delivered, not just generic tool demos.
Performance metrics were updated to match the new process.
We have internal people who can evaluate output quality without vendor help.

Governance and measurement

We have risk tiers with different approval speeds.
We know which initiatives fall under high risk regulatory obligations.
We report AI results in revenue, cost or cycle time terms.
Our reporting includes what failed.

Reading the score. Below 15: you are at adoption stage, and the correct move is to pick one process and do it properly rather than broaden the tool estate. 15 to 27: you have real initiatives but the operating model is the constraint, so fix ownership and reuse before adding scope. Above 27: your constraint is portfolio management, and the priority becomes killing weak initiatives faster and scaling the strong ones across units.

The 30/60/90 Day Roadmap

This assumes a company of 20 to 500 people with no dedicated AI team. It is executable with existing staff plus a few days of outside help.

Days 1 to 30: Evidence and selection

Run the self assessment above with five people from different functions, separately, then compare scores. The disagreements are the useful part.
Inventory current usage, including unsanctioned tools. Ask without penalty. You will find more than you expect.
Map three candidate processes end to end and score them on the four dimension matrix.
Capture baselines for the top two: cycle time, volume, error rate, loaded cost.
Publish a one page position on what happens to freed capacity.
Set the three risk tiers and the approval path for each.

Days 31 to 60: Build one thing properly

Redesign one process on paper first, with the owner in the room. Remove steps before adding technology.
Build the smallest version that runs in production, not a demo.
Assemble the evaluation set of 50 to 200 real cases.
Train the affected team on the redesigned process, not on the tool.
Run in parallel with the old process for two weeks and compare against baseline.
Start the second initiative's design while the first is in parallel run.

Days 61 to 90: Prove, document, extend

Cut over the first process and measure for three consecutive weeks.
Write the internal case study with real numbers, including what went wrong.
Document the reusable components: retrieval setup, prompts, evaluation harness, review workflow.
Present to leadership in revenue, cost and cycle time terms.
Select the next three initiatives using the same scoring matrix.
Decide the funding model for the next two quarters: central budget, business unit budget, or a split.

By day 90 you should have one process genuinely transformed, a documented method, and a portfolio ready for the next wave. That is a realistic target. A company wide transformation in 90 days is not, and anyone selling you one is selling adoption.

What It Costs

Ranges from programs I have seen and run, in euros, for the first twelve months. These assume you are not building proprietary models.

|---|---|---|---|---|

The internal time line is the one companies systematically underestimate. If nobody in your organization has three days a week to give this, the program will not work regardless of what you spend externally.

Cost traps worth naming: per seat licensing that scales faster than value, consumption based pricing without usage caps, integration work quoted separately from the platform, and the cost of maintaining evaluation and governance after the project team disbands.

Case Studies From My Own Work

These are companies I worked with directly. Numbers are as measured, and I have kept the identifying detail out where the client preferred it that way.

Hotel group, revenue from 9 to 10 million euros. The transformation was not in guest facing technology. It was in revenue management and channel operations: pricing decisions that used to be made weekly on intuition became daily, data driven and partly automated, and the marketing content pipeline moved from an external agency cycle of weeks to an internal cycle of days. The freed capacity went into direct booking channel work, which carries no intermediary commission. That is the second order effect that produced most of the margin.

Medical center, capacity up roughly 20 percent. No new clinical rooms, no new practitioners. The gains came from scheduling optimization, automated reminder and rescheduling flows that cut no shows, and administrative document handling. The interesting part was the workforce decision: the administrative team was not reduced, it was moved onto patient follow up, which improved retention on top of the capacity gain.

Sports and retail organization, sales up around 30 percent. Marketing operations rebuilt around AI assisted content production and audience segmentation. The mechanism was volume and speed: campaign cycles that took two weeks compressed to two days, which allowed testing at a frequency the old process could not support. The lesson generalizes. In marketing, the return usually comes from iteration rate rather than from any single better asset.

Agritourism business, guests roughly doubled. Small operation, minimal budget. Multilingual content production, review response automation, and booking funnel work. This is the case I cite when someone tells me transformation requires enterprise scale. It does not. It requires a process that is worth changing and an owner who will change it.

The common thread across all four: none of them started with a platform decision. Each started with one process, a baseline, and a decision about where the freed capacity would go.

Common Mistakes

Buying capability before defining the process. The tool is not the constraint. The process is.

Measuring adoption instead of outcomes. Weekly active users tells you people opened an app. It does not tell you anything moved.

Treating pilots as a stage rather than a decision. A pilot should have a pre agreed threshold for production or termination. Without it, pilots become permanent.

Running everything through a single committee. Governance that treats a document summarizer like a credit decision engine produces shadow IT within one quarter.

Ignoring the middle layer. Executives sponsor and frontline staff use, but middle managers own the process and the metrics. If their targets did not change, the process will not change either.

Building on a single vendor's unreleased roadmap. Model capability is moving fast enough that architecture decisions should assume replacement, not permanence. Keep the retrieval layer, prompts and evaluation harness portable.

Announcing transformation before proving one case. Credibility spends down fast. Prove it in one process, then announce.

Sector Notes

Manufacturing. Highest returns in quality inspection, demand forecasting and maintenance scheduling. Constraint is usually data acquisition from machines rather than model capability.

Professional services. Document review, research and drafting are transformable immediately. The real question is commercial: if you bill hourly and delivery time falls 40 percent, you have a pricing problem before you have a technology problem. Address the business model in parallel.

Retail and ecommerce. Content production, merchandising decisions and support automation. Watch for brand consistency degradation when content volume rises.

Healthcare. Administrative and scheduling first, clinical support much later and under strict governance. Highest regulatory exposure of any sector on this list.

Financial services. Strong returns in document processing, compliance monitoring and client research. Most initiatives here land in Tier 3 governance, so build documentation from day one.

Construction and field services. Quoting, scheduling and dispatch. Often the fastest payback of any sector because the processes are paper heavy and the margins are thin.

For a broader view of how adoption patterns differ across large organizations, the enterprise AI adoption framework covers the structural side, and the case for CEO ownership of AI strategy addresses the sponsorship question directly.

What Changes in 2026

Three shifts that should influence how you plan rather than what you do first.

Agents move from demo to production, unevenly. BCG's data puts agentic systems at roughly 17 percent of total AI value in 2025, projected to reach 29 percent by 2028. The companies deploying them successfully are, without exception, the ones that already redesigned the underlying processes. Agents amplify process quality. They do not substitute for it.

Evaluation becomes a competitive capability. As model quality converges across vendors, the advantage moves to whoever can measure fitness for their specific work. The evaluation set stops being hygiene and becomes an asset.

Regulatory documentation becomes a procurement requirement. Large buyers are beginning to ask suppliers how AI is used in service delivery. Being able to answer clearly is turning into a commercial advantage rather than a compliance cost.

None of this changes the sequence. Process first, capacity decision second, technology third, measurement throughout. If you are at the point where you need a candid outside assessment of which processes to transform first and what the realistic economics look like, that conversation is worth having before the budget is committed rather than after.

For context on where the underlying technology actually stands, independent of vendor claims, the Stanford HAI AI Index remains the most rigorous public benchmark of capability and adoption trends.

FAQ

What is AI transformation and how is it different from AI adoption?

AI adoption means your people have access to AI tools and use them. AI transformation means the structure of the work itself changed: fewer steps, different roles, different economics. The practical test is whether removing the AI would break something in your operating model. If nothing breaks, you have adoption. Adoption is cheap and rarely visible in the P&L. Transformation requires process redesign, a decision about freed capacity, and a measurable effect on revenue, cost or cycle time.

How long does an AI transformation take?

One process can be genuinely transformed in 60 to 90 days, including baseline measurement, redesign, production deployment and verification. A company wide transformation across multiple functions typically takes 18 to 36 months, and it happens process by process rather than all at once. Programs that promise enterprise wide change in a single quarter are selling tool rollouts. The sequence that works is one process proven properly, documented, then repeated with falling marginal cost.

How much does AI transformation cost for a mid sized company?

For a company between 50 and 250 employees, a realistic first year total is 80,000 to 300,000 euros, split roughly across technology and licenses, external expertise, and internal time. The largest and most underestimated component is internal time: one to two full time equivalents. As a budget heuristic, if more than about a third of your spend is software licenses, the plan is weighted wrong. Roughly 70 percent of the effort in successful programs goes to process and people change.

Why do most AI transformation projects fail?

MIT research on 300 public deployments found roughly 95 percent of enterprise generative AI pilots produced no measurable P&L impact, and concluded the cause was approach rather than model quality or regulation. In practice the failure modes are consistent: no process redesign, no baseline measurement, no owner in the business, no decision about what happens to freed capacity, and governance so heavy that employees route around it. All five are organizational, and all five are fixable without changing vendors.

Who should own AI transformation inside a company?

A single executive should be accountable for portfolio results, with each initiative owned by the business function whose P&L it affects. A small central team owns platform, security review, standards and reusable components, and its success is measured by how many business initiatives reach production. IT-only ownership is the most common failure pattern, because technology does not own the numbers the initiative is supposed to move.

How do you measure the ROI of AI transformation?

Capture a baseline before you build: cycle time, volume, error rate and loaded cost for the target process. After deployment, measure the same metrics for at least three consecutive weeks. Convert only realized value, meaning hours that actually became output or were removed from cost, not theoretical time savings. Attribute conservatively when other changes happened in the same period, and report the initiatives that failed alongside the ones that worked. Realistic first year results are 15 to 40 percent cycle time reduction in redesigned processes.

Do we need a modern data platform before starting AI transformation?

No, and waiting for one is a common and expensive delay. The first wave needs programmatic access to the documents and records the process already uses, a retrieval layer over your own content, logging of inputs and outputs, and an evaluation set of real cases. Data lakes, unified customer platforms and model operations stacks become relevant at scale. If an initiative requires cleaning years of historical data first, it is a data project and belongs in a later wave.

What does the EU AI Act require from companies running AI transformation?

Obligations apply on a phased timetable: prohibited practices and the AI literacy requirement applied from February 2025, general purpose model obligations from August 2025, and the bulk of high risk system obligations in 2026 and 2027. Practically, classify each initiative by risk tier before building it. Most internal productivity work with human review sits in the lowest tier. Automated decisions affecting individuals in credit, employment, insurance or access to services carry the heaviest obligations and need documentation produced as you go.