AI in IT operations, soberly
IT operations produces text at industrial scale: tickets, runbooks, change records, logs, postmortems, handover notes. Language models are genuinely good at text. That overlap is real, and it is also narrower than the marketing suggests. The distance between the two is where operational budgets go to die, so it pays to be precise about where the value actually sits.
What works today
Four uses have earned their place, and each for a specific reason. Knowledge access: question answering over your own runbooks, tickets, and documentation. The value is not intelligence; it is retrieval that survives bad folder structures, and it is usually the best first use case because the relief is high and a wrong answer is visible. Drafting: first versions of change descriptions, incident summaries, and stakeholder communication. The human edits and signs; the model removes the blank page. Triage: routing tickets, tagging incidents, spotting duplicates. Boring, measurable, and exactly the pattern work models handle well. And summarization: long incident timelines and log excerpts compressed into something a person can act on, useful precisely because nobody reads the long version anyway.
Before anything goes live, four tests. A human stays in the loop for anything that changes state. The blast radius of a wrong answer is small and visible. The relief is measurable in hours saved or tickets deflected, not in enthusiasm. And the data boundaries are settled in writing, together with security and data protection, before the first prompt exists rather than after the first incident.
No special exemptions
The most useful mental move is to treat AI like any other technology entering regular operations. A named owner, or it is a demo rather than a service. Evaluation on your own cases: a small, honest test set of real questions with known answers tells you more than any vendor benchmark. Build to run applies in full: a runbook, monitoring, and a fallback path for when the system is wrong or unavailable. And assistive before autonomous: the system proposes, a human disposes. Autonomy is not a starting point. It is something a capability earns through a track record you can inspect.
What to leave alone, for now
Some applications should wait, not because they are impossible but because their failure modes are unacceptable at current maturity. Autonomous change execution in production combines the two things you least want together: a large blast radius and unclear accountability. Automatic alert suppression is an elegant way to sleep through the one alarm that mattered. Actions without logs violate the oldest rule in operations, no log, no action, and AI does not get to skip it. Sensitive or health-related data does not enter any system on the strength of enthusiasm; clearance comes first. Anything whose failure mode nobody can explain has no place in an operational chain. And any capability woven into operations needs the same exit path as every other sourcing decision: your data comes back, your process survives the vendor.
The pattern behind that list is not caution for its own sake. Operations runs on accountability, attribution, and reversibility. Tools that weaken those three do not become acceptable by being impressive.
The sober upside
None of this is a case against the technology. The relief is real: hours returned to teams that were drowning in text, faster onboarding because knowledge stops hiding in folders, calmer incidents because the timeline writes itself. Teams that start small, measure honestly, and expand from evidence collect compounding wins. Teams that start with autonomy collect incidents with novel root causes.
The question is not what AI could do for operations. It is what you can afford to be wrong about. Start where the answer is "not much", and let the track record argue for more.