There is a version of AI strategy that gets commissioned at the enterprise level, runs for four months, involves every function, and produces a document with a vision statement, a set of guiding principles, a maturity model, and a heat map of opportunity areas.
It is not useless. It aligns a leadership team, it gives the board something to look at, and it usually surfaces two or three genuinely good ideas.
What it rarely produces is a decision that anyone below the executive layer can act on. The scope is too wide for the recommendations to be specific, and specificity is the whole point.
Why breadth dilutes the recommendation
A recommendation is only as strong as the constraints it accounts for. Constraints are local. The data available to claims operations is not the data available to marketing. The regulatory posture of a client-facing function is not the posture of an internal reporting team. The tolerance for an imperfect output in a drafting task is nothing like the tolerance in a calculation that feeds a filing.
When a strategy has to cover all of those at once, every recommendation it makes has to be true across all of them. What survives that filter is principle, not direction. “Establish clear ownership for AI use cases.” “Prioritize use cases with measurable value.” “Invest in data readiness.”
Nobody disagrees with any of it. Nobody can start on Monday because of it either.
Scope the same exercise to one function and the constraints become knowable. Now a recommendation can name the workflow, the tool, the data it touches, the review step, the person who owns the output, and the thing that will be true in eight weeks that is not true today.
The argument for going narrow first
Three practical reasons, beyond the specificity point.
The evidence transfers, the strategy does not. A department that has actually changed a workflow has produced something enormously more useful than a strategy document: a real account of what the change cost, what resistance looked like, where the data was worse than expected, and what the output is worth. That account is what makes the second and third department move faster. A strategy written before anyone has done the work has no such account to draw on.
Decision rights are simpler. Inside one function, the person who owns the process, the person who owns the budget, and the person who owns the outcome are frequently the same person or sit within one or two reporting lines. Cross-functional AI initiatives spend a large share of their calendar time resolving who gets to decide. That time is not wasted, exactly, but it is not progress either, and it is worth deferring until there is something concrete to decide about.
Failure stays proportionate. If a narrow effort turns out to be wrong, the organization has lost a quarter in one function. If an enterprise-wide program built on an untested assumption turns out to be wrong, the correction is expensive and public, and it tends to make the next attempt harder to fund.
How to draw the boundary
Not every function is a good first candidate. The ones that work tend to share four properties.
A process that runs often enough to measure. Something that happens weekly gives you a signal in a month. Something that happens quarterly does not tell you much before the strategy has to be refreshed anyway.
A recognized problem, not just an available tool. The strongest starting points are places where the team already complains about something specific. The work then has a baseline and a group of people who want it to succeed. Starting from “we have licenses, where should we use them” inverts that and produces adoption problems later.
Data that already exists in some form. Not clean data, and not well-governed data. Existing data. The gap between messy and usable is a project. The gap between absent and existing is a much larger one, and it is not an AI project.
A leader who will actually make decisions. The single largest determinant of whether this kind of work lands. A function whose leader will engage with a recommendation, push back on it, and then commit, will get somewhere. A function whose leader wants to be shown options and then escalate every one of them will not.
What the narrow version still has to include
Going narrow is not an excuse to ignore the enterprise. Two things have to be carried even in a single-function engagement.
The first is the constraints that are genuinely enterprise-level: model usage policy, vendor terms, data classification rules, and whatever the risk and compliance functions have already decided or are in the process of deciding. Discovering these late is the most common way a promising departmental effort gets stopped after it has already spent its credibility.
The second is a deliberate note on what would and would not transfer. When the work succeeds and someone asks whether the next function can copy it, the answer needs more nuance than yes or no. Some of what made it work was the tooling. Some of it was the specific data. A meaningful amount of it was that one manager spent time reworking how her team reviews output. Distinguishing those in advance is what makes the second attempt faster rather than merely more confident.
The enterprise strategy comes second
None of this is an argument against enterprise AI strategy. It is an argument about order.
An enterprise strategy written after two or three functions have done real work is a substantially different document. It can name what the organization has learned about its own data, its own review appetite, its own adoption behavior, and its own vendors. Its principles are derived from evidence rather than from a framework.
Written first, it is a set of reasonable-sounding intentions. Written second, it is a synthesis. The second one is worth commissioning.
Where Velnoro fits
Velnoro engagements are scoped to a specific part of the business rather than to an organization-wide mandate. The work establishes what is actually going on in that area, lays out the realistic options with a recommendation and the reasoning attached, and produces a plan that names the sequence, the owners, and the effort.
The category stays narrow. The diagnosis does not: the business, process, technology, and adoption sides of the problem all get looked at, because a recommendation that ignores any one of them tends not to survive contact with the team that has to run it.