Skip to main content
Discuss Book a call

AI Governance and Risk: an owner for every system you run

Ask who is accountable for the AI your business runs, and you'll probably get the name of a committee. We find the AI already in use, name the person who answers for each system, and wire the controls into the work, so governance sits where decisions are made.

Line illustration for AI governance and risk: concentric circles around an AI system, with one ring left open where no one is responsible.

In brief

AI governance and risk advisory settles who is accountable for each AI system and which controls apply to it. We start by finding every system in use, including AI inside vendor products, classify each by what an error costs, name an owner with authority to stop it, and write the policy last, from what exists.

On this page

Why does an AI governance policy written first describe systems nobody can name?

A committee meets, drafts AI governance principles on fairness, transparency and human oversight, and publishes them. Nothing in the business changes, because nothing in the document points at a system. The support team's drafting assistant, the vendor feature switched on at the last release and the spreadsheet macro that calls a model all sit outside it, because nobody listed them.

Governance becomes real when a person can say: this system, this owner, this control, this evidence that it ran. Everything before that is intention.

A stepped line rising from unowned, through named, informed and empowered, to rehearsed, with a marked break after named where the owner has a name but no authority.
Ownership comes in degrees. A name in a register is only the first. Governance tends to fail at the step where that person has no authority to change or stop the system.

The AI governance and risk work, in the order it has to happen

  1. 01

    Find the systems

    From contracts, subscriptions, release notes and conversations with the teams.

  2. 02

    Classify by consequence

    Who is affected, and whether an error can be undone.

  3. 03

    Name the owner

    The person whose decision the system informs, with the right to approve, pause and withdraw it.

  4. 04

    Wire and rehearse the controls

    Review, sampling and logging built into each workflow, an incident path that has been tried, and a written exit for each system.

  5. 05

    Write the policy

    From what now exists, so every line applies to something.

Which questions set the controls on a system?

We classify by what an error costs. A spelling suggestion and a model that screens applicants may share a vendor and a release date, and they don't share a control set.

Question about the systemWhat a yes puts in place
Does it inform or make a decision about a person, such as a patient, a customer or an employee?Human review before action, and the reasons kept with the decision
Can its output reach a customer or a regulator without anyone reading it?A release check, sampling after release and an approver by name
Does it handle personal, confidential or regulated data?Sign-off by the data owner, a retention rule and a limit on where the data may go
Is the model supplied by a vendor who can change it without telling you?A change-notice clause, a re-review at each material release and a check at renewal
Can the decision be reversed, and how quickly?A stop path, and the name of the person who holds it

A composite example

A group of dental clinics where each site picked its own tools

Take a group of dental clinics where each site chooses its own tools. Sites have adopted a note-taking assistant from the same vendor, each through its own subscription paid on a manager's card. The vendor changes the underlying model in a release note nobody reads.

The group's compliance lead hears about the tool when a clinician asks whether it may be used for treatment notes.

This group is a composite, not a client.

  1. Take the inventory from the money. Expense records and subscriptions give us the tools. Conversations with site managers tell us how they are used, including a transcription feature nobody had listed as AI.
  2. Classify by consequence. Notes feed the patient record and later clinical decisions, so the note-taker gets strict controls. A scheduling assistant gets a light touch.
  3. Name an owner with authority. The clinical director owns the note-taker and can approve a site's use, pause it and withdraw it. The group agrees in writing to back that authority.
  4. Fix the vendor terms. Change notice, data residence and retention go into the renewal, with a re-review at each material release.
  5. Rehearse a pause. One site's use is stopped for a day to prove the notes workflow still works without the tool.

Where it endsThe group has a list it can put in front of counsel and auditors, an owner for each tool, and a vendor clause that would catch the next silent change. The policy, written afterward, comes out short because the controls already exist.

Is AI governance the work you need, or is it legal interpretation or a certification?

It fits when

  • AI is in use across functions and nobody can produce a complete list
  • Vendors have added AI to products you already pay for
  • A policy exists on paper and no system is known to follow it
  • The board or a regulator has asked who is accountable

Look elsewhere when

  • The question is what a law requires of you. That is for your counsel; we prepare the facts and the questions
  • You are pursuing a formal certification, which needs an auditor with that scope
  • The business has no AI in use or planned, and a short intake rule is enough
  • Nobody with authority will accept ownership of a system, since a map would only record the refusal

The work asks teams to disclose tools they may have adopted informally, and it gives owners duties they didn't have. Expect early resistance from sites and teams that read the inventory as an audit. We present it as a question nobody has asked them before.

What does the risk committee hold at the end?

  • An inventory of AI in use and in planning, including AI inside vendor products, with how each was found
  • The classification method and the classification of each system
  • An ownership map showing, for each system, who can approve, pause and withdraw it
  • Controls written against each system's workflow, with evidence that each one ran
  • Vendor requirements for contracts and renewals
  • An incident playbook that has been rehearsed, and a board reporting format
  • Policies that describe what exists

What do you bring, and what stays with your counsel?

We need access to the teams that run each system, to procurement and finance records, and to contracts with AI vendors. Rules differ by market, so the written scope names the jurisdictions it covers.

We're not a law firm. Interpreting regulation is for your counsel, and we prepare the questions and the evidence they need. We don't guarantee a regulatory outcome, or that incidents won't occur. We design so the first incident is found early, by someone who knows what to do.

Can you check your position first?

The assessment shows where ownership is thin, the register is where classified systems are kept, and the policy starter shows the shape the last document takes. The report on who owns an AI system after launch describes how ownership fails in practice, and the briefing on AI regulation sets out what is coming into force.

What does a risk or compliance lead ask first?

Do we need an AI policy before we start?

No. The inventory comes first, because a policy written without one describes systems you can't name. We write the policy last, from the controls and owners the work establishes, so each line of it applies to something real.

How do you find AI we don't know about?

From contracts, expense and subscription records, vendor release notes and structured conversations with the teams that use the tools. Staff rarely hide it. They've simply never been asked, so the question, and a safe way to answer it, matter most.

Who should be accountable for an AI system?

The person who owns the decision the system informs, not the team that built it or the vendor that supplied it. We name that person for each system and write down what they can approve, pause or withdraw.

Does this cover AI we buy as well as AI we build?

Yes. Bought systems carry the same consequences, and vendors change them without notice. The controls cover what you require from a vendor, what you check at renewal, and the event that triggers a re-review of a bought system.

Can you name who is accountable for each AI system you run?

Send what you know about where AI is running today, gaps included. We'll reply with how we would go looking for the rest.