The IT Gatekeeper

IT resistance to AI initiatives comes in three distinct forms, and the change manager who treats them as a single phenomenon will apply the wrong intervention to each of them. Distinguish first. Respond second.

The first form is genuine security concern. IT has evaluated the AI tool's data handling practices and identified a real vulnerability: data leaves the organizational perimeter in a way that violates policy, the vendor's security certifications are insufficient for the data sensitivity, the access control model creates audit trail gaps. This concern is legitimate and must be resolved with a security answer, not a communication strategy.

The second form is process protection. The AI initiative creates work for IT: integration development, security review, vendor due diligence, infrastructure provisioning, ongoing incident response. IT's resistance is not to the AI — it is to the unplanned workload the AI creates without accompanying resource allocation. This is a resource negotiation problem, not a security problem. It is solved by including IT in the project plan with explicit resource commitments, not by improving the communication of the AI initiative's value.

The third form is authority defense. The AI initiative was not IT's decision. It was brought in by a business unit, possibly without IT consultation, and IT's first contact with it is being asked to approve it. IT finds problems. This is not because problems exist — it is because finding problems is how IT reasserts its authority over technology decisions that bypassed its review. The intervention is structural: involve IT in the design, not the approval.

1. Diagnose the resistance type Ask IT to specify the concern in writing. Genuine security concerns produce specific, technical, actionable concerns: 'The vendor's data retention policy does not specify deletion timelines for customer PII processed through the model.' Process protection resistance produces workload concerns: 'We don't have the bandwidth to review this in the current quarter.' Authority defense resistance produces procedural concerns: 'This should have gone through the architecture review board before evaluation.' The specificity and nature of the written concern diagnoses the resistance type.
2. Respond to the actual concern Genuine security concern requires a security resolution — documentation, vendor certification review, architectural modification. Process protection requires resource allocation — timeline adjustment, dedicated IT resource, or phased rollout that reduces IT workload concentration. Authority defense requires structural involvement — schedule the architecture review, give IT a formal role in the governance structure, treat the retroactive review as the legitimate process it is.
3. Do not attempt to manage legitimate concerns The most common mistake is applying change management communication techniques to genuine technical concerns. Empathy statements and stakeholder engagement strategies do not resolve a data handling vulnerability. They produce the impression of responsiveness while the legitimate concern festers. IT recognizes the technique and it damages credibility. Resolve the concern. Then apply the communication.