AI platform teams automate more than almost anyone else: overnight retraining runs get relaunched from cron, GPU nodes get drained before patching, caches get flushed, stuck queues get restarted, and every one of those actions tends to begin life as somebody’s quick script. The Ops Atlas gives this discipline a name — AutomationOps — for governing operational automation as a production system: choosing what deserves automating, making repeats safe, capping the damage a bad run can cause, and keeping an owner attached until the day the script retires. The label is editorial rather than industry-standard; UiPath has shipped a product with a similar name since April 2021, and Robocorp published a methodology under it before archiving the work in 2023. The craft described here is broader than any vendor’s feature set, and this AutomationOps reference page is the cleanest map of the territory. Below are eight controls that matter most when the systems being automated are the ones learning from data.

1. Put the AutomationOps Inventory on the Platform Ledger

No team sets out to build a sprawl of undocumented scripts; it accumulates the way repositories accumulate branches. Someone writes a cache-flusher during an incident, a colleague copies it for a second cluster, and within two years the platform runs on a few dozen automations that exist only in tribal memory. The first control is simply counting. How many operational automations exist? How many carry a registered owner, a stated purpose and a review date? That gap — the unregistered share — behaves exactly like data-lineage debt. Machine-learning teams would refuse to ship a model without provenance, yet the script that restarts the inference fleet at 3 a.m. usually has none. Two questions expose the gap fast: who gets paged when this script misfires, and what breaks if it silently stops running tomorrow? If either answer is a shrug, the automation is unmanaged. Making the inventory visible is unglamorous work, and every later control stands on it.

2. Grade Every Action by Blast Radius

Restarting one pod and wiping a fleet’s disks are both “automation”, but they belong to different universes of risk. A tiering scheme makes the difference explicit:

• Tier 0 — reads only: inventories, health checks, reports. Nothing can break.
• Tier 1 — reversible and aimed at one target, like restarting a single service.
• Tier 2 — reversible but touching many targets at once, such as batch patching; it owes you dry runs, staged batches and health checks between waves.
• Tier 3 — irreversible or data-destroying: deletions, overwrites, anything touching money. A named human approves, deletion is soft, execution is staged.

The highest tier echoes dual-authorization controls that NIST defined for privileged changes long before cloud tooling existed, which tells you the underlying problem is old and only the speed is new. Grading also settles arguments about process: a Tier 1 action needs no change-review board, while a Tier 3 one always does.

3. Refuse Empty Target Lists

One of the most instructive failures of the past decade started with a list. An internal Google maintenance tool that drained drives ahead of decommissioning treated an empty machine list as meaning “everything”, and duly erased live disks. Engineers distilled the lesson into a rule worth adopting wholesale: empty never means all. A runner handed zero targets should stop and complain, not quietly widen its scope. The same principle covers regexes that match nothing, filters that accidentally exclude every host, and queries that return no rows. Any of those can flip a careful operation into a fleet-wide one. The guard costs a single if-statement, which is the cheapest insurance you will ever write, and refusing to proceed also produces a log entry that tells you which input contract failed — better than discovering the semantics at three in the morning.

4. Rehearse the Stop Button

Every automation above the read-only tier deserves two kill switches: one for that script alone, and one that halts the whole runner. The second matters on the bad afternoon when several jobs misbehave together. A switch nobody has pulled is a rumour rather than a control, so drills belong to the design: twice a year for the riskier tiers, someone stops a live automation on purpose and the team measures how long the stopping took. The engineer on call holds the right to pull the switch without asking permission first — an arrangement that feels awkward in a planning meeting and invaluable at four in the morning.

5. Give AutomationOps Agents the Smallest Identity That Works

AI agents are joining the operator pool. March 2026 brought full availability for AWS’s DevOps Agent, with Azure answering through an SRE agent of its own; both investigate alerts and propose fixes. Treat them like junior operators on probation: the narrowest identity that lets them do their work, read-only until they earn write access, and every action routed through the same dry-run, batching and halting controls that human-triggered jobs obey. An agent sharing the team’s admin credential is not an agent at all; it is an unlogged operator with perfect confidence. The vendors shipping these products say much the same in their own guidance — rare agreement, and worth acting on.

6. Count the Hours You Actually Get Back

Automation earns its keep only when the arithmetic says so. The honest version multiplies monthly runs by the minutes saved each time, divides by sixty, then subtracts the hours the script itself consumes in maintenance and breakage. That final term is where optimistic business cases quietly die: a job saving ten minutes a day but needing an afternoon of care every month may be running at a loss. Track net hours returned as deliberately as you track uptime, and let the number decide whether a marginal automation stays, gets simplified, or is retired in favour of doing the task by hand. Teams that publish this figure monthly report a pleasant side effect: engineers start proposing deletions, not just additions, because the scoreboard rewards subtraction too.

7. Watch Induced Incidents, Not Just Success Rates

A script can succeed every single time and still be quietly harmful — skipping a cache warm here, leaving a replica slightly stale there, nudging latency upward everywhere. Run success rate answers “did it finish”; the sharper question is “did the run itself cause trouble”. The induced-incident rate, adapted from DORA’s change-fail-rate idea, counts the incidents where an automation was the trigger rather than the bystander. A rising ratio is an early warning that a job’s assumptions have drifted away from the system it manages, usually long before anything fails loudly enough to page a human.

8. Retire Automation on Purpose

Scripts rot because the systems beneath them keep changing: endpoints move, schemas evolve, the team that understood the workaround disperses. The registry should therefore carry review dates, and retirement should be celebrated as a decision rather than discovered as an outage. An automation nobody can explain is a liability wearing the costume of an asset, and unlike a model, it degrades silently rather than visibly. When a script’s owner leaves, its review lapses, or its net hours turn negative, the honest move is deletion — the task returns to a human who will notice when it stops making sense.

None of these controls demands exotic tooling; most are policy written down and enforced by boring code. For teams already working the intelligence angle, the walkthrough on bringing AIOps into an IT team pairs naturally with an AutomationOps registry, and the pieces on cutting IT event noise and multi-cloud monitoring for busy engineers cover the observation half of the loop. Order matters: inventory first, tiers second, clever stuff only after the boring parts hold.