Why Most AI Adoption Frameworks Fail at Stage Two (And What IT and Data Leaders Should Do Instead)

Your organisation has an AI adoption framework. It has stages, a steering committee and a deck that went to the board. Six months in, two of the five nominated use cases are still waiting on data access approvals, the pilot has no evaluation set, and nobody can say whether last quarter's Copilot licences changed anything measurable.

The failure almost never happens at the readiness assessment. It happens one step later, in the gap between "we prioritised our use cases" and "we can prove the pilot worked." That gap has a name inside most organisations: nobody owns the plumbing.

Here is the pattern, stage by stage, and where IT and data leaders should be inserting themselves rather than waiting to be invited.

The stage-by-stage framework, and the stage nobody staffs properly

Most working AI adoption frameworks for businesses run through five stages. The labels vary, the sequence rarely does.

1. Readiness assessment — Where is the organisation now on data quality, tool access, workforce literacy and governance?
2. Use case prioritisation — Which two or three workflows are worth attacking first?
3. Foundations — Data access, governance rules, environment setup, capability building.
4. Pilot — Run the use case on a defined scope with a control group or baseline.
5. Scale — Expand, monitor, retire what does not work.

Stage two is where the politics get comfortable. Prioritisation workshops are genuinely useful and genuinely low-risk. Everyone agrees a use case sounds valuable. Nobody has yet asked the awkward question: who grants access to the data this use case needs, and by what date?

That question lands in stage three, and stage three is chronically understaffed compared to stages one and two. The readiness assessment gets an external facilitator. The prioritisation workshop gets two days off-site. The foundations work — access provisioning, classification, evaluation set definition, logging — gets assigned to a data engineer who already has a backlog.

Contrarian position: prioritisation is not the bottleneck, instrumentation is

The popular advice is that organisations fail at AI adoption because they pick the wrong use cases. In our experience working across corporate, public sector and regulated environments, use case selection is rarely the problem. Most leadership teams can identify three plausible candidates in an afternoon.

The bottleneck is that by the time a use case is nominated, nobody has pre-agreed what "working" will look like in numbers, and nobody has secured the data path to measure it.

Consider a realistic example. A shared services team wants AI-assisted drafting for standard customer correspondence. Good use case. Clear volume. Clear pain. What the prioritisation session did not produce:

• A baseline — current average handling time per letter, and current rework rate
• An evaluation set — 100 real historical letters with the “correct” version agreed by two reviewers
• A named data owner willing to release redacted historical correspondence
• A telemetry plan — what gets logged, where, and who reads it

Without those four items, the pilot becomes a demo. Demos persuade nobody at the budget stage, because a demo cannot answer "compared to what?"

Where this breaks in Malaysian and Singaporean enterprise context

Under PDPA and internal classification, releasing historic workflow data is a governance decision, not an IT ticket.

Two local realities make the instrumentation gap sharper than it is in markets where AI adoption frameworks are usually written.

PDPA and internal classification. Under Malaysia's Personal Data Protection Act, and matching internal data-classification policies across most GLCs and regulated firms, historical workflow data often contains personal data. Getting that data into a test environment is not a technical task with a ticket. It is a governance decision with a legal reviewer. If your framework's stage three does not name a legal or compliance reviewer with allocated time, the pilot queue will sit idle for weeks.

Shared services and outsourced functions. Where a workflow is partly handled by a shared service centre or a vendor, the data lives somewhere your team may not control. AI pilots scoped without checking data custody will discover this at the worst possible moment.

What IT and data leaders should do differently

1. Reframe stage one to produce a data inventory, not a maturity score

Readiness assessments usually output a maturity number on a five-point scale. That number is useful for a board slide and useless for planning. Ask instead for a use-case-linked data inventory: for each of the top five nominated workflows, what data exists, who owns it, how it is classified, and what the access path looks like.

This changes the conversation with the business. Instead of arguing about readiness scores, you are arguing about whether the contact centre's historical chat logs can be released to a sandbox by a stated date.

2. Give stage three a named owner and a hard gate

The stage-gate discipline that works in most transformation programmes is missing from AI adoption frameworks. Fix it by requiring, before any pilot is approved:

• A named business sponsor and a named technical owner
• A baseline measurement for the process as it runs today
• A signed-off evaluation set or acceptance criteria
• A data access confirmation with an approval date

If any of those four are missing, the pilot does not start. That is a harder line than most steering committees are used to, and it is the single highest-leverage change you can make.

3. Treat adoption telemetry as a deliverable, not a by-product

Most organisations can tell you how many licences they bought. Very few can tell you how many distinct users ran a task-augmenting prompt last week, in which department, and what happened downstream. That is a measurement design problem, not a reporting problem.

Decide the three adoption metrics you will track before rollout, at the role level rather than the tenant level. Per-department weekly active usage, time-to-first-draft for a specific document type, and human revision rate are more defensible than a licence utilisation percentage.

4. Put the guardrails in place before the sandbox opens

Data safety depends on tool settings, policies, data type and actual usage behaviour — not on the vendor's name. A practical AI governance workshop with your risk and compliance colleagues, held before the pilot environment goes live, is cheaper than retrofitting policy after an incident.

Define what may and may not be entered into an external model, where AI-generated output requires human sign-off, and how a suspected data exposure gets reported. Then make those rules part of onboarding for every pilot participant, not a PDF in a shared drive.

The role-by-role impact, in practice

An AI adoption framework that only names executives and end users will under-deliver, because the work sits in the middle. What actually changes, role by role:

Role	What changes during adoption	What they need from IT and data
Data engineer	Becomes the de facto AI infrastructure owner	Access provisioning runbooks, classification tags, sandbox environments
Data analyst	Shifts from one-off analysis to evaluation-set curation	Clear labelling conventions, review time allocated in their week
Data steward / governance	Owns classification decisions on historical workflow data	Authority to approve or reject access requests without escalation
IT / platform	Manages model access, logging, tool configuration	Named tool owners and a decision on sanctioned versus shadow tools
Department head	Becomes the adoption sponsor for their team	A baseline for their process, and a simple dashboard they can read
Risk and compliance	Reviews data release and output accountability	Defined review SLA so pilot queues do not stall
HR and L&D	Design role-specific capability sessions	The actual workflows being piloted, not generic AI literacy

That last row matters more than most frameworks admit. Generic AI literacy sessions raise awareness; they do not change how a specific team does a specific task. When AI training and consultancy in Malaysia are paired, the training content can be built around the exact workflows in the pilot — which is also what makes capability sustainable after the pilot ends.

A note on HRD Corp claimability

If your organisation is funding capability building through HRD Corp, AIHQ is a registered HRD Corp training provider, and programmes can be structured to be HRDC claimable — subject to client eligibility, grant approval and HRD Corp submission requirements. Claimable status is not automatic and should be confirmed against your own registration and levy position before you build it into a training budget. Treat approval as a dependency with its own lead time, in the same way you would treat data access.

Counter-arguments worth taking seriously

"This makes pilots too slow." It does make them slower to start and faster to conclude. A three-week pilot with a baseline and a defined evaluation set produces a defensible answer. A three-month pilot without either produces a slide.

"We will work out measurement after we see it working." This is the most common and most expensive position. Without a pre-agreed baseline, any improvement you observe will be contested by whoever wanted a different outcome. The argument you will lose is not about the tool; it is about attribution.

"Our data is not ready for this." Then the honest output of stage one is a data remediation project, not an AI pilot. Naming that early is more valuable than launching a pilot designed to fail. For teams still mapping their way through this, a structured AI adoption framework consulting engagement is often where that decision gets made properly.

Sequencing: what a realistic first 90 days looks like

• Weeks 1–3: Data inventory for the top three use cases. Name owners. Confirm classification and access paths.
• Weeks 4–6: Baseline measurement of each process as it runs today. Build or curate evaluation sets. Start the compliance review of historical data.
• Weeks 7–9: Sandbox environment, guardrail rules, telemetry design. Pilot participants confirmed and briefed.
• Weeks 10–12: Pilot runs on defined scope. Weekly read of the three adoption metrics. Decision gate at the end: scale, adjust or stop.

Ninety days is not aggressive. It is roughly the minimum time required for the governance work to happen in a regulated environment, and it is short enough to keep executive attention.

Where custom solutions enter the picture

Some workflows will clear the pilot and reveal that an off-the-shelf tool is not sufficient — the process needs a retrieval layer over internal documents, an approval routing step, or an interface inside an existing system. That is the normal transition point. Reviewing custom AI solutions at the end of a successful pilot is a very different conversation from commissioning one at the start, because you will have baseline data and a defined problem.

Organisations that sequence it this way tend to get further than those that buy a platform first and then go looking for a problem.

For IT and data leaders, the practical takeaway is narrower than the framework suggests. Your job is not to own AI adoption. It is to make adoption measurable — by demanding a data inventory at stage one, a named owner and four hard gates before any pilot, and role-level telemetry from day one.

The frameworks that fail at stage two fail because they were designed for consensus, not for evidence. Fix that and the rest of the sequence is workable.

AIHQ has trained and engaged over 9,000 professionals across corporate, public sector, professional and regulated environments, and works with AIHQ training and consultancy teams to structure adoption from readiness through to implementation. For frameworks tailored to your data landscape, you can discuss your AI adoption needs with the team directly.