I have been pondering, and continue to ponder, the role of IT in AI adoption and I think it’s about to change - especially in it’s relationship with frameworks like ITIL and COBIT. For a while, many organisations likely tried to keep AI away from being “just an IT thing” - rightly so (up to a point). If AI adoption is seen to start and end with IT, it can easily become another technology project looking for a business problem. The opposite is also risky - what happens when AI adoption grows up?

When people are experimenting with ChatGPT, Copilot, or other assistants, the governance model can be fairly lightweight. Some training, acceptable use guidance, privacy awareness, and sensible controls are enough to get started. As organisations move from individual use to copilots, coworkers, agents, and eventually more autonomous systems, the question changes.

It is no longer just, can we use AI?

It becomes, can we operate AI safely, reliably, and in line with the organisation’s needs and risk tolerance? That is where IT departments have a much bigger role to play.

What is it?

AI is increasingly becoming an enterprise IT capability, not only a tool or an innovation and productivity initiative - it’s becoming a capability, which matters. A capability needs ownership, support, lifecycle management, governance, security, change control, service expectations, risk management, vendor oversight, and ongoing improvement.

We are now in familiar territory for IT departments. Most mature IT organisations already have ways of thinking about this using frameworks such as ITIL and COBIT 2019. These frameworks are not AI frameworks in themselves, but they provide a well-established foundation for managing technology in a way the organisation can trust.

The AI maturity path I use has five broad stages:

• Assist: AI helps individuals perform tasks faster. This is where many organisations begin. People use assistants to draft content, summarise information, brainstorm ideas, analyse documents, or improve their own productivity.
• Augment: AI starts to improve decision-making and content creation in more structured ways. Copilots become embedded into workflows, functions, and business processes - AI has access to your corporate data (think Microsoft Copilot and Work IQ).
• Advise: AI starts supporting multi-step, human-in-the-loop work. This is where the idea of AI coworkers becomes more practical. The system is no longer only answering questions. It is helping progress work (think Microsoft Cowork).
• Act: Agents begin performing delegated tasks and actions. This is a different level of operational responsibility. The AI is not only producing information. It may be initiating workflow steps, updating records, triggering notifications, or interacting with other systems (this is where Microsoft Scout starts to be used or Copilot Studio Agents).
• Automate: Autonomous agents operate with limited human intervention. This does not mean humans disappear. It means the design, control, monitoring, and accountability expectations become much higher (code heavy, specific agents and multi-agent systems built around frameworks like Microsoft Agent Framework)

The important point is that the management system has to mature as the AI capability matures.

Early experimentation may lean heavily on knowledge management, service desk support, training, and continual improvement. More advanced use starts to involve service levels (and affect Disaster Recovery and Business Continuity), change enablement, requirements definition, solution identification, configuration management, operations, security, monitoring, event management, problem management, availability, continuity, benefits delivery, and performance measurement.

That sounds like a lot, but it is not new work for many IT departments, it is familiar work applied to a new class of technology.

What AI changes is the shape of the risk. Traditional systems tend to behave in more deterministic ways. Not perfectly, but predictably enough that organisations can usually define the process, test it, monitor it, and manage it.

• AI systems introduce more variability.
• They may summarise incorrectly.
• They may make recommendations that look plausible but need review.
• They may act on incomplete context.
• They may depend on data quality, prompt design, retrieval quality, model behaviour, vendor changes, permissions, and user behaviour.

In short - they act more like people.

That does not make them unusable but it does mean that they need to be managed properly.

What does it mean from a business perspective?

The business implication is not that IT should take AI away from the business (to be clear I do not like the classical distinction between ‘IT’ and ‘the business’ - we are all ‘the business’ - I am using it here to communicate a perspective). It is that AI needs the business and IT to work together more deliberately as adoption matures.

