Introducing AI to your team without panic

Introducing AI to a team is partly a practical job: accounts, rules, training. It's also a conversation about people's work, and people bring their worries to it. Some will be excited. Some will be sceptical. Some will be quietly anxious about their jobs, about being monitored, or about being expected to do more for the same pay.

This guide helps you introduce AI in a way that is honest about what you know and what you don't. It covers the worries you're likely to hear, what to say and not say, a sample announcement, and a set of questions staff commonly ask with ways to answer them.

Start with what you actually know

Before you say anything to your team, find out the facts. You'll be asked, and "I don't know" is fine once. It isn't fine on things you could have checked.

Find out from your leadership, IT and HR:

• Why the organisation is introducing AI. What problem is it meant to solve?
• Which tools, on which accounts, and what they're approved for.
• What the rules are, or when they'll be ready.
• What's logged or visible to administrators. Ask IT directly what they can see.
• What training will be offered, and whether there's time set aside for it.
• Whether there are any plans that affect roles, and what you're allowed to say about them.

If the answer to the last question is "nothing has been decided", find out whether that's genuinely true or whether decisions are being made that you haven't been told about. Either way, you can only pass on what you know.

The worries you're likely to hear

Job security

This is often the biggest one, even when nobody says it out loud. People have seen headlines about AI replacing jobs, and they'll be wondering what it means for them.

The honest position depends entirely on your organisation, and you should not assume either way. Don't say "AI will never replace anyone here" unless you know that's true and have the authority to promise it. Equally, don't hint at changes you know nothing about.

What you can usually say truthfully is what the tool is being introduced to do, which tasks it's meant to help with, and what you personally know about plans for the team. If there are no plans affecting roles that you're aware of, say exactly that: "I'm not aware of any plans to change roles because of this." Then say who could answer the question more fully.

Surveillance

Some people will worry that AI tools let the organisation watch what they type, measure how productive they are, or read their drafts. Take this seriously. It's a reasonable question about any new workplace tool.

Find out from IT what administrators can see before you answer. The answer depends on the product and how your organisation has set it up. With Microsoft 365 Copilot Chat, for example, Microsoft's documentation explains how enterprise data protection works when people sign in with a work account, and how the organisation's own permissions and sensitivity labels apply. Your IT team can tell you what that means in practice for your organisation.

Then tell your team plainly what you've learned. If some activity is logged, say so. If the organisation has decided not to use the tool to monitor individual performance, and you've been told that, say that too. What damages trust is saying "nobody can see anything" and being wrong.

Expectations and workload

People may worry that if AI makes a task quicker, they'll simply be given more work, or that targets will go up. Others worry that learning a new tool is extra work on top of an already full week.

Both are fair. Learning takes time, and checking AI output takes time too. Some tasks won't get quicker at all. Be honest that you don't yet know how much time it will save, because nobody does until it's been tried and measured. The guide on whether AI is actually saving time explains how to find out.

If you can, set aside time for learning, and say so. "Take an hour this week to try it on something real" is more convincing than "we expect everyone to get to grips with it".

Permission to experiment

Some people won't try the tool because they're afraid of doing it wrong, or of looking foolish. Others will use it for everything without thinking about whether they should.

Give clear permission to experiment within guardrails. Name some low-risk tasks to start with. Say that it's fine if something doesn't work, and that you'd like to hear about it. Share your own attempts, including the ones that went badly.

Guardrails

People are more comfortable with a new tool when they know where the edges are. Before the introduction, have at least interim rules on:

• which tools and accounts to use
• what information can and can't go in
• what needs checking, and by whom
• who to ask, and what to do if something goes wrong

The simple team AI rules guide has a one-page template. Your organisation's policy and approved tools still take priority.

Transparency

Say what you're doing and why. Share the rules. Share what you learn from trying it, including what didn't work. If something changes, tell people before they hear it elsewhere.

What to say and what to avoid

A sample announcement

Adapt this to your team and your organisation's actual situation. Remove anything that isn't true for you.

Notice what the announcement doesn't do. It doesn't promise time savings. It doesn't say jobs are safe forever. It doesn't claim nothing is visible. It says what Priya knows, and says where she'll come back with more.

Questions staff commonly ask, and how to answer them

These are questions you're likely to hear. The answers are approaches to adapt. Fill them in with what's true in your organisation.

"Is this about cutting jobs?"

If you know there are no plans: say so, in the words you've been authorised to use. "I've asked, and I'm not aware of any plans to change roles because of this."

If you don't know: say that honestly and say who does. "I don't know the answer to that, and I don't want to guess. I'll ask Erin and come back to you by Friday." Then do it.

Avoid: "Don't worry about it." It sounds like you know something and won't say.

"Can you see what I type into it?"

Give the answer IT gave you, in plain words. If you haven't asked yet, don't guess. "I'll find out exactly what's logged and tell the whole team." If some usage data is visible to administrators, say who can see it and why.

"Do I have to use it?"

Be clear about the actual expectation. If it's optional, say so. If the organisation expects people to try it, say that, and explain the support available. It's reasonable to expect people to try a new tool. It's not reasonable to expect them to use it on tasks where it doesn't help.

"Will my targets go up?"

Say what you know. If nothing has been decided, say that, and say that any change would be discussed first. Point out that you'll be measuring whether it actually saves time before anyone draws conclusions.

"What if it gets something wrong and I send it?"

Be honest: the person who sends something is responsible for it, whether AI drafted it or not. Then say what that means in practice: check against the source, ask if unsure, and tell you quickly if something goes wrong. Make clear that reporting a mistake is the right thing to do.

"Can I keep using my own ChatGPT account instead?"

Explain the rule and the reason. Personal accounts on consumer tools may be under different terms from work accounts, and the organisation can't support or oversee them. If there's a genuinely useful thing someone can only do in another tool, ask them to tell you, so you can raise it with IT.

"I don't trust it. Is that OK?"

Yes. Some scepticism is healthy, because AI tools do make mistakes. Ask what specifically concerns them. Their concerns may be exactly the checks the team needs. Invite them to try it on a low-risk task and judge for themselves.

"Will customers know we used AI?"

Explain your rule on disclosure. A sensible starting point is that anything sent to a customer is checked and approved by a person, sounds like your organisation, and is disclosed where the customer would reasonably expect to know. Your organisation's policy decides the specifics.

I'm a manager introducing an AI tool to my team next week. Here is what I know: [the tool and accounts, why it's being introduced, what the rules are, what IT told me about logging, what I know about any plans for roles]. List the ten questions my team is most likely to ask. For each, suggest an honest answer based only on what I've told you. Where I don't have enough information to answer honestly, say "You need to find out:" and name what to check and who might know. Do not invent reassurances. UK English.

Use the result to prepare. Check anything it suggests against what you actually know.

After the introduction

The first announcement is the start. What happens in the following weeks matters more.

• Keep it on the agenda. A short item at each team meeting for the first two or three months: what's working, what isn't, any near misses.
• Share what you learn. Good prompts, tasks that didn't work, errors caught by checking.
• Follow up on questions. If you promised to find something out, report back, even if the answer is "still not decided".
• Measure before you conclude. Don't announce savings until you've measured them.
• Update the rules. Tell people what changed and why.

Common mistakes

Over-selling. Promising big time savings sets you up to lose trust when some tasks turn out slower.

Promising what you can't guarantee. Reassurance you can't back up does more harm than an honest "I don't know yet".

Leaving out the rules. Introducing a tool without saying what can go in it leaves people guessing about data.

Forgetting the sceptics. The people who don't like it often spot the problems first. Listen to them.

Making it compulsory for everything. Some tasks are better done by hand. Say so.