Why Governance Must Come Before AI in Leadership Decisions

The wrong order

A CHRO brought a leadership assessment platform to the talent committee, confident in what it could offer. The vendor's dashboard was polished, the competency taxonomy precise, and the security and data-residency questions were answered without hesitation. The General Counsel asked one question. What had the board seen that would allow it to govern the system if a promotion decision made on its outputs were later challenged? The room did not have an answer. That question should have come first.

I have watched the order go wrong more than once. The board sees the demo before it sees the controls. Procurement sees the vendor pack before NomCo sees the governance burden. HR sees more data and assumes the evidential position has improved. It has not. More data does not remove the governance problem; it sharpens it.

This is the sequence error underneath a great deal of current AI deployment in leadership work. Boards debate whether the output looks useful, then ask legal and governance teams to clean up the implications afterwards. By the time a board is debating whether to trust the output, the governance work should already have been done.

In “Where Leadership Analytics Goes Wrong and How to Fix It”, I introduced the Claim Boundary: a published statement of what a leadership system does claim, does not claim, and cannot yet claim on the evidence available. That is the statement of limit. This article asks a stricter question one step earlier. What has to exist before the board is willing to let that claim into the room at all?

The distinction matters. A Claim Boundary tells the board where the evidence stops. A Regression Pack tells the board whether the system is governed well enough for the board to rely on anything inside that boundary. D is about honesty; E is about permission. They are not the same discipline.

This is one of seven disciplines I am publishing on evidence-based leadership decisions. Each examines a different point at which the evidence and the confidence diverge.

What the governance literature already established

The literature is clearer on this than current deployment behaviour suggests.

Bogen and Rieke showed that employers and vendors can adopt automated hiring tools without giving buyers or affected people a sufficiently clear view of what is being measured, how judgments are formed, and where the risks sit (Bogen & Rieke, 2018). That disclosure gap is not accidental. It is structural. Providers invest heavily in documenting what a system can do but rarely invest with equal precision in documenting where it should not be relied on. Raghavan and colleagues deepened the point: hiring-system promises about fairness and objectivity often run further than the practices beneath them can support (Raghavan et al., 2020).

The accountability literature moves in the same direction. Mitchell proposed model cards because high-impact systems need a standard way to state intended use, limits, and relevant caveats (Mitchell et al., 2019). Raji argued for internal algorithmic auditing because accountability gaps do not close themselves (Raji et al., 2020). NIST's AI Risk Management Framework begins with mapping and governing risk, not with a dashboard or a vendor promise (NIST, 2023).

Other high-stakes domains already know the sequence problem is real. SR 11-7 and PRA SS1/23 do not ask financial institutions to use a model first and document it later, they assume the reverse. Model use is a governance issue before it is a performance issue. COSO's internal control framework makes a related point in plainer language: a control environment is not something you describe after the process runs. It is what makes the process trustworthy while it runs (COSO, 2013). Reporting disciplines such as TRIPOD and TRIPOD+AI apply the same logic to prediction models (Collins et al., 2015; Collins et al., 2024). The same logic extends to model design itself. In settings where the stakes are material, explanation after the fact is a weaker control than systems that remain inspectable while the decision is being made (Rudin, 2019).

Those literatures are saying something simple. Governance is not the paragraph at the back of the deck; it is the precondition of responsible use.

Why documentation after deployment is not governance

Boards often receive the wrong pack. They receive a procurement summary, an information security response, perhaps a privacy note, perhaps later a model card, and perhaps later still an assurance deck once the pilot is already underway. All of that may be helpful, but none of it resolves the sequencing problem.

Documentation after deployment explains what was built, while governance before deployment limits what the system is allowed to do inside a decision. Those are different objects with different purposes. The distinction matters because leadership decisions have social lock-in. Once a system's output has entered a succession discussion, helped frame a shortlist, or shaped who counts as credible, the board is no longer judging in a clean room. It is judging under the influence of an output already being treated as meaningful. Governance at that point is being asked to ratify a use that is socially underway.

A board does not need thicker description after the fact. It needs a smaller, sharper pre-deployment record that constrains behaviour. What is the system for here, exactly? What is it not for? What evidence classes support the output? When must the system abstain? How will the board know if the output should stop being relied on?

The regulatory direction of travel is the same, and the AI Act is phasing in. Transparency obligations have applied since 2 August 2026, the UK's Data (Use and Access) Act is in force, and the Annex III high-risk obligations that cover employment uses are set to apply in December 2027.

Boards should not wait for a compliance date; the burden of proof starts before reliance.

Regression Pack

This is the missing object. I use the phrase deliberately. Boards do not need a glossy AI policy once the system is already running. They need a pre-deployment pack that shows how the system behaves under challenge, how its claim narrows when evidence weakens, and what happens if live use falls below the standard the board was promised.

It is not a model card clone. Model cards help. Internal audits help. Security reviews help. But boards need one governance object they can use in procurement, approval, and oversight without becoming technical specialists. The first page of the pack should be the Claim Boundary, introduced in my previous article “Where Leadership Analytics Goes Wrong and How To Fix It”. The remainder governs first reliance, ongoing challenge, and conditions for withdrawal.

Seven elements turn it into practice:

1. Intended use

   The exact decision context must be named. Search-universe expansion is different from shortlist pressure-testing. Shortlist pressure-testing is different from committee support in succession. A board should not have to infer the use from marketing language.

2. Excluded use

   The pack should state, in plain English, what the system must not be used for. Not a sole basis for an employment decision. Not a covert inference about personal qualities. Not a replacement for committee judgment.

3. Evidence classes

   The board should see what classes of evidence are in play. Public record. Structured inputs. Documented track record. Human review. Role-relevant outcomes. Without that, the board cannot judge whether the claim is proportionate.

4. Abstention conditions

   Low coverage, weak construct match, role ambiguity, sparse evidence, conflicting signals. These are not edge cases. They are normal conditions in leadership work. A system that never abstains is not complete. It is undisciplined.

5. Error history

   What has the system been wrong about? What weak spots are known? What changed after challenge or correction? Boards do not need a perfection story. They need an error culture.

6. Challenge tests

   What would materially alter the conclusion? Changed role requirements? Source corrections? Stronger contradictory evidence? If the provider cannot say what would change the output, the board is dealing with a conclusion that has not been properly stress-tested.

7. Rollback conditions

   At what point does the board stop relying on the output? This is the most neglected element. A system should not enter a leadership decision unless the board also knows what would cause it to suspend use, narrow use, or revert to human-only judgment.

What boards should require before AI touches real decisions

A Regression Pack does not rescue a weak system. It does not validate a vague construct. A strong pack cannot make a weak claim stronger than the evidence allows. Governance is necessary. It is not sufficient.

I need to be precise about regulation. This is not legal advice. UK data protection and recruitment governance, alongside the AI Act, all move in the same direction. Documentation, due diligence, meaningful oversight, and a workable record of challenge are not optional clean-up work once the tool is live, they are design decisions.

This argument would weaken on two conditions: that governance retrofitted after deployment creates controls as robust, inspectable, and board-usable as systems designed with governance from the start, and that documentation produced after the fact constrains real-world use as tightly as a pack approved before first reliance.

Before the next AI-enabled tool enters a live succession, appointment, or leadership review, the board should require the pack: ahead of the demo, the press-ready summary, and the model explainer that arrives after the pilot has already run.

The board should be able to see, before first use, what the system is for, what it is not for, what evidence classes support it, where it abstains, what it has got wrong, how it will be challenged, and what would cause the board to stop relying on it. That is the minimum burden of proof for letting AI near a consequential leadership decision.

And once that discipline is in place, the next question becomes harder again. Not whether the system is governed, but whether the leaders using it can themselves govern AI in role. That question cannot be answered by self-report; it has to be answered by record.

Governance is not what comes after trust breaks, it is what makes reliance thinkable in the first place.

Written by James Nash.

First published on inBeta.io. Co-published on Substack. Summer 2026.
Series: The Seven®, by James Nash. © Copyright 2026 inBeta. inBeta, Optics, Divergence and The Seven are all trademarks of inBeta Ltd