RPA governance became an urgent topic about eighteen months after RPA became a popular one, which is roughly how long it takes a successful pilot to turn into an unmanaged estate. The pattern repeated across enough organisations to be predictable: a first wave of automations delivered exactly what was promised, a second wave was approved enthusiastically, and somewhere between twenty and fifty robots the programme stopped producing new value and started consuming the team that built it. Industry surveys through the late 2010s consistently found that only a small minority of organisations scaled beyond a few dozen robots. The condition acquired a name — pilot purgatory — and it was almost never caused by the technology. It was caused by the absence of any answer to the question of who owns a robot after the person who built it moves on.
What actually breaks between ten robots and a hundred
At small scale, an automation estate is managed by memory. One or two developers know every robot, what it touches, and when it runs. Failures are noticed because someone is watching. Changes are coordinated because the same person makes all of them. That model degrades in specific, identifiable ways. Nobody knows what exists. There is no inventory tying each robot to a process owner, a business case, the systems it touches and the person responsible for it. When a system change is planned, no one can answer which automations will break — so either the change is delayed or the robots fail silently after it ships. Failures become invisible. An unattended robot that fails at 3am does not raise its hand. Without monitoring and alerting, the discovery mechanism is a business user noticing that a report is wrong, which happens days later and destroys confidence faster than any single outage. Change control runs in one direction. IT changes applications on their own cadence. The automation team learns about it afterwards. At ten robots this is annoying; at a hundred, a single portal redesign becomes a multi-week outage across several processes simultaneously. Credentials rot. Robots built quickly run under whatever login was available — frequently a named employee's. Password rotation breaks them. Staff departures break them. And an audit eventually asks why a production posting in the ledger is attributable to a person who was on leave. The maintenance load overtakes the build capacity. This is the arithmetic that ends programmes. If each robot needs a few days of maintenance per year and a small team builds thirty robots annually, maintenance consumes the entire team within a few years. Without a deliberate decision to fund maintenance separately or to retire automations, the build pipeline stops. Nobody retires anything. Robots automating processes that no longer matter keep running, keep consuming licences, and keep breaking. Retirement requires someone with the authority to say a business case has expired, and that role is almost never assigned.
The centre of excellence that helps, and the one that does not
The standard remedy was a centre of excellence, and it worked in roughly half the organisations that tried it. The difference between the two outcomes came down to whether the centre was a service or a gate. The version that fails becomes the sole builder of automations. Every request enters a queue, business units wait months, and the speed advantage that made the technology attractive disappears. Frustrated teams then buy their own tooling and build robots outside the process, which is how organisations end up with shadow automation on top of shadow IT. The version that works owns standards, platform, credentials, monitoring and the inventory — and lets business units build within those standards. It provides templates, a code review, a deployment pipeline and a place where every robot is registered. It says no to automations without a named owner, and it retires robots whose owner has disappeared. The distinction matters because governance in this domain is not about restricting who can automate. It is about ensuring that nothing enters production without an owner, a monitor and a documented dependency list.
Practical Guidance for Automation Governance Design
- Maintain a single registry of every automation in production. Process owner, technical owner, systems touched, schedule, business case, and last review date. Nothing else in governance works without this.
- Refuse to deploy any robot without a named business owner who accepts the outcome. Technical ownership is not enough. Someone must be accountable for the process being correct, not just for the code running.
- Give every robot its own service account with least privilege. Never run production automation under a personal login. This is the single most common audit finding in mature estates and the easiest to prevent at the start.
- Wire automation into IT change management in both directions. Application changes must check the registry for dependent robots; robot changes must follow the same release process as any other production code.
- Monitor and alert on every unattended run. Success, failure, duration and exception counts, routed to a team that acts on them. A robot nobody watches is a process nobody is running.
- Fund maintenance as a standing capacity, not as an overflow. Reserve a defined share of the team explicitly for keeping existing automations alive, and model it in every new business case.
- Review the portfolio on a schedule and retire aggressively. Any robot whose owner has left, whose process has changed, or whose underlying system now offers an API is a candidate for decommissioning.
- Version-control automation code and keep it out of the vendor platform only. If the logic exists solely inside a proprietary orchestrator, your ability to audit, migrate or recover it is entirely dependent on that vendor.
The Regional Dimension
In the Gulf, two local factors turn the governance gap from a management problem into an operational risk. The first is workforce mobility. Residency tied to employment produces turnover rates that are high by global standards, and automation knowledge is exactly the kind of knowledge that lives in one person's head. A robot built by a contractor or a departing analyst, with no documentation and credentials stored in their profile, becomes an orphan the week they leave. Regional estates accumulate orphaned automations faster than comparable estates elsewhere, and the registry discipline that seems bureaucratic at ten robots is the only thing that prevents it. The second is what regional robots are typically automating. A large share of Gulf automation targets external government and bank portals — wage protection payroll submission, labour and immigration filings, social insurance contributions, nationalisation ratio reporting, tax and invoicing submissions. These interfaces are mandatory, deadline-bound, and entirely outside the organisation's change control. A portal redesign announced with little notice will break automations, and the consequence is not a delayed report but a missed statutory filing. Governance here needs an explicit manual fallback for every compliance-critical robot, rehearsed rather than assumed. Credentials deserve separate attention regionally. Many portal logins are held by PRO or government-relations intermediaries acting on the company's behalf. Automating against an intermediary's credentials compounds two control weaknesses at once, and it should be resolved as an access question before it is treated as an automation question. Multi-entity structures finish the picture. A group running mainland, free-zone and Saudi entities typically has near-identical robots replicated per entity with small variations, maintained by different people. Consolidating those into parameterised automations with one owner reduces the maintenance surface substantially — and is much easier to do before the estate reaches fifty robots than after.
The objection worth taking seriously
The fair criticism of all this is that governance destroys the property that made the technology valuable. RPA succeeded because a business team could automate a process in weeks without entering the IT queue. Adding registration, review, change control and standards recreates the queue, and at that point the organisation has paid for a tool whose main advantage it has deliberately removed. There is evidence for this. Plenty of programmes stalled not from chaos but from process weight, with approval cycles longer than the development work. The resolution is to scale governance to consequence rather than applying one standard to everything. An attended robot that helps one analyst format a spreadsheet needs a registry entry and nothing else. An unattended robot that posts to the general ledger or submits a statutory filing needs full change control, monitoring, segregation of duties and a tested fallback. Most organisations that got this right operated a two or three tier model, and most that failed applied enterprise-grade controls uniformly and watched the pipeline stop. The non-negotiable minimum, at every tier, remains small: it exists in a registry, it has a named owner, and someone is alerted when it fails.
| Automation example | Control emphasis |
|---|---|
| Attended formatting aid | Registry entry and proportionate ownership |
| Unattended ledger posting or statutory filing | Change control, monitoring, segregation of duties and tested fallback |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
Common Questions
How many robots can a team maintain?
It depends on the volatility of the underlying systems, but a useful planning assumption is that each production robot consumes a few days of maintenance per year, more where it touches external portals. Model the maintenance curve before committing to a build target; programmes that plan build capacity without maintenance capacity reach their ceiling in about two years.
Should business units be allowed to build their own automations?
Yes, within a defined standard — platform, templates, credential handling, registry entry and code review. Centralising all construction creates a bottleneck that pushes teams toward unsanctioned tools. Centralising standards while federating construction is the pattern that scales.
What is the earliest warning sign that an estate is drifting?
Someone asks which robots will be affected by a planned system change and nobody can answer. That single question is a reliable diagnostic. The second warning sign is a maintenance backlog growing month over month while new build requests keep being approved.
Does moving to AI agents solve the governance problem?
No — it raises the stakes on the same problem. Agents are more resilient to interface changes, which removes one class of failure, but they act with greater latitude and less predictability. The registry, named ownership, least-privilege credentials, monitoring and tested fallbacks all become more important, not less, because the question shifts from "did it break?" to "what exactly did it decide to do?"
Automation Governance Design — an automation estate fails at the point where nobody can answer who owns a robot, what it touches, and how you would know if it stopped.