Run the Patch Cycle with AI-Drafted Artifacts

Tier: Core · Workflow area: Identity, endpoint & patch · ~35 minutes

This playbook wires AI into each stage of the monthly patch cycle — from Patch Tuesday triage through ring promotion to exception records — using WSUS, Intune or RMM patch data as input, so the writing stops eating the week while the promotion judgment stays visibly human. (UC-34)

When to use

• Every monthly cyclethe artifacts recur, the structure is stable, and the drafting time is pure overhead. This is among the highest-ROI recurring uses of AI in sysadmin work.
• Patch-failure triageclustering hundreds of failed installs into a handful of causes is exactly the summarization work models do well.
• Exception and deferral recordsthe documentation nobody writes until the auditor asks. AI removes the excuse.

When NOT to use

• Out-of-band emergency patchingactively exploited, patch-now situations follow the incident process; draft the paperwork after the fleet is safe.
• Letting AI set the promotion schedule"pilot looks fine, promote" is a judgment about your risk tolerance, blast radius and business calendar. AI can argue both sides; it does not get the vote.
• Applicability claims without dataasking a model which CVEs affect your fleet without giving it your fleet inventory produces plausible fiction. Data in, or nothing out.

The recipe

1. 1.

   Draft the applicability analysis from release notes plus your inventory. On Patch Tuesday, feed both halves:

   Copy

   Below: (a) this month's security update summary [paste the release
   notes / CVE list], (b) our fleet profile [OS versions with device
   counts, key server roles, exclusions]. Produce an applicability
   analysis:
   - Which updates apply to which fleet segment, with device counts
   - Updates that do NOT apply to us, with the reason (no such role/OS)
   - Known-issue flags from the release notes relevant to our segments
   - A "verify manually" list for anything you could not map confidently
   Table format. Do not invent CVE details not present in the input.
   

   Spot-check two mappings against the vendor bulletin before circulating — mis-mapped KB-to-OS rows are the common drafting error.

2. 2.

   Generate the pilot-ring rationale as a standing artifact. Once per quarter, have AI draft (and you correct) the written rationale for ring composition: why these 25 devices, which hardware models, app profiles and departments they represent, what coverage gaps remain. This document is what turns "we patch some machines first" into a defensible process at audit time.

3. 3.

   Run the pilot, then AI-triage the failures. Export failure data from Intune > Reports > Windows updates, WSUS console, or the RMM patch report, and cluster it:

   Copy

   Here are this cycle's patch failure records: [paste export —
   device, model, OS build, update, error code, timestamp].
   1. Cluster failures by probable root cause, using error codes and
      shared attributes (model, build, disk space, connectivity)
   2. For each cluster: count, most likely cause, the standard
      remediation for that error class, and confidence
   3. Flag any cluster that suggests the UPDATE is faulty rather than
      the endpoints (same model+build failing identically)
   4. Order clusters by device count descending
   

   Sample output shape you want: 0x80070070 — 41 devices — disk space <10GB — cleanup script — high confidence. Verify one device per cluster manually before mass-remediating.

4. 4.

   Make the promotion decision yourself, then have AI write it down. Look at pilot health (failure rate, helpdesk signal, known-issue reports from other orgs), decide promote / hold / rollback, and only then:

   Copy

   Draft a ring-promotion record: cycle 2026-08, pilot ring results
   [paste numbers], decision: PROMOTE to Ring 2 on 2026-08-12,
   decided by [name]. Include the evidence reviewed, the known issues
   accepted, and the rollback trigger (helpdesk tickets > N or failure
   rate > X% in first 48h). One page.
   

   The record exists because you decided — never the reverse. If you notice AI's draft arguing you into a different decision, that is a signal to stop and re-examine, in either direction.

5. 5.

   Document exceptions with expiry dates. For every deferred device or excluded server, AI drafts the exception record from your bullet points: asset, patch deferred, business reason, compensating controls, owner, expiry date, re-review trigger. An exception without an expiry is a permanent vulnerability with paperwork.

6. 6.

   Close the cycle with a one-page report. Feed the month's numbers (applicable, deployed, failed, remediated, excepted) and get the summary for management and the entry for your compliance evidence folder. Reconcile the headline compliance percentage against the console report before sending — the pb-27 rule applies to patch numbers too.

Make it yours

• Intune/Autopatch shopAutopatch owns ring mechanics; your AI artifacts shift to reviewing its reports, drafting the exception records it does not write, and documenting the cases where you pause its progression.
• WSUS shopthe exports are uglier; keep a saved prompt that normalizes WSUS's per-update status codes into the failure-triage format, and lean harder on the applicability analysis since nothing does it for you.
• RMM/third-party patching (NinjaOne, Automox, PDQ)same artifacts from the RMM's patch reports; add third-party app patching (browsers, Java, readers) to the applicability prompt since that is where these tools earn their keep.

Quality check

• Every artifact cites its data source and export date. An analysis that cannot say what it was computed from is not evidence.
• One-per-cluster manual verification before mass remediation. Clustering errors are cheap; a wrong mass-fix is not.
• Promotion records name a human and a rollback trigger. "Promoted per process" without a name and a threshold is neither.
• Exception list reviewed at cycle start. Expired exceptions either renew with a fresh reason or the device patches this cycle — no third state.