Does speeding up daily tasks actually make an enterprise any stronger? Paradox Interactive’s VP of Data, Analytics & AI, Serge de Gosson de Varennes, breaks down why vanity metrics fail – and how to turn isolated wins into compounding business value.
Getting teams to use new tools quickly can look like momentum, but speeding up isolated tasks doesn’t automatically make an organization any stronger. To explore what real AI maturity looks like in practice, we recently sat down with Serge de Gosson de Varennes, VP of Data, Analytics & AI at Paradox Interactive, to discuss what it really takes to drive an enterprise AI transformation.
Bringing a Ph.D. in Symplectic Geometry and 20 years of cross-industry experience, Serge dives into why true transformation isn’t about license counts or token usage, but about building compounding capability. In this discussion, we cover the shift from task automation to workflow redesign, practical frameworks for measuring economic impact, and how federated ownership enables organizations to continuously absorb whatever technology comes next.
At the upcoming Data 2030 Summit, you will be talking about moving beyond AI adoption to building lasting organizational capability. What do you mean by that, and why is it so important for enterprises today?
speaker at the Data 2030 Summit
AI adoption is relatively easy to observe. Employees start using assistants, developers adopt coding tools, teams create prototypes, and the number of AI-supported activities increases. Those developments are important and useful, but they create the illusion that the organisation itself has transformed.
For me, transformation happens when AI changes how work is organised, governed and improved. A faster task is not always or necessarily a better workflow, and a successful local solution is not automatically an organisational capability. The question is whether the organisation is learning how to use AI repeatedly and reliably rather than solving every problem from scratch. 
That is what I mean by institutional capability. If one successful implementation establishes governed data access, an evaluation method, a security pattern, an integration or an operating practice that other teams can reuse, then the organisation is building leverage. And, the beauty of it is that there is a very simple test:
Does each successful AI implementation make the next one easier, safer or cheaper to build?
If the answer is consistently yes, capability is beginning to compound. This is important to know because models and vendors will change rapidly. A durable transformation therefore cannot depend entirely on today’s technology. It has to create an organisation that becomes progressively better at absorbing whatever comes next.
In your session description, you point out that metrics like token usage, licenses, or estimated time saved are misleading. Why do these vanity metrics fail to reflect true organizational AI maturity?
Those metrics mostly measure activity, not outcomes.
A growing number of licences tells me that people have access. Token consumption tells me that the technology is being used. The number of experiments tells me that there is interest. None of those measures tells me whether the organisation has become more effective.
Estimated time saved is particularly problematic. If somebody says, “AI saved us 10,000 hours,” my next question is: what happened to those hours?
Did we increase throughput? Did quality improve? Did cycle time fall? Did we avoid additional hiring or external costs? Did employees redirect that capacity toward more valuable work? Or did the time simply disappear into another activity?
I think AI measurement needs to mature from adoption toward cost, value and impact. At Paradox, for example, the implementation framework explicitly separates behavioural adoption, attributable spend, realised value and operating impact rather than treating any one of them as success on its own.
The ultimate measure of AI maturity is not how much AI an organisation consumes. It is whether AI becomes a dependable organisational capability that improves quality, increases capacity, accelerates decisions or enables something that previously was not possible.
Once an organization moves away from those vanity metrics toward reusable foundations, how must ownership, governance, and funding models change across the business?
This is where AI transformation stops being primarily a technology discussion and becomes an operating-model discussion. Ownership needs to become much clearer. A central AI function should not own every business workflow simply because AI is involved. The people closest to the work still need to own the workflow, the quality requirements and the business outcome. They know their problems best. At the same time, certain capabilities make much more sense when they are shared: platforms, model access, common integrations, security patterns, evaluation tooling and parts of governance.
I therefore tend to favour a federated model: shared capability, distributed ownership of value.
And governance should work in the same way. It should be proportional to consequence rather than applied identically to every initiative. Low-risk experimentation should remain lightweight, while systems that are sensitive, operationally important or highly autonomous need more scrutiny because of the consequences. Good governance should reduce uncertainty and make known safe patterns easier to reuse, rather than force every team to rediscover the same answer.
Funding then needs to reflect the distinction between local value and shared capability. A team should normally remain accountable for the economics of the workflow it wants to improve, but shared infrastructure should not depend on one local business case carrying the entire cost when many teams will ultimately benefit. The hard part is not choosing centralisation or decentralisation. It is deciding explicitly which responsibilities belong where.
One of your core takeaways from the session is “building for reuse.” How do you design an AI capability so it becomes a standardized pattern for other teams, rather than a one-off custom build?
I would start by being careful not to mistake reuse for standardising everything. Some solutions genuinely are local and should remain so. Trying to turn every successful experiment into an enterprise platform creates unnecessary complexity and most probably doesn’t make any sense. The question is: Does the solution contain components or decisions that address a problem other teams are likely to encounter?
That might be technical: a governed connector to an internal data source, identity and access for agents, an evaluation framework, observability, or a deployment pattern. These are typically reusable components. But reuse can also be organisational. A security decision, a legal interpretation, an ownership pattern, a method for measuring quality, or even a documented failure can all become reusable capability.
The practical discipline is to ask after an initiative succeeds:
What did we solve here that another team should not have to solve again?
Then you need ownership. Reuse without ownership quickly becomes abandoned infrastructure. Somebody needs responsibility for maintaining the capability, documenting its intended use, monitoring dependencies and deciding when it should change or be retired. And I am even going further: If there is no ownership, no maintenance and no development, it should not exist. That is also why I prefer thinking in terms of capabilities rather than projects. A project ends when its deliverable is complete. A capability has a lifecycle and continues to create value after the original project has disappeared.
To ground that concept in practice, could you share an example of an end-to-end workflow redesigned into a reusable asset, and what general framework do you use to measure its real economic value?
Software quality assurance is a perfect example. Imagine a team initially uses AI simply to generate test cases. That may save time, but it remains a local use case. If we look at the workflow end to end, there may be much more opportunity: requirements enter the process, test plans are created, execution produces failures, failures are classified, duplicate bugs are identified, tickets are created, developers receive context, changes are reviewed, and results flow back into the development process.
Once you redesign that workflow rather than optimise a single task, several reusable assets can emerge: integrations with issue tracking, common testing patterns, evaluation criteria, security controls, knowledge retrieval, ownership models and monitoring.
At Paradox, one of our QA analysts, Kay Sakura, developed an AI-supported QA workflow that demonstrated substantial local value. Importantly, the solution did not remain an isolated success: it was shared and made available across the organisation, allowing other teams to benefit from the capability rather than having to solve the same problems independently. For me, this is a good example of the transition we want to encourage, from a successful local initiative to a reusable organisational capability.
Economically, I would measure four things together: adoption, cost, value and impact. Cost includes more than tokens. Value needs to be realised rather than claimed. Impact asks what changed operationally: cycle time, throughput, quality, avoided work, or newly possible capability. And if the resulting foundation reduces the cost of subsequent implementations, that reuse should be treated as part of the economic value as well.
Looking toward 2030, what single legacy habit or mindset around data strategy must enterprise leaders unlearn today to build lasting AI capability?
The habit I would most like organisations to unlearn is the idea that data is primarily an asset owned and delivered by a central data team. AI makes the limitations of that model much more visible.
Enterprise AI depends on trustworthy information, but the people who understand the meaning, quality and operational context of that information are distributed throughout the organisation. A central data function can provide architecture, standards, platforms and governance, but it cannot manufacture domain ownership from the centre.
The same applies to AI. If every useful data product or AI workflow depends on a specialist central team understanding the business better than the business itself, the organisation will always struggle to scale, or even fail. The shift is from thinking of data as something a data team delivers to thinking of data, analytics and AI as shared organisational capabilities with explicit local ownership.
That does not mean decentralising everything. Quite the opposite: common foundations become even more important. But central teams should make good local ownership easier rather than replace it.
By 2030, I think the strongest organisations will not be those with the largest AI teams. They will be those where reliable data, clear ownership, reusable capability and decision-making discipline have become part of the way the company operates. AI will amplify that foundation. It will not substitute for it.
Join the Discussion at Data 2030 Summit
Ready to take these insights further? Catch Serge de Gosson de Varennes live at the Data 2030 Summit as he breaks down what it takes to turn local AI wins into enterprise-wide leverage. Click here to join the conversation live!
