An AI strategy is a set of choices about where artificial intelligence should change the business, what role it should play, and what evidence must exist before the company invests further. It is not a list of AI projects. It is also not a technology roadmap with the word AI added to the title.
I have watched companies repeat the same pattern across analytics, automation, cloud, ERP and now generative AI. A new capability appears, leaders ask every function to find use cases, and a long idea list quickly becomes the strategy. The list creates motion. However, it rarely settles which business problems deserve funding, which workflows must change, who remains accountable, or when an experiment should stop.
The pressure is understandable. Boards want an AI position. Employees are already using public tools. Vendors can demonstrate polished results in minutes. Competitors announce new assistants and agents. Waiting carries a cost, but hurried investment carries one too. A company can spend heavily, create dozens of pilots and still build very little that changes revenue, cost, risk or service.
My view comes from years of leading data, analytics, AI, SAP, engineering, governance and transformation work across complex business environments. The recent experiments on this site are public examples readers can inspect. They reinforce some of those views and challenge others, but they are not the source of my professional experience.
This article explains the AI strategy framework I would use with business and technology leaders. It connects business outcomes, workflow redesign, the division of work between AI and people, the operating model, controls and measurable value. You will also find a one-page decision canvas that can be used in an actual investment discussion.
Why an AI strategy is different from an AI project list
A project list answers, “What could we build?” A strategy answers harder questions: Where do we intend to win or improve? Which constraints will we accept? What will we stop doing? How much evidence is required before more money is committed?
Think about AI strategy as capital allocation with an operating model attached. The organization has limited funding, scarce business attention, finite data capacity and only so much tolerance for change. Every selected use case consumes some of each. Therefore, approving a weak idea also delays a stronger one.
This distinction matters because AI can look convincing before it is useful. A model may summarize a policy beautifully but miss the exception that creates financial exposure. An agent may complete a test workflow but fail when source data changes. A prediction may be statistically accurate yet arrive too late for anyone to act. The demonstration is not the business result.
Earlier waves of analytics often began with structured data, defined measures and a known decision. Generative AI expanded the range of possible inputs and outputs. It can work with language, images, documents and code, while agentic systems can select tools and take multi-step actions. As capability expands, the strategy question grows from “Can the model predict?” to “What authority should the system have, and how will the organization know when its actions are wrong?”
A familiar analogy is hiring. A leader would not hire 50 people because each candidate demonstrated an interesting skill. The leader begins with work that needs to be done, defines roles, assigns authority, decides how performance will be measured and creates supervision suited to the risk. AI investment deserves the same management discipline.
The six connected choices in an AI strategy framework
A useful AI strategy keeps six choices connected, and a weakness in one can invalidate the rest. A valuable business outcome without an executable workflow remains an ambition. Even a capable model remains a prototype without an accountable operating owner. Once in production, a system without evidence of value becomes permanent cost.
The following model is intentionally compact. Its purpose is to make gaps visible before a steering committee approves funding.
| AI strategy choice | Decision leaders must make | Evidence to request |
|---|---|---|
| Business outcome | Which revenue, cost, risk or service result should change? | Baseline, target, economic value and accountable sponsor |
| Workflow | Which decision or task will change, and for whom? | Current process, delays, exception paths and user behavior |
| AI role | Will AI advise, draft, predict, decide or act? | Task boundaries, expected outputs and retained human authority |
| Operating model | Who owns the product, data, adoption, risk and service? | Decision rights, funding model, skills and support process |
| Controls | What access, review, monitoring and escalation fit the risk? | Failure modes, control tests, override path and incident response |
| Value | What proof justifies the next investment? | Measured change against baseline, adoption and full operating cost |
Many plans discuss all six topics somewhere. The problem is that they are handled by separate teams at separate times. Strategy chooses the outcome, a lab selects the model, IT designs the platform, Legal reviews risk, and Finance asks about value near the end. By then, the architecture and expectations may be expensive to change.
The better discipline is to place the choices in the same conversation. A higher level of AI autonomy changes the required controls. Weak data changes which workflow can be attempted. A slow review process changes the likely value. These are connected design decisions.
Choice 1: Start the AI strategy with a business outcome
“Use generative AI in Finance” is not an outcome. “Reduce the time required to resolve invoice exceptions without increasing duplicate payments” is much closer. It identifies a workflow, speed objective and risk boundary.
I ask leaders to state four things before discussing a model:
- The business measure that should change
- The current baseline and economic consequence
- The person accountable for the result
- The period in which evidence should appear
If no baseline exists, the first investment may be measurement rather than AI. That is not delay for its own sake. Without a baseline, almost any pilot can be described as successful because nobody can show what improved.
Outcome selection also requires saying no. High-volume work is not automatically valuable. Expensive work is not automatically suitable for AI. I prefer problems where better speed, consistency or decision quality matters, the result can be measured, and people can act on the output.
Choice 2: Redesign the workflow, not only the task
AI value often disappears in the handoffs around the model. A system may classify an invoice exception in seconds, but the case still waits two days for an email response. Meanwhile, a customer-service assistant may draft a useful answer while the agent must copy it across three systems. Forecast accuracy might improve, yet planners cannot see why the recommendation changed.
Map the current workflow from trigger to business result. Record queues, decisions, rework, controls, exceptions and handoffs. Then decide where AI changes the flow. The objective is not to automate every step. It is to improve the whole result.
For example, consider accounts payable invoice exceptions. An invoice arrives, the system attempts a purchase-order match, and a mismatch enters a queue. An analyst reviews the purchase order, receipt, invoice, vendor history and company policy. The analyst then requests information, recommends a resolution or escalates a possible duplicate.
An AI component could assemble the evidence, classify the exception and draft a recommendation. However, it should not be judged only on classification accuracy. The business should measure exception cycle time, analyst effort, duplicate-payment risk, avoidable escalations and supplier impact.
This is why I test AI in realistic business workflows rather than isolated prompts. In my AI for accounts payable experiment, the interesting question was not whether ChatGPT could read an invoice. It was whether it could apply matching rules consistently and expose the cases that still needed human review.
Choice 3: Define the role of AI and the role of people
The phrase “AI-powered process” hides the most important operating decision. What exactly is the AI allowed to do?
| AI role | Example | Human responsibility |
|---|---|---|
| Retrieve | Find the relevant policy and transaction evidence | Confirm that the sources are current and applicable |
| Draft | Prepare an exception summary or supplier message | Review, revise and approve communication |
| Recommend | Suggest a reason code and resolution path | Accept, reject or escalate the recommendation |
| Decide | Approve low-risk exceptions within defined limits | Set policy, monitor outcomes and handle cases outside limits |
| Act | Update a record or initiate a downstream transaction | Authorize boundaries, review logs and respond to incidents |
Each step increases the potential value and the consequence of error. A drafting assistant can waste time or create a misleading message. An agent with system access can alter data, contact a supplier or trigger payment activity. Controls should follow the authority granted, not the excitement surrounding the model.
Human review should also be designed, not added as a vague promise. Who reviews? What evidence will that person see? How much time do they have? Can they disagree easily? Where is the decision recorded? If every output receives a ceremonial click, the control creates cost without much protection.
Choice 4: Build an AI operating model that survives the pilot
A pilot can run through personal effort. Production cannot. Someone must own the business outcome, product backlog, source data, model or service, user adoption, risk decisions, incidents and operating cost.
The AI strategy should make those responsibilities explicit before scale. Otherwise, the project succeeds into an ownership dispute. The innovation team wants to move to the next experiment, IT receives a service it did not design, and the business assumes somebody else is monitoring quality.
I favor a product-oriented structure for material AI use cases. One accountable business product owner holds the outcome and priorities. Data, engineering, security, risk, legal and process experts contribute their authority. The model can be purchased or built, but accountability for the business result cannot be outsourced to a vendor.
This operating model must include adoption. A technically sound system creates no return if people avoid it, duplicate its work or do not trust its recommendations. Leaders should decide how roles change, which old steps will be removed, how feedback reaches the product team and how performance expectations will change.
The connection to data leadership is direct. Building a data team requires roles that connect engineering with decisions and adoption. AI increases that need because model behavior, business policy and workflow design must be managed together.
Choice 5: Put controls inside the AI strategy
Governance should shape the design before deployment. It should not appear as a late approval gate after the team has committed to an architecture and promised a launch date.
Begin with credible failure modes. Could the system expose restricted data, invent a policy, treat one customer group unfairly, approve an invalid transaction, follow a malicious instruction or continue operating after source quality falls? The answer determines access, testing, review, monitoring and escalation.
The control pattern should match the use case. A writing assistant using public marketing content does not need the same oversight as an agent changing supplier master data. Risk classification must consider data sensitivity, audience, decision consequence, reversibility and autonomy.
My AI governance framework goes deeper into the controls that should change as autonomy and business impact rise. The related data governance framework covers definitions, ownership, quality and decision rights for the data underneath the system. An AI strategy needs both disciplines because a well-controlled model can still fail on misunderstood data.
For free public guidance, the NIST AI Risk Management Framework organizes risk work around governing, mapping, measuring and managing AI risk. The OECD AI Principles provide another useful reference for trustworthy AI and responsible stewardship. These resources can inform policy, but each company still has to translate principles into workflow-level decisions.
Choice 6: Define value evidence before funding scale
AI economics are often described with a productivity estimate: minutes saved per task multiplied by transaction volume. That can be a useful starting hypothesis, but it is not a complete business case.
The calculation should include adoption, review effort, model and platform cost, integration, data preparation, monitoring, change management, exception handling and the cost of errors. It should also distinguish capacity released from cash removed. Saving 20 percent of an employee’s time does not automatically reduce cost by 20 percent. The value may instead appear as faster service, higher throughput or work that was previously deferred.
For the invoice example, a balanced value case could include:
| Value dimension | Baseline | Pilot measure | Guardrail |
|---|---|---|---|
| Speed | Median hours from exception creation to resolution | Change in cycle time for eligible cases | No increase in rushed incorrect resolutions |
| Effort | Analyst minutes by exception type | Net time after AI review and correction | Include escalation and rework time |
| Quality | Incorrect coding and reopened cases | Validated decision accuracy by risk tier | Zero tolerance for defined high-impact errors |
| Financial risk | Duplicate or improper payments | Detected and prevented exposure | Track false blocks that delay valid payments |
| Adoption | Current workflow usage | Eligible cases processed with the new workflow | Check for shadow processes outside the system |
Set the evidence threshold before the pilot starts. Otherwise, sponsors can move the goalposts after seeing an attractive demonstration. A threshold might require a measured cycle-time reduction, acceptable quality within each risk tier, sustained user adoption and a credible cost to operate at production volume.
Use evidence gates to decide when AI should scale
An AI strategy should treat funding as a sequence of evidence-based commitments. Early work buys information cheaply. Later work buys reliability, integration and adoption. The burden of proof should rise with the investment and operational exposure.
Explore: Is the problem worth solving?
Exploration tests feasibility and clarifies the business problem. It should be small, time-bound and honest about fictional versus real data. The output is a decision about whether a pilot deserves funding, not a claim that the solution is ready.
Pilot: Does it work with real data and real users?
A pilot tests quality, workflow fit, user behavior and likely economics in a controlled scope. It should include representative exceptions, not only easy cases. People who perform or depend on the work need to use the system, because their correction effort is part of the result.
Production: Can the organization operate it safely?
Production requires security, reliability, integration, monitoring, support, change control and incident response. Passing a pilot does not prove these capabilities. This stage often exposes costs hidden by manual support during the experiment.
Scale: Is the value repeatable?
Scale should follow measured value and a reusable capability. Reuse may include a shared platform, control pattern, data product, evaluation method or operating team. Copying an application without those foundations can multiply support cost faster than value.
The important decision at every gate is allowed to be “stop.” Stopping a weak pilot protects capital and attention. It is evidence that the portfolio process works, not proof that the team failed.
A practical AI strategy scorecard
Leaders do not need a 100-page plan to test whether an AI strategy is ready for investment. A short scorecard can expose most gaps.
| Question | Strong answer | Warning sign |
|---|---|---|
| What business result changes? | Named measure, baseline, target and sponsor | “Improve productivity” without a measurable workflow result |
| What work changes? | Mapped workflow, users, handoffs and exceptions | A model demo with no process redesign |
| What may AI do? | Clear task and authority boundaries | “Human in the loop” without a named reviewer or action |
| Who runs it? | Business owner and named product, data, risk and service roles | Temporary project team with no production owner |
| How can it fail? | Tested failure modes, controls and escalation | Generic responsible-AI principles with no workflow controls |
| Why invest again? | Evidence threshold and full cost by funding stage | Success declared from user enthusiasm or a polished response |
Download the one-page AI strategy decision canvas
I created a one-page canvas to bring these choices into a working session. Use it for one use case at a time. If several teams fill it out independently, compare their answers. Differences about the outcome, AI authority or accountable owner often reveal more than another presentation.
The canvas is deliberately one page. It should force decisions, not become another planning document that records every idea without choosing among them.
Common AI strategy mistakes I would challenge
Starting with a platform target
“Move every team to one AI platform” may be an architecture preference, but it is not a business strategy. Platform choices should follow use-case patterns, security needs, integration economics and the capabilities the organization intends to reuse.
Counting use cases as progress
A portfolio with 80 ideas can have less value than three production workflows. Track decisions, evidence and business results. Idea volume is mainly a measure of workshop activity.
Using one control model for every use case
Excess control makes low-risk work slow and expensive. Weak control makes high-impact automation dangerous. Classify the use case, then choose review, testing and access based on its consequence and autonomy.
Treating data problems as a later workstream
The pilot will reveal data problems, but that does not mean leaders should enter it blindly. Source ownership, grain, definitions, access, quality and feedback paths belong in the initial decision. My guide to data readiness for AI explains how to assess those conditions before model excitement hides them.
Assuming adoption will follow accuracy
People may reject a good recommendation because it arrives in the wrong tool, removes judgment they value, adds review work or conflicts with performance measures. Adoption is part of product design and management, not a communication task at the end.
Scaling before operating costs are visible
Prototype costs can exclude human support, evaluation, exception handling, integration and monitoring. Scale the economics only after those costs appear in a realistic operating test.
How this AI strategy connects to execution
This framework answers what the company will fund and why. The next layer is execution: sequencing capabilities, preparing data, selecting pilots, establishing governance, changing work and measuring return.
My complete AI ROI roadmap is the natural next read once the strategic choices are clear. It covers the path from readiness and use-case selection through pilots, adoption and value tracking. These two articles serve different purposes. Your AI strategy chooses the bets and constraints, while the roadmap turns those choices into an execution path.
For leaders responsible for the investment case, AI to ROI for Business Leaders book on Amazon develops the financial, operating and leadership decisions in more depth. The cost of waiting is not only that a competitor may move first. It is also that your organization may continue funding disconnected pilots while the few workflows capable of producing measurable value remain stuck in discussion.
An AI strategy is credible when it changes decisions. It tells teams which problems deserve exploration, what evidence earns further funding, how much authority AI receives, which controls apply and who owns the result after launch.
What are you trying to build with AI? Share the business workflow, the data involved and where the work is getting stuck in the comments. I am especially interested in cases where the demo looked strong but the operating model, controls or value case remained unresolved.