Executive Summary
The hidden barrier to AI adoption is department heads’ legitimate fear that if an AI initiative succeeds, credit for the result will go to the AI team instead of the business unit that redesigned its own operating model.
Core conclusions
- Resistance is rational, not irrational: credit displacement, loss of control, and dependency fears are well-documented drivers of opposition to organisational change, even when the change itself is beneficial.
- The fix is structural, not motivational: dual sponsorship (business and technical), a business-unit Product Owner with real authority, and shared KPIs that attribute improvements jointly rather than to “the AI team.”
- Communication and capability transfer matter as much as governance: credit-sharing language, co-authored case studies, and an explicit plan for the department to own and operate the AI-enabled process reduce the status loss driving resistance.
The argument, in ten slides
Save it, share it, or send it to the department head who just asked “why should my team help you?”
In many organisations, AI leaders are encountering a subtle but significant form of resistance. It is not open objection to the technology, nor a lack of ideas. Instead, it often surfaces as a question from business leaders:
“Why should my team help you build this?”
Behind that question sits a legitimate concern about ownership, recognition, and control. Department heads recognise that AI initiatives can materially improve productivity and service, but they also sense a risk: if the programme succeeds, the narrative may become “the AI team delivered this result” rather than “the department transformed its operating model with AI”.
This dynamic, a perceived loss of credit and status, is emerging as a structural barrier to AI adoption, particularly in organisations moving beyond pilots into embedded, operational AI.
Why Business Units Resist
Research on resistance to technological change consistently highlights loss of control, loss of status, and fear of dependency on others as key drivers of opposition, even when the technology is objectively beneficial. In many cases, department leaders are not resisting AI itself; they are resisting a shift in who appears to create value. Credit displacement is a core concern: the department invests time, subject-matter experts, and operational risk in AI experimentation, and when KPIs improve, internal communication highlights “the AI initiative” rather than the business unit’s leadership in redesigning work. Leaders worry that success will be framed as “operations were underperforming until the AI team stepped in”, implicitly diminishing existing leadership. When core decision flows or workflows are re-implemented through AI systems managed by a central team, departments fear becoming dependent on a capability they do not fully govern.
Standard IT project patterns often reinforce this problem. Many AI programmes are branded at group level (“AI Transformation”, “Enterprise AI Platform”) with success stories written from the perspective of the central team, not business sponsors. AI teams are measured on “number of use cases delivered” or “model accuracy”, while departments are measured on service levels, financial performance, safety, or compliance, with no explicit link between departmental performance reviews and AI collaboration behaviour. Business units are asked to allocate their best people to discovery workshops, data clean-up, and testing, while the value to those individuals’ careers and to the department’s standing is often vague or left implicit. Under these conditions, a rational department head may conclude that active engagement is a net political risk: all the disruption, but limited recognition and uncertain control.
Making AI a Co-Owned Asset
To reduce resistance, AI initiatives need to be framed and structured as co-owned assets where the business unit is the visible owner of the outcome, the AI team is the enabler and technical partner, and recognition structures clearly reflect joint success.
Co-ownership in governance and sponsorship. Every AI initiative should have a dual sponsorship model: a business sponsor (e.g. Head of Operations) accountable for the business outcome, and a technical sponsor (e.g. Chief AI Officer) accountable for technical robustness. Key milestones should require joint sign-off from both sponsors. Appoint a Product Owner or Use Case Owner from the business unit. This person controls the backlog, prioritisation, and acceptance criteria, with the AI team as delivery and advisory partner. This is the same tension between central AI capability and business-unit ownership I explore in Scaling AI Requires Capability, Not Centralisation.
Shared KPIs and incentives that reward collaboration. If AI success improves departmental KPIs but recognition flows primarily to the AI function, resistance is rational. For each AI use case, define a small set of core metrics and explicitly attribute improvements to both the business leadership that redesigned processes and the AI capability that enabled new automation or decision support. Incorporate an AI adoption dimension into leadership scorecards: quality and number of AI initiatives sponsored, degree of adoption, and documented impact on departmental outcomes. For senior SMEs and line managers who contribute significant time, recognise them as co-authors or co-owners of the solution in internal communications and external case studies.
Explicit credit-sharing and communication protocols. Departments are more likely to collaborate when they trust that success narratives will be shared fairly. Use language such as: “This transformation was led by the X Department, working with the AI team as technical partner.” Standardise case study templates where the problem statement and context come from the business unit, the redesign of the operating model is attributed jointly, and technical innovation is described as an enabler of the department’s vision. Acknowledge that the department took operational and reputational risk in experimenting with new approaches. This positions the department as innovative rather than as a passive recipient of technology.
Delivery and Psychology
Co-design rather than requirements handover. Use structured discovery sessions where process owners, frontline staff, and analysts jointly define pain points, decision logic, and practical acceptance criteria. This aligns with change management findings that resistance decreases when employees are involved early and meaningfully in the design of new technology.
Capability transfer as a core objective. Define an explicit objective that the department will own and operate the AI-enabled process, be able to interpret model outputs and performance metrics, and have clear levers to adjust workflow or reconfigure parameters without constant central intervention. Implement dashboards that show how AI initiatives contribute to departmental KPIs and organisational strategic objectives, issued under joint branding of the department and AI function. By shifting from “we will build a tool for you” to “we will build a capability with you that you will own”, the AI team reduces perceived dependency and status loss.
There is also value in acknowledging the psychological drivers upfront. Status is not at risk; it is enhanced: AI initiatives are evidence that the department is leading modernisation. Control is preserved through clear boundaries: define explicitly what remains under departmental authority (process design, risk appetite, service rules) and what is under AI team authority (model selection, MLOps, technical standards). Failure is treated as learning, not weakness. These messages must be reinforced through executive sponsorship. Senior leadership must demonstrate, through their own communication and recognition patterns, that departments partnering on AI are valued and not diminished.
Practical Steps for AI Leaders
-
Acknowledge the concern explicitly. Recognise that time and reputational risk are real costs to the department. State clearly that the intent is to elevate the department, not to centralise credit.
-
Propose a concrete co-ownership model. Offer a joint sponsorship and steering structure. Appoint a business Product Owner with real authority.
-
Align incentives and recognition. Work with HR and senior leadership to ensure that AI collaboration features in leadership evaluations. This is squarely the territory I cover in HR Leadership in the Age of AI. Ensure successful AI use cases highlight the department’s leadership in internal and external communications.
-
Make contributions and impact traceable. Maintain a contribution log capturing which teams provide data, SMEs, testing, and operational change. Use this log as an input to performance reviews and recognition.
-
Design for departmental capability, not dependency. Commit to a transition plan where the department can operate and interpret the AI solution with defined support boundaries.
The question “Why should my team help you?” often signals misaligned incentives and unspoken concerns about status and ownership rather than hostility toward AI. Treating it as a political or cultural obstacle to be overcome will only heighten resistance. Instead, AI leaders should consider this behaviour as a design requirement: incorporate co-ownership into governance, align KPIs and recognition so departments are rewarded for AI-enabled performance, and structure delivery and communication to make business units visibly lead, with AI as an enabling capability.
Free tool
Enterprise AI Value & Adoption Dashboard
Track adoption and impact by business unit so departmental leadership gets visible credit alongside the AI team.