Four questions. One accountability chain.

In Part 3, we asked how we can know when the system has changed. Now we reach the final question: who owns the machine?

Who can stop the system. What can prove what it did. How can we know when it has changed. But behind all three sits the question that determines whether any of them survive: Who owns the machine?

The chain ends where accountability begins: ownership.

Ask a bank who owns its AI and the answers arrive in the plural. IT owns the infrastructure. The data science team owns the model. The business line owns the outcome. The vendor owns the thing the model was built on. Compliance owns the policy. Each answer is true, and together they describe the problem, because a responsibility that belongs to five functions belongs to none of them in the way that matters, which is that when a regulator asks who is accountable, one person has to be able to say it is me.

This series has spent three articles describing capabilities a bank needs to keep an AI system governable: the authority to stop it, the evidence to prove what it did, the monitoring to know when it has drifted. None of these is a task that completes. Each has to be maintained after the project that built it has ended, exercised on a schedule, and answered for when it is tested, and a capability that no one owns decays quietly, in exactly the way the systems it was meant to govern decay. The question underneath the whole series is not what a bank should build. It is who, in the structure of the institution, holds the thing after it is built.

For most banks the honest answer, today, is no one. And that answer is now a supervisory problem, because the regulators have stopped accepting the plural.

The gap the org chart hides

Ownership is hard for a structural reason rather than a lack of care. AI governance demands a combination that no existing function was built to hold: regulatory fluency, technical understanding of how the models behave, the authority to classify risk and enforce controls, and the standing to be heard across business lines that would rather ship. No single team on a traditional bank org chart was designed with all four. The risk function has the standing and the regulatory fluency but often not the technical depth. The data science team has the technical depth but sits inside the business line it would need to challenge. Legal has the fluency but not the operational reach. So the responsibility falls into the space between functions, and the space between functions is where things go to not get done.

The default resolution, when no function owns it cleanly, is to make it a committee. This is the failure mode disguised as a solution. A committee can advise, review, and deliberate, but a committee cannot be accountable, because accountability is singular by nature: when the outcome is bad, a committee is a set of people who can each truthfully say the decision was not theirs alone. Running AI governance as a standing committee means no one owns the cycle time, no one answers when the board asks for a portfolio view of AI risk, and no one is named when a regulator asks who decided. The committee is how a bank converts a clear accountability into a diffuse one and files it under governance.

There is a recognisable point at which this stops being survivable. Industry practitioners put it at somewhere around twenty to thirty active AI use cases, the level past which informal coordination between well-meaning teams can no longer hold the risk. Below that, a bank can improvise. Above it, the absence of a named owner stops being a latent weakness and becomes the thing an examiner finds first.

The shape of an answer

There is no single correct structure, and the right design varies with the size and complexity of the institution. But the shape that regulated finance keeps converging on is the one it already uses for every other material risk, adapted rather than reinvented: the three lines of defence.

The first line is the business, and it matters precisely who in the business. The first-line owner is the person who captures the economic upside of the system and answers for its regulatory outcomes: the head of lending whose product the credit model decides, the head of fraud whose losses the detection model moves. IT is not that owner. IT builds and runs the infrastructure and sits alongside the business as the internal service provider, but the risk belongs to the P&L leader whose product the system serves. This distinction is not pedantic. Name an IT manager as the system owner and the business line treats AI compliance as an IT chore rather than a risk it owns, which is how a consequential system ends up governed by the one function with no authority over the product it affects. The second line is an independent risk function that sets the standards, classifies the models by materiality, and challenges the first line's work. The third line is internal audit, providing assurance independent of both. This is not a novel invention for AI. It is the structure banks have used to govern credit risk and market risk for decades, and its virtue is precisely that it is familiar: it already encodes the separation between the people who take a risk and the people who independently check it.

The part that matters most for AI is the one the previous article ended on. The second line only works if it is genuinely independent of the first, and this is where a specific, common failure occurs: treating AI governance as a technology initiative and housing it under IT. IT sits on the delivery side of the first line, building the very systems that governance is supposed to independently challenge. Put governance there and the challenge is no longer independent, because the function raising the alarm reports to the function that shipped the thing. The material risks at stake are not, in the end, technology risks. They are risks to the bank's customers, its capital, and its standing with a regulator, and those cannot be governed by the team whose job is to make the technology work.

Above the three lines sits the part that does not distribute, and the distinction here is one regulators keep sharp. The board holds oversight: it approves the enterprise's AI risk appetite, sets the policy limits, and demands independent reporting on where the exposure sits. It does not own the operational risk. That ownership rests with a single senior executive, most often the Chief Risk Officer or a designated AI officer, who holds the mandate to implement the control framework, enforce the tripwires, and answer for AI outcomes in the way that has a name attached. The board sets the appetite and demands the reporting. The named executive holds the operational mandate to enforce it, so that when the question comes, there is a person and not a committee.

The vendor does not absorb the liability

There is a second place banks look to put the responsibility down, and it is more tempting than the committee, because it appears to move the risk off the books entirely. The bank did not build the model. It bought it, from a vendor with more AI expertise than the bank will ever have in-house, and surely the accountability for the model sits with the party that built it. This is the most expensive misunderstanding in enterprise AI, and the first article in this series named its smaller version: a provider meeting its own obligation does nothing to settle the deployer's.

