If I were leading an AI initiative today, I would start by assuming that the capability problem is already solved.
Not because any specific model is good enough for every use case.
Because the bottleneck is almost never the model.
The organizations I have seen do this well share a pattern. They spent less time on the technology than you would expect, and more time on the structural decisions that determine whether anything gets used. The organizations I have seen do this poorly made the opposite bet.
The first decision is scope, and most leaders make it too large.
Not "what should the AI do", which single decision should it support, where the cost of getting that decision wrong is already visible and already felt by someone.
Most initiatives start with a platform ambition. A horizontal capability. A set of use cases that would collectively justify the investment.
That framing almost always fails.
It creates too many stakeholders with different definitions of success. It spreads ownership across teams that do not naturally coordinate. It turns every decision into a committee negotiation.
Start with one decision. Make it matter. Then expand.
The instinct to start broad is partly organizational. It is easier to sell a platform than a feature. But breadth at the start is a liability, not an asset. The narrower the initial scope, the higher the chance of visible impact, and visible impact is the only thing that earns permission to expand.
The second decision is accountability, and this conversation is harder than it sounds.
Before anything is built, someone needs to be accountable for the decision the system will support. Not accountable for the project. Accountable for the outcome.
In practice, people are willing to be involved. They are less willing to be accountable.
When you push for clarity on this and find it genuinely difficult to get, that is signal. It means the decision itself is not fully owned: who makes it, who it affects, who has to live with the result. Solving the ownership question often surfaces everything else that is unclear about the problem.
If you cannot get a clean answer after a real push, the initiative is not ready to start.
The third decision is honesty about the data: not whether it exists, but whether it behaves.
Does it arrive when the decision is being made? Is it owned by a team with aligned incentives? Does it encode the same assumptions the system needs to act on?
I have seen teams proceed confidently on data that was technically available but practically unusable. It arrived at the wrong cadence. It was owned by a team that defined the metric differently. It reflected how decisions were reported, not how they were actually made.
The honest answer to the data question often changes the scope of the initiative. That is a good thing. Changing scope at the beginning costs almost nothing. Changing it in month six costs everything.
The fourth decision is evaluation, and it has to happen before the system is built.
What does "working" mean? Not at the model level. At the decision level.
If you cannot define what better looks like before you start, you will default to proxies afterward. Usage rates. Model accuracy. Time-to-action. These are measurable and defensible, and they correlate loosely with the thing you actually care about.
That is not measurement. It is reassurance.
Define the signal that would tell you the decision is improving. Accept that it will be slow to observe and hard to attribute cleanly. Build toward it anyway.
Beyond the framing decisions, the thing I believe most strongly is this:
Invest heavily in the first deployment.
Not because the first use case is the most important one. Because the first deployment sets the credibility of everything that follows.
If it works, if it gets used, if it produces visible improvement, if it handles failure gracefully, the next initiative starts from a different position. The ownership conversation is shorter. The data negotiation is less contested. The case for investment is already partially made.
If the first deployment is rough, the second initiative inherits a skepticism it should not have to overcome.
Most leaders treat the first deployment as a proof of concept. A test. Something to learn from before the real thing.
That framing is wrong.
The first deployment is the real thing. It determines whether there is a second.
Most AI initiatives fail before they fail.
The outcome is largely set in the first month, by framing decisions made quickly or not made at all. Scope that is too broad to own. Accountability that is distributed enough to disappear. Data assumptions that are optimistic enough to avoid confronting. Success metrics that are vague enough to feel safe.
By the time the model is in production, most of those decisions are locked in.
The capability is not what makes this hard.
The leadership decisions are.