Mistral AI sposta il tema della sovranità dell’intelligenza artificiale dal solo controllo dei modelli alla disponibilità dell’intera infrastruttura necessaria per eseguirli. La società francese ha reso generalmente disponibili i Regional Endpoints per mantenere l’elaborazione dell’inferenza in Europa o negli Stati Uniti, ha aperto in public preview un livello di servizio prioritario destinato ai workload critici, inizierà a ospitare sulla propria piattaforma modelli open sviluppati da altre aziende e sta aggregando impegni pluriennali di imprese e istituzioni per sostenere la costruzione di nuova capacità di calcolo in Europa. Mistral prevede 1 GW di capacità sovrana nell’Unione europea entro il 2030.
Le quattro iniziative compongono una strategia che riguarda direttamente il passaggio dell’AI generativa dalla sperimentazione alle applicazioni di produzione. Quando un modello entra nei processi aziendali, la disponibilità della GPU diventa parte della continuità operativa, la localizzazione fisica dell’elaborazione entra nelle policy di data governance e la possibilità di cambiare modello senza ricostruire l’infrastruttura riduce il rischio di dipendenza tecnologica. Modelli, inferenza, capacità di calcolo e localizzazione dei dati diventano quindi componenti della stessa architettura enterprise.
Regional Endpoints: scegliere dove viene eseguita l’inferenza
I Mistral Regional Endpoints, ora generalmente disponibili, introducono una scelta esplicita della geografia nella quale vengono elaborate le richieste inviate alle API. Sono attualmente disponibili un endpoint europeo e uno statunitense, affiancati dall’endpoint globale tradizionale. Per l’Europa, Mistral utilizza infrastrutture distribuite fra più data center nell’Unione europea e nei Paesi EFTA; negli Stati Uniti l’esecuzione rimane all’interno di data center statunitensi.
Dal punto di vista applicativo, il funzionamento resta quello di una API gestita da Mistral: è l’endpoint utilizzato dall’applicazione a determinare la regione nella quale il modello deve eseguire l’inferenza. Questo permette a un’organizzazione di applicare requisiti di data residency direttamente al routing delle chiamate e può diminuire la latenza quando utenti, applicazioni e infrastruttura AI si trovano nella stessa area geografica.
La differenza rispetto all’endpoint globale è sostanziale. Utilizzando api.mistral.ai, Mistral non assume un impegno sulla localizzazione specifica dell’inferenza. L’endpoint europeo api.eu.mistral.ai e quello statunitense api.us.mistral.ai vincolano invece l’esecuzione alle rispettive regioni. Il servizio regionale comporta un sovrapprezzo del 10% rispetto al listino standard, applicato ai token di input e output e alle operazioni di lettura e scrittura della cache.
La regionalizzazione presenta però confini precisi. La localizzazione dell’inferenza non equivale alla regionalizzazione dell’intero servizio Mistral. Configurazione dell’account, chiavi API, billing, gestione degli accessi, analytics di utilizzo e altri metadati del control plane possono essere trattati attraverso sistemi situati fuori dalla regione scelta. Mistral segnala inoltre la possibilità di trasferimenti limitati e protetti verso subprocessor esterni alla regione. Per una valutazione di compliance, quindi, la localizzazione dell’esecuzione del modello deve essere considerata separatamente dalla geografia del control plane e dagli eventuali flussi dei subprocessor.
Anche il perimetro funzionale è attualmente più ristretto rispetto all’API globale. I Regional Endpoints supportano soltanto i modelli e gli strumenti effettivamente disponibili nella regione selezionata; tra le tool call, la documentazione indica al momento il function calling come funzionalità regionale supportata, mentre funzioni stateful quali Agents, Batch e Files API non sono disponibili. Mistral distingue inoltre la regional inference dalla Zero Data Retention: la prima stabilisce dove avviene l’elaborazione, la seconda determina se il contenuto di richieste e risposte eleggibili viene conservato dopo l’esecuzione. Per determinati workload regolamentati possono quindi essere necessari entrambi i controlli.
Priority Tier crea una classe di servizio per i workload critici
La seconda componente interviene sulla prevedibilità della capacità. Mistral Priority Tier, disponibile in public preview, assegna alle richieste eleggibili una coda prioritaria rispetto al traffico Standard Tier durante i periodi di elevato utilizzo dell’infrastruttura condivisa. L’azienda lo indirizza ai workload real-time e business critical che richiedono una disponibilità più prevedibile dei modelli ospitati.
Le organizzazioni concordano con Mistral limiti personalizzati per ciascun modello, espressi attraverso parametri come richieste o token al minuto. La chiamata API può utilizzare service_tier="auto" per chiedere l’esecuzione prioritaria quando il contratto, il modello, i limiti configurati e la capacità della regione lo consentono. Se la capacità Priority non è disponibile oppure vengono superati i limiti assegnati, la richiesta può ricadere sul livello Standard invece di essere automaticamente respinta. La risposta API espone poi quale tier ha effettivamente servito la richiesta, permettendo di registrare eventuali fallback nei sistemi di osservabilità.
Il prezzo riflette questa garanzia aggiuntiva: Priority Tier applica un moltiplicatore di 1,75 volte il prezzo Standard, equivalente a un premio del 75%, anche sui token memorizzati nella cache dopo l’applicazione degli eventuali sconti di caching. Diventa quindi una classe di servizio da riservare ai flussi nei quali prevedibilità e disponibilità hanno un valore economico superiore al costo incrementale, lasciando batch processing e richieste meno sensibili alla latenza sulle classi più economiche.
La tabella tecnica di Mistral assegna al Priority Tier un uptime SLA del 99,5%; per Standard Tier e Batch non indica invece alcun uptime SLA. L’accesso alla classe prioritaria richiede un accordo attivo o una configurazione specifica dell’account con Mistral.
Una piattaforma multi-model anche per modelli open di terze parti
Il terzo elemento della strategia riguarda il modello eseguito sull’infrastruttura. Mistral ha costruito una parte rilevante del proprio posizionamento sulla disponibilità di modelli con open weights, che possono essere scaricati, ispezionati, adattati e distribuiti in infrastrutture controllate dal cliente. Ora estende questa logica alla propria piattaforma gestita ospitando anche modelli aperti sviluppati da terzi.
Il primo sarà Z.ai GLM-5.2, sviluppato dalla società cinese Z.ai, precedentemente nota come Zhipu AI e fondata nel 2019 a partire da risultati di ricerca dell’Università Tsinghua. Mistral ospita il modello senza modificarlo e lo orienta in particolare ai workflow di programmazione e di agentic engineering con contesti estesi. La documentazione Mistral indica per GLM-5.2 una context window da un milione di token e un output massimo di 128.000 token. Il modello può utilizzare chat completion, function calling, structured output, predicted output, prefix completion e batch processing attraverso le API della piattaforma.
La novità architetturale è la possibilità di utilizzare modelli provenienti da fornitori diversi mantenendo lo stesso livello infrastrutturale, gli stessi controlli regionali e gli stessi meccanismi di servizio. Un’impresa può così assegnare modelli differenti a reasoning, coding, elaborazione documentale, trascrizione o workload ad alto volume senza dover necessariamente moltiplicare piattaforme operative, sistemi di autenticazione e livelli di governance.
Questa scelta riflette la progressiva evoluzione delle architetture AI enterprise verso un approccio multi-model. Mistral stessa affianca modelli generalisti e di frontiera a sistemi specializzati come Mistral OCR per la document intelligence e Voxtral per l’elaborazione vocale, oltre alla possibilità di addestrare modelli personalizzati sui dati aziendali. L’ingresso di GLM-5.2 aggiunge la possibilità di utilizzare sullo stesso piano di esecuzione un’intelligenza prodotta fuori dall’ecosistema Mistral.
Dall’API alla capacità fisica: 1 GW entro il 2030
Il passaggio più industriale riguarda ciò che si trova sotto i modelli. Mistral vuole costruire fino a 1 GW di capacità AI sovrana nell’Unione europea entro il 2030, facendo di Mistral Compute un’infrastruttura europea capace di sostenere sia training sia inferenza su larga scala.
La piattaforma Mistral Compute utilizza hardware NVIDIA delle generazioni GB200, GB300 e B300, insieme a nodi CPU Grace e x86. Il progetto Mistral Compute era stato approvato nell’aprile 2025; i primi rack GB200 sono arrivati nel luglio dello stesso anno e nel dicembre 2025 sono stati aggiunti sistemi GB300. A febbraio 2026 i GB200 erano già utilizzati per workload di produzione e risultava in sviluppo il sito svedese presso EcoDataCenter; a marzo sono stati inseriti i primi clienti esterni.
La localizzazione europea dei data center non elimina tutte le dipendenze esterne. Mistral Compute utilizza GPU NVIDIA inserite in un ecosistema software riconducibile in larga parte allo stack proprietario CUDA: tecnologie statunitensi che possono ricadere sotto la normativa americana sulle esportazioni e sulle riesportazioni. La Commissione europea considera infatti la sovranità tecnologica una proprietà dell’intera catena, dai chip al software, non soltanto della sede fisica nella quale vengono eseguiti i modelli.
Mistral Compute combina risorse GPU per training e inferenza con gli altri livelli della piattaforma. Sul piano operativo integra telemetria relativa a salute delle GPU, consumi, temperatura, errori ECC – Error-Correcting Code e throughput, oltre a metriche per singolo job esportabili verso gli strumenti utilizzati dal cliente. La governance comprende Single Sign-On (SSO), System for Cross-domain Identity Management (SCIM), Role-Based Access Control (RBAC) collegabile agli account del workload manager Slurm, gestione dei secret, key management, audit trail e webhook CI/CD.
Sul fronte della sicurezza, Mistral dichiara segmentazione di rete EVPN-VXLAN, cifratura AES-256 dei dati a riposo con Bring Your Own Key (BYOK) e protocolli definiti per la cancellazione dei dati. Sono elementi rilevanti soprattutto perché Mistral sta cercando di spostare Mistral Compute dal ruolo di semplice fornitore di GPU verso quello di stack infrastrutturale completo per l’AI enterprise.
Le European Compute Units trasformano la domanda in capacità prenotata
Per finanziare e dimensionare questa espansione Mistral introduce anche un meccanismo commerciale denominato European Compute Units (ECU). L’azienda aggrega gli impegni pluriennali di un gruppo di imprese e istituzioni europee e li converte in accesso alla capacità infrastrutturale costruita da Mistral nel corso degli anni.
Le ECU non vengono presentate come una nuova unità tecnica standardizzata per misurare le prestazioni delle GPU. Rappresentano piuttosto un meccanismo contrattuale attraverso il quale la domanda futura contribuisce a determinare quanta capacità costruire, dove localizzarla e a quali organizzazioni assegnarla. Gli aderenti possono poi utilizzare la capacità prenotata sui differenti prodotti disponibili attraverso Mistral Compute, adattandola all’evoluzione dei propri workload.
L’approccio affronta uno dei problemi strutturali dell’infrastruttura AI: un data center con acceleratori di ultima generazione richiede investimenti iniziali elevati, disponibilità energetica, apparati di rete ad alte prestazioni e impegni pluriennali sull’hardware. Aggregare preventivamente domanda industriale consente al provider di costruire capacità contro contratti di lungo periodo, mentre i clienti ottengono una maggiore prevedibilità sull’accesso alle risorse di calcolo.
Intorno all’iniziativa Mistral raccoglie il sostegno di Amadeus, ASML, Capgemini, Caisse des Dépôts e CMA CGM. Christophe Fouquet, CEO di ASML, lega esplicitamente l’investimento infrastrutturale alla capacità europea di sviluppare e utilizzare AI secondo condizioni controllate localmente: “Poche iniziative industriali saranno più importanti per la prossima generazione europea della costruzione della capacità necessaria a sviluppare ed eseguire l’intelligenza artificiale secondo le proprie condizioni”.
La sovranità AI diventa una proprietà dell’intero stack
La strategia di Mistral identifica quindi tre livelli di controllo distinti: la possibilità di scegliere e modificare i modelli, il controllo geografico dell’esecuzione e la disponibilità garantita della capacità fisica necessaria per far funzionare quei modelli. È una definizione di sovranità AI più ampia della semplice residenza del dato e particolarmente rilevante quando gli LLM diventano componenti permanenti dei processi produttivi.
Per un’impresa europea, la differenza è concreta. Un modello open eseguito su un hyperscaler extraeuropeo offre una forma di controllo sul software, ma lascia l’infrastruttura e la capacità nelle mani del provider. Un endpoint europeo mantiene l’inferenza nella regione, senza trasformare automaticamente in regionale l’intero control plane. Una capacità GPU europea dedicata aggiunge un ulteriore livello, perché riduce la dipendenza dalla disponibilità spot di infrastrutture globali. La sovranità effettiva deriva dalla combinazione di questi livelli e dai contratti che ne garantiscono l’applicazione.
Mistral sta cercando di presidiare contemporaneamente tutti questi strati: modelli propri e di terzi, API, inference routing regionale, capacità prioritaria, GPU dedicate e infrastruttura fisica. Il traguardo di 1 GW entro il 2030 estende la strategia oltre la scala di un laboratorio di modelli e la colloca direttamente nel mercato europeo dell’infrastruttura AI, dove la disponibilità di energia, acceleratori, reti e contratti di lungo periodo sta diventando una variabile strategica quanto la qualità dei modelli stessi.
