Why AI Adoption Stalls: Six Obstacles

The most urgent gap in an AI readiness assessment I ran for an enterprise client was not a technical one. The company's knowledge existed; nobody could reach it.

That result matches a list I wrote before I had to use it. Of the six things that stall AI adoption, five are people and operating-model problems. Budget for those, and the technology mostly takes care of itself.

Which six obstacles stall AI adoption and limit its business impact?

Six obstacles stall AI adoption, and only the first is mainly technical. The other five sit with people, roles and the way the company runs. I wrote the list in November 2025, during MIT Professional Education's Applied Generative AI for Digital Transformation program, before I tested it on a client, so read it as a practitioner's checklist rather than a survey result.

1. Budgets and resource allocation. Compute and cloud spend, data work, and staff time to learn and build while the core business keeps running. Staff time is the line leadership under-budgets, and for API-based generative AI the budget is mostly staff time, not hardware.
2. Talent and knowledge. Few people can build the more capable systems or see novel uses. The choice is to reskill or to pay a premium for scarce talent, and not choosing is also a choice.
3. Unclear return. Returns are still debatable by sector and function, so buy-in follows a pilot that demonstrates return, then the bigger commitment. "No proven ROI" is the argument resisters will reach for.
4. Change management. Culture, structure and vision all move at once, which is hard for each person and for the organization. Most large transformations fail.
5. Vision. AI lets a company re-imagine whole workflows because sequential timelines compress. The obstacle is building an environment that rewards curiosity about novel uses.
6. Active engagement in learning. A workforce only moves along the experience curve by using the tools. Without that use, knowledge loss is inevitable, and nothing replaces the intuition that comes from doing.

An AI readiness assessment that scores four things, data, workflows, team and governance, puts obstacle 1 on data and workflows. Obstacles 2, 4, 5 and 6 land on team and governance.

Which obstacle shows up first?

In the assessment I ran, the knowledge and learning obstacles (2 and 6) showed up before anything technical. The company's knowledge existed, but nobody could reach it. The tooling question was the easiest one on the list.

What the assessment found, from a four-month digital transformation and AI readiness program for an enterprise client, with the readiness assessment in month one:

• Discovery sessions and a structured readiness questionnaire covered seven functions, from finance and HR to customer success.
• Staff rated their own documentation accuracy as low as 4 out of 10 in some teams. That is their own estimate, not a measurement, so treat it as a signal rather than a score.
• The single most frequent and urgent finding was not a model or tooling gap. Institutional knowledge existed but was scattered across a portal, SharePoint, local servers, personal notes and the memories of experienced staff.
• The gap workbook scored six domains: strategy and value, governance and ethics, culture and people, engineering and technology, data, and operating model.
• Nine prioritized gaps came out of the assessment. Five were gating for the first build; four shaped its content scope and post-launch roadmap.
• The output was one scoped build: a retrieval knowledge base for internal documents and procedures, with source attribution and role-based access as gating governance requirements before broad rollout.

I went in expecting the data and tooling rows to dominate. They did not. Knowledge held in personal notes and long-tenured memories is a question of who knows what (obstacle 2) and who is learning (obstacle 6). The technology decision was the easy row; the people rows, and the question of who owns each gap, decided the plan.

We planned for champions in each pilot department, each planned at two to four hours a week, and left the choice of who to the client. That is deliberate. The client knows its people better than any consultant could: who will embrace the change, who will model the new habits, and who can bring co-workers along. When the requirements were written, the names, and whether managers would release those hours, were still the client's to settle.

What does change management install?

Change management installs ownership: every gap gets a named owner and a status before anyone chooses a tool. Most large transformations fail, and a gap list with no owners is a slide, not a plan.

In the assessment above, the gap workbook had a column for each of these:

• current state and desired state
• the gap and its severity
• business impact and a priority category
• a remediation action
• a process owner
• a status

The last two columns do the work. A remediation action without a process owner has nobody to answer for it, and one without a status has no way to show progress.

Where the gaps include governance, the same logic applies to a company AI policy. The policy structure I built in an MIT Professional Education course has seven parts, ten principles and four implementation mechanisms; it is a shape that works, not a standard. The four parts I find most often missing are:

• An AI system of record: one register of every AI effort in the company.
• Human gatekeeping at each lifecycle stage: the human in the loop AI check, a verification gate rather than a statement of intent.
• A hallucination clause.
• Ethical review staged to technology readiness.

This is structure, not legal advice; your own counsel reviews the policy before anyone adopts it.

Who should learn first?

The people who will own the gaps should learn first, and they learn by using the tools on their own work, not by reading about them. Of the six obstacles, this is the one I hold most strongly.

Use is what moves a team along the experience curve. Experience raises the level of abstraction people can work at. Without that use, knowledge loss is inevitable, and in a company where much of what matters sits in experienced staff's memories, that risk is not abstract. Nothing replaces the intuition that comes from doing.

I spend most of my day in AI tools, testing new workflows. Some become core to how I work; others quickly fall by the wayside. AI is changing how work can be done, so curiosity matters more than any single tool. Deep expertise can even get in the way, because the best practices it rests on may no longer be the most efficient way to do the job. So I encourage clients to explore and try things with AI on their own. If they find the answer themselves, that moves them along. If they struggle, it becomes a teachable moment: they see what did not work, we work through why, and they approach the task differently next time. That is where the real learning happens, and it is worth more than being handed a finished tool.

At one client, a staff member had tried to pull records out of a 30,000-word master document with an AI tool, and it kept crashing. Asking the AI to read the whole thing at once is the natural first move, and it is where large documents break. Within two hours of receiving the file I took a different route: I had the AI write a small program that read the document's 386 sections one at a time into a spreadsheet, counting anything odd instead of quietly fixing it. The result was 1,728 records in a spreadsheet. A later cross-check of the same data showed that 520 of 1,551 dated entries had already expired. Afterwards I walked the client through how it was done. The difference is the lesson: use AI to build the tool that does the reading.

How do you budget for the five?

Budget staff time as the main line item, and answer the return question with a pilot that demonstrates return before the bigger commitment. For API-based generative AI, the spend is mostly staff time, not hardware: time for people to learn and build while the core business keeps running. That is the line leadership under-budgets.

At the client, staff time was not budgeted at the start. The agreement promised access to subject-matter experts within three business days of a request, not a number of hours. The real asks surfaced as the work reached each step: 45 to 60 minutes per person to complete a document-scoring workbook, then two to four hours a week for each pilot champion. Set the hours before the work starts; otherwise every step opens with a request for time.

Unclear return is real, because returns are still debatable by sector and function. "No proven ROI" will be the first objection from anyone who resists the change. The answer is not a forecast; it is one scoped pilot with a named owner, governance gates set before rollout, and a return the team can see. How that kind of pilot goes wrong is its own subject: why AI pilots fail at mid-market companies.

At the client, the return question was on paper from the start: the first three findings in the gap workbook, all marked urgent, were that nobody could track what AI delivered, funding came with vague success measures, and the evidence of impact was anecdotal. An early deck did include a rough return estimate, but the plan did not rest on it: we proposed two weeks of measuring the current state first (hours spent, documentation accuracy, how long invoices took to get paid) so every pilot had a baseline to beat, and the plan made any second phase depend on measured improvement and adoption above 60 percent.

Score the people rows first, and give every gap an owner and a status before choosing a tool. That order is what an AI readiness assessment includes when it is built to change the plan, not decorate it.

If your first AI effort is moving slower or smaller than planned and you suspect the reason is not the software, scoring the people rows and giving each gap an owner is where our AI transformation advisory engagements start. Get in touch to talk through yours.