The IT and security conversation

Most AI enablement leads hit IT and security at some point, and it often feels like a wall. A request to try a new tool sits in a queue for weeks. A workflow involving customer data gets a flat no. A session is cancelled because "security haven't signed it off". It's easy to conclude they're against the whole idea.

Usually they're not. They're responsible for things going wrong, they've often been brought in late, and they're being asked to approve something whose risks are genuinely new and still moving. What they need is a partner who understands their concerns, brings them information rather than pressure, and makes their job easier. This playbook is how to become that partner, ideally before you need anything from them.

Before the conversation: do your homework

Go in knowing what's already decided. Find out:

• Which AI tools are approved today, under which accounts, and whether anyone's checked what employees are using unofficially.
• Who owns what. IT may own tool deployment and identity; security owns risk assessment; a data protection lead owns personal data questions. They're sometimes the same person and sometimes three teams.
• Existing policies: acceptable use, data classification, third-party risk, incident reporting. AI work should fit into these rather than invent parallel processes.
• What they've already said. If there's been a security note about AI, read it. Repeating something they've already answered doesn't help.

Then write a short summary of your programme from their point of view: which tools you're focused on, which teams, what kind of data the workflows involve, and what you're asking people to do. Half a page is enough.

The first conversation: listen first

Book forty-five minutes with the relevant leads. Open with the aim, not a request:

I've been asked to get people using AI well. I want to do that in a way that doesn't create problems for you, and I'd rather understand your concerns now than find out later. Can I tell you briefly what I'm planning, and then hear what worries you?

Spend no more than five minutes on your plan. Then ask:

1. What are you most concerned about with AI use here, today?
2. What do you already know about how people are using it, including tools we haven't approved?
3. What's your process for assessing a new tool or a new use, and how long does it usually take?
4. What would you need from me to make that process quicker or easier?
5. Is there anything you'd like people to be told that they aren't being told now?

The concerns you'll probably hear

You don't need to resolve these yourself. You need to understand them well enough to design around them and to know who answers each one.

• Data leaving the organisation. What goes into the tool, where it's processed and stored, and whether it's used to train models. This is answered by the vendor's terms and your agreement with them, not by you.
• Unapproved tools. People using personal accounts or browser extensions because the approved option is slow or missing. Security usually sees this as a bigger risk than the approved tool.
• Access and permissions. Tools that connect to email, files or internal systems can surface information to people who technically had access but never would have found it. Permissions that were "fine because nobody looks" stop being fine.
• Output risk. Inaccurate content going to clients, code with vulnerabilities, or decisions about people made with AI help.
• Incident handling. What happens when someone pastes something they shouldn't, and how it gets reported.
• Vendor change. Terms, features and defaults change. Something assessed six months ago may behave differently now.

When you hear one of these, ask the follow-up: "What would make you comfortable?" Sometimes the answer is a setting, sometimes a policy line, sometimes training. Sometimes it's "nothing yet", which is a clear answer you can work around.

What to offer them

You'll get more help if you bring something useful. Offer:

• A channel. "Anything you want staff to know about safe AI use, I'll include in sessions and guides." Then do it.
• Early visibility. Share your workflow list before you start each one, with a line on what data it involves. Let them flag concerns before a team is enthusiastic about something they'll have to stop.
• Intelligence. You'll hear about unapproved tool use, risky habits and confusing policies long before they do. Agree how to pass it on without getting individuals in trouble.
• Help with the policy. Offer to write the plain-English version (see Writing a one-page AI usage policy), with them owning correctness.
• A named point of contact on your side, so they're not chasing a programme.

Agree a working arrangement

By the end of the first or second conversation, agree something simple in writing. It doesn't need to be formal. A short note covering:

Approved tools and accounts: [list, with owner]
Fine without asking: [kinds of workflows and data]
Needs a quick check: [kinds of workflows and data, who to ask, expected turnaround]
Needs a full assessment: [new tools, integrations, personal data in volume]
How we report incidents: [route, and the "you won't be in trouble for reporting" principle]
How we stay in touch: [e.g. monthly thirty minutes, plus workflow list shared in advance]

When the answer is no

Sometimes you'll get a no on a workflow or a tool. Handle it well:

• Ask what would change it. "Is that no for now, or no for this use? What would need to be true?"
• Ask for the reason in writing, so you can explain it to the team. "Security said no" breeds resentment. "We can't use client contracts in this tool because of [reason]" is a guideline people can work with.
• Offer an alternative. Often the same workflow works with redacted material, a different data set, or a narrower step.
• Don't escalate straight away. If you need a decision overturned, go through your sponsor, after you've understood the reasoning, and only for things that really matter.

Mistakes to skip

• Arriving with a request and a deadline. You've made them the blocker of your plan before they've heard it.
• Interpreting vendor terms yourself. You'll get something wrong. Ask them to, and pass on their reading.
• Going around them. A team using a tool security haven't seen is a short-term win and a long-term loss of trust.
• Hiding unapproved use. If you know it's happening, they need to know too. Agree how to raise it without naming people.
• Treating sign-off as permanent. Tools change. Agree a review rhythm.

At the end you should have

• A clear picture of what's approved, who owns which decisions, and the existing policies AI fits into
• A list of IT and security's real concerns, in their words
• A written working arrangement with three tiers: fine, quick check, full assessment
• A regular slot and an agreed way to share your workflow list in advance
• Their key messages built into your sessions and guides

The free maturity scorecard includes governance questions that are worth running past your IT and security leads together. The Role Book covers the full governance track over 90 days, including the working arrangement template and how to handle new tools and integrations as the programme grows.