I got asked three times last month how to “restructure IT for AI.” Each time it came from a CIO or CTO who’d read something on LinkedIn about AI-native org designs and was now panicking that their traditional infrastructure-applications-support structure was obsolete.

Here’s what I told them: slow down. Your org structure probably isn’t the problem. And restructuring for the sake of restructuring is how you lose your best people while accomplishing nothing.

That said, AI does change some things about how IT teams need to work. Let me talk about what actually needs to change and what doesn’t.

What Doesn’t Need to Change

Your infrastructure team still matters. AI workloads need compute, storage, networking, and security—the same things every workload needs. Your infrastructure team already knows how to provision and manage these resources. They need upskilling on GPU infrastructure, model serving, and ML pipeline tooling. They don’t need to be reorganised into an “AI Platform Team” with a new reporting line and a fancy title.

ITIL isn’t dead. I know it’s fashionable to declare ITIL irrelevant in the age of AI. Nonsense. Change management, incident management, and service-level management matter more when you’re deploying models that can make autonomous decisions. If anything, you need stronger governance processes, not weaker ones.

The service desk stays. Users still need help. AI-powered chatbots handle about 30% of tier-one tickets well, and the rest still need humans. The ratio will shift over time, but “we’ll replace the service desk with AI” remains a fantasy for most organisations in 2026.

What Actually Needs to Change

Data engineering needs its own team. If your data engineers are buried inside application development or reporting to a BI manager, that’s the single biggest structural change I’d make. AI lives and dies on data quality, and data engineering needs dedicated headcount, dedicated budget, and a direct line to IT leadership.

I don’t mean hiring a Chief Data Officer and creating a 50-person data department. I mean taking the three or four data engineers you probably already have, giving them a team lead, and making data quality a first-class IT function instead of an afterthought attached to the analytics team.

Create an AI governance function, not an AI team. The instinct is to create a centralised AI team that builds everything. This fails for the same reason centralised innovation labs always fail—they become disconnected from the business units that actually need the capabilities.

Instead, embed AI skills across existing teams and create a small governance function (two to three people) that sets standards, reviews deployments, manages model risk, and maintains the tooling and infrastructure that other teams use. Think of it like your security team: they don’t build every secure application, but they set the standards and review the implementations.

Your architects need to understand ML operations. This is non-negotiable. If your enterprise architects can’t evaluate a model deployment pipeline, can’t assess whether a proposed AI solution needs real-time inference or batch processing, and can’t estimate the infrastructure cost of training versus serving, they’ll make bad decisions that take years to unwind.

Send your senior architects on a proper MLOps course. Not a vendor-sponsored half-day. A genuine deep-dive into how models get built, trained, deployed, monitored, and retired. They don’t need to write Python—they need to understand the operational characteristics well enough to make architecture decisions.

The Reorg Mistakes I Keep Seeing

Mistake 1: Creating an AI Centre of Excellence. I’ve watched four of these get created and dissolved within eighteen months. They attract attention initially, do some interesting proof-of-concept work, and then stall because they can’t get access to production data, production infrastructure, or production users. The business units view them as ivory tower experimenters. Don’t do this.

Mistake 2: Hiring an AI leader with no IT operations experience. You need someone who understands model deployment and monitoring in a production environment, not someone who’s brilliant at research but has never dealt with an SLA. Data scientists who’ve never had a pager go off at 3am don’t understand the operational realities of enterprise IT.

Mistake 3: Restructuring before you have a use case. “We need to be AI-ready” is not a strategy. Pick two or three concrete AI use cases that your business actually needs, staff them, deliver them, and let the organisational structure evolve around real work. Don’t draw boxes on an org chart for capabilities you don’t have yet.

The Honest Assessment

Most IT organisations don’t need a radical restructure to support AI. They need better data engineering, a governance framework, and some targeted upskilling. The companies that blow up their org charts and start from scratch usually end up with something that looks suspiciously similar to what they had before, minus the institutional knowledge of the people who left during the disruption.

Change what needs changing. Leave the rest alone. Your IT org has survived cloud, mobile, DevOps, and containerisation. It’ll survive AI too, as long as you don’t panic and restructure it into oblivion.