The Governance Case Before the Pilot

Answer These Before Anything Touches a Customer

The point of a pre-deployment case is not to slow the pilot down. It is to get the assumptions written while they can still be checked. Six answers carry most of the weight. Purpose: what decision or task, for whom, and what success looks like as a number. Data: what goes in, from where, on what basis, and what may never go in. Validation: what evidence exists, against what comparator, on data resembling yours. Monitoring: which metrics, at what cadence, on whose desk. Fallback: what happens when it is unavailable or wrong, and who may switch it off. Owner: the person accountable for the outcome, not for the project.

• Purpose, data, validation, monitoring, fallback, owner — six answers, written before the pilot begins
• State success as a number against a comparator, not as an efficiency ambition
• The data answer must include what may never enter the system, not only what will
• The owner is accountable for the outcome; a project sponsor is a different role

The Questions a Risk Committee Will Ask

Committees converge on a predictable set, and the questions that stall a proposal are rarely technical. What is the worst realistic outcome for a customer, and how would we discover it had happened? What population was this validated on, and how does it differ from ours? Which existing process does it replace, and how good is that process — measured rather than assumed? Who is accountable when it is wrong? What does switching it off cost, and could we still operate? Which obligations does it touch: conduct, records, data protection, model risk, third-party? And what did we actually commit to in the contract? Bring answers, or the meeting produces an action list instead of a decision.

• The worst realistic customer outcome, and the mechanism by which you would detect it
• The validation population versus yours, and the measured quality of the process being replaced
• The cost of switching it off, and whether the institution can still operate without it
• Which obligations it touches, and what the contract actually commits the firm to

Proportionality, and the Pilot That Never Ends

Not every use needs the same weight of case. Scale it to consequence: an internal drafting aid with no customer effect and no confidential input does not need what a credit decisioning model needs, and running both through the same process teaches everybody that the process is theatre. What does need discipline at any scale is the exit. Pilots become permanent quietly — the review date passes, the people who used to do the work have moved on, and the tool is load-bearing without ever having been approved as such. Set a review date with a named decision maker, define in advance what would end the pilot, and record what the firm would do if the provider withdrew tomorrow.

• Scale governance to consequence — identical process for trivial and critical uses teaches cynicism
• Pilots become permanent by default; set a review date and name who decides at it
• Write down what result would end the pilot before any results exist
• Record the answer to provider withdrawal — dependency accumulates faster than anyone plans for

Try It Yourself

A governance case is only useful before anyone is committed to the answer. Write one for something your institution could plausibly do.

Proposed use and the decision it affects:
Purpose — success stated as a number, against what comparator:
Data — what goes in, from where, on what basis, and what may never go in:
Validation — what evidence, what comparator, on data resembling ours:
Monitoring — which metrics, what cadence, whose desk:
Fallback — what we run on when it is wrong or unavailable, and who may switch it off:
Owner — named person accountable for the outcome:
Worst realistic customer outcome, and how we would detect it:
Obligations touched — conduct, records, data protection, model risk, third-party:
Review date, and what result would end the pilot: