Introduction
More than three years have already passed since OpenAI released ChatGPT.
Corporate adoption of generative AI has moved through the pilot phase of 2023-2024 and is now, through 2025-2026, transitioning into a phase of full-scale application to real business operations.
In particular, the capabilities of AI agents have improved dramatically — symbolized by the rise of coding agents in late 2025 — and companies are rapidly moving beyond individual productivity gains to consider AI adoption that targets entire business processes and organizations.
News about new models, tools, and use cases flies around almost daily, and the generative AI market continues to gain momentum.
On the other hand, reports on actual enterprise adoption tell a different story:
- At least 50% of generative AI projects will be abandoned after PoC by the end of 2025 (Gartner)
- 56% of companies have realized neither revenue growth nor cost reduction from AI, and 74% of the economic value generated by AI is captured by the top 20% of companies (PwC)
- 88% of generative AI pilot projects never reached production deployment (IDC)
To put it bluntly: despite all the excitement, AI adoption is simply not working out at most companies.
Until now, the sheer novelty of the technology and the trend itself meant that merely introducing AI carried a certain value — a kind of "bonus period," so to speak.
However, as the hype cycle progresses and the novelty of AI adoption itself fades, we are entering a phase where the question is no longer "Are you using AI?" but "What value have you created with AI?"
So how can organizations make AI adoption succeed?
Unfortunately, there is no universal law that guarantees success. The right approach differs greatly depending on the organization's size, talent, business processes, data, systems, and corporate culture.
While the shape of success varies by organization and by business, organizations where AI adoption fails share a fairly common set of patterns.
In this article, drawing on my experience with AI adoption and business application across multiple organizations, I will lay out the representative anti-patterns seen in organizations where AI adoption stalls.
For those feeling a bit fatigued by the daily flood of AI news and tool updates, I hope this article serves as a set of checkpoints for pausing and re-examining the AI initiatives in front of you.
Each section stands on its own, so feel free to start with whichever topic interests you most.
Organizational Anti-Patterns That Stall AI Adoption [Table of Contents]
- Not understanding that "AI delivers fast initial results"
- Treating AI as something you "buy off the shelf"
- Failing to judge price by the value AI creates
- Discussing AI at too high a level of abstraction
- Obsessing over end-to-end automation
- Not realizing the real problem isn't AI
- Getting ROI thinking wrong
1. Not Understanding That "AI Delivers Fast Initial Results"
One of the most fascinating — and at the same time most treacherous — characteristics of AI is that it delivers extremely fast initial results.
Why has AI captured so much global attention? One major reason is that visible output appears almost immediately after you start using it.
If we re-examine the phenomenon of "most PoCs are failing," what it really means is this: a great many people initially judged "this will work," but once they actually proceeded, it turned out to be far harder than expected.
If something had looked difficult from the start, the PoC would never have been launched in the first place.
Therefore, the essence of the widespread PoC failure phenomenon is that, relative to AI's actual difficulty, many people judged "this looks promising" at the earliest stage.
Anyone who uses AI in real work knows this well: when you delegate document creation, writing, or app development to AI, something that looks reasonably good comes back right away.
At this stage, everyone's first impression is the same: "Wow, impressive" — "This is going to work."
But when you inspect the details, you find numerous places that need correction and rework. Finishing it into a final deliverable takes far longer than expected — sometimes even longer than not using AI at all.
Moreover, the closer someone is to the decision-making layer rather than hands-on work, the more abstract their view of the business becomes, making them prone to look at the initial 70-80 point output and conclude, "This is ready for practical use."
In other words, because AI starts fast, it easily clears the 70-80 point bar that, by conventional standards, would justify moving forward with a PoC or adoption review. But raising it to the 90-95+ point level required for stable, real-world business use is extremely difficult.
Because the distance between 70-80 points and 90-95 points is hard to see, many AI projects get off the ground once, only to stall at the stage of application to real operations.
Vendors and sales representatives understand this characteristic well. They prepare polished demos and proposal decks and show you beautifully crafted prototypes: "Look how easily AI can streamline your operations."
With AI, building an attractive prototype is relatively easy. The hard part is adapting it to real business conditions, exceptions, quality standards, existing systems, and operational structures — and bringing it to a state where it can be used reliably.
Therefore, when evaluating AI adoption, you need to assume the "AI starts fast" characteristic as a premise and discount your assessment accordingly.
In most IT adoption, results ramp up gradually over time, like a technology S-curve. AI, by contrast, ramps up extremely quickly and then tends to plateau. Without understanding this difference, you will overvalue the impression made at the prototype stage.
Especially when an organization's decision-makers do not use AI in their daily work, they will keep repeating PoCs based on optimistic assessments without ever noticing this characteristic.
Of course, fast initial results are not a bad thing in themselves — nothing starts if the project never gets off the ground.
What matters is skillfully using that initial velocity as momentum to launch the project, while at the same time properly managing expectations about the difficulty of reaching practical deployment.
You should discount the first demo somewhat, treat it as the starting point, and design a path that lands the project all the way at real operational use within the organization.
Even as I write this, countless reckless PoC plans based on highly abstract, optimistic assessments are no doubt being launched between corporate and vendor decision-makers.
The lower the resolution your own decision-makers have on AI and on the business itself, the more caution is required.
2. Treating AI as Something You "Buy Off the Shelf"
This pattern is common among people who carry a strong mental image of SaaS and packaged-product adoption from the early days of the term "DX" (digital transformation).
They assume that AI, like conventional IT tools, is something you purchase externally, deploy internally, and adoption will simply follow.
Organizations like this tend to constantly scan the market: "Which LLM has the highest performance?" "Isn't there a better AI tool or product out there?"
Model and tool selection certainly matters. But as demonstrated by the fact that simply handing out a general-purpose AI like ChatGPT to employees quickly hits a ceiling in effectiveness, product adoption alone does not generate essential value.
The essence of AI utilization lies in how you pass your company's context — business knowledge, data, rules, and decision criteria — to the AI. Going further, what matters is not merely replacing parts of existing work with AI, but rethinking your business model and business processes themselves around AI as a premise.
Off-the-shelf products are generalized and abstracted so that any company can use them. Simply deploying a product will never reach into your company's specific business issues, organizational structure, or complex exception handling.
The fact that AI vendors have in recent years created a role called the FDE (Forward Deployed Engineer) is emblematic of this.
For a vendor, it would be far more efficient to sell a standardized product as-is and scale it to many customers with minimal effort. That they nonetheless place importance on FDEs — engineers who embed deeply in customer organizations and support implementation tailored to individual operations and systems — is precisely because deploying products and tools alone does not translate into real business value.
This also shows that the customer success role that spread a few years ago is not sufficient by itself.
It is not enough to support product usage and drive up utilization rates; unless you reach into the customer's business processes, systems, data, and organizational issues the way an FDE does, it is difficult to make AI stick in real operations.
In other words, AI program leads need to look inward at their own company, not just outward at external products and technologies.
Continuing the old tool-adoption playbook — attending trade shows, taking vendor pitches, and trying one new product after another — will not solve the essential problems.
Be cautious when your AI program lead spends more energy gathering information on external vendors and products than in dialogue with internal business departments.
3. Failing to Judge Price by the Value AI Creates
This is also common with the type of person described above: they tend to think about AI adoption as an extension of conventional SaaS adoption.
That is, they apply the typical SaaS price anchor to AI — a vague sense that "around 980-1,500 yen per user per month" is normal — and anything above that feels expensive.
A typical case is the adoption of coworking-style AI offerings from Claude, OpenAI, and others.
For these, the cheapest Pro plans do not provide enough tokens; for serious use, the $100 plan (roughly 15,000 yen per user per month) is the recommended tier.
At this point, thinking in conventional SaaS terms, people conclude "15,000 yen a month is too expensive." But the hourly cost a company bears for an employee is roughly 4,000 yen at an annual salary of 5 million yen, and roughly 8,000 yen at 10 million yen.
In other words, if an employee using such an AI coworker saves just 2-4 hours or more per month, the investment pays for itself.
By connecting the AI coworker to your core internal tools and defining task skills that substitute for or support your own work, saving a few hours per month is easily achievable.
Moreover, skills can easily be shared across the organization, so not everyone needs to build their own. Since desktop operation is also possible, some may initially find it valuable as a kind of RPA replacement.
The strong price anchoring to conventional SaaS makes 15,000 yen per month feel expensive, but since every employee effectively gains a dedicated assistant or subordinate, it is an extraordinary bargain in cost-effectiveness terms.
If you keep viewing it through the old "IT tool" lens and price band, you will misjudge the adoption decision.
Recently there has been growing discussion that AI should be viewed as personnel cost rather than IT cost. Going forward, companies may well polarize into those that pay seemingly high costs for AI and reap even greater returns, and those that treat AI as just another IT tool, stick to cheap tools and free tiers, and obtain only limited results.
Given my line of work, I spend more than 100,000 yen a month on AI — and since hiring a human assistant would cost many times more, it feels like an incredible bargain.
If anything, being able to procure such extraordinary resources freely means I feel I should be finding ways to spend more on it going forward, not less.
In the AI era, the way we think about AI costs and budgets needs to be fundamentally reconsidered. Be cautious when the people in charge, or those involved in decision-making, are still operating with the conventional IT-tool mental model and budget expectations.
4. Discussing AI at Too High a Level of Abstraction
Compounding the fast-start problem is the fact that discussions about AI adoption are often conducted at far too high a level of abstraction.
In typical presentation decks and proposals, an AI agent icon is placed on top of business functions, organizational functions, or highly abstract process diagrams, accompanied only by grand messages like "Streamline operations with AI."
The As-Is/To-Be processes remain at the conceptual level, and you cannot see what specifically goes in as input, what comes out as output, or how much impact can be expected.
It amounts to a decision-maker and a vendor's sales representative chatting about how "AI could probably be useful somewhere around here."
To some extent this is unavoidable — like an FDE, you cannot draw a concrete picture without actually seeing the on-the-ground business processes, data, and the state of the system environment.
Between an upper-layer manager who does not really understand frontline operations and a vendor sales representative who, being from another company, naturally does not understand the internals either, a loose agreement gets struck — at a very high level of abstraction — that "we will use AI in this area and produce results."
Then, on the strength of a fast prototype and validation results, optimistic targets are set among stakeholders. As the project actually proceeds, it collides with all sorts of unanticipated problems and becomes difficult to land (= PoC failure).
Of course, since you have to start from concept planning, a conceptual phase is necessary. The problem arises when the project races ahead without adequate scrutiny by people who actually know the business terrain and people who can properly appraise AI projects.
Because in reality, it is not uncommon for a project considering AI to turn out not to need AI at all.
Anyone who implements AI for business applications has surely thought, at some reasonably advanced phase, "Wait — do we actually need AI for this?" — and probably more than once or twice.
If user input is inconsistent and you want AI to clean and structure it for downstream processes, then fix the input form instead. If you want AI to replace judgments employees make based on data, then define rules and master data, route cases programmatically, and send only the exceptional cases that rules cannot cover to human review.
For cases that cannot be defined by rules, AI does not know the right answer either, so a final human check is required anyway. There is no need to have AI process the other 90% just to handle the 10% of exceptions.
To put it plainly, AI is needed only when dealing with "fuzzy" information — information with variability. All non-fuzzy information is a problem that should be solved with programmatic, rule-based automation.
And from the standpoint of business process design, what matters most is preventing fuzzy information from arising in the first place.
Unstructured, inconsistent data caused by disorganized operations; business processes that remain un-ruled because they depend on specific individuals — people try to resolve this fuzziness with AI, but this is fuzziness that should never have existed in the first place.
Solving an upstream process problem downstream with AI is, as a rule, a poorly-conceived strategy.
At high levels of abstraction, it is easy to think "using AI here would streamline the work." But as you raise the resolution on the business, you often find that this is not a problem AI should solve.
In one past project of mine, after diligently untangling the business processes, there was no place left where AI should be used — leaving me with the odd dilemma of "we can achieve the goal, but this is an AI project and there's nowhere left to use AI..."
That said, for someone in the position of championing AI, perhaps the truly critical skill is being able to make the decision not to use AI and explain the reasoning to stakeholders. From a business consultant's perspective, if reworking the business processes made AI unnecessary, that might be the mark of a truly first-rate consultant.
Naturally, AI is a means, not an end — and wherever AI is used, the difficult questions of "reliability" and "reproducibility" inevitably follow.
This is not to say AI should be avoided as much as possible. Rather, you should first pose the question "Is there a way to solve this without AI?", discuss it among stakeholders, and only when the answer is clearly No (AI is genuinely required) should AI adoption be considered.
Rule-based programs are faster than AI and 100% reproducible, so AI is the second option, not the first.
Business users who were initially excited about AI often find, as discussions and implementation reviews raise their literacy, that one day they ask: "Wait — do we even need AI for this?"
And in many cases, abandoning the AI approach and returning to first principles solves the problem by other means.
When high-abstraction AI decisions are driven solely by upper layers without this kind of AI literacy, you end up trying to solve problems with AI that should not be solved with AI. The difficulty rises needlessly, and the project bogs down.
When an AI project kicks off, it is critical to ascertain who has discussed it, and to what depth.
5. Obsessing Over End-to-End Automation
This is a problem that tends to arise from being too earnest: insisting on end-to-end (E2E) automation in business processes that use AI.
To maximize the automation rate, teams attempt to automate every possible step — but the obsession with E2E automation itself can derail the project.
The fundamental premise to keep in mind: AI and E2E automation are a very poor match.
It is tempting to think that since AI can now handle previously intractable unstructured data, E2E automation should be achievable at a broader scale than ever. But the great price of AI's flexibility is that its reproducibility will never be 100%.
Rule-based programs are simple: for predefined logic, they execute with 100% reproducibility. Conversely, when an undefined case arrives, they fail with 100% reproducibility.
AI itself has a long history, yet the vast majority of real-world systems around us run on rule-based programs. That is because in the real world, reliability matters enormously.
The generative AI use cases that come up first — ideation, summarization, drafting documents, search assistance — share one property: when the AI fails, nothing immediately catastrophic happens.
They rest on the premise that a human check occurs downstream and final accountability transfers to a human — which is why using AI there is acceptable.
For example, suppose you launch an AI project to replace time-consuming document creation and submit the output directly to clients. With careful engineering, it might run fine in almost all cases.
But you can never completely eliminate the possibility that, in some entirely unanticipated way, personal information is accidentally included or a client's name is wrong.
Even if you harden prompts based on observed errors or chain a checking AI for double-checks, the space of potential errors is infinite, and you quickly face rule explosion.
Even if a meticulous PoC or pilot yields a validation result of "zero errors," that only means "the cases so far were fine." You can say safety is high, but it guarantees nothing about future safety.
In short, AI is fundamentally incapable of 100% reproducibility, so aiming for E2E automation with AI begins an endless cycle of trial and error.
The first thing to decide when using AI is where to compromise — in other words, where to stop.
Taking AI's sub-100% reproducibility as a given, you draw the line on where and how far AI will be used.
The basic policy for AI-powered automation projects is: maximize the automation impact of the intermediate processes.
You give up on E2E automation — but since efficiency drops the more finely human checks are interleaved, you study the current As-Is flow, push the human-involved steps as far as possible to the front and the back, and automate the middle with AI.
To make the final human review easy, you also build in traceability and logging mechanisms, increasing the transparency of what tasks the AI performed and why it made its judgments — thereby reducing the effort of the checking step as well.
When you delegate a task to a subordinate, isn't it clearly easier to receive a report like "I performed the work in these steps and made this judgment based on this information" than a bare "Done"?
Better still: "I'm a bit unsure about this point — could you check it?" or "I couldn't determine the right way to handle this part, so I've put it on hold. Could you advise?" Reports that admit what wasn't understood are far more valuable than plausible-looking output for everything.
Also, the more the intermediate processes are entrusted to AI, the more the initial instructions and alignment of understanding matter. Depending on the nature of the work, it is often better to have a human in the first step as well. In most cases, the shape will be humans bracketing the AI's processing at the front and the back.
If your AI automation strategy aims from the start at expanding areas of 100% E2E automation, project difficulty becomes extreme and applicable areas shrink dramatically. The result is that the image of "AI is hard after all" takes hold among stakeholders, and other AI initiatives stall too.
Given AI's characteristics, rather than pursuing E2E automation in narrow point-and-line domains, a more effective strategy is to paint the whole surface: start with roughly 70-80% automation across a broad area and gradually raise it toward 90-95%.
Achieving 70% automation in two business processes is both easier and more impactful than achieving 100% automation in one.
Keeping the premise "AI will never be 100% reproducible" in everyone's mind from project launch, and aligning on "what are we aiming for (where do we draw the line)" is in a sense the most important thing of all.
If you design operations from the start with an 80% automation target, a project that achieves 95% is a resounding success. But if you set 100% as the target from the start, operational design gets shortchanged — 95% automation then cannot be sustained in operation, and production launch itself becomes difficult.
The cause of most PoC failures is reckless target-setting that fails to properly account for AI's characteristics.
Personally, when considering an AI project, my first question is always "Is there a way to solve this without AI?" And if the answer is that AI should be used, the next question is "Where do we stop?"
A project that assumes AI for everything from the outset and pursues E2E automation at low resolution can safely be said to fail with high probability.
That said, leading with too much realism too early dampens stakeholders' enthusiasm — and that, in itself, becomes a major cause of project failure.
In such cases, the critical skill is maintaining stakeholders' enthusiasm for AI and the project's momentum, while progressively revealing the realistic line and steering the target to an appropriate level.
6. Not Realizing the Real Problem Isn't AI
The most typical failure mode of AI projects — and the real difficulty of AI projects — is that most of the problems to be solved lie outside of AI.
Since it's an AI project, one might assume a brilliant AI engineer would make it succeed. But even if you managed to hire an excellent AI engineer, on their own they would be like a fish out of water, unable to deliver the expected results.
That is because AI probably accounts for only 10-20% of the factors that determine an AI project's success or failure.
AI performance is already very high and has become somewhat commoditized; as long as you use a recent model, results do not differ much regardless of who uses it.
When generative AI first appeared, prompt engineering drew attention and the "prompt engineer" job title briefly emerged. Today, AI writes the prompts — and we have AI write the programs too.
Mastery of AI is of course an important element, but in terms of what decides an AI project's success, it does not account for a large share.
The fundamental bottlenecks are business processes, data, system infrastructure, and the driving organization.
First, if the business process itself is complex, person-dependent, and has no defined rules, no amount of high-performance AI will improve operational efficiency.
You would be adding AI — a large new variable — to work that is already unorganized and full of variables. Far from converging, things spiral, and you even create a brand-new job: handling AI errors.
Rather than trying to force AI to solve a complex business process, you should redefine it as a simple process and then have programs and AI execute it at high speed. The variable to move first is the business process — not the AI.
Next, data. This is obvious, but the question is whether the necessary data is properly maintained.
AI itself cannot determine whether the data supplied to it is wrong; unless something is obviously false by common sense, it treats the given data as correct.
If outdated documents or erroneous data get loaded into the AI's context, the AI proceeds on that premise. The quality of the information you hand to AI matters above all else.
The other critical factor is the timing of when information is passed to the AI.
There is a big difference between instructing "Process tasks A through C in order — everything you need is somewhere in this folder and this database" versus "For task A, reference these two files and this table; for task B, use..." — limiting and specifying the necessary information per step.
Even if all the information is accurate, whatever is handed to the AI influences its judgment, so choosing not to pass information that is unnecessary at that point is essential.
If the data is disorganized, all you can say is "it's somewhere in there," which spawns a new task — the AI searching for information — and business quality naturally degrades.
By handing the AI the minimum necessary information at the right time for each task, the AI's reliability and reproducibility improve dramatically. This, of course, requires that data be properly organized and managed.
Rather than handing over an entire database, preparing a data mart shaped precisely for what the AI needs in that business process will yield far greater overall quality improvements.
Next, system infrastructure. This is less a bottleneck than a knockout factor: the systems used internally have no API or SQL interface, and the AI simply has no way to access the data it needs.
It is fine to develop your AI project concept, but confirming whether the AI can even access the necessary data comes first.
Since building such infrastructure quickly is difficult, workarounds exist — dumping data via nightly batch, or scraping screens with RPA — but the loss of real-time capability often severely reduces the efficiency gains, or makes operation impractical altogether.
If the system environment is not AI-native, only surface-level AI initiatives are possible — meeting minutes, summaries, document drafts. In any domain where you plan to use AI, the environment for AI to operate in must be prepared.
When the footing for AI is terrible — or AI cannot move at all — no amount of talking about AI means anything.
Finally, the driving organization. As described above, AI projects require action on every front: business process improvement, data infrastructure, system environment.
That means very strong authority is required, along with the drive to engage stakeholders across departmental lines.
Fundamentally, it is difficult unless you form a team whose mission is offensive DX — a DX promotion department reporting directly to executive management — and grant it appropriate authority.
The typical failure case is vaguely assigning AI initiatives to the traditional corporate IT department.
This is not because traditional IT departments are bad — the problem is that the KPIs are simply too different. Although rarely written down in formal evaluation criteria, in most cases the department is run on a demerit system rather than a merit system.
Under a demerit system, not making mistakes — that is, not causing system or security incidents — is the top priority. And the optimal strategy for not making mistakes is to do as few new things as possible (create no points of change).
Every point of change carries probabilities of both success and failure, so avoiding change becomes paramount — and turning down requests from business departments gradually becomes the expected internal norm.
I have rarely seen it myself, but companies where the IT department works closely with business departments and is deeply trusted internally must be very few (if yours is one, it is a remarkable company).
This is not the fault of IT departments or the people in them — it is a management decision.
Top IT talent abroad routinely commands annual salaries in the hundreds of thousands of dollars, yet in traditional companies the opposite tendency persists: IT departments sit on suppressed salary tables.
Handing an AI project — with its extreme uncertainty, the need to engage business departments, manage difficult stakeholder expectations, and drive hard — to an IT department with that history and context, and simply letting go, is unreasonable.
Since organizational culture cannot be changed overnight, the answer is to create an offensive DX unit that can act under direct executive sponsorship (ideally a hybrid of tech-strong external hires and people deeply familiar with internal operations) and give it merit-based KPIs.
To summarize: what matters is that business processes and data are in order, that infrastructure for accessing system data is in place, and that the driving organization has strong leadership. When these are satisfied, an AI project will produce good results unless the targets are badly misconceived.
In terms of skill-based roles, business consultants and database/infrastructure engineers take priority — the so-called AI engineer enters, in a sense, at the very last stage.
Which latest AI model to use, which AI tools to adopt — against problems of this scale, these are very minor questions. Asked whether the LLM should be Claude, GPT, or Gemini, the answer is: any of them is fine (that is not the question we should be discussing right now).
If your internal AI project's discussions are dominated by AI topics alone, be on guard. If the main topics are internal systems, data, and resolving business issues, that is a healthy project (a good project).
What matters is having people with the judgment to determine what the current bottleneck is and which variable to move — including the decision not to use AI. Talking only about AI will never resolve the true bottleneck.
7. Getting ROI Thinking Wrong
Finally, ROI.
Even people not particularly versed in AI understand the term "ROI" as a common business language. So when someone who does not sufficiently grasp the state of the field or the characteristics of AI calculates an ROI, that number can itself become the project's bottleneck.
The fundamental premise: ROI is not a binary matter of positive or negative. Depending on the time window you cut, the very same initiative can be either.
A clear example is new-graduate hiring. At large companies especially, there are training periods spanning six months to a year after joining. And even after completing that long training and being assigned to the field, new hires are not immediately useful.
On the contrary, senior employees must serve as mentors for new hires who know nothing yet, carving time out of their own work to train them.
In other words, if you cut new-graduate hiring at a window of six months to a few years, the ROI is decidedly negative. But as new hires accumulate experience and become productive contributors, at some point they cross the break-even point, and from there the ROI turns positive — it is a long-term initiative.
Whether you calculate an ROI yourself or review one calculated by someone else, the first things to check are: what time window was used, and is that window appropriate?
If the ROI window demanded is extremely short — "an AI initiative with clearly visible results in one month" — what you can actually do becomes very limited.
You end up restricted to surface-level moves: introducing simple AI tools anyone can use, or inoffensive AI training that requires no interdepartmental coordination.
What matters is maintaining an investment perspective and setting the ROI evaluation window appropriately for the nature of each initiative.
It is not that shorter is better or longer is better. For example, sort initiatives across multiple time horizons: short-term initiatives in months, mid-term in six months to two years, long-term in two to five years.
If you center everything on short-term ROI, churn through a few AI projects without success, and conclude "AI is hard after all" or "AI doesn't produce ROI," that does nothing to improve the organization.
This is not unique to AI, but quick-win initiatives that involve no pain of improvement rarely deliver essential, lasting results.
And the fundamental reason AI projects fail to show ROI is, in most cases, not that AI is hard — it is that the organization is carrying accumulated "debt."
The identity of this debt is the business, data, system, and organizational bottlenecks described earlier. Leaving these unaddressed is the same as already carrying a large liability.
Demanding short-term ROI from an AI project in this state is tantamount to making AI repay all of the organizational debt accumulated over the years.
But the debt properly needs to be repaid before AI can produce results — expecting AI to suddenly deliver large returns on an unprepared foundation is unreasonable.
It is like planting crops in an untilled, desolate field: no matter how superb a crop you find and buy from outside, as long as the soil has fundamental problems, the crops will not thrive. Likewise, what decides an AI project's success is not the AI model's performance but the organizational environment in which AI is deployed.
It once seemed AI might leapfrog existing problems in a single bound, but in reality the opposite is happening: the companies that had steadily worked on DX before generative AI arrived — the AI-Ready companies — are the ones using AI to generate outsized, accelerating results.
Conversely, in carefully tilled, fertile soil, even a somewhat difficult crop can be grown well. To put it starkly: an organization with disorganized operations and data adopting the latest models — Claude Fable, Mythos, GPT-5.6 — will be outperformed by a steadily DX-hardened, AI-Ready organization running GPT-4o.
In an AI-Ready organization, every project produces ROI more readily, and the payback period shortens.
So when an AI project struggles to show ROI, the question to ask is not "Which AI model should we use?" but "Which organizational issue is the bottleneck?"
Precisely because there are no shortcuts, facing your company's actual state, doing the unglamorous DX work, and building an environment where future ROI comes easily is what puts you in a position to harvest large returns continuously.
For better or worse, AI can be described as a technology that surfaces, all at once, the DX debt an organization has accumulated.
It hurts in the short term, but looking a few years ahead — as AI's evolution accelerates further — the companies that resolve these organizational issues will be the ones to reap ever larger rewards.
Even if the immediate AI project fails to deliver the expected results, if that failure lets stakeholders viscerally recognize the organizational issues and forge a shared understanding of the need to become AI-Ready, then in the long run, that AI project arguably produced a large ROI.
On the other hand, if you lack the organizational-debt perspective and keep repeating initiatives that chase only short-term ROI, by the time you notice, an irrecoverable gap will already have opened.
Switching to the latest AI model can be done instantly — but solving organizational issues takes a very long time.
Concretely, what matters is running a cycle like the following:
- Make the organization's current environmental issues visible, and align stakeholders on expectations for AI and its difficulty
- Launch projects in areas with relatively solid footing and a high probability of winning
- Improve business and data issues along the way, and carry the project all the way to production operation (do not let it end at PoC)
- Share the results internally, creating a state where other departments say "we want to do this too"
- Make visible the potential and the bottlenecks for AI adoption in other areas
- Roll projects out horizontally while further solidifying the organization's foundation
By repeating this cycle, the organization gradually becomes AI-Ready.
Naturally, simply telling people from the start that "organizing business processes and data is important" will not move most of them to act.
Without a visible exit or return, it looks like an effort-only exercise, and stakeholders struggle to internalize why it must be done now.
Here is where AI's fast start can be used to your advantage: build a prototype with AI first and show the future state of the work in tangible form, so stakeholders can concretely imagine, "If this becomes real, this is how much our work changes."
At the same time, actually running the AI reveals the reasons things don't work — business processes, data, permissions, system integration.
But with a clear AI-shaped exit in view, reasons and motivation for the unglamorous improvements emerge: "If we clean up this process, we can make it real." "If we fix this data, the impact gets even bigger."
Because the AI exit is visible, stakeholders' awareness of business and data management rises, and organizational issues long deferred finally get addressed.
In other words, AI can serve as an effective trigger for surfacing organizational issues and building out the environment.
Show the future with AI, expose the gap with the present, close that gap one piece at a time while delivering results, then expand to the next area — running this positive cycle is what matters.
Because a large part of this is investment in the future, mechanical ROI targets that ignore these multifaceted factors end up slowing an organization's DX rather than advancing it.
AI is, if anything, a downstream matter. Improving organizational issues — the upstream — has far larger ripple effects across every AI initiative, and it is the latter effort where ROI truly materializes.
When I talk with professional acquaintances who drive AI at the field level, almost none of the conversation is about AI — it is consumed by how to resolve organizational issues.
Conclusion
What did you think?
Amid the daily whirlwind of AI information, important and otherwise, organizations where AI adoption fails share broadly common patterns.
I believe the current phase is not about frantically trying every new model and tool, but about seriously solidifying the organization's foundation so that the benefits of AI's continuing evolution can be enjoyed sustainably.
If an organization is AI-Ready, every improvement in AI performance delivers a larger benefit. To put it bluntly, it means building a position from which you can free-ride on AI's evolution.
Keeping up with the latest AI certainly matters, but rather than scrambling to collect fast-moving information with a short shelf life, it is more important to engage with your own operations, data, systems, and organizational structure over the medium-to-long term, and to resolve the bottlenecks one by one.
The important things tend to be boring. But precisely because anyone will chase what is flashy and fun, it is the organizations that quietly and steadily do what truly matters that may come to hold the greatest competitive strength in the AI era.
We help organizations work through exactly these challenges — from untangling organizational issues to hands-on support for AI adoption.
