Key takeaways
- AI sovereignty includes control over data, models, compute access and operations.
- Open-weight models provide deployment options, but require infrastructure and operational expertise.
- Israel’s opportunity spans the physical data centre and the software that makes AI useful.
- Operating workloads can capture more spending while introducing greater cost and reliability obligations.
- Building global infrastructure companies and securing domestic compute access require distinct strategies.
Your customer data might still be there. Your application could still load. Your team would still own its code. But the intelligence powering customer support, document analysis, coding tools and autonomous workflows could become unavailable. How much of the business would continue operating, and how quickly could you restore the rest?
This is a hypothetical stress test, not a prediction. But it gets to the heart of a question that deserves more attention as AI becomes embedded in the economy: how much control do we have over the technology we increasingly depend on?
Mistral co-founder and CEO Arthur Mensch recently warned that Europe risks falling into a “complete trap” if it concentrates on industrial applications while leaving frontier AI models to the US and China. His argument, reported by POLITICO, is that Europe needs its own advanced models and computing capacity to preserve its security and freedom to act.
Mensch has a commercial interest in that argument. Mistral benefits when governments and enterprises prioritise European AI. Nevertheless, the underlying question matters well beyond Europe, and it is particularly relevant to Israel.
Building successful AI applications and controlling the infrastructure they depend on are different achievements. Israel needs a strategy for both.
That question brings us to the infrastructure beneath AI: the compute that runs models, the networks that connect it, the storage and databases that supply information, and the software that makes the system reliable. Israeli founders are building across these layers. Understanding where they fit helps explain both Israel’s commercial opportunity and the capabilities it needs to secure for itself.
What happens if the model disappears?
The impact of losing access depends on how a product is built. A business relying on one hosted model without a tested alternative could lose critical functionality immediately. Another might continue operating with a different provider, reduced capabilities or more human intervention.
Switching models is possible, but it is rarely as simple as changing an API key. Models differ in their responses, tool use, latency, context handling and reliability. Prompts that work well with one may perform poorly with another. A replacement needs to be tested against the actual tasks customers depend on.
Using the same model through a second cloud provider may provide another delivery route. It does not necessarily remove dependence on the model owner or protect against every kind of access restriction. Operational resilience and strategic independence are related, but they are not identical.
Open-weight models provide another option. When the weights are available and the licence permits the intended use, organisations can run a model on infrastructure they control. OpenAI’s own gpt-oss models illustrate this distinction: they can be deployed locally or through hosting providers, independently of access to OpenAI’s hosted API. That does not make them equivalent replacements for every proprietary model or every task.
And downloading weights is only the beginning. Someone still needs to provide the compute, memory, storage, networking, deployment software and operational expertise.
A fallback model without the capacity and systems to run it is a contingency plan on paper.
AI sovereignty starts beneath the model
I think the most useful definition of AI sovereignty is the ability to make meaningful choices about the systems you depend on: where they run, who can access the data, which models they use, and whether essential operations can continue when a supplier changes its terms or becomes unavailable.
That does not require every country to manufacture its own chips or every startup to train a frontier model. It requires understanding dependencies and deciding which ones are acceptable, which need alternatives, and which capabilities are too important to leave entirely outside your control.
There are several layers to this:
- Data control: Can you access, export and govern your own information?
- Model control: Can you select, adapt or replace the intelligence powering your product?
- Compute access: Can you obtain the capacity required to run it?
- Operational control: Can your team deploy, monitor, secure and recover the system?
These questions explain why AI infrastructure extends far beyond GPUs. The model is one component in a much larger system.
What AI infrastructure actually includes
For founders and investors, it helps to break the stack into the problems each layer solves.
| Layer | What it provides | Why it matters for AI |
|---|---|---|
| Power and cooling | Electricity, heat removal and facility resilience | Computing capacity is useful only if it can be powered and operated reliably. |
| Compute | CPUs, GPUs and specialised accelerators | Performs the calculations required for training and inference. |
| Networking | Connections between chips, servers and clusters | Distributed workloads need to move and exchange information efficiently. |
| Storage and memory | Persistent data storage and fast working memory | Models and processors need timely access to weights, datasets and intermediate results. |
| Databases and retrieval | Structured queries, search and access to relevant information | Connects AI systems to business facts and context. |
| Data engineering | Ingestion, transformation, quality and lineage | Makes information from fragmented systems usable and maintainable. |
| Orchestration and inference | Resource allocation, deployment and model serving | Turns available hardware and models into dependable services. |
| Agent infrastructure | Tool access, workflow execution, state and permissions | Enables systems to carry out multistep tasks across business applications. |
| Evaluation, observability and security | Testing, monitoring, diagnosis and protection | Helps teams understand whether a system works, why it failed and what it is allowed to do. |
These categories overlap. A company may operate across storage, databases and data processing, or combine infrastructure orchestration with model deployment. The purpose of the taxonomy is to make the dependencies visible.
It also helps distinguish three different activities: training a model, serving a model, and operating an agent. They share infrastructure, but their requirements and economics are not identical.
Databases deserve more attention
Databases are a particularly interesting part of this story because access to a capable model does not automatically give an agent an accurate understanding of a business.
Consider an agent investigating why a customer stopped using a product. It may need the customer’s current account status, historical activity, support conversations, billing events and the sequence in which those things happened. Finding a relevant document is useful, but it may not answer the entire question.
Different infrastructure serves different needs. A transactional database maintains business state. An analytical system supports queries over large datasets. Vector retrieval helps find information by similarity. Event history preserves sequences of activity. Agent state records progress through a task.
Pinecone, for example, provides vector database infrastructure for AI retrieval. Keewano is building database infrastructure designed for machine-generated workloads and access to detailed event data. These represent different approaches to making information available to AI systems (Disclosure: Remagine Ventures is an investor in Keewano, Troup AI and Pandorian, all mentioned in this article).
The investment question is not whether every company needs a new database because it uses AI. It is whether a new workload creates requirements that existing systems struggle to meet at an acceptable cost.
As agents become more active consumers of business data, that question becomes increasingly important. The infrastructure must support the queries machines actually generate, while maintaining permissions, freshness and predictable performance.
Mapping Israel’s AI infrastructure opportunity
Israel already has companies operating across many of these layers.
Grove Ventures, working with Startup Nation Central, mapped more than 70 companies across six data-centre infrastructure categories: energy, cooling, compute, storage and memory, connectivity, and management and orchestration. According to the mapping, 65% were founded since 2020. Those figures describe Grove’s data-centre ecosystem, rather than the entire AI software infrastructure market.
The landscape below extends that perspective into databases, data engineering, inference and AI operations.
Several areas stand out.
Moving and feeding data. DriveNets addresses networking for AI infrastructure, while WEKA focuses on the data infrastructure needed to keep AI workloads supplied with information. These are reminders that the performance of a computing system depends on much more than the processor itself.
Operating the infrastructure. ClearML spans infrastructure management, orchestration and deployment. NeuReality combines hardware and software for inference. These businesses address the work required to turn computing resources into usable production capacity.
Connecting enterprise data. Matia brings together data integration, reverse ETL, observability and catalog capabilities. This layer matters because an AI system’s usefulness depends partly on the quality and availability of the information it receives.
Making AI dependable. Evaluation, monitoring and security become more important as systems take actions. Traceloop focuses on LLM evaluation and observability, while Prompt Security, acquired by SentinelOne, addresses AI security. Their work illustrates why the infrastructure opportunity continues above the model-serving layer.
Power and compute. The physical foundations deserve equal attention. ZutaCore develops direct-to-chip liquid cooling to remove heat from demanding computing systems, while NextSilicon develops accelerated computing architectures for high-performance and AI workloads. They address different constraints, but both illustrate why access to models alone is insufficient: AI needs infrastructure that can run efficiently and reliably. For countries seeking greater control over their AI capabilities, power, cooling and computing capacity are part of the same strategic discussion.
Models and adaptation. Israeli founders are also building the intelligence itself. AI21 Labs develops the Jamba family of models, while Decart combines generative-model research with infrastructure optimisation for real-time experiences. Troup AI, a Remagine Ventures portfolio company, addresses another part of this layer through fine-tuning and model swarms deployed within an organisation’s own environment. These approaches reflect different opportunities: developing models, making them more efficient, and adapting them to specific enterprise tasks. The sovereignty question becomes practical here: how much control can an organisation retain over the intelligence it uses and where it runs?
Governing AI-generated software. As AI writes more code and agents take on more development work, organisations need ways to preserve their engineering standards. Pandorian, also a Remagine Ventures portfolio company, provides code governance that enforces an organisation’s standards across repositories and development workflows. It addresses a different problem from generating code: ensuring that the growing volume of human- and AI-written software follows the rules the organisation has established. Alongside evaluation, observability and agent security, this is an important part of the infrastructure required to put AI to work at scale.
For Israel, this creates multiple routes to building significant companies. Competing in AI does not require every founder to compete directly with a frontier model lab.
From selling infrastructure software to running the workload
There is also a business-model shift worth watching.
Notable Capital’s Glenn Solomon and Dan Cahana argued in a recent Ctech post that agents will expand infrastructure demand as they generate and operate more software. Their thesis is that companies taking responsibility for running a workload can capture a larger share of spending than vendors selling management software around someone else’s infrastructure.
They call these businesses “workload clouds,” citing Snowflake as an early template and Vercel, fal and Browserbase as examples across other workloads. Their expectations for declining software attach rates are forecasts, not established market outcomes.
The distinction matters for founders. Providing a tool that helps a customer operate a system is a different business from becoming the service on which that workload runs. The latter can create a deeper customer relationship, but also brings responsibility for capacity, uptime, support and infrastructure costs.
Higher revenue capture does not automatically mean better margins. The opportunity is to deliver a workload more effectively and build a business around that advantage.
Israel faces two separate infrastructure questions
The first is whether Israeli founders can build globally important AI infrastructure companies. The landscape shows considerable activity already.
The second is whether startups, researchers and institutions operating in Israel have sufficient access to affordable compute and the capabilities to use it. Success on the first question does not automatically solve the second.
Speaking at the Journey conference in October, Amnon Shashua argued that AI requires a different scale of infrastructure investment from the software businesses Israel historically excelled at building. His warning was that talent and ingenuity need to be matched by computing resources and a deliberate strategy for allocating them.
It would be wrong to conclude that nothing is happening. Israel’s National AI Program explicitly includes compute access, data infrastructure, research and talent among its priorities. The relevant debate is whether implementation, availability and affordability match the needs of the ecosystem.
My view is that Israel should pursue both objectives: help founders build infrastructure businesses for global customers, and ensure that companies and researchers at home can access the resources required to compete.
A country can export excellent infrastructure technology while remaining dependent on external providers for its own critical workloads.
What I would ask founders building in this market
At the pre-seed and seed stage, “AI infrastructure” is too broad to be an investment thesis by itself. I would want to understand the specific constraint a company removes.
What gets measurably better? Lower cost per completed task, faster deployment, higher utilisation, better reliability or stronger control are tangible outcomes. A benchmark improvement needs a connection to a customer’s economics.
Who buys it? A data-centre operator, an infrastructure engineer and an enterprise AI team have different budgets, procurement processes and expectations. The route to market needs to fit the product.
Why does this become a company? A useful feature may be absorbed by a cloud platform, database vendor or model provider. Defensibility might come from systems expertise, workload-specific optimisation, distribution or the operational difficulty of delivering the service.
What happens when the models improve? Better models may eliminate some workarounds while increasing demand for data access, execution capacity and monitoring. Founders need a view on which side of that change they sit.
How dependent is the infrastructure company itself? A product promising flexibility should be clear about its own reliance on particular clouds, chips, model providers and deployment environments.
The practical meaning of sovereignty
For most startups, the sensible response is to use the best available models while making dependencies explicit. Know which workflows are critical. Retain control over business data and application state. Test an alternative model on real tasks. Understand what would continue working during an interruption and what would need to pause.
A second provider account is not the same as a tested recovery plan. Equally, self-hosting is not automatically the right choice for every company. The cost and complexity should be proportionate to the importance of the workload.
For Israel, the ambition should be broader: sufficient capability to keep building, researching and operating essential systems, alongside companies that become valuable suppliers to the rest of the world.
The sovereignty debate gives us a useful starting question: what happens if access disappears? The infrastructure opportunity begins with the work required to make the answer less alarming.
The companies that make AI more reliable, efficient and controllable will help determine who can build with it, and on whose terms.
He is a former General Partner at Google Ventures (GV) in Europe, former head of Google for Entrepreneurs in Europe, and founding head of Campus London, Google's first startup hub. Eze writes on Israeli tech, venture capital, artificial intelligence, and founder strategy.
He is also the founder of Techbikers, a nonprofit that brings together the startup ecosystem on cycling challenges in support of Room to Read.
- Israel’s AI Infrastructure stack - November 5, 2026
- Sequoia’s London exit: what Europe can learn from Israel - November 4, 2026
- Requests for Startups: Winter 2027 edition - November 4, 2026
