AI Strategy Is Not an IT Decision

Every organization making decisions about AI implementations has made the same mistake at least once: they handed the strategy to IT.

It makes intuitive sense: AI involves software, data pipelines, vendor integrations, and infrastructure decisions. Those are clearly in technology’s swim lane, and technology functions belong to IT. The CIO gets a mandate, a budget gets allocated, a project gets stood up, and the work begins.

What follows is often technically competent and operationally irrelevant. The system gets built and it runs, but nobody uses it in a way that changes how decisions actually get made. Within twelve months the questions begin to circulate: why hasn’t the investment paid off?

What IT is actually for

IT departments at airlines and travel companies are responsible for some of the most genuinely complex infrastructure in any industry. They maintain systems that process millions of booking transactions, run revenue management platforms, manage distribution connections to hundreds of points of sale, and keep core operational systems available around the clock across time zones worldwide. That is not background work; it is foundational to everything the commercial organization does.

IT is also the right function to evaluate vendor security posture, own the data access governance, manage integrations between new AI systems and existing platforms, and ensure that whatever gets built can be deployed, maintained, and supported reliably at scale. These are critical responsibilities.

What IT is not positioned to do is define which commercial problems are worth solving with AI, because IT does not live and breathe those problems every day. A team evaluating AI vendor architecture does not have a native view of where the revenue management workflow breaks down at peak, how competitive pricing moves translate into pressure for the analyst team, or what a correctly calibrated forecast adjustment looks like in a specific market. Those are core RM processes which require specialized knowledge to understand. The question of which AI investment will change how the commercial operation performs cannot be answered from outside the commercial operation.

Where strategy has to originate

The teams that should own AI strategy are the ones that will determine, within the first thirty days of any deployment, whether the system is genuinely useful or a well-funded distraction.

In an airline commercial environment, this means the pricing and revenue management teams who will work with the platform every day. It means the analysts who will decide whether to trust a recommendation, probe it, or override it. It means the managers who will recognize immediately whether the system is surfacing real problems or generating noise. These are the people who know exactly where the current tools don’t suffice, where manual work is substituting for missing infrastructure, and what a good answer actually looks like for a given market situation.

The commercial team is not always good at articulating this. They are occupied with the daily operational reality that the AI investment is supposed to help with, and they often lack a framework for translating operational friction into a clear AI brief. That gap is real and it is addressable, but the answer is not to hand the problem to a function with less context. It is to invest in helping the commercial team develop the articulation, ideally with a partner who can sit in the room with them and draw it out.

The thirty-day test is not a metaphor. Commercial teams are not patient with tools that do not work on the actual job. If an AI system does not produce outputs that are immediately legible, relevant to the decision at hand, and actionable within existing workflows, it will stop being used—not because the team is resistant to change, but because the work does not wait for a tool that is not ready. Airlines that have deployed genuinely useful AI systems did so because the commercial team was involved in defining what the system needed to do before the first line of code was written.

The services problem

The same failure mode appears when organizations outsource AI strategy to a generalist technology consulting firm. Technically competent execution in service of a poorly defined problem produces the same result as handing the mandate to internal IT.

Generalist firms bring methodology, project management discipline, and genuine engineering capability. What they typically lack is the domain knowledge required to define the problem correctly in the first place. They can implement what they are asked to implement, but they cannot tell you whether the thing you have asked them to implement was the right thing to build in the first place.

The result is a system that functions exactly as specified and solves a problem that was not quite the right one. The specification was written by people who understood the technology, yet nobody in the room understood the operation well enough to push back on whether the brief was correct.

The alternative is not a different methodology or a smaller engagement model. It is a different kind of partner—one who understands the business domain and the AI architecture well enough to translate between them in both directions. That means someone who can sit with a Head of Revenue Management, understand the pain points she describes, and translate them into a technical architecture. And then do the reverse: take a model output and explain it to a commercial team in terms that connect to their actual decision-making context, not as a university lecture on model evaluations.

Three owners, not one

The governance model that actually works is simple to describe and requires discipline to maintain.

Business teams own the problem definition and the success criteria. Not a vague mandate to use AI to improve commercial performance; specific articulation of which workflow is broken, what the current cost of that broken workflow is, and how a measurably better outcome looks. If the commercial team cannot describe how good looks before the project starts, the project has no honest basis for evaluation.

AI specialists own the architecture and the implementation. Given a clear problem and a defined success criterion, the technical design and execution belong to the people with the expertise to make sound architectural choices. Data preparation lives as a shared function across commercial and AI. Teams are not built like this today because the technology landscape has never been like this before. I recently wrote a separate piece on this concept: leaders must rethink the org chart if they want to fully harness the power of the technology.

IT owns the infrastructure and the integration layer. Once an architecture is designed, IT’s role is to ensure it can be deployed securely, connected to the systems and data it needs to interact with, and maintained without creating new operational risk. That is substantial and consequential work; it is also bounded work.

When those three are aligned—when the commercial team has defined the problem, the AI specialists have designed the solution, and IT is executing the infrastructure—transformation is free to progress: projects reach production, systems get used, and outcomes are measurable.

Conclusion

AI strategy is not an IT decision in the same sense that revenue strategy is not a finance decision. Finance executes the accounting, manages the controls, and ensures the numbers are right. Revenue strategy requires people who understand the markets, the competitive dynamics, the customer, and the leverage points in the commercial model. The expertise is different. The accountability is different. The proximity to the problem is different.

The organizations compounding value from AI are the ones that have been practical about this distinction. The ones still waiting for the investment to pay off are usually still waiting for someone to answer the question that should have been answered first: what specific problem, for which team, with what measurable definition of better?

That is not a technology question. It never was.