Chapter 9 — Governance That Can Run on a Tuesday
Most governance programs fail because their rules exist only in a document. After the document is written, the business keeps running, systems keep changing, employees keep using them, and new settings keep appearing. After a month, the rules begin to expire; after three months, the rules and real work are no longer the same thing.
Governance has to enter daily operations. It does not need to begin as a large committee or a new software platform. It begins by making four permissions and four records visible in one critical flow.
Four Permissions, One Named Person for Each
First, who may let AI touch which data? Customer, employee, contract, pricing, and financial data are not the same thing. The operational question is not simply whether a system can access them. It is who sets that boundary, who can change it, and who answers for its consequences.
Second, who may let AI generate content on the organization’s behalf? An external email, customer reply, hiring evaluation, or suggested contract revision does not become the organization’s position merely because AI generated it. Generation permission determines what AI may draft; it does not determine who may formally speak for the organization.
Third, who may approve an AI recommendation for the next step? AI may recommend, but the approval step that turns a recommendation into action must identify who assents, who reviews, and who may send it back.
Fourth, who is accountable for the final result? This is the layer a process most easily evades: the first three may be configured and yet no one carries the outcome. Whoever bears the result should have commensurate decision rights over data access, content generation, and recommendation release. Assign buttons first and add a responsible person later, and permissions remain a technical project.
Take one running AI flow and write four lines, one name on each: who approves data, who approves generation, who authorizes release, and who is accountable for the result. Add the decision boundary beside each name: what that person may change, what they must return, and what they must escalate. Any blank line is today’s blind spot.
Permission is not permanent merely because it was once granted. A new customer segment, a changed data source, a different model behavior, or a new output channel can alter the risk of an existing flow. The named person should know which change requires a new decision rather than treating every later use as covered by the original approval. That simple discipline stops a narrow pilot from becoming a broad operating practice without anyone noticing.
Records Must Reconstruct the Responsibility Chain
After AI enters a process, organizations accumulate system logs, model outputs, and approval records. More logs do not necessarily create a usable record. If an incident still depends only on participants’ memories, even abundant records have not formed a responsibility chain.
The minimum usable record captures four things: who issued the instruction, what AI touched, what AI produced, and who moved the output to the next step. Together, those links make it possible to distinguish a human judgment error from an AI-output deviation or a release failure in the process.
Records are not kept in order to assign blame. They are kept so the organization can review, repair, and continue using AI. If employees understand records as a tool for later punishment, they will bypass the formal process or keep crucial judgment outside the record. The logs may look clean while containing no learning value.
The record also needs a home that the relevant roles can actually reach. A system log that only a technical team can read will not help a process owner reconstruct a customer decision; a spreadsheet held by one manager will not help a reviewer understand whether a rule changed last month. Define one location for the operational record and one named route for retrieving it when an exception occurs. The objective is reconstructability, not exhaustive surveillance.
Review the Anomaly, Not the Mountain of Logs
The question is not “who reads the logs?” The question is who looks, by when, and where the conclusion is recorded. AI can screen the first pass: compare an event with a normal pattern, flag access outside a stated boundary, or identify an output that skipped a required release point. That does not remove human judgment. It makes the handoff to human judgment visible and timely.
The signals should enter a queue for judgment, where a designated review owner handles and records a result within a stated time. Anomalies must return to a person and to someone authorized to change the rule. Without a named review owner, a response time, and a disposition record, the anomaly queue becomes another mountain of logs.
The queue needs three possible dispositions: close the event as within the approved boundary, correct the specific result and continue, or pause the flow and escalate it. A reviewer should not be forced to invent a fourth path whenever a case is uncomfortable. The escalation route must name both the person who can resolve the immediate decision and the person who can change the underlying condition. Otherwise the organization will clear the symptom and leave the same exception waiting in the next queue.
An exception should produce a usable operating record, not merely an urgent message. Capture the trigger, the evidence available at the time, the action taken, the boundary that governed, the decision-maker, and the change required before the next similar case. This record lets the organization distinguish three different problems that are often mixed together: a user made an ordinary error, the flow lacked necessary information, or the rule itself no longer fits the operating context. Each needs a different response. Treating all three as “AI risk” creates a vague backlog and teaches the process nothing.
The exception authority resolves the immediate conflict within the stated decision boundary. If the conflict reveals that the boundary itself is obsolete, the process owner owns the proposed operating change and the knowledge maintainer updates the relevant rules, cases, and guidance after the change is approved. The review owner then tests whether the revised flow can be used as intended. This is a short route, not a new committee: resolve the case, repair the condition, verify the repair, and return the lesson to the live workflow.
The distinction matters because a fast answer is not always a sound resolution. A customer deadline may justify an authorized exception with recorded conditions; it does not automatically justify changing the rule for all future customers. Conversely, a repeating exception is evidence that a supposedly narrow condition may now be part of the normal work. The monthly review should surface that pattern and force a decision: preserve the exception, revise the boundary, add a different human judgment point, or stop the AI-enabled action until the underlying condition is understood.
Rollback Is an Organizational Capability
Rollback is more than reverting a code version. Customer commitments AI has already sent, hiring screens it has affected, approval results it has advanced, and employee trust it has changed do not disappear automatically when a version is restored. The question is: after AI makes an error, can the organization still catch it?
I built a small file-organizing tool, mainly for my own use. The job sounded straightforward: take an untidy collection of files and help put it in order. The difficulty appeared at the level of the folder.
Some folders function as inboxes. They contain unrelated items and should be opened up so the files can be sorted separately. Others are archives: project records, client deliverables, or historical material whose internal arrangement already carries meaning. Those folders should move as a whole—or be left alone. From the outside, the two can look much the same.
I could have treated the problem as a classification challenge and kept refining the system’s guess. I chose a different boundary. When the distinction mattered, the tool asked the user whether to separate the contents or preserve the folder as a unit. One additional decision stayed with the person because an incorrect split could destroy order that would be hard to reconstruct.
That choice shaped the rest of the product. The tool showed what it planned to do, acted only after a deliberate choice, and preserved a route back for the actions it allowed. AI could suggest; the person decided; the system made the action visible. Reversibility was not a convenience added after the main feature. It was part of the permission to act.
The management lesson I draw from that design decision is broader than file organization. When an automated action can be contained and reversed, the organization can let the system move first and review by sampling. When the action can destroy context, bind the company, or affect a person in a way that cannot simply be restored, better prediction is not enough. The decision boundary has to move back to someone with the information and authority to judge it.
Rollback therefore begins before an incident. It begins when the organization decides which actions may run automatically, what must remain reversible, and where a person must make the call. The later recovery steps—pause the flow, hand the work back to a person, trace the impact, and repair the rule—depend on that earlier design. If no path back was built into the work, a rollback plan written after failure is only a description of what the organization wishes it could do.
To catch it, four actions are needed. First, pause: once an anomaly is found, the flow can stop so the error does not spread. Second, human takeover: after AI stops, a named person takes over and still understands the underlying method of judgment. Third, trace the scope of impact: find which results AI has already affected, which need review, and which require correction. Fourth, repair the rule: after the incident is handled, update the process, organizational memory, and permission rules so the same problem does not recur by the old path.
People are not inefficient backups. In high-risk decisions and critical processes, the people able to take over, judge, and correct are the organization’s final fallback capability. When you want to pause and there is no switch, return to humans and the role no longer exists, or review impact and there is no usable record, the enterprise has increased automation while dismantling its own brakes.
Test recovery before the process is under pressure. Choose one plausible failure and ask the team to trace it: which outputs can be stopped, who takes the next customer or employee decision, where the affected population can be found, and who decides when the flow may resume. If the team cannot answer in a calm room, it will not answer well in a live incident. A rollback plan is credible only when the handoff back to human judgment is operationally possible.
A Weekly, Monthly, and Quarterly Rhythm
Give the flow an operating rhythm: review the anomaly queue every week; ask monthly whether rules, permissions, or the process itself have changed; and review quarterly whether the flow should be upgraded, replicated, or paused. Governance is not a meeting. It is bringing permission boundaries, anomaly signals, record quality, and rollback readiness back to the table regularly.
The monthly review is a change test, not a status update. Ask whether the AI touchpoint now receives a new kind of data, reaches a new decision, serves a different population, or relies on a rule that has changed since the original approval. If the answer is yes, reopen the relevant permission, review standard, and recovery plan before treating the altered flow as routine. This keeps governance tied to operating change rather than to the calendar.
Record the result of that change test in the same ledger: no material change, change accepted with an updated boundary, or change held until a new decision is made. The point is not to create a second reporting system. It is to preserve the reason a flow remains authorized as work, data, and risk conditions evolve. The regular rhythm turns every exception into a governed decision rather than an email trail. At the quarterly review, leaders can then see a pattern rather than a stack of isolated exceptions: which flows are becoming stable, which are accumulating unresolved returns, and which should be paused before scale turns a local weakness into a wider one.
For each critical AI flow, keep one small governance ledger: process name, AI touchpoint, accessible data, high-risk outputs, the named person authorized to release the output, record location, and rollback action. The ledger is not paperwork for its own sake. It aligns responsibility, the system, and the review mechanism around the same flow.
The CEO sets the enterprise objective and resolves enterprise-wide or irreversible trade-offs. The CIO ensures that permissions and records can be made real in the system. The CHRO ensures that roles, incentives, and the retrospective mechanism do not turn into hidden surveillance or blame shifting. The process owner remains accountable for the operating result within the workflow’s stated boundary. These roles should examine the same responsibility chain, not maintain unrelated governance materials.
Start with a real flow that is already running. Ask five questions: Who issued this instruction? What did AI touch? What did AI produce? Who moved the output to the next step? Who is accountable when something goes wrong? If any answer is blank, do not buy another tool or launch another training session. Repair that gap first.
AI has not entered an organization because it can run automatically. It has entered because, once it runs, the organization knows who authorizes, who releases, who reviews, who repairs, and who is accountable for the outcome.
The Tuesday Rule
On an ordinary Tuesday, a manager should not need to convene a steering committee to answer a routine exception. The team should be able to find the four permissions, retrieve the operational record, identify the review owner, and choose one of the three dispositions: close within the approved boundary, correct and continue, or pause and escalate. The process owner should know which result needs a human decision today; the person authorized to release the output should know the boundary of that authority; and the person receiving the escalation should know when the flow may resume.
That is a small operating rule, not a theoretical definition of governance. Test it with a live but bounded event: an output sent to the wrong channel, a recommendation outside its stated condition, or a record that cannot be reconstructed. Follow the route from detection to disposition, recovery, and the change that reaches the next cycle. If the team cannot do that, it does not yet have governance. It has a policy document beside an unmanaged workflow.