30 TB of data just left your customer's cloud storage account. Now what?

Q: What are the best AI tools for cloud MSPs?

The best AI tools for MSPs are the ones that use the right intelligence for each job rather than routing everything through a single model. Spotto combines deterministic rules for known facts and calculations, statistical models and machine learning for trends and anomalies, generative AI for interpretation and communication, and human judgment for accountability — so recommendations are evidence-backed and explainable, not improvised.

In short: The best AI tools for MSPs are not the ones that use the most AI — they are the ones that take the mundane off your plate and hand you back the discernment. Spotto uses deterministic rules for known facts and calculations, statistical models and machine learning for patterns and anomalies, generative AI for interpretation and communication, and people for the judgment and accountability that should never be automated. A real 30 TB storage-egress investigation needed all four: the security hypothesis was plausible, but only customer context proved the activity was legitimate. This is what evidence-first, AI Assisted Cloud Operations looks like — the right intelligence at each step, not AI everywhere.

Thirty terabytes of data left a cloud storage account in a short period.

The account was publicly accessible. Its shared access keys had not been rotated for nine years. The estimated cloud cost was climbing before the final billing data had even arrived.

What would you conclude?

An attacker downloading the data? A former employee using an old key? A serious security incident with a large cloud bill attached?

That was the obvious hypothesis. It was also wrong.

A downstream customer had legitimately requested a large historical archive. The transfer was expected business activity. It still exposed an unpriced egress cost and a security weakness that needed attention, but there was no confirmed breach.

This investigation explains one of the most important decisions we made when building Spotto.ai: an AI product should not use AI for everything.

An autonomous agent told to "fix the anomaly" could have blocked legitimate access, rotated a key without understanding its dependencies, or confidently written an incident report for an incident that had not occurred. A rules engine could identify the key age and public exposure, but it could not know why the data moved. A human alone might not have found the event until the provider bill arrived.

The right answer required four kinds of intelligence working together:

Intelligence	Best used for	Role in Spotto
Rules and code	Known facts, calculations, constraints, and repeatable checks	Find technically valid opportunities consistently across every customer environment
Statistics and machine learning	Trends, forecasts, shifts, and patterns that cannot be expressed well as fixed thresholds	Detect unusual behaviour and predict what may happen next
Generative AI	Interpretation, synthesis, investigation, and natural-language communication	Bring evidence together, explore trade-offs, and help turn findings into a plan
People	Context, judgment, ethics, accountability, and customer decisions	Decide what the evidence means for this customer and own the outcome

This is not a maturity ladder where rules are primitive and agents are advanced. Each is good at a different job. The 30 TB investigation needed all four.

What are the best AI tools for MSPs?

The best AI tools for MSPs are the ones that take the mundane off your plate and hand you back the discernment. They automate the work machines do well — scanning every customer estate, applying the same checks consistently, joining configuration, pricing, billing and metrics evidence, and drafting the first explanation — and they deliberately return the judgment to your people: what the evidence means for this customer, which trade-off is acceptable, and who owns the decision.

Measured that way, the best tool is not the one that automates the most. It is the one that removes the repetitive discovery and formatting work while keeping a human accountable for the call. The 30 TB investigation below shows why that boundary matters — and why an AI product should be judged on the discernment it hands back, not the autonomy it takes away.

Why the discernment has to stay with you

Because you know the customer, and the model never will.

Spotto gets you most of the way — it finds the work, prices it, and drafts the explanation. But the last, decisive step depends on context that lives in your relationship, not in their telemetry. What did they actually ask for last time you spoke? What are they trying to do this year? Do they have the appetite for a $10,000 rebuild, or a $1,000 fix that buys them time? The evidence cannot answer those. You can.

Take one finding: an app service running well under capacity. Spotto surfaces it — but "underutilised" has three right answers, and only you know which. If it is genuinely idle, delete it. If it ticks along at a low steady load, downsize it. If you know they are putting a new product on it next quarter, reserve the capacity now and save them money on growth they have not had yet. Same data, three different calls — and the difference is entirely the future you can see because you know where their business is heading.

It is the same reason we do not let Spotto act on an anomaly by itself. The 30 TB transfer above looked like a breach; automating a block would have cut off a legitimate customer doing legitimate work. Only the person who knew the relationship could tell an incident from a Tuesday.

