Sovereign AI in Europa: Was Mistral und OVHcloud bereits abdecken und wo Lücken bleiben
Mit Modellen und Cloud-Diensten aus Europa lassen sich mehrere Ebenen einer KI-Infrastruktur selbst kontrollieren. Europäisches Hosting allein schützt jedoch nicht, wenn ein Anbieter den Zugriff kappt, denn Abhängigkeiten bleiben etwa beim Modell oder beim Retrieval bestehen.
Veröffentlicht am 9. Oktober • Zuerst veröffentlicht auf jrobineau.com
Kurzfassung. Europa verfügt bereits über Modelle und Cloud-Dienste, mit denen sich mehrere Ebenen eines KI-Systems kontrollieren lassen. Mistral und OVHcloud bieten praktische Optionen, doch Abhängigkeiten bleiben bestehen. Europäisches Hosting allein sorgt nicht dafür, dass ein Dienst weiterläuft, nachdem ein Anbieter den Zugang gekappt hat. Man muss das Modell ersetzen, die eigenen Daten zurückholen und den Dienst neu aufbauen. Ein sinnvoller Test ist die Frage, ob man diese Unabhängigkeit dreißig Tage lang aufrechterhalten kann.
Dieser Artikel richtet sich an CTOs, CIOs und Teams, die KI-Funktionen in Produktion bringen.
Eine API ist die Schnittstelle, über die Ihre Anwendung einen entfernten Dienst aufruft. Der Verlust des Zugangs bedeutet den Verlust der entsprechenden Funktion. Die Ursache kann kommerzieller, technischer oder regulatorischer Natur sein. Ihr Kontinuitätsplan muss alle drei Fälle abdecken.
Am 12. Juni 2026 kündigte Anthropic an, Fable 5 und Mythos 5 für alle Kunden auszusetzen. Das Unternehmen verwies auf eine US-Exportkontrollrichtlinie. Seine anderen Modelle blieben demnach zugänglich. In der Erklärung wurde kein Datum für die Wiederherstellung des Zugangs genannt.
Die operative Frage ist einfach. Kann Ihr Dienst weiterlaufen, wenn ein Anbieter oder eine ausländische Behörde die Zugangsbedingungen abrupt ändert? Ja, für die Funktionen mit einem vorbereiteten und getesteten Ersatz. Für alles andere bleibt Kontinuität eine Annahme.
Verfügbar. Mistral bietet Open-Weight-Modelle und kündigte am 11. August 2026 die allgemeine Verfügbarkeit von Regional Endpoints an. Diese ermöglichen Kunden, für die Inferenz, also die Modellausführung, Europa oder die Vereinigten Staaten zu wählen. Eingeschränkte, abgesicherte Übertragungen an Subprozessoren außerhalb der gewählten Region bleiben weiterhin möglich.
OVHcloud stellt AI Endpoints bereit, eine API, die Open-Weight-Modelle aus Europa serviert. Sein Artikel vom 28. September beschreibt zudem OVHai LLM, hervorgegangen aus Dragon LLM nach der Übernahme im März. Dieses Labor ergänzt das Cloud-Angebot um Fähigkeiten in Modelldesign und Modellanpassung.
Geplante Kapazität. Mistral zielt auf bis zu 1 GW bis 2030. Das ist eine Absichtserklärung, keine sofort verfügbar kapazierbare Kapazität. Im Juli startete die Kommission eine Ausschreibung für bis zu sieben KI-Gigafabriken. Sie beschreibt außerdem ein Netzwerk aus neunzehn AI Factories, Zentren für Rechenleistung und Support. Die Gigafabriken sollen diese Kapazität erweitern. Die Ausschreibung stellt weder eine Lieferung noch den kommerziellen Zugang sicher, den Ihr Team erhalten wird.
Diese Komponenten machen einen europäischen KI-Stack glaubwürdig. Sie bieten getrennte Wahlmöglichkeiten bei Modell, Betreiber und Region. Sie beweisen nicht, dass das daraus entstehende System eine Unterbrechung übersteht. Dieser Nachweis muss aus Ihrer Architektur kommen.
Mein Artikel über souveränes Self-Hosting behandelt die Infrastrukturgrundlagen. Hier kommt als zusätzliche Herausforderung hinzu, eine nützliche KI-Funktion zu erhalten, wenn sich das Modell oder der Betreiber ändert.
In der Praxis bewahrt souveräne KI die Wahlfreiheit bei Bereitstellung, Daten und künftigen Änderungen. Diese Wahlmöglichkeiten müssen nutzbar bleiben, wenn ein Partner ausscheidet. Jede erfordert eine eigene Bewertung mit klaren Grenzen.
Rechtliche Souveränität betrifft die anwendbaren Gesetze und die Entitäten, die den Dienst kontrollieren. Technische Portierbarkeit misst, was Sie verschieben können. Operative Autonomie beschreibt, was Ihr Team eigenständig betreiben kann. Industrielle Unabhängigkeit betrifft die Fähigkeit, die vom System benötigten Komponenten herzustellen und zu ersetzen.
Weights sind die Parameter, die ein Modell beim Training lernt. Herunterladbare Weights ermöglichen es, eine Kopie aufzubewahren. Allein ihre Verfügbarkeit macht das gesamte Modell nicht zu Open Source. Ihre Rechte hängen weiterhin von der Lizenz ab.
Für Ihr gewähltes Mistral-Modell sollten Sie die exakte Version, die erforderlichen Dateien und den Lizenztext aufbewahren. Lassen Sie prüfen, ob die Rechte zur Nutzung, Anpassung und Weiterverbreitung zu Ihrem beabsichtigten Einsatz passen. Eine Marke impliziert keine einheitliche Lizenz über das gesamte Produktportfolio.
Erstellen Sie einen Evaluierungsdatensatz mit repräsentativen Anfragen und Akzeptanzkriterien. Er soll die Fehler messen, die für Ihr Geschäft relevant sind. Ein Ersatz kann dem erwarteten Protokoll folgen und dennoch unbrauchbare Antworten liefern.
Der Aufruf einer europäischen API delegiert den Betrieb weiterhin an Dritte. Die Bereitstellung von Mistral auf OVHcloud erfordert daher eine explizite Entscheidung über das Betriebsmodell. Die Nutzung eines Modells aus einem verwalteten Katalog unterscheidet sich vom Betrieb seiner Weights auf eigenen reservierten Ressourcen.
Für die verwaltete Option sollten Sie das exakte Modell und die Bedingungen für seine weitere Verfügbarkeit prüfen. Beim Self-Hosting müssen Hardwarekompatibilität und die Betriebskompetenz Ihres Teams validiert werden. Gehen Sie nicht davon aus, dass jedes Mistral-Modell über jedes OVHcloud-Angebot verfügbar ist.
Dokumentieren Sie die vertragliche Entität, die Region, die Subprozessoren und den Support-Zugang. Ergänzen Sie Anfragelimits und garantierte Kapazität. Eine zweite API desselben Betreibers kann dieselbe Ursache für eine Unterbrechung haben.
Eine GPU ist ein Prozessor, der viele Berechnungen parallel ausführt. Das Hosting nicht-europäischer Beschleuniger in einer europäischen Einrichtung ändert nichts an deren industrieller Herkunft. Abhängigkeiten können Chips, die sie steuernde Software und Ersatzteile umfassen.
Ein installierter, autonomer Server benötigt nicht unbedingt eine entfernte API für jede Antwort. Er kann dennoch schwierig zu reparieren oder zu erweitern sein. Dieses Risiko hat einen anderen Zeithorizont als ein unmittelbarer Ausfall des Zugangs.
Dokumentieren Sie die Mindesthardware, die Ihr Ausweichmodell benötigt. Messen Sie den Durchsatz auf dieser Konfiguration. Was auf Ihrem Laptop funktioniert, kann unter realistischer Last scheitern.
Dokumente müssen zusammen mit ihren Zugriffsrechten exportierbar bleiben. Bewahren Sie auch Modellanweisungen und Konfigurationsversionen auf. Die Vektorsuche repräsentiert Dokumente als Zahlenfolgen, um ähnliche Inhalte wiederzufinden.
Der Austausch des Modells, das diese Repräsentationen erzeugt, kann den Neuaufbau des Suchindex erfordern. Behalten Sie die Originaldokumente und messen Sie die Zeit, die der Neuaufbau benötigt. Der Export der Zahlen allein garantiert keine wiederverwendbare Suche.
Prüfen Sie anschließend Authentifizierung, Secrets und Protokolle. Secrets sind die Schlüssel und Zugangsdaten, die Dienste verwenden. Observability bündelt die Signale, die nötig sind, um das Verhalten dieser Dienste zu verstehen. Ein Failover muss autorisierten Zugriff, Alarme und Incident-Nachweise bewahren.
Meine Multi-Cloud-Erfahrung mit Terraform und Ansible führt mich dazu, reproduzierbare Infrastruktur zu priorisieren. Diese Tools beschreiben Ressourcen und Konfiguration in Dateien. Sie helfen beim Wiederaufbau von Systemen, doch Anbieter haben weiterhin eigene Anforderungen. Eine Migration erfordert Anpassungen, die tatsächlich getestet wurden.
Halten Sie Deployment-Dateien, benötigte Software und Verfahren außerhalb der Anbietergrenze, die Sie testen. Bitten Sie jemanden, der das Verfahren nicht geschrieben hat, den Dienst wieder aufzubauen. Dokumentieren Sie jeden unerwarteten Eingriff und die dafür benötigte Zeit.
Reichen Mistral und OVHcloud aus, um einen Stack souverän zu machen? Nein, ihre Auswahl löst nicht alle fünf Ebenen. Sie können eine kontrollierte Architektur tragen, wenn Rechte, Abhängigkeiten und Betrieb diese Entscheidung unterstützen.
Hardwareabhängigkeiten außerhalb Europas bleiben eine Einschränkung. Für einen Dreißig-Tage-Plan konzentrieren Sie sich auf verfügbare Kapazität und kritische Ersatzteile. Über mehrere Jahre gehören Hardware-Erneuerung und Software-Alternativen dazu. Diese Zeithorizonte erfordern unterschiedliche Investitionen.
Kapazität und Finanzierung schaffen eine weitere Einschränkung. Eine Ankündigung eines Rechenzentrums reserviert keine Ressourcen für Ihr Unternehmen. Fordern Sie ein Datum, eine Region, eine Ressourcenzuweisung und eine vertragliche Zusage ein. Finanzieren Sie den Ausweichplan, bevor Sie ihn benötigen.
Die Reife der Werkzeuge muss Funktion für Funktion geprüft werden. Testen Sie strukturierte Antworten, Dokumentenverarbeitung und Aufrufe externer Tools. Bewerten Sie auch Fehlerdiagnose und Wiederherstellung. Das Erscheinen einer Funktion in einem Katalog belegt nicht, dass sie die Anforderungen Ihrer Anwendung erfüllt.
Kompetenzen sind genauso wichtig wie Maschinen. Legen Sie fest, wer Updates, Sicherheit und Vorfälle betreut. Wenn nur eine Person das System warten kann, bleibt die Autonomie fragil. Sorgen Sie für Vertretung und planen Sie Zeit für Schulungen ein.
Ein Ausweichmodell kann bei bestimmten Aufgaben auch hinter Ihrem Primärmodell zurückliegen. Keine allgemeine Benchmark-Rangliste entscheidet über Ihren Anwendungsfall. Akzeptieren Sie ausdrücklich einen eingeschränkteren Funktionsumfang oder behalten Sie eine menschliche Prüfung für sensible Antworten bei. Ziel ist ein nützlicher, sicherer Dienst während der Übergangszeit.
Wählen Sie einen primären Anbieter und definieren Sie genau, was dessen Verlust bedeuten würde. Ein Modellausfall unterscheidet sich vom Verlust des gesamten Cloud-Kontos. Spezifizieren Sie wesentliche Funktionen, erwartete Last und akzeptable Fehler. Legen Sie auch die maximale Wiederanlaufzeit und den akzeptablen Datenverlust fest.
Beginnen Sie mit einer kurzen Übung, um offensichtliche Probleme zu beheben. Sie bereitet auf den Dreißig-Tage-Test vor, ersetzt ihn aber nicht. Schließen Sie in diesem Zeitraum einen Neustart, eine Wiederherstellung und eine Konfigurationsänderung ein. Prüfen Sie auch seltene Jobs und ablaufende Zugangsdaten.
Der Bericht soll festhalten, welche Funktionen überlebt haben, zu welchen Kosten und mit welchem Team. Vermerken Sie auch die nicht verfügbaren Funktionen. Wiederholen Sie die Übung nach einer größeren Modell- oder Infrastrukturänderung. Ein früherer Erfolg validiert nicht automatisch die nächste Version.
Man kann ausländische Technologie kaufen und dennoch einen gangbaren Ausstieg behalten. Man kann sich auch für europäische Anbieter entscheiden und von einem Dienst abhängig bleiben, den man nicht ersetzen kann. Der Unterschied liegt in den Nachweisen, die für jede Ebene vorliegen.
Mistral und OVHcloud bieten die Grundlagen, um eine solche Fähigkeit in Europa aufzubauen. Ihre Aufgabe besteht darin, diese Optionen in eine Architektur zu überführen, die das Team betreiben kann. Beginnen Sie mit einer kritischen Funktion und einer Failover-Übung. Getestete Reversibilität ist mehr wert als ein Label.
Um diese Abhängigkeiten in Ihrem System zu untersuchen, kontaktieren Sie mich für ein AI-Architektur- oder Kontinuitätsaudit.
Quellen: Anthropic, 12. Juni 2026 · Mistral AI, 11. August 2026 · OVHcloud, 28. September 2026 · Europäische Kommission, 30. Juli 2026. Abgerufen am 2. Oktober 2026.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
Posted on Oct 9 • Originally published at jrobineau.com
TL;DR. Europe already has models and cloud services that let you control several layers of an AI system. Mistral and OVHcloud offer practical options, but dependencies remain. European hosting alone will not keep a service running after a provider cuts access. You need to replace the model, retrieve your data and rebuild the service. A useful test is whether you can sustain that independence for thirty days.
This article is for CTOs, CIOs and teams putting AI features into production.
An API is the interface your application uses to call a remote service. Losing access means losing the corresponding feature. The cause might be commercial, technical or regulatory. Your continuity plan needs to cover all three.
On June 12, 2026, Anthropic announced it was suspending Fable 5 and Mythos 5 for all customers. The company cited a US export control directive. It said its other models remained accessible. The statement provides no date for restoring access.
The operational question is straightforward. Can your service continue if a provider or foreign authority suddenly changes access conditions? Yes, for the functions with a prepared and tested replacement. For everything else, continuity remains an assumption.
Available. Mistral offers open-weight models and announced general availability of Regional Endpoints on August 11, 2026. These let customers choose Europe or the United States for inference, meaning model execution. Limited, safeguarded transfers to subprocessors outside the selected region remain possible.
OVHcloud provides AI Endpoints, an API serving open-weight models from Europe. Its September 28 article also describes OVHai LLM, formed from Dragon LLM following its March acquisition. This lab adds model design and adaptation capabilities to its cloud offering.
Planned capacity. Mistral targets up to 1 GW by 2030. That is an ambition, not capacity immediately available to reserve. In July, the Commission launched a call for up to seven AI Gigafactories. It also describes a network of nineteen AI Factories, centres for computing and support. Gigafactories are intended to expand that capacity. The call establishes neither delivery nor the commercial access your team will receive.
These components make a European AI stack credible. They offer separate choices of model, operator and region. They do not prove that the resulting system will survive an interruption. That evidence has to come from your architecture.
My article on sovereign self-hosting covers the infrastructure foundations. Here, the additional challenge is preserving a useful AI function when the model or operator changes.
In practice, sovereign AI preserves choices over deployment, data and future changes. Those choices must remain usable when a partner withdraws. Each needs a separate assessment with explicit limits.
Legal sovereignty concerns applicable laws and the entities controlling the service. Technical portability measures what you can move. Operational autonomy describes what your team can run independently. Industrial independence concerns the ability to produce and replace the components the system needs.
Weights are the parameters a model learns during training. Downloadable weights let you retain a copy. Their availability alone does not make the entire model open source. Your rights still depend on its licence.
For your chosen Mistral model, retain the exact version, required files and licence text. Have the rights to operate, adapt and redistribute it checked against your intended use. A brand does not imply one licence across its entire product range.
Prepare an evaluation set containing representative requests and acceptance criteria. It should measure the errors that matter to your business. A replacement can follow the expected protocol while producing unusable answers.
Calling a European API still delegates operations to a third party. Deploying Mistral on OVHcloud therefore requires an explicit choice of operating model. Using a model from a managed catalogue differs from running its weights yourself on reserved resources.
For the managed option, check the exact model and the terms governing its continued availability. For self-hosting, validate hardware compatibility and your team's ability to operate it. Do not assume every Mistral model is available through every OVHcloud offering.
Map the contracting entity, region, subprocessors and support access. Add request limits and guaranteed capacity. A second API from the same operator may share the same cause of interruption.
A GPU is a processor that performs many calculations in parallel. Hosting non-European accelerators in a European facility does not change their industrial origin. Dependencies can include chips, the software controlling them and replacement parts.
An installed, autonomous server does not necessarily need a remote API for every answer. It may still become difficult to repair or expand. That risk has a different time horizon from an immediate access outage.
Document the minimum hardware your fallback model requires. Measure throughput on that configuration. Something that works on your laptop may fail under realistic demand.
Documents must remain exportable together with their access permissions. Retain model instructions and configuration versions too. Vector search represents documents as sequences of numbers to retrieve similar content.
Replacing the model that produces those representations may require rebuilding the search index. Keep the original documents and measure the time needed to rebuild it. Exporting numbers alone does not guarantee reusable search.
Then check authentication, secrets and logs. Secrets are the keys and credentials services use. Observability brings together the signals needed to understand how those services behave. Failover must preserve authorized access, alerts and incident evidence.
My multi-cloud experience with Terraform and Ansible leads me to prioritize reproducible infrastructure. These tools describe resources and configuration in files. They help rebuild systems, but providers still have their own requirements. Migration requires adaptations that have actually been tested.
Keep deployment files, required software and procedures outside the provider boundary you are testing. Ask someone who did not write the procedure to rebuild the service. Record every unexpected intervention and the time it takes.
Are Mistral and OVHcloud enough to make a stack sovereign? No, choosing them does not resolve all five layers. They can underpin a controlled architecture if rights, dependencies and operations support that choice.
Hardware dependencies outside Europe remain a limitation. For a thirty-day plan, focus on accessible capacity and critical spare parts. Over several years, include hardware renewal and software alternatives. These horizons call for different investments.
Capacity and funding create another constraint. A data centre announcement does not reserve any resources for your company. Ask for a date, region, resource allocation and contractual commitment. Fund the fallback before you need it.
Tool maturity needs checking feature by feature. Test structured responses, document processing and calls to external tools. Also assess error diagnosis and recovery. A feature appearing in a catalogue does not establish that it meets your application's requirements.
Skills matter as much as machines. Identify who handles updates, security and incidents. If only one person can maintain the system, autonomy remains fragile. Arrange cover and allocate time for training.
A fallback model may also trail your primary model on particular tasks. No overall benchmark ranking settles your use case. Explicitly accept a narrower feature set, or retain human review for sensitive answers. The aim is a useful, safe service during the transition.
Choose a primary provider and define exactly what losing it would remove. A model outage differs from losing the entire cloud account. Specify essential functions, expected load and acceptable errors. Set the maximum recovery time and acceptable data loss too.
Start with a short exercise to fix obvious problems. It prepares you for the thirty-day test but does not replace it. Include a restart, a restoration and a configuration change during that period. Check infrequent jobs and expiring credentials too.
The report should state which functions survived, at what cost and with which team. Record unavailable functions as well. Repeat the exercise after a major model or infrastructure change. Past success does not automatically validate the next version.
You can buy foreign technology while retaining a workable exit. You can also choose European providers and remain dependent on a service you cannot replace. The difference lies in the evidence available for each layer.
Mistral and OVHcloud provide foundations for building that capability in Europe. Your task is to turn those options into an architecture the team can operate. Start with one critical function and a failover exercise. Tested reversibility is worth more than a label.
To examine these dependencies in your system, contact me for an AI architecture or continuity audit.
Sources: Anthropic, June 12, 2026 · Mistral AI, August 11, 2026 · OVHcloud, September 28, 2026 · European Commission, July 30, 2026 Accessed October 2, 2026.