AI Adoption Is Not an IT Project

The people you need are mostly domain experts, not software developers

Leadership teams still commonly treat AI adoption as a technology programme. The logic seems sound: AI is technology, technology belongs to IT, AI systems run on software, and software is built by engineers. So naturally, AI adoption gets handed to IT and staffed mostly with developers.

That logic mixes up two different things: building the machinery and doing the organizational work that makes the machinery useful.

AI adoption is a business transformation that IT and engineering enable, not an IT project in its own right. Most of the people who make it work won’t be developers. They’ll be domain experts.

AI is not traditional software

Traditional software puts most of its behaviour in code. Developers translate business requirements into instructions a computer executes step by step.

AI systems work differently. What they do is shaped by instructions and examples, business rules and decision criteria, domain knowledge and terminology, documents and context, permissions and escalation paths, evaluation cases and acceptance standards, and the APIs, MCPs, integrations, and conventional code that connect it all together.

That last piece clearly belongs to engineering. Most of the rest doesn’t.

Somebody has to define what the AI should know, what it should do, which rules it has to follow, what counts as a good result, and when it should hand off to a human. None of that is really a coding task. It’s domain work.

The people you need are already in the business

It’s tempting to assume that adopting AI means hiring a wave of AI engineers and developers. You’ll need some additional technical capacity, sure. But developers won’t make up most of the headcount.

What you need more of is people who understand the work the AI is supposed to do: accountants, lawyers, underwriters, clinicians, operators, engineers, sales leaders, financial analysts, risk professionals, compliance specialists, experienced frontline staff.

Their job is to document domain knowledge, define business and governance rules, describe how decisions actually get made, flag exceptions and edge cases, produce examples of good and bad outputs, build evaluation cases, set quality thresholds, decide when human review is required, and test whether the AI holds up in real situations.

They don’t need to learn to code. They need to learn how to put their expertise into words precisely enough for an AI system to use it, and how to tell whether the system applied it correctly.

That’s not “just writing.” It’s turning tacit professional knowledge into explicit instructions, rules, examples, and tests.

Developers can’t manufacture that knowledge. They can build the frameworks that hold it, connect the systems that feed it, and put controls around how it’s used. But they can’t tell you what good underwriting looks like, whether a legal interpretation holds up, how an operational exception should be handled, or whether a financial analysis is credible. That knowledge lives in the business, not in engineering.

AI adoption needs business governance too

The non-engineering work goes beyond domain knowledge. Somebody has to decide which AI initiatives are even worth pursuing: spotting and prioritizing opportunities, vetting proposals, judging whether AI is the right tool for the problem, building a credible business case, estimating costs and returns, checking organizational readiness, setting governance and risk requirements, approving investment and deployment, assigning accountability, and measuring whether the benefits actually showed up.

IT and engineering have a role here. They can assess technical feasibility, estimate the build effort, flag infrastructure needs, evaluate security implications, and calculate operating costs. What they shouldn’t do is decide, on their own, whether an initiative is strategically worthwhile, financially justified, operationally acceptable, or within the organization’s risk appetite. Those are calls for the business to make.

What IT and engineering should own

None of this makes IT or engineering less important. They’re still responsible for the foundation: platforms, data and system integrations, APIs and MCPs, identity and access management, infrastructure and deployment, security controls, reliability and observability, vendor and model integration, and the deterministic code that sits behind AI skills.

That foundation is what makes AI adoption possible in the first place. But possible isn’t the same as useful, or worthwhile.

The split should be clean: domain teams define what the AI needs to know, what it should do, what rules apply, and what a good result looks like. Engineering builds the secure, reliable machinery that lets it know and do those things. IT enables the work, engineering builds the components, and business leaders own the use, the value, the risk, and the consequences.

What goes wrong when AI is treated as an IT project

Hand AI mainly to IT and you’ll see engineering teams asked to go find use cases in business functions they don’t actually run. They end up guessing at business rules nobody wrote down, trying to reproduce professional judgment they don’t have, evaluating outputs in domains they don’t understand, and being asked to prove a financial return that only the operating leaders can actually deliver.

Meanwhile the business sits back and waits for IT to hand them an AI application.

Both halves of that arrangement are wrong. Engineering can’t extract knowledge the business has never written down. It can’t judge whether an output reflects sound professional judgment without the people who have that judgment. It can’t redesign someone else’s operating process for them. And it can’t produce a financial return unless the people who own the work actually change how they do it.

What you get instead is usually a slick demo that never turns into something the business can rely on.

A different workforce model

Don’t treat the AI workforce as a new technical department bolted onto the org chart. Think of it as a cross-functional capability where domain experts actively design, evaluate, and own AI-enabled work.

You’ll still need AI engineers, developers, data specialists, architects, security people, infrastructure teams. But around that core you need a much larger group of business specialists supplying the knowledge, writing the rules, evaluating performance, governing use, and realizing the value.

So the real workforce question isn’t “how many AI developers do we need?” It’s “how do we equip our domain experts to express, test, govern, and improve the knowledge and judgment that AI-enabled work depends on?”

That second question leads to a completely different adoption programme. It changes who’s in the room, who owns the outcomes, what capabilities you need to build, where the budget sits, and how initiatives get approved.

The leadership decision

AI adoption touches business strategy, investment governance, operating-model design, domain expertise, risk management, financial accountability, organizational change, and technical delivery all at once.

Leadership teams shouldn’t hand the whole problem to IT just because AI happens to be technical. The technology comes from vendors, platforms, APIs, models, and engineering teams. The knowledge, judgment, rules, accountability, and value have to come from the business.

In a lot of organizations, the scarce resource isn’t AI programming skill. It’s the ability to actually articulate how the business works, and then turn that understanding into instructions, rules, examples, evaluations, and controlled workflows.

Engineering builds the machinery. Domain experts teach it how the business works. Business leaders decide where to use it, what risk they’ll accept, and whether it’s worth the investment.