This is where the best MSPs pull ahead. They do not wait to be asked. They walk into the review already knowing the customer's secure score is 32%, already holding a prioritised plan and a twelve-month roadmap to get it to 80 — a step ahead of the customer's own thinking. That is what generates continuous work: not the AI, but the relationship the AI lets you get in front of sooner. Spotto exists to accelerate that relationship — to hand you the evidence and the time, so your judgment is the thing the customer pays for.

What Spotto knew - and what it could not know

An MSP using Spotto was reviewing one of its customer environments when the platform surfaced the sharp increase in cloud-storage egress.

This particular environment was running in Azure, which gave the investigation Azure-specific billing, metrics, pricing, and configuration evidence. The decision problem, however, was not unique to Azure. The same questions apply when an unusual transfer appears in Amazon S3 or another public-cloud storage service: what happened, what will it cost, is it authorized, and who has enough context to decide what to do?

There was an immediate timing problem. Azure cost data is not real-time. Microsoft says cost and usage data is typically available within 24 hours for Enterprise Agreement, while pay-as-you-go data can take up to 72 hours. Waiting for the final bill would mean discovering the cost after the transfer had already occurred.

Spotto used current resource and telemetry evidence, recent rates, and pricing data to estimate the emerging cost while billing-backed detail was still catching up. The estimate was labelled as an estimate; Azure billing remained the financial source of truth. Its job was to provide an early warning, not impersonate an invoice.

That warning answered the first question:

Something materially different is happening. Where is it coming from?

The Cost Tree made it possible to move from the overall increase to the service, meter, and storage account responsible. Statistical anomaly detection helped establish that the change was unusual relative to the environment's history.

The configuration evidence then introduced a second concern. The storage account was publicly accessible, and its shared access keys had not been rotated for nine years.

At that point, the evidence justified an urgent question:

Has an attacker, a former employee, or someone holding an old key downloaded the data?

Only the customer conversation could supply the missing fact: a downstream customer had requested and legitimately downloaded the archive.

That did not make the investigation a false alarm. It revealed two valuable issues:

The commercial issue: the customer had provided a data-retrieval service without fully appreciating the egress cost. They could now decide whether archive retrieval should be priced, structured, cached, staged, or billed differently.
The security issue: nine-year-old shared keys and public access still created avoidable exposure. Microsoft recommends using Microsoft Entra ID and managed identities where possible, limiting Shared Key use, and rotating access keys regularly when keys remain necessary.

No single technology could have reached that outcome safely.

Metrics and cost estimation provided speed.
Statistical models identified an abnormal pattern.
Deterministic checks identified the security posture and key age.
Generative AI could help connect the evidence, retrieve current guidance, explore response options, and draft a customer explanation.
A human spoke with the customer, disproved the breach hypothesis, understood the business event, and agreed on the next steps.

The correct outcome required evidence first, judgment last.

Rules are not less intelligent when the answer is already known

Spotto's Cloud Engine contains deterministic recommendation logic. It gathers cloud configuration, inventory, relationships, pricing, billing, and metrics, then applies repeatable checks.

For one Azure example, if an App Service Plan is running on Premium v2, Spotto can identify it as a modernization candidate. Premium v2 can be more expensive and less capable than an appropriate newer generation, and it is not eligible for the same reservation options as Premium v3. The rule can be tested:

IF the resource is a Premium v2 App Service Plan
THEN surface a Premium v3 or newer modernization investigation

The exact destination is not guessed. Region availability, workload requirements, current utilization, feature compatibility, pricing, and migration risk still need to be checked. As explored in How Can Azure Be Faster and Cheaper?, a newer service generation can improve both cost and performance, but it is a candidate for validation rather than a universal migration instruction.

Other deterministic checks can answer questions such as:

Is this resource running an outdated or retiring SKU?
Does this paid App Service Plan contain no applications?
Has a storage access key exceeded the configured rotation period?
Is public access enabled where a safer access model is available?
Is a resource unattached or showing no meaningful activity over the observation window?
Does a proposed SKU exist in the required region and preserve the necessary capabilities?
What is the current retail price for this region, SKU, operating system, and billing model?

These checks are fast, consistent, interpretable, and inexpensive to run. They can be tested against known inputs and expected outputs. If the same condition exists in 500 customer subscriptions, the same rule can assess all 500 without asking 500 engineers to rediscover it.

This is where traditional software is better than an LLM. A model should not improvise whether a SKU exists in a region, perform approximate arithmetic on a price table, or reinterpret a security control differently on each run. Those facts belong in code, structured data, provider APIs, and deterministic calculations.

