This module installs the judgment that every later module assumes: deciding in advance, and in writing, which production tasks AI may only draft, may advise on, may act on with approval, or may run alone — chosen from blast radius, irreversibility and verification cost rather than from enthusiasm or fear.
It is a Tuesday standup at a mid-size commerce company, and Divya — the platform lead — is holding two printouts. The first is a Slack thread from last week: at 03:12, an AI investigation assistant told Priya, the on-call SRE, that a checkout-api latency spike was "caused by the 02:58 payment-svc deploy," with three tidy citations. Priya rolled the deploy back. The latency didn't move. The real cause, found forty minutes later, was a Redis eviction storm the assistant never mentioned — the deploy it blamed was real, the citations were real, and the conclusion was wrong.
The second printout is a capacity forecast the same assistant produced that morning: confident, well-formatted, and, Meera points out with visible satisfaction, generated by a model that cannot actually fit a trend. Meera is the team skeptic; she has argued for a month that AI has no business anywhere near production.
Divya doesn't disagree with the caution — she disagrees with its bluntness. "You're both right and both wrong," she tells the room. "The question was never whether we use AI here. It's that nobody has written down where — and until we do, we keep having this argument one incident at a time."
That written-down where is what this module builds. You already know how to prompt, how to structure outputs, what a verification gate is, and why an agent needs an allowlist — that was the Common Core. This module is where that discipline meets the one domain where the industry itself has drawn a line. Stack Overflow's 2025 survey found that 76% of developers will not use AI for deployment and monitoring — the single strongest AI resistance measured anywhere in the software lifecycle. At the same time, DORA 2025 found 90% of developers using AI daily, with individual throughput up sharply while organizational delivery stayed flat, and concluded that AI is an amplifier: it magnifies the strengths of well-run systems and the dysfunctions of badly-run ones. Ops is where those two findings collide, because ops is where amplified dysfunction becomes an outage.
This module's answer is neither the enthusiast's "let the agent run the cluster" nor the refusenik's "AI never touches prod." It is a trust map: a deliberate, written placement of every recurring ops task onto one of four trust levels, built from the properties of the task — blast radius, irreversibility, verification cost — rather than from vibes in either direction. Every module after this one assumes you have this map; M2 and M3 are, in effect, the map applied to IaC and incidents.
The 76% deploy/monitoring resistance is not a fear statistic to overcome — it is trust calibration working as intended, and your job is to turn that blunt instinct into a precise, per-task map.
A senior developer accepting a wrong AI suggestion typically pays in review time: the compiler objects, a test fails, a colleague catches it, and the worst common case is a bug that ships behind further gates. The software-engineering track calls this the "almost right" tax — 66% of developers report spending extra time debugging AI-generated code, and it is paid in minutes and hours. Ops pays the same class of error in a different currency, and the exchange rate is brutal. Three structural properties explain why.
Dev-time AI output is scoped by the file, the PR, the service. Ops actions are scoped by whatever the credential can reach. A hallucinated parameter in application code breaks a feature; a hallucinated parameter in a Terraform module, applied, can recreate a database. An AI-suggested kubectl command runs with your kubeconfig's permissions, not with the model's confidence level. The unit of damage in ops is not "a bug" — it is "everything this control plane governs." This is why the trust map is drawn per task and credential scope, not per tool: the same assistant is harmless generating a dashboard JSON and hazardous generating a terraform apply that someone pipes to yes.
Most dev mistakes are reversible by construction — that is what version control is for. Ops operates a spectrum: restarting a stateless deployment is trivially reversible; scaling is reversible with a lag; a schema migration is reversible only if you engineered the down-path; deleting a resource with data, rotating a secret consumers depend on, or sending a wrong customer communication during an incident is not meaningfully reversible at all. The trust map's most important single question is: if this action is wrong, what is the undo, and how long does it take? Tasks whose undo is "restore from backup and explain to the client" sit at a different trust level from tasks whose undo is Ctrl-C, regardless of how good the AI is at either.
Dev has fast, cheap oracles: compilers, unit tests, local runs. Ops truth is often only observable in production, later, under load. An AI-drafted alert threshold looks exactly as plausible as a correct one; you find out which it was during the incident it failed to catch. This inverts the economics the software-engineering track taught: there, the burn zone was "verification cost exceeds generation savings." In ops, for a whole class of tasks, verification before reality is nearly impossible — which is why the trust map compensates with staged exposure (plan before apply, canary before fleet, advise before act) instead of pretending review alone is enough.
The question that places a task on the map is never "is the AI good at this?" — it is "what happens when the AI is wrong here, and how would I know before it matters?"
The map uses four levels. They form a ladder of increasing AI authority and decreasing human touch — and, critically, a task's level is a decision you make and write down, not a property that emerges from usage.
AI produces an artifact; a human reads, edits, and owns every consequence; the artifact does nothing until a human acts on it. Drafting a runbook, a postmortem skeleton, a Grafana dashboard JSON, a PromQL query you will read before running, release notes, an on-call handoff summary. This is where AI earns its keep in ops today with close to zero incremental risk — the risk profile is that of any junior draft you review. The failure mode at this level is not the AI acting; it is you rubber-stamping. Generate-only still requires the Common Core read-and-verify discipline, because a wrong runbook step is a landmine with a delay fuse.
AI has read access to real operational data — logs, metrics, alert history, cluster state — and produces analysis, hypotheses, or recommendations that reference that data. K8sGPT explaining a CrashLoopBackOff, an investigation agent correlating a spike with a deploy, an anomaly explanation, a rightsizing recommendation. The step up from Level 1 is data access, and it buys relevance at the price of two new risks: the advice can be confidently wrong about your system (not just wrong in general), and read access must be genuinely read-only and data-governance-clean (client telemetry in a services-company context may not be pasteable at all — your MSA decides, not you). Level 2 output is consumed under citation-checking discipline: every claim that references data gets spot-checked against the source before you act on it. M3 builds this discipline out fully.
AI proposes a concrete action — a remediation, a config change, a scale-up — from a bounded, pre-approved action set, and a named human approves each execution. The proposal is specific ("restart deployment checkout-api in prod-eu, 12 pods affected, last restart 41 days ago"), the action set is an allowlist designed in daylight, execution is logged, and the approval is not a formality — the approver is accountable exactly as if they had typed the command. This is the level the incident-tooling market is converging on: PagerDuty's SRE agent ships human-oversight execution first and holds fully-autonomous modes back deliberately; that sequencing is itself a lesson. The engineering substance of Level 3 — allowlist design, approval UX that resists rubber-stamping, audit logs — is M3's bounded-remediation material.
AI executes without per-action human approval, inside hard technical constraints. On a 2026 ops trust map this level is nearly empty, and should be. What legitimately lives here is narrow, mechanical, and self-limiting: actions that were already automated pre-AI (an HPA scaling on CPU is autonomous action; nobody approves each replica), plus perhaps AI-mediated versions of the same — where the action is idempotent, reversible in seconds, rate-limited, scoped to one resource class, and watched by an independent kill switch. The honest test for Level 4 is: would you have trusted a cron job with this in 2020? If not, an LLM's judgment does not change the answer. Anything touching data, money, customer communication, security boundaries, or anything whose undo you cannot state — never Level 4, and for most of it, never Level 3 either.
Levels are assigned to task-plus-scope, not to tools — "AI restarts pods" can be Level 3 in prod and Level 4 in an ephemeral test namespace, and both placements can be correct at once.
The most dangerous transition on the map is silent drift from Level 2 to Level 3 — the day an engineer starts pasting the advisor's suggested commands into a prod shell without independent thought, the approval gate has dissolved without anyone deciding it should.
Both of this module's headline statistics are routinely misread — as either "AI is not ready for ops" or "ops engineers are laggards." Read correctly, they are a placement guide.
DORA 2025 — "AI amplifies." The report's core finding is that AI adoption is near-universal (90%, up 14 points year over year) and that individual throughput gains do not automatically become organizational performance; AI magnifies existing system quality in both directions, and throughput gains come with stability risk unless controls absorb them. For the trust map this translates directly: the better your existing verification infrastructure — tests, policy gates, canaries, rollback paths, observability — the higher up the ladder you can safely place tasks, because the system catches what review misses. Teams with weak gates get the amplified downside. The map is therefore not static: every gate you build in M2 and M3 is a license to move specific tasks up a level. DORA's AI Capabilities Model names quality internal platforms as one of the capabilities that convert AI speed into delivery — in this track's terms, the platform is the set of gates.
Stack Overflow 2025 — the 76%. The resistance is real, measured, and directionally sound — but it is blunt. "Deployment and monitoring" spans on-call handoff summaries (Level 1, near-zero risk, high toil value) and production remediation (Level 3 at most). Treating the whole span as forbidden wastes the safe wins; treating the whole span as fair game because "AI is good now" ignores exactly the properties this module opened with. The 76% marks where the default should be conservative — in ops, a task sits at Level 1 until you argue it up, whereas in dev the argument runs the other way.
The positive evidence exists and is specific. Google's SRE organization reported that AI-drafted postmortems scored 10% better than human-written ones in blind review with a projected 51% reduction in writing time, and that AI-prepared executive incident summaries took 52% less time at comparable quality. Note what shape this evidence has: both are generate-only tasks with mandatory human verification — the strongest measured wins in AI-for-ops live at the bottom of the trust ladder. That is the pattern to internalize: the evidence supports climbing the ladder task by task, bottom-up, gate by gate. It does not support starting at the top.
Scenario questions in this track's assessment deliberately include cases where the correct answer is "do not use AI here" or "use it one level lower than proposed" — placement judgment is scored, not enthusiasm.
The map is a table you can defend in review: every recurring task, a level, and a one-line justification citing the task's properties. Build it in four passes.
Pass 1 — inventory. List your actual recurring tasks from artifacts, not memory: your on-call handoff notes, closed tickets, PR history, the alerts you acked last month. The research behind this track groups ops work into eight areas — CI/CD and releases, IaC, incident response, observability, capacity and cost, security ops, developer platform, and runbooks/knowledge — and a personal inventory of 25–40 concrete tasks is typical.
Pass 2 — score each task on three axes.
Pass 3 — assign levels. A workable default rule set:
Level 1 (generate-only): any task whose output is text/config a human
will read and own before it does anything. Default for everything.
Level 2 (advise): Level 1 tasks that become materially better with
read access to real data, AND the data is governance-clean,
AND you commit to citation-checking the output.
Level 3 (act-with-approval): only where (a) action set is enumerable
and small, (b) every action's undo is known and fast, (c) execution
is logged, (d) a named human approves each run. Typically 3-6 tasks.
Level 4 (act-autonomously): only what you'd have trusted to a
dumb automation in 2020, now with an LLM in the loop. Often empty.
A worked slice of a real map, from Priya's on-call rotation at the commerce company:
| Task | Blast radius | Undo | Level | Why |
|---|---|---|---|---|
| Postmortem drafting | none (text) | n/a | 1 | Strongest positive evidence in the category; claim-by-claim review gate (M3) |
| PromQL for ad-hoc questions | none until run | n/a | 1 | Query read before execution; sanity-check habit from M4 |
| Alert triage enrichment | read-only | n/a | 2 | Needs live alert/deploy data; citations spot-checked |
| K8s failure diagnosis | read-only | n/a | 2 | K8sGPT-class; kubectl remains source of truth |
| Restart / rollback / scale from allowlist | one deployment | seconds–minutes | 3 | Bounded set, audit log, human approves (M3 lab) |
| Terraform apply to prod | estate | sometimes none | never above 2 | AI drafts and explains plans; human runs apply, always |
| Capacity forecasting | budget decisions | quarters | anti-pattern | See below — wrong tool, not wrong level |
Pass 4 — calibrate as a team. A personal map governs your own week; a team map governs what tooling gets deployed and what an agent's service account may touch. Run a one-hour workshop: each engineer places ten contested tasks independently, then the team argues the disagreements. The disagreements are the value — they surface unstated assumptions about undo paths and credential scopes that would otherwise surface during an incident. Write the result down next to the on-call runbook, and put a review date on it: the map is expected to move as your gates improve and as tools mature — a map that has not changed in a year is not stable, it is stale.
Add a fourth column to your map — "what gate would move this up a level?" — and it stops being a restriction document and becomes your team's AI adoption roadmap.
Two failure patterns are worth teaching explicitly, because both look like reasonable placements and both are wrong for instructive reasons.
Asked for a capacity forecast, an LLM will produce one — confident, well-formatted, and unfounded; it is exactly the printout Meera brandished at standup. Language models are not time-series models; they do not fit trends, model seasonality, or quantify uncertainty, and no trust level fixes that, because the failure is not risk exposure but task-tool mismatch. The correct division of labor: statistical and ML forecasting tools (Prophet-class models, your observability platform's forecast functions) produce the numbers; the LLM operates at Level 1–2 around them — critiquing assumptions ("this forecast assumes the Diwali traffic pattern repeats; here are three reasons it may not"), explaining the model's output to stakeholders, drafting the capacity review doc. The general lesson generalizes well beyond forecasting: some ops tasks belong to deterministic or statistical tools with AI as explainer, and recognizing those tasks is part of trust-map literacy. Scanners find misconfigurations, AI explains them; models forecast, AI narrates; kubectl reports cluster truth, AI interprets it.
The subtler failure: a team adopts an AI investigation assistant, it is right often enough that citation-checking quietly stops, and six months later an incident runs 40 minutes long because everyone anchored on the AI's confident, wrong hypothesis and nobody checked the cited evidence. Priya's 03:12 rollback from this module's opening is exactly this failure in miniature — the deploy was real, the citations were real, and the conclusion was wrong, so the wrong deploy got rolled back while the Redis eviction storm ran on. The countermeasure is to practice the failure before it happens: when you run game days and chaos exercises, include injects where the AI investigator is wrong on purpose — a planted plausible-but-false lead, a citation that does not support the claim it decorates — and score responders on whether they catch it, not just on time-to-mitigate. This converts the 76% instinct from a mood into a maintained skill, exactly the way fire drills maintain evacuation behavior. M3's triage lab seeds a false lead for this reason, and your team's game-day calendar should too: an AI-failure inject at least once a quarter, rotated across scenario types, with the catch-rate tracked like any other drill metric.
The trust map's hard edges are marked by task-tool mismatches (LLMs forecasting) and by verification discipline decaying with familiarity (the unquestioned investigator) — both are prevented by design and drills, not by intentions.
Your first 15 minutes: the next time you are about to run a command an AI suggested during on-call, stop before you hit enter and say one sentence out loud — "what happens if this is wrong, and would I know before it matters?" That single habit is Priya's whole lesson, and this module, in miniature.
Check yourself: A teammate proposes letting an agent auto-restart any crash-looping pod in production because "the model is clearly good enough now." Which single question decides whether that placement is acceptable — and why is "the model is good enough" the wrong basis for the answer?
terraform apply on a plan it summarized as "12 changes, no destroys"; (d) an agent restarts a crash-looping deployment in a staging namespace with a 2-hour TTL; (e) the same restart in prod during business hours; (f) AI rotates a leaked credential it detected. One of these has a trap — in (c), the cap comes from who verified the plan summary, not from the apply itself; explain.This module's companion playbooks cover the trust-map construction method as a reusable template (personal and team variants), the four-level ladder with placement rules and India/services-company data-governance overlays, the team calibration workshop agenda, and the AI-failure game-day inject library. Do this at work this week → pb-29 Sanity-Check a Capacity Forecast with AI — Without Letting It Forecast (the forecasting anti-pattern, made concrete), pb-15 Run an AI Incident Investigation and Verify Every Citation (the antidote to Priya's 03:12 rollback), and pb-21 Generate Game-Days That Test Your Humans AND Your AI (the AI-failure inject Exercise 5 asks you to design). There is deliberately no lab in M1 — the scenario exercises above are the assessment surface — but every lab in M2 and M3 begins by asking you to state the trust level of the task at hand, and the capstone assessment's judgment domain samples directly from this module.