AI Governance for Engineering Teams: Beyond the Ethics Board

Governance is usually assessed by whether the process exists. The better assessment is a stopwatch: pick a model in production and time how long it takes to reconstruct how it got there.

Penhale Mutual's internal audit asked a reasonable question about the fast-track model: what was it trained on, what thresholds was it approved against, who approved it, and what has changed since.

The governance process had run correctly. The ethics board met quarterly, reviewed a deck, asked good questions, approved with conditions. The minutes existed and said so.

Answering the four questions took eleven days. The training data was described in a notebook nobody could locate a current copy of. The approved thresholds were in the deck, which reflected a model version that had been retrained twice since. The conditions attached to approval had been actioned, probably, in a Slack thread. The person who could confirm had changed teams.

Nothing was hidden and nobody had behaved badly. The minutes were evidence that a meeting occurred. They were not evidence about the system currently deciding how fast people get paid.

The unit is the artifact, not the meeting

This post is narrow on purpose: governance as the record that a decision was made deliberately, produced by the engineering workflow rather than alongside it.

The adjacent pieces belong elsewhere and it's worth being strict about the boundary. What the system is allowed to decide is the autonomy level. Who bears a wrong output is the harm question. What actually refuses a release is the quality gate — the gate does the stopping; governance is what the stopping leaves behind. The broader organisational and market case for AI governance is its own subject.

The test you can run: pick a model in production and time yourself answering the four questions above from artifacts alone — no asking colleagues. That number is your governance, expressed honestly.

Why the board can't see what it's governing

The structural problem isn't that boards are unserious. It's the information path: the board's picture of the system comes from a document prepared by the people being reviewed, describing a version that will have moved by the time anyone acts on it.

Three gaps open up, and none of them is detectable from inside the meeting:

• The deck describes intent; the pipeline deploys artifacts. A slide saying evaluated for subgroup performance and a CI job that blocks on subgroup thresholds are different objects, and only one of them holds after the meeting ends.

• Approval is a point; the model is a stream. Approving version 3 says nothing about version 7, and there's usually no mechanism that notices the difference.

• Conditions have no home. "Approved, subject to monitoring for drift" is a real decision that lands in prose. Prose doesn't fail a build.

None of this argues for abolishing the board. It argues that the board should be setting thresholds and policies that something else enforces, rather than rendering per-model verdicts on documents.

The test: take one condition attached to a past approval and find the artifact that enforces it. If it's a sentence, it was a hope.

Where each answer has to live to survive a year

The reconstruct test fails in predictable places, and each has a fix that is an engineering change rather than a process one.

The question	Where teams look	Where it survives	Fails when
What was it trained on?	A notebook, someone's laptop	A model card in the repo, versioned with the code	The card is a PDF written at review time
What thresholds was it approved against?	The approval deck	Gate config in the pipeline, in version control	Thresholds live in a slide
Who approved it, on what evidence?	Minutes	A pipeline record naming the approver and the eval run	The signature isn't attached to an artifact
What has changed since?	Memory, Slack	Deploy history plus the eval diff per version	Nobody diffs evals between versions

The common property of the right-hand column is that every answer is a byproduct of shipping rather than a thing someone has to remember to write. That's the whole mechanism. Documentation produced as a separate act decays because nothing breaks when it's wrong; documentation the pipeline refuses to deploy without stays current because it's load-bearing.

The fourth row is the one most often missing entirely, and it's the one auditors actually ask about. A per-version eval diff — which cases improved, which regressed — turns "what changed" from an archaeology project into a link.

The test: try to deploy a model with a deliberately incomplete model card. If it deploys, the card is a convention, and conventions don't survive a busy quarter.

Automate the routine so humans get the novel

The reason to build this isn't tidiness. It's that a governance function reviewing everything reviews nothing carefully — the same attention problem that makes a board that approves every change worthless.

So split by what the check can see. Automated gates handle anything with a threshold: accuracy floors, subgroup bounds, prediction-distribution shifts against the previous version, data-quality ranges. Human review handles what a threshold can't express — a new use case, a novel data source, a change in who the subjects are, an autonomy level moving up.

Ownership divides cleanly and should be written down: model teams own the card and the evaluation evidence; platform owns the gates, the pipeline and the monitoring; the governance function owns the policies and thresholds the gates enforce. That division is what prevents both failure modes — governance as someone else's problem, and governance as a queue.

The test: count how many model reviews your governance function did last quarter and how many were genuinely novel. A high ratio of routine means your humans are doing a job a threshold could do.

When this is more than you need

• One model, one team, one use case. You have a decision to make, not a governance system. Write the four answers in the README and move on; a process amortises judgment across models and you don't have several yet.

• Nothing consequential is being decided. Internal summarisation with a human reading every output doesn't need an approval trail. Say so explicitly rather than letting it become precedent.

• A research or exploration phase. Gating experiments teaches people the pipeline is an obstacle. Gate the path to production instead, and put a date on when the experiment stops being one.

• When the record would be the only artifact. Producing evidence nobody will ever read, for a system nobody could act on, is the compliance theatre this is supposed to replace — just with better tooling.

The test: for each governance artifact you produce, name who has read it and what they did. Anything with no reader is cost without coverage.

What to change this week

Don't convene anything. Run the stopwatch.

Pick your most consequential model and try to answer the four reconstruct questions from artifacts alone. Whatever the number is, it's the honest state of your governance, and it's the most persuasive thing you can put in front of a leadership team — because it isn't an opinion about rigour, it's a duration.

Then fix the slowest answer, and fix it by making the artifact a deployment requirement rather than a task. One row, wired into the pipeline, is worth more than a framework adopted whole.

Penhale's reconstruct time is under an hour. The model card lives beside the code and CI won't deploy without it, the thresholds are gate config with a change history, and every deploy links to its eval diff. The ethics board still meets — it sets the thresholds now, which is the part it was always best placed to do.

Sources

• European Union, Regulation (EU) 2024/1689 — the AI Act, which classifies AI systems by risk tier and attaches documentation, record-keeping and human-oversight obligations to the high-risk tier. Referenced here for the shape of its obligations, not for any figure.