Governance in practice

What you will be able to do

Decide who may approve which change, which documents you keep, and when you need a privacy or legal specialist. Use the risk register’s scores, so that small changes stay quick and dangerous ones get a careful look.

Before you startWhat to know and to have readyAbout 30 minutes

What you need to know

• Larkfield’s risk register and its five risks, from Risk at leadership level.
• The release gate and the sign-off of the definition of done, from Define done with evidence.
• The two vendor proposals and their data terms, from Choose vendors and models as a leader.
• The decision record, from Team rituals and AI-assisted work.

What you need

• A browser and a document tool, with your copy of the risk register and the decision record template.

Changing a light bulb, moving a wall

At home, you change a light bulb when it breaks. Nobody approves it, and nobody writes it down. Moving a wall is different. You need a builder, often a permit, and sometimes an engineer who checks that the house will not fall down. The plans are kept, so the next owner knows what was changed.

The rules are not about the size of the job. Painting a whole house is a big job, and it needs no permit. Removing one small wall can need an engineer, if that wall carries the roof. The checks follow what can be harmed.

The problem: too little, and too much

At Larkfield, “last week” was a light-bulb process for a wall-moving change (a constructed situation, with recorded answers). Someone changed one setting, and prompt v3 answered every ticket. There was no release decision and no gate. The evaluation had already said “do not ship”. 10 tickets that needed a person reached nobody.

The opposite mistake is also common. Imagine that every change needs Nadia’s signature and a legal review, including a new word on the agents’ screen. Work waits for weeks. People stop asking, and they make changes quietly. Too much control ends in the same place as too little: changes that nobody checked.

The idea: governance in proportion to the risk

Governance is the set of rules about who may decide what, with which evidence, and where the decision is written down. Good governance is in proportion to the risk: the bigger the possible harm, the more evidence and the more senior the approval.

Three words do most of the work:

• An accountable owner is the one person who answers for the AI feature’s results and can say “stop”. For Larkfield’s assistant, that is Nadia, the head of customer operations. The owner does not do the work, and the owner cannot hand the answer to a team.
• An approval is a named person’s decision, written down, before a change reaches customers.
• Documentation is the short record that lets someone else check the decision later: what was decided, on which evidence, by whom.

The risk register gives the scale. Here is the one that Larkfield uses. The score bands and the levels are the course’s choice; your organisation can set its own.

Three levels of approval. The score of the risk that a change touches decides the level, not the size of the change.

Text description of the diagram

The diagram starts with a change or a decision. The question is: what can it harm? You read the score of the risk that it touches in the risk register. There are three paths. A low score, 1 to 4: the team lead decides, and adds a line to the change log. A medium score, 5 to 9, or any change to the prompt or the model: the product lead approves. The release gate must pass, and the team writes a decision record. A high score, 10 to 25, or any risk with impact 5: the accountable owner signs. All the medium steps still apply. A specialist reviews the change if personal data or the law is involved, and the team writes a launch checklist with pause conditions.

Why is every prompt or model change at least medium? Because prompt v3 looked like a small text change. It was a shorter prompt. It also left two safety tickets with no answer. A change to the words that steer the model can change everything that the model does.

A tiny example: four changes at Larkfield

Kwame lists four changes that the team plans this month (constructed for this course). For each one, Nadia’s rule gives the level:

Change	Risk it touches (score)	Level	Who approves	Written record
A clearer label “AI draft: check before sending” on the agents’ screen	none of the five	low	Grace, as team lead of the agents	a line in the change log
Prompt v2 with one new reply rule, gate passed	R2 (9), R5 (15)	medium: a prompt change whose gate passed	Omar	gate result, decision record
Release prompt v3 although it fails the gate	R1 (10), R5 (15)	high: an exception to the gate	Nadia	she reads the evidence and refuses
Send real tickets to a new vendor for a pilot	R4 (8): personal data goes to a new company	high: personal data moves	Nadia, after a privacy specialist	data terms, specialist’s answer, decision record

Two rows need a word. A prompt change with a passed gate is medium. The gate already checks the high risks, such as tickets that need a person and tickets without an answer. Omar can approve it, although he proposed it, because the gate decides on evidence and not on his opinion. An exception to the gate is a different decision. It removes the control on a high risk, so only the accountable owner can make it, and she reads the evidence first.

