Start with a business constraint, not a technology theme
“We need generative AI” is not a strategy. “Our claims cycle time is too slow because specialists spend hours assembling case context” is a strategy input. The second statement names a constraint, an owner, and a way to know whether the work succeeded.
Executives should begin with two or three constraints that already have sponsorship: a cost problem, a service-level problem, a risk problem, or a growth bottleneck that data and process already touch. If no senior owner is willing to change the process, the use case is not ready.
Use a simple filter before architecture debates
Every candidate use case should be able to answer five questions. If it cannot, it belongs on a later list.
- What decision or workflow will change?
- What data is required, and is it accessible under current controls?
- What is the cost of being wrong, and who approves the output?
- How will success be measured in 90 days and in 12 months?
- Which team will operate the system after the project team leaves?
This filter is intentionally unromantic. It protects the organization from funding ideas that cannot survive contact with production.
Build the first path to production on purpose
The first use case has two jobs. It must create a business result, and it must create a reusable path: identity, data access, evaluation, monitoring, and a support model. If the first project is treated only as a local win, the second project starts from zero again.
Choose a use case that teaches the organization
The ideal first project is important enough to attract attention and contained enough to finish. Internal operations, knowledge retrieval, and assisted case preparation are often better teachers than a public-facing moonshot.
Put governance in the path, not in a parallel committee
Security, legal, and risk teams should see the design early. A review that begins after a prototype is complete creates delay and political friction. The strategy should state what is allowed in a first release, what requires human approval, and what data classes are out of scope.
Strategy is a portfolio with different time horizons
Not every AI investment should pay back in a quarter. Some work is foundational: data contracts, cloud identity, evaluation harnesses, and operating procedures. Some work is tactical: a specific process that can be improved now. A coherent strategy keeps both visible so the foundation is not starved and the tactics are not endless experiments.
Business owners, CTOs, and CIOs do not need a more complicated framework than that. They need the discipline to start with one constraint, fund a production path, and refuse to confuse activity with capability. That is where an enterprise AI strategy should begin.