An AI governance operating model is the set of roles, decision rights and approval gates that decide which AI systems reach production, who can change them, and what evidence is required at each step. For a finance team it works when those gates are wired into the deployment pipeline and the model registry, not when they live in a committee charter that nobody reads between quarter-ends.
Most governance decks describe a committee. A committee is not an operating model. It is a place where decisions are ratified after they have already been made in a pull request. The gap between the two is where the real risk sits: a feature that started as a lookup, quietly grew a language model in the retrieval path, and now drafts text that lands in a customer communication or a journal entry with no validator having ever seen it. Governance that only convenes monthly will always be describing a system that shipped three weeks ago.
Roles before committees
Start with decision rights, because a role that cannot say no is decoration. We map every AI system in finance operations to four accountable roles, and we make each one a named person, not a function.
- Business owner. Accepts the residual risk of the system in production. Owns the false-positive budget and the cost of the errors the model will make. This is the person who has to live with what happens at quarter-end when the model is wrong.
- Model developer or vendor liaison. Owns the build, the eval sets, the drift monitoring and the change log. For a bought system, this role owns the vendor’s evidence and the questions the vendor cannot answer.
- Independent validator (second line). Reviews the model on data the developer never touched, checks for lookahead and leakage, and holds the production gate. Reports outside the chain that built the model.
- Internal audit (third line). Tests whether the first two lines actually did what the policy says, on a sample, after the fact.
Those last two are the second and third of the three lines of defense, and the word “independent” carries the whole sentence. If your validator reports to the person whose bonus depends on the model shipping, you have one line of defense wearing three hats. In finance the classic failure is the validator who signs off on a fraud model using a test set that shares customers, and therefore leakage, with training. The model looks excellent until entity resolution reveals that half the test population was memorized.
Gates that live in the pipeline
A gate is a point where a system cannot proceed until specific evidence exists and a specific person has signed. The evidence has to be a build artifact, produced by the pipeline, not a slide produced by a person. We wire four gates for finance AI.
- Intake gate. Every AI system enters the model inventory before it gets a data connection. No registry entry, no credentials. This is the cheapest control you will ever install and the one most often skipped.
- Data gate. Before training or retrieval indexing, the lineage of every input is recorded and point-in-time correctness is proven. For a model that scores transactions, this means showing that no feature encodes information unavailable at decision time. Lookahead is the single most common defect we find, and it is invisible in backtest accuracy.
- Validation gate. Independent evaluation on a held-out set with the failure modes named in advance: what the false-positive budget is, where drift will be measured, what the reconciliation tolerance is against the system of record. The validator signs, or the system waits.
- Production gate. Straight-through processing is allowed only for the decisions where the audit trail is complete and the rollback path has been tested by actually rolling something back. Everything else routes to a human queue with the model’s reasoning attached.
The point of putting gates in the pipeline is that they stop being negotiable. A registry that is a spreadsheet gets edited after the fact. A registry that issues the credential a job needs to read production data cannot be bypassed by someone in a hurry before quarter-end.
Change is the event that matters
The version that passed validation is almost never the version running six months later. Someone swapped the embedding model, widened the retrieval window, edited a prompt, or the vendor pushed an update. Each of those changes the behaviour of the system, and in a governance model that only looks at initial approval, each is invisible.
So we treat change as the primary governed event, not deployment. A prompt edit is a model change. A new document in the retrieval corpus is a data change. A vendor version bump is a change you did not make but now own. Each gets a registry entry, a diff, and a rule for how much re-validation it triggers. Small changes get a monitoring check. Changes that move the decision boundary go back through the validation gate. The registry has to carry the lineage that makes this decidable, which is why the inventory and the operating model are the same project wearing two names.
None of this requires a large second line. It requires that the validator’s signature is a precondition the pipeline enforces, that every AI system is in the inventory before it has a data connection, and that a prompt edit is logged with the same seriousness as a change to a coefficient. The committee can keep meeting. What makes its decisions hold is the wiring underneath it: the registry that issues credentials, the gates that block a job without a signature, and the change log that catches the version nobody remembered to re-validate.
FAQ
Do we need a separate AI governance committee, or can our existing model risk committee absorb it?
In most finance teams the existing model risk committee can own it, provided its charter is extended to cover data lineage and prompt or retrieval changes as versioned events. A separate committee usually adds a meeting without adding a control.
Who signs off before an AI system touches a general ledger or a customer decision?
The business owner accepts the residual risk, but the second line validator holds the gate. Nothing reaches production posting or a customer-facing decision until validation is signed and the rollback path is tested.
How is governing an LLM feature different from governing a scorecard?
The scored population and the decision boundary are the same problem. What changes is that the input space is unbounded text, so your controls move toward eval sets, retrieval provenance and output constraints rather than coefficient review alone.