IT and AI teams: how to end the conflict between them

IT and AI teams often share the same budget and the same executive under the label of technology, while working toward opposite priorities. IT answers for control, standardization, and risk reduction. The AI team answers for experimentation, flexibility, and fast learning. Without a rule that reconciles the two, each one slows the other down, and the organization pays on both sides: AI projects that never reach operations, and controls bypassed by parallel tools.

Graham Kenny, Kim Oosthuizen, and Ganna Pogrebna, who advise companies through this transition, describe three recurring disagreements: what counts as data, who has the competence to decide, and whether existing systems can carry what AI wants to build on top of them.

Why do IT and AI teams clash?

Each team was built for a different risk. IT spent decades keeping critical systems running, and its processes exist to prevent failure: approved changes, separate environments, audit trails. The AI team exists to find out what works, and it measures its own work by the number of hypotheses tested and the speed at which a model reaches users. Both logics have good reasons behind them, and each team sees the other through its flaw: IT sees AI as uncontrolled risk, and AI sees IT as an obstacle.

The disagreement costs more when nobody has the authority to settle it. At a bank with 36,000 employees, both functions reported to the same general manager, an arrangement that looked efficient and left every dispute unresolved until late in the project. Two cultures formed, with duplicated tools, inconsistent rules, and greater exposure to risk. Innovation stayed in isolated projects that never scaled, and control weighed on all of them.

What counts as data

For IT, data is what fits in tables and columns, with an owner, a dictionary, and an access rule. Generative AI and AI agents work on different material: customer service transcripts, contracts, emails, service notes, and workflow logs. At a conglomerate that operates in financial services, logistics, property, and retail, the head of AI summed up the divide by saying that IT did not recognize the qualitative, conversational material the models used as data. Business units closer to the customer began operating under one definition, and IT under another.

The company settled the question at the leadership level. It formally expanded the enterprise data inventory to include unstructured sources, classified as strategic assets with the same standing as structured databases, and extended its existing data standards to them. IT gained the controls it needed over that material, and the AI team began working with recognized data. The company also required every AI application to sit inside an existing workflow, such as the customer service queue or claims assessment, instead of running as a separate system.

Keeping that material in good shape is work of its own, covered in the article on unstructured data and generative AI.

What to do: add to the data inventory the unstructured sources your AI projects already use, each with an owner, a sensitivity classification, and a retention period, under the same standards that apply to databases.

From competence to accountability: who answers for what

At the bank, the argument began as a dispute about competence. A senior IT manager argued that the AI team lacked the fundamentals and delivered systems without dashboards, governance, or auditability. The head of AI replied that IT treated every initiative as a compliance risk before understanding its purpose, and that the AI team was asking to be brought into governance earlier, so it could design for auditability from day one.

The bank started with structure. It separated the head of AI and head of IT roles, which had reported to the same general manager. IT kept infrastructure, cybersecurity, resilience, and compliance controls. AI took model development, experimentation, and the deployment of AI products, always inside the bank's security and regulatory environment.

Next, it created a mandatory taxonomy, based on the distinction Thomas Davenport and Peter High described in HBR in December 2024. On one side sits analytical AI: machine learning, predictive models, and decisioning systems whose outputs must be explainable and auditable. On the other, generative AI, which produces text, summaries, and conversational responses with a different risk profile. Every project intake form, risk template, and reporting pack had to state which branch applied. Analytical AI stayed in auditable domains such as fraud, credit, and pricing, and generative AI in lower-risk tasks such as drafting and summarization, with additional controls for higher-risk uses. IT's resistance eased once it saw that much of the AI work already sat close to the governance world it knew.

Finally, the bank rewrote its job descriptions. Data engineers, data scientists, machine learning engineers, AI product owners, and IT had overlapping remits, and several teams believed they owned model development, deployment, or validation. With the roles redefined, the handover points between them became visible. Organizations looking for an external reference for this division can use ISO/IEC 42001, published in December 2023, which specifies the requirements for an AI management system, established, maintained, and improved like the organization's other management systems.

