COOs and Chiefs of Staff at SaaS companies between $1M to $50M ARR whose AI pilots worked in one team and stalled when they tried to scale, and who have not yet assigned ownership of the data foundation every function's AI work runs on.
Most operations teams have a graveyard of AI pilots that worked. The tool performed. The team liked it. The results were real.
And then nothing happened. The pilot stayed in one team and never reached the rest of the organization.
The reason is almost never the tool. The data behind the pilot was never made available to any other function. Every other team that tried to build on top of it started from scratch.
Microsoft moved Copilot to over 500,000 NHS staff in one coordinated rollout. That scale did not happen because the tool was better. It happened because the organizational data infrastructure was built before deployment began. 1
At London Tech Week, the conversation moved from what AI can do to who owns making it work consistently.
Most companies at $1M to $50M ARR are still in the first conversation. The second one is the one that scales.
The ops teams that compound are not the ones that deployed the most tools. They are the ones that built the data foundation every function’s AI work actually runs on.
Relve rates this 90/100, a high signal for COOs and Chiefs of Staff scaling AI past the pilot stage.
The data problem does not stop at Ops. Every function is building on it.
Your Pilot Worked. Your Data Did Not Travel With It.
A pilot that works in isolation is not evidence that the tool works. It is evidence that the data in that one team's context was clean enough for the tool to run.
The moment a second team tries to build on the same tool, they find out whether the data travels. In most organizations, it does not.
The problem is structural. Every function has been building its own version of organizational truth. Marketing has one CRM view. Engineering has its own deployment data. Finance has a separate spreadsheet.
When an AI tool tries to synthesize across these, it produces outputs that contradict each other because the inputs are not the same. The tool is not broken. The data foundation is.
Claire Hughes Johnson's test is whether the system scales without breaking the organization. A pilot that works for one team on clean isolated data scales into fragmentation if the underlying data was never unified.
The tool surfaces the problem. It does not create it. The operations job is to own that unification before the tool arrives, not after it fails.
Most organizations skip the invisible work because it produces no demo and no launch announcement. It produces a second rollout that actually scales.
The NHS rollout worked because someone built the data infrastructure before the tool went live. At 500,000 staff that is a programme. At your scale it is three questions answered in writing.
What does clean mean for this organization? Who owns consistency across functions? Which function has the highest-priority data gap?
That is the entire data readiness requirement for a company under 100 people. Most have not written any of the three.
Every Function Is Building on a Different Version of Your Company.
This is the operations failure that AI made visible. It was always there. AI just made it expensive.
When Engineering builds an AI system, it trains on the data it can access. When Marketing builds its AI layer, it trains on a different dataset.
When HR uses AI for hiring, it pulls from a third source. None of these teams are being reckless. They are each building with what they have.
When those outputs meet in a leadership meeting, every function is defending a different version of what the company is doing. That is not an AI problem. It is an ops problem.
The operations function is the only one with both the mandate and the cross-functional visibility to own the data foundation that every other function builds on. If Ops does not own it, no one does.
Ray Dalio built Bridgewater on one principle: an organization can only make good decisions when everyone is working from the same version of reality.
The AI layer does not create alignment. It amplifies whatever alignment or misalignment already exists in the data beneath it.
- There is one owner of data consistency across Engineering, Marketing, Operations, and HR
- Each function's AI outputs draw from the same source data, not separate siloed datasets
- When two functions produce AI outputs on the same question, those outputs do not contradict each other
- The data behind every current AI pilot has been documented and is available to other functions
- There is a written definition of what clean, consistent, and ingestion-ready means for your organization
Three or more unchecked means every function is building on a different version of the company. AI will compound that fragmentation, not fix it.
The Pilot That Scaled Got the Data Right Before the Tool Arrived.
The NHS moved 500,000 staff onto Copilot. Barclays and the Department for Education are in the same early-adopter cohort. These are not organizations with simpler data problems than yours. 2
They are organizations that built the data infrastructure before the tool arrived. That sequencing is the reason the rollout reached scale. It is not a product story. It is an operations story.
Most organizations get the sequence backwards. They deploy the tool, discover the data is not ready, try to clean the data while the tool is live, and produce outputs no one trusts.
The correct sequence: clean and structure the data, define what consistency means across functions, assign one owner, then deploy.
Someone at the NHS owned the data. Someone defined what consistent meant across 500,000 users in different roles, departments, and systems. That work happened before anyone saw a Copilot interface.
The NHS is a UK example of what getting the data right before deployment looks like at scale. Your market will face the same question when the next tool lands.
Deploying AI onto an unstructured data foundation does not produce bad results immediately. It produces confident-sounding results that gradually diverge from reality. By the time the contradiction becomes visible, it is in a board meeting, a client presentation, or a hiring decision. The cost is not a failed pilot. It is a trusted output that was wrong.
Three Operations Decisions Before the Next Tool Lands
List every AI initiative in the last 12 months that produced positive results in one team and never expanded. For each one, answer one question: was the data behind it documented, cleaned, and made available to other functions?
The answer will almost always be no. That is not a failure of ambition. It is a failure of sequencing. The pilot proved the tool worked. It never proved the data was ready to scale.
Owner: COO or Chief of Staff.
Cost: Every new tool deployed onto the same fragmented data foundation produces the same result. A successful pilot that never scales.
Name one person whose job it is to answer: is every function working from the same version of organizational reality?
This is not a data engineering role. It is a cross-functional operations role. The owner defines what consistent means, audits whether each function meets it, and escalates when it breaks.
Under 30 people: The COO or Chief of Staff owns this directly. The organization is small enough that one person can hold the full picture. The work is a weekly check across functions, not a data project.
30 or more people: Assign a named operations lead with explicit cross-functional authority. They need access to Engineering, Marketing, HR, and Finance data. Without the authority, the role produces reports no one acts on.
Owner: COO assigns. Done before the next AI tool is deployed.
Cost: The next tool will produce the same fragmentation as the last one. The data foundation problem does not resolve itself through iteration.
Before the next AI tool goes live anywhere in the organization, answer three questions in writing.
What does clean data mean for this organization? What does consistent mean across functions? What does ingestion-ready mean for the systems Engineering is building?
These are not technical definitions. They are operational commitments. Engineering builds systems to ingest data that meets the standard. Marketing produces content that meets the standard. HR maintains records that meet the standard.
Owner: COO or assigned data consistency lead. Reviewed and signed off by Engineering lead.
Cost: Without a written standard, every function defines clean differently. The fragmentation does not stop. It just happens more expensively with AI tools on top.
The organizations that build the data foundation before the tools arrive compound. The ones that build after spend every rollout discovering the same problem at greater scale.
What Ops Owns Now
The conversation at London Tech Week was not about which tools to deploy. It was about who owns making AI work consistently across the whole organization. That owner is Ops. 3
Operations owns the data foundation, the consistency standard, and the rollout governance that determines whether a pilot becomes an organizational capability or a one-team experiment.
Not the tool vendor. Not Engineering. Not the individual team that ran the pilot. That accountability belongs to one function.
Every next tool will land on the data foundation that exists today. The organizations that have built it will compound. The ones that have not will run the same failed rollout sequence at higher cost.
The next tool is coming. The question is not whether the organization is ready. It is whether Ops has made it ready. Two different questions, two different owners. One of them is yours.
References
1 Microsoft, "London Tech Week 2026: The UK can lead in the AI era," June 2026.
2 TechTimes, "London Tech Week 2026 Closes: Microsoft's $30B UK Push Puts 505,000 NHS Staff on Copilot," June 12, 2026.
3 TLT LLP, "UK tech sovereignty: Insights from London Tech Week 2026," June 2026.
