The edge versus cloud debate is usually framed as a choice. In practice every connected product splits its pipeline across both, and the useful question is where each stage belongs.
Four constraints decide it
Latency, bandwidth, connectivity and cost. Anything that must respond faster than a network round trip belongs at the edge. Anything that would be expensive to transmit continuously belongs at the edge. Anything that must keep working when the link drops belongs at the edge. Everything else is a candidate for the cloud.
Reduce early
The strongest architectural move is to convert raw samples into features close to the sensor. A high rate vibration stream is impractical to send continuously and unnecessary to store. A compact set of features per interval carries most of the diagnostic value at a tiny fraction of the bandwidth, and it makes your cellular bill predictable.
What the cloud is genuinely better at
Comparison across a fleet, model improvement, long term storage, device management and updates. None of these need to be local, and all of them get better with scale. A device that learns only from itself is limited to what it has seen.
Design for the link being down
Assume connectivity is intermittent, because on industrial sites it is. Local buffering with a defined retention window, and a reconciliation strategy on reconnect, should be in the design from the beginning. Retrofitting offline behaviour into a cloud-first product is one of the harder rewrites there is.
A simple rule
Decisions at the edge, learning in the cloud. If a stage of your pipeline changes what the device does right now, keep it local. If it changes what the device knows over time, the cloud is the better home for it.