A valid recommendation is not always the right decision

A rules engine can prove a technical condition. It cannot automatically know the customer's intent.

Consider an App Service Plan with little or no observed traffic. Several recommendations may be valid:

Delete it if the workload has been abandoned.
Downsize it if the workload is real but currently small or not yet launched.
Reserve it if the customer expects to run it at a stable size for the next one or three years.

Those options can appear contradictory. They are actually different paths through the same decision.

Why is utilization low?
├─ The service is no longer required
│  └─ Validate dependencies, then remove it.
├─ The service is required but lightly used
│  └─ Downsize it and retain suitable headroom.
└─ The service is about to receive sustained demand
   └─ Keep or resize it, then evaluate a commitment.

Spotto can link related recommendations and show safe alternatives and trade-off alternatives. It can also prevent mutually exclusive savings from being added together as if the customer could delete, downsize, and reserve the same resource simultaneously.

The human still needs to ask why the resource exists.

Perhaps it is a disaster-recovery component. Perhaps a launch was delayed. Perhaps the customer is decommissioning the whole application in three months, so an otherwise sensible operating-system upgrade would create more migration risk than value. Perhaps the recommendation improves security but introduces a cost the customer cannot currently fund.

In Spotto, the team can prioritise or dismiss a recommendation, capture the reason, add comments, and optionally set a time window so "not now" does not silently become "never." The next engineer can see the context instead of asking the customer the same question again.

The machine makes the decision manageable. It does not pretend the business context does not exist.

Where deterministic rules stop working

Suppose we created this cost rule:

IF daily cloud spend increases by more than $1,000
THEN raise an anomaly

For a small customer, a $1,000 increase may be extraordinary. For a large customer, it may be an ordinary Tuesday. A fixed percentage is not much better when costs are seasonal, a workload runs at month end, or a new service is growing deliberately.

Cloud behaviour changes. There are weekly cycles, release events, school holidays, financial reporting periods, campaigns, new customers, credits, refunds, and services that move from idle to busy. Encoding every permutation as an if statement would produce a brittle collection of thresholds and false positives.

This is where statistics and machine learning become useful.

Spotto's Azure Metrics and Billing Analyzer currently uses an ensemble of methods for cost anomaly detection. These include z-score analysis, rolling-spike detection, step-change detection, exponentially weighted drift, month-to-date trajectory, seasonal decomposition, forecast residuals, Isolation Forest, and Spotto heuristics. An anomaly is surfaced when multiple methods agree rather than allowing one sensitive detector to declare a crisis by itself.

Different methods catch different behaviours:

A rolling baseline can detect a sudden spike.
Step-change detection can identify a new sustained level.
Seasonal modelling can distinguish an unusual day from a normal weekly cycle.
Drift detection can find a slow increase that never creates one dramatic spike.
Forecast residuals can identify behaviour that no longer fits the expected trend.
Isolation Forest can find unusual combinations of cost and calendar features.

Spotto also produces cost forecasts and maps anomalies back to the services and resources that drove the change.

The output is probabilistic. It says, in effect:

This pattern is sufficiently unlike the established behaviour to deserve investigation.

It does not say:

We know why this happened, who approved it, or whether it is bad.

The models found the 30 TB event. They could not know that a customer had requested an archive.

Where generative AI earns its place

Once Spotto has gathered trustworthy facts and identified the pattern, the problem changes. The question is no longer only, "What condition is true?" It becomes:

What is the most likely explanation?
Which evidence supports or weakens each hypothesis?
What should we investigate next?
How do cost, security, reliability, performance, and operations affect one another?
What does the cloud provider's current guidance say?
How should we explain this to the customer?
What are the safe options, and what are their trade-offs?

Those are good generative-AI questions.

Spotto Chat can start from the page the engineer is viewing, retrieve authorized Spotto evidence, look up current official provider documentation and pricing context, and support deeper investigations using specialist cost, security, performance, reliability, and operations perspectives. In Spotto's current Azure workflow, those external lookups use official Microsoft sources. The same evidence-first pattern can extend to other cloud providers without changing which decisions belong to rules, models, GenAI, or people.

That does not mean sending millions of billing rows, thousands of metrics, every resource configuration, and an entire cloud price catalogue to an LLM and hoping it gets the maths right.

Spotto uses tools and bounded retrieval to give the model the evidence it needs:

Raw cloud data
  -> deterministic collection, normalization, and calculation
  -> statistical analysis and anomaly detection
  -> scoped retrieval of relevant evidence
  -> generative-AI interpretation and synthesis
  -> human review and customer decision

Calculators calculate. Pricing services return prices. Statistical models analyse time series. The LLM interprets the selected evidence and communicates the result.

That division makes GenAI particularly useful for:

Explaining a complex recommendation in plain language.
Comparing several technically valid options.
Preparing questions for a customer investigation.
Drafting an executive summary from validated findings.
Turning recommendations into the first version of a statement of work.
Relating a technical issue to the customer's strategy, risk appetite, compliance goals, or budget.
Looking up current provider documentation when service behaviour may have changed.

It is also where GenAI's limitations are acceptable. Wording can vary between runs. An investigation may need another question. A first draft may require correction. Those are manageable when the underlying facts, calculations, access controls, and approvals remain outside the model.

The customer context cannot live only in one engineer's head

Human judgment is essential, but humans are expensive, slow, and difficult to scale. An MSP cannot ask its most experienced architect to inspect every metric, price, recommendation, backup result, and security setting across every customer every day.

There is another human limitation: context often stays with one person.

The primary engineer may know that a legacy server is being retired in three months. A secondary engineer covering leave may see an urgent vulnerability and unknowingly restart a conversation the customer already had. A FinOps specialist may recommend a commitment without knowing that the product is being sold. A security specialist may propose a control without knowing the approved budget.

Spotto Notes and recommendation comments let the team record customer objectives, constraints, decisions, known exceptions, roadmap timing, security posture, FinOps preferences, and compliance requirements. That context can support both other people and Spotto Chat.

This creates a useful loop:

Spotto finds and measures a condition.
A person validates it with the customer.
The team records the reason and decision.
Future investigations use that context.
A time-bound exception returns for review instead of disappearing.

Human judgment becomes reusable without pretending it can be fully automated.

Some decisions are ethical before they are technical

In another architecture review, we looked at an education platform that allowed teachers to upload photos and videos for parents. Its public privacy policy said the data would remain in a particular region.

The team had good intentions. The deployed architecture did not match the promise.

The content was being distributed through a global content delivery configuration without the access restrictions the policy implied. A resource inventory could show the CDN. A relationship graph could show the data path. A security rule could identify public exposure. Generative AI could summarize the mismatch and propose technical alternatives.

But the material conclusion required a person to compare what the organization had promised with what its system actually did.

That is a question of customer trust, privacy, accountability, and ethics - not merely whether the architecture is cost effective or performs well. A human needed to explain the implication, understand the constraints, and agree on a remediation plan with the customer.

The same is true for high-risk security changes, major financial commitments, destructive cleanup, and architectural migrations. Spotto can surface the evidence, make alternatives understandable, and support an approved action. Accountability remains with the people responsible for the environment and the customer relationship.

What this means for an MSP

The goal is not to remove cloud engineers, service delivery managers, security specialists, FinOps practitioners, or solution architects from managed cloud operations.

It is to stop using those people as an expensive rules engine.

Spotto handles the work machines are good at:

Continuously scanning across customer estates.
Applying the same known checks consistently.
Joining configuration, pricing, billing, metrics, licensing, commitments, and architecture evidence.
Watching trends and finding abnormal behaviour.
Ranking and grouping recommendations so the team is not handed a thousand-row export.
Retrieving supporting evidence and drafting customer-ready explanations.
Preserving the decision trail for the next review and the next engineer.

The MSP's people handle the work people are good at:

Understanding why the customer built the environment this way.
Resolving incomplete or conflicting evidence.
Balancing cost, risk, performance, reliability, compliance, and effort.
Applying ethics and customer promises.
Building trust and gaining approval.
Owning the final decision and its outcome.

That is a more valuable human role, not a smaller one.

The most AI is not the best AI

Spotto.ai does not use one kind of intelligence for every problem.

We use deterministic rules when the logic is known and precision matters. We use statistical models and machine learning when behaviour must be learned from history. We use generative AI when evidence needs interpretation, synthesis, or communication. We keep people in the loop when context, accountability, ethics, and customer judgment decide the outcome.

The 30 TB egress investigation needed all four.

A cost estimate created speed. Anomaly models found the unusual pattern. Rules identified security concerns. GenAI supported the investigation and response. A human discovered the legitimate business reason and turned the event into a cost, security, and customer-value improvement plan.

