AI Governance

What AI Governance is

AI governance is the set of rules an organisation puts around how its staff use AI. It answers four plain questions. Which tools are approved? Where does a third-party tool’s terms stop being acceptable? Who stays responsible for a result? And how is that result checked before it reaches a client or a decision?

On this site it is covered governance-first in the foundational programmes and not bolted on at the end. The site’s governance article adds that at small and mid-sized scale it does not need a compliance department to run it. It needs an owner, a short written policy and a review point built into how work already gets done.

Rules, not Software

The word governance can suggest a platform or a dashboard. On this site it means something plainer: decisions written down and someone answerable for them. A business can have excellent AI tools and no governance, and a business with a few tools and one clear page of rules can have quite a lot.

It is also not a one-off document. The governance article says the organisations that keep theirs current run it as a process that gets rerun as usage changes, in the same way an operational audit is rerun and not filed once and forgotten.

Where most Businesses start

The governance article reports that 68% of small businesses now use AI in some part of their operation, and that 77% of them run it with no written policy. It also reports that only 2% of small organisations have a comprehensive AI governance framework. Those are third-party figures the article cites from its own sources, and this page repeats them as it states them.

The gap those numbers describe is adoption running ahead of rules. That means a business with no policy is the normal starting point, and not an unusual one. It also means most governance documents, when they finally get written, are built against a guess about usage and not a record of it.

Shadow AI

Even where a policy exists, it usually covers only the tools the organisation approved on purpose. The article reports that 81% of employees use unapproved AI tools at work. Shadow AI is any tool staff use that was never approved, reviewed or logged, from a free chatbot with client data pasted in to a browser extension nobody signed off.

That is why the site does not treat a ban as governance. The banning article argues that a ban removes the visible use and leaves the invisible use, which is exactly the part nobody is watching. Governance that works starts by finding out what is really happening.

Start with an Inventory

The first step is a list. The governance article says to ask every team the same plain question: which AI tools do you actually use, for what, and on what kind of data. The answer is usually longer and more varied than leadership expects, and it is the only foundation a policy can be built on.

The list does not need software and does not need to be complete on the first pass. It needs to be honest, including the tool a manager would rather not have mentioned. The banning article adds the tone: open with the reassurance that nobody is being disciplined for an honest answer, and mean it. A team that says it uses a personal account for meeting summaries has told you what the approved tool is missing.

Sort by Risk, not one rule for everything

With the list in hand, the temptation is to write one rule that approves everything or blocks everything. The article says both produce a policy nobody follows. Risk classification asks a narrower question of each use: what happens if this goes wrong, who is affected, and does it touch personal data, a regulated decision or a client-facing output nobody checks first.

A tool used to draft an internal summary carries a different exposure from one used to screen a job application. An internal draft can move fast with a light review. Content a client sees needs a checked step. A hiring decision or a regulated communication needs a named human checkpoint, and it has to be staffed. The high-risk AI system page covers the Act’s own top classification.

A named person and a checkpoint

A rule that says a person should check the output is a hope and not a control. Oversight has to name who checks it, at what stage and against what standard, before the result reaches a client, a decision or a public output. A checkpoint is only as real as the person accountable for running it.

The ownership article makes the same point about tools. It defines an owner narrowly: the one named person who can answer four questions about a tool. What is it used for? Who can use it? What data can it reach? When was it last checked? That person does not have to do the technical work, but needs the authority to pause the tool. Ownership by committee is ownership by nobody.

Why nobody owning it goes wrong

The ownership article describes what happens when a rollout ends and no one takes over. Buying a tool is a project with an end date, and owning it is a job with none. Five slow failures follow. Quality drifts because nobody samples the outputs. Access widens because permissions granted for a pilot stay in place. The written rules go stale. Incidents have no reporting route. And the business cannot show its work when a customer or insurer asks which AI is in use, on what data and under whose supervision.

It gives an illustration, not a real client: a professional services business connects an assistant to a shared drive, and it later surfaces HR text from a folder never meant to be searchable. There was no attack and no fault in the tool. There was a gap where an owner should have been. The article’s fix is a thirty day sequence. List every tool in week one, name one owner each in week two, write a one-page record in week three, and set a review rhythm and an incident route in week four.

Drawing the line by Data

