AI Governance for Financial Services

This page is general analysis, not legal or regulatory advice, and it does not describe the internal controls, systems, or practices of any specific employer. It reflects patterns common across regulated operational environments, discussed at a conceptual level.

Model governance and execution governance are different obligations

A model risk management framework typically asks whether a model was validated, whether its outputs are monitored for drift, and whether it performs within approved bounds. That is necessary and it is not sufficient. It says nothing about whether a specific downstream action the model's output leads to — a trade instruction, an account change, a customer communication — was authorized to actually execute. Model governance evaluates the model. Execution governance evaluates the action. Financial-services AI programs that only build the first have a real gap in the second, even when the model governance work is excellent.

Segregation of duties applied to an AI pipeline

Segregation of duties exists so that no single actor can both initiate and approve a consequential action unchecked. Applied to an AI system, this means the entity that generates a proposed action (the model or agent) should not also be the entity that authorizes its execution, and the policy that governs what is authorized should be maintained separately from the system executing against it. When the same pipeline both proposes and approves its own actions, segregation of duties has not been preserved just because a human is nominally "in the loop" somewhere upstream.

What examiners and auditors actually want as evidence

Observability — logs showing what a system did — answers "what happened." It does not answer "was this authorized, and by what standard." Audit-grade evidence for an AI-driven action needs to show: what policy version was in effect at decision time, what the system was authorized to do under that policy, what it actually did, and who or what approved the specific action taken. A dashboard showing model accuracy metrics is not evidence of execution control. A tamper-evident record of an authorization decision, tied to a specific action and a specific policy version, is.

It's worth stating plainly: a technical assessment or governance review is evidence a control exists and was evaluated. It is not, on its own, proof of regulatory compliance, and no vendor or advisor should imply otherwise. Compliance determinations sit with the regulated entity and its counsel and compliance function, informed by that evidence — not substituted by it.

Third-party AI dependencies

Most AI capability in a regulated environment now arrives through a vendor, an API, or an embedded model in a purchased platform. Vendor risk management practices built for static software do not automatically cover a dependency that can change its behavior with a model update the vendor pushes on their own schedule. The governance question extends: what happens to your execution controls when the underlying model changes, and does your enforcement layer catch a behavior change even if the vendor's release notes don't mention one?

Change control for a system that changes itself

Traditional change control assumes a human proposes a change, it goes through review, and the system's behavior shifts at a known point in time. An AI system's behavior can shift with a prompt change, a policy update, a fine-tune, or a model version bump from a vendor — each with a different blast radius and a different owner. A financial-services AI governance program needs change control that accounts for all of these as distinct change types, each with its own evidence trail, rather than treating "the AI system" as a single artifact that changes all at once, on a predictable schedule.

Accountability under partial failure

When an AI-driven process degrades gradually rather than failing outright — slower, less accurate, occasionally wrong in ways that don't trip an alert — accountability gets murky. Who is responsible for noticing partial degradation before it becomes a reportable incident is a question that needs an explicit owner before the degradation happens, not one worked out during the post-mortem.