TL;DR
- A bank gets AI governance capability three ways: build it in-house, buy a dedicated platform, or extend the governance features already sitting inside the cloud ML or MLOps stack the bank already runs.
- Building takes real staff time and produces a system the bank owns outright. Most institutions underestimate how long it takes to reach examiner-ready coverage.
- Extending what you already run looks like the free option, and often is, until an examiner asks a specific account-level question the native tooling was never built to answer.
- SR 26-2 requires a bank to name an individual accountable for each model. Building alone and extending native tooling both leave that evidence as a manual task. A dedicated platform produces it by default.
- Buying a platform changes what the work is. The bank stops building the machinery that produces governance evidence and starts producing the evidence itself.
- Honest caveat: no path removes the underlying work of governance. Every path still requires the bank to decide who owns each model, how approvals happen, and what gets shown when an examiner asks. The choice is who builds the machinery that produces that answer.
A bank evaluating AI governance platforms is usually further along than the search term suggests. The real question underneath “which platform” is “do we even need one,” and that question splits three ways. Build the capability with an internal team. Buy a platform built for it. Or extend the governance features that already ship inside the cloud ML platform or MLOps stack the bank runs today. Each path gets a bank to something that looks like AI governance. Only one of them reliably produces what an examiner asks for.
Three ways a bank ends up with AI governance
Build means assigning an internal team, usually data science or platform engineering, to design and maintain the lineage tracking, approval workflow, and audit export a governance program needs. The bank owns everything it builds. It also owns every gap in what it built.
Buy means adopting a platform designed specifically to produce governance evidence for regulated AI models: an accountable owner per model, a maker-checker approval record, testing and monitoring history, and an export an examiner or auditor can read without a translation step.
Extend means using the governance and monitoring features already built into the cloud ML platform or MLOps stack the bank’s data science team already runs day to day. These features exist. Most cloud ML platforms ship some version of model monitoring, drift detection, and access logging. The question this piece answers is whether that existing tooling closes the same gap a dedicated platform closes, and for most regulated use cases it does not.
None of these three paths substitutes for supervisory guidance. SR 26-2, the Federal Reserve’s current model risk guidance, states plainly that it does not set enforceable standards, but examiners still use it to structure what they ask a bank to show, a distinction covered in more depth in iTuring’s piece on model governance. Whichever path a bank picks has to produce evidence against that expectation. The paths differ in how much of that evidence-producing work falls on the bank’s own team.
Building it in-house: what a regulated institution has to staff
A build path starts with a real decision: who inside the bank owns this. Usually that is data science or platform engineering, occasionally a dedicated model risk function if one already exists. From there, the team has to design and maintain several things at once: a lineage record that survives a model moving from development to production, an approval workflow with a real maker-checker split, a testing and monitoring history that holds up months later, and an export format an examiner can read.
Most banks that go this route underestimate two things. The first is how long it takes to reach coverage across every model in production, since most banks are running more than one. The second is that the work does not stop once the system ships. A governance system has to keep working as new models are added, existing models are retrained, and the bank’s own model inventory grows. The team that built it now maintains it indefinitely.
Build is the right answer when a bank has a genuinely unusual model portfolio, an internal platform team with capacity to spare, and enough runway before the next exam to accept a slower path to full coverage.
Extending what you already run: the option that looks free until an examiner asks a specific question
This is the option most engineering teams reach for first, because it looks like no new decision at all. The bank’s data science team is already running models inside a cloud ML platform or an MLOps stack, and that platform already has some version of monitoring, drift alerts, and access logs built in. Extending those features into a governance program costs nothing to license and nothing new to learn.
The gap shows up at a specific moment: when an examiner or auditor asks for evidence tied to one account-level decision. Native cloud ML monitoring was built to tell an engineering team whether a model is drifting or degrading. It was not built to answer “who approved this model, on what evidence, and why did it produce this specific output for this specific customer.” That is a different question, and answering it usually means someone on the bank’s team manually assembling logs from several systems into a document a regulator can read. The dashboard existing is not the same thing as the evidence existing in the form an examiner needs it.
Extend is the right answer when a bank’s model count is small, growth is slow, and the team has the bandwidth to close that evidence gap by hand each time it comes up. It stops being the right answer once model count or examiner scrutiny grows faster than the manual work can keep pace with.
Buying a dedicated platform: what changes and what does not
Buying a platform does not remove governance work from the bank. It changes what that work is. The bank’s team spends less time designing lineage tracking, an approval workflow, and an audit export from scratch, or manually assembling evidence out of tools that were not built to produce it. It spends that time using a system that already produces the evidence as a byproduct of normal operation.
This piece is not where to evaluate a specific platform. iTuring’s piece on what separates a real AI governance platform from a checkbox tool covers the evaluation criteria, demo questions, and red flags to use once a bank has decided buying is the right path. The decision this piece answers comes first: whether buying is the right path at all, against building or extending.
A short decision guide: which path fits which bank
The right starting point depends on model count, growth trajectory, and how much runway exists before the next exam cycle asks for evidence the bank does not yet have.
- A handful of models, slow growth, no near-term exam pressure. Extend what the team already runs, and accept the manual work of assembling evidence when it is asked for.
- A growing model count, or an exam cycle approaching that will ask account-level questions. Buy a dedicated platform. The evidence-producing work becomes routine. It stops being a fire drill each time it is needed.
- A large internal platform team, an unusual model portfolio, and real runway before the next exam. Build, with the lineage, approval, and audit-export requirements designed in from the start, before the system is already carrying production models.
- Uncertain which of the above describes the bank today. Start with what the current model inventory looks like, then match it against the three descriptions above. Defaulting to whichever path requires the least new procurement skips the comparison this piece is making.
What extending native tooling quietly leaves undone
The honest version of this comparison is that extending what a bank already runs is not a bad decision. For a bank early in its AI adoption, with a handful of models and no exam pressure yet, it is often the right one. The risk is not in choosing it. The risk is in not recognizing when it has stopped being sufficient.
The signal to watch for is not model count on its own. It is whether the bank can currently answer, for any single model, who approved it, what it was tested against, and why it produced a specific output for a specific account, without someone spending a day pulling that answer together from several systems. If that answer takes a day to assemble today, it will take longer once the model count doubles.
How iTuring fits regardless of the path a bank starts on
A bank does not have to choose iTuring to start extending or building. The platform is built to be the evidence layer underneath whichever path a bank is on. Model Gov keeps a single accountable owner and a maker-checker approval record for every model, the specific SR 26-2 requirement every path above has to satisfy one way or another. Model Risk Management holds the testing and monitoring history an examiner asks for at the account level, the detail a model-level summary alone does not carry. iTuring’s own deployment history includes a case where a bank went from decision to live production in two weeks, evidence of how fast the evidence-producing work can start once a bank decides buying is the right path.
Most banks reading this already have an answer to at least one of these questions: how many models are in production today, and how long it currently takes to answer who approved one of them. Book a 15-minute discovery call to see what buying a dedicated platform would change about that answer.
Sources
- SR 26-2, Board of Governors of the Federal Reserve System, 17 April 2026. https://www.federalreserve.gov/supervisionreg/srletters/SR2602.htm
- “Build vs. buy AI governance: What the cost comparison looks like,” Monitaur, 2026. https://www.monitaur.ai/blog-posts/build-vs-buy-ai-governance-what-the-real-cost-comparison-looks-like
- “Build vs Buy Your AI Governance Layer,” Axiom Studio, 2026. https://axiomstudio.ai/blog/build-vs-buy-ai-governance-layer-engineering-leaders
- “Improve Collections and Optimize Efforts,” iTuring.ai case study. https://ituring.ai/case-study/improve-collections-and-optimize-efforts/
