강력한 보안을 기반으로 한 글로벌 클라우드 에지

Panels about AI sovereignty tend to follow a predictable arc. Someone invokes GDPR. Someone else mentions hyperscalers. A politician says something optimistic. Everyone applauds and goes home.Last week's Gcore AI panel in Luxembourg didn't go that way.We had Christos Floros — founder of Monnett, former political candidate, and one of the more honest voices I've heard on the intersection of technology and governance — alongside Clara Ulken from our own team. The audience was full of founders, investors, and operators who are actually building things. And the conversation got uncomfortable in all the right ways.Here's what I actually took away — not the polished version, but the substance.First, who controls AI today? (Nobody in this room)We opened with a live audience poll: who controls AI today — US hyperscalers, governments, or private enterprises?The result was essentially: US hyperscalers, and also private enterprises, and those two categories overlap almost completely. Nobody selected governments. The response to that option landed somewhere between a polite laugh and a collective wince.It's worth sitting with that for a moment. We're building policy frameworks, funding initiatives, running regulatory consultations — and the people in the room, the practitioners, don't believe governments are meaningfully in control of the technology those policies are meant to govern. That's not cynicism. That's an accurate read of the current state.The follow-up question — is China a factor? — got a more nuanced answer. The US dominates, clearly. But writing off China as irrelevant would be a mistake. Christos noted that Mistral remains one of Europe's few genuine bright spots in foundation models, and the audience felt the fragility of that position without anyone needing to say it directly.What is sovereignty, actually?Before you can have a serious conversation about sovereign AI, you need a working definition of sovereignty. It sounds obvious. It isn't.Christos gave what I thought was the most honest framing of the evening. He invoked the Greek revolutionary motto — Eleftheria i Thanatos, freedom or death — not as theatre, but as a genuine philosophical anchor. Sovereignty is the freedom to self-govern. The freedom to decide what kind of society you want to be. The freedom to shape, rather than merely consume, the tools that increasingly make decisions on your behalf."If we're not able to shape the very tools that are shaping our decision-making," he said, "then we're not free."That's a harder standard than most AI sovereignty discussions apply. Most conversations focus on data residency and regulatory jurisdiction. Those matter — but they're the floor, not the ceiling. The deeper question is whether Europe is building the capacity to shape the direction of AI development, not just the conditions under which foreign-built AI gets deployed here.Clara brought it back to the operational: sovereignty for AI means controlling where your data lives, how it's accessed, and who has legal authority to compel its disclosure. That last point is the one that actually changes business decisions. Under the US CLOUD Act, American cloud providers are required to produce customer data when served with a valid US legal order — regardless of where the data is physically stored. A German company's files on AWS servers in Frankfurt are not protected from that obligation by their European location. European providers operating under EU law face no equivalent compulsion from US authorities.That distinction is increasingly driving real infrastructure decisions. It's not abstract sovereignty. It's a concrete legal risk that procurement teams are starting to model.Sovereignty is not isolation — and the distinction mattersOne of the more productive moments came when Leo, our moderator, floated an analogy: is sovereignty like an island, where everything made inside stays inside?Both panelists pushed back, and I think they were right to.Christos: "Being interdependent just means being self-sufficient enough to act as a global player — to trade with others, to exchange goods and services — without being absolutely dependent. The moment you become dependent, you're no longer sovereign."Clara: "When we talk about European sovereign AI, we're not talking about an isolated European sovereign AI. It's about Europe being sovereign — having the ability to control its own narrative — while also supplying those services to the world. There are plenty of US companies that don't want to be beholden to the Cloud Act and would therefore like to store their data in Europe."This is an important distinction for how Gcore thinks about our role. We're not building infrastructure for Europe to retreat behind. We're building infrastructure that allows European companies — and global companies that value European standards — to operate without being structurally dependent on providers subject to foreign legal authority. The goal is competitive participation in the global market, not withdrawal from it.Europe is already in the game — further than the narrative suggestsA recurring frustration I have with public discourse on this topic is the framing of European AI infrastructure as a future ambition rather than a present reality.It isn't.Gcore operates tens of thousands of GPUs across data centers in Europe and globally. We were among the European companies highlighted at Nvidia's GTC conference in San Jose this year — alongside Nebius, which recently announced a 310 megawatt AI factory project in Finland. These are not pilot programs or announcements about future capacity. This is infrastructure that exists and is serving real demand right now.The global AI infrastructure shortage is real — but it's global. US companies are struggling to find compute just as much as European ones. The narrative that Europe is uniquely behind ignores the fact that demand has simply outpaced supply everywhere. What's different about Europe is that our regulatory environment, so often framed as the obstacle, is increasingly the reason companies want to be here.GDPR compliance used to be a compliance cost. It's increasingly a sales feature.The 75 million euro reality checkDuring the panel, I referenced the Euro 3C project — a pan-European AI infrastructure initiative led by Telefónica, involving 70 organizations across Europe, currently seeking €75 million in public funding to connect AI infrastructure across the continent.The audience reaction was immediate. Christos: "75 million doesn't sound like enough." Clara: "75 million is an astronomically small number when it comes to deploying AI infrastructure at this scale."To put it in context: a single hyperscale data center with meaningful GPU capacity costs hundreds of millions to build and equip. A major AI training cluster can run into the billions. Microsoft alone has committed $80 billion to AI infrastructure investment in a single year. €75 million, spread across 70 organizations and multiple countries, is not a rounding error — it is structurally insufficient to change the competitive landscape.But here's where I think the more useful conversation is: the question isn't whether €75 million is enough to build one European AI supercomputer. It's whether that's even the right model.Clara made the point clearly: the future of European AI infrastructure is not one centrally governed supercomputer. It's a distributed architecture — national and regional projects across Spain, Luxembourg, Germany, Finland, and elsewhere — operating under a common regulatory framework with consistent data standards and governance requirements. The European Commission's AI Factories initiative points in this direction: fund distributed projects, require regulatory compliance, let the private sector execute.That's a model that can actually work. Not because €75 million is enough, but because the right architecture doesn't require a single massive bet — it requires consistent standards applied across many funded projects.The regulation speed problem — an honest assessmentI want to be straight about something that tends to get softened in official Gcore messaging.Europe's regulatory process is slow. Not slow in a bureaucratic-caricature way, but slow in the specific sense that matters for technology: the world that a regulation is designed to govern often looks different by the time the regulation takes effect.Leo used the European Green Deal as his example — a framework designed in 2019 to address energy problems from 2015-2017, that arrived just as COVID, the Russian invasion of Ukraine, and Strait of Hormuz disruptions fundamentally changed the energy calculus. By the time the policy was operational, it was partially solving a problem that no longer existed while missing new problems it hadn't been designed for.The question for AI regulation is whether the same dynamic plays out — and the honest answer is: probably yes, to some degree. AI is moving faster than energy infrastructure ever did.Christos was blunter than I might be in an official capacity: "We don't have the knowledge. The best, most knowledgeable people don't take the time to get invested in politics. We don't know who's voting on our regulation."That's uncomfortable. It's also accurate. The people with the deepest understanding of large language models, GPU infrastructure, inference economics, and adversarial AI capabilities are, almost without exception, not in the rooms where EU AI regulation gets written. They're at Gcore, at Mistral, at the startups in this room, at the research labs. Getting that expertise into the regulatory process — not as lobbyists, but as genuine technical advisors — is one of the most important things that could happen for European AI governance.That said: the instincts behind European regulation are right. The Smart Spires project in Esch that Clara described — deploying AI compute infrastructure with cameras throughout a city, where European regulation prevents any facial recognition data from ever reaching the servers — illustrates what good regulation actually looks like. It doesn't design the product. It defines what the product cannot do. Private companies build and operate the infrastructure, understanding the market. Regulation sets the hard limits. That division of labor is the model that works.What Mistral and LetzAI tell us about sovereign identityOne of the sharper exchanges came around a question I've been turning over myself: what is the sovereign AI of Luxembourg?Luxembourg has a strategic partnership with Mistral AI — a French company whose largest shareholder is ASML, the Dutch semiconductor equipment manufacturer. Is Mistral "Luxembourg's sovereign AI"? Or is it LetzAI — founded in Luxembourg, built on Gcore infrastructure from the start, Luxembourgish team and founder — that earns that designation?Clara's answer: both are sovereign, and the question of which is "more" sovereign gets into semantics that may not be productive. The operative standard is whether a company operates under EU law, whether its data infrastructure is subject to EU jurisdiction, whether it complies with GDPR. Mistral meets that standard. LetzAI meets it more directly. Both are legitimate expressions of European AI capability.Christos took the federalist view: as long as European companies are operating under EU law and collaborating across borders, he's satisfied. He'd actively prefer cross-border collaboration — companies operating across multiple EU member states — because it reinforces the European project itself.I find myself somewhere in between. There's genuine value in companies that are born sovereign — built from the ground up on European infrastructure, under European legal jurisdiction, by European teams. That's a different thing from companies that are European by compliance rather than by origin. Both matter. They serve different purposes in the ecosystem.The capital gap is where this actually breaks downHere's where I spend a disproportionate amount of my time as Head of EU Sovereignty, because it's where the structural gap is most concrete.Everything about European AI infrastructure — the regulatory framework, the distributed architecture model, the genuine technical capability that exists in companies like Gcore and Nebius, and Mistral — can be undermined by one persistent problem: the availability of patient, risk-tolerant capital for European deep-tech companies.A US startup raising a pre-seed round operates in a market where investors are familiar with deep-tech risk, comfortable with long timescales to liquidity, and operating in a single legal and regulatory jurisdiction. A European equivalent raises in a fragmented landscape, navigating different legal environments across member states, with a smaller pool of investors who have direct experience with infrastructure-scale technology bets.Clara put it directly: "It is much easier for a US startup to get their pre-seed and first series funding than it is for a European company to do so. That's really where I hope to see change — allowing more free market, easier access to funding in Europe."The infrastructure isn't just data centers and GPUs. It's the financial infrastructure that allows companies to build data centers and GPUs. Until the capital environment in Europe moves closer to what exists in the US, we're solving the second-order problem while the first-order problem persists.This is where I'd push back on purely regulatory solutions. Gcore can be sovereign. Mistral can be sovereign. But if the companies that should be building the next layer of the European AI stack can't raise their Series A because there isn't enough patient capital in the ecosystem, the sovereign infrastructure they would have built doesn't exist. The talent stays, but it leaves to build in the US. That's not a regulatory failure — it's a capital markets failure, and it needs different solutions.Choosing European: a responsibility on both sidesThe panel ended with an audience member making what I thought was the most direct point of the evening: "Don't you think it's up to us? We talk about sovereignty, and then we spin up AWS instances because it's easy. Isn't it our job to choose European providers?"Yes. With a condition that Christos stated clearly: "We need to develop better products. Gcore needs to be better than their competitors. At the end of the day, the market decides."That's the only honest version of this argument. Sovereign infrastructure that underperforms isn't sovereign infrastructure that gets used. If European providers — including Gcore — ask companies to make a values-based choice between equivalent options, that's a reasonable ask. If we're asking companies to accept a material performance or cost disadvantage in the name of sovereignty, that's not a sustainable model and it's not one I'd endorse.The obligation runs in both directions. The ecosystem should support European providers. European providers should earn that support by building things that are genuinely better — not just jurisdictionally preferable, but technically excellent, commercially viable, and increasingly indispensable.That's the standard we're working toward.Where I land after this conversationThe European AI infrastructure conversation has matured significantly in the last two years. We've moved past the stage where the main debate was whether Europe should build sovereign infrastructure. The debate now is about how — what model, what funding mechanisms, what governance structures, what timelines.Here's my current read:The distributed model is right. Not one supercomputer, but many sovereign nodes operating under consistent standards. That's both the realistic path and the correct one.The regulatory instincts are right, but the execution needs to catch up. Getting technical expertise into the regulatory process is urgent. The people who understand the technology need to be in the rooms where decisions get made.The capital environment is the most underaddressed constraint. Regulatory reform that makes it easier for European investors to back European deep-tech companies would do more for AI sovereignty than almost any infrastructure initiative.And Europe's current position is stronger than the mainstream narrative suggests. We're not preparing to compete. We're competing. The question is whether we can sustain and accelerate that trajectory.At Gcore, that's the problem we wake up to every day. If you're working on pieces of this — infrastructure, policy, capital formation, applications — I'd genuinely like to talk.Dima Maslennikov is Head of EU Sovereignty at Gcore. Gcore operates global cloud, edge, and AI infrastructure with a focus on sovereign, GDPR-compliant deployment across Europe and worldwide. The views in this post are the author's own.Watch the full video of the event here:

