Top 5 Issues Companies Face Starting AI Adoption
Eighteen months in, the licenses are paid and the dashboards haven't moved. AI adoption fails as procurement and succeeds as role redesign. Five issues that compound in this exact order.
"AI is everywhere but I'm not seeing it in our numbers."
That sentence is the one I hear most often from tech-company owners who are eighteen months into AI adoption. They have bought the licenses. The team is using Copilot. Someone ran a workshop. A few pilots were declared successful and quietly shelved. And the delivery dashboard looks the same as it did before any of it started.
The instinct is to assume the tools are the problem, or the people, or the model version. None of those is usually the root cause. The root cause is that AI adoption is being treated as a procurement event when it is actually a redesign of how each role does its work. Until that frame shifts, the five issues below will keep recurring in exactly the order they show up here.
This essay is the diagnostic vocabulary I wish I had when I started leading AI transformation inside the R&D org I run. Each issue has a symptom you can see from the CEO chair, a root cause sitting one layer underneath, and an implication for what a production-grade AI operating model would do instead.
AI adoption fails because companies buy tools instead of redesigning roles
The symptom is the one in the opening sentence: licenses bought, training booked, no shift visible in the delivery metrics that actually matter to the business. Cycle time looks the same. Defect density looks the same. The proportion of effort spent on rework looks the same. Sometimes throughput goes down for a quarter because people are context-switching between the old workflow and a half-built new one.
The root cause is that nobody redesigned the role. Buying a license for a developer is a procurement act. Redesigning the developer role is an operating-model act. The two look superficially similar and are deeply different. A redesigned role specifies which tasks now use AI, which tasks now have a different acceptance criterion because AI is producing the first draft, which review steps got compressed and which got added, and how the role's output is measured now that the input mix has changed. None of that is in a license agreement.
The implication is that AI adoption belongs to the head of the role, not to IT. The head of QA owns the redesigned QA role. The head of PM owns the redesigned PM role. IT owns provisioning. When the redesign is delegated to IT, the result is provisioning without redesign, which is exactly the state most companies are in eighteen months in. Inside the AI R&D team I lead, the redesigns that stuck were the ones where the role's head sat in the redesign sessions and personally rewrote the role's daily artefacts.
Without an AI security policy, shadow AI is already inside your company
The symptom is harder to see because it is, by definition, invisible. Engineers paste production code into ChatGPT to debug it. Account managers paste customer emails into Claude to draft replies. A product manager pastes a section of the roadmap into Gemini to summarise it for the board pre-read. None of this shows up in the procurement system because none of it is being procured. It is happening on personal accounts. The counter-move is the AI security policy you ship before any AI tool.
The root cause is that there is no policy that tells anyone what is sanctioned, what is forbidden, and what data may leave which system under what conditions. In the absence of a policy, people apply the rule they apply to every other tool that helps them get their work done faster: they use it. The fault is structural, not behavioural. If a fast tool exists and the company has not said anything about it, the staff who care about doing their job will use it.
The implication is that the AI security policy is not the last step of an AI adoption programme. It is the first. Until there is a sanctioned-tools list and a data-handling rule per data class, every other investment in AI adoption is being made on top of an uncontrolled surface. The policy does not need to be long. It needs to name the sanctioned tools, name the data classes that may and may not enter them, and name who reviews exceptions. That document, ratified at the executive level, is what converts shadow AI into governed AI. Issues three through five are not worth attempting until issue two is solved.
A vendor webinar is not training; role-specific reskilling is
The symptom is a calendar invitation. Someone from the AI vendor runs a one-hour overview session, screens are blurred over for the screenshot in the all-hands deck, and the training row on the AI adoption roadmap gets checked off. Six weeks later, the only measurable behaviour change is that the people who were already curious about AI are using it more, and the people who were not are using it the same amount as before.
The root cause is that the training was generic. It was not anchored to the role's daily artefacts. A developer does not need a tour of the Copilot interface; the developer needs a structured walk through how the code-review checklist changes when AI is producing the first commit, how the test-writing step shifts, and what the new failure modes look like when AI gets confident in the wrong direction. A QA engineer does not need an overview of test-generation tools; the QA engineer needs a curriculum that rebuilds test design around the assumption that production code will arrive faster and with different defect patterns. A PM does not need a Gemini demo; the PM needs a redesigned discovery workflow.
The implication is that every role gets its own AI-fluency curriculum, written by the head of the role, anchored to that role's daily outputs, and assessed against changes in those outputs. Generic training is procurement masquerading as enablement. Role-specific reskilling is the actual change. The cost difference is real - role-specific curricula take weeks per role to build - and that cost is the cost of the change actually happening.
Tool selection that lives in procurement produces a sprawl no one owns
The symptom is a list of subscriptions. Three code-assistants. Two writing tools. A meeting-summariser. A "company GPT" experiment. A vector database somebody set up. An agent platform that one squad demoed. None of them are deeply adopted. All of them are billing monthly. The CFO asks who owns the AI tool stack and the answer is everyone and no one.
The root cause is that tool selection was treated as a buy-the-best-tool problem when it is actually a fit-this-tool-to-this-role problem. Procurement evaluates vendors. Procurement does not evaluate workflow fit. When the loudest engineer in the office advocates for a specific assistant and there is no role-level criterion to push back with, the loudest engineer wins. Multiply that across departments and the result is sprawl by enthusiasm.
The implication is that tool selection is a role-level decision with explicit fit criteria written down before the evaluation starts. The criteria are not generic; they describe the workflow the tool is being adopted into. For QA, the criteria might describe how the tool integrates with the existing test-management system, what the audit trail looks like when an AI-generated test fails, and how the tool's output is reviewed before commit. For PM, the criteria are different. Procurement still runs the vendor process - pricing, security review, contracts - but procurement does not own the selection. The head of the role does. This single change removes most of the subscription sprawl on its own, because most of the sprawl is what happens when nobody is allowed to say no.
If no delivery metric was named, nothing changed by definition
The symptom is the one this article opened with. The CEO looks at the delivery dashboard and the numbers look the same as they did before AI was anywhere in the conversation. The instinct is to conclude that the AI investment did not work. Sometimes that is true. More often, the truth is narrower: no delivery metric was named at the start, no baseline was captured, and there is therefore no way to detect a change that may have happened.
The root cause is that the AI rollout was scoped around inputs (tools deployed, licenses provisioned, training delivered) instead of around outcomes (cycle time on a specific workflow, defect density on a specific product surface, rework percentage on a specific class of work). Input metrics are easy to capture and meaningless on their own. Output metrics are harder to capture and are the only ones the CEO actually cares about.
The implication is that every AI investment must name the delivery metric it will move, the baseline must be captured before the rollout starts, and the measurement window must be long enough to tell signal from noise. If no metric was named, no metric will move - not because AI does not work, but because nobody set up the conditions under which a result would be visible. In an effective redesign, the first artefact of every role redesign is the metric definition and the baseline reading. Without that document, the rollout is theatre.
The shift the five issues actually point to is operating-model, not tooling
Read the five issues again as a single sentence and what they say is that AI adoption has been mis-classified. It has been treated as a wave of tooling decisions when it is actually a redesign of how the work gets done. The five issues are the five places that mis-classification surfaces.
A production-grade AI operating model addresses all five in the same document and in this order: a security policy that lists the sanctioned tools and the data classes that may enter them; role-level redesigns owned by the heads of those roles, anchored to the daily artefacts the role produces; reskilling curricula that match the redesigned roles; tool-selection criteria owned by the heads of roles, with procurement running the buy but not owning the choice; and a delivery-metric per redesign with a captured baseline. The same five issues, rewritten as the components of an operating model.
The reason this reframing matters for a CEO reading this is that the cost of fixing five issues one at a time is much higher than the cost of recognising them as a single underlying problem. Eighteen months in, the question is no longer whether to invest in AI. The question is whether the org has the operating model to convert that investment into delivery. The companies that stay stuck at the eighteen-month mark are the ones that have not. The companies that pull ahead from here are the ones that stop buying tools and start redesigning roles, in that order, with governance underneath and a measurement frame on top.
