Lesson 1 · AI Governance Basics
Accountability before automation
- Length
- 27 minutes across 7 sections
- You will be able to apply
- The Single Name Test
- You will produce
- Commit Statement
- You will work
- 3 gated questions
Personalize the practice
Apply this to your environment
These details adapt the application prompts and coach questions. They do not affect your score.
Whose name is on this output, and do they know it?
Core question
classification
Classify the accountability pattern before the framework appears
Required practiceYou are reviewing OmniCorp workflows before they go live. Classify each one by the level of human accountability it should require before reading the Single Name Test.
Automation moves work. It does not move responsibility. When an AI system drafts a letter, scores an application or routes a case, the obligation to have got it right does not attach to the system: it attaches to whoever owned the outcome before the system existed. That is a matter of fact, not of policy, and it holds whether or not anyone has written it down.
Most organisations discover this the hard way, at the moment something goes wrong and the question is asked out loud for the first time. This lesson exists so that the question is asked before, in a quiet room, by you.
The pathology: Diffused Ownership
Ask who owns an AI-assisted workflow and listen to the answer. You will usually hear a plural. The operations team owns it. IT owns the tool. The vendor owns the model. Compliance signed off. Each of those statements is true and none of them is a person, and a plural cannot be asked a question, cannot be given a veto, and cannot be held to an answer.
The correction is not a governance committee. Committees dilute ownership rather than concentrate it. The correction is a single name, tested against three specific conditions.
Every component has a custodian and the assembled workflow has none, so the pronoun is we.
- Diffused Ownership
- Every component has a custodian and the assembled workflow has none, so the pronoun is we.
- Concentrated ownership
- One named person satisfies all three conditions and can be asked a question on any given day.
The Single Name Test
Definition
For every AI-assisted output that reaches a person or a system outside the team that produced it, one named individual must satisfy three conditions: they can be asked why the output says what it says and can answer without escalating; they could have stopped it before it left, and had the practical means to do so; and they are not the person or system that generated it. One name, three conditions, all three or the test fails.
The name is a person, never a role, never a team, never a rota. A role can be vacant. A team can be busy. A rota can rotate to somebody who has never seen this workflow. A name can be asked a question on a Tuesday afternoon.
When to Use It
Apply it before a workflow goes live, when an existing workflow gains a new audience or a new data source, and whenever the named person changes job. That last trigger is the one organisations miss: accountability leaks out of a workflow silently at every reorganisation, and nobody notices until the workflow is orphaned.
Apply it also when the answer feels obvious. Obvious ownership that has never been stated is the most common form of Diffused Ownership, because everyone assumes the same person owns it and that person has not been told.
How to Apply It
- Write one name. If two names appear, decide which one answers the phone, and record the other as a contributor.
- Confirm the named person can answer the why question without escalating, and if they cannot, fix that before going live.
- Confirm they have a real means to stop the workflow, not merely the authority to object to it.
- Confirm they did not generate the output, and if they did, name a second person who did not.
| Condition | Fails when | Evidence it holds |
|---|---|---|
| Can be asked | The name is a role, a team or a rota | A person who has read the workflow and can explain it unprompted |
| Could have stopped it | They can object but cannot pause the system | A documented, tested mechanism they can trigger alone |
| Did not generate it | The reviewer is the author, or the author's direct report | A separate person, with time allocated to look |
Worked example 1 of 3
OmniCorp Financial deployed an AI workflow that drafts arrears letters for accounts in early collection. Marisa Delgado asked the three questions in a standing meeting.
- Marisa Delgado
- Who owns the arrears letters?
- Collections lead
- The collections function. We do.
- Marisa Delgado
- If a customer's solicitor writes asking why the letter stated a balance that was ten days out of date, who answers that letter?
- Collections lead
- It would come to me, and then I would ask the data team.
- Marisa Delgado
- Then it is your name, and the second half of your answer is the problem. Can you stop the workflow this afternoon, on your own, without a change request?
- Collections lead
- No. I would have to raise a ticket.
- Marisa Delgado
- Then two of the three conditions fail. We fix both before the next batch, not after.
The fix took nine days: a documented balance-as-at field the collections lead could explain without help, and a pause switch she could operate herself. Neither change touched the model.
Why This Works
The three conditions are chosen because each one, alone, is routinely satisfied by an arrangement that is nonetheless unaccountable. Plenty of workflows have someone who can explain them and no means to stop them. Plenty have someone with a stop button who has no idea what the system does. Plenty have both, held by the person who built it, which is not review but self-certification. Only the conjunction is worth anything.
Insisting on a person rather than a role works because it makes the gap visible immediately. Nobody notices that the risk function owns a workflow in the abstract. Everybody notices when the name written next to it is somebody who left in March.
Worked example 2 of 3Optional depth
Alan Brixmoor leads benefits administration at OmniCorp Public, where an AI workflow classifies incoming citizen queries into fourteen routing categories. The named owner was the head of digital services, who satisfied conditions one and two comfortably. Condition three failed in an unexpected way: the classification was reviewed by nobody at all, because the routing was considered too low-stakes. Alan traced three months of misrouted disability queries that had each added eleven days to a decision. The stakes had never been low. They had simply been invisible, because no separate person was looking.
Worked example 3 of 3Optional depth
At OmniCorp Studio, Jo Halvorsen is the named person for all six AI uses in an eleven-person practice, and conditions one and two hold trivially. Condition three cannot hold for the work she drafts herself. Her answer was not to appoint a governance function she cannot afford: it was to name her studio manager as the reviewer for anything client-facing, allocate twenty minutes a week to it, and accept that anything her studio manager also worked on has no reviewer and therefore does not go out AI-assisted. Small organisations do not get an exemption from the third condition. They get a smaller scope.
Edge Cases and NuancesOptional depth
Three cases strain the test. Vendor-operated workflows, where the system runs outside your organisation entirely: the name is still yours, because your customer has no relationship with your vendor, and the contract is a mechanism for recovering cost rather than a transfer of accountability. Fully automated decisions with no human in the loop, where condition two must be satisfied by a monitored threshold and a tested kill switch rather than by a reviewer's judgment. And workflows spanning two functions with genuinely equal claims: pick one name anyway, record the second as a contributor, and revisit in a quarter. A shared name is not a compromise, it is the pathology with extra steps.
The person can explain why the output says what it says without escalating.
- Can be asked
- The person can explain why the output says what it says without escalating.
- Could have stopped it
- They have a tested mechanism to halt the workflow alone, within the hour.
- Did not generate it
- They are separate from the person or system that produced the output.
Knowledge check
Why does the Single Name Test require a person rather than a role or a team?
Common Failure Modes
The test end to end
Dr. Naomi Ellery at OmniCorp Health inherited an AI workflow that pre-populates referral letters from the clinical record. It had run for fourteen months and was well liked. She applied the three conditions in sequence.
Condition one: she asked the clinical lead why the letters ordered comorbidities the way they did. He did not know, and neither did the two people he escalated to. The answer eventually came from a vendor engineer. Condition one failed, and the failure had been invisible for fourteen months because nobody had asked.
Condition two: the workflow could be disabled, but only by a change request with a five-day standard lead time. On paper it could be stopped. In practice, during the five days it would take, another four hundred letters would go out. Condition two failed. Condition three held: a clinician reviewed every letter before signature, and was not the generator.
Naomi did not switch the workflow off. She wrote both failures down, named herself as owner while they were open, negotiated an emergency-disable path that took forty minutes rather than five days, and required the vendor to document the ordering logic in language a clinical lead could read aloud. Eight weeks later she handed the name to the clinical lead, who could now satisfy all three conditions. Ownership was not asserted. It was constructed, and then transferred.
Decision point
Trevor Okafor at OmniCorp Retail is asked to approve an AI workflow that sets markdown prices on slow-moving stock. The proposal names the merchandising steering group as the accountable body, cites a completed risk assessment, and notes that the pricing team reviews the outputs weekly. Nothing has gone wrong in the four-month pilot. What do you do?
Self-check
Mark the level that describes you today. Nothing is submitted.
| Behaviour | Ready | Developing | Not yet |
|---|---|---|---|
| Locating the owner | |||
| Testing the stop mechanism | |||
| Separating reviewer from generator |
Commit
Commit Statement
Complete every line in your own words, then sign and date it. Attach the name you wrote against your closest AI workflow.
| Window | Field application |
|---|---|
| Days 1 to 7 | Write one name against every AI workflow you can see, and mark which of the three conditions you have actually verified rather than assumed. |
| Days 8 to 21 | Take the workflow with the weakest stop mechanism and get a path built that the named person can trigger alone within the hour. |
| Days 22 to 30 | Test one name by asking that person the why question cold, and record how many escalations it took to answer. |
One name per workflow is accountability you can establish yourself, for the workflows you can see. It does not give you a register that survives a reorganisation, decision rights that hold when two functions disagree, or the independent assurance a regulator will ask for. Turning named ownership into an operating model with delegated authority and evidence that outlives the people who created it is the capability the paid programs develop next.
Learner feedback