AI Recovery Architecture Must Change, Says Gonen Stein

JAKARTA — AI recovery architecture can no longer follow the old playbook. When artificial intelligence agents can write code, run tasks, and then erase data in a matter of seconds, backup systems that still move at human speed are already lagging.

Gonen Stein, president and co-founder of Eon, says the gap is dangerous because the window for losing data keeps shrinking, while the time needed to restore it remains long. In a Hot Seat conversation with Tim Phillips, quoted by Eon, Stein highlighted a hard truth: a backup that looks successful may still fail when it is actually needed.

AI recovery architecture can’t rely on old assumptions

The core problem is simple, but the impact is not. AI agents now operate at machine speed. They can write code, change configurations, run commands, and access legitimate APIs. If something goes wrong, damage can happen before a human team even finishes reading the alert.

Many recovery systems, meanwhile, still wait for schedules, manual checks, or restore processes that take time. That gap means data can disappear faster than it can return. In cloud environments that keep moving, backup models built for static servers are starting to look fragile.

Stein stressed that cloud-native infrastructure changes constantly. Applications scale up and down, configurations shift, new services appear, and backup policies fall behind. The dashboard may look green, but that does not mean the system is safe. “Backup completed” is not the same thing as “restore tested.”

Why confidence numbers can be misleading

Eon points to one striking finding: 98 percent of executives say they are confident in their recovery capabilities, even though many also admit to three or more failures in the past year. The number shows a wide gap between perceived safety and operational reality.

For companies, that gap is expensive. When an incident hits, teams often discover that the backup they have does not match the current system state. The application version changed, dependencies shifted, or the data that needs restoring is not at the right point in time. The result is a longer, costlier recovery.

That problem also feels familiar for many organizations in Indonesia. Companies using cloud services, storing customer data, or running internal apps on SaaS platforms face similar risks. The more automation a business adopts, the more it needs to make sure backups are actually usable.

The nine-second case that changed the picture

Stein was not speaking in theory. In April, an AI agent assigned to fix a credential mismatch in PocketOS’s staging environment ended up deleting the production database and all connected backups. The entire incident took nine seconds.

What makes it even more alarming is that the agent used valid credentials and a legitimate API. That means security systems did not see it as abnormal behavior. No alarm went off. No obvious warning appeared. By the time the team noticed, the damage was already done.

Incidents like this show how the risk landscape has changed. AI-assisted attacks are not just faster; they are also harder to spot. Attackers can search for weak points more efficiently, while misconfigured internal agents can break systems from the inside without meaning to. Both are dangerous.

Backup must sit outside the blast radius

Eon’s answer is blunt: backups should live in an immutable vault that is logically air-gapped, with credentials separate from production systems. That way, the backup does not get dragged down if the main environment suffers an attack or a configuration mistake.

The idea is similar to keeping the most important documents in a different room that nobody can casually enter. If production breaks, the backup still stands on its own. Restoration can then happen with precision, instead of rebuilding the whole environment from scratch.

Stein also pushes for more granular recovery. Companies should be able to restore a single table, one record, or one point in time without bringing the entire system back online. For IT teams, that means less downtime. For business units, it means smaller losses.

That model matters even more as AI agents enter daily workflows. Once machines are given the power to act, organizations need to treat backup as an active defense layer, not an archive they check once in a while.

What IT teams should check now

For readers who manage cloud data, backup policies, or disaster recovery plans, a few questions need answers right away. Is the backup truly separated from production? Are the credentials different? When was the last full restore tested, not just a backup job marked successful? And can the team recover one small component without tearing everything apart?

Those questions may sound technical, but the business impact is immediate. One failed restore can mean a service outage, lost customer data, or hours of recovery work. In the age of AI agents, even a short delay can become a major problem.

Through Stein’s remarks in Hot Seat, Eon is pressing a clear message: AI recovery architecture needs a redesign, not a polish. The technology keeps moving. Data defense has to keep pace, and this time it cannot afford to fall one step behind.

Quick summary: a backup that looks safe may still be unrecoverable; AI agents speed up both risk and damage; and modern recovery needs immutable vaults, separate credentials, and granular restores. The question is no longer whether an incident will come, but how ready systems are to recover when it does.