Groups who lean on learned models for day-to-day operations often assume the model will also catch the adversary. It will catch a lot, but it will not catch everything, and the gap between those two statements is where ThreatOps lives. Below, automated detection sits on one side and a human-run discipline of intelligence plus hunting on the other, so the contrasts are easy to see. The aim is to help an AIOps-minded team decide what each one is for, what it costs, and where they should hand work to each other.

A short framing first. The Ops Atlas entry on ThreatOps describes the discipline as one operation that joins threat intelligence with proactive hunting, and it says openly that no standards body defines the term. The practices underneath, meaning intelligence production and hunting, are well established. You can read the full treatment in the xOps School Atlas entry for ThreatOps, which is the source for the framing used throughout this article.

The comparison at a glance

Before the detail, here is the shape of the contrast in plain prose rather than a grid. Automated detection answers a question somebody already wrote down: does this event match a rule, a baseline, or a learned pattern? ThreatOps asks what question we should be asking next. The first is a runtime property of your stack. The second is a recurring human process that feeds the first with better questions.

• Trigger. Detection fires when telemetry matches. A hunt starts from a hypothesis someone has formed about adversary behaviour.
• Cadence. Detection runs continuously. Hunts run on a rhythm; the Atlas suggests roughly every two weeks, with one or two behaviours examined each time.
• Output. Detection produces alerts. A hunt must end with an artefact: something concrete on paper: one of four things: a rule request, a data-shortfall ticket, a hand-over to responders, or a note confirming the team would have spotted the behaviour had it occurred.
• Failure mode. Detection fails silently when an adversary behaves in a way nobody modelled. Hunting fails when it turns into unstructured browsing with nothing written down at the end.

Where automated detection is clearly stronger

It would be dishonest to pitch ThreatOps as a replacement for the machinery you already own. Automated detection is faster than any person, never gets tired, and scales with data volume. Anything you can describe precisely should end up as a production detection, and the Atlas treats production detections as belonging to a neighbouring discipline rather than to ThreatOps itself. The scope line is deliberate: ThreatOps decides what is worth detecting and proves the idea works, and a separate team owns the detection once it is in production.

The same goes for round-the-clock alert triage, which the Atlas also places outside ThreatOps. A team that makes its hunters double as the night shift ends up with hunting as overflow work for the operations centre, an anti-pattern the Atlas names. The hunters stop hunting, and the discipline quietly disappears.

If your day-to-day involves taming noisy monitoring, you already know this tension from the operational side. We covered one version of it in our notes on reducing IT event noise with smarter tooling, and the lesson transfers: more signal is not the same as more understanding.

Where ThreatOps does something automation cannot

The honest case for the discipline is about blind spots. A joint advisory from US agencies in February 2024 on a state-sponsored group known as Volt Typhoon is the example the Atlas leans on. The advisory said conventional indicators of compromise were generally lacking, and it described footholds being kept for at least five years. A pure indicator sweep, the sort of check a feed-driven pipeline performs, would come back empty and a team might conclude it was not affected. The Atlas cautions against ever closing the question on that evidence by itself.

Dwell-time data points the same way. The 2026 edition of a widely read incident-response report reported a worldwide median stay of 14 days for intruders, up from 11, and 122 days for cyber-espionage cases and cases involving North Korean IT workers. Whatever you make of the precise numbers, the direction is clear: some intrusions sit quietly for a long time, and nothing in a rules engine announces them.

Hunting addresses that by starting from behaviour rather than from artefacts. The Atlas describes a frame with four slots, Actor, Behavior, Location and Evidence, so that every hunt is written as a testable statement. “Someone with valid credentials is using remote access in a way our baselines treat as normal” is a hypothesis you can test. “Look for bad stuff” is not.

Two ways of being wrong

An AIOps model and a ThreatOps programme fail in different ways, which is why the comparison matters.

A model fails by confident omission. It scores events against what it learned, and adversary behaviour that blends into normal operations scores low. The Atlas gives an illustration from its own lab exercise: three well-known criminal groups were compared and, across 92 distinct techniques in total, only two were common to all of them, valid accounts and externally exposed remote services. Behaviour overlaps less than people expect, so a detector tuned for one family can miss another.

A ThreatOps programme fails by drift. Without discipline it collects feeds nobody evaluates, publishes reports nobody reads, and starts hunts that end in no artefact. The Atlas lists these as vanity metrics to avoid: indicators ingested, reports published, hunts started, and coverage heat maps. Its worked quarter instead tracks outcomes, for example how many hunts yielded a new rule request or a data-shortfall ticket, and how many intelligence items led to a real action. In the worked example, a feed whose precision was a mere 15 percent was kept in alerting mode and flagged as a candidate to cancel.

That last point is the one an automation-minded reader should sit with. Feeding a blocklist straight into enforcement feels efficient. The Atlas, citing guidance from FIRST, says feeds are for flagging and alerting, not automated blocking, until a source has earned trust. Its sample policy allows blocking only for sources rated A or B for reliability, with credibility scores of 1 or 2, a measured precision of at least 0.9 over 90 days, and no hits on allowlists. Whoever is on call can undo a block at will, and an intelligence owner looks the decision over within the hour.

What each approach costs

Costs differ in kind: detection takes engineering time to build and tune, while ThreatOps takes a small, steady amount of people-time.

The Atlas proposes keeping five to eight active priority intelligence requirements, each limited to one question, one fact and one decision, and reviewing them quarterly. For teams who like automation, think of it as the specification layer. A requirement says what the business needs to know, and anything that does not trace back to a requirement is a candidate for deletion, including feeds.

There is also a data prerequisite that AIOps practitioners will recognise instantly. The Atlas decision tree begins with a blunt test: if roughly three months of usable telemetry is not on hand, repair the data before anything else. No amount of clever analysis rescues a hunt over missing logs. When a hunt cannot be completed because the data is incomplete, the right output is a logged shortfall, not a shrug.

The handoff rule that ties them together

The most useful single idea in the comparison is the handoff. Once a hunt finding is validated, it turns into a request for a detection. That sentence turns hunting from a hobby into a production input. A hunter confirms that a behaviour exists and is observable, writes it up so a non-participant could rerun the hunt, and passes it to whoever owns detections. The automated layer then takes over the repeatable part, which is exactly what it is good at.

If you already operate AI-assisted tooling, you have the receiving end in place. Our overview of how AI supports IT decision-making describes the kind of context that makes this handoff smoother: the more clearly you can describe an environment, the faster a hunter’s finding turns into a tuned rule.

The Atlas also insists that a hunt with no finding is not a failure. When a team can demonstrate that it would have noticed the behaviour and noticed nothing, the negative is a confident one, and that counts as a win. Where the data fell short, the outcome is a hole that needs closing. Only “we looked around and have nothing to show” is a real failure, because it leaves no artefact.

A practical way to choose

Rather than picking one side, decide which question you are trying to answer this quarter.

1. If your main problem is volume and response time on known patterns, invest in detection engineering and noise control first.
2. If your main worry is what you do not know, such as long-lived access that never trips a rule, add a small hunting cadence with a named owner.
3. If you lack stakeholders who can say what intelligence they need, the Atlas suggests a lean advisory model rather than a large build.
4. If nobody can own the follow-up from findings, consider buying managed hunting rather than starting a programme that will stall.

Notice that none of those choices involves swapping the model out. The comparison is not about which is better; it is about which job each one does. Automated detection is the engine. ThreatOps is the navigation: it keeps asking whether the engine is pointed at the right terrain.

Closing thought

The sensible position for an AIOps reader is a division of labour. Let machines hold the line on everything you can describe, and let a small, disciplined human practice work on everything you cannot yet describe, then convert its successes into rules. Keep the metrics honest, expire what you ingest, and write down what every hunt produced. That is the whole comparison in one sentence, and it is why the two approaches work better together than either does alone.