There is a kind of AI resistance nobody names properly. It is not fear, and it is not general scepticism, and it does not require the person holding it to avoid AI themselves. It comes from someone who is entirely comfortable with a purpose-built AI system, specified once and left to run autonomously against a defined task, but who is quietly opposed to a person reaching for AI directly, on their own initiative, against data and systems that are already theirs to use. Call it the resistance. It has the same punch as calling the other side of this story an ally, a term I have used before: naming who is being built with also names who is not.
The resistance rarely says so out loud. What it protects is control over a capability, and the systems and data access behind it, whether or not the person doing the protecting would ever describe it that way. It is the old habit of requiring every use case to be specified, built, and signed off in advance, comfortable the moment AI is packaged into something that runs on its own, uncomfortable the moment a person is the one driving it directly. Prepackaged and constrained beats easy and quick, every time, and that preference rarely gets named as a preference.
Some of that caution is completely legitimate. Restricting access to a system that genuinely carries risk is not gatekeeping, it is governance, and I do not want to flatten the two together. The distinction that actually matters is between restriction as a safeguard and restriction as control. The cleanest tell I watch for is API access withheld from someone for their own profile, their own account, their own data. There is no governance rationale for denying a person programmatic access to something that already belongs to them.
That argument does not automatically extend to a customer's data. If someone has a legitimate business reason to work with a customer's information and access is still withheld, the question is not whether the data is theirs, it is not, it is whether the restriction is proportionate to the actual risk and applied consistently regardless of who is asking. Customer data carries real stakes that a person's own profile does not, and the safeguard case for restricting it can be entirely genuine. The tell there is the same as anywhere else: does the objection hold up once the stated risk has actually been addressed, or does it just move to a new reason?
Here is a version of that test I use directly. If someone can already export a report to Excel, what is actually different about giving them programmatic access to the same report so their AI can use it? Usually nothing, and often the AI-mediated path is the more governable one, not the less. An export sits in a spreadsheet indefinitely, copied, forwarded, and out of anyone's sight the moment it leaves the system. Access built properly, gated through existing identity and scoped to a single query, does not have to leave a permanent copy anywhere at all. Restricting the path that is transient and logged while leaving the one that produces a permanent, ungoverned file wide open is not a security decision. It is a comfort decision dressed as one.
None of this removes the risk. Any access, exported or programmatic, can be misused, and I am not claiming otherwise. What justifies choosing the AI-mediated path anyway is not that it is safer in some absolute sense. It is that it buys real efficiency, work done faster, by more people, at a lower ongoing cost, and that gain is worth carrying a risk that already existed in a less examined form.
If you manage people and you notice someone who is entirely at ease with a purpose-built AI system running against a dataset, but quietly against a person on their own team reaching for AI directly against that same data, that is worth naming plainly rather than filing under general resistance to change. Ask what the restriction is actually protecting, and whether the answer survives being said out loud.