We're excited to announce the alpha release of Gcore Terraform Provider v2 — a complete rewrite of our Terraform provider, built for the way we build today.This isn't an incremental update. It's a new foundation.Why we rewrote itAs Gcore's platform has grown — across Cloud, AI infrastructure, CDN, DNS, and more — we wanted our Terraform provider to keep pace automatically rather than through manual updates. We set out to build something where the provider accurately reflects the API by construction, and where shipping updates is fast. v2 is the result.What's new in v2Auto-generated from our OpenAPI spec — and that changes everything. The v2 provider's schemas, documentation, and validation are generated directly from our API spec using industry-proven code generation tooling. This means the provider stays accurate and in sync with the API, and when we ship new API features, a matching Terraform update can follow quickly.Built on the modern Terraform Plugin Framework. v2 is built on the current Terraform Plugin Framework, aligning us with where the ecosystem is heading and unlocking better performance and long-term maintainability.One unified API client. v2 uses a single, unified Go client — gcore-go — keeping things consistent and easy to maintain across all resources.Plural data sources. v2 adds plural data sources for most resources, making it much easier to query and manage groups of resources declaratively.Import support. Almost all resources now support terraform import, enabling teams to bring existing Gcore infrastructure under Terraform management without starting from scratch.What to know right nowv2 is in alpha. That means:Do not use it in production yet. Breaking changes between releases should be expected while the provider is in alpha.The existing provider (v0.*) remains fully supported. Documentation is still available and nothing is going away. We'll announce beta and General Availability milestones separately as v2 matures.Both versions live in the same GitHub repository: the master branch holds the v0 provider, and the v2 branch holds the new one.Migrating from v0 to v2We know many of you have been using the v0 provider extensively — particularly for Cloud and AI workloads. We're committed to making the migration as smooth as possible.Migration guidelines will be published as part of the v2 provider documentation. That said, we don't expect a fully automated migration path — Terraform configurations tend to be specific to how each team structures their infrastructure. For customers who want hands-on help, our Developer Experience team is happy to work through it with you directly, based on your specific setup. Don't hesitate to contact our support team via the customer portal.Part of a bigger pictureThis release is the next step in our broader push to improve developer experience across the Gcore platform. Earlier this year, we launched auto-generated SDKs in both Python and Go, covering all Gcore products. The new Terraform provider builds on that same foundation — one source of truth, the OpenAPI spec, powering everything.What's next? A Gcore CLI. Watch this space.Explore the Gcore Terraform Provider v2 →

