From IT governance to AI governance: what actually changes

Introduction

A mid-sized health insurer hands one AI model the decision to settle certain claims on its own, and another the drafting of the replies sent to its policyholders. Who, in that organization, is still actually deciding? This is the central question AI governance raises today, and it forces us to revisit what IT governance took years to establish.

Long treated as a support function managed on technical grounds, IT became a governance matter in its own right from the 2000s onward. In the OECD’s formulation, to govern is to provide “the structure through which the objectives of the company are set”, together with the means of attaining them and of monitoring performance, a logic that IT systems do not escape, since they draw on significant resources and commit the company over the long term.

This shift from managing IT technically to governing it, governance being defined as a framework of decision rights and accountability meant to “encourage desirable behavior in the use of IT”, marks a decisive change of approach: which technologies to use, for what purposes, with what risks, under whose responsibility, and against what performance criteria?

The main issues in IT governance

Four main axes structure the governance of IT.

Strategic alignment means making sure that technology choices serve the objectives of the company and, conversely, that technical possibilities feed strategic thinking. The governance question is easy to state and often hard to settle: which business objective does this system serve, and how will we know that it does? The typical failure is not the absence of a strategy but the existence of projects that are technically legitimate and strategically orphaned.

The most common sign is a portfolio of initiatives that mirrors the org chart rather than the priorities of the company: each department gets its own tools and nobody arbitrates between them. Governance should then be in a position to require that every significant investment be tied to an identifiable objective and to a business indicator, and not merely to the obsolescence of the solution it replaces.

Risk management and resilience combine two requirements that are often conflated, although they sit on either side of the same event. Risk management plays out beforehand: identifying what can happen, estimating its likelihood and its consequences, ranking, treating, then explicitly accepting whatever remains. Resilience plays out afterward: once prevention has failed, what capacity is left to absorb the shock, to operate in degraded mode, to return to normal and to learn from the incident?

Making the best use of resources and of the value created matters just as much. Three things then need to be kept apart: cost, which is estimated beforehand; resources, which are a capacity (budget, available skills, the ability of teams to absorb change and assets that can be reused); and value, which can only be observed afterward.

Finally, organizing accountability for steering means both separating roles that are readily conflated (deciding, implementing, controlling, reporting and so on) while making sure that the person designated has the corresponding means and authority, and keeping governance questions on the agenda over time.

The frameworks available today

The main frameworks for assessing IT governance are better read as complementing one another than as competing, since each puts the emphasis on a different dimension. They have now reached a high level of maturity.

Two frameworks speak directly to governing bodies. ISO/IEC 38500 is the only standard whose explicit subject is the governance of IT: it sets out guiding principles for an “effective, efficient and acceptable” use of technology, but it provides neither processes nor auditable requirements. Its latest edition (2024) takes in subjects that have become impossible to ignore: migration to the cloud, AI governance, remote work, digital ethics and sustainability.

COBIT, published by ISACA, takes the opposite approach: it is the most detailed of the frameworks, built around a strict separation between governance (a single domain, Evaluate, Direct and Monitor) and management (all the others), so that the difference between deciding and implementing is written into the architecture of the framework itself. ISACA has announced an update for the second half of 2026, largely in digital form, with a self-assessment module.

Three further standards set out the conditions under which decisions are carried out, which makes them the natural complement to the frameworks above rather than governance frameworks in their own right. ISO/IEC 27001 structures the management of information security around a closed loop (risks, controls, monitoring, continual improvement) whose value reaches well beyond its own scope. ITIL and ISO/IEC 20000 cover service management: availability, incidents, changes, service levels. A new version of ITIL has been rolling out gradually since 2026, with an extension module devoted to AI governance. The NIST Cybersecurity Framework, in its version 2.0, deserves a mention of its own: it has added a Govern function to the historical technical functions, recognizing that managing cyber risk cannot be sustained without decisions and accountability at the level of the organization.

New questions in the age of AI

Unlike conventional IT systems, AI systems raise new problems that change what governance frameworks have to cover.

