How to Build an AI Policy That Works for Your Business

Chances are, your team is already using AI. Not “considering it” or “piloting it in one department”, actually using it, whether or not anyone signed off on it first...

Unfortunately that's the reality of things now, so the important question is whether there’s a policy in place to manage it, or whether you’re about to find out the hard way what happens when there isn’t 😬

We put that question to Nick Harkin, one of Trust Keith’s Data Protection and AI advisers.

Here’s what he told us about building an AI policy that people actually use, rather than one that sits in a folder nobody opens 🥲

What we’ll cover:

• Why your business needs an AI policy now
• The 3-part structure every good AI policy needs
• Getting tool approval right, without creating a bottleneck
• Training that survives contact with reality
• The pitfalls that come up again and again
• Handling multiple jurisdictions
• Frequently asked questions
• Free AI Policy template

Why your business needs an AI policy now

The EU AI Act is live. Prohibited practices have been in force for over a year, more obligations landed this year, and more are coming in 2026. Regulation is moving faster in this space than almost anywhere else in compliance right now, which is exactly why so many businesses feel like they’re already behind before they’ve started.

But the regulatory timeline isn’t actually the most urgent part. The more immediate reality is much simpler: your note-taker is probably AI. Your drafting tool is probably AI. Your customer support chatbot might be AI. 

“AI is already here. The reality is that in the vast, vast majority of cases, your staff and colleagues are using AI. So it’s not about letting the cat out of the bag, it’s about accepting this is already happening. How do we make sure we’re using it in a responsible, safe way, in a way that really aids the business, rather than puts your data and your customers’ data at risk?”

An AI policy isn’t a document that grants permission to start using AI at some future date. It’s a document that catches your business up to what’s already true, and gives people a safe, sanctioned way to do what they were going to do anyway. Without one, you’re not preventing AI use, you’re just losing visibility into it, which is a considerably worse position to be in.

The 3-part structure every good AI policy needs

Most of the AI policies that don’t work fail for the same reason: they try to make one document do three completely different jobs at once. A policy that’s trying to be a technical governance framework, a plain-English staff guide, and an up-to-the-minute regulatory tracker all in one place ends up serving none of those purposes well.

Nick’s approach is to split it into three distinct layers, each with a different audience and a different update cycle.

“I always see these policies as broken up into three main areas. You’ve got your underlying governance — definitions of what counts as AI, what’s a permitted tool or model, how you’re making decisions as a company, and how data protection rolls on top of that.

You’ve then got your AI acceptable use policy, aimed much more at your actual staff and colleagues — it’s human-readable, it tells people who it applies to, why it exists, what the rules are, when they should stop, when they should escalate.

And then the third part is the regulatory appendix.”

Breaking that down in practice:

1. Governance. This is the static, structural layer. Definitions, permitted tools, how decisions get made, and how your wider data protection obligations sit on top of it. It doesn’t change often, and it’s not really written for a general audience. It’s the foundation everything else references.

2. Acceptable use. This is the part your team actually reads, and the part that determines whether the policy gets followed at all. It needs to be written for humans, not lawyers: what’s in, what’s out, when to stop, when to ask for help.

3. Regulatory appendix. AI law is genuinely moving faster than almost any other area of compliance, and different jurisdictions are pulling in different directions, some tightening rules, others loosening them to attract investment. Rather than baking fast-changing regulation into your core policy (and having to rewrite the whole document every time a rule shifts!), keep it as a separate, living appendix that gets reviewed and updated on its own schedule.

All three can live in one document. Most businesses find that easier to maintain in practice, but treating them as three different jobs, written for three different audiences, is what stops the whole thing collapsing into a single dense document nobody reads past page one.

Getting tool approval right, without creating a bottleneck

This is the part that trips up most businesses, because it’s a genuine tension rather than a simple fix. Make approval too strict, and people just use the tool anyway — on their phone, on a free account you have no visibility into. Make it too loose, and “approval” stops meaning anything at all.