An interview with Alexey Shirobokov, CEO & Founder of Mission Space with Dima Maslennikov, Head of Startups at Gcore, recorded at House of Startups, Luxembourg. At Gcore, we work closely with startups building at the edge of deep tech and frontier infrastructure. Every so often, we sit down with founders whose work deserves more than a press release. This is one of those conversations.A powerful solar event hit recently—rated G4 out of G5 on the geomagnetic storm scale. For most people, it's a headline. For critical infrastructure operators, satellite companies, aviation, and anyone dependent on GNSS (GPS/Galileo), it's a serious operational risk.Mission Space, a Luxembourg-based startup, is building a product that turns "space weather" from a scientific phenomenon into something decision-makers can act on. Their goal is not just predicting geomagnetic activity—but translating it into operational guidance: what to switch, reduce, postpone, or protect—and when.I spoke with Alexey Shirobokov, Mission Space's CEO and founder, about the real economic impact of solar storms, why the biggest bottleneck is data quality, how the company is building its own orbital sensing layer, and why European data sovereignty will matter more over the next five years.The moment space weather becomes business riskDima Maslennikov (DM): Alexey, thanks for joining. Introduce yourself and Mission Space in two or three sentences.Alexey Shirobokov (AS): I'm the founder of Mission Space. We've been in Luxembourg for four years, building a tool for predicting geomagnetic storms and space weather. And you're interviewing at the right time— we recently had a major solar event, G4 out of G5. We haven't seen that intensity in about twenty years. In a couple of days, we'll understand the consequences for both space and ground infrastructure.DM: Did you predict this event?AS: Of course—after it happened. And that's the point: the real value isn't just knowing "a storm occurred." The value is producing forecasts that help operators make decisions.From Kp-index to "what should I do at 3 a.m.?"DM: What kind of economic impact can events like this have? Who are your customers and what problem do you solve?AS: Let's start with history. In 1989, a solar storm of a similar scale caused a massive blackout in Quebec—people were without electricity for a week because a transformer failed. These events induce currents in power grids and transformers. Equipment can't handle it and burns out. When a large high-power transformer fails, whole regions can go dark.Our idea is to make forecasting not only accurate but actionable. It's not enough to say "the Kp-index will be X." Grid operators need to know whether they should switch something, reduce load, enter a controlled shutdown—or do nothing. It depends on their equipment, location, predictable load, and timing. If the peak hits at 3 a.m., that's one scenario. If it hits at 7 p.m., that's a different one.And power grids are only one segment. In general, we serve industries tied to radio communications, satellite operations, and GNSS.DM: Telecom operators?AS: Yes—especially satellite telecom operators. Also aviation: communications and navigation are sensitive to what happens in the ionosphere. And then there's autonomous machinery relying on GNSS for precise positioning. In effect, a solar event can resemble GPS jamming: no reliable signal, no reliable positioning, and machines behave poorly. If you're planning operations for autonomous systems, you'd like to know in advance what's coming.DM: Does this connect to defense tech as well?AS: Absolutely. Space weather events affect huge territories and create confusion for equipment. In defense scenarios, in peacetime, you at least have context and warnings. With space weather, it's random—unless you monitor it properly.A real-world story: tractors, drifted GPS lines, and insurance lossesAS: Here's a memorable example from the U.S. A year ago, many tractors—often with operators—were following GPS lines in fields. During short-lived space weather spikes, GNSS quality degraded and positioning drifted. That led to planting errors and misapplied chemicals. I believe insurers recalculated losses in the hundreds of millions of dollars range.DM: That's expensive.AS: Very. Insurance is an underappreciated customer segment here. In many ways, these events resemble extreme weather—except we all observe Earth weather, while space weather is far less visible operationally.And if you look forward: humanity is clearly heading back to the Moon, and later to Mars. Private stations—Starlab, Axiom—are coming. The share of economic activity generated in space will grow. There are already discussions about orbital data centers. But this entire system becomes much harder if you're not monitoring and managing how solar events affect space infrastructure.DM: So when my kids fly to Mars, we'll check "space weather" like a forecast?AS: Exactly. It will become a normal operational tool. In a future where you travel between—say—an office on the Moon and an office on Earth, that is the weather that matters.Why now: cheaper launches, better computing, and ML that finally makes senseDM: Why did you start Mission Space? Are you building it solo or with co-founders?AS: The story is simple. We met excellent researchers in this niche field. Not many people work on it. We realized the timing was right to move from government research projects toward commercialization.Several things made it possible: the falling cost of launching payload to orbit, improved computing, and mathematical models—especially machine learning—becoming more feasible. A major part of our know-how is our detectors—hardware that measures relevant parameters in orbit. We made them small enough that you don't need "millions and millions" per deployment. Roughly speaking, it's around the lower bound of about a million dollars to launch a unit in the way we design it.DM: How do you actually deploy these detectors in orbit?AS: We mount them on satellites via partner platforms. We have two programs where we launch detectors alongside partner missions.DM: You already launched something, right?AS: Yes. In March last year we launched our first platform—our first mission. It wasn't long, but it was crucial: validate survivability (launch stresses, radiation), confirm the detectors operate, and find bottlenecks—data transmission, compatibility with different equipment. This year we plan two launches, and next year I expect three to five.The long-term idea is to have more than ten orbital data collection points so we can process and improve models close to real time. In our case, "real time" is a key lever for forecast quality.The hardest part is not "more data"—it's clean dataAS: For real-time forecasting, we need serious storage. We collect data from our own detectors, but also from existing detectors on Earth and in space. One of our core goals is to consolidate this into our own data lake and make it the world's largest dataset on space weather.The big problem is data cleaning. Scientific and sensor data can be noisy: broken feeds, missing timestamps, drifting sensors, intermittent sources. You have to restore gaps and normalize streams. If you train ML on dirty data, you get wrong outputs.That's actually a key reason ML wasn't widely used in this domain before: collecting and cleaning the data is extremely labor-intensive. Volumes are already in terabytes, and raw datasets across the ecosystem could reach petabytes. Meanwhile, some of the most widely used models are still "old"—designed in the 70s and 80s, when modern computing simply wasn't available.DM: So your full stack is: collect, store, clean, model, product?AS: Exactly. We aggregate data, clean it at scale, and apply modern machine learning to deliver products for satellite constellation operators, ground communications infrastructure, and GNSS-dependent and autonomous systems.Business model: subscriptions plus high-resolution feedsDM: How do you monetize? Subscriptions, API access, enterprise deployments?AS: We charge for two things. First, the end product—typically as a subscription integrated into the customer's operations. Second, access to specific localized indicators and granular feeds, especially for customers who build their own models.DM: Can you share a rough price range?AS: Our estimate is ~€10,000/year for basic system access. For granular data feeds for sophisticated customers, it can go into the hundreds of thousands per year.DM: Do you already have paying customers?AS: Yes. We have several satellite-focused companies where we run joint PoCs and research collaborations with commercial contracts.Why Luxembourg: density, visibility, and a "business-minded" space agencyDM: You've been in Luxembourg for four years. Why Luxembourg?AS: Luxembourg is one of the few places in Europe where working with space infrastructure is relatively accessible. The density of space professionals is high, and the space industry is significant relative to the economy. It's also easier to be visible here and avoid getting lost in the bureaucracy and noise you might face in larger ecosystems.DM: How important is the Luxembourg Space Agency?AS: Very. The Luxembourg Space Agency has scaled rapidly—more people, more projects. And unlike some larger European space agencies historically built as scientific-bureaucratic structures, here it acts more like a business partner that helps push product development and commercialization. We expect our first fully supported project this year—we're moving through the gates now.DM: What about the wider ecosystem—House of Startups, LCI?AS: It matters. If you want to be part of the ecosystem, you need to be in the flow. House of Startups gives convenient access to events and stakeholders. We're based in the Luxembourg City Incubator, which does a good job connecting stakeholders.This year, the ecosystem also introduced a 20% tax deduction on early-stage investments—similar to the UK model—which can meaningfully unlock smaller checks.DM: Like €50–100k angel checks?AS: Exactly. Ten people investing €50k is already half a round. When part of the risk is effectively softened through tax incentives, early-stage decisions become easier.Infrastructure and the hyperscaler trap: why Mission Space moved to GcoreDM: Let's talk infrastructure. What triggered the move to Gcore?AS: We want infrastructure support to be simple and require minimal manual effort. Scaling was becoming more costly in terms of effort, and scalability had limits.We need scalability without paying astronomical amounts. With major hyperscalers, there's a well-known trap: you burn through credits quickly, then costs spike, and you're locked into their ecosystem. Also, despite "startup-friendly" messaging, reaching real support can be hard—especially from Luxembourg, which can feel like a peripheral market to them.Data sovereignty: why it matters more in the next five yearsDM: As a Luxembourg company building a global product, how important is data sovereignty for you?AS: Our product value increases with more data. So it's critical that data ends up in our data lake. At the same time, data sovereignty is becoming more relevant. I believe the ability to separate and manage data by sovereignty constraints will be essential over the next five years.If you look at future regulations and programs, European projects may require data to be local. Then it becomes an advantage if your infrastructure and processing are already inside Europe.It also depends on customers. For European public-sector customers, it's very relevant. In the U.S., it's already happening: certain scientific or orbital data is hard to move outside the American perimeter.Can Europe become a single market? Not without solving capital and language fragmentationDM: Europe is slow and bureaucratic, or Europe is accelerating—where do you stand?AS: It depends on whether Europe can truly unify. Today, borders are still very real. In venture, many funds have sovereign LPs—national money—so they face constraints. French money tends to invest in France, German money in Germany. Cross-Europe investments exist, but often marginally.That makes it hard to treat Europe as a single market. I struggle to imagine a major shift where taxpayers in one country broadly fund startups in another without a very clear accountability mechanism.There's also the language barrier. Even with English, people gravitate toward local-language networks and markets. Regulation reinforces this fragmentation.What's next: from a beta+ product to lunar space weather infrastructureDM: Give me three key milestones for the next 12–36 months.AS: First, migrating fully to Gcore infrastructure, building a powerful data lake, and rolling out a solid beta+ product this year.Second, launching more detectors—two missions this year and expanding further next year.Third, a lunar mission around 2027–2028. We want to start building space weather infrastructure around the Moon, where monitoring is still minimal today.Over a five-year horizon, we aim to have several mature, commercialized products in the directions we discussed—strong enough to replace legacy operational approaches with actionable forecasting.DM: Alexey, thank you. I hope you hit these milestones faster than your plan—and we'll do a follow-up interview in six months to compare notes.AS: Thank you!Key takeaways for founders and operatorsSpace weather is infrastructure risk: power grids, aviation, satellites, telecom, autonomous systems, and insurance all feel the impact.Actionability beats raw indices: operators need “what do I do” guidance, not only a Kp number.Data quality is the moat: cleaning noisy scientific streams is one of the hardest, most defensible parts of the product.Orbit becomes your proprietary data layer: more detectors = better real-time modeling and differentiated products.Sovereignty will shape access to data and contracts: especially in public-sector and regulated programs.If you're thinking about your infrastructure provider and where your data lives, Gcore offers European sovereignty, global edge performance, and none of the lock-in that comes with the hyperscaler default. With data centers across Europe and beyond, it's infrastructure built for companies that take their data strategy seriously. Get in touch.