• AI value is created in the business process, not in the model itself. The useful question is not whether an organisation has deployed AI. The useful question is where AI improves real work. That might be customer service, finance, HR, procurement, operations, project delivery, reporting, research, or document-heavy back-office workflows. IT can provide the operating discipline, but the business still needs to define what useful, safe, and valuable actually means.
• The risk profile changes as AI moves closer to action. An assistant that helps someone draft an email is one thing. An agent that updates a service ticket, triggers a workflow, changes a record, or sends a communication is another. The closer AI gets to operational action, the more important it becomes to define permissions, approval points, exception handling, logging, monitoring, rollback, and accountability.
• Existing IT management disciplines become more valuable, not less. ITIL and COBIT are sometimes seen as heavy or bureaucratic, but used well they are practical tools for asking sensible questions. Who owns the service? What level of performance is expected? What risks are acceptable? How is change managed? How do we know whether the capability is delivering value? What happens when something goes wrong?
• AI governance cannot sit only in policy documents. Policies matter, but they are not enough. A policy that says “use AI responsibly” does not help much when an agent fails, a vendor changes a model, a retrieval source is outdated, or a user relies on an unsupported output. Governance needs to show up in architecture, procurement, service design, training, operational support, monitoring, and management reporting.
• Organisational readiness becomes more important at each stage. At the Assist stage, the main readiness questions are often literacy, privacy, acceptable use, and access. At the Advise and Act stages, readiness becomes more operational. Do we understand the workflow? Is the data good enough? Are roles clear? Are controls in place? Do staff trust the system? Is there a support model? Can we explain what happened if the output is challenged?
• Effort savings and duration savings are different things. AI can save significant effort in drafting, analysis, summarisation, research, and workflow support. But that does not automatically mean the organisation can move everything faster. Reviews still happen. Approvals still happen. Change still takes time. People still need confidence.
• Repeatability is where the value compounds. One-off experiments can be useful, but the larger opportunity is in repeated processes. Service requests. Incident analysis. Policy reviews. Procurement support. Report drafting. Meeting preparation. Knowledge search. Vendor assessments. Risk reviews. These are areas where IT departments already understand process, controls, support, and continuous improvement.
• Quality control becomes a design issue. With AI, quality cannot rely only on the individual user checking the output at the end. The process needs to be designed for quality. That may include approved knowledge sources, clear prompts, retrieval controls, human review points, testing, logging, sampling, feedback loops, and escalation paths.
• Leadership needs to decide the role IT is expected to play. Some organisations will expect IT to provide secure tools and stay out of the way. Others will expect IT to lead governance, architecture, vendor selection, integration, and operating models. The worst position is ambiguity. AI adoption will spread either way. The question is whether it spreads with enough structure to be useful and safe.

What do I do with it?

The practical starting point is not to create a giant AI governance programme. It is to match the level of management discipline to the level of AI maturity and risk tolerance - be pragmatic.

• Map where AI is being used today. Start with reality, not aspiration. Where are people already using AI? What tools are being used? What data is involved? What business processes are affected? Which uses are individual productivity aids, and which are becoming part of how work actually gets done?
• Separate assistance from action. Treat AI that helps people think, draft, summarise, or analyse differently from AI that takes action in systems. Once AI can update records, trigger workflows, send messages, or make operational recommendations, the governance and service management expectations should increase.
• Use familiar frameworks rather than inventing everything from scratch. ITIL and COBIT already give IT leaders a useful language for service management, controls, risk, value, quality, operations, change, and performance. The work is not to force AI awkwardly into old categories. The work is to use established disciplines to ask better questions about a new capability.
• Build the AI operating model gradually. Define who owns AI tools, who approves new use cases, who manages vendors, who reviews risk, who supports users, who monitors performance, and who decides when a pilot becomes an operational service. Keep it lightweight at first, but make it real.
• Put procurement and vendor management into the conversation early. Many organisations will consume AI through existing software platforms, not build models themselves. That means vendor questions matter. What data is used? Where is it processed? Can the vendor explain key behaviours? What controls exist? What happens when features change? What contractual commitments are in place? What happens when we exit the contract and relationship?
• Treat AI literacy as part of service adoption. Training should not only teach people how to prompt. It should help people understand appropriate use, limitations, review responsibilities, privacy expectations, and when not to use AI. This is especially important as AI moves into more structured workflows.
• Design for human accountability. Human-in-the-loop should not be a vague phrase. Be clear about who reviews what, when they review it, what evidence they use, and what decision they are accountable for. AI can support judgement, but it should not blur ownership.
• Start with workflows where the risk and value are both understandable. Document-heavy internal processes are often good candidates. Policy review, meeting preparation, knowledge management, procurement support, service desk knowledge, risk registers, reporting, and internal research can all create value without immediately jumping to high-risk automation.
• Measure value in operational terms. Do not only count licences, minutes used or prompts. Look at process cycle time, rework, quality, user adoption, avoided effort, improved consistency, better knowledge reuse, faster triage, reduced backlog, and stronger compliance evidence. Those are the measures leaders can actually use.
• Increase governance as autonomy increases. A lightweight approach may be fine for Assist. It is unlikely to be enough for Act or Automate. As AI systems gain the ability to perform delegated tasks, organisations need stronger controls around monitoring, disaster recovery, business continuity, security, change, configuration, performance, and benefits realisation.

The point here is that done well, IT should help AI adoption become more useful, more repeatable, more reliable and more trusted. A shift in the conversation from “Should AI be owned by IT or the business?” to “How do we combine business ownership with the management disciplines needed to operate AI responsibly?”

IT departments can make a real contribution, not by turning AI into another slow approval process, but by helping the organisation adopt it in a way that stands up when the use cases become more important, more integrated, and more autonomous.