Onur Alp Soner is the co-founder and CEO of Countly, a product intelligence and user engagement platform. A technologist and entrepreneur, he bootstrapped Countly from an open-source analytics project into a global platform used by enterprises across regulated and data-sensitive industries. His work sits at the intersection of product, data, privacy and technology, with a focus on helping companies understand user behaviour, build better digital experiences and keep control over their data. In this interview, he explains where digital-sovereignty exposure really sits, how enterprises should decide what to keep under their own control as they adopt AI, and how leaders can tell whether they could actually switch providers.
A recent Capgemini Research Institute study found that 86% of large organisations have significant exposure to foreign or externally controlled technology supply chains. From your perspective, which dependencies create the greatest practical exposure, and where do leadership teams most often misjudge their level of control?
The biggest exposure usually isn’t the obvious infrastructure layer. It’s often in the systems businesses rely on to understand their customers, from analytics and CRM to customer engagement and AI services. These platforms hold valuable information about how customers behave, what they buy and where they struggle. Over time, many organisations have handed this data to external providers one tool at a time, without fully considering how dependent they've become.
There are also less visible dependencies, including identity management, encryption keys and third-party SDKs embedded in products. Companies may know which vendors they work with, but that doesn't necessarily mean they have a complete picture of where their data goes or who can access it.
I think the biggest misconception among leadership teams is that choosing an EU hosting region or signing the right contract gives them control over their data. Yes, choosing an EU region tells you where the servers sit, but it doesn't necessarily tell you who operates them, who holds the keys, which legal jurisdictions apply or how easily you could move to another provider.
There's also the question of how much choice businesses actually have. An organisation might work with twenty different SaaS vendors, but if most of them depend on the same two or three infrastructure providers, its exposure is still concentrated.
Finally, most companies have an exit strategy on paper, but very few have actually tested it. If you've never moved your data out, you don't really know whether you can.
You’ve argued that sovereignty is less about eliminating foreign technology than understanding dependencies and controlling critical data. How should enterprises decide which data, workloads and systems must remain under their own control, and which can safely rely on external providers?
I’d start with consequences, not data labels. For every critical system, businesses should consider three things: what would happen if it became unavailable or its provider changed the terms of service; the risks if an external party gained access to the data; and how easily they could move to another provider or rebuild the system if needed.
In practice, I'd prioritise keeping control over regulated data, customer information and core intellectual property. But it's not just the raw data that matters. The insights businesses build from it, including customer segments, models and decision logic, can be just as valuable. These are assets that become more valuable over time and can be difficult to recreate if a company becomes too dependent on a particular provider.
That doesn't mean everything needs to be managed internally. Businesses can reasonably rely on external providers for computing resources, collaboration tools and other systems that aren't central to what differentiates them, provided they have a realistic way to switch providers if needed.
It’s also important to be precise about what “control” actually means. It doesn’t mean owning every server or avoiding foreign technology. What matters is being able to decide where your systems are deployed, who operates them, who holds the keys and whether you can take your data elsewhere. You can use software developed anywhere in the world while keeping control over the infrastructure it runs on. That's the distinction that matters.
As companies embed third-party foundation models, AI APIs and cloud services into their workflows, what new dependencies emerge? Which risks are materially different from those created by traditional software vendors?
As businesses integrate AI into their products and operations, they're becoming dependent on external providers in ways that go beyond traditional software. One of the biggest differences is how updates to AI models can affect the products built around them. When a provider updates or retires a model, a product's behaviour can change, sometimes without warning. Unlike software updates that businesses can manage themselves, changes to externally managed AI models may happen outside their control, affecting the results their products produce.
Another concern is the new data flows created by AI services. Prompts, retrieved documents and other context sent to an external AI API can mean sensitive information leaving a company's environment, often in ways that existing data protection measures weren't designed to monitor. AI agents and connectors add another layer of risk because they can act on information and perform tasks using the permissions they've been given, rather than simply accessing data.
Switching providers also comes with costs that aren't always obvious. Beyond moving data or replacing an API, businesses may have built prompts, evaluation processes and entire workflows around the behaviour of a particular model. Moving to another provider could mean having to adapt or rebuild much of that work.
This is why I’d advise businesses to understand exactly where their AI components are running, retain control over the data used to provide context to models, and maintain their own evaluation processes to assess the impact of model changes. They should also build in the flexibility to switch models or providers from the start, rather than addressing these dependencies once they become difficult to untangle.
What are the most important architectural trade-offs between self-hosted or open-source systems and fully managed services? In which circumstances does the additional operational responsibility of self-hosting pay off?
Self-hosting tends to pay off when businesses are dealing with regulated or strategically sensitive data, have strict data residency or jurisdiction requirements, or rely on systems that are so deeply embedded in their operations that they function more like infrastructure than individual tools. It can also make sense at a scale where having control over deployment has a meaningful impact on cost and performance. For smaller teams using systems that aren't business-critical, the additional responsibility for maintenance, security updates and monitoring may not be worth it.
However, open source doesn't automatically mean sovereignty. Businesses still need to consider who maintains the software, what support is available and whether they have the resources to operate it effectively. It's also worth remembering that the choice isn't necessarily between managing everything internally and relying entirely on an external provider. Companies can run vendor software within their own infrastructure while deciding how much of the day-to-day operation they want to handle themselves.
There's also a longstanding assumption that self-hosting comes at the expense of product capabilities and usability, with fewer features, more complicated interfaces and a longer path from data to decisions. This is something we've focused on with Countly 27. We believe enterprises shouldn't have to sacrifice functionality to retain control over deployment, which is why we've brought analytics, AI and customer engagement capabilities together in a platform that organisations can operate within their own infrastructure.
If a regulated enterprise wanted to reduce its exposure to vendor lock-in over the next 12 months, what concrete steps would you prioritise? How should its leadership measure whether it has actually improved its resilience and ability to switch providers?
I'd start by building a clear picture of the dependencies across critical services, including sub-processors and the infrastructure providers that vendors themselves rely on. Once businesses understand where those dependencies exist, they can assess the risks associated with each one and identify which systems need a realistic exit strategy.
The next priority should be making sure they can actually move their data. This means negotiating data exports in open formats, exit assistance and control over encryption keys into vendor contracts, while favouring open standards when selecting new providers. But having these provisions in place isn't enough. I'd recommend choosing at least one important system and testing the entire exit process by moving its data into an alternative environment. Businesses will learn far more from doing this than from relying on policy documents. For financial institutions in the EU, DORA also places requirements around exit strategies for certain critical ICT services, making this a regulatory consideration as well as an operational one.
I'd also make deployment flexibility a standard part of evaluating new technology, particularly AI services. Before signing with a provider, businesses should understand where the technology runs, who operates it and what switching to an alternative would involve.
When it comes to measuring progress, leadership teams should focus on what they've actually tested rather than what they've documented. They should track how many critical systems have an exit plan that's been exercised, how long switching providers takes in practice, how much critical data can be exported in usable, open formats, and how many single points of dependency they've eliminated.
If those numbers haven't improved after twelve months, the business hasn't made much progress on resilience, regardless of what its policies say.
Looking three to five years ahead, how do you expect enterprise AI strategies and digital-sovereignty requirements to reshape technology procurement and infrastructure choices? What widely held assumption do you think will prove wrong?
I expect procurement to start with three questions that used to come last: where does the technology run, who operates it, and can we leave? Deployment flexibility will become a buying criterion rather than a niche requirement, and AI will accelerate this shift. The most useful AI depends on rich, proprietary context, so organisations will increasingly bring models to their data rather than send their data to models. Hybrid architectures will become the default, with different parts of the AI stack running in different environments and enterprises demanding clarity about which is which.
The assumption I think will prove wrong is that sovereignty and technological capability have to come at the expense of each other. In other words, that businesses must choose between using the most advanced platforms and keeping control over their data. That was a reasonable belief when private or self-hosted options were more limited, but it's becoming outdated. Enterprises will expect advanced capabilities without compromising on privacy or control, and vendors who can't offer both will lose ground.
A related misconception is that the model is the moat. Models will keep improving and becoming cheaper, but what remains difficult to replicate is a company's own data and the intelligence it builds from it. That's exactly the part worth keeping under your control.
