Who owns your bot?

Executive Summary

Enterprise automation creates value by reducing repetitive work, improving process efficiency and releasing capacity across the organisation. But every bot or automated workflow also creates an ownership obligation. It may execute business logic, hold credentials, process regulated data or produce outputs relied upon elsewhere in the business.

When ownership, documentation, access controls and ongoing review are unclear, successful automation can become an unmanaged operational and governance risk. This article explores the rise of shadow automation and argues that enterprises need visibility over what has been automated, named accountability for each automation, proportionate governance and clear processes for reviewing changes and managing failures.

Who Owns The bot?

Ask most executive committees how their automation programme is going and the answer comes with the same repeated terminology: the number of bots deployed, the hours returned, the number of processes touched, and the amount of team capacity liberated. A finance analyst who once spent three days a month reconciling intercompany balances now spends an afternoon reviewing exceptions. A claims team that used to rekey data between two systems no longer needs to. Multiply that across a few hundred small automations and the business case looks unarguable.

These numbers aren’t wrong and they’re very helpful to the company using automation, but these numbers aren’t the whole picture. The prevailing assumption in most large organisations is that team-level automation can only be good: a quick win with no downside, no carrying cost, and no obligation once it is live. Under that assumption, the only sensible next step for the business is to build more and build faster.

But a bot is more than just a productivity gain. It executes business logic, holds credentials, touches regulated data, and produces outputs that other people rely on. Every one of those properties creates an obligation. But obligations that are never assigned to someone do not disappear, they accumulate quietly, in the same way technical debt accumulates, until something breaks and the organisation discovers it cannot answer this basic question: who owns this?

Automation With No Owner

The pattern is consistent and well-intentioned. Someone identifies a tedious manual process and reaches out for help. They have access to a low-code platform, an RPA licence, a scripting environment, or increasingly an AI agent builder made available under a self-service model. They build something that works, and it saves the team oodles of time. Out of this success, word spreads, and more variants appear in adjacent teams.

What does not happen, in most cases, is the assignment of a named owner in a register. When the builder changes teams, leaves the organisation, or takes on a role that does not include maintaining a reconciliation script, the automation continues to run unchanged. Nothing in its behaviour signals the transition, and it may operate correctly for months afterwards. But what has changed is that, now, no one is responsible for it: the automation still performs a business function, but there is no longer anyone assigned to confirm it works, to update it when the process changes, or to answer for its output.

That absence of ownership creates risk in three areas:

Undocumented business logic. The automation expected decision rules: which records to include, which thresholds trigger an exception, and how to treat an ambiguous field. Those decisions were made by a limited number of people, for reasons that were obvious at the time but often recorded nowhere. So, when the logic is questioned later, for example by an auditor, a regulator, or a customer complaint, the organisation cannot explain its own process, because the explanation left with the person who wrote the script.

Orphaned access. Bots need credentials, and in practice they are frequently given standing access under a provisioned account, or under a generic service account created outside the normal identity lifecycle. If left unchecked, the access persists, unattached to any active employee, and often exempted from the password rotation and recertification controls applied to human accounts.

Spreading blast radius. The output produced by an (unowned) unattended bot is rarely used only by the team that built it. Often the bot does work that the team produces for an internal or external customer. For example, a file lands in a shared folder, feeds a management report, populates a customer record, or initiates a payment. Even if the automation’s original scope was local, its results can flow through the organisation and beyond, wherever that data is subsequently used by participants in the data chain.

Shadow Automation

Around a decade ago, shadow IT was identified as a major business risk. Business information tools and services were acquired and run outside the knowledge of the IT function. Organisations built governance to manage it and created a general expectation that if a system mattered to the business, someone was accountable for it.

Shadow automation is the same underlying problem, but harder to see. Where an unlisted software subscription was mainly a data or cost exposure, an unlisted bot is actively doing things inside the business, like updating records, sending communications, or initiating transactions. It also tends to leave less of a paper trail, because it is usually built on platforms the organisation already licenses and actively encourages people to use, rather than acquired through an approval process that would have flagged it. And because the tools involved are now genuinely easy to use, automations can be created faster than most governance processes are built to track.

But lessons from the shadow IT era still apply today. The problem was that the organisation had no way of knowing what existed and no one could be held accountable when something went wrong. That was addressed through governance, and the same correction is now needed for automation.

Why this is a Governance Question, not a Technical One

Perhaps the natural response is to treat this as a platform problem and tighten access controls or improve the engineering. But this approach won’t address the actual risk, which is about accountability rather than technology.

A bot that simply stops running is the easier case; someone usually notices within a day or two and escalates it. The harder case is a bot that keeps running after something around it has changed, like if a source system is upgraded and a field moves. The automation has no way of knowing the world has changed, so it applies yesterday’s logic to today’s data and produces an output that looks normal but is wrong. Because the process is automated, the manual check that used to catch this kind of thing is gone. Because there is no owner, nobody is watching for the drift. And because there is no documentation, the error can be hard to trace even once it is found.

This problem also becomes more visible under formal examination. Audit and regulatory frameworks generally ask the same set of questions: who is responsible for this control, how are changes to it authorised, how is its continued effectiveness evidenced, and what happens when it fails. Businesses with unowned bots will struggle to answer any of these questions well if there is no accountable individual, no periodic review confirming it still works as intended, and no tested procedure for when it does not.