What to do: write your organization's AI taxonomy, with the branch and control level of each use, and a role matrix that states, for each stage of a model's life cycle, who develops, who validates, who deploys, and who approves the move from one stage to the next.

Three classes of use case, by the foundation they need

A telecommunications operator with 9,200 employees met AI in the middle of a consolidation program. IT had accumulated decades of layered systems, point-to-point integrations, and end-of-life infrastructure, and critical functions still exchanged data through flat files between platforms never designed to talk to each other. The AI team trained its own large language model on internal archives and began testing it on several fronts, from drafting documents to predicting network faults and customer churn.

The first cases, low-risk and with no contact with operations, worked. The next ones depended on real-time data, and models that performed well in testing degraded or failed in production because the data arrived fragmented, inconsistent, or late. The AI team blamed IT's slowness, and IT blamed AI's haste to build on an unstable base.

The operator split its portfolio into three classes. The first holds low-foundation cases, such as drafting documents, searching internal policy archives, and knowledge tools, which create value on a controlled set of documents with usage rules and human review. The second holds cases that need cleaner data without intervening in operations, such as customer sentiment analysis, whose outputs are treated as signals for human decisions. The third holds critical cases, such as network fault prediction, churn intervention, and automated customer response, which require stable data pipelines, consistent identifiers, and real-time monitoring.

The company connected the AI roadmap to the IT consolidation roadmap through a single dependency map, showing which AI ambitions relied on systems not yet stable. The question shifted from "is IT blocking innovation?" to which cases could proceed now, which needed a foundation upgrade first, and which should stop. Projects that sounded modern and solved no defined problem were halted.

What to do: place each use case in your portfolio in one of the three classes, and tie those in the third class to the milestones of the IT modernization plan in a single dependency map; a case that depends on an unstable system waits for its milestone, which has a date and an owner.

The same metrics for both teams

The conglomerate and the operator also changed how they measure. The conglomerate set up a joint accountability model, with shared governance structures and metrics tied to customer and business outcomes. IT still owns governance, quality, and compliance, and AI owns experimentation and workflow delivery, and both are assessed against the same commercial results. With a shared target, both teams gained a reason to move together.

The operator replaced activity metrics, such as prototypes launched and pilots running, with outcome and readiness measures. IT's consolidation work, expensive and largely invisible to the rest of the company, began to show up in business terms, and the AI program gained credibility. The outcomes chosen were concrete: earlier detection of network faults, fewer escalated complaints, and better churn alerts. Tying each AI project to a line of the income statement is the subject of the article on AI ROI.

What to do: remove the count of pilots and prototypes from the technology dashboard and replace it with two kinds of measure, the business outcome of each use case and the readiness of the foundation it needs, with both teams' targets set on the same numbers.

Conclusion

In all three cases, the conflict between IT and AI ended with decisions made above both teams. The conglomerate broadened its definition of data and applied IT's standards to it. The bank separated the leadership roles, classified AI by risk, and rewrote job descriptions with the handover points in view. The operator ranked use cases by the foundation each one needs and tied the AI roadmap to the modernization plan. The conglomerate and the operator began measuring both teams by business results. The first step is an inventory: of the data AI uses, of the overlapping roles, and of the use cases, with the class of each one.

These decisions rest on the service management governance IT already practices, and it pays to measure where the organization starts before redesigning it. Takter's ITIL® Maturity Journey is an objective assessment of service management capabilities and of the maturity of the service value system (SVS), including governance, practices, and continual improvement, and it links governance to business metrics.

Sources

• Graham Kenny, Kim Oosthuizen, and Ganna Pogrebna, AI and IT Teams Often Clash. But They Don't Have To., Harvard Business Review, July 2026.
• Thomas H. Davenport and Peter High, How Gen AI and Analytical AI Differ, and When to Use Each, Harvard Business Review, December 2024.
• ISO and IEC, ISO/IEC 42001:2023, Artificial intelligence: Management system, December 2023.