Episode 1 gave you a register: the list of your organization's real AI uses, with an owner per use and a three-status triage. You can now see what is happening.
Then comes the question that decides everything else: who answers for these uses in front of leadership?
It sounds bureaucratic. It is not. Until it has an answer with a name on it, every AI decision is made by whoever is sitting at the screen, with the information they happen to have, and nobody else knows. That is exactly how a resume-screening tool reaches production without an assessment, and how an incident ends up at the executive committee without any manager ever having had the chance to say no.
The AI governance committee trap
The usual reflex is to create a committee. Twelve people, a monthly meeting, a three-page mandate. Six months later the committee still meets, AI uses still get deployed without it, and nobody can say who approved what.
That is not a seriousness problem, it is a design problem. A committee arbitrates hard cases; it cannot be the gate every use passes through. If everything must go through it, it becomes a bottleneck teams route around, and you are back in the shadow AI you just finished inventorying.
Governance that holds does the opposite: most decisions happen without a meeting, because the rules are written and the roles are clear. The committee only sees what falls outside the frame.
The four roles, and what they actually decide
Four roles are enough. They are responsibilities, not new positions: in a 200-person organization they usually land on three people who already work there.
The use owner. The manager whose team uses the tool. They answer for the outputs of that use the way they answer for their team's work. They enter the use in the register, flag a change of vendor or purpose, and must be able to explain an AI-assisted decision. The point worth carving in stone: accountability does not delegate to the model. If a tool screens candidates badly, the vendor will not be the one answering to your board.
The privacy officer. Under Quebec's Law 25 this person already exists in your organization, by default the person with the highest authority, often delegated in writing. For AI, their role is specific: decide which categories of data may enter which type of tool, and trigger a privacy impact assessment when a use processes personal information or sends data outside Quebec. This is not a blanket veto on AI, it is a data boundary.
Security. They assess the vendor and how the tool is wired in: authentication, permissions granted through OAuth, logging, hosting, terms on training with your data. Their question is not "is AI dangerous?", it is "does this specific integration create an access path we are not watching?".
The executive owner. One named person who answers for the whole thing to the board and arbitrates when the three roles above disagree. In most organizations this is the CEO or the CFO, rarely the head of IT, because the trade-offs are business decisions first.
A simple test for whether your roles are real: take the three most sensitive uses in your register and write the four names beside each one. If you hesitate on any cell, governance does not exist yet for that use.
The one-page usage policy
A forty-page AI policy will not be read. A one-page policy will, provided it answers what people actually wonder at their desk. Six sections are enough.
- What is approved. The named list of allowed tools, and for each one what you may put into it. An empty or vague list pushes teams toward their personal tools; clearly saying "yes, this one, for that" is what makes the prohibitions credible.
- What never leaves. The data categories forbidden in any unapproved tool: personal information of customers, employees or candidates, unpublished financial data, source code and secrets, information covered by a client contract or by professional privilege.
- Decisions that require a human. Hiring, termination, credit, pricing, clinical and legal decisions. A useful formulation: AI may prepare, a named human decides and signs.
- Review before reuse. Anything going to a customer, a regulator or the public is reviewed by someone competent in the subject matter. The rule applies to text and to code alike.
- How to get a new tool approved. A five-question form and a published turnaround, for example five business days. Without a credible turnaround, the policy gets bypassed.
- What to do when something goes wrong. A no-blame reporting channel, and an explicit commitment that declaring a misuse carries no sanction. It is the logical continuation of the inventory amnesty.
Date the policy, name the person to contact, and schedule a quarterly review. Tools change fast enough that any static policy is wrong within six months.
The four decisions to settle before writing
Writing the policy is easy once these four questions have answers. Most organizations stall because they draft before deciding.
1. Free tier or enterprise tier? The terms differ on one point that changes everything: whether your inputs are used to train models. That is a cost-versus-exposure trade-off, and it belongs to leadership, not to a technical meeting.
2. Where does the data go? Hosting, jurisdiction, the vendor's own subprocessors. Under Law 25, sending personal information outside Quebec requires a prior assessment. It is often this point, not the nature of the AI, that disqualifies a tool.
3. What do we log? Without a log of prompts and responses for sensitive uses, you can neither investigate an incident nor demonstrate that a decision was made properly. With a log, you create a new database to protect and retain on a schedule. This choice is made use by use.
4. What about agents? An assistant that suggests and an agent that takes actions are not the same problem. Decide now whether autonomous actions require prior approval, and which ones. That is episode 7's subject, but the rule has to exist before the first agent is plugged in.
How this connects to your other obligations
None of this is a parallel regime. AI governance hooks into what you already have: the incident register and the privacy officer under Law 25, vendor assessment under your third-party risk program, access management and logging under your security controls.
If you are aiming at ISO 42001 or the NIST AI RMF later, this foundation is exactly what they ask for first: named roles, an applied policy, traceable decisions. We return to that in episode 6.
What you should have by Friday
Four roles assigned by name for your sensitive uses, a one-page policy dated and circulated, four decisions settled and written down, and an item on the next executive committee agenda. This is not a six-month project. It is a week of work, once the inventory is done.
Episode 3, next Thursday: the risks specific to large language models. Prompt injection, data leaking through context, hallucinations in production, and why your usual application controls do not see them.
In the meantime, our free cyber risk score includes a "data and AI" domain that tests exactly these governance questions, and the Risk Engine module turns a register and a policy into continuous risk tracking.