An enterprise AI strategy earns its value by making investment choices coherent.
Across my strategy and governance work, the recurring challenge has been connecting decisions that different groups make separately. A business team identifies an opportunity. Technology considers platforms. Security examines access. Finance asks about returns. People leaders plan learning. Each perspective is necessary, and their choices need to work together.
The starting point is the organization's strategy. What must improve for customers? Where does the business need to grow, become more resilient, or operate differently? Which capabilities make it distinctive? AI priorities should express those choices clearly enough that leaders can explain why one opportunity deserves resources ahead of another.
An objective such as improving customer retention creates a more useful conversation than increasing AI adoption. It opens several possible approaches: improving service, identifying recurring friction, helping employees make better decisions, or changing an offering. AI may contribute to any of them. The business outcome provides the basis for comparison.
It also creates room for both efficiency and opportunity. An enterprise needs to improve familiar work while examining how changing capabilities may alter customer expectations, competitive advantage, or the services it can offer. A portfolio that includes both can make these different ambitions visible and fund them appropriately.
The human-centered part belongs at the beginning. Understand the work as people experience it, including informal coordination, exceptions, and judgment that process diagrams omit. Ask who will benefit, whose workload may increase, and what employees need in order to use the new capability effectively.
Include the customer in that examination. A feature that is technically impressive may introduce friction into an experience people already value. The proposed improvement should be recognizable to its intended beneficiary.
Architecture provides the next set of choices. In my strategy outline, I separated systems of record, organizational context, and AI touchpoints. That remains a useful way to ask where information lives, which sources are authoritative, and how AI will interact with them.
An enterprise should be able to explain how a system gets the information it needs, how access follows the user's or agent's role, where outputs go, and how activity can be inspected. It also needs a way to keep business rules and context current. A capable model working with stale guidance can be consistently wrong in a very polished way.
Build, buy, and partner decisions follow from the capability required. Buying can be appropriate when an established product meets the need and fits the operating environment. Building can make sense where distinctive workflows, knowledge, or customer experience justify sustained ownership. A partner can provide expertise or capacity the organization needs to develop.
These choices include obligations after delivery. Who maintains the solution, handles incidents, evaluates changes, and owns the knowledge needed to operate it? A partner arrangement should be explicit about those responsibilities and about how the organization retains the ability to change direction.
Model and platform selection deserve the same discipline. Evaluate representative work, including difficult cases. Consider output quality, access controls, integration, response time, operating cost, observability, and the ability to recover from failure. The most capable model on a general benchmark may not provide the best fit for a particular business process.
A platform decision has wider consequences than a model decision. It can shape identity, information access, monitoring, development practices, and future switching costs. Leaders should know which elements they are standardizing and where variation is justified. Too much fragmentation creates duplication; premature uniformity can exclude useful approaches.
The pilot should resolve a decision. State what is uncertain, what evidence the test will produce, and what would justify expansion. That could involve performance on representative work, employee ability to use the system, integration reliability, or the economics of operating it at the intended volume.
A successful demonstration is only part of that evidence. Scaling requires an accountable business owner, service ownership, support capacity, appropriate data access, quality controls, and a credible benefit. It may also require changing roles and handoffs that the pilot bypassed through extraordinary attention from a small team.
Funding should reflect these differences. An exploratory experiment, a broadly available productivity tool, and a critical production workflow do not need identical business cases. They do need explicit purposes, cost visibility, and decisions about when to continue or stop.
The strategy should also preserve options. Document why a platform was selected, which assumptions underpin the business case, and which changes would trigger a review. Keep organizational knowledge usable beyond a single application where practical. The ability to revise a decision is valuable when both business needs and technology are evolving.
I would bring these choices together in one leadership conversation: the outcomes we seek, the people and workflows affected, the shared foundations we need, the responsibilities we will retain, and the evidence required to scale. Where does your current AI strategy make those choices explicit—and where are teams still making them independently?