AI strategy
A governed enterprise AI strategy connects business decisions, service outcomes, data boundaries, security, human oversight, delivery ownership, and evidence. It gives an organisation a way to choose useful work without treating every model or agent idea as a production commitment.
Describe the decision or service step AI is expected to support, who owns the outcome, what happens when the output is wrong, and which human remains accountable. A use case should be understandable before its technology is selected.
The AI consulting and implementation route provides an internal path when strategy must become a delivery decision.
Identify data sources, permitted use, access roles, retention responsibilities, sensitive fields, external actions, and escalation conditions. Separate an AI suggestion from an automated action that changes a record or affects a person.
Review data quality, workflow fit, integration needs, testing, support ownership, user change, and failure handling. Sequence work according to readiness and consequence, not novelty alone.
Define evaluation questions, human checkpoints, audit records, exception signals, and decision owners. Evidence should show what was tested, approved, uncertain, and challenged.
Connect each measure to an operating decision. Do not call activity a business result without a documented definition, source, owner, and review action.
An AI strategy does not need to cover every department at once. It needs a coherent boundary, decision rights, and a sequence that can be reviewed.
The business or service owner remains accountable for the outcome. Platform, data, security, and delivery teams own their defined controls and enabling responsibilities.
An AI strategy is mostly a set of decisions about where effort goes, what waits and who has authority to change course. For a leadership team the useful question is rarely which model to adopt. It is which decisions in the operation would be better informed by a model, and which of those can be handled safely in the next planning cycle. A workshop that produces forty ideas is common. It becomes a strategy only when each idea is scored against the same criteria and the leading few have an owner who can be held to account for the result.
Four questions do most of the sorting. Is the decision frequent enough that a better answer changes outcomes in a way the business can see? Is the input available, lawful to use and of acceptable quality? Can a person check the output at the speed the process allows? And if the output is wrong, is the damage small enough to correct afterwards? An idea that fails the first question may still be worth doing for convenience, but it should not be funded as a strategic priority. An idea that fails the last question, where a wrong output triggers a customer-facing or financial change with no review, needs stronger controls before it is considered at all.
| Candidate use case | Decision it supports | Main readiness question | Typical sequencing position |
|---|---|---|---|
| Drafting a reply that an agent reviews before sending | Which response goes to the requester | Whether approved reply wording and templates already exist | Early, because a reviewer is already in the loop |
| Ranking incoming requests by likely effort | Which request to take first | Whether past effort records are consistent enough to learn from | Early if the records are clean, later if they are not |
| Recommending a change to a record automatically | Whether the record should change | Whether every change can be traced and reversed | Late, after review and audit paths are proven |
| Scoring a decision that affects someone's access or benefits | Whether to approve or refuse | Whether the decision is lawful, explainable and open to appeal | Needs separate governance before any design work begins |
Decision rights are the part of a strategy that teams most often leave vague. Someone must own the business outcome. Someone must own the data the model reads. Someone must own the security posture of the tool, and someone must own the delivery plan. These roles often sit in different functions. The strategy should name each role and state what that role may approve alone, what needs a joint decision and what must go to a leadership forum. A common failure is that a business sponsor approves a pilot, a technology team builds it, and nobody holds the authority to stop it when its results disappoint. Writing down the stop authority at the outset costs little and protects the program from drifting on momentum.
Sequencing is a judgment about readiness and consequence. A reasonable pattern begins with a use case where the output is advisory, a reviewer is already present and the input is well understood. That first piece of work builds the habits that later, riskier work depends on: evaluation against known cases, logging of what the tool produced, and a change process for updating prompts, data sources or thresholds. The next stage addresses use cases that touch more systems, which brings integration testing, access design and support ownership into scope. The final stage handles automated actions and decisions that affect people. Teams that jump straight to the final stage often spend the following year rebuilding the foundations they skipped.
Equally important is knowing what to pause. A use case should be paused rather than quietly dropped when its input data degrades, when the process it supports changes, or when reviewers report that the output is no longer usable. A pause with a stated reason and a review date keeps the portfolio honest and makes it possible to restart the work without starting the argument again.
A portfolio review every few weeks is usually enough during the first year. The review should cover which use cases moved stage and why, which evaluation results changed, which challenged outputs or incidents occurred, and which assumptions no longer hold. The meeting should not be a status report. Its purpose is to take a decision on each active item: continue, change scope, pause or stop. Items that have sat in the same state for several cycles deserve a direct question about whether they still earn their place.
| Operating decision | Who should decide | Evidence the decision should rest on |
|---|---|---|
| Move a use case to the next stage | Business owner, with the risk owner's agreement | Evaluation results against agreed acceptance conditions, and no open incident on the current stage |
| Expand a use case to more users or systems | Business owner and the platform or security owner | Access design reviewed, integration tested, support route named |
| Pause a use case | Business owner, on advice from the reviewer | Degraded input, changed process or reviewers reporting unusable output |
| Stop a use case | Leadership forum, recorded with its reason | Repeated failure against acceptance conditions or a changed legal position |
Activity measures such as the number of drafts generated or documents processed are easy to collect and easy to misread. A useful measure connects to a decision the business already makes. For a triage use case, the question is whether requests reach the right queue sooner and whether reassignments fall. For an advisory tool, the question is whether reviewers accept, edit or reject outputs at a rate that tells the team something about quality. Each measure needs a written definition, a data source, a named owner and a review action attached to it. If a measure cannot change a decision, it is reporting, and it should be labeled as reporting rather than presented as a business result.
A strategy should end with a short list of approved use cases, their owners, their boundaries and the evidence each one must produce before it moves on. It should not contain a technical design for each use case. That belongs in the delivery plan, which should refer to the boundary decisions rather than reopen them. When a delivery team finds that a boundary cannot be met, the change should go back through the same decision forum rather than being settled inside the project. Organizations that keep this line clear tend to avoid two common problems: a strategy document nobody can act on, and a project that quietly redefines the strategy without anyone deciding to.
The AI governance controls page covers approved use, data access, human oversight, evaluation and audit evidence, which is where boundaries agreed in a strategy become operating rules. The CMDB, CSDM and ITAM page is relevant when a use case depends on records that describe the estate accurately, and the AI engineering delivery capacity page is relevant when the decisions are settled and the question becomes who builds and maintains the work.
No. A strategy needs a coherent boundary, clear decision rights and a sequence that leadership can review. Starting with two or three functions where the decisions are well understood usually produces better evidence than a whole-company plan written before any use case has been tested.
A named executive should own it, because the trade-offs involve business priorities, risk appetite and budget. The technical leads contribute feasibility and constraints, but the sequencing and stop decisions belong to the people who carry the business consequence.
Revise it when evidence changes, not on a fixed calendar alone. A new data source, a material incident, a change in regulation or a failed evaluation are all reasons to reopen the sequence. Otherwise a quarterly review is enough to confirm that the order still reflects readiness.
Record it with its prerequisites. The idea may be sound but depend on data cleanup, a new integration or a control that does not yet exist. Recording those dependencies turns a rejected idea into a planned one with a clear trigger for revisiting it.
If your leadership team has a list of AI ideas but no agreed rule for choosing between them, the useful first step is a working session that scores the candidates, names the decision owners and sets the stop authority. You can discuss your AI use-case priorities to start that conversation. If the list already exists and the open question is which services would deliver the top items, the AI and ML services page describes the service routes.
Bring the AI priority, data boundary, or delivery decision that needs an accountable operating model.
Discuss governed AI strategyGuides from the Oblytech ServiceNow library that explain the practice behind this page.