TL;DR
- A data governance model built for people does not survive being run by models. Centralized, decentralized, and federated structures all assign decision rights around periodic human requests. An AI-driven institution asks for data continuously, and that changes which structure holds up.
- Federated governance tends to win at AI-driven institutions, but only with the tooling to back it. Without shared lineage and access controls that apply to machine identities, a federated model behaves like a decentralized one with an extra meeting.
- The access-rights problem is new. Most governance structures were built to grant a person a login once, never to distinguish a model’s access from a person’s, or to track a chain where one model’s output becomes another model’s training input.
- SR 26-2 leaves AI models out of scope, and that gap puts more weight on data governance. The Fed’s replacement for SR 11-7 excludes generative and agentic AI models. Examiners still ask what evidence a bank can produce on them, and data governance is one of the few places that evidence exists today.
- A short self-check separates an AI-driven institution from a bank running a few AI pilots. How often models request data and whether a person sits in that loop matters more than headcount or asset size.
- This is the sequel to iTuring’s piece on the general decision. Read Data Governance Models: Which One Fits a Bank first for the general decision, and use this piece when AI itself is the reason for the redesign.
A bank redesigning its data governance around AI is answering a narrower question than the general one. It already knows which structure, centralized, decentralized, or federated, fits its size and culture in the abstract. What it needs to know now is whether that structure holds up when dozens of models request data around the clock, a demand pattern no handful of people ever created. For most AI-driven institutions, the answer is federated, with the right tooling underneath it, and the reasoning follows below.
What changes when AI stops being another data consumer and becomes the primary one
A governance model built around human requests assumes a request happens once. A person joins a team, gets access to the data that role needs, and keeps it until the role changes. Request volume is bounded by headcount, and review cadence can keep pace with it.
An AI-driven institution breaks that assumption on three fronts: a model that retrains weekly generates a new access event every time it retrains, a feature store that refreshes daily pulls from dozens of source systems on a schedule no human review queue was sized for, and an agentic workflow can trigger a data pull, an action, and a follow-up pull with no person approving any step.
The three governance structures still apply. Each now has to answer a question it was never designed for: what happens when the requester is a model running every hour, and the request never really stops.
Centralized governance under continuous AI demand: where it holds and where it breaks
Centralized governance puts one team in charge of every access decision. It holds up well at the exact moment an institution needs it most, its first few models: a team reviewing ten or fifteen requests gives a fast, consistent answer, and gives an examiner a single place to point when asked who approved a decision.
The structure breaks once the model count outgrows what that team can review at machine speed. A bank running forty models, each retraining on its own schedule, sends forty times the request volume through a queue sized for far fewer. What follows is worse than a bottleneck: either deployment slows to match the review team’s capacity regardless of model readiness, or the team starts approving requests it has stopped meaningfully reviewing, producing a paper trail that looks like governance without the substance behind it.
Decentralized governance under continuous AI demand: same problem, faster
Decentralized governance hands data ownership to each business line. Under continuous AI demand, this looks appealing at first: each team’s models get exactly the access pattern they need, with no central queue slowing anything down.
The cost shows up in consistency, and AI compounds it faster than human-paced use did. Two lines defining the same customer field differently used to surface as a mismatch in a quarterly report. Under continuous AI demand, it surfaces the moment two models trained on differently governed data get compared or combined into a downstream decision, and an examiner gets a different answer on which model touched a given record depending on which line is asked, a gap that only widens with each retrain cycle.
Federated governance under continuous AI demand: why it tends to win by default, and what it still requires
Federated governance splits the decision: a central group sets classification, security, and access rules once, and business lines apply those rules to their own data and models without routing every request through a central queue.
This is the structure that scales with continuous AI demand, because a model’s access request can be evaluated automatically against a pre-set rule, with no person needing to read it first. That only works if the tooling underneath the policy can enforce it: a data catalog that classifies information once, access controls that treat a service account like a human login, and lineage that records automatically which model pulled which data, when, and under which approved use. Without that layer, a federated policy becomes a decentralized structure with an extra document nobody enforces.
The access-rights problem no human-oriented governance model solves by default
Every structure above was built to answer a human question: who gets to see this data, and who approved it. None answers a newer question by default: does a model’s access look different from a person’s, and should it.
The difference runs deep. A person with read access to a customer table looks at records one at a time. A model with the same nominal access pulls the whole table on a schedule, retrains on it, and produces an output a second model may then treat as its own training input. That chain has no clean human equivalent, and a governance model granting “read access” without naming who or what is reading, and for what purpose, cannot answer an examiner’s question about it.
This gap matters more given what current model risk guidance leaves out. SR 26-2, the Fed’s April 2026 replacement for SR 11-7, excludes generative and agentic AI models, calling them “novel and rapidly evolving” and deferring them to future guidance. Examiners still ask what monitoring and access evidence a bank can produce on those models regardless, per reporting on Fed Vice Chair Michelle Bowman’s post-rescission remarks. Data governance, specifically the layer above, is where that evidence has to come from.
A short checklist: is your institution AI-driven enough to need this redesign
Not every bank running a few AI pilots needs this stress test. The general framework in Data Governance Models: Which One Fits a Bank covers most institutions. This checklist separates the two cases.
- Models retrain on a schedule shorter than a quarter.
- More than a handful of models pull from the same core customer data at once.
- At least one workflow lets a model call another model, or trigger an action, with no person approving each step.
- The same dataset feeds both a human-facing report and a live model in production.
- Your last exam or internal audit could not get a clean answer on which model touched a given record, and when.
Three or more of these signals mean the general framework alone is not enough. The governance model needs the stress test above, on top of the organizational-fit question the earlier piece already answers. Structure is only one part of the redesign: a follow-up piece covers which specific data inputs go unaudited once AI is added to the pipeline.
How iTuring keeps lineage and access control intact regardless of which model you land on
Whichever structure an AI-driven institution lands on, the layer underneath it has one job: name which model, or person, touched a given piece of data, when, and under what approved purpose. iTuring’s Data Accelerator builds that lineage automatically across more than 25,000 pre-built financial signals, treating a model’s service account as its own named, tracked identity, separate from a generic system-access category.
A centralized team can use that lineage to answer an examiner’s question in minutes. A federated structure can use it to let business lines move fast without losing the audit trail a central team would otherwise chase down by hand. The same discipline runs underneath the 116% improvement in collections recovery iTuring delivered for a leading NBFC in India, where every model stayed traceable from its first data pull onward.
Choosing a data governance model for an AI-driven institution is not the general decision, and mistaking the two is how the gaps above go unnoticed until an examiner finds them first. Book a 15-minute discovery call to see how iTuring’s Data Accelerator keeps lineage and access control intact no matter which structure your institution runs.
Sources
- “Supervisory Letter SR 26-2 on Revised Guidance on Model Risk Management,” Board of Governors of the Federal Reserve System, 17 April 2026. https://www.federalreserve.gov/supervisionreg/srletters/SR2602.htm
- iTuring.ai case study, “Improve Collections and Optimize Efforts.” https://ituring.ai/case-study/improve-collections-and-optimize-efforts/
- iTuring.ai, “Data Governance Models: Which One Fits a Bank.” https://ituring.ai/data-governance-model/
