The five questions fit on a card. Running them properly takes ninety minutes, three people who cannot delegate their answers, and a scribe. This is that version.
A board-level AI review has one job: establish whether the programme in front of you is defensible. Not whether it is impressive, not whether it is on schedule — defensible, meaning that when something goes wrong, the organisation can say what happened, on whose authority, and inside which limits, from evidence, without a six-week reconstruction project.
Almost no review does that job, and the reason is structural rather than a failure of nerve. The standard review agenda — accuracy, model selection, roadmap, adoption metrics — is the agenda the presentation was built to satisfy. Those questions have prepared answers because the team building the system asks them of itself every sprint. Questions with prepared answers cannot discriminate between a programme in control and a programme that is merely confident. A diagnostic question has to be one the presenter cannot have rehearsed, and cannot answer well by accident.
The five below have that property. Each can be answered well in a single sentence by a programme that is actually in control, and each is nearly impossible to fake, because a good answer requires a design decision to have been made deliberately, by a named person, at a point in time. You are not testing knowledge. You are testing whether a decision exists.
What follows is the working-session edition: for each question, what a strong answer sounds like against what a weak one sounds like, what the silence means about the organisation rather than the technology, the follow-up to ask when the first answer goes sideways, and the recurring pattern in the sector where that failure bites hardest. Then how the five compose into a single architecture, how to run them as a ninety-minute session that produces written findings, and what to do with each class of finding once you have it.
A note on the vignettes. Every pattern described below is a composite — the recurring shape of a failure across programmes in a sector, with all identifying detail removed. None describes a single organisation, and none contains a client fact. The archetype is the unit of evidence here, because the specifics are not mine to publish.
Question one: what exactly can it see — and who decided that?
The strong answer is a list, delivered without hesitation, in three columns the presenter can produce from a document rather than from memory: the sources the system retrieves from; the scope within each source, stated as a boundary rather than a system name (“policy documents in the servicing repository, excluding the legal-hold partition”); and the authorisation each of those rides on — whose entitlement the retrieval executes under, and whether it is the end user’s or the system’s own. The word “excluding” appearing anywhere in the answer is a good sign. It means someone drew a line.
The weak answer is a single noun phrase: “everything in the knowledge base,” “the enterprise corpus,” “all the documents in the shared drive.” It is usually delivered cheerfully, because to the team it sounds like coverage. Then the second half of the question lands — who decided that? — and the room goes quiet, because there is no answer. Nobody decided. An ingestion pipeline decided, in week two, by pointing at a directory root and inheriting whatever it found.
What the silence means organisationally. This is not a technical gap. It is an ownership gap with a specific and uncomfortable shape: the largest single change to the effective access-control posture of the enterprise in recent memory was executed as a data-engineering task, with no named owner, no approval, and no record. The permissions did not survive the trip. A document that took a decade of access-review cycles to fence off became a chunk of text in an index that answers to a service account. Nobody removed the controls; the controls simply had no representation in the format the new system reads. The organisational fact you have discovered is that the control environment has a hole in it that no control-testing programme is looking at, because the hole is in a new system that nobody has classified as an access-control system.
The follow-up, when the first answer is evasive. The evasive answer to question one is a reassurance about the future: “we have permission-aware retrieval on the roadmap,” or “the vector store is inside the perimeter.” Do not argue with either. Ask the operational version instead:
“Pick one document that a specific named employee is not cleared to read. Show me the query that proves the agent will not surface its contents to that employee — today, in the running system.”
This converts an architectural claim into a demonstrable one, and it is the single highest-yield follow-up in the entire session. A programme with permission-aware retrieval runs the query in two minutes. A programme without it discovers, out loud, that the retrieval layer has no concept of the asking user at all — that entitlement is enforced on the way into the chat window and nowhere after. That discovery, made by the team in front of the board rather than by a regulator eighteen months later, is worth the whole ninety minutes.
The archetype: a Tier-1 retail bank deploying a servicing agent. The pattern is consistent enough to be predictable. The agent is scoped to customer servicing — balances, product terms, dispute status. To answer well it needs the policy corpus, so the policy corpus is indexed. The policy corpus lives in a repository that also holds the collections playbook, the hardship-programme thresholds, and the pricing exception matrix, because those are all “policy” to the team that owns the repository. None of that is secret, exactly. All of it is material that the bank has spent years ensuring frontline staff see only under specific conditions, because the thresholds at which the bank will forgive a fee are commercially and conduct-sensitive. The agent now retrieves against all of it, and answers a customer-facing question by quietly consulting material no frontline agent may open. Nothing has leaked. Nothing needs to have leaked for this to be a finding: the bank cannot state its own retrieval boundary, and the first person to ask it to — a conduct regulator, an internal auditor, a plaintiff’s counsel — will get a shrug.
Question two: what may it do, and inside whose authority?
Not what it can do. What it may. The gap between those two verbs is the whole question, and a presenter who answers the capability question when you asked the permission question has told you something already.
The strong answer has three parts and takes about fifteen seconds: a scope in business terms, a named grantor, and an expiry. “It may adjust fees up to two hundred units on accounts in good standing with no dispute open in ninety days; the authority was delegated by the Head of Servicing on the fourteenth of March; it lapses at the next annual delegation review.” That is a mandate. It reads exactly like the delegation of authority a bank already writes for a human in the same role, because it is one — the only novelty is the actor.
The weak answer describes plumbing: “it runs under the servicing service account,” “it has write access to the core through the integration layer,” “we scoped the API key to the servicing endpoints.” Every one of those sentences describes what the system is technically able to reach. None describes what it is permitted to do, on whose behalf, or for how long. A service account is not an authority model. It is a keyring. The difference between an actor with a mandate and an actor with keys is that only one of the two can be found in breach of anything.
What the silence means organisationally. The delegation framework — which exists, and which the organisation takes seriously for humans, with signed schedules and annual reviews and an audit trail — was never extended to non-human actors, because nobody in the delegation-framework function was told a new class of actor had arrived. Meanwhile the engineering function provisioned access the way it provisions access to every service: broadly, to avoid tickets, on the reasonable assumption that the application layer would constrain what actually gets done. In an agentic system the application layer is a language model deciding what to do next. It is not a constraint. It is the thing being constrained.
There is a second, sharper organisational reading. If nobody granted the authority, nobody holds it, and if nobody holds it, nobody is accountable for its exercise. Accountability has not been transferred to the system — that is not a thing that can happen. It has simply been dropped. When the incident arrives, the search for the accountable executive is a search for someone who never agreed to be one.
The follow-up, when the first answer is evasive. The evasive answer is the appeal to the human: “there’s a human in the loop for anything material.” Take it seriously and then test it, because it is sometimes true and usually not:
“Name the action classes that route to a human. Then tell me, from the last thirty days, how many the human declined.”
The second half is the one that works. A functioning control has a decline rate. A rubber stamp has a decline rate indistinguishable from zero, and when it is zero the honest reading is that the human is confirming, not deciding — which means the control that appears on the architecture diagram is not present in the system’s actual behaviour. Ask what the reviewer sees at the moment of decision. If the answer is a recommendation without the underlying evidence, you have found a control that cannot function even in principle, because no human can adjudicate a decision whose basis they cannot see, at the rate the machine produces them.
The archetype: a general insurer’s claims-adjustment agent. Recurring shape: the agent is given authority to settle low-value claims outright, which is genuinely sensible — the human review cost exceeds the claim value, and that arithmetic is why the programme was funded. The mandate is written as a monetary ceiling per claim. What the mandate does not carry is a rate limit, a per-claimant aggregate, or a policy-level ceiling. So the ceiling holds perfectly on every individual decision and fails completely in aggregate: a claimant with a pattern the system does not model, a policy wording the system reads more generously than the underwriting intent, and a volume of small correct-looking decisions that no single reviewer ever sees together. The failure is not that the agent exceeded its authority. It is that the authority was expressed in one dimension and exercised in three.
Question three: what is the cost per outcome — not per month?
This is the question a board is best equipped to ask and least likely to think of, because in the AI conversation everyone defers to the technologists, and cost per outcome is not a technology question. It is a unit-economics question, and a board asks those for a living.
The strong answer is a number with a denominator that is a business event: cost per resolved case, per processed claim, per closed ticket, per completed onboarding — inclusive of the system’s own consumption, and stated against the same number for the process it replaced or augmented. A programme that has this number will also volunteer its shape: which categories of work are cheap, which are expensive, and where the crossover sits at which the agent costs more than the human it was meant to relieve. That crossover exists in every deployment. Knowing where it sits is the difference between a programme and an experiment.
The weak answer is a monthly vendor invoice, sometimes divided by seats, sometimes divided by nothing at all. It is not that the number is wrong. It is that it has no denominator, so it cannot be compared to anything, cannot be forecast, and cannot be defended when it moves. And it will move, for a reason specific to agentic systems that most finance functions have not yet internalised: an agent’s consumption does not scale with the number of users. It scales with the number of steps the system takes, and every step re-reads the accumulated context. A task that takes the system twelve turns instead of four does not cost three times as much; it costs considerably more than three times as much, because each of those turns carries a larger context than the last. Usage growth and cost growth are not linearly related, and the relationship is worst precisely on the hard cases — which are the cases the programme was funded to handle.
What the silence means organisationally. Finance has not been given a model, so finance has priced the programme as a software licence. That is the whole finding, and its consequence is scheduled: somewhere around month eight, when volume has grown into the categories the pilot avoided, the run-rate breaks the assumption the business case was built on. At that point the conversation is no longer about whether the programme works. It is about whether it can be afforded, held under time pressure, with the CFO learning the cost structure for the first time in the same meeting where they are asked to approve more of it. Programmes rarely recover their political capital from that meeting.
There is a governance reading as well, and it is the one that matters at board level. A programme that cannot state cost per outcome cannot state benefit per outcome either, because the two share a denominator. Which means the benefits case — the reason this was approved — has never been measured. It has been asserted, and the assertion has been tracked with adoption metrics, which measure enthusiasm.
The follow-up, when the first answer is evasive. The evasive answer is the reassurance that costs are falling: “inference gets cheaper every quarter.” True, and irrelevant to your question. Ask:
“Take your ten most expensive completed tasks from last month. What did each cost, and what did the same task cost when a person did it?”
The tail is where the economics live, and the tail is what nobody instruments. A programme that can answer this has per-task cost attribution wired into its telemetry, which is a strong signal about engineering discipline generally. A programme that cannot has only aggregate spend, which means it has no ability to identify, price, or route away from the task classes that are destroying its margin.
The archetype: a healthcare payer’s prior-authorisation triage agent. The pattern: the pilot runs on clean, single-condition requests and the unit economics look transformative. Production traffic is not clean. The requests that consume the system are the ones with multi-year histories, conflicting documentation, and a clinical picture that requires the agent to pull, re-read, and reconcile a large record across many turns. Those are perhaps a tenth of volume and the clear majority of consumption. They are also, precisely, the cases where a wrong answer has a clinical consequence and a regulatory one. So the expensive tail and the risky tail are the same tail — which is an argument for routing it to humans on both grounds at once, and an argument nobody can make until someone has measured cost per outcome by category.
Question four: what happens when it is wrong?
Every system is wrong sometimes. The review question is never whether wrongness occurs; it is whether wrongness is contained — whether the organisation can state, in advance, the largest amount of damage a single wrong decision or a single bad afternoon can do.
The strong answer describes limits, not quality. Value ceilings per action and in aggregate. Escalation thresholds keyed to uncertainty or to case characteristics rather than to sampling. A gate at the point of action rather than a review of the output afterwards. Reversibility, stated honestly — which actions can be undone, which cannot, and whether the irreversible ones are inside or outside the agent’s mandate. And a blast radius someone can say out loud: “the worst single afternoon is roughly this, and here is the arithmetic.”
The weak answer is an accuracy figure. “It’s ninety-six percent accurate.” Accuracy is a quality metric and containment is a design property, and confusing them is the most common category error in the entire field. Consider what the strong-sounding number actually says: on an uncontained action class, four percent means the system will act wrongly, unsupervised, at whatever rate you feed it volume. That is not a quality statement. It is an incident schedule with the dates left blank. And the number is usually worse than it sounds, because it was measured on a distribution that production traffic does not match — accuracy quoted from an evaluation set is a statement about the evaluation set.
What the silence means organisationally. The programme has been governed as a model and not as an actor. Model governance asks whether the output is good. Actor governance asks what the actor is permitted to break. The organisation has a mature function for the first — validation, monitoring, performance thresholds — and typically no function at all for the second, because the second has historically been the human operator’s job, discharged by judgement rather than by control. When the human is removed from the loop, every property they were silently providing has to be reconstructed in software or it simply does not exist. Containment was one of those properties. Nobody noticed it leaving, because nobody had ever written it down.
The follow-up, when the first answer is evasive. The evasive answer is the monitoring answer: “we monitor for drift and we’d catch it.” Monitoring is detection, not containment, and the gap between them is measured in hours of unsupervised action. Ask:
“Suppose it is wrong in the same direction on every case for four hours before anyone notices. Walk me through what the organisation is looking at when someone does.”
Correlated failure is the case that matters and the case nobody models. Independent errors at four percent are an operating cost. The same error repeated across a morning’s volume — because a retrieved document was stale, or a prompt change shifted a boundary, or an upstream provider updated a model — is a single incident with hundreds of instances, and it is the shape almost every real agentic incident has taken. If the answer to this question is a number of affected cases the presenter can compute on the spot, the programme is contained. If the answer is “we’d stop it quickly,” it is not.
The archetype: a Gulf universal bank standing up a corporate-onboarding agent. The recurring pattern: the agent assembles and pre-adjudicates onboarding files, and its containment story is a human reviewer at the end. The reviewer approves at the rate the agent produces, which is the point of the programme. Then a change upstream — a screening-list format, a document classifier, a provider version — shifts how one category of entity is characterised, consistently, in the same direction. Every individual file looks reasonable to the reviewer, because each is internally coherent; the error is only visible across the population, and no one is looking across the population. The containment failure is not the absence of a human. It is that the human was positioned to catch individual errors and the failure mode was collective. Contained systems put a limit on the population, not only a reviewer on the instance.
Question five: if it acted wrongly last Tuesday, what could we prove today?
The deepest of the five, and the one that separates programmes that survive their first incident from programmes that die of it.
The strong answer is a record captured at the moment of action, not assembled afterwards: what the system knew and where each piece came from; under which authority it acted and who granted that authority; which policy or check evaluated the action and what that check returned; what it did; and what happened next. Captured synchronously, held immutably, retained for a period that matches the limitation period of the underlying obligation rather than the default retention of the logging platform. A programme with this can answer a regulator’s question about a specific Tuesday in an afternoon.
The weak answer is “we have logs.” On inspection, in nearly every case, this means chat transcripts and application telemetry — what was said, and that a call was made. Not what was retrieved, not under whose entitlement, not which policy evaluated it, not what the alternatives were. Reconstructing an action from that material is a project, and projects have durations, and the duration is the thing that kills the programme.
What the silence means organisationally. Evidence was treated as an observability concern rather than a governance one, so it was designed by the people who own uptime, to answer the question “is it working?” — a question that needs aggregates and sampling. The governance question is “what exactly did it do to this person, on this date?”, which needs completeness on the individual event. Those two requirements produce different systems, and only one of them was built. The organisational fact is that the assurance function was not in the room when the telemetry was designed, and by the time it is in the room the cost of retrofitting is a rebuild of the action path.
The consequence deserves stating in full, because it is not obvious and it is where I have seen the most damage. During a reconstruction project, nobody can bound what else the system might have done. Not “we think it’s fine” — genuinely cannot bound it, because bounding it is the same problem as reconstructing it. The rational response of any risk officer facing an unbounded exposure is to stop the system, and often the adjacent systems. So a single wrong decision on a single Tuesday, in a programme without evidence, produces a suspension measured in weeks, a remediation programme, and a permanent asterisk beside every future request for autonomy. Programmes rarely die of the wound. They die of the diagnosis taking too long.
The follow-up, when the first answer is evasive. The evasive answer is confident and general: “everything is logged.” Make it specific and dated:
“Pick a real action from three weeks ago. Reconstruct it in front of me — what it saw, whose authority, which check. Take as long as you need.”
The clock is the finding. Under ten minutes and the record exists. An hour with three engineers means it can be done but not at incident tempo and not at incident volume. “We’d need to come back to you” is the answer you should assume a regulator will also receive, and should be minuted as such. Note that this follow-up is also the highest-yield item in the session for a second reason: it is the only one that produces an artefact you can hand to the audit committee without translation.
The archetype: a specialty insurer’s underwriting-support agent. The pattern that makes this concrete: a broker disputes a declination months later and alleges the decision turned on a document that should not have been considered. The programme has the decision, the timestamp, and the model version. It does not have the retrieval set. So the honest answer to “what did it read?” is that it can be approximated by re-running today’s index against the same query — which is not the same thing, because the index has changed, and everyone in the room knows it. The insurer is not in trouble because the agent did something wrong. It is in trouble because it cannot demonstrate that the agent did something right, and the burden in that conversation sits with the party that cannot produce the record.
The five are one architecture, asked from five angles
Read as a checklist, the five look like five separate concerns owned by five different functions. They are not. They are five observation points on a single dependency chain, and the reason a review that runs all five is worth more than five reviews that each run one is that the dependencies are where the real findings live.
The chain runs in this order: authority → context → economics → containment → evidence. Not the order you ask the questions in — that order is chosen for the room, opening with the most concrete and least defensive question. This is the order the properties depend on each other in the build.
Authority is first because it is generative. The authority model determines what the agent can be built to do. Everything downstream is expressed in its vocabulary: a containment limit is a limit on an authority, an evidence record is a record of an authority being exercised, a permission-aware retrieval decision is an authority evaluated at read time. Decide it late and you are not adding a feature; you are re-deciding what the system is, which is why retrofitting authority means rebuilding the agent rather than wrapping it.
Context is second because it is authority applied to knowledge. The question “what can it see” is the question “whose entitlements govern retrieval” wearing different clothes. A programme with a real authority model gets permission-aware retrieval nearly for free, because the entitlement is already a first-class object it can evaluate at read time. A programme without one cannot build permission-aware retrieval at all without first building the thing it skipped — which is why so many teams have it permanently on the roadmap.
Economics is third because the unit of cost is the unit of authority. Cost per outcome requires knowing what an outcome is, which requires knowing which actions belong to which mandate. Programmes that cannot name their action classes cannot attribute cost to them, which is precisely why their finance model degenerates to a monthly invoice.
Containment is fourth because a limit needs something to limit. You cannot put a ceiling on an action class that has not been defined, and you cannot define an action class without an authority model. This is why containment conversations in undisciplined programmes always slide into accuracy conversations: accuracy is the only property available to discuss when the actions themselves have never been enumerated.
Evidence is last and is the load-bearing one, because it is the only property that is falsifiable. The other four can be asserted on a slide. Evidence either reconstructs the Tuesday or it does not. This is also why evidence is the property that fails most visibly when anything upstream was skipped: a record of an action is only meaningful if the action had a defined authority, a bounded context, and a check to record the result of. “We log everything” in a programme with no authority model produces a large volume of text that proves nothing, which is the most expensive possible outcome — the storage cost of assurance with none of the benefit.
This is why the questions compound rather than sum. A programme that fails question one will fail question five, reliably, because what the system could see was never bounded and therefore what it knew can never be reconstructed. A programme that fails question two will fail question four, because a limit requires a defined thing to be limited. When you score the session, do not count how many of the five were answered. Find the earliest one that failed, and treat everything after it as unverified regardless of how well it presented.
Where the regulators actually are — and why the vacuum argues for building now
A reasonable director asks the obvious question at this point: if these five properties matter, why is nobody requiring them? The answer is more interesting than “regulation is slow,” and it changes the calculus rather than excusing delay.
In the United States, the framework everyone assumed would specify these controls has just been withdrawn from the field. On 17 April 2026 the Federal Reserve, FDIC and OCC issued revised interagency model risk management guidance — OCC Bulletin 2026-13 and parallel issuances — which supersedes SR 11-7 and SR 21-8 and rescinds OCC 2011-12 among others. Two things it says matter here. It states that generative and agentic AI models are not within the scope of the guidance, with separate AI guidance promised and a request for information on banks’ use of AI to come. And it states that it does not set forth enforceable standards or prescriptive requirements.
Read that as a deferral, not an exemption. Every obligation attached to the underlying action is untouched: safety and soundness, consumer protection and fair lending, sectoral duties, third-party risk management. If an agent adjusts a fee wrongly, the fee was still adjusted wrongly, and the supervisory conversation proceeds on that basis. What has been removed is the document that would have told you which controls satisfy the obligation. The obligation without the specification is a harder position to be in, not an easier one — and the forthcoming guidance will be written against whatever the industry has by then built, by supervisors reading what the leading programmes actually do. Being one of the programmes it is written against is a materially better position than being one that has to retrofit to it.
The picture outside the US points the same way. India’s DPDP Act 2023, with the DPDP Rules notified in 2025, makes erasure a hard operational obligation rather than a policy statement — personal data must be erased once the purpose is no longer served, with data-principal requests handled inside defined timelines. For an agentic system, that obligation reaches into every derivative store the pipeline created, which is a design constraint at build time and an expensive discovery at audit time. The Reserve Bank of India’s FREE-AI committee report (August 2025) sets out seven principles and twenty-six recommendations for AI in the financial sector, including board-approved AI policies at regulated entities and a consolidated RBI guidance document to follow — an explicit signal of direction to every scheduled commercial bank, NBFC and payment operator. In the Gulf, supervisory frameworks and national AI programmes are advancing together, which produces an unusual condition: the same institution is often being encouraged to deploy ambitiously and expected to demonstrate control, simultaneously, to the same authority.
The common shape across all three markets is that the obligation is arriving ahead of the specification. That is exactly the condition in which the five properties are worth more than a compliance checklist, because a checklist tracks a specification and these five track the obligation itself. A programme that can state its authority model, bound its retrieval, price its outcomes, contain its errors and reconstruct its actions is defensible against a specification that has not been written yet. That is the point.
Running it as a ninety-minute working session
The five questions do not work as agenda items inside a status review. They work as a session with its own frame, its own participants and a written output. Ninety minutes is not arbitrary — it is roughly the point at which the prepared material runs out and the real answers start, and it is short enough that senior people will actually attend.
Who must be in the room. Three people cannot delegate their attendance, and the session should be rescheduled rather than run without them. The person who can grant authority — the business executive who owns the process the agent operates in, not their delegate, because question two is a question about a decision only they can make. The person who built the action path — the engineer or architect who can answer what actually happens at the moment of action, as opposed to what the architecture diagram says happens. The person who will be asked to defend it — risk, audit, or model risk, whoever will be in the room when a supervisor asks. Beyond those three, the sponsor and a scribe. Five to seven people total. The session degrades sharply above eight, because above eight the incentive to perform overtakes the incentive to find out.
Two rules about the room, both of which matter more than they sound. First, the vendor is not in it — not for the first session. Their presence changes what the internal team is willing to say, and one of the five findings you are looking for is whether the internal team can answer at all. Second, “I don’t know” is an acceptable answer and is minuted as one. Say this out loud at the start. Without it the session produces confident approximations, which are worse than gaps because they cannot be actioned.
The agenda. Ten minutes of framing: what the session is for, the three rules, and the explicit statement that this is not an audit and nothing said here is a finding against a person. Then sixty minutes across the five questions — roughly twelve minutes each, though they will not divide evenly and should not be forced to. Ask the question. Take the first answer without interrupting. Ask the follow-up if the first answer was a reassurance, a capability, a metric, or a roadmap item. Then stop, and let the scribe read back what was captured before moving on. That read-back is the mechanism; it is what converts a conversation into a finding, and it is the step every rushed session drops.
Then fifteen minutes of classification, done in the room and out loud: for each question, is this answered, partially answered, or open. Do the classification with the team present rather than afterwards in private, because a finding the team agrees with on the day gets remediated and a finding delivered afterwards gets contested. The last five minutes assign an owner and a date to each open item. An unowned finding is a note.
What gets written down. One page, produced within twenty-four hours while the session is still true. For each of the five: the question, the answer as given (in the presenter’s words, not paraphrased into governance language — the paraphrase is where the finding gets lost), the classification, the specific gap if any, the owner, and the date. Then one line at the top: the earliest question that failed, because that is the dependency finding and everything after it is unverified. Then one line at the bottom: whether any answer routed to the vendor, and which.
That last line deserves its own attention, because it is the meta-finding the session is uniquely able to produce. If every answer arrives via the vendor, the discovery is not about any single question. It is that the obligations stayed in the building and the ability to meet them was outsourced. That is a sourcing decision, made implicitly, that no committee approved — and it is the finding most likely to change what the board does next.
What to do with each class of finding
Findings from this session fall into four classes, and treating them all as a single remediation backlog is how a good session produces nothing.
A missing decision. Nobody decided what the agent may see, or who granted its authority, or where the containment ceiling sits. This is the most common class and the cheapest to fix, because the fix is a meeting rather than a rebuild. Someone with standing writes the decision down and signs it. Do not let this become an engineering ticket — the gap is not that the system lacks a capability, it is that the organisation lacks a decision, and routing it to engineering guarantees a technical implementation of an unstated intent. Target: two weeks, and it should be the first thing done, because several other findings will turn out to have been downstream of it.
A missing mechanism. The decision exists but the system cannot enforce it — permission-aware retrieval that is not built, aggregate limits that are not implemented, evidence capture that does not exist at the point of action. This is real engineering with a real cost, and the honest board response is to price it and sequence it rather than to demand it by a date. One judgement to make here, and it is the expensive one: whether the mechanism can be added to the existing action path or whether the action path has to be rebuilt around it. Authority and evidence are usually the second kind. A team that says “we can add that” about evidence capture should be asked to demonstrate it on one action class before the estimate is believed.
An unpriced exposure. The system is doing something whose worst case nobody has bounded — an uncontained action class, an unmeasured cost tail, an unreconstructable record on an action with a long limitation period. This class should not go into a backlog at all. It should go to whoever sets risk appetite, with the exposure stated in the units that function uses, and a decision taken to accept it explicitly or to constrain the system until it is bounded. The point of surfacing it is not remediation; it is that someone with the standing to accept the risk actually accepts it, in writing, rather than the organisation carrying it by default.
A capability that was outsourced by accident. The answers routed to the vendor. The remediation is not technical and cannot be delivered by the vendor. Someone internal has to be able to answer, which means someone internal has to understand the action path well enough to defend it — a staffing and knowledge-transfer decision, with a timeline measured in quarters, and one that should be made deliberately rather than discovered during an incident. Where a genuine dependency is going to remain, put it in the contract: evidence access, retention commitments, notification of model changes that alter behaviour. A dependency you have priced and papered is a position. One you discovered in a review is a finding.
The strongest objection, and where it breaks
The serious counterargument runs like this: this is exactly the governance theatre you claim to be against. Five questions, a scribe, a one-pager, a classification scheme. You have described a ceremony. Meanwhile the competitor down the road is shipping.
It is a fair challenge and it lands on a real failure mode. Most governance activity in enterprise AI is theatre — a review board that meets monthly and approves everything, a model inventory nobody reads, a risk assessment completed after the decision it was meant to inform. The word “governance” has been thoroughly devalued by people who apply it as a process wrapper around work they cannot evaluate.
The distinction is whether the activity changes the artefact. A governance ceremony produces a document about the system. These five questions produce changes to the system: an authority written down and enforced, a retrieval boundary that holds at read time, a ceiling in the code path, a record captured at the moment of action. If the session produces a one-page finding list and nothing in the system changes, the objection is correct and the session was theatre. Judge it on that basis. I would rather it be judged on that basis, because it is the only basis on which the practice is worth anything.
On speed, the empirical claim runs the other way, and it is the part senior people consistently find counterintuitive. The programmes I have seen answer all five are the fastest-moving in their sectors. Not despite the discipline — because of it. When the risk function can verify a claim instead of taking it on trust, approval stops being a negotiation and becomes a check. When the authority model is explicit, expanding an agent’s mandate is an amendment rather than a fresh architecture debate. When evidence exists, the first incident is an afternoon’s investigation and a targeted fix rather than a suspension. The slow programmes are the ones re-litigating first principles at every gate, because nothing was ever written down in a form anyone could check.
Governance built as architecture is an accelerant. Governance performed as ceremony is a two-hour meeting everyone dreads, and the objection above is a fair description of it. Both exist. The five questions are how you tell which one you have.
Take the five into your next review
You do not need to understand transformers to govern an AI programme. You need five questions, a room with the right three people in it, and the nerve to sit through the silences rather than filling them.
The silences are the output. A question that produces an immediate, specific, one-sentence answer has told you a decision exists. A question that produces a pause has told you where the decision is missing, which is more useful, and is available to you at no cost beyond ninety minutes and the willingness to be told something inconvenient in front of the people who will have to fix it.
Ask them in order. Write down the earliest one that failed. That is the finding.