Where does AI rollout risk belong in your risk register?

AI data security causing headaches? Before you log “employees sharing data with AI” as a people problem, check who handed them the AI in the first place.

When someone pastes sensitive information into an AI tool, the reflex is to file it under misconduct. Policy breached, person at fault, fix is a reminder (or, heaven help us, more training).

The Oh, Behave! 2026/27 data points to a different reading. The report finds that AI adoption has outpaced AI governance, and this risk sits squarely in that gap. That changes where it belongs in your risk register, as well as what will actually reduce it.

Employers opened the door

We surveyed 5,000 adults across the UK, US, India, Brazil and Singapore this year. Half of all respondents use AI at work. Of those, 41% started doing so on their own initiative, while 44% started because their employer required or encouraged it. In the UK, 49% were encouraged by their employer.

So basically, someone opened the front door and asked people to walk through it. Fair enough, but that comes with a job attached.

The guidance didn't follow

52% of working AI users have had no AI security or privacy training. 24% say their employer never explained what it’s OK to share and 19% say it was unclear.

The message people received was “use this”. Far fewer received the message “and here's what not to put in it”.

The result: sensitive information, out of sight

Across the five countries, 32% of people who use AI at work have shared sensitive company information with it without their employer knowing. Of those who shared, 50% said internal documents or customer data and 47% said financial data.

Put that next to the numbers above and a pattern appears: people were asked to use AI, but weren't shown where the boundaries were. So, without clear guidance, people had to draw the line themselves. And when nobody hands out the ruler, that line comes out a little wobbly.

Where AI data security goes in the risk register

How you frame a risk decides how you treat it.

When it’s logged as people misbehaving, the treatment is discipline and reminders, and the root cause stays exactly where it was. Whereas when it’s logged as a gap in how the organisation managed a change, the treatment is a control the organisation owns (and – importantly – can put in front of an auditor).

A register entry might look like this:

• Risk: sensitive company information is entered into AI tools without the organisation's knowledge.
• Cause: AI tools adopted, often at the organisation's encouragement, without clear guidance on what can and can't be shared.
• Owner: the AI rollout owner. Control owner: the security team.
• Existing control: an AI policy that people acknowledge.
• Gap: people don't know where the lines are in practice, for the tools they actually use.

This framing is also easier to take to the business, because it doesn't accuse anyone. It says the organisation changed how work gets done and needs to finish the job. Most leaders can live with that.

The missing control: worked examples

The report's recommendation is simple: go beyond policy acknowledgement and give people concrete examples of what's OK to share and what isn't.

A signed policy proves someone saw a document. It doesn't prove they can tell whether a customer email, a draft contract or a spreadsheet of sales figures can go into a prompt. (Ask three people in your organisation …we'll wait.)

Concrete examples close that gap. In practice, that means:

• Examples tied to your tools: A short set of “fine” and “not fine” cases for each AI tool you've approved, using the kinds of information your people actually handle.
• Guidance shipped with each rollout: Every new AI tool arrives with its examples on day one, rather than six months later after an incident.
• Guidance at the point of use: Help where people actually use AI, not tucked away in the annual module.

Evidence that holds up with your CISO and your auditors

Whatever framework you map to – whether that's ISO 27001, DORA, NIS2 or your own internal version – the questions tend to be the same. Is the risk identified and owned? Is there a control? Can you show it works?

Here’s the evidence that answers them:

• Coverage: every approved AI tool has usage guidance and examples, with the date each was issued.
• Understanding: people can sort realistic examples into “OK” and “not OK” in a short scenario check, rather than just attesting to a policy.
• Behaviour: a trend in risky sharing over time, from regular pulse surveys or from your tooling where you have it.
• Process: new AI rollouts can't go live without the guidance step, so the control keeps working after you've stopped looking at it.

Training completion still has a place, but as an input. On its own, it shows people sat through something, but it doesn't show that the risk went down.

A small change with a clear payoff

This doesn't need a new programme: the evidence can come from existing reviews and rollout sign-offs. What it does need is one honest register entry, a named owner and a guidance step built into the next AI rollout.

‍

What you get back is a risk you can explain, a control you can evidence and fewer surprises for everyone …including the people who were only doing what they were asked.

Read the full Oh, Behave! 2026/27 report for the complete AI findings, including the UK figures.

‍