AI-enabled work increases the number of situations in which teams must make decisions under uncertainty. A model can generate an answer without explaining every internal step, an agent can call tools that change business data, and an automation can scale a mistake faster than a person could. ITIL Version 5 is explicitly designed for this environment, but its value comes from applying management principles to the operating system around AI rather than treating AI as a special technology that sits outside governance.
As of September 28, 2026, PeopleCert describes ITIL Foundation (Version 5) as AI-aware and focused on digital product and service management, measurable value, lifecycle thinking, continual improvement, and better decision-making in modern digital environments. The ITIL certifications pathway expands that foundation into product, service, experience, strategy, transformation, and AI-related guidance. The practical question for teams is how to use those ideas when AI introduces speed, variability, and new control requirements.
The safest approach is neither “automate everything” nor “require human approval for everything.” Both extremes can destroy value. Instead, teams should connect AI decisions to outcomes, experience, risk, data quality, governance, human accountability, and feedback. The framework’s principles and Value System help make those trade-offs visible.
Start with the value and experience the AI-enabled work should create
An AI initiative should begin with a clear outcome, not with a model capability looking for a use case. A service desk agent might reduce time spent summarizing tickets, help route work, draft responses, or automate low-risk requests. Each use case creates different value and different risk. Measuring only “percentage automated” can reward behavior that frustrates users or moves work to a hidden manual queue.
Value should therefore be described in outcome terms: shorter time to resolution, fewer handoffs, better first-contact accuracy, improved accessibility, lower analyst toil, reduced backlog, or more consistent decisions. Experience belongs in the definition because users may reject an automated interaction that is technically correct but opaque, repetitive, or unable to handle exceptions.
This framing changes design decisions. A team optimizing for trustworthy resolution may choose a slower human escalation path for ambiguous identity cases rather than forcing the agent to guess. That is not a failure of automation; it is a value decision based on the real service outcome.
Use governance to define where autonomy begins and ends
AI needs decision boundaries. Governance should define which actions can be taken automatically, which require validation, which require approval, and which are prohibited. These boundaries should be tied to impact rather than the novelty of the technology. Drafting a knowledge summary has a different risk profile from changing a payroll record or disabling a user account.
Decision rights should be explicit enough that designers can implement them. A policy such as “use AI responsibly” is too vague to operate. A stronger rule might allow an agent to classify incoming requests and retrieve approved knowledge, require human approval before changing entitlements, prohibit use of unapproved external data, and require trace data for every tool action. The control can then be tested.
Governance also defines accountability. A model does not become the accountable owner of a business outcome. Product owners, service owners, risk owners, and operational teams still need clear responsibility for how AI is selected, configured, monitored, and improved.
Treat AI as part of a value stream, not an isolated assistant
An AI component sits inside a wider flow of work. Before automation, map how the work moves from trigger to outcome: who provides input, what systems are involved, which decisions occur, where exceptions appear, and how completion is verified. This exposes whether AI is addressing the actual constraint or merely accelerating one step while the rest of the value stream remains slow.
For example, summarizing an incident in seconds does not create much value if the request then waits six hours for ownership because the routing model is weak. Automating document extraction does not help if a downstream approval requires data the document never contains. Value-stream thinking directs AI investment toward the real bottleneck.
It also reveals where humans contribute unique value. Human review is most useful at ambiguity, high-impact judgment, exception handling, policy interpretation, relationship-sensitive communication, or irreversible actions. Keeping people in those points can improve both control and experience without forcing a person to repeat deterministic work that automation handles well.
Data quality and privacy are operating constraints, not afterthoughts
AI output quality depends heavily on the information supplied to the model or agent. Teams should know which data sources are authoritative, how current they are, whether retrieval is filtered correctly, and what happens when data is missing or contradictory. A confident answer from stale knowledge can be more damaging than an explicit “I do not know.”
Privacy is part of that data design. Sensitive information should be minimized, access should follow business need, and prompts or tool calls should not expose data simply because a model technically accepts it. Protecting personal data in AI systems provides additional context for PII handling and data-minimization concerns.
Data controls also need lifecycle ownership. Someone must maintain the source, correct bad content, revoke obsolete access, and verify that a retrieval index or knowledge base actually reflects approved policy. Without that operational responsibility, a well-tested agent can become less reliable over time as its environment changes.
Automate intelligently by separating probabilistic and deterministic work
Generative AI is useful when the task involves language, classification, synthesis, flexible reasoning, or ambiguous input. Deterministic automation is usually better when the rule is exact and repeatable: calculate a threshold, validate a schema, enforce a policy, or execute a known transaction. Strong AI-enabled workflows combine the two instead of forcing every step through a model.
A practical pattern is to let an AI component interpret a request, select a known action, and produce structured parameters, while deterministic logic validates the parameters and enforces allowed ranges before execution. This reduces the chance that fluent model output bypasses business rules. It also makes failures easier to diagnose because the reasoning stage and control stage are visible separately.
This separation supports auditability. Teams can review which model decision led to a tool call, which deterministic checks ran, what data changed, and whether a human intervened. That evidence becomes part of operating the service rather than a debugging artifact collected only after an incident.
Design for learning and adaptation instead of assuming a finished model
AI-enabled services change even when the code around them does not. User behavior evolves, business terminology changes, policies are revised, new data enters the system, and model providers update capabilities. An initial evaluation therefore cannot prove permanent reliability. The operating model needs ongoing evaluation, feedback, and controlled change.
Useful signals include task success, escalation rate, tool failure, unsupported-answer rate, correction frequency, user abandonment, policy violations, latency, and cost. Qualitative review remains important because a numeric success score may hide undesirable behavior. Teams should sample outputs and investigate patterns in failures, not just track averages.
Continual improvement turns those observations into changes. A high escalation rate might indicate poor instructions, missing context, or an appropriately conservative risk threshold. The correct response depends on evidence. Reducing escalations blindly could make the service less safe; increasing them blindly could destroy the value proposition.
Keep transparency proportional to the decision and audience
Users do not need a technical explanation of every model token, but they often need to know when they are interacting with automation, what the system can do, which information it uses, and how to reach a person. Higher-impact decisions need stronger explanation and evidence. Internal operators also need traces detailed enough to reconstruct failures and understand tool use.
Transparency should therefore be designed for multiple audiences. Users need clear expectations and escalation options. Operators need observability. Risk and audit teams need evidence that controls were applied. Product teams need performance and experience data. Executives need outcome and risk reporting. A single dashboard rarely satisfies all of those needs.
This is one reason ITIL’s product, service, experience, and governance perspectives matter together. Transparency is not only a compliance feature; it shapes trust, supportability, and the organization’s ability to improve the AI-enabled service.
Use scenario-based risk decisions rather than generic fear or hype
AI discussions often become polarized between optimistic productivity claims and lists of catastrophic risks. A better operational approach is scenario-based. Identify the specific decision, data, action, stakeholder, failure mode, and recovery path. Then design controls that match the actual impact. AI risks and challenges can help broaden the threat discussion, but the service team still needs to translate broad concerns into concrete operating controls.
For a low-risk drafting assistant, reviewable output and data boundaries may be enough. For an agent that can update customer records, tool permissions, validation rules, approval thresholds, and rollback mechanisms become more important. For regulated decisions, teams may determine that the model should support a human rather than make the decision directly.
This proportional approach prevents two common failures: under-governing high-impact automation and over-governing low-risk assistance until no value remains. ITIL principles help keep both value and control in view.
Prepare for Foundation by connecting principles to operating choices
For Foundation study, do not reduce AI to a list of new technologies. Take a scenario such as an AI service desk assistant and ask how value, experience, governance, value streams, practices, information, suppliers, and continual improvement influence the design. That demonstrates the holistic thinking the current framework emphasizes.
Also practice distinguishing a principle from a control. A principle guides judgment; a control implements a specific boundary. “Focus on value and experience” is a decision orientation. “Require human approval for account deletion” is an operational control. “Review tool-call traces weekly” is a monitoring activity. Confusing those layers makes AI governance sound either too abstract or too mechanical.
The durable lesson is that responsible AI-enabled work remains management work. The technology changes the speed and uncertainty of decisions, but organizations still need clear outcomes, accountable owners, controlled value streams, capable practices, reliable information, stakeholder trust, and evidence-driven improvement.