That is what AI Assisted Cloud Operations should look like: not AI everywhere, but the right intelligence at each step.

Common questions

What are the best AI tools for cloud MSPs?

The best AI tools for MSPs are the ones that use the right intelligence for each job rather than routing everything through a single model. Spotto combines deterministic rules for known facts and calculations, statistical models and machine learning for trends and anomalies, generative AI for interpretation and communication, and human judgment for accountability — so recommendations are evidence-backed and explainable, not improvised.

What are the leading AI assistants for Azure-focused MSPs?

An AI assistant for Azure-focused MSPs should start from trustworthy, scoped evidence — configuration, metrics, billing, pricing and commitments — rather than asking a model to reason over a raw cloud estate. Spotto Chat works from the page an engineer is viewing, retrieves authorised Spotto evidence and current Microsoft documentation, and supports cost, security, reliability, performance and operations investigations while keeping calculations and pricing in deterministic code.

Is Spotto really an AI product if many recommendations come from rules?

Yes. AI is part of a wider decision system. Using deterministic logic for facts and calculations makes the AI layer more useful because it receives better evidence and has less room to invent an answer.

Does Spotto automatically implement recommendations?

Only supported actions can be implemented or scheduled, and they remain permission- and approval-controlled. Destructive, high-risk, or context-dependent changes still require appropriate validation, change management, testing, monitoring, and rollback planning.

Why not let an agent analyse the entire cloud environment directly?

Cloud estates contain too much structured data for a reliable one-prompt answer: configurations, relationships, price catalogues, metrics, billing rows, commitments, and policies. Spotto first collects, calculates, filters, and analyses that data, then gives the AI layer bounded evidence relevant to the question.

Does anomaly detection prove that something is wrong?

No. It identifies behaviour that differs from the expected pattern. The change may be waste, an incident, business growth, a planned deployment, or legitimate customer activity. The value is finding it early and making the investigation faster.

Does keeping a human in the loop prevent automation?

No. It places automation where it is safe and valuable. Spotto can automate continuous discovery, analysis, evidence gathering, workflow, and supported approved actions while keeping material customer decisions accountable to a person.

What to do next

Choose one customer environment and review three different kinds of Spotto evidence:

A deterministic recommendation where the condition is clearly true.
A trend or anomaly that needs an explanation.
A recommendation with two or more valid response options.

For each one, ask:

Which facts can Spotto prove?
Which parts are estimates or probabilities?
What context is missing?
Which trade-offs need a customer decision?
What should be recorded so another engineer does not have to rediscover it?

That exercise reveals the real value of an AI-assisted operating model. The platform handles scale and complexity. The MSP brings judgment, trust, and accountability.

Try Spotto with one customer environment and see what the right combination of rules, models, AI, and people can uncover.

About Spotto

Spotto is the AI Assisted Cloud Operations platform for MSPs — it turns cloud operations into revenue intelligence: the billable work, validated savings, and hidden risk in every customer tenant, with the evidence to action it. Spotto currently analyzes Azure inventory, telemetry, cost, pricing, licensing, commitments, security posture, and architecture signals to identify and explain customer-value opportunities. Its decision model—deterministic evidence, statistical analysis, generative-AI assistance, and human accountability—is designed for cloud operations rather than one provider's vocabulary.

Spotto combines deterministic cloud analysis, statistical models, machine learning, generative AI, and human-controlled workflows so MSPs can find, validate, communicate, and deliver improvements across cost, security, performance, reliability, and operations.

Summary

Spotto uses rules for known logic, statistics and machine learning for patterns, generative AI for interpretation and synthesis, and people for judgment and accountability.
A real 30 TB storage egress spike showed why all four are necessary: the security hypothesis was plausible, but customer context proved the activity was legitimate.
Deterministic recommendations are repeatable and explainable, but they are evidence-backed candidates rather than universal business decisions.
Statistical models find spikes, drift, step changes, seasonal deviations, and forecast variance that fixed thresholds miss.
Spotto Chat uses scoped evidence, current documentation, pricing tools, and specialist analysis instead of asking an LLM to calculate over an entire raw cloud estate.
Human context can be captured in Notes, comments, dismissal reasons, and review windows so it remains useful across the MSP team.
The best AI system is not the one that uses the most AI. It is the one that uses the appropriate intelligence for each decision.