Storage Intelligence adds findings and safer batch previews

A storage recommendation can be sensible and still select the wrong objects for a bulk change. Google Cloud’s latest Storage Intelligence update shortens the path from a finding to a batch job. That makes the selection review more consequential.

Google announced general availability of Storage Intelligence advisor and enhanced storage batch operations on September 25, 2026. The announcement lists daily usage findings, multi-bucket processing, dry-run validation and filters based on Storage Insights datasets. These capabilities are available to Storage Intelligence customers; they are relevant to teams managing the object stores behind training, analytics and inference pipelines.

A daily finding is a review input

The advisor documentation covers unusual cold-storage operations, rate-limited requests, cross-region egress and storage growth. Google describes findings based on daily snapshots. Use that timescale when assigning the response: this is not a substitute for the service’s immediate error and latency monitoring.

In a hypothetical training pipeline, a spike in reads against archived objects might reflect a newly scheduled evaluation job. Moving those objects to another class may help, but changing the job’s read pattern could be the better intervention. First establish which workload created the demand and whether that demand will continue.

The selected objects are the action’s scope

The batch operations documentation describes managed jobs for object changes. The new dry-run capability previews affected counts and potential errors, with total size reported when filtering by object prefixes. Dry runs can incur object-listing costs. A clean preview is useful evidence about the proposed selection. It cannot decide whether a dataset is still required by another team.

Bind approval to the reviewed object scope and operation, following our bounded-action principle for production automation. Save the selection criteria and review output with the change record. If the dataset or selection changes materially before execution, re-evaluate the scope rather than treating the earlier review as unlimited permission.

For the training example, sample the selected objects with the dataset owner. Check whether active experiments, recovery procedures or retention requirements depend on them. Count and size agreement alone will not reveal a semantically wrong prefix.

A completed job needs a result check

After the approved operation, inspect its reported results and failures before deciding what work remains. Keep follow-up actions scoped to unresolved objects. A partial result should not automatically trigger a fresh operation against the entire original population.

Deletion deserves a different boundary from a reversible metadata correction. If the team cannot establish a usable recovery path, choose preservation or a narrower action until an authorized owner accepts the consequence. Neither an advisor recommendation nor a successful dry run makes lost data recoverable.

The practical first adoption step is one owned finding and one reviewed selection. Measure the change in storage cost or workload behavior that motivated the action, including any side effects. Expanding the batch size is useful only after the team can explain what its previous action actually changed.