Automation without expiry converts efficiency into waste.

Every month, a magazine arrives at my house, addressed to the former occupant who moved out years ago. Every month, I return it, remarking ‘addressee moved, no forwarding address.’ Every time, the next month, it comes back anyway, because the system doing the sending was built well, runs reliably, and has never been asked whether it should still run at all.

That is not a story about a magazine or its mailing list. It is a story about every automated process in your organisation that was built for a purpose, delivered that purpose, and then kept going. The failure mode here is not malfunction. The process works. It executes what it was designed to do. The problem is that nobody built a way for it to stop.

The Difference Between Reliable and Still Relevant

In operational terms, we have long celebrated automation that runs without intervention. Systems that self-execute, processes that require no manual trigger, and workflows that fire on schedule are treated as signs of maturity. Automation that frees human capacity from repetitive tasks is valuable. The problem emerges when “runs without intervention” becomes “runs without oversight.” There is a category of process in most large organisations that occupies this space: live, functioning, consuming resources, and answering to nobody in particular. The original owner moved on. The business case that justified it is no longer revisited. The review point that should have been scheduled was never built into the design. The process persists because no signal exists to stop it.

Call these what they are: orphaned processes. They are not broken or malicious, just ungoverned.

Financial institutions already carry what has been described as accumulated governance debt: opaque model lifecycles, information sprawl, and infrastructure never designed to support the pace at which automation is now being deployed. Orphaned processes are one of the most tangible expressions of that debt. They do not appear in incident reports. They show up as unexplained line items in capacity models, as controls that reference systems whose original purpose nobody can clearly say, and as processes that nobody will agree to switch off because nobody is quite sure what depends on them.

The Regulatory Expectation is Lifecycle Discipline

Regulatory guidance on model risk management now explicitly requires that institutions maintain a comprehensive model inventory that is accurate, evergreen, and subject to robust controls — with decommissioned models retained for a period the institution considers reasonable, and clear processes for modifying, replacing, or retiring models that are no longer fit for purpose. The expectation is not just that you know what you have deployed. It is that you know whether what you have deployed still deserves to be running.

The Monetary Authority of Singapore’s AIRM Guidelines reinforce this directly, requiring comprehensive change management processes including clear procedures for decommissioning automated systems, as a necessary element of ongoing risk control and compliance. DORA, now in force across EU financial entities, takes the same position at the infrastructure level: entities must map their ICT systems, identify and classify critical assets and functions, and document dependencies between assets, systems, processes, and providers, a requirement that cannot be meaningfully satisfied by organisations that have lost track of which automated processes are still running, who owns them, and why.

The US Treasury’s Financial Services AI Risk Management Framework, developed in coordination with over 100 financial institutions, requires lifecycle accountability to be embedded at every stage, from deployment through to decommissioning, with controls that exist not only on paper but in operational architecture. The message across jurisdictions is consistent: governance of automated processes does not end at deployment. It is a continuous obligation.

It Concerns Autonomous Agents Too

What applies to legacy automation applies with greater urgency to autonomous agents. A 2025 survey by Fenergo found that 93% of financial institutions plan to implement agentic systems within two years. These are not passive processes that execute a fixed script on a schedule. Agentic systems make decisions and take action at machine speed, and the governance question shifts from “Is the model accurate?” to “Who is accountable when the system acts?”

Agent sprawl (the uncontrolled deployment of autonomous systems across departments without centralised governance) is already an identified risk, mirroring the challenges organisations previously faced with IT sprawl and SaaS sprawl, but with higher stakes given the autonomy and decision-making power involved. Unless boards and regulators act, the financial services sector risks a situation where over-reliance on automation collides with public trust and regulatory accountability.

The orphaned process problem, when applied to agentic systems, is no longer a matter of wasted postage. It is a matter of autonomous decision-making that nobody has re-validated, consuming capacity nobody has measured, operating under permissions nobody has reviewed, and answerable to an owner who may no longer be in the organisation. Automation without process control amplifies variability rather than reducing it, and regulators view such inconsistency as a governance weakness, particularly in large or systemically important institutions.

The Eight-Question Solution

The solution to this is not a programme. It is a discipline. Every automated process and every autonomous agent deployed in a regulated environment should be able to answer eight questions at any point in its lifecycle. Not retrospectively, but from the moment it is designed.

• Ownership: Who is accountable if this process or agent is still running next year? This is not the team that built it, but a named individual, carrying current accountability. If that person has left the organisation or moved to a different role, the answer has already failed.

• Purpose: What tells us this process or agent is no longer needed? The original reason for building it is not sufficient. There needs to be a condition under which the business case is no longer valid, and someone needs to know what that condition is.

• Review: When is its next mandatory review point? A scheduled date, built in from the start, at which the process or agent is re-evaluated against its original purpose and current business context.

• Economics: What is the ongoing cost against the value being delivered? Every automated process consumes something: compute, storage, human oversight, third-party service capacity, or all of the above. The question is whether the value it returns justifies what it continues to consume.

• Stop Rule: What explicitly stops or sunsets this process or agent? The condition for termination should be designed in, not discovered after the fact. A process without a defined stop condition is, by design, permanent.

• Control: Can it be paused or retired without escalation? If switching off a process or an agent requires heroic effort, undocumented dependencies, or organisation-wide coordination, the governance around it was never adequate. Controllability is a governance requirement, not a technical feature.

• Capacity: What capacity does it consume today? Not at launch. Today. Automated processes and agents accumulate costs over time in maintenance, monitoring, exception handling, vendor charges, and the opportunity cost of infrastructure that could be deployed elsewhere.

• Reallocation: Where would that capacity go if the process or agent stopped? This question makes the economics concrete. It converts the abstract question of “is this still worth doing?” into a real comparison against what else the organisation could be doing with the same resources.

McKinsey’s framing is precise: governance of autonomous systems must define scope, inventory, and ownership, and make all three auditable. These eight questions are the operational expression of that requirement. They are not a retrospective audit exercise. They are what intentional design looks like when the people building automated capability take seriously the obligation to govern what they create.

Orphaned automation is the operational equivalent of decisions that were reasonable at one point but have since become a liability. It was built for good reasons and it worked, but nobody built a way for it to stop. The question for leaders is whether the proliferation of automated capability is happening by design or by drift. Those are very different organisational postures, and only one of them is defensible in front of a regulator.

As financial institutions scale automated operations and deploy increasingly autonomous systems across their processes, the measure of governance maturity will not be how efficiently those systems were built or how reliably they run. It will be whether the organisation can demonstrate, at any point, that it knows what it has running, why it is still running, who is accountable for it, and what would happen controllably and deliberately if it were to stop.

Aiversight works with risk and compliance leaders in regulated financial services to identify where accountability, controls, and governance fracture as automation scales. If your organisation is building out automated or agentic capability and the governance architecture has not kept pace, that gap will not close itself.