Larkfield keeps four documents, all of them templates of this course. They are the risk register, the definition of done with its gate, the decision records and the launch checklist. Nothing else is required. A decision that is not in one of them did not happen.

Privacy law, in plain words

Larkfield’s tickets contain personal data: information about a person who can be identified. One error example has an order number and “the card ending in 3302”. Another one describes a child. Most countries have privacy laws for such data. Larkfield is a Canadian shop, so Canada’s rules apply to it; the GDPR is the European Union’s best-known example. The laws differ, but they usually ask similar questions:

• Why do you use the data? Customers wrote to get help. Drafting a reply fits that purpose. Training another company’s model may not.
• How much do you need? Send the model only what it needs to draft the reply.
• Who else gets it? The model provider receives every ticket. Many laws expect a contract that limits what the provider may do with the data.
• Where is it stored, and how long is it kept?
• What rights do people have? They can often ask what you hold about them. Some laws also let people ask a person to review an important decision that a machine made alone. The machine learning course explains this in When a simple model is better.

The two vendor proposals of Choose vendors and models as a leader answer some of these questions differently. Both vendors are made up for this course, with constructed terms. ReplyRight keeps tickets and replies for 18 months, in the United States, and uses them to improve its model unless Larkfield buys its Enterprise plan. DraftDesk deletes them 30 days after the reply, never uses them for training, and stores them in Canada. A leader does not need to know which law applies to each line. A leader needs to see that these lines are different, and to ask before real tickets move.

AI regulation, in plain words

AI laws are newer, and they change. The European Union’s AI Act is the best-known example. In general terms, it sorts AI uses by the harm that they can do:

• Some uses are banned.
• Some uses are high-risk, for example AI that helps decide who gets a job or a loan. They come with heavy duties: documentation, human oversight, records and checks.
• Some uses have transparency duties, for example telling people when they talk to an AI system.
• Most other uses have few or no new duties.

The course’s reading, which a specialist must confirm: a drafting assistant whose replies an agent reads and sends is unlikely to be high-risk. If Larkfield later let the assistant answer customers alone in a chat, the duty to tell customers that they talk to an AI could apply. Other countries, Canada among them, have their own rules or plans, or none yet. These laws and their start dates change, so this section is general orientation, not legal advice. Check the current text with a specialist.

When to ask a specialist

You do not need a lawyer for every change. You need one at a few clear moments, before the moment passes:

Four questions that tell a leader when to ask a specialist. Ask before real data moves or the feature launches, not after.

Text description of the diagram

The flow asks four questions in order. First: does the change use personal data in a new way, or send it to a new company or a new country? If yes, ask a privacy specialist before any real data moves. If no, the second question: does the output decide, or strongly shape, a person’s job, credit, insurance, health, housing or legal rights? If yes, ask a legal specialist, because the use may count as high-risk under AI law. If no, the third question: do people deal with the AI with no person in between, or without knowing that AI is used? If yes, check the duty to tell people that AI is used. If no, the fourth question: is this a new country or a new kind of customer? If yes, ask a specialist for that country. If the answer to all four is no, the team decides, with the risk register and a decision record.

A specialist can be a privacy officer, a company lawyer or an outside adviser. Give them evidence, not a summary. Say what data moves, to whom, where it is stored and for how long. Say what the AI’s output changes for a person. The AI security and privacy course shows how to prepare that request, in Residency and contractual questions.

Discuss: a pilot with real tickets

Omar wants to try DraftDesk (made up for this course). Its proposal offers a pilot on 200 of Larkfield’s own tickets before Larkfield signs.

• Omar: “Let’s start next week. It is only a pilot, 200 tickets. It does not need an approval.”
• Kwame: “Real tickets carry names, orders and card endings. They would go to a new company that has never had our data. That is R4, and the rule says high.”
• Grace: “We already have 271 made-up test tickets with labels. No customer wrote them. Use those.”

Before you read on, answer these:

1. Which level does Omar’s pilot need, and who approves it?
2. Is Grace’s idea a way around the rule, or a better pilot?
3. What would need a specialist, and when?

The course’s answer. A pilot that sends real customer data to a new company is high, even if the data stays in Canada. Nadia approves it, after a privacy specialist reads DraftDesk’s data terms and contract. “Only a pilot” does not change what happens to the data. Grace’s idea is not a way around the rule. It is the better pilot. The made-up tickets contain no real person’s data, so they need no privacy review. They already have labels and recorded results for prompt v2. So the comparison is fair, with the same tickets for every option, as in Run a fair pilot. Omar can start next week, at the medium level, with a decision record.

