Data Governance for AI Agents: Five Controls Lifted From Bank Regulators

On 17 April 2026, US bank regulators replaced the model risk guidance American banks had followed since 2011, and wrote generative and agentic AI out of its scope. The most heavily supervised AI adopters now have no written agent rules either. Data governance for AI agents still has a template, though: the five data controls banks were already made to build.

The short answer

Data governance for AI agents means knowing which agents exist, what data each one reads, whether that data is accurate and from an authoritative source, who owns it, and whether someone independent checks the results. Bank regulators wrote all five controls for models more than a decade ago. They translate to agents with little change.

Why bank data governance is the template worth copying

Banks are not the obvious place to look for agent advice. They move slowly, they buy from large vendors, and their compliance budgets dwarf yours. They are also the only sector told, in writing and for over a decade, how to govern the data behind automated decisions.

That matters because agents fail at the data layer more often than anyone budgets for. The 2024 Bank of England and FCA survey found that four of the five risks firms ranked highest were data risks: privacy and protection, quality, security, and bias. The sample was 118 firms, 50 of them UK banks, so read it as a picture of financial services rather than of every industry.

The model gets the attention. The data is the part regulators kept writing about. Every control below comes from one of four sources: the US model risk guidance, the Basel risk data principles known as BCBS 239, the Prudential Regulation Authority's model risk statement, and the FCA's accountability regime.

The 2026 rewrite that wrote agents out of model risk guidance

For 15 years, SR 11-7 was the reference text for model risk management in US banking. The Federal Reserve issued it in April 2011 and the OCC adopted it as Bulletin 2011-12. It defined a model, expected an inventory and set the standard of "effective challenge".

On 17 April 2026 the Federal Reserve, the OCC and the FDIC replaced it. The Fed's SR 26-2 "supersedes and replaces SR letter 11-7". The OCC's Bulletin 2026-13 rescinded its own 2011 bulletin and the Model Risk Management booklet of the Comptroller's Handbook.

One passage in the OCC bulletin matters more to you than the rest. "Generative AI and agentic AI models are novel and rapidly evolving. As such, they are not within the scope of this guidance." The agencies said they plan a request for information on model risk that considers banks' use of AI, including agentic AI.

Why the carve-out is not permission

It is tempting to read the exclusion as a sign that agents are too new to govern. I read it the other way. Regulators excluded agents because they could not yet write prescriptive rules for them, not because the underlying data risks are new.

Sullivan & Cromwell's review of the guidance notes that it points banks to their broader risk management and governance practices for tools it does not cover. In plain terms, the bank still owns the risk and simply has no checklist. That is exactly your position.

The definition of a model also narrowed. It now covers "a complex quantitative method, system, or approach" and excludes "deterministic rule-based processes and software" with no statistical theory underneath. Much of an agent stack, the tool calls, routing rules and retrieval filters, would sit outside that definition even if agents were in scope.

Control 1: an agent inventory that records purpose and exposure

Every model risk regime starts with a list. SR 11-7 expected banks to identify the models in use across the organisation, and the FDIC's 2017 adoption notice repeated that expectation. The PRA's SS1/23 makes it Principle 1, "Model identification and model risk classification".

The 2026 US guidance adds a tiering rule. Purpose is what a model is for, and exposure is how much it can affect. For low materiality models, Sullivan & Cromwell report that oversight may consist of identifying those models and monitoring their performance.

The UK went further on scope. The PRA's policy statement says its definition is meant to bring "recommendation systems in client services and other AI/ML that deliver qualitative output" into scope. Its principles cover models "whether developed in-house or externally (including vendor models)". That breadth is the part worth copying, because most of your agents produce text, not numbers.

The non-bank translation for the inventory

Keep one register with a row per agent. Record its stated purpose, every data source it reads, every system it can write to, and its owner. Tier it by exposure: read only, internal writes, customer facing, or money moving.

The failure this prevents is the shadow agent. A team builds a summariser for internal use, another team wires it into a customer workflow, and nobody re-tiers it. The register is where that reuse becomes visible, because the purpose field no longer matches the systems field.

Our agent governance maturity model treats this register as the first level for that reason. Without it, the other four controls have nothing to attach to.

Control 2: data quality for AI agents, checked at the input

BCBS 239 was written after the 2008 crisis exposed a basic failure. The Basel Committee found that many banks "were unable to aggregate risk exposures and identify concentrations fully, quickly and accurately". Its principles followed in January 2013.

Principle 3, accuracy and integrity, asks banks to produce accurate and reliable risk data, aggregated on "a largely automated basis so as to minimise the probability of errors". The point is not automation for speed. Manual steps are where errors enter and where they hide.

The Committee's 2023 progress report tied this directly to new technology. Banks, it said, should "ensure sound data quality as the basis for digitalisation projects". Agents are the most aggressive digitalisation project most companies will run this decade.

The non-bank translation for input checks

Identify the fields that trigger agent actions. For a support agent, that might be plan tier and refund history. For a finance agent, it is invoice amount, vendor ID and payment status. Put automated checks on those fields, and make a failed check block the action rather than log a warning.

This is the control most teams skip, because the data looked fine when the pilot ran. An analyst catches a wrong number in a dashboard. An agent acts on it, possibly hundreds of times before anyone looks. The runtime version of this check, with lineage and freshness alongside it, is set out in the three checks to run before an agent acts.

I would not start with a data quality platform. Start with five fields, written assertions and a hard stop. Expand only when the list of fields that drive actions grows.

Control 3: one authoritative source for every data element

