AI Governance and Risk: make accountability real
We find the AI your business already runs, name who answers for each system, and wire the controls into the work, so that governance exists where decisions are made.
In brief
AI governance and risk advisory sets 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 a policy written first describe systems nobody can name?
A committee meets, drafts 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 at the point where a person can say: this system, this owner, this control, this evidence that it ran. Everything before that is intention.
A governance build, in the order it has to happen
- 01
Find the systems
From contracts, subscriptions, release notes and conversations with the teams.
- 02
Classify by consequence
Who is affected, and whether an error can be undone.
- 03
Name the owner
The person whose decision the system informs, with the right to approve, pause and withdraw it.
- 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.
- 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, not by what the technology is. A spelling suggestion and a model that screens applicants may share a vendor and a release date, and they do not share a control set.
| Question about the system | What 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? | 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 pattern we are called into
A group of dental clinics where each site picked its own tools
A group of dental clinics lets each site choose its tools. Sites have adopted a note-taking assistant from one vendor, each through a separate subscription paid on a manager's card. The vendor changes the underlying model with a release note nobody reads.
The group's compliance lead learns of the tool when a clinician asks whether it may be used for treatment notes.
- Take the inventory from the money. Expense records and subscriptions give us the tools. Conversations with site managers give us how they are used, including a transcription feature nobody had listed as AI.
- 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.
- 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.
- Fix the vendor terms. Change notice, data residence and retention go into the renewal, with a re-review at each material release.
- Rehearse a pause. A 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, is short because the controls already exist.
Is this 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, which 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 did not have. Both are the point. Expect early resistance from sites and teams that read the inventory as an audit. We frame 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 the 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 we need from you, 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 are not a law firm. Interpreting regulation is for your counsel, and we prepare the questions and the evidence they need. We do not guarantee a regulatory outcome, or that incidents will not occur. We design for the first one to be found early, by someone who knows what to do.
Where 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.
Questions a risk or compliance lead asks first
Do we need an AI policy before we start?
No. The inventory comes first, because a policy written without one describes systems you cannot name. We write the policy last, from the controls and owners the work establishes, so that each line of it can be applied to something real.
How do you find AI we do not know about?
From contracts, expense and subscription records, vendor release notes and structured conversations with the teams that use the tools. Staff rarely hide them. They have simply never been asked, so the question, and a safe route for answering 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 include what you require from a vendor, what you check at renewal and the event that triggers a re-review of a bought system.
Related
Can you name who is accountable for each AI system you run?
Describe what you are weighing in a few lines. A senior practitioner replies with a suggested first conversation.