The specialist is needed later, and before a deadline: before any real ticket goes to DraftDesk, if the pilot is good enough to continue.

What would change the answer: if the made-up tickets missed an important kind of real ticket, a pilot on real data could become necessary. It would still go through the specialist first. And if DraftDesk’s terms changed, for example to use tickets for training, the specialist would need to look again.

When to use it, and what it costs

Set the levels once, when the AI work starts, and write them in the risk register’s header. Review them when a new risk appears. A small team can keep the same three levels for every AI feature.

The cost is time. A medium change waits for a gate run and a short record. A high change waits for the accountable owner, and sometimes for a specialist, which can take weeks. So keep most changes at low or medium, with automatic gates. Save the high level for the few decisions that need it.

Common mistake

A signature that read nothing

Symptom: a high-level approval comes back signed within minutes. The approver’s only evidence is a message: “the tests are green”.

Cause: approval became a formality. The person signed a claim, not evidence. “Last week” showed how much “green” can hide: the service accepted every ticket while 10 tickets that needed a person reached nobody.

Fix: the approver reads the gate table and the error examples before signing, as in Review work you cannot write yourself. The definition of done’s sign-off has a line “Evidence read (files, runs)”. If that line is empty, the approval is not valid.

See it end to endBuild, buy or partner for invoice extractionCase study

The case study reads each provider’s data terms as criteria: what is kept, where, for how long, and for what use. One vendor’s terms fail a must-have.

See it end to endRecover a stalled AI projectCase study

The stalled project’s delivery data holds names, addresses and delivery times. The recovery plan checks what the pipeline keeps with the people who own privacy.

Knowledge check

Check your understanding

Give the level, the approver and the record for each change: (a) translate the agents' help text into French; (b) move the assistant to a newer version of the same hosted model, with the same prompt; (c) let the assistant send replies alone for delivery-status questions.

Show the answer

(a) Low: it touches none of the register’s risks. The team lead decides, and adds a line in the change log. (b) Medium at least: a model change can change everything, as prompt v3 did. The release gate must pass, then the product lead (Omar) approves, with a decision record. If the gate fails, only the accountable owner can make an exception. (c) High: no person reads the reply, so wrong replies reach customers directly (R2 and R3 change). And customers deal with the AI with no person in between. Nadia signs, a specialist checks the duty to tell customers that AI is used, and the team writes a launch checklist with pause conditions.

Check your understanding

Name three questions that you would bring to a privacy specialist before real tickets go to ReplyRight (made up for this course), and why each one matters.

Show the answer

For example: May we let ReplyRight use our customers’ tickets to improve its model, which is its default unless we buy the Enterprise plan? That use may not fit the purpose for which customers wrote. Is keeping tickets for 18 months in the United States acceptable for our customers and our law? Where and how long data is kept are separate questions. What contract limits what ReplyRight may do with the data, and what happens to it when we leave? Its proposal exports only settings, not the reply history.

Check your understanding

Omar proposed prompt v3, and Omar approves medium changes. Is that a conflict? When does it become one?

Show the answer

It is not a conflict while the release gate decides on evidence. The gate checks the high risks with fixed lines, written before anyone looks at the result. Omar approves only a version that passed. It becomes a conflict at an exception. Releasing a version that fails the gate removes the control on a high risk. Then Omar cannot approve his own proposal; only the accountable owner, Nadia, can, after reading the evidence.

Recap

• Governance sets who may decide what, with which evidence, and where it is written. Keep it in proportion to the risk: the register’s score decides the level, not the size of the change.
• Three levels: the team lead decides (low); the product lead approves after the gate passes (medium, and every prompt or model change); the accountable owner signs (high, every exception to the gate, and every new flow of personal data).
• Privacy law asks why you use personal data, how much, who else gets it, where, for how long, and what rights people have. AI regulation sorts uses by harm: banned, high-risk, transparency duties, few duties.
• Ask a specialist before real data moves or the feature launches, and bring evidence. This course gives orientation, not legal advice.

Next, you plan the launch itself: the stages, the signals and the conditions that pause the feature.

Next: Launch and after