Can the IT team execute the AI transformation alone?

Seeing AI solely as an IT project is the most common and costly mistake mid-sized companies make in their transformation journey.

Today, AI is on the agenda at the board meeting once again. At one end of the table stands the vice president; at the other, the IT manager. The IT manager confidently presents the project they have been working on for the past few months: a chatbot fed with internal company data. One of the developers set up the API connection, designed the interface, and deployed it to the server. The moment the sentence, "Our AI transformation has already begun; we don't need an additional budget or external support, we are solving everything in-house" is uttered, the company unwittingly falls into a classic trap.

This scenario, which we frequently observe in companies with 50 to 500 employees, stems from confusing the fundamental difference between technology and business transformation. Companies' existing tech teams are experts in keeping the infrastructure running, ensuring data security, solving daily technical issues, and integrating current software. However, an AI transformation is not a software update or a new server installation. It is the redesign of how work is done, inter-departmental workflows, and even the company's value-creation model.

The presence of technology and the transformation of business processes are not the same thing When the tech team is tasked with creating an AI solution, they rightfully treat it as an engineering problem. They write code, perform integrations, and get the system running. But just because software works technically doesn't mean it will increase the company's operational efficiency.

For example, imagine you want to automate the manual data entry that takes the operations team hours every day. The tech department can build an AI model that reads documents and processes them into the database. Technically, this is a great achievement. However, because the operations team doesn't know how to use this tool in their existing workflows, can't let go of their old habits, or doesn't want to take on the responsibilities brought by the new system, they stop using the tool. Ultimately, you end up with software that works technically but remains untouched by anyone.

The missing link here is business analysis and process design. Tech teams typically lack the time and perspective to deeply analyze the micro-inefficiencies in the daily operations of departments, the sensitivities in customer relationship management, or the legal risks of the finance team. Their job is to build the requested system, not to design how that system will reflect on business outcomes.

The limits of a single in-house developer In many mid-sized companies, there is a prevailing perception that the currently employed developers can handle this job alone. This approach is like having a single civil engineer draw the architecture, lay the plumbing, and do the interior design of the building all at once.

Developers write code based on clear definitions given to them. If you tell them, "Build us an invoice reading system," they can do it. However, the question of "How can we reduce our operational costs with AI?" is a question that a business strategist must answer, not a developer. Leaving the developer in this position distracts them from their primary job while also condemning the company to a narrow technological perspective.

Moreover, existing tech teams are already crushed under their own workloads. Routine tasks like daily cybersecurity threats, crashing servers, computer setups for new hires, and the maintenance of current business software leave no time for strategic projects that require focus, like AI. AI projects generally fall behind urgent operational issues on the tech department's priority list, and as the process drags on, motivation is lost.

Shifting the leadership of transformation to business units True transformation takes place under the leadership of business needs, not technology. Therefore, decision-makers must stop viewing AI as a sub-project of the tech department. The first step is to identify where existing business processes are bottlenecked and in which departments time is being wasted.

To make this assessment, companies typically start with a comprehensive situational analysis. An AI Readiness Audit process reveals not only the company's technological infrastructure but also the competencies of its employees and the suitability of its processes for AI.

In the subsequent phase, the goal is to achieve quick wins before diving into large-budget, long-term projects. Organizing a short-term Discovery Sprint brings business units and technical teams to the same table. In this collaborative effort, small-scale projects that can be implemented within a few weeks and will directly impact the business are identified.

From a broader perspective, management needs strategic support for this transformation to be sustainable. Companies can organize an Executive Workshop to clarify the leadership team's vision or seek external guidance through a Transformation Retainer model to manage the long-term roadmap. Some organizations even prefer to create an Advisory Board Seat to ensure that decisions are made impartially and with a business focus.

What you should do next week Before making your AI decision next week, you can apply a simple test in your meeting with your tech manager. Don't ask them about technical details, which models they will use, or database integrations. Instead, ask the following questions:

• Which specific step in our operations team's daily working routine will this AI tool we are developing eliminate?
• When this new system goes live, how much freed-up time are we targeting in the weekly working hours of the employees in the relevant department?
• How will we manage employee resistance to the business process changes this transformation will bring?

If the answer you receive is about system architecture, API costs, or technical libraries, you need to realize that your transformation is stuck within the confines of the tech department. The solution is not to blame your tech team, but to build the bridge that will combine their technical power with the right business strategy. The first thing you need to do is put the business process on the table, not the technology.