An evaluation posted to arXiv on 6 July 2026 ran 302 quality-audited Kubernetes incidents past retrieval-augmented models and scored two abilities separately. Naming the root-cause service: correct between 91.4% and 99.7% of the time. Choosing a valid recovery action for the incident it had just diagnosed: 36.8% to 60.3%. Forty to fifty-five points sit between those two columns, and that distance is the most useful number published about AIOps this year.

That is a claim about kinds of work, not about model quality. The model reads well and decides badly, and that sorts the market into two piles. Some operational work fails visibly, in front of the person holding it. Some fails by turning into an action against production. AIOps earns its money in the first kind and is currently a liability in the second, and most of the disappointment in this market comes from buying it for the second after a demo of the first.

Alert correlation, deduplication and the first draft of the story

PagerDuty markets its AIOps product as cutting alert noise by up to 91%. Read that beside a February 2026 survey of 1,039 SRE, DevOps and IT operations professionals, sponsored by NeuBird, in which 44% reported an outage in the past year linked to suppressed or ignored alerts. Correlation that folds forty pages into one incident is a genuine gain. Correlation that quietly decides which pages you never see is how that 44% happens, and what separates them is whether the grouping can be inspected.

The strongest cases are the ones a human can check in seconds. A model that reads the deploy history, the metric shift and three log streams and drafts the incident narrative is doing work otherwise done at 3am by someone with poor recall, and when it is wrong the evidence sits in the paragraph. Explaining why a bill moved is the same kind of task, full of correlations a human spots a month late, and the FinOps Foundation's State of FinOps 2026, released on 19 February 2026 across 1,192 respondents managing over $83 billion of annual spend, found 98% of them now manage AI spend, up from 31% two years earlier. Turning a resolved incident into a written runbook is better still: the facts are settled, and the worst outcome is a human correcting a sentence.

AI code review on infrastructure catches one class of mistake and is blind to another

Veracode's 2026 GenAI Code Security Report, published on 28 July 2026, tested more than 100 models and found the average security pass rate stalled at 56%, up one point from 55%. Roughly 44% of generation tasks introduced a risky vulnerability when nobody prompted specifically for security. The best performer, GPT-5.5, reached 68%, still failing one security task in three.

The uneven part is the useful part. Those models passed SQL injection tasks 83% of the time and cryptography 87%, but cross-site scripting only 15% and log injection 12%. An AI reviewer is strong on what it has seen labelled a thousand times, close to blind elsewhere, and it will not tell you which mode it is in. On an infrastructure-as-code diff, use it as a second reader for the mistakes obvious in hindsight: the security group opened to 0.0.0.0/0, the change that is a replacement rather than an update. Do not make it the gate: the classes it misses are the ones nobody wrote a rule for.

Autonomous remediation is where the evidence stops supporting the pitch

The same study carries the finding that should end the self-healing conversation for another year. Even when the model correctly identified both the root-cause service and the fault type, it chose an invalid remediation in 39.5% to 62.0% of those correctly diagnosed incidents. Diagnosis does not carry over into action. Gartner's June 2025 prediction that over 40% of agentic AI projects would be cancelled by the end of 2027 named inadequate risk controls alongside cost, and this is the one that is missing.

Capacity planning fails for a related reason: the model produces a confident number from thin evidence, and a confident number is what a planning meeting wants. EU AI Act Article 14 is written against exactly that, requiring that a human overseer can interrupt a high-risk system and bring it to a halt in a safe state, and naming automation bias as the thing oversight has to resist.

The spending ceiling has to sit above the provider's billing console

In May 2026 an autonomous agent was handed unrestricted AWS credentials and told to port-scan DN42, a hobbyist network. It provisioned five m8g.12xlarge instances, 48 vCPUs each, plus load balancers and Lambda functions, then kept re-applying the same CloudFormation template. The operator found out roughly 24 hours later from credit-card charges totalling $6,531.30, for a workload the community reckoned would fit on a $5 per month VPS. AWS later cut the bill to $1,894. The protection that worked was a goodwill credit.

No major provider's budget tooling would have stopped it, and all three say so in writing. Amazon documents AWS Budgets as refreshing up to three times a day, each update typically 8 to 12 hours behind the last, a cadence built for humans who make expensive mistakes one at a time. Microsoft states that an exceeded Azure budget threshold does not affect resources or stop consumption, with cost data typically available within 8 to 24 hours. Google Cloud states that an alerts-only budget does not automatically cap usage or spending. AWS ships an open-source Budget Controls solution that acts at 90% of a budget, covers four services in one region, and concedes that storage and networking keep accruing charges. A three-person agency, written up in July 2026, took a $14,000 single-day AWS charge against a normal monthly bill of $10 to $15 after attackers pulled static keys off an instance and spent them on Bedrock model calls.

Our answer is to put the limit where the credentials are issued, not where the invoice is assembled. Spend on Sencai is tracked as it happens by provider, project and environment, with caps and budgets that alert while it is accruing rather than on an 8 to 24 hour billing cycle. Acting on a breached cap automatically is on our roadmap and is not shipped, so today a human still pulls the credential. AI is the one budget we can bound in advance: it is bought in credits, and a credit is a fixed amount of money rather than a token count, so a model price change moves how many tokens a credit buys and never what it is worth. Each paid personal plan has a monthly allowance and a hard ceiling set at a multiple of it, so a runaway script cannot produce an unbounded bill. Runbooks are approval-gated for the same reason: the model proposes, a named human executes.

An audit trail that can say whether a person or a model did it

EU AI Act Article 12(1) requires high-risk systems to technically allow the automatic recording of events over the lifetime of the system, and Article 26(6) requires deployers to keep those logs at least six months unless other law says longer. If you are planning against an August 2026 date, correct it. Regulation (EU) 2026/1744, the Digital Omnibus on AI, in force from 27 July 2026, moved Annex III stand-alone high-risk systems to 2 December 2027 and Annex I product-embedded systems to 2 August 2028. The dates moved; the obligations did not.

The operational reason to build this has nothing to do with the deadline. Six months after an incident the question is whether a person or a model made the change, and a setup that records AI actions in one system and human ones in another cannot answer it without a join nobody trusts. We refused to keep two records: model actions and human actions land in one append-only trail. Sencai exports it as CSV with the entry_hash and prev_hash on every line, so a reader who does not take our word for it can recompute the chain. The field that earns its place is the small one next to the actor, saying whether the change came from a person or from a model spending a person's allowance.

The rule that falls out of the evidence is unglamorous and holds. Let a model read anything, including the things it reads badly, because a bad reading is visible in the paragraph it wrote. Let it write only where a named person signs the change and a credential limit sits underneath in case that person is wrong too. Between a provider notification on an 8 to 24 hour cycle and someone who reads email on weekdays there is a smoke detector and no sprinkler. The DN42 operator had a smoke detector.