An AI system can be defined, following NIST and the OECD, as a system that, for a given set of objectives, produces outputs (predictions, recommendations, decisions) influencing real or virtual environments. What sets it apart from conventional software is the nature of what gets verified. Conventional software applies explicit rules: verifying it yields a verdict, compliant or non-compliant. An AI system generalizes a behavior learned from data: its performance becomes a measurement (error rate, dispersion, performance by population segment or by type of case), non-zero and not uniform, even when its execution is deterministic. Governance therefore has to restate its requirements, moving from “does the system work?” to “what level of error do we accept, on which cases, and beyond what threshold do we stop using it?”

What is more, whereas conventional procedures can be exhaustive by listing the functions expected of a system, AI systems operate over open input spaces. Control over an AI system therefore lies less in the system itself than in the limits placed around its use.

A conventional IT control stays valid as long as the code, the configuration and the environment do not change. Change management can therefore rely on versions and releases. An AI system, by contrast, can degrade even though nothing has been modified: input data shifts, patterns of use change, the reality the model represented is no longer quite the same. Verification has to become periodic or continuous, with indicators monitored in production and thresholds that trigger a reassessment.

Conventional audit leans heavily on examining design, by reading a rule, retracing a piece of processing or reconstructing the path of a decision. That route stays narrow with models whose inner workings cannot be read as explicit rules. Whatever cannot be inferred from design then has to be established by systematic experiment on selected cases.

A worked example

A mid-sized health insurer: 900 employees, 600,000 policyholders, some 12 million reimbursement claims processed a year, a customer service center absorbing 500,000 calls and 1.2 million emails. At the heart of the information system sits a claims application extended layer by layer over some twenty years.

The insurer starts two projects built on AI systems. One model reads supporting documents, extracts the data and, below a certain amount, decides on the reimbursement on its own. An assistant drafts the replies to policyholder emails, which an adviser approves before they are sent. The four classic governance axes then shift:

• Strategic alignment: the business objective no longer comes before the technical choice. The capability exists, and the organization looks for somewhere to apply it. The question is no longer “which technology serves this objective?” but “does this objective justify this risk?” Setting the automation threshold means deciding how error is distributed: a policyholder who is not reimbursed when they should have been and a payment made in error do not carry the same cost, the same visibility or the same consequences.
• Risk and resilience: non-determinism is not a general property of AI systems. It mainly concerns large language models at the point of sampling, and should not be confused with the probabilistic character of the model itself, which can be computed deterministically. Governance should therefore not be asking whether the system works, but what level of error is acceptable, in which cases, and beyond what threshold we have to stop using it.
• Measuring cost and value: billed by usage, cost grows with adoption. The success of the project therefore erodes its own business case, and the investment analysis has to be built on volume scenarios rather than on a single figure. Value becomes hard to attribute. Does a shorter processing time come from the model, from another project running in parallel, or from a seasonal variation? Without a baseline established before deployment, the insurer will be able neither to confirm nor to rule out the benefit announced.
• The question of accountability: the assistant comes with human validation, which appears to settle the matter of supervision. But if the adviser has a few dozen seconds per message and approves almost every suggestion, supervision is documented without being effective: it shifts responsibility onto an employee who lacks the means to carry it.

Conclusion

The frameworks available today set out what has to be decided, who has to decide, and along which line of accountability. What they say nothing about is how to check that a decision remains valid over time, and that question becomes central once AI systems are in play.

With these systems, every governance requirement has to be translatable into something measurable and testable: an error threshold, an indicator monitored in production, an experimental protocol. It is that translation, more than the frameworks themselves, that we will explore in the coming articles in this series.

References

• OECD Principles of Corporate Governance, 1999, p. 13.
• IT Governance vs IT Management: who does what, Bologna Business School.
• IT Governance, Peter Weill and Jeanne W. Ross, Harvard Business School Press, 2004, p. 8.
• Board Briefing on IT Governance, ITGI, 2nd ed., 2003.
• ISO/IEC 38500:2024, Information technology: Governance of IT for the organization, 3rd ed.
• ISACA, “Celebrating Three Decades of COBIT”, @ISACA, 2026, vol. 8.
• NIST Cybersecurity Framework 2.0.