Principle 2 of BCBS 239 covers data architecture and IT infrastructure. Its practical demand is that a bank can produce one consistent figure for a risk across the group, rather than reconciling competing versions by hand.

This is where banks have struggled most visibly. The 2023 progress report covered 31 global systemically important banks, "seven years after the expected date of compliance". It concluded that "additional work is required at all banks to attain or sustain full compliance". Deloitte's reading of the report counts 2 of the 31 as fully compliant, up from none in the 2019 assessment.

Read that number carefully. These are among the best resourced institutions in the world, under direct supervisory pressure, and almost none finished. Fragmented architecture is the hardest data problem to fix. Agents make it worse, because each one can quietly bind to a different copy.

The non-bank translation for authoritative sources

Declare a system of record for each entity your agents touch: customer, contract, price, inventory, employee. Then bind agent tools to that system and nothing else. If the CRM is the source for contract value, the agent reads the CRM, not a warehouse extract refreshed nightly.

The failure this prevents is two agents giving two answers. A sales agent quotes from the billing system, a support agent quotes from a stale export, and the customer receives both. Neither agent is wrong about its own data. The architecture is.

Control 4: a named data owner who can switch the agent off

The UK approach to AI accountability runs through people, not new rules. The FCA states it does "not plan to introduce extra regulations for AI" and relies on existing frameworks. Its rules, it says, "emphasise accountability for senior managers". Under the Senior Managers and Certification Regime, each business function sits with a named individual, so an AI system used there sits with them too.

The PRA applies the same logic to models. SS1/23 expects firms to allocate "responsibility for the overall MRM framework to the most appropriate Senior Management Function (SMF) holder(s)". Respondents to its consultation agreed the chief risk function was likely the right holder.

The Basel Committee says the same about data. Its 2023 report asks banks to "foster a culture of ownership and accountability for data quality across the organisation".

Most UK firms already report having an owner. The joint survey found 84% had an accountable person for their AI framework. It also found 46% had only partial understanding of the AI technologies they use. Naming an owner and equipping that owner to act are different achievements.

The non-bank translation for ownership

Assign one person per agent, by name, with two powers: the authority to pause it and the budget to fix its data. Then assign a separate owner for each data domain the agent reads, usually the team that runs the system of record.

I would not give this to a committee or an AI centre of excellence. Committees approve things, and they rarely stop things at 2am. The test is simple. If the agent misbehaves tonight, whose phone rings, and can that person turn it off without a meeting?

Control 5: effective challenge and outcome checks, vendors included

SR 11-7 defined effective challenge as "critical analysis by objective, informed parties who can identify model limitations and assumptions and produce appropriate changes". The FDIC's adoption notice adds that it "refers to a combination of incentives, competence, and influence". The reviewer must be independent enough to say no, skilled enough to be right, and senior enough to be heeded.

The 2026 rewrite dropped much of the prescriptive detail but kept this core. The OCC describes the retained work as "validating conceptual soundness and outcomes analyses". Outcomes analysis compares what a model said or did against what actually happened.

Vendor models get the same treatment. As summarised by Sullivan & Cromwell, the guidance describes sound practice for vendor models as "developing an understanding of the model" plus ongoing monitoring and outcome analysis. The PRA expects vendor documentation to be detailed enough "to validate their use".

The non-bank translation for challenge

Have someone who did not build the agent review its design before it gets write access. Then sample its outputs weekly against ground truth: the refund that should have been issued, the ticket that should have been escalated, the record that should have changed. Track the error rate by tier.

For vendor agents, ask for documentation sufficient to test the agent, not a trust centre page. The UK survey found a third of AI use cases were third-party implementations, up from 17% in 2022. That share is where partial understanding lives. If a vendor cannot say what data its agent reads and how it fails, treat the agent as untested.

Monitoring does not end at launch. What to watch once an agent is live is covered in the piece on agent drift in production.

Where this data governance argument is weakest

Two objections deserve a straight answer, and a third point limits who should act on any of this.

These controls were built for scorecards, not agents

Bank model risk rules assume a defined input, a calculation and an output you can compare with reality. Agents chain many calls, choose their own tools and produce text. Outcomes analysis for a credit scorecard is a statistics exercise. For an agent that drafts contract amendments, it is a judgement call that is expensive to repeat at volume. Regulators excluded agentic AI partly for this reason, and I cannot claim the translation is clean.

Banks themselves have not made them work

If 29 of the 31 largest banks had not fully met the data principles after a decade, copying them may simply copy the paperwork. That risk is real. A register nobody updates and an owner who cannot pause anything are worse than nothing, because they create the appearance of control.

The defence is to adopt the controls narrowly, on agents that write to systems, and to measure whether they catch anything. If a check has never blocked an action in three months, either your data is clean or the check is wrong. Find out which.

Proportionality cuts against all of this too. The US guidance is aimed mainly at banks above $30 billion in assets. A 20-person company running two internal agents does not need a validation function. It needs the register and the owner, and probably nothing else for now. Mapping agents onto formal regimes is a separate exercise, covered in the HIPAA and DORA control mapping, and most readers here do not need it yet.

Frequently asked questions

How to put the first two controls in place this month

Build the register first. One row per agent, with purpose, data read, systems written, owner and exposure tier. If you find an agent nobody remembers approving, that is the finding, and it justifies the hour on its own.

Then take the agent with the highest exposure tier and write down the five fields that trigger its actions. Put an automated check on each, and make a failed check stop the action. Leave the other three controls until those two are running. For how financial firms pace this against other regulated sectors, read the comparison of AI adoption in banking and healthcare.

Related reading