The CIO and AI: from managing technology to orchestrating capabilities

For years, the CIO's job was measured by two things: that infrastructure worked and that projects were delivered on time and on budget. That job still exists, but it no longer explains the role. Much of the infrastructure is consumed as a service, product teams deliver continuously, and AI, especially agents that act on systems, introduces decisions that fit neither a project plan nor a support contract.

On top of that, AI does not arrive only through the Technology function. It arrives through productivity tools other departments buy, through new features vendors switch on in services already under contract and through teams trying out models on their own. If the CIO does not offer a fast, governed path, the organization finds its own paths, with no inventory, no data controls and no one accountable for the results.

The question the board asks the CIO today is no longer "does it work?" but "what capabilities do we have, what risk do we take on with them and what value do they produce?". Answering it takes a different way of working: less direct management of assets and more orchestration of capabilities that depend on many players. This article sets out what that means in practice.

What changes in the role

Managing means making sure an asset works. Orchestrating means combining capabilities you do not fully control (data from other departments, third-party platforms, vendor models, agents acting with some autonomy, people with new profiles) so they produce a business outcome with an accepted level of risk. The difference is not semantic. It changes what the CIO decides, delegates and reports.

Three forces drive the change:

• AI depends on cross-cutting capabilities. A useful AI use case needs quality data, governed integrations, a platform to run on and people who know how to oversee it. If one is missing, the use case does not scale.
• Risk moves. With agents that take actions, risk no longer sits only in a system's availability but in the quality of automated decisions. That calls for explicit governance.
• Cost becomes variable. Model and cloud consumption grows with usage, not with an annual contract. Without financial discipline, a successful use case can turn into a budget problem.

A capability map to orchestrate

We recommend that the CIO run the function as a capability map, not as a system inventory. The diagram shows one way to organize it.

Each capability has an owner, a maturity level and a roadmap. The CIO does not need to run all of them directly, but does need to answer for how they combine. We have covered some in detail: AI-ready data and integration before agents.

Responsibilities: then and now

The table summarizes how responsibilities shift. It is not a list of new tasks stacked on top of the old ones; it is a change of emphasis.

Area	Then: manage	Now: orchestrate
Infrastructure	Run data centers and servers	Offer self-service internal platforms on private and third-party cloud
Projects	Deliver on time and on budget	Fund capabilities and products with measurable outcomes
Data	Look after databases	Ensure quality, lineage and governed access for analytics and AI
Vendors	Negotiate contracts and SLAs	Manage model and service dependencies, with exit plans
Automation	Scripts and scheduled jobs	Agents with autonomy levels, least privilege and audit trails
Talent	Fill technical positions	Train by role and redesign work alongside agents
Risk	Availability and continuity	Also the risk of automated decisions, bias, privacy and variable cost

Decisions the CIO does not delegate

Orchestrating means delegating a lot: platform teams decide their architecture, product teams decide their priorities, vendors run their services. But some decisions we recommend the CIO keep, because they commit the whole organization:

1. Which AI use cases are approved and at what maximum autonomy level. Technical assessment is delegated; final approval of use cases that affect customers or compliance, together with Risk, is not.
2. The reference architecture. Which platforms, integration patterns and model services are standard, and when an exception is accepted.
3. Critical vendor dependencies. Accepting that a critical process depends on a single model or cloud provider is a risk decision, not a procurement one.
4. Investment allocation across capabilities. How much goes to data, platform, talent and new use cases. If it is decided case by case, cross-cutting capabilities always lose.
5. When to switch off. Who can stop an agent or an AI service, and under what conditions. That criterion must be signed off before it is needed.

ISO/IEC 38500 helps draw this line. It separates the governance of IT, which belongs to the governing body (evaluate, direct and monitor), from its management. ISACA's COBIT 2019 makes a similar distinction between governance objectives and management objectives. The CIO lives between the two: preparing governance decisions for the board and answering for management.

How to report to the board

The board does not need the status of every project. It needs to understand what capabilities the organization has, what risks it takes on and what value it gets. We recommend a short quarterly report with four blocks:

• Value: business results from use cases in production, compared with what was promised when they were approved.
• Risk: AI use cases by autonomy level, significant incidents, open exceptions and critical vendor dependencies.
• Capabilities: maturity of each capability on the map and gaps that hold back new use cases.
• Decisions requested: what the board needs to approve, with options and the risks of each.

Keep the same structure and the same metrics every quarter, so the board sees trends rather than isolated snapshots. And bring every significant risk with a proposal: accept it, mitigate it at an estimated cost or retire the use case. A board that only receives alerts with no options ends up stopping everything out of caution.

The NIST AI RMF provides useful vocabulary for the risk block, with its Govern, Map, Measure and Manage functions. If the organization runs an AI management system under ISO/IEC 42001, the report can draw on its management review; we explain how in ISO/IEC 42001 in practice.

Metrics that work

A common mistake is to report activity (number of pilots, models tested, people trained) instead of outcomes. We propose metrics grouped by question:

• Does it produce value? Use cases in production with outcomes measured against a baseline; time from approval to production.
• Is it under control? Share of AI use cases inventoried and with an owner; use cases by autonomy level; response time to AI incidents.
• Is it sustainable? Unit cost per use case (for example, cost per transaction handled) and its trend; concentration of spend on a single vendor.
• Do we have the foundation? Critical data sources with measured quality; integrations exposed through governed APIs; training coverage by role.

A few metrics, each with a written definition and an owner, are worth more than a sprawling dashboard nobody reviews. Cost deserves special attention: model and compute spend grows with usage, and it should be measured per unit of value from the first use case in production. We go deeper in FinOps for AI.

A first-year checklist

If you are taking on the role or want to reorient it, this sequence tends to work:

1. Inventory existing AI use cases, including those nobody formally approved.
2. Publish the capability map with an owner and a maturity level per capability.
3. Agree with Risk and Compliance on the autonomy scale and the use case approval process.
4. Define the reference architecture for integrations, platforms and model services.
5. Review contracts with critical vendors: data, continuity and exit plan.
6. Set up the quarterly board report with its four blocks.
7. Launch a role-based training plan and measure its coverage.

Before presenting the approval framework and autonomy levels to the board, validate them with Compliance, Legal and Risk, because they set responsibilities that regulation may require.