AI Governance in Practice: What It Actually Involves Day-to-Day

AI governance is the set of recurring activities that keep AI use inside an organisation visible, approved and accountable. In practice that means approving tools, reviewing how they are used, routing incidents, checking suppliers and training staff. It is operational work on a schedule rather than a document.

What does AI governance actually involve day-to-day?

Five activity types account for most of the work: tool approvals, usage reviews, incident routing, supplier checks and staff training. Each produces a record, and those records are the evidence an assessor asks for. Beyond the five, expect an inventory of AI systems in use and a log of approval decisions.

• Tool approvals. A named owner assesses what data a requested tool touches, where that data goes and whether an approved alternative exists. Decision recorded, requester informed.
• Usage reviews. Periodic checks of what AI is actually running: licences purchased, features enabled inside existing platforms and unapproved tools appearing in expense claims. This is where Shadow AI surfaces.
• Incident routing. A defined path for AI-related problems, each with a route to a person who can act.
• Supplier checks. AI questions added to procurement and vendor review: which models are used, what happens to your data and what changes without notice.
• Training and communication. Telling staff what is approved, what is prohibited and where to ask. Repeated, because tools change monthly.

That record-keeping is also the evidence base for ISO 42001 or the EU AI Act, both of which set requirements well beyond record-keeping alone.

What is the difference between AI governance and an AI policy?

A policy states intent. Governance is the machinery that makes intent observable: the usage review that catches the unapproved account, the incident route that captured the near-miss, the training record showing the rule was communicated. Policy alone fails audit because it creates no evidence and no feedback. Assessors ask what you do, who does it and how you know it happened.

Our AI Security Programmes cover the operating rhythm as well as the document set.

What does an AI governance programme look like at a small organisation?

At fewer than roughly 100 staff, AI governance is usually one person spending a few hours a month. They maintain a list of approved tools, handle requests as they arrive, add two or three AI questions to supplier onboarding and review quarterly what is in use against what was approved. The common failure at this scale is diffusion rather than under-resourcing: nobody owns it, so tool decisions happen inside individual teams. Naming an owner and giving them a monthly slot solves most of it.

What does an AI governance programme look like at a mid-sized organisation?

Between roughly 100 and 1,000 staff, informal handling usually breaks down. The typical shape is a named owner in risk, security or operations spending one to two days a month, supported by a small cross-functional group meeting quarterly with legal, IT and one or two business representatives. Tool approvals follow a documented route, usage reviews run monthly from identity and expense data, and supplier checks sit inside procurement.

This is the scale at which regulated organisations start needing AI Behaviour Verification for systems influencing decisions about people. Many organisations at this size bring in fractional leadership rather than hiring, which is what our vCAIO engagement covers.

How does AI governance change at a large organisation?

Above roughly 1,000 staff the activities stay the same and the coordination cost dominates. Expect a formal governance forum with terms of reference, delegated approval authority for lower-risk tools, a maintained system inventory with risk classification and reporting into the board or audit committee. Usage reviews become continuous monitoring rather than periodic sampling, and incident routing integrates with the existing security incident process.

The recurring failure here is governance that describes itself accurately and controls nothing. An AI Security Gap Analysis that tests controls against reality rather than documentation is the usual corrective.

Who should own AI governance?

One named individual with authority to say no, supported by people who hold the relevant expertise. Ownership commonly sits with the CISO, head of risk, COO or a dedicated AI lead. The title matters far less than three conditions: the owner can block a tool adoption, they have visibility of what the organisation is running and they report somewhere that pays attention.

Distributed ownership across a committee with no accountable individual consistently produces documented programmes with no operational effect. Our answer on who should be responsible for AI sets out how the mandate is written down.

How long does it take to establish?

A working baseline usually takes six to twelve weeks for most mid-sized organisations. That covers discovery of current AI use, naming an owner, standing up the approval route, adding supplier questions to procurement and running the first usage review. It does not cover certification readiness, which depends on scope and evidence maturity.

The sequencing that works is to find out what you have, decide who owns it, then write the policy. A structured AI risk assessment sits between the second and third steps.

How do we know whether it is working?

Three signals. Approval requests are arriving, which means staff know the route exists. Usage reviews are finding things, which means the review has real visibility. Incidents are being reported, which means people trust the process enough to raise problems.

A programme that receives no requests, finds nothing and logs no incidents is not a mature programme; it is an invisible one. For related detail, see our entries on AI governance frameworks and what customers expect for AI security. This page is general guidance on operating practice rather than legal or compliance advice, and the staff bands and timelines above are rules of thumb rather than thresholds.