A conversation with Ben Whorwood, Senior Architect at FlowMoCo
For boards, one of the most important questions about AI may not be whether the technology works.
It is whether AI can make the organisation's data more valuable.
Most enterprises have spent years accumulating information that competitors cannot easily reproduce: customer interactions, transaction histories, operational data, pricing decisions, service records, product performance, documents, processes and deep domain knowledge.
AI potentially gives organisations completely new ways to interrogate, combine and act upon that information. That creates an opportunity for competitive advantage.
But it also creates risk.
We recently sat down with Ben Whorwood, Senior Architect at FlowMoCo, to discuss this tension and, in particular, how enterprises can take advantage of AI without automatically giving AI systems unrestricted access to the valuable data underneath the opportunity.
One of Ben's observations provides a useful starting point:
The AI doesn't always need your data. Sometimes it just needs to understand the shape of your data.
That sounds like an architectural detail. It is actually part of a much bigger board-level conversation about competitive advantage, risk and control.
The board's quest should be competitive advantage
There is a danger that board conversations about AI become dominated by risk. What information could be exposed? Which tools can employees use? Where is data processed? What regulations apply? What controls do we need?
All are legitimate questions. But they shouldn't become the purpose of the conversation.
The board's real quest should be: how can we combine AI, our proprietary data and our domain expertise to create an advantage our competitors cannot easily reproduce?
Access to an AI model alone is unlikely to provide much differentiation. Your competitors can access similar models. They can buy similar copilots and experiment with similar AI tools. What they don't necessarily have is your data.
Years of operating a business create information and organisational knowledge that may become significantly more valuable when AI gives us new ways to use it. That could mean better decisions, new products, more personalised customer experiences, faster operations, better predictions or entirely new ways of delivering the organisation's expertise.
The strategic question therefore isn't simply:
"What can AI do?"
It's:
"What could AI enable us to do with what we uniquely know?"
But the pressure to move is considerable
Boards are having to answer that question while AI itself is changing extraordinarily quickly.
Pressure is coming from inside the organisation. Employees are experimenting. Development teams are adopting AI coding tools. Business functions want productivity gains. People may already be putting company information into AI systems before formal policies have caught up.
Then there is external pressure. What are our competitors doing?
Move too quickly and the organisation may accept risks it doesn't properly understand. Move too slowly and competitors may learn faster, operate more efficiently and find opportunities in their data first.
The board is therefore trying to govern a moving target.
A control framework created six months ago may not reflect what today's tools can do. A tool originally approved for generating text can acquire memory, integrations and agentic capabilities. A coding assistant can move from suggesting code towards modifying repositories and executing actions.
The risk boundary can move without the board consciously deciding to move it.
Boards have been here before
There is something familiar about this.
Think back to the transition to mobile-first. Employees wanted smartphones. Customers wanted apps. Information previously accessed from controlled corporate environments suddenly needed to be available from devices carried around in people's pockets.
Boards and technology teams had to find their way through device management, authentication, application security, remote access and customer privacy. There were bumps along the road.
Then came cloud computing. For organisations accustomed to directly controlling infrastructure, putting applications and data onto infrastructure operated by somebody else created another wave of uncomfortable questions.
Where is our data? Who can access it? What happens if the provider fails? What stays on-premise? What moves?
Again, enterprises learned as they went. Over time, each organisation found its own equilibrium between risk, reward and control.
AI feels similar. But the learning curve feels steeper and the potential impact greater.
Mobile changed access. Cloud changed infrastructure. AI changes agency.
AI systems increasingly don't just store or display information. They can interpret it, combine it, generate something new and potentially act on the result. And unlike a cloud migration, AI adoption can start with somebody opening a browser.
That combination of accessibility, speed and agency makes keeping governance aligned with adoption particularly difficult.
Your data may become part of your moat
This makes protecting enterprise data important for another reason.
Sensitive data clearly needs protection because of privacy, regulatory and contractual obligations. But proprietary data may also increasingly form part of an organisation's competitive moat.
If AI can amplify the value contained within your accumulated information and organisational knowledge, exposing it indiscriminately isn't simply a compliance issue. It can become a competitive-strategy issue.
The answer isn't to lock everything away. That might protect the asset while preventing the organisation from extracting its value.
The challenge is more sophisticated: how do we make our data work harder without unnecessarily giving it away?
This is where Ben's "schema, not secrets" idea becomes particularly useful.
Does the AI actually need your data?
Imagine you're building a new application around customer records containing:
- First name
- Surname
- Address
- Account number
- Account status
An AI model helping an engineering team build the interface needs to know those fields exist. It may need to understand their types and relationships. But does it need a real customer's name, home address and account number?
Often, it doesn't.
Ben describes giving the AI the schema — the structure or metadata describing the records — rather than the actual customer information. The AI can then work with synthetic records. It understands the shape of the problem without being given the secret.
Real customer information can subsequently be introduced within the organisation's controlled environment.
That leads to an important architectural principle: start with the business outcome, then expose the minimum information necessary to achieve it.
Design-time AI isn't necessarily runtime AI
There's another useful distinction.
Using AI to build something doesn't necessarily mean AI needs permanent access to the data the finished system will process.
AI can help prototype an interface, generate integration code or explore a workflow using schemas and synthetic information. The production application can then operate against real customer information inside established security boundaries.
For boards, these distinctions matter. Using AI to prototype against synthetic data is one risk profile. Giving AI read access to ten million customer records is another. Giving an autonomous agent permission to change those records is another again.
"Are we using AI?" is therefore becoming almost meaningless as a governance question.
Boards need to understand how it is being used, against what information, with what agency and to create what value.
When the real data is the value
Of course, synthetic data isn't always enough. Sometimes the opportunity exists precisely because of what is contained within the real dataset.
Healthcare provides an obvious example.
Researchers may want to identify patients who could benefit from a clinical trial. Knowing that a database contains fields for age, diagnosis and treatment isn't sufficient. The value comes from interrogating the underlying information.
Even then, exposing all of that information isn't necessarily inevitable. Technologies such as homomorphic encryption are interesting because they explore the possibility of performing useful computation against encrypted information. Work by Sebastian Kot and London Quantum Group provides an example of the broader privacy-preserving approach in practice.
Imagine a research organisation asking: "How many patients meet these criteria?"
It needs the answer. It doesn't necessarily need the names, addresses and complete medical records of everyone used to derive it.
That is essentially the same architectural philosophy taken further: extract the value while minimising exposure of the underlying asset.
Think of data access as a spectrum
Rather than making a binary decision between giving AI access to customer data or not using AI, boards can think about progressively greater levels of exposure:
No customer data → Schema → Synthetic data → Privacy-preserving computation → Controlled access to real data.
The organisation should move along that spectrum only as far as the business outcome requires.
This is where experienced engineering becomes strategically important. The board can identify the opportunity and determine its appetite for risk. But engineers have to turn those intentions into architecture.
Where should processing happen? Which data does the AI actually need? Can synthetic information be substituted? What should remain inside existing security boundaries? What access should an agent have? How will that access be monitored? How can it be revoked?
And what happens when something goes wrong?
These are precisely the kinds of considerations FlowMoCo describes in its approach to governed AI: understanding information flows first, then designing architecture, integrations, controls, testing and governance around the required business outcome.
The board is managing opportunity as well as risk
This brings us to perhaps the most important shift.
The board isn't simply managing AI risk. It is managing the tension between three things: competitive advantage, risk and control.
Too much emphasis on control and the organisation may fail to exploit an asset competitors are learning to use. Too much emphasis on speed and the organisation may expose the very information that creates its advantage. And doing nothing isn't necessarily the safe option.
The board's role is to create an environment in which the organisation can experiment, learn and discover where the advantage lies, while engineering keeps the boundaries deliberate. That requires governance to become more iterative too.
Instead of asking once a year, "What is our AI policy?", boards might regularly ask:
- Where could our data and AI create an advantage competitors can't easily replicate?
- What experiments are we running to find out?
- What sensitive information can our AI systems access today?
- Has that access changed since we last reviewed it?
- Could schema, synthetic data or privacy-preserving approaches reduce exposure?
- Are our controls evolving as quickly as our capabilities?
Those are strategic questions, not simply IT questions.
Find the advantage. Then engineer it properly.
At FlowMoCo, we believe organisations should use AI to discover the right thing to build, then use experienced engineers to build it properly.
The same principle applies to the board's AI journey.
The objective shouldn't be to create the organisation with the most restrictive AI policy. Nor should it be to become the organisation using the most AI tools.
The quest is to discover where the combination of your data, your domain expertise and AI creates meaningful competitive advantage. Then engineer the systems and controls that allow you to exploit that advantage confidently.
We have navigated transformations like this before. Mobile changed access. Cloud changed infrastructure. AI changes agency. The destination is familiar: finding the right balance between risk, reward and control. What's different this time is the speed of the journey — and potentially the size of the prize.
Continue the conversation with Ben
Enterprise AI, proprietary data and the associated risks are evolving quickly. There won't be a single architecture or governance model that's right for every organisation. If this article has prompted you to think differently about your data, AI strategy or where competitive advantage might exist inside your organisation, get in touch with Ben Whorwood, Senior Architect at FlowMoCo.
Ben would be interested to hear how other boards and technology leaders are approaching the challenge, compare perspectives, or talk through your own enterprise context.
Because perhaps the most valuable question for the next board meeting isn't:
"What are we doing about AI?"
It is:
"What could we do with AI and our data that our competitors cannot — and how do we engineer it properly?"