How we ACTUALLY decide whether an AI tool is safe to use

Every AI tool looks amazing in a demo just now.

It’s quick, impressive, and usually accompanied by a reassuring claim about being “enterprise-ready” or “secure by design”. In isolation, that’s often true. But the demo isn’t where the risk lives.

The risk shows up later, once the tool is embedded in day-to-day work. That’s when real people start using it with real data, often under time pressure, inside an organisation that still has to answer to customers, board members, auditors, and regulators.

Over the last couple of years, I’ve been involved in assessing tools for use across the entire organisation. Not as an academic exercise, but in environments that already have to stand up to ISO audits, SOC 2 scrutiny, and increasingly direct questions about AI governance. I wanted to share how these decisions actually get processed, not the policy version of those decisions.

We start from caution, not optimism

That doesn’t mean we’re anti-AI. It means we’ve learned that starting from enthusiasm tends to hide the things that matter most. The phrase I most commonly follow is a derivative of Maya Angelou’s “Hope for the best, prepare for the worst”.

The first conversation is rarely about features or productivity gains from our side. It’s about exposure. We try to understand what new risk this tool introduces, what data could realistically end up in it, and what would be uncomfortable to explain later if something went wrong.

If those answers are vague or hand-waved away, that’s usually a sign that we don’t understand the tool well enough yet. At that point, slowing down is the responsible choice.

Of course, that’s not to say that we’re driving the first conversation, typically the very first conversation is the qualification conversation for the sales person…! Typically we take control in the “anything to ask before we schedule the follow up?” slot to fire in the first salvo of queries.

We follow the data, not the narrative

Most vendors tell a similar story:

“We don’t train on your data.”

“Your data is secure.”

“We’re trusted by over 20 customers.”

Those statements might all be true, but they’re rarely specific enough to be useful.

What actually matters is how data moves through the system in practice. Where it’s processed, how long it’s retained, who can access it, and what happens when you want it removed. These details are rarely exciting, but they’re where governance lives.

When those answers aren’t clear or change depending on who you ask, it’s not a paperwork problem. It’s a signal that the risk hasn’t been fully thought through.

Context is the risk multiplier

One of the easiest mistakes to make is treating an AI tool as inherently safe or unsafe.

In reality, context matters far more than capability. The same tool might be perfectly reasonable in one part of the organisation and completely inappropriate in another.

A developer using it to summarise logs or generate test data is operating in a very different risk space from someone pasting customer conversations, financial projections, or candidate information. That distinction is critical.

For that reason, we don’t approve tools in isolation. We approve how they’re used. Being clear about that upfront avoids a lot of difficult conversations later.

We design for how people actually behave

This is where a lot of well-intentioned governance falls apart.

Policies tend to assume careful, consistent behaviour. Real life includes deadlines, distractions, and the occasional questionable decision at the end of a long week. Any approach that ignores that reality is fragile by design.

So we pay close attention to how easy a tool is to misuse, whether guardrails are built into the experience, and how much relies on people remembering what they were told in training. If safe usage depends entirely on goodwill and memory, it won’t hold up over time.

Good controls account for human behaviour rather than pretending it doesn’t exist.

We pressure-test the decision, not just the tool

One of the most useful checks we’ve adopted is asking how a decision would stand up later.

Could we explain, calmly and clearly, why we approved this tool if an auditor asked? What about a customer? Or our own leadership after an incident?

If the justification boils down to convenience or popularity at the time, that decision won’t age well. Strong governance decisions tend to be unremarkable in the moment, but easy to defend long after the initial excitement has passed.

Sometimes the right answer is “Not Yet”

This is often the most uncomfortable part of the process.

Teams want momentum. Leadership wants progress. AI moves faster than most governance frameworks ever have. That tension is real, and pretending otherwise doesn’t help anyone.

But there’s an important difference between blocking progress and setting clear conditions. “No” without explanation shuts people down. “Not yet, and here’s what would need to change” keeps trust intact.

When we delay or block a tool, we try to be explicit about what the real blocker is and whether it’s something that could realistically be addressed later. That clarity matters more than speed.

What’s actually changing

Organisations haven’t suddenly discovered AI risk.

What’s changing is that long-established security and assurance disciplines are finally being applied properly, and AI no longer gets a free pass simply because it’s new or impressive.

The teams that handle this well won’t be the ones with the most policy documents or the loudest AI strategy. They’ll be the ones who can explain their decisions clearly, without defensiveness or panic, long after the demo has been forgotten.

That, in practice, is what good governance looks like.