Most organizations are now using AI in some capacity. That alone tells you something important: access to AI tools is not a competitive advantage. Everyone can call the same APIs and run the same models. The organizations actually getting value from AI are not winning because they found a better tool. They are winning because they figured out where to apply AI.
The Problem with Generic AI Adoption
Gartner predicts that at least 30% of generative AI projects will be abandoned after proof of concept by the end of 2025, primarily due to poor data quality, inadequate risk controls, escalating costs, or unclear business value. The RAND Corporation found that AI projects fail at more than double the rate of conventional technology projects, by some estimates. These are not engineering failures. They are strategy failures.
The pattern is consistent: organizations start with the technology and work backward, asking “what can we do with this?” That question almost always leads to generic use cases that competitors can replicate, or pilots that demonstrate capability but do not attach to anything that matters.
The better question is: what problems do we have that no one else has quite the same way, and which of those are ones AI can actually help with?
Identify Your Proprietary Assets
A model is only as useful as what you give it to work with. The strategic question is not “can AI do this?” It is “do I have the data, context, and domain specificity to do this better than anyone else could?” That question points you directly at your proprietary assets: the things competitors cannot easily replicate.
McKinsey distinguishes between organizations that are “takers” (users of available tools, typically via APIs and subscription services), “shapers” (integrators of general models with their own proprietary data), and “makers” (builders of foundation models). For most organizations, the maker approach is too expensive to be practical, and the taker position produces no durable edge. The shaper position is where competitive advantage lives, and the question is what proprietary assets you bring to that integration.
Two categories worth examining closely:
Proprietary data and signals. What data does your organization have that competitors cannot easily replicate? This could be years of customer behavior on your platform, domain-specific labeled datasets, internal knowledge that has never been formalized, workflow telemetry, or transactional patterns specific to your business model. The more specific and harder to reproduce, the more strategically valuable it is as AI input.
Workflows and context. A general-purpose model has no knowledge of your internal processes, your terminology, or your business logic. Your competitive opportunity is in applying AI within workflows that have been shaped by your domain expertise and operational reality. The workflow itself is where differentiation lives. A better model applied to the same generic workflow as your competitor is not much of an advantage.
The model is available to everyone. What feeds it is not.
Identify Problems That Are Specific to You
Proprietary assets only create advantage when they are pointed at the right problems. That requires looking inward: at your users, your application, and the workflows your product creates.
Finding these problems requires discovery work. Understanding what your users are actually trying to accomplish, where they get stuck, what they are working around, and what would meaningfully change their experience or outcome. User research, workflow observation, and support data are often better starting points for an AI strategy than a list of available AI features.
Three filters worth applying:
Industry-specific problems. What problems in your industry are shaped by constraints, failure modes, or definitions of success that general-purpose tools are not built around? Every industry has its own version of this: the operational realities, the ways things go wrong, and the standards that define a good outcome. A tool with no knowledge of your industry context cannot navigate those. You can.
Application-specific problems. What problems exist within your product that no one outside your application would encounter? These problems surface from your specific workflows, your user interactions, and the gaps between what your product enables and what users are trying to do with it. Because they emerge from your product, the data and context needed to solve them exists only with you.
User-specific problems. What do your users want to accomplish that the current experience makes difficult or impossible? These are problems defined by the gap between what users are trying to achieve and what your product currently allows them to do. Understanding them requires talking to users directly. Intent does not always show up in usage data.
From Current Workflow to What Users Actually Need
Once you have identified what users are trying to accomplish and where the current experience falls short, the question becomes what AI makes possible within that gap that was not practical before.
Most workflows contain steps that exist not because they serve the user, but because the tools and processes available today require them. Manual handoffs, repeated context-setting, information retrieved from one place to enter into another, judgment calls that are time-consuming but not genuinely complex. Users work around these constraints because they have no choice.
The productive question is not “how do we make the current experience faster?” It is “if users were not constrained by what exists today, how would they prefer to accomplish this?” That reframe often reveals that the goal is not to streamline the current workflow but to collapse it: to remove the steps that only exist because AI was not previously available to handle them.
What you can deliver through that transformation depends on what you bring to it. Your proprietary data, your domain context, and your understanding of what users are actually trying to accomplish are what make the outcome possible in a specific way. A competitor cannot replicate it by purchasing the same model. They would need the same assets, the same problem understanding, and the same depth of user knowledge.
Match Your Implementation Approach to the Risk Level
Not all AI applications carry the same risk, and treating them the same way is a mistake in both directions. Moving cautiously on low-risk applications wastes momentum and cedes ground to competitors who will not wait. Moving quickly on high-risk ones creates real exposure that can set you back further than moving slowly would have.
A practical way to think about this:
Low risk means the stakes of a wrong output are low, a human naturally reviews the output anyway, or the failure mode is visible and easily corrected. These are the right places to prototype aggressively, move fast, and learn from real usage. Think: drafting a first pass, summarizing internal documents, suggesting tags or categories. Ship it, watch it, iterate.
Medium risk means errors have real consequences but are catchable before they cause harm. Here, human-in-the-loop design is not a crutch but a feature. Build explicit review steps into the workflow. Use AI to accelerate human judgment, not replace it. Set up guardrails that surface low-confidence outputs for human review. Preserve the data you need to audit decisions if questions arise later.
High risk means errors are costly, difficult to reverse, or highly visible to customers or regulators. In these areas, move deliberately. Start with narrow scope. Build observability before you build capability. Validate outputs against known-good ground truth before any real-world deployment. The goal is not to avoid these areas permanently; it is to earn the right to operate in them by demonstrating you understand where the model can go wrong.
Where to Start
For most organizations, the right starting point is the intersection of two things: problems that are specific to you, and applications that carry low risk. That intersection is where you can move fast enough to build momentum, build something specific enough to actually work, and limit exposure enough that the cost of being wrong is manageable. Early wins in that zone create the data, the organizational confidence, and the learned intuition to take on more complex applications later.
The trap to avoid is starting with the most impressive-sounding use case rather than the most tractable one. A narrow, well-defined AI application that genuinely solves a real user problem in your specific context is worth more than an ambitious pilot that stalls in proof of concept because the data was not ready or the problem turned out to be harder to define than expected.
Start specific. Start low risk. Build something only you could have built.