The regulatory position is now explicit, and it runs the other way from the intuition. Supervisors expect a bank to govern the risks of a third-party relationship as if the bank were performing the activity itself. Under the revised model risk guidance, vendor-sourced models carry the same validation and monitoring obligations as models built in-house; a vendor's attestation that its model is sound does not satisfy the bank's obligation to validate it. And the reach extends past the immediate vendor. Recent requirements in mortgage lending oblige institutions to govern the AI use of their vendors, subcontractors, and downstream originators to a standard no less protective than the one they apply to themselves, and to be able to disclose, on request, what AI is in use, why, how, and with what safeguards, across that whole chain.

The consequence is precise. Buying the model transfers the building of it. It does not transfer the owning of it. The bank still has to validate a system it did not construct, monitor a model it cannot fully see inside, and answer for outcomes produced by a component a third party controls, including the case from the third article where that third party updates the model beneath the bank without notice. The vendor relationship does not shrink the ownership problem. It adds a layer to it, because now the accountable owner inside the bank is accountable for something they do not control.

What to do about that depends on who the vendor is, and here the honest version matters. Against a hyperscaler serving a public model endpoint, a regional bank has essentially no leverage to demand custom audit rights or advance notice before a model is deprecated, and a piece that pretends otherwise is no use to the risk officer reading it. When the contract terms cannot be won, the defense moves from the contract to the architecture. It means deploying models inside a private enterprise tenant rather than against a public endpoint, so the environment is under the bank's control. It means pinning a specific model checkpoint version rather than calling a floating alias that the vendor can repoint without warning, so the model does not change beneath the bank between one call and the next. And it means securing the terms that are winnable even from a large vendor, chiefly the guarantees around data: that the bank's data is not retained and not used to train the vendor's models. Where the bank does have leverage, with a smaller model vendor or a fintech that needs the bank's business, the rights to inspect, to be notified of changes, and to obtain the evidence an examiner will demand should be secured in the contract, because a right the bank did not negotiate is a right it does not have when it needs it.

What ownership actually means here

Owning an AI system, set against all of this, is not a title but a job. It is a specific and continuing set of obligations that someone has to actually hold.

It means a named person, senior enough to enforce a decision across a business line, who is accountable for the system for as long as it runs. It means that person owning the standing capabilities the series has described, not as a one-time delivery but as things kept alive: the authority to halt the system and the willingness to use it, the evidence trail maintained so a decision can still be reconstructed a year on, the monitoring watched by someone empowered to act when it fires. It means the risk classified honestly, so a consequential system is governed as one rather than tiered down to reduce the oversight burden. It means the vendor relationship governed as part of the system rather than treated as somebody else's model. And it means all of this surviving the thing that kills most of it, which is the departure of the people who set it up, because the project team disbands and the system does not, and an owner who exists only until go-live is not an owner.

This is the discipline the whole series has been circling. The first article observed that a kill switch with no one authorised to pull it is not a control. The pattern held at every layer after it. Evidence with no one maintaining it decays into logs that prove nothing. Monitoring with no one accountable for the signal becomes a dashboard measuring the wrong thing. And all three capabilities together, with no single owner holding them past the launch, add up to an AI governance programme that exists on paper and answers no one when it is tested. The common failure across all four articles was never the technology. It was the assumption that a capable system, once deployed, governs itself, and that accountability for it can stay spread across the functions that each touched one part of it.

It cannot. Regulatory responsibility for AI has settled on the institution that deploys it, and inside the institution it has to settle on a person. The banks that will come through the next few years of supervision are not the ones with the most advanced models. They are the ones that decided, before the examiner arrived, who owns the machine after everyone who built it has gone home. That decision is not a technical one, and it was never going to be. It is the oldest question in governance, arriving in a new domain: when this goes wrong, who answers for it. A bank that can name the person has built something it can defend. A bank that answers in the plural has not yet understood the question.

Sources

• On the three lines of defence as the standard AI-governance operating model, the requirement that the first-line owner be the business/P&L leader rather than IT, and the failure of housing governance under IT (delivery side of the first line): banking AI-governance guidance and EBA/ECB internal-governance principles (2026).

• On accountability requiring a single named owner rather than a committee, and the ~20–30 use-case threshold at which informal coordination fails: AI-governance operating-model analyses (2026).

• On the board holding oversight and risk appetite while a named senior executive (CRO or designated AI officer) holds operational accountability: banking AI-governance frameworks aligned to the EU AI Act and model risk guidance (2026).

• On vendor/third-party models carrying the same validation and monitoring obligations as in-house models, with vendor attestations not satisfying the bank's obligation: SR 26-2 / OCC Bulletin 2026-13 commentary (2026) and long-standing third-party risk management guidance (regulators expecting third-party risks governed "as if the bank were performing the activities itself").

• On the limited leverage against hyperscaler/public-endpoint providers and the architectural defenses that follow (private-tenant deployment, version-pinned checkpoints rather than floating aliases, and contractual no-retention/no-training-on-customer-data terms): enterprise GenAI deployment and vendor-risk practice (2026).

• On the duty to govern vendors, subcontractors, and downstream originators to a standard "no less protective" than one's own, with on-request disclosure of AI use across the chain: Fannie Mae Lender Letter LL-2026-04 and associated legal analysis (2026).

• Callbacks to Parts 1–3 of this series (the deployer/provider split, the evidence-reconstruction standard, and drift including silent vendor model updates).