The banning article’s answer to what a policy should say is a one-page rule with three parts. The first lists what may never be entered into any AI tool: client names and contact details, contracts, HR records, credentials and anything under a confidentiality agreement. The second lists what is fine in the approved tool. The third says anything else goes to one named person first.

The line is drawn by kind of data and not by tool, and client and HR data is what a business’s data protection duties already cover, so the page adds no new principle. It also notes that some restrictions should be firm. A good narrow ban names the tool or the data, gives the reason in a sentence, points to the approved alternative and says who to ask.

Rules people can apply

A rule only works if people understand it. The banning article says a rule people understand gets followed in cases it did not anticipate, and that is where most real decisions happen. Staff need enough AI literacy to judge a case the page never covered.

That is the reason governance sits inside training and not in a memo. The governance article says the classification a review produces belongs inside a foundational programme, whether a set course for a whole team or bespoke training built around one function’s workflows. What makes it stick is practice on the person’s own work, and not a slide of prohibited actions.

Governance and the Ladder of Delegation

The site’s article on automating a task against automating a decision sets out a ladder: Assist, Recommend, Execute and Never delegate. It says a written governance policy is, among other things, a record of which rung each automated process sits on and who signed off on putting it there.

Without that record, it warns, a business finds a process crossed a line only after something goes wrong, and not when it was designed. The article’s view is that governance and workflow design ask the same questions, and that keeping them in separate documents reviewed by separate people is how a process ends up governed on paper and misclassified in production.

Where the Regulations sit

Governance is wider than the two regulations the site names. The EU AI Act classifies systems by risk and applies by what a use does, not by company size. GDPR covers personal data. The governance article says any use case touching personal data carries both at once, checked at the same point in the process and not as a separate review bolted on afterwards.

The article’s point is that data protection is one part of governance and not the whole. It also warns that “the vendor handles compliance” is not a defensible answer, because a business that deploys a tool keeps oversight duties of its own. This page is not legal advice, and the site says no audit substitutes for advice from a qualified lawyer.

A worked example

This is an illustration, not a real client. A 20-person firm has no AI rules. A short round of team conversations turns up five tools: an approved assistant, two free chatbots, a transcription add-on and an AI feature switched on inside its email software. Nobody had listed the last one.

The firm sorts the five by risk. Internal drafting moves fast. Anything a client sees gets a checked step. The transcription add-on touches client calls, so it is the highest exposure. Each tool gets one named owner, the one-page rule says client details go in only through the approved assistant, and the owners meet quarterly. Nothing here needed a specialist. It needed a list, a sort, some names and a date.

In Training and in an Audit

The all-staff briefing covers the rules directly: hallucinations, data privacy, approved against third-party tools, what can go wrong, how to report an incident, the regulatory framework, internal guidelines as a checklist and the AI systems register. The leadership masterclass opens with a governance-first section on the organisation’s own approved tools and third-party boundaries, data protection, human responsibility and verification, and ethics, bias and oversight.

An audit runs the same five steps the governance article applies to governance: map, document, identify, test and build. It assesses the EU AI Act and GDPR at the Identify step and delivers a compliance checklist. It is a diagnostic and not a legal opinion. The AI audit page states its limits.

Mix-ups worth avoiding

Four confusions come up often enough to name. The first is treating governance as the policy document, when the document is the smallest part of it. The second is treating it as a synonym for data protection, which is one part.

The third is treating a ban as governance, when a ban leaves the invisible use nobody owns. The fourth is treating governance as a project with an end date. It is an ongoing job, and the same is true of the tools it covers.

Where it goes wrong

The most common failure is writing the policy before checking what staff use, so the rule describes a guess. A second is a rule with nobody responsible for enforcing it. A third is a checkpoint that exists on paper and is skipped under deadline pressure, which is why it has to be named and staffed.

A fourth is a policy that stops changing. New tools and new features keep arriving, so the site’s advice is a review date in the calendar for each tool and a second trigger whenever a vendor announces a change. The rules should also be tested against how the highest-risk use actually behaves before they are rolled out everywhere.

Where it is taught

Governance runs through the foundational programmes, and the all-staff briefing is built to reach a whole organisation at once. The leadership masterclass is recommended for leaders before staff training begins. The rest sit in the wider training catalogue.

The full sequence is in the governance article, and the case for naming one person per tool is in the ownership article.