Highlights from Spicy Bytes with HYCU: SaaS, the Data Estate, and AI Integrity

In an ideal world, you know how well your data protection strategy works ahead of time by testing practices that are scheduled, controlled, and repeatable. The kind of validation you do on purpose, not in a panic.

In reality, most organizations don’t test recoveries often enough. So restore day becomes the first time you learn what comes back cleanly, how long it takes, and what it costs. Limited or no testing puts a lot of pressure on the unknown. Assumptions about your recovery process can be costly when something breaks, someone deletes the wrong thing, or an incident forces you to prove you can get back to a known-good state.

Dashboards can look confident right up until you need receipts. And when your data is spread across on-prem, cloud, and hundreds of SaaS apps, “we’re fully covered” is often more belief than verified outcome.

That gap is what we delve into on a recent episode of Spicy Bytes, a Wasabi original series filmed at Boston’s historic Fenway Park, where the industry takes are hot and the wings get hotter with each question. In this episode, we sat down with HYCU’s Andy Fernandez to discuss SaaS blind spots, the modern data estate, why testing is skipped, and why AI turns data integrity into a hard requirement.

You can catch the full episode on Wasabi TV. In the meantime, here are a few highlights from the conversation. Let’s start with an assumption that causes real damage because it sounds reasonable: that SaaS includes data protection by default.

SaaS and shared responsibility

SaaS (software as a service) didn’t become popular by accident. It’s the collision of two incentives that make perfect sense: software vendors moving from license and maintenance to subscription revenue, and customers wanting out of the data center investment and upkeep business.

But while SaaS changes who operates the platform, it doesn’t change who’s accountable when data is deleted, corrupted, or unavailable. SaaS still follows the shared responsibility model. In simplest terms, it breaks down like this:

• Security “in” the cloud (customer-owned): identity and access, data policies, immutability, and the operational practices that determine how data is protected and managed

• Security “of” the cloud (provider-owned): the underlying platform, infrastructure, facilities, and operations that run the service

This took me straight back to the early Microsoft 365 days, when we had to reinforce the point constantly. Microsoft secured and operated the underlying infrastructure, but customers were still accountable for protecting their data from deletion, misconfiguration, insider risk, and other forms of loss.

The same dynamic applies across today’s SaaS landscape. The vendor runs the service, but it’s still your data, and you’re still accountable for making sure it can be restored when something goes wrong.

Now scale that responsibility across hundreds of applications owned by different teams. That’s where the data estate problem shows up.

The data estate visibility gap

It used to be relatively easy to know where your data lived and put the right people, policies, and processes in place to protect it. Today, your data estate is spread everywhere, across countless applications and services.

To make it even more complicated, a lot of those tools are owned and managed by individual departments. Sales and Marketing have their stack. So do Finance, Dev, and Ops. IT often doesn’t have full visibility into what’s in use, where data resides, or whether it’s properly protected.

But when something goes wrong, IT is still accountable for protecting data and restoring operations.

To regain control, organizations need a complete, unified view of the data estate, one that makes it possible to identify every application by department, understand where the data is stored, and verify that protection is actually in place.

Once you’re dealing with a distributed data estate, the next challenge isn’t just coverage; it’s trust. AI raises the cost of getting that wrong.

AI makes data integrity non-negotiable

The uptick in AI-powered solutions is changing data protection in three big ways:

• Vendors are increasingly using AI to improve efficiency and outcomes

• AI generates and depends on massive amounts of data that must be protected

• Attackers are using AI to get more effective, especially in phishing and social engineering

But underneath all of that is a simpler point from the episode: the most important determinant of AI success is data integrity.

If your data is inaccurate, unavailable, corrupted, or lost, model quality suffers. AI doesn’t clean up messy inputs. It scales the consequences of them.

That’s why protecting AI is not just about backing up a model. Organizations are building AI on data pipelines, vector databases, and platforms like BigQuery, Databricks, and Snowflake. Protecting AI workloads means protecting the foundational data and the systems AI depends on, including the upstream sources feeding those platforms, such as SaaS applications.

The fundamentals still matter. If the underlying data isn’t protected, AI performance degrades. As AI-driven automation expands, mistakes can scale faster; misconfigurations and unintended actions can turn into data loss events at machine speed.

What good looks like

When AI raises the bar, good protection stops being a feature discussion and becomes an outcomes discussion. The goal: make restore day boring.

In practice, that comes down to a few fundamentals we dig into in the episode: keeping an independent copy that isn’t tied to the same SaaS platform you’re trying to restore, running restore tests often enough that your confidence is earned, and maintaining visibility across the data estate so you can verify what’s protected and what isn’t.

From there, we get into the practical friction points that derail good intentions: why restore testing gets skipped in the real world, how cloud fee models can turn validation into a penalty, and why SaaS restores have to be precise and application-aware.

It’s the difference between a backup strategy that looks good on paper and one that holds up when you actually need it.

The bottom line

Most teams don’t lose data because they didn’t care. They lose it because they assumed a dashboard meant proof, and didn’t test restores until an incident forced the issue. With SaaS sprawl, a distributed data estate, and AI raising the stakes on integrity, that’s a risky place to be.

The good news is that this is fixable. Teams don't need perfect visibility or a massive overhaul to get started. They need a more honest view of what is protected, what is restorable, and what still needs work. That kind of clarity makes every other investment in resilience, recovery, and AI more credible.