AI Governance Will Migrate to IT, Just Like Everything Else Did

AI governance accountability will end up with IT in most organisations, not because IT wants it or because the Chief AI Officer role has failed, but because IT already owns every framework, control category and workflow that AI governance requires. Organisations absorb new technology in a structural pattern, and it applies reliably to anything that acquires network connectivity and starts handling corporate data. AI is following that path now.

This matters commercially rather than academically. If you accept the destination, the interesting question stops being who owns AI strategy in five years and becomes who manages the risk during the migration.

The migration pattern

Every technology category that connects to the corporate network and handles corporate data eventually becomes IT’s responsibility. The examples are recent enough that most IT directors lived through at least two of them.

Mobile phones were once a facilities problem. Handsets, airtime contracts and desk allocations were managed by telecoms or facilities staff. Then BlackBerry devices started synchronising corporate email through the BlackBerry Enterprise Server. The moment corporate data started flowing through those handsets, the facilities team was out of its depth and IT inherited the problem. Mobile Device Management emerged as a formal discipline. The phones never went back.

Desktop telephony followed the same route. For decades it sat in its own silo, run by dedicated telecoms engineers. When VoIP arrived and phones became network endpoints running over IP infrastructure, the silo collapsed. Phones joined the network, joined the asset register and joined IT.

Photocopiers took the same path once digital models arrived with network connectivity, internal hard drives and print server capability. They stored document images, sat on corporate networks and needed security configuration, so they became IT assets. Fax machines followed when IP fax and unified communications moved them onto the same infrastructure.

The pattern is less about the device than about the moment a technology category connects to the network and starts processing corporate data. At that point IT’s existing governance frameworks become directly relevant, and ownership follows the frameworks.

Why IT is the natural home for AI governance

The case for IT ownership is structural rather than aspirational. Map what AI governance requires against what IT already runs, and the overlap is close to total.

Start with the asset register. An AI tool processing corporate data is an IT asset. Which tools are in use, on what commercial terms, with what data access and under whose authority are all asset management questions, and IT holds both the framework and the process for answering them.

Acceptable use is the same story. The policy question for AI is structurally identical to ones IT has already resolved for cloud services, personal devices and internet access: what can employees use, under what conditions, with what data? The template exists. The AI-specific content needs writing into it. Nobody needs to build the framework from scratch.

Access control is where the parallel becomes concrete. Preventing corporate data from reaching AI systems that should not process it requires role-based access control, data classification and data loss prevention tooling. Those are live IT functions today, not theoretical equivalents.

Supplier management and security engineering sit in the same place. The due diligence process for a new AI supplier is the security review IT already conducts for any cloud service handling corporate data, using questionnaires, contractual clauses and a review process already in use. Prompt injection, model vulnerabilities and insecure AI integrations are engineering problems for the team already accountable for application security and production systems.

This is also where the CAIO versus CISO question resolves itself. The CISO already owns risk assessment, control frameworks, incident response and third-party assurance across every other technology category in the organisation. A CAIO appointed alongside that has to either duplicate those functions or coordinate them, and coordination roles tend to be absorbed by whoever owns the underlying controls. In large enterprise the scale and strategic complexity of AI adoption warrants a dedicated executive function. Outside that context, every framework AI governance requires already sits inside IT and security, so the accountability question answers itself once you map the requirements.

The transition gap

Knowing where AI governance will land does not mean IT is ready to own it today. Most IT teams were not resourced for this. Their budgets do not include AI security expertise and their supplier relationships were not built around it. The specialist knowledge required sits outside the skill profile they recruited for.

That gap is not unique to AI. Every migration that preceded it went through the same period. Mobile Device Management took years to mature as a discipline after the first enterprise smartphones arrived. Cloud security expertise developed slowly after SaaS adoption accelerated well ahead of IT readiness. In each case specialist suppliers filled the gap while IT built the knowledge and resource to bring the function in house.

AI security governance in UK organisations is in that gap now. IT teams generally recognise the destination. Most are not yet equipped to reach that point without external help, which is why the practical decision facing boards is less a structural debate about reporting lines than a straightforward question about the current period: who is assessing AI risk, against which framework and on what timescale?

Where the answer is nobody, a retained vCAIRO function covers the accountability while the internal capability builds.

Key questions on AI governance ownership

Who should own AI governance in a mid-sized organisation today?

In most mid-sized organisations, AI governance should sit with IT or the CISO rather than a dedicated AI function. IT already owns the asset registers, acceptable use policies, access controls and supplier review processes that AI governance depends on. A separate function duplicates those controls without adding assurance, and rarely survives the first budget cycle.

What slows down AI governance once IT takes ownership?

The usual constraint is specialist knowledge rather than willingness. IT teams understand asset management and access control but have limited exposure to model vulnerabilities, prompt injection and AI-specific supplier assurance. Budgets set before AI adoption accelerated rarely include that expertise, so progress stalls between recognising the requirement and resourcing it.

When should an organisation start formalising AI governance?

As soon as staff are using AI tools with corporate data, which in most organisations has already happened. Formalising governance after adoption means working backwards from an unknown position, so the practical starting point is establishing what is actually in use, then assessing that against a recognised framework.

Does a Chief AI Officer appointment ever make sense?

Yes, in large enterprise where AI adoption carries material strategic and regulatory complexity across multiple business units. At that scale a dedicated executive function coordinates work that no single existing owner can absorb. Below that scale, the remit overlaps almost entirely with responsibilities the CISO and IT leadership already hold.

If you are using AI without a clear picture of where your governance and security gaps sit, an AI Security Gap Analysis maps your current position against recognised frameworks and produces a prioritised roadmap rather than a generic checklist.