There is a scene that repeats itself when a company finally writes its AI use policy. The document exists, management has approved it, it has been signed, and then someone sends an email to the team with the subject line: “new policy on the use of digital tools.” No one opens it, and two weeks later, everything is still working exactly as before. The work that went into drafting the policy has achieved very little because it has been treated as another procedure to file away.
The communication failure almost always comes down to the same thing. The policy is presented as a list of things people cannot do, when its real purpose should be to provide a framework for making better decisions. This mismatch between what a policy is and how it is presented explains much of the resistance that is later, and often unfairly, attributed to a lack of willingness on the part of the team.
Why policies are perceived as bans
The language of regulation naturally tends towards restriction. A sentence such as “Do not use customer data in external tools without a signed data processing agreement” may be correct and necessary, but it sounds exactly like what it is: a ban.
When there is no context, the instinctive reaction is often defensive, because the policy is perceived as a form of control, a lack of trust, or simply more work required to keep doing the same job. That reaction is the logical consequence of communicating the “what” without explaining the “why.”
The change in framing that transforms everything
The same policy can support two very different ways of communicating. It can be presented as a rule: “The use of AI tools with customers’ personal data is prohibited without prior authorization.” Or it can be presented as a criterion: “When you use AI with customer data, this is the question you need to ask yourself, and this is the process that protects you if something goes wrong.”
The content is essentially the same, but the context changes completely, and so does the team’s reaction. The first version creates resistance because it sounds like someone is watching what you do. The second creates a sense of security because it gives people something that protects them.
A policy that the team understands as a form of self-protection is more likely to be followed. One that is perceived as a way for the company to control people’s behaviour is more likely to be ignored when no one is watching.
Start with the problem it solves
Before presenting the policy, explain the problem it solves for the team, not just for the company in the abstract.
What happens when someone uploads customer data to a tool that stores that information on servers outside the EU without realising it? What happens when IT discovers that there are ten AI tools being used across the company that no one has evaluated?
This problem does not only affect the organisation. It can also expose an individual employee who may have used the tool without realising the risks. Once people understand this, the policy stops feeling like an imposition and starts to feel like a safeguard.
Explain the criteria, not just the rules
The team needs to understand the reasoning behind each restriction so that they can apply it to situations that the policy does not explicitly cover, which will be the majority of situations they encounter in their day-to-day work.
A policy that only provides rules creates dependency because it forces people to ask what to do every time a new situation arises. A policy that provides criteria does the opposite: it allows people to make informed decisions in scenarios that no one has specifically written down.
That is the difference between a document that ends up sitting in a drawer and one that the team actually uses.
Give concrete examples from everyday work
Abstract examples do not resonate. The examples need to come from the actual work people do.
If the sales team wants to use an AI tool to prepare personalised proposals, the policy should explain what data can be used and under what conditions.
Examples based on what people actually do every day turn the policy into something practical, rather than a theoretical document that no one knows how to apply to their own situation.
Provide a clear channel for questions
One of the reasons policies end up gathering dust is that the team does not know who to ask when they encounter a situation that is unclear.
A simple channel for questions, whether that is a designated person, an email address or a form, reduces friction and encourages adoption. It shows that the policy is a living framework that people can turn to, rather than a closed document that is signed once and then forgotten.
How you communicate it matters more than when
Communicating a policy through a mass email is probably one of the least effective ways to do it, because policies are internalised through conversations, not documents.
A short 30-minute session in which someone explains the reasoning behind the policy, answers questions and gathers feedback from the team can generate far more engagement than the best-written PDF in the world.
This does not mean organising a complex training programme. It means making real time for conversation rather than focusing only on the wording of the document. That conversation is, almost always, what separates a policy that simply exists from one that is actually put into practice.
Frequently asked questions
How can I introduce an AI policy to the team without creating resistance?
Frame it as a set of criteria that protects the team, rather than as a list of restrictions. Adoption improves when people understand the concrete problem the policy solves for them, not just for the company in the abstract. It is therefore advisable to start with real situations that arise in their day-to-day work.
Should I involve the team in creating the AI policy?
If possible, yes. Policies developed with input from the team tend to generate greater buy-in and are more realistic about what actually happens in practice.
Even when the policy is defined by management, communicating it properly and explaining the reasoning behind it works consistently better than simply distributing it as a finished set of rules.
What happens if the team ignores the AI policy?
When a team ignores a policy, the problem is usually related to communication or perceived relevance rather than a lack of willingness. A policy that is not understood, or that feels disconnected from people’s daily work, is unlikely to be followed.
The answer is not necessarily to make the rules stricter, but to review how the policy was communicated and how closely it is connected to what the team actually does.
