The Autonomous IT Operations Maturity Model

Nothing in this model is a technology milestone. Every transition between stages is a decision somebody has to be willing to sign, and the estates that move fastest are the ones that identified who that person was before they started.

1. Why five stages

The stages are not arbitrary. Each one corresponds to a distinct question the organisation has to answer, and you cannot answer a later question before an earlier one. An estate that tries to jump from stage 0 to stage 3 fails not because the technology cannot do it, but because it has no evidence base on which to grant the permission.

2. Stage 0 — Reactive

Humans read every alert. Correlation happens in an engineer’s head. Runbooks exist as a mixture of wiki pages of uncertain currency and knowledge held by three people, two of whom are on the night shift.

• Signature: alert volume is discussed in terms of how many people it takes to read, not what it means.
• Autonomy: 0%. Some scripted responses may exist, typically disabled after an incident nobody has documented.
• The dominant cost: 3–4 engineer-FTE per year triaging alerts that required no action.
• Exit criterion: telemetry is complete enough that a diagnosis engine would see what an engineer sees.

The work at this stage is unglamorous and has nothing to do with AI: agent coverage, consistent naming, and deleting suppression rules whose author has left the team. Estates that skip it produce a stage 1 observation period with poor agreement rates and conclude, wrongly, that the diagnosis is bad.

3. Stage 1 — Observed

The platform is deployed with every policy inert. It ingests telemetry, diagnoses incidents, matches policies, and records what it would have done — executing nothing. This is the single highest-value stage in the model and the one most often rushed.

The output is not a demo. It is an evidence pack: for every incident in the observation window, what the machine concluded, what policy it would have selected, and what the engineer actually did. Agreement rates above 90% on matched classes are typical; the disagreements are the useful part.

Exit criterion: a change advisory board has reviewed the observation evidence and approved a named, narrow set of policy classes for activation. Not the library — a set you can count on one hand.

4. Stage 2 — Assisted

Actions are proposed, fully diagnosed, with evidence and a one-click approval. Nothing runs unattended. This is where the majority of enterprises we assess are currently sitting, and a substantial number of them are sitting here permanently by choice — which is a legitimate end state, not a failure.

The reason stage 2 is defensible as a destination is that the effort saving is already most of what is available. Human effort in incident response decomposes into noticing, diagnosing, deciding, and executing. Deciding is roughly 8% of it. Stage 2 removes the other 92% while retaining a named human on every production change.

• Signature: engineers stop complaining about being paged and start complaining about approval-click volume — a much better problem.
• Autonomy: ~25%, driven by a small number of trivially safe classes promoted early.
• Failure mode: approval fatigue. If an engineer is approving 60 pre-diagnosed actions a shift without reading them, the control is theatre.
• Exit criterion: a body of execution history showing approved actions producing the expected outcome, with rollbacks at or near zero.

5. Stage 3 — Governed autonomy

Signed policies in the autonomous class run unattended within their declared blast radius. Everything else remains assisted or human-only. This is not “the AI runs the estate” — in a mature stage 3 estate, roughly 58% of the policy library is autonomous and it handles about 60% of incidents.

The prerequisite is not confidence in the model. It is the governance apparatus: signed policies with mandatory rollback, derived approval classes, precondition re-verification against live state, and hash-chained decision records. An estate that reaches stage 3 without those has not matured; it has taken a risk it has not measured.

6. Stage 4 — Self-optimising

Stage 4 is not more automation. It is what the organisation does with the capacity the first three stages returned. An estate at stage 3 that never staffs problem management stays at stage 3 forever, resolving the same incidents faster and more cheaply, indefinitely.

The distinguishing behaviour at stage 4 is that incident volume starts falling. Recurring signatures get eliminated at source: the batch job that generated the blocking sessions gets fixed, the log rotation that filled the filesystem gets corrected, the deployment that leaks connections gets rewritten. Autonomy rate may plateau or even dip, because the easy repetitive band is shrinking as a proportion of a smaller total.

• Signature: problem management is a named, staffed function rather than something done when there is time.
• Autonomy: 75%+ of a shrinking incident population.
• Leading indicator: recurrence rate of the top 25 signatures, quarter on quarter.
• The real return: engineering capacity spent on the 12–16% of genuinely novel incidents, which is where the estate’s hardest problems live.

7. Self-assessment — five dimensions

Score each dimension 0–4 against the descriptors below. Your stage is the lowest dimension score, not the average — this model is deliberately rate-limited by its weakest link, because that is how it behaves in practice.

The dimension that most often lags is the fourth. Estates routinely reach strong telemetry and decent runbooks while automation remains procedurally invisible to the change process — which works until the first audit, at which point it does not.

8. Stage transitions in the field

9. Anti-patterns — how estates stall

1. 1Skipping observation. Without an evidence pack there is nothing to show a change advisory board, and approval stalls indefinitely. The seven days you save cost you a quarter.
2. 2Activating broadly. Forty classes at once makes the first month’s outcomes unattributable. When something surprising happens — and it will — nobody can say which policy caused it.
3. 3Framing the programme as headcount reduction. The engineers asked to author policies are being asked to automate themselves out of a job; policy quality suffers and edge cases go undocumented.
4. 4Letting policy authorship escape change control. A junior engineer widening an allowlist without review is a production change made through a side door. Require two-person review on scope fields specifically.
5. 5Measuring autonomy against alert volume. It inflates the number, hides the truth, and makes year-two comparisons meaningless.
6. 6Treating stage 3 as the destination and never staffing problem management. The estate resolves the same incidents forever, quickly and cheaply, and never gets to the compounding return.
7. 7Suppressing rather than correlating. Suppression discards signal and makes the dashboard look better; it is the single most common way an estate makes stage 0 look like stage 1.

“Every estate that stalled, stalled at a governance boundary. We have never once been blocked by the model.”

Kiran Patel, VP Engineering

10. Using this model

Score the five dimensions honestly, take the lowest as your stage, and work only on that dimension. The model is rate-limited by its weakest link, so effort spent on any other dimension returns nothing until the weakest one moves.

Then identify, by name, the person who has to sign the next transition — head of operations for stage 1, the change advisory board for stage 2, the CISO for stage 3, the CIO for stage 4. Ask them what evidence they would need. In our experience that conversation, held before any deployment, is worth more than the first two months of the programme.

References & further reading

1. [1]ITIL 4 — Continual Improvement, Problem Management, Change Enablement AXELOS / PeopleCert
2. [2]ISO/IEC 20000-1:2018 — Service management system requirements International Organization for Standardization
3. [3]NIST AI Risk Management Framework (AI RMF 1.0) National Institute of Standards and Technology, January 2023
4. [4]Accelerate: The Science of Lean Software and DevOps Forsgren, Humble & Kim, IT Revolution Press, 2018
5. [5]The Site Reliability Workbook Beyer, Murphy, Rensin, Kawahara & Thorne, O’Reilly Media, 2018
6. [6]AAQUILIX stage-transition benchmarks, 14 production estatesInternal — 2024–2026