A conversation with Ben Whorwood, Principal Architect at Flowmoco
The conversation around enterprise AI is moving quickly.
For many organisations, the question is no longer whether employees should be allowed to experiment with generative AI. AI is beginning to move deeper into the enterprise technology stack: connecting to email, accessing documents, interacting with development environments, querying databases and, increasingly, taking actions on behalf of users.
That shift creates enormous opportunities. It also changes the nature of enterprise technology risk.
Ben has been experimenting seriously with generative AI in development since early 2025. But as an enterprise architect, his starting point has always been slightly different from the "move fast and see what happens" approach often associated with AI development.
Security, isolation and control have been part of the thinking from the beginning. Ben has routinely operated AI development tools inside sandboxes, including restricting network access, precisely because of the increasing reach these tools can have into a developer's environment.
During our conversation, we explored everything from vibe coding and enterprise prototyping to customer data and the changing role of software engineers.
But one observation stood out.
As organisations connect AI to more of their infrastructure, perhaps we need to rethink one of the least fashionable areas of technology:
backup and disaster recovery.
From answering questions to taking action
The first wave of generative AI was relatively contained.
You typed something into a prompt and received something back.
Agents change that model.
Give an AI agent access to your email and it can potentially organise thousands of messages. Connect it to a development environment and it can modify source code. Connect it to a business system and it could potentially update records, create content or initiate workflows.
The attraction is obvious.
The same ability to process thousands of items in seconds is precisely what makes agents powerful. But acceleration works in both directions.
As Ben puts it:
"The acceleration also applies to destruction."
An instruction interpreted incorrectly by a human might result in one record being changed incorrectly.
An automated agent could potentially make the same mistake thousands of times before anybody notices.
That changes the resilience conversation.
Every integration opens another door
Ben uses a useful analogy when thinking about AI integrations.
Every time you enable an integration, you're effectively opening a door.
The question shouldn't only be whether you trust whoever or whatever comes through it. You should also ask:
What happens if the person coming through that door burns the house down?
That sounds dramatic, but it's a useful way of thinking about resilience.
Enterprise security has traditionally invested heavily in preventing unwanted access. Authentication, authorisation, network security and access controls are all designed to stop someone getting through the wrong door.
AI creates an interesting additional problem.
The system causing the damage may have been invited in.
It may be properly authenticated.
It may have legitimate access.
It might simply do the wrong thing incredibly quickly.
This is particularly relevant as organisations move from AI assistants that recommend actions towards agents capable of executing them.
The risk model therefore changes.
We don't just need to ask:
"How do we prevent something going wrong?"
We also need to ask:
"How quickly can we recover when it does?"
Assume something will eventually go wrong
One of Ben's most important observations is that the response may need to be surprisingly straightforward:
Make it possible to undo what happened.
That means better backups, better disaster recovery, greater use of immutable data and the ability to replay or roll back changes. If an AI-enabled process makes a damaging series of changes, the organisation needs a known route back to a good state.
Ben believes current adoption may actually be moving faster than organisations' thinking around recovery and resilience. His expectation is that greater attention may ultimately be driven by a significant incident demonstrating just how quickly an AI-enabled system can make destructive changes.
There is, however, an important architectural detail.
Your recovery mechanism needs to survive the failure you're recovering from.
Real resilience requires independent infrastructure
Ben gives the example of connecting AI tooling to development platforms such as GitHub or GitLab.
If an agent has extensive access to your repositories, simply assuming the repository itself provides your backup may not provide the resilience you think it does.
Instead, Ben suggests asking a more fundamental question:
Are those repositories also being backed up to a location that isn't on that platform?
This is perhaps the most important practical takeaway from our conversation.
Resilience needs independence.
If your production environment, operational data and backups ultimately depend upon the same platform, infrastructure or set of credentials, a sufficiently serious failure could affect both the primary system and the mechanism you expected to use to recover it.
A genuinely resilient architecture introduces separation.
Your day-to-day systems operate within their normal environment, while recoverable copies exist on independent infrastructure.
Depending on the context, that might mean a separate account, separate platform, separate cloud infrastructure, immutable storage or another isolated backup mechanism.
The precise architecture depends on the organisation and the consequences of failure.
The principle is more universal:
The failure of your primary environment shouldn't automatically result in the failure of your ability to recover it.
That has always been good disaster-recovery practice.
AI makes it more urgent because we're dramatically increasing the speed and scale at which authenticated systems can potentially make changes.
AI changes the potential blast radius
This leads to another useful way for enterprise technology leaders to think about AI integrations: blast radius.
If an AI tool only has access to an isolated development sandbox containing synthetic data, the potential consequences of failure are relatively contained.
Give an agent read access to an enterprise document store and the risk profile changes.
Give it write access to source-code repositories, email, customer records or operational systems and it changes again.
The more capable the agent becomes, the more important it is to understand not simply whether the integration is secure, but what the maximum consequence of an incorrect action could be.
And crucially:
Could we recover from it?
The boring infrastructure may become more important
There's an understandable temptation for businesses experimenting with AI
to concentrate investment on the exciting end of the technology.
Models. Agents. Automation. Interfaces. Productivity.
Backup and disaster recovery rarely generate the same enthusiasm.
But as we give AI systems greater agency, some of these established engineering disciplines become more important, not less.
Before enabling another powerful integration, enterprise teams should be asking:
What information will this integration expose?
What can the agent actually change?
What's the potential blast radius if it gets something wrong?
Can those changes be reversed?
How quickly could we recover?
When did we last test that recovery process?
Does our recovery infrastructure sit independently of the system we're protecting?
The last question may prove particularly important.
Because a backup that disappears with the system it is supposed to protect isn't much of a backup.
Use AI to move faster. Engineer for when it goes wrong.
None of this is an argument against enterprise AI.
Quite the opposite.
AI gives organisations an extraordinary opportunity to explore ideas, automate processes, prototype new systems and rethink how software is built.
At Flowmoco, our view is that AI can help organisations discover the right thing to build. Experienced engineers then help them build it properly.
And building properly includes thinking about the day when something doesn't behave as expected.
Security isn't only about keeping people and systems out. Increasingly, it is also about controlling what happens after we deliberately let them in.
As Ben's analogy reminds us, every AI integration opens another door.
The question for enterprise technology leaders isn't simply whether they are comfortable opening it.
It's whether they know what they'll do if something comes through that door and burns the house down.
Continue the conversation with Ben
This is an evolving area of enterprise architecture, and different organisations will have very different risk profiles, legacy estates, regulatory requirements and approaches to resilience.
If this article has prompted you to think differently about your own AI integrations, backup architecture or disaster-recovery strategy, get in touch with Ben Whorwood, Principal Architect at Flowmoco.
Ben would be interested to hear how other technology leaders are approaching the problem, compare perspectives, or talk through the implications within your own enterprise context.
Sometimes the most valuable conversation isn't simply about what AI could enable you to build next.
It's about making sure you can recover it when something goes wrong.