“Approval needs to have a no option. If everything is just being approved and rubber-stamped through, this isn’t a control anymore, it’s just a queue until your tool goes live, but it hasn’t actually had proper review.

It needs to be lightweight and manageable, because people need to actually be able to use it. One owner.

A short checklist: what’s the business purpose, what data does it touch, do we need a DPIA on it.

And the approval itself should be quick. Ayes or a no, not just a rubber-stamped yes.”

That last point about DPIAs is worth pulling out on its own. Not every new AI tool needs a full Data Protection Impact Assessment, but your approval checklist should be the thing that flags when one’s genuinely needed, rather than leaving it to chance or to whoever happens to be reviewing the request that week.

A few things that make the approval process actually work, rather than just exist:

• Fold it into what already exists. You don’t need a separate AI bureaucracy running in parallel. Most businesses already have a process for approving new suppliers and software. Extend that process to cover AI tools, rather than building something new alongside it that people have to learn from scratch.
• Keep the tool list alive. New AI capabilities, and new tools built on top of existing models, are showing up constantly. A list that isn’t reviewed regularly is out of date within months, and an out-of-date approved list is barely more useful than no list at all.
• Watch for what happens when approval is too slow. This is where the real risk sits, and it has a name...

“The longer you leave something lying around, the more likely you are to end up with what we call shadow AI. If your tool hasn’t been approved on the enterprise system, someone’s just typing it into their phone to get the result they want. And they’re probably doing that on a free model, which is probably putting your data back to be ingested and trained elsewhere, because you haven’t got the corporate agreements around that.”

Shadow AI isn’t a sign of a badly behaved team, it’s a predictable response to friction. If the approved route takes six weeks and the free version of a tool is one search away, most people will take the free version, not because they’re trying to cut corners, but because they’re trying to do their job.

The fix isn’t a blanket ban, which just pushes the same behaviour further underground and out of your sight entirely. It’s making the approved route genuinely faster and easier than the workaround.

“Rather than saying you can’t do it, the question should always be: how can we make it so people can? It’s always a yes-if. Yes, if we get the right policies and use cases in place. Yes, if we spring for the enterprise version rather than the free personal one, which is sending your data back out. It’s all about making it easy for people to do the right thing.”

Training that survives contact with reality

A single onboarding session on “what is AI” isn’t training in any meaningful sense. It’s a box ticked, forgotten within a month, and rarely connected to what someone actually does at their desk on a Tuesday. Good AI training works the opposite way: it’s specific to the job, not the abstract principle, and it answers the question someone is actually going to have.

“You want people understanding what they can put in and what they can’t put in, rather than a lecture on what confidentiality and data looks like in the abstract. It’s not ‘here’s a theory’, it’s ‘for my job, can I put this into a large language model or not?’ And because everything’s changing so rapidly, you need to make it easy to remove confusion. If someone doesn’t understand the rule, you don’t want them staying quiet, you want them asking, and escalating.”

There’s a real difference between knowing a rule exists and knowing how to apply it to the specific thing in front of you, and most training programmes only manage the first one. Two things are worth building into your training cadence to close that gap:

Refresh it when the policy changes, not just annually. One-off training doesn’t survive contact with a policy update. If your acceptable use rules change — a new tool gets approved, a use case gets restricted — a short, targeted update on what’s different does far more good than a comprehensive annual refresher delivered months after, once everyone’s already forgotten the original session anyway.

Tie it to real, specific examples. The difference between putting a contract template into an AI tool and putting a signed, completed customer contract in is obvious once someone walks you through it — one contains no personal data, the other is full of it. It’s genuinely not obvious before someone explains it, which is exactly why abstract “don’t put confidential information into AI tools” guidance so often fails to change behaviour. People need the specific scenario, not the general principle.

The pitfalls that come up again and again

Across the businesses Nick works with, the same handful of mistakes keep coming up:

Using something too generic

This is the most common one: a pre-written template pulled from somewhere online, or a policy your own LLM generated for you in five minutes, neither of which has been shaped around what your business actually does.

“You end up with essentially a template that doesn’t actually reflect what your business does, and doesn’t reflect how you’re using AI and what your acceptable cases are. It’s like the generic cookie policies you see everywhere. They look good, but they don’t survive contact with what your business is really doing.”

Overcorrecting into unnecessary complexity

Eighteen months ago, plenty of businesses simply banned AI outright as the safest option. That approach has largely disappeared, for good reason, but it’s sometimes been replaced by the opposite problem: trying to build a fully formal information asset register, tracking every agent and every bot, before you’ve written down anything at all.

“Put a list in the company handbook. Put a list in your policies. It’s better existing there than in a framework that you haven’t built yet and that’s massively over-egged because that’s what you think you should be doing. Perfect is the enemy of good.”

For most scale-ups, an informal but written-down list beats an ambitious formal register that never gets finished. You can always build toward something more structured later.

Fuzzy ownership

Is AI governance sitting with technology? Operations? HR, if it touches candidate data? In a lot of businesses, the honest answer is “nobody’s quite sure,” which means nobody’s actually revisiting the policy either. Pick an explicit owner, and build in a trigger for review. A useful one is switching tools. Moving from one note-taker to another, or from one AI provider to another, is a natural moment to check the relevant section of your policy is still accurate, rather than waiting for a scheduled annual review that’s months away.

Handling multiple jurisdictions

If your business operates across the UK, EU, US and APAC, you’re dealing with genuine regulatory divergence, not just minor variation in wording. Some regions are actively tightening AI rules; others are deliberately loosening them to attract investment and business.

Nick’s advice here cuts against the instinct a lot of businesses have, which is to either chase the single strictest rule everywhere, or relax to the loosest one to avoid friction.

“Use the policy and the acceptable use section to set a strictest sensible baseline — active human review, not just human in the loop, no unapproved tool use, controls over personal data. Then use jurisdictional annexes at the end, which can either confirm the baseline meets local law, or flag where you need something stricter still. You’re never going to relax further than that baseline, but you might need to increase things depending on local law.”

Frequently asked questions

Is an AI policy the same thing as ISO 42001?

No, though the two are closely related and often confused. ISO 27001 is the foundational layer, the international standard covering confidentiality, integrity and availability of information generally, across any system. ISO 42001 sits on top of that as the AI-specific management standard: a structured, auditable way of demonstrating your business develops, provides and uses AI safely.

Your AI policy then sits above both of those, translating that formal structure into something your staff can actually read, understand and follow day to day.

Do developers building AI products need a separate policy from someone using ChatGPT for drafting?

No. The same acceptable use policy should cover both, with different sections addressing different teams, rather than two entirely separate documents. The underlying principles (human oversight, data controls, when to escalate) don’t change based on someone’s role. What changes is the specific guidance each team needs day to day, and that’s better handled through role-specific training than through maintaining a second parallel policy that has to be kept in sync with the first.

How do we find out what tools our team is actually using?

A data discovery scan is the most reliable starting point. Checking where company email addresses are being used to log into tools across your estate, which surfaces a genuinely accurate picture rather than a guess. It won’t catch personal devices or personal accounts, which is exactly where staff buy-in matters: ask people directly what they’re using and why, not as a disciplinary exercise, but because a genuinely useful tool someone’s already found on their own might be worth bringing into the business properly, for everyone.

Should we be monitoring employees’ personal AI use?

Nick’s view is clear on this: monitor what happens on corporate infrastructure and corporate accounts, because that’s the data you’re actually responsible for. Don’t try to monitor personal phones or private tools. Instead, make it genuinely easy and low-stakes for someone to say “I’ve been using this for work, can we look at bringing it in properly,” so it gets assessed and potentially approved, rather than hidden out of fear of getting in trouble.

How to get started with an AI Policy

As we mentioned earlier, a generic policy won't cut it, but you do need to start somewhere.

That's why we've put together this AI policy template, to help you with those first steps.

It includes the governance layer, the staff-facing acceptable use rules, and a regulatory appendix covering the UK, EU and US, all built around the exact structure Nick talked through above.

Go through it, personalise it to your organisation, and make it your own.