AI Governance for Managers: Building Accountable AI Use at Work

Individual AI literacy solves half the problem. Someone can understand exactly what an AI tool can and cannot do and still make a bad decision if there is no organisational structure around them — no record of which tools are actually in use, no process for approving a new one, no one checking how tools are actually being used once they are rolled out, and no clear route to raise a problem when something goes wrong. That structure is AI governance, and for most teams it is a manager’s job to build it, not a specialist compliance function’s.

Why individual good judgment is not enough

Most AI use inside organisations today did not arrive through an official rollout. It arrived because someone found a tool that helped them work faster and started using it — often without anyone in a position to say yes or no ever finding out. That is normal and not malicious, but it means the tools actually shaping decisions, drafts and client communications in a team are often invisible to the people responsible for managing risk. Governance starts with making that visible. For the habits individual employees need on top of this structure, see our guide to AI literacy at work.

Step one: build an honest inventory of what is actually in use

Before writing any policy, find out what is really happening. Ask the team directly, rather than relying on what is officially sanctioned: which AI tools do you use for work, and what do you use them for? This is not a disciplinary exercise — treating it as one guarantees people stop being honest about it. The goal is a working list: tool name, what it is used for, roughly how often, and what kind of information gets put into it. That list is the starting point for every governance decision that follows.

Step two: set up a real approvals process for new tools

Once you know what is in use, the next gap to close is what happens when someone wants to start using something new. A workable approvals process does not need to be slow or bureaucratic — it needs to exist and be easy to use. At minimum it should answer three questions before a tool is approved: what data will it have access to or be given, where does that data go and under what terms, and is there a genuine business reason to use it over an already-approved alternative. Make the process quick enough that people use it rather than work around it — a process nobody follows provides no governance at all.

Step three: monitor how AI is actually being used, not just what is approved

Approval at the point a tool is adopted is not the end of the job. How people actually use a tool tends to drift from how it was intended to be used, especially as they get more comfortable with it. Build light-touch monitoring into normal management practice rather than a separate audit exercise: spot-check outputs that get used in client-facing or high-stakes work, ask people what they are using AI for as part of normal one-to-ones, and pay attention to near misses — the times someone caught a wrong AI-generated figure before it went out — as early warning signs rather than one-off incidents to forget about.

Step four: create a clear escalation path

When something does go wrong — a confidential document pasted somewhere it should not have been, a fabricated fact that nearly made it into a client deliverable, an AI tool behaving unpredictably — people need to know exactly who to tell and that telling them will not be punished as if they had caused the problem deliberately. A team that is afraid to report an AI-related mistake will simply stop reporting them, which is worse for everyone than the mistake itself. Name a specific person or route for escalation, and treat early reporting as the behaviour you want to reinforce.

Putting it together: a lightweight routine, not a heavy programme

None of this requires a large compliance function. For most teams, workable AI governance is: a maintained list of tools in use, a short and genuinely usable approval process for new ones, some ordinary management attention to how tools are actually being used, and a named escalation route. Reviewing all four periodically — quarterly is reasonable for most teams — keeps the structure current as tools and use cases change. The aim is not to slow AI adoption down. It is to make sure adoption happens with eyes open, so that when a client, auditor or regulator asks how your team uses AI, there is a real answer rather than a guess. For structured training that helps a team build this discipline, see our CPD courses.

FAQ

Do we need a formal written AI policy before we can start governing AI use?

A written policy helps, but it is not the first step — an honest inventory of what is actually being used is. A policy written without that inventory tends to describe an idealised version of AI use rather than the real one, and gets ignored.

Who should own AI governance in a small or mid-sized team — HR, IT, or the manager?

In practice it is usually shared: IT or a data and security function on tool approval and data handling, HR on policy and conduct, and the line manager on day-to-day monitoring and escalation. What matters more than who owns which piece is that someone is named as the escalation contact, so it is never unclear when something goes wrong.

What is the biggest governance mistake managers make with AI tools?

Treating the first rollout of an approved tool as the end of the job. Use patterns drift, new tools get adopted informally, and a governance structure that is not revisited periodically becomes out of date within months.

Should employees be punished for using an unapproved AI tool?

Not as a first response. If people are afraid of punishment for disclosing AI use, they will simply go quiet about it, which removes your visibility entirely. Correct the behaviour, get the tool assessed or replaced with an approved alternative, and save disciplinary responses for genuine misuse — such as knowingly putting confidential data at risk after being told not to.