CM-301h · Module 3

Converting IT from Gatekeeper to Partner

4 min read

The standard relationship between a business-led AI initiative and IT is adversarial by structure. The business unit wants to move fast. IT's job is to control risk. The business unit presents the AI tool to IT for approval. IT finds problems. The business unit escalates. IT approves with conditions. The conditions create delays. The business unit concludes that IT is obstructionist. IT concludes that the business unit is reckless. Both conclusions are partially correct.

The change management win is not getting IT to say yes faster. It is getting IT involved early enough that they help design the solution — before the solution is built, when their input can shape the architecture rather than veto it.

IT consulted in the design phase becomes IT that owns part of the outcome. When the AI tool's integration architecture was designed with IT input, IT has a structural reason to want the integration to succeed. When IT was presented with a finished integration to approve, IT has no ownership stake in the outcome and every structural incentive to find the risks that protect them if it fails.

The behavioral shift from gatekeeper to partner requires one thing: being invited to the design conversation before the design is complete. Not the approval conversation. The design conversation. This means involving IT before the tool is selected, before the integration is architected, before the use case is fully defined. Most business-led AI initiatives do not do this because they anticipate IT resistance and try to minimize IT's surface area. This strategy produces the resistance it tries to avoid.

Do This

  • Involve IT in the tool selection process: 'We are evaluating three AI vendors and want IT to assess the security and integration posture of each — what are your evaluation criteria?'
  • Give IT the architecture design authority for the integration components: 'We need the integration designed to work with our existing SSO and data architecture — can IT own that design?'
  • Schedule a standing IT working session for the duration of the AI initiative, not one-time approval meetings
  • When IT identifies a problem, treat it as a design input, not an approval obstacle: 'IT has flagged a data residency issue — let's incorporate their solution into the architecture'

Avoid This

  • Present a finished AI initiative to IT for approval — by the time IT sees it, the architecture decisions have been made and their only available move is to find problems with what exists
  • Minimize IT's involvement to reduce friction — the friction is structural and minimizing involvement does not eliminate it; it concentrates it at the approval stage where it has the most impact
  • Escalate IT concerns to executive sponsors as the primary intervention strategy — executive pressure produces compliance without ownership, which produces an approval followed by implementation obstacles