Three proposals, forty minutes, six definitions of "comfortable"
I have sat through some version of this agenda many times. Three AI proposals are listed for one board meeting, with forty minutes allotted. The first is a drafting assistant for internal reports. The second is a chatbot for customer enquiries. The third is a model that would help decide which applications for credit terms are approved. The chair, being sensible, asks the question every chair asks: "Are we comfortable with this?"
Six directors answer, and I count six different answers. One hears "comfortable" as "nobody will be embarrassed." Another hears "the legal exposure is manageable." A third hears "we are not falling behind competitors." Nobody is wrong, and nobody has been told what the word means. The meeting runs over, two items are deferred, and management leaves unsure what would have earned a yes.
To be clear about what follows: the group in this article is a composite. It is a mid-sized regional services group with about $24 million in annual operating profit, and every figure below is illustrative, not research and not a client's data. The point is the structure, which you would re-size to your own balance sheet.
Why "cautious" is not a risk appetite
When I ask a board how it feels about AI, the most common answer is "cautious." Management is then expected to bring forward anything risky. This sounds prudent and it fails in three ways.
- It is not measurable. No one can check whether an initiative is inside "cautious." A limit that cannot be tested cannot be enforced.
- It slows the safe items. Without a line, management cannot tell which proposals are routine, so everything arrives at the board and waits in the same queue.
- It hides the dangerous items. When every proposal receives forty minutes of vague discussion, the one that deserved real scrutiny gets the same attention as the others.
A risk appetite is a different object. It states how much loss the organisation will accept, how quickly it must find out when something goes wrong, and when the board wants to hear about it. Those are quantities. If your board already sets appetite for credit, liquidity or operational risk, you know the form. AI deserves the same treatment, in numbers short enough to fit on half a page.
The Four Limits: classify, cap, time, trigger
I use four limits for every class of AI use. The sequence matters, because each one depends on the one before it.
First, set the organisation-wide ceilings. In the composite, the board tolerates a single AI-caused loss of 1 percent of operating profit, which is $240,000, and a cumulative annual loss of 2.5 percent, which is $600,000. Then apply the four limits.
- Classify. Sort uses by who is touched and how reversible a mistake is. Class A is internal drafting and analysis, where errors are caught and fixed. Class B is customer-facing work, where some harm can be undone and some cannot. Class C is anything that decides money, employment, health or legal standing, where the harm is hard to reverse.
- Cap. Give each class a loss ceiling per event. Class A: $20,000. Class B: $120,000. Class C: $240,000, the full single-event tolerance, and only with committee sign-off.
- Time. Set the longest acceptable time to detect a failure. Class A: 30 days. Class B: 7 days. Class C: 24 hours. A limit you cannot detect in time is not a limit, because the loss keeps accumulating while you look.
- Trigger. Say when a matter returns to the board: any single event above 50 percent of its class cap, or cumulative loss above $300,000, half of the annual tolerance.
The third limit is the one boards omit most often. A cap of $240,000 means little if the monitoring in place would find a fault 9 days later. The ceiling and the detection time have to be read together.
The same agenda, re-run with the statement in hand
Now put the same three proposals in front of the same board, with the statement approved at an earlier meeting.
The drafting assistant is Class A. It touches only internal documents, management confirms detection within 30 days through routine review, and the worst plausible loss sits under $20,000. It is approved in two minutes, with no discussion of comfort.
The customer chatbot is Class B. The cap is $120,000 and the board needs detection inside 7 days. Management's plan reviews a sample of conversations monthly, which is too slow. The board approves with one condition: weekly review of flagged conversations before launch. That is a precise instruction rather than a general unease.
The credit-terms model is Class C. It decides money, so the limit is 24 hours to detect a fault, and the proposed monitoring would catch problems in about 9 days. The proposal goes back, with the gap stated plainly: 9 days against a 24-hour limit. Management knows exactly what to fix.
The meeting ends 15 minutes early. One item is approved, one is approved with a condition, and one is declined for a reason that can be written in a sentence. Declining it precisely is as useful to management as approving the others quickly.
I have written separately about matching effort to stakes at the task level, in Not Every AI Task Deserves Your Best Model. This is the same discipline, applied one level up, to what the board itself must decide.
The half-page template
The statement fits in one table with seven columns and one row per class. The columns, in order:
- Class: A, B or C.
- Example uses: two or three concrete examples, so classification is not a debate.
- Loss cap: the per-event ceiling in currency.
- Detection time: the maximum time to find a failure.
- Escalation trigger: what sends a matter back to the board.
- Owner: one named executive who reports against the row.
- Review date: when the row is next examined.
Filled in for the composite, the three rows read as follows.
- Class A: internal drafting and analysis; cap $20,000 per event; detection within 30 days; escalate above $10,000 in a single event.
- Class B: customer-facing assistants and communications; cap $120,000; detection within 7 days; escalate above $60,000 in a single event.
- Class C: decisions affecting money, employment, health or legal standing; cap $240,000 with committee sign-off; detection within 24 hours; escalate above $120,000 in a single event.
Beneath the table, one line applies to all classes: cumulative AI-caused loss above $300,000 in a year returns to the board.
What to settle in the first 90 days
Do not try to perfect the statement. Get a first version approved, then use it for a quarter and learn where it pinches.
- Weeks 1 to 3: choose the anchor. Agree the single-event and annual tolerances with the CFO, tied to a figure you already report, such as operating profit.
- Weeks 3 to 6: classify what exists. List AI uses already running in the business, including the ones nobody formally approved, and assign each a class. This step usually surprises directors.
- Weeks 6 to 9: test detection. For each Class B and C use, ask how long a failure would take to surface today. Any answer longer than the limit is a gap to fix or a reason to defer.
- Weeks 9 to 12: approve and schedule. The board adopts the statement, names an owner per class and puts a review in the calendar. I recommend two reviews a year.
A caveat belongs here. The numbers in this article are a composite, and they should be sized to your balance sheet, your sector and your capacity to absorb loss. If you operate in a regulated sector, align the statement with the risk appetite framework your regulator already expects, rather than building a parallel one. This is a governance method, not legal or regulatory advice, and your counsel and your regulator come first.
The aim is modest. A board that has written down four numbers per class has not removed the risk. It has made every later conversation shorter and more exact, and that is most of what good oversight requires.
Related evidence: The EU AI Act obliges providers of high-risk AI systems to report a serious incident to the market surveillance authorities immediately after establishing a causal link to the system, and in any event not later than 15 days after becoming aware of it — a disclosure deadline fixed in law rather than decided during the incident. (the EU AI Act's 15-day serious-incident reporting deadline)
The Model Cards paper proposes short documents that accompany trained machine learning models and report benchmarked evaluation across a variety of conditions. (the Model Cards for Model Reporting paper)
