Opening
In a regulated environment the model is the easy part. Auditability, model risk, controls and the operating model around them are what decide whether an AI system ships. I have taken AI programs through that review for a large credit union, a global card network and, at IBM, for American Express, and I set the AI governance for a banking practice that builds these systems. This page is what that work consists of: choosing use cases that can be governed, grounding generative output so it cannot invent what matters, building auditability into the decision rather than around it, governing the teams that build, and treating adoption as the outcome the governance exists to protect.
What governance has to cover
AI governance in banking is often reduced to a policy document and a review committee. Both are necessary and neither is sufficient. Governance that works covers the whole life of a system: which use cases are selected and on what business case; what data each one may use and under whose permission; how model risk is assessed and re-assessed as the model and the data change; for generative systems, how output is grounded and validated; for automated decisions, how each outcome is recorded, explained and reviewable; how the audit trail is kept; and how the people whose work changes are brought along. A bank that has the policy but not the operating model will pass the first review and stall at the second, when the system meets real data and real customers.
Start from the business case, not the technology
Governance that begins after a model is built is remediation. The use cases that survive a risk review are the ones chosen with the review in mind: a clear owner, a defined decision the system will influence, a measurable outcome, and a known set of data with known permissions. A use case chosen because a demo impressed an executive has none of these, and it is the one that stalls when risk asks what decision it makes and who answers for it.
I ran exactly this triage at IBM India's Investment Review Board from 2011 to 2014, where every proposal needed a written business case and a quantified ROI model before it was heard. Proposals arrived across six categories and went through intake and compliance checks, a cross-functional review spanning service line, technology, finance, operations, learning and IT, sponsor sign-off, and a defence of the case in front of an executive board, with change control on any extension of scope, budget or timeline once funded. The approval cycle fell from more than thirty days to five, not by removing scrutiny but by making the standard explicit so that proposals arrived ready to meet it. The same discipline applies to AI use-case portfolios today. An institution that writes down what a governable use case looks like gets governable use cases, and gets them faster.
Grounding and the numbers
For generative systems the first control is that the model never invents a fact that matters. In the client briefing system I delivered for a global card network, every number in a brief was injected from the analytics layer rather than generated, the narrative was grounded in retrieved sources that carried their provenance, and an automated validation step checked figures against source before a brief was released. That is not a feature; it is the difference between a tool a compliance team will sign and one it will not.
The design separates what the model is allowed to do from what it is not. Retrieval brings in the relevant and recent evidence, internal transaction and relationship history alongside continuously ingested external signals, each carrying where it came from. Precomputed analytics and forecasts supply the figures. The language model writes the narrative around evidence and figures it was given, and the validation step confirms that the figures in the output match the figures in the source before anyone reads it. A relationship manager reading the brief can trace any statement back, which is what a compliance reviewer needs to see before the system is used in a regulated conversation about pricing or renewal.
Auditability by design
Every automated decision needs a recorded reason and a path to a human. The telesales compliance auditing platform I architected for American Express in 2020 scored every call with specific flag reasons, routed failures and low-confidence cases to reviewers with jump-to-timestamp playback, and fed reviewer decisions back to retrain the models, with PII redaction, encryption and a full audit trail throughout. Built before generative AI, it is still the reference design for what "auditable" means.
The system existed because a control had failed. When telesales agents moved to work from home in March 2020, the mandatory disclosures on card acquisition calls could be skipped or rushed, and manual QA sampled only a small fraction of calls, so a regulatory finding could surface long after the fact. The platform moved the audit to the full call volume and surfaced violations within days. What made it acceptable to a regulated institution was not the accuracy of the speech models alone. It was that every score carried its reasons, every uncertain case went to a person with the evidence in front of them, the reviewer's decision was captured, and the whole chain was recorded and access-controlled. Those properties are what a bank should demand of any system that decides, whether it scores calls, approves applications or writes briefs.
Governance over the people building it
In the banking practice I lead, architectural governance sits over the AI squads themselves: code quality, test automation and design standards are enforced in the engagement, not inspected afterwards. Model behavior, auditability, model risk and compliance are aligned with the business case at the start.
This matters because most governance failures are not model failures. They are an integration that logs personal data it should not, a prompt changed without review, a test suite that never covered the failure a regulator later asks about. Standards applied inside the squad, as the system is built, catch these where they are cheap. Standards applied by a committee at the end catch them where they are expensive and, often, after the build has committed to a design that cannot easily change. Reusable, pre-governed accelerators help for the same reason: when the scaffolding for identity, compliance or requirements has already been through review once, each new engagement inherits controls instead of rebuilding them.
Adoption is a governance outcome
An approved system nobody uses has failed its business case. Change management with the people whose work changes, from bankers who no longer see 98% of applications to relationship managers who receive a generated brief, is part of the governance plan, not a communications afterthought.
On the credit union account opening platform, bankers went from touching every application to seeing the 2% the system routed to them, with reasons attached. That is a change in a job, and people whose jobs change need to know what will reach them, why, and what the system has already checked. The relationship managers who receive a generated client brief need to know what it can and cannot be relied on for. Governance that stops at approval leaves these questions to chance, and it is these questions, not the model, that decide whether the business case is realised. Treating adoption as a governance outcome closes the loop: the case that justified the system is the case the operating model is built to deliver.
Practical AI governance, then, is not a gate at the end of a project. It is the set of decisions made at the start about use case, data, grounding, auditability, standards and adoption, carried through delivery. It is what I have spent the last several years doing for banks, credit unions and a global card network. The related pages on /generative-ai-in-banking and /fraud-decisioning cover the two places where it bites hardest.