Tag: Open Source

AI & GENAI, TECH & BUSINESS

Installare LocalAI in azienda in 90 minuti: la guida operativa

Questo articolo è diverso dagli altri che ho scritto in questa serie su AI privata. Gli altri parlano di strategia, architettura, scelte di alto livello. Questo è una guida tecnica step-by-step. Se siete il CTO o il tech lead che ha deciso di portare un ecosistema AI privato dentro l’azienda e volete sapere esattamente cosa fare lunedì mattina per partire, è qui.

Lavoro come cofondatore di LocalAI.io dal 2023, e in questi anni ho visto centinaia di setup in produzione. Ho distillato in questa guida il percorso operativo che, a partire da un Mac Mini M4 Pro o un server Linux base, in 90 minuti porta un’azienda dal “non abbiamo niente” a un ecosistema AI privato completo, con gateway compatibile OpenAI, modello locale funzionante, vector database per il RAG, primo agente che risponde alle domande sui vostri documenti aziendali.

La guida è scritta per chi sa cosa è Docker e ha terminale aperto. Se siete completamente nuovi al mondo dell’infrastruttura container, vi consiglio di lavorare insieme a un developer che vi affianchi sui primi step. Il setup di base è semplice, ma la produzione richiede un occhio operativo.

Prerequisiti hardware e software

Per una prima installazione LocalAI di valutazione, ipotizziamo lo scenario più semplice: un Mac Mini M4 Pro 48 GB. Vanno bene anche un Linux server con almeno 32 GB di RAM, una workstation con RTX 4070 o superiore, oppure un server cloud privato italiano con GPU dedicata. Per produzione su 100+ utenti simultanei serve hardware più potente (vedere la mia guida hardware precedente).

Software preliminare: Docker installato e funzionante (Docker Desktop su Mac, Docker Engine + Compose v2 su Linux), 50 GB di spazio disco libero (i modelli pesano), connessione internet veloce per il primo download dei modelli, terminale e un editor di testo.

Verifica preliminare:

docker --version
docker compose version
df -h

Se Docker non è installato, fermarsi qui e installarlo (su Mac da docker.com, su Linux con i package manager standard). Procediamo assumendo che il setup di base sia pronto.

Step 1: avvio di LocalAI base (15 minuti)

Creiamo la cartella del progetto e il file Docker Compose minimo:

mkdir -p ~/ai-aziendale/{models,data}
cd ~/ai-aziendale

Creiamo il file docker-compose.yml:

services:
  localai:
    image: localai/localai:latest
    container_name: localai
    restart: unless-stopped
    ports:
      - "8080:8080"
    environment:
      - LOCALAI_API_KEY=cambia-questa-chiave-in-produzione
      - MODELS_PATH=/models
      - CONTEXT_SIZE=4096
      - THREADS=8
    volumes:
      - ./models:/models
      - ./data:/data

Se siete su server Linux con GPU NVIDIA, usate l’immagine localai/localai:latest-gpu-nvidia-cuda-12 e aggiungete la configurazione GPU sotto deploy.resources.reservations.devices.

Avviamo il container:

docker compose up -d

Il primo avvio scarica l’immagine, può richiedere 5-10 minuti a seconda della velocità della connessione. Verifichiamo che sia attivo con curl http://localhost:8080/readyz. Se vede risposta OK, LocalAI è in piedi. La Web UI è raggiungibile a http://localhost:8080.

Step 2: scaricare e caricare il primo modello (20 minuti)

LocalAI ha una galleria integrata di modelli pre-configurati. Per partire, scarichiamo Qwen 4 32B-A3B che è la mia raccomandazione di default per la PMI italiana (rapporto qualità/velocità ottimale).

Dalla Web UI: tab Models → cercare “qwen” → cliccare Install sul modello desiderato. In alternativa via CLI:

curl -X POST http://localhost:8080/models/apply 
  -H "Content-Type: application/json" 
  -H "Authorization: Bearer cambia-questa-chiave-in-produzione" 
  -d '{"id": "huggingface@Qwen/Qwen3-32B-A3B-Instruct"}'

Il download impiega 15-20 minuti per un modello da 32B (18 GB di peso quantizzato Q4). Quando il modello è caricato, testiamolo:

curl http://localhost:8080/v1/chat/completions 
  -H "Content-Type: application/json" 
  -H "Authorization: Bearer cambia-questa-chiave-in-produzione" 
  -d '{
    "model": "qwen3-32b-a3b",
    "messages": [
      {"role": "system", "content": "Rispondi in italiano professionale."},
      {"role": "user", "content": "Cosa sai dell AI Act europeo?"}
    ],
    "temperature": 0.7
  }'

Se la risposta arriva, il modello è funzionante. Su un Mac Mini M4 Pro, aspettate 50-70 token al secondo.

Step 3: integrare un’applicazione esistente (10 minuti)

LocalAI espone API completamente compatibili OpenAI. Qualsiasi applicazione che usa la libreria OpenAI può essere ripuntata sostituendo base_url e api_key. Esempio Python:

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:8080/v1",
    api_key="cambia-questa-chiave-in-produzione"
)

response = client.chat.completions.create(
    model="qwen3-32b-a3b",
    messages=[
        {"role": "system", "content": "Sei un assistente aziendale."},
        {"role": "user", "content": "Riassumi il documento allegato in 3 punti."}
    ]
)

print(response.choices[0].message.content)

Da qui in poi, ogni applicazione AI che il vostro team ha sviluppato (chatbot, tool interni, integrazioni con CRM) può essere ripuntata su LocalAI con tre righe di codice. È il vero superpotere dell’API-compatibility: zero refactor.

Step 4: aggiungere il vector database per RAG (20 minuti)

Per RAG (Retrieval Augmented Generation), serve un vector database che indicizzi i documenti aziendali e li recuperi semanticamente durante le query. Qdrant è la scelta più equilibrata oggi.

Aggiungiamo Qdrant al docker-compose.yml:

  qdrant:
    image: qdrant/qdrant:latest
    container_name: qdrant
    restart: unless-stopped
    ports:
      - "6333:6333"
      - "6334:6334"
    volumes:
      - ./qdrant_storage:/qdrant/storage

Restart dei container con docker compose up -d e verifica con curl http://localhost:6333/healthz.

Ora serve un modello di embedding per generare le rappresentazioni vettoriali dei vostri documenti. LocalAI supporta nativamente modelli di embedding. Carichiamo un modello multilingue:

curl -X POST http://localhost:8080/models/apply 
  -H "Content-Type: application/json" 
  -H "Authorization: Bearer cambia-questa-chiave-in-produzione" 
  -d '{"id": "huggingface@BAAI/bge-m3"}'

Step 5: ingestione documenti aziendali (15 minuti)

Carichiamo i documenti aziendali nel vector database. Script Python di esempio per indicizzare una cartella di PDF:

import os
from openai import OpenAI
from qdrant_client import QdrantClient
from qdrant_client.models import VectorParams, Distance, PointStruct
from pypdf import PdfReader
import uuid

openai_client = OpenAI(
    base_url="http://localhost:8080/v1",
    api_key="cambia-questa-chiave-in-produzione"
)
qdrant = QdrantClient(host="localhost", port=6333)

collection_name = "documenti_aziendali"
qdrant.recreate_collection(
    collection_name=collection_name,
    vectors_config=VectorParams(size=1024, distance=Distance.COSINE)
)

docs_folder = "./documenti"
for filename in os.listdir(docs_folder):
    if not filename.endswith(".pdf"):
        continue
    reader = PdfReader(os.path.join(docs_folder, filename))
    for page_num, page in enumerate(reader.pages):
        text = page.extract_text()
        if not text.strip():
            continue
        chunks = [text[i:i+500] for i in range(0, len(text), 500)]
        for chunk in chunks:
            embedding = openai_client.embeddings.create(
                model="bge-m3",
                input=chunk
            ).data[0].embedding
            qdrant.upsert(
                collection_name=collection_name,
                points=[PointStruct(
                    id=str(uuid.uuid4()),
                    vector=embedding,
                    payload={"text": chunk, "filename": filename, "page": page_num}
                )]
            )
print("Indicizzazione completata.")

Questo script va eseguito una volta sui vostri documenti iniziali, poi pianificato per girare quando si aggiungono nuovi documenti (cron job, n8n workflow, manuale).

Step 6: il primo agente RAG (10 minuti)

L’ultimo pezzo: l’agente che usa il vector database per rispondere a domande sui vostri documenti.

from openai import OpenAI
from qdrant_client import QdrantClient

openai_client = OpenAI(
    base_url="http://localhost:8080/v1",
    api_key="cambia-questa-chiave-in-produzione"
)
qdrant = QdrantClient(host="localhost", port=6333)

def chiedi(domanda: str) -> str:
    embedding = openai_client.embeddings.create(
        model="bge-m3",
        input=domanda
    ).data[0].embedding
    
    risultati = qdrant.search(
        collection_name="documenti_aziendali",
        query_vector=embedding,
        limit=5
    )
    
    contesto = "nn".join([r.payload["text"] for r in risultati])
    
    risposta = openai_client.chat.completions.create(
        model="qwen3-32b-a3b",
        messages=[
            {"role": "system", "content": "Rispondi solo sulla base del contesto fornito. Se non sai, dillo."},
            {"role": "user", "content": f"Contesto:n{contesto}nnDomanda: {domanda}"}
        ]
    )
    
    return risposta.choices[0].message.content

print(chiedi("Quali sono le regole sui rimborsi spese?"))

Eseguite lo script e ponete domande sui documenti che avete indicizzato. Se le risposte sono accurate, avete un primo agente AI RAG funzionante.

Da prototipo a produzione: cosa manca ancora

Quello che abbiamo costruito in 90 minuti è un prototipo funzionante. Per portarlo in produzione su 50-200 utenti aziendali servono altri tre componenti che vale la pena pianificare subito.

Autenticazione e gestione utenti. Il setup base usa una API key condivisa. In produzione serve SSO (Okta, Azure AD, Google Workspace), oppure almeno un sistema di user management. LocalAI supporta multi-tenancy nativo, va configurato.

Frontend. Per gli utenti finali serve un’interfaccia. Open WebUI è la scelta più rapida (compatibile OpenAI, si integra con LocalAI in cinque minuti). In alternativa, sviluppate un’interfaccia custom usando librerie come Vercel AI SDK o LangChain.

Monitoraggio e logging. Per l’AI Act servirà logging strutturato di tutte le interazioni, metriche di performance, alert su anomalie. LocalAI esporta metriche Prometheus, che potete agganciare a Grafana per dashboard di monitoraggio. Per il logging completo, vale la pena integrare un sistema come Langfuse o un equivalente custom.

Backup e disaster recovery. I modelli pesano decine di GB e sono difficili da redownlodare velocemente. Il vector database con i vostri documenti indicizzati è ancora più critico. Pianificare backup periodici delle cartelle models/ e qdrant_storage/.

Stack alternativo e specializzazioni

Lo stack base che ho descritto va bene per la PMI italiana media. Per scenari più specifici:

Per aziende che vogliono modelli multipli in parallelo (uno per chat, uno specializzato per estrazione strutturata, uno per codice): LocalAI gestisce nativamente più modelli, basta caricarli tutti e routare le richieste applicativamente.

Per workload server con alta concorrenza (200+ utenti simultanei): valutare vLLM come motore di inferenza sotto LocalAI, oppure deployment distribuito su più nodi GPU.

Per fine-tuning su dati aziendali specifici: LocalAI supporta fine-tuning LoRA. Setup più complesso, vale la pena partire dal supporto della community o di chi conosce il dominio.

Cosa fare nei prossimi 30 giorni

Una volta avviato lo stack di base, vale la pena pianificare le prime quattro settimane di adozione interna con metodo.

Settimana 1: setup completo (i 90 minuti di questa guida), indicizzazione di un primo corpus documentale ristretto (es. policy HR, FAQ tecniche), test con 3-5 utenti early adopter del team interno.

Settimana 2: raccolta feedback, miglioramento del system prompt, espansione del corpus a documenti aggiuntivi, prima integrazione con un sistema aziendale (CRM, helpdesk).

Settimana 3: apertura a 10-20 utenti, monitoraggio metriche (latenza, qualità delle risposte, errori), aggiunta del frontend Open WebUI o equivalente.

Settimana 4: valutazione roll-out più ampio, definizione del piano di scalabilità (più hardware, più modelli, integrazione con SSO aziendale), pianificazione governance.

Per chi sta valutando l’avvio di un ecosistema AI privato aziendale e vuole supporto operativo, c’è la pagina Advisory dove descrivo i formati di collaborazione che propongo. Per la community LocalAI in italiano, il canale Discord di LocalAI.io è il posto giusto.

La domanda finale, quella che cambia il modo di fare AI aziendale nei prossimi 12 mesi, è semplice. Lunedì mattina, avete in casa il vostro primo endpoint AI privato funzionante? Se la risposta è no, questa guida vi dà tutto quello che serve per cambiarla entro le 12.

AI & GENAI, TECH & BUSINESS

Guerra dei prezzi AI: la difendibilità si sposta sul controllo dell’inferenza

Il 13 giugno il Wall Street Journal ha raccontato la fuga verso i modelli cinesi: aziende e startup, sfiancate dal conto dei token, che spostano i carichi di lavoro su alternative più economiche e quasi sempre open source. Bradley Olson racconta di strumenti che fanno rimbalzare il lavoro da un modello all’altro, Claude o ChatGPT per i compiti che lo meritano, modelli aperti per tutto il resto. OpenAI e Anthropic, tutte e due con il fascicolo per la quotazione già depositato, stanno valutando di tagliare i prezzi.

Sotto la cronaca del taglio c’è un movimento più lento, e per chi quei sistemi li mette in produzione conta molto di più. La guerra dei prezzi AI sta spaccando il mercato in due, e le due metà non si difendono allo stesso modo. Da una parte i volumi, che scivolano verso il basso costo. Dall’altra il valore, che resta in alto, dove le capacità di frontiera sono ancora poche e ancora difficili da replicare.

I volumi seguono i modelli cinesi

Il pavimento dei prezzi lo ha colato DeepSeek, e da lì in giù si è mosso tutto il resto. Su OpenRouter, la piattaforma di instradamento che migliaia di sviluppatori usano per scegliere a chi mandare le proprie richieste, i modelli cinesi pesano oggi intorno al 46% del traffico identificato. Anthropic, Google e OpenAI messe insieme stanno sotto al 36. Un anno fa i cinesi erano sotto il due per cento. Qwen, DeepSeek, Kimi, GLM, MiniMax: nomi che fino a poco fa nessun ufficio acquisti pronunciava, e che adesso girano dentro metà dei flussi agentici del pianeta.

La ragione è prosaica, e la dice bene un investitore citato nel pezzo, Tommy Shaughnessy di Delphi: il modello è il costo più grosso per chi vende inferenza, e questi se lo ritrovano gratis. I laboratori cinesi rilasciano modelli di livello frontiera come pesi aperti, chi fa inferenza li serve a costo quasi azzerato, e il prezzo finale crolla a una frazione, da sette a cinquanta volte meno a seconda del confronto che si fa. Per moltissimo lavoro quotidiano, una sintesi o una classificazione o una bozza da rifinire, la differenza di qualità tra i modelli cinesi e quelli di punta semplicemente non si vede in busta paga. E nel frattempo i conti dei token diventano insostenibili: c’è chi, come Uber, ha bruciato l’intero budget AI dell’anno entro aprile.

Il prezzo basso ha un indirizzo

Un modello che costa quasi niente è comodo, fino al momento in cui ti accorgi da dove arriva, e che quel quasi niente per chi lo produce ha una funzione. GLM-5 di Zhipu è addestrato e servito su silicio Huawei Ascend, niente NVIDIA: per le imprese e gli enti cinesi quell’indipendenza dall’hardware americano vale più di un punto di benchmark. Distribuire frontiera come open weight, a costo zero per il mondo, è anche una mossa di quota e di influenza, un loss leader giocato su scala geopolitica.

Negli Stati Uniti la cosa ha già smesso di essere teorica. Ad aprile la commissione della Camera sul Partito Comunista Cinese ha aperto un’indagine su Airbnb e Anysphere per l’uso di modelli cinesi, segno che dentro un’app che usi ogni giorno può girare inferenza che a qualcuno, a Washington, non piace affatto. E l’Europa, in questa mappa, è quasi un buco: tanti utilizzatori, pochissimi produttori, con Mistral come eccezione più citata che strutturale. Dipendere da una sola sponda è un rischio già scomodo. Appoggiare il proprio lavoro su due sponde lontane, e su nessun pezzo di casa, è una postura che vale la pena guardare prima che diventi un vincolo.

Il routing come punto di controllo

Lo strumento che il Wall Street Journal descrive, quello che smista il lavoro tra modello esterno, sistema interno e open source self-hosted, è la cosa più importante dell’articolo, e quasi nessuno la nomina. Nel momento in cui i modelli diventano intercambiabili e quasi gratuiti, il pezzo di valore si sposta su chi decide dove va ogni richiesta, con quali regole, con quali dati, dentro quali confini. Orchestrazione, routing, inferenza locale: qui si gioca il margine, e qui si gioca la difendibilità.

È lo stesso filo che avevo provato a tirare quando una direttiva americana ha spento Fable 5 e Mythos 5 in tutto il mondo: in produzione vince meno il modello migliore e vince di più chi controlla l’instradamento e tiene l’inferenza vicina. Per chi compra in azienda, e ancora di più per una pubblica amministrazione o un settore regolato, questo livello smette di essere un dettaglio da architetti e diventa oggetto di governance, e materia da mettere a gara: la domanda da scrivere nel capitolato diventa chi orchestra, dove gira il carico, cosa esce dal perimetro, più che quale modello ci sia in fondo. È esattamente la direzione di prodotto su cui lavoro con LocalAI, inferenza che resta dentro casa.

La frontiera resta un permesso, non una proprietà

L’altra metà del cielo, quella del valore, ha una sua fragilità che il prezzo basso ci fa dimenticare. Le capacità di punta restano accessibili a condizioni decise da altri. Anthropic ha pubblicato la classe Mythos con due nomi e due regole: Fable con i guardrail, che dirotta le richieste su cyber, bio e chimica verso un modello più sorvegliato, e Mythos vero e proprio, senza freni pubblici, riservato a un programma ristretto. Sopra questa scelta industriale è arrivata la geopolitica, con il blocco all’export che ha staccato i modelli di frontiera dal resto del mondo da un giorno all’altro.

Chi costruisce sopra una API di frontiera costruisce sopra un permesso. Un permesso ottimo, potente, conveniente finché dura, e revocabile per ragioni che non dipendono da te: una direttiva o una decisione di sicurezza nazionale presa in un fuso orario lontano. Tenere tutto il valore della propria azienda dentro quel permesso è una scommessa che in pochi farebbero a occhi aperti, se la guardassero per quello che è.

Costruire da qui con quello che si controlla

Da questa biforcazione non si esce scegliendo una metà contro l’altra. La frontiera serve, per i compiti dove la differenza si vede e si paga. L’open economico serve, per il volume. Quello che cambia è dove si mette il proprio baricentro, e quanto del proprio destino si lascia in mano a un listino o a un permesso altrui.

Per un’organizzazione che parte adesso, e parte da qui, il punto fermo viene prima della tecnologia. Prima il metodo, la mappa di quello che quel processo fa davvero, di quali dati non possono uscire, di dove la frontiera vale il prezzo e dove i modelli cinesi aperti bastano e avanzano. Poi la tecnologia, scelta su quella mappa: orchestrazione propria, inferenza che si può portare in casa, libertà di cambiare modello senza riscrivere l’azienda. In Pelle Digitale avevo descritto la tecnologia come una superficie che ci portiamo addosso, e una pelle si sceglie con cura, non si appalta al primo che la regala. La velocità di mettere AI in produzione, ormai, ce l’avranno tutti. La difendibilità, quella, resta di chi controlla il proprio stack.

Senza dubbio la domanda che lascio aperta è semplice: del valore che la tua azienda affida all’AI, quanta parte vive su qualcosa che puoi spegnere tu, e quanta su qualcosa che possono spegnere altri?

AI & GENAI, TECH & BUSINESS

Anthropic spegne Fable 5 e Mythos 5: open weights di frontiera e sovranità tecnologica

Venerdì sera, ora di Washington, Anthropic ha disattivato i suoi due modelli più capaci, Claude Fable 5 e Claude Mythos 5, per tutti i clienti del mondo, e il dibattito sugli open weights è ripartito di colpo. A tre giorni dal lancio. La causa è una direttiva di export control del governo americano, che vieta l’accesso a qualsiasi cittadino straniero, dentro e fuori dagli Stati Uniti, compresi i dipendenti stranieri della stessa azienda. Una conformità selettiva era impossibile, l’interruttore è stato abbassato per chiunque, ovunque, e in molti hanno letto il blocco come la spinta che mancava verso i modelli open weights. I due modelli erano disponibili da pochi giorni, ed è la prima volta che una direttiva di questo tipo colpisce così, in una sera, i modelli di punta di un laboratorio americano.

Ethan Mollick, su LinkedIn, ha scritto una previsione che va nella direzione opposta.

Il blocco non porterà più modelli a pesi aperti. Semmai, scrive Mollick, vedremo la fine dei modelli di frontiera open weights. Il ragionamento è lineare: se un modello di classe Mythos è considerato rischioso, neanche la Cina avrà interesse a lasciarlo aperto, e un modello del genere non lo costruisci senza una concentrazione di calcolo che sta dentro un Paese, visibile e regolabile.

Ho lasciato un commento sotto il suo post, e provo qui ad allargarlo.

Sul meccanismo Mollick ha ragione, per la punta assoluta. Sulla conclusione servono due correzioni, e tutte e due portano esattamente dove passo le mie giornate, l’inferenza locale e la sovranità tecnologica, il lavoro che faccio in LocalAI.

La logica del footprint tiene

Un modello al vertice della capacità oggi nasce da una concentrazione di GPU che occupa data center fisici, dentro una giurisdizione precisa, con consumi, forniture e contratti tracciabili. La definizione che gira da tempo nei documenti regolatori è quella di calcolo regolabile, regulatable compute: un addestramento al vertice lascia tracce fisiche, il consumo elettrico fuori scala, le dimensioni dei data center, l’acquisto di decine di migliaia di acceleratori, e tutto questo uno Stato lo identifica e lo raggiunge. Le stesse restrizioni americane sull’export dei chip più avanzati esistono perché quel calcolo si vede, si conta, si può fermare a monte. Venerdì lo Stato lo ha fatto, in una sera.

Un modello aperto da sette o settanta miliardi di parametri, invece, una volta scaricato vive di vita propria, e una copia su un portatile non si richiama indietro con una direttiva. È la differenza che molti hanno colto subito, chi tiene i pesi in locale non se li vede togliere da nessun governo. Mollick anticipa l’obiezione cinese, e fa bene. Al vertice vero, quello dei modelli più potenti in assoluto, nessuno dei due blocchi ha convenienza a far circolare i pesi liberamente. Su questo gli concedo tutto, il tetto si chiude su entrambi i lati.

Dall’1,2% a quasi il 30% in un anno

La parola «frontiera», però, nel suo post indica il soffitto, la classe Mythos. La capacità che muove davvero l’adozione sta un gradino sotto, nel near-frontier, più che sufficiente per quasi tutto quello che le aziende fanno ogni giorno: estrarre dati da un contratto, classificare richieste, alimentare un sistema RAG, scrivere bozze, far girare agenti su compiti delimitati. Per questi lavori la distanza dal soffitto si è assottigliata fino a diventare irrilevante, e il modello più potente in assoluto non cambia l’esito di un’estrazione di campi o dello smistamento di un ticket. E lì la Cina accelera, in chiaro.

Qwen di Alibaba, Kimi di Moonshot, GLM di Zhipu, DeepSeek, e da inizio giugno MiniMax con il suo M3, presentato come primo modello di frontiera open weights che tiene insieme coding di alto livello, un milione di token di contesto e input multimodale. I numeri raccontano lo spostamento meglio di qualsiasi tesi. Uno studio di OpenRouter su centomila miliardi di token, ripreso insieme ad Andreessen Horowitz, misura la quota dei modelli open source cinesi sull’uso globale degli LLM salita da circa l’1,2% di fine 2024 a quasi il 30% un anno dopo. Il paper della Commissione USA-Cina di marzo riporta una stima di un partner di a16z secondo cui intorno all’ottanta per cento delle startup americane costruisce su modelli base cinesi, e segnala che tra novembre e dicembre 2025 sette dei dieci modelli più scaricati su Hugging Face venivano da laboratori cinesi. I modelli proprietari occidentali restano davanti, intorno al settanta per cento dell’uso complessivo, ma la pendenza della curva aperta è tutta da una parte. L’adozione poi si autoalimenta, più sviluppatori scaricano un modello e più nascono strumenti, integrazioni e materiali intorno, e più quel modello diventa la scelta ovvia per il progetto successivo. È un volano che lavora a favore di chi pubblica i pesi, e in questo momento a pubblicarli con più aggressività è la Cina.

Fine del frontier open weights occidentale

A chiudersi, allora, non è il layer aperto, è la sua sponda occidentale. Se gli Stati Uniti regolano chiuso il proprio gradino alto e l’Europa continua a scivolare fuori dai vertici, con Mistral che esce dai primi posti tra i laboratori di punta, lo strato aperto del near-frontier non sparisce, passa di mano. Passa ai laboratori cinesi, che lo tengono aperto proprio perché l’apertura è una leva competitiva contro le API chiuse americane, un modo per entrare negli stack di tutto il mondo mentre l’alternativa si blinda.

Il blocco ha messo in chiaro un contrasto che diversi osservatori hanno colto subito. Un modello di frontiera open weights come M3 lo scarichi e lo fai girare sul tuo hardware, e nessun governo te lo spegne a distanza, mentre due modelli di punta serviti da un endpoint centralizzato sono spariti per chiunque nel giro di una sera. La parte scomoda della previsione di Mollick è questa: una chiusura del vertice occidentale dettata dalla sicurezza può consegnare lo standard aperto a Pechino, e regalare a un concorrente sistemico la posizione di default su cui costruiscono sviluppatori e imprese.

Per l’Europa la posta è alta. Se lo strato aperto che entra negli stack diventa cinese, l’autonomia digitale che il continente insegue da anni si ritrova a poggiare su modelli sviluppati sotto un’altra giurisdizione, con un’altra catena di fornitura e un altro sistema di valori a monte. Mistral resta la carta europea più seria, e proprio per questo il suo arretramento dai vertici pesa oltre il singolo laboratorio. La sovranità tecnologica, in questo scenario, smette di essere una parola da convegno e diventa una scelta su quale ecosistema di modelli vuoi poter usare anche tra cinque anni.

Una sera è bastata a spegnere due modelli

Qui arriva la parte che vedo meglio dal mio mestiere. Per il valore che conta in produzione, la capacità di frontiera non è mai stata l’elemento che fa la differenza. In produzione la differenza la fa la continuità del servizio, e una sera come quella di venerdì la mette alla prova più di qualsiasi benchmark. Due modelli spariti per direttiva, a tre giorni dal lancio, con Amazon a cui è stato chiesto di revocare l’accesso in tutte le regioni, e nessuno dei clienti che ci aveva costruito sopra un processo ha avuto voce in capitolo.

È una traiettoria, più che un episodio isolato. Il Dipartimento della Difesa aveva già etichettato Anthropic come rischio per la catena di fornitura, e l’azienda ha aperto un contenzioso contro quella classificazione. Quando un fornitore si trova in mezzo a una tensione del genere, la volatilità regolatoria smette di essere un’ipotesi da slide e diventa una variabile operativa. E c’è un secondo lato, speculare, se l’ottanta per cento delle startup americane gira su modelli cinesi quell’esposizione un domani può diventare a sua volta oggetto di una direttiva: la dipendenza da un fornitore lontano è un rischio qualunque sia la bandiera del fornitore. La lezione che le aziende portano a casa questa settimana è architetturale, serve un disegno capace di reggere il momento in cui un down o un blocco arrivano davvero. Ne avevo scritto guardando alle opzioni di self-hosting con Mistral, e quel ragionamento oggi vale per chiunque appoggi un processo critico su un solo fornitore lontano.

Routing e inferenza locale, il livello che resta tuo

L’architettura che regge a tutto questo è agnostica rispetto al modello: un livello di astrazione e di routing che, nel momento esatto in cui qualcosa a monte si rompe, sposta il traffico da un’API di frontiera a un modello aperto che gira in casa. È quello che costruiamo in LocalAI, un motore open source che funziona come sostituto diretto delle API di OpenAI e di Anthropic, così lo stesso codice che ieri chiamava Fable 5 oggi può chiamare un Qwen o un DeepSeek sul tuo hardware, CPU compresa, senza che i dati escano dalla tua infrastruttura, con agenti, RAG e supporto MCP già dentro. In termini concreti cambi l’indirizzo dell’endpoint e la chiave, non l’applicazione che ci sta sopra.

La spinta verso questo disegno non arriva solo da chi vende inferenza locale. VentureBeat, commentando proprio questo blocco, indica come via più resiliente un’architettura a fallback attivo, con sistemi pensati per essere agnostici rispetto al modello e livelli di routing intelligenti che spostano il traffico da un modello di frontiera a un fallback a pesi aperti nell’istante in cui arriva un’interruzione o un divieto. Nello stesso caso Anthropic, per non lasciare tutto fermo, ha dirottato le richieste sopravvissute su Opus 4.8, un modello meno capace ma ancora acceso. Lo ha fatto perché quando il vertice si spegne serve comunque un posto dove ricadere, e quel posto, se è davvero tuo, non te lo toglie nessuno.

Compatibilità diretta vuol dire usare gli stessi SDK e la stessa struttura di chiamata, e il livello di routing decide richiesta per richiesta dove mandare il lavoro, in base a quanto è sensibile il dato, al costo e a quanto serve davvero la potenza del modello più grande. Una bozza interna resta in casa su un modello locale, una sintesi complessa può salire sul cloud di frontiera, e se quel cloud non risponde il traffico ricade sul locale senza che l’utente se ne accorga. Per banche, sanità e pubblica amministrazione lo stesso motore gira on premise o in ambienti isolati dalla rete, dove il dato non ha proprio il permesso di uscire.

Il lock-in vero, quello che fa fallire le migrazioni, vive oltre il modello, negli embedding, nel database vettoriale, nella logica di orchestrazione che hai cucito addosso a un fornitore. Possedere il livello di astrazione significa poterli sostituire un pezzo alla volta, senza riscrivere tutto. E sul costo cambia la natura della spesa, l’inferenza locale ha un costo prevedibile legato all’hardware, più che una bolletta a consumo che cresce con l’uso e che un fornitore può ritoccare quando vuole. È la stessa famiglia di strumenti, da LocalAI a LocalAGI fino a LocalRecall, di cui avevo raccontato il senso più ampio parlando di pelle digitale e di agenti autonomi.

Gli agenti rendono il problema più grave

C’è un livello in cui tutto questo pesa il doppio, ed è quello degli agenti. Un agente che dipende da una sola API di frontiera per pianificare i passi e chiamare gli strumenti si ferma del tutto nel momento in cui quell’API viene tagliata, e non si ferma una funzione, si ferma il processo che gli avevi delegato per intero. Più l’agente è autonomo e incastrato nei flussi di lavoro, più alto è il costo di un’interruzione improvvisa, perché hai spostato sul modello non una risposta ma una catena di decisioni.

Un livello di routing con fallback locale è quello che permette a un agente di degradare con grazia, passando a un modello che gira in casa e continuando a lavorare, magari un po’ più lento, invece di spegnersi a metà. È una delle ragioni per cui LocalAGI sta sopra LocalAI, l’orchestrazione degli agenti vale finché sotto c’è un’inferenza che non puoi perdere da un momento all’altro.

La difendibilità si sposta dal modello al controllo

Da mesi insisto su una tesi che questa settimana trova una conferma sgradevole. Quando la capacità di frontiera diventa una merce che si affitta, finché non te la spengono, «avere il modello migliore» smette di essere un fossato difensivo. L’asset che resta difendibile è il controllo, sull’inferenza, sul luogo dove vivono i dati, sul livello di routing che tiene in piedi tutto il resto. La capacità la noleggi in un pomeriggio, il controllo te lo costruisci, e per questo vale di più.

Per l’Italia e per l’Europa la cosa non è teorica. Gli obblighi dell’AI Act per i sistemi ad alto rischio arrivano in pieno il 2 agosto 2026, con gestione del rischio, governance del dato, tracciamento e sorveglianza umana da dimostrare, il GDPR rende il luogo del dato una questione legale prima ancora che tecnica, e la spinta sul cloud sovrano sta già ridisegnando quali fornitori possono servire i progetti pubblici. Uno stack che possiedi risponde alle tre cose insieme, compliance, residenza del dato e continuità, e lo fa senza dover sperare che il fornitore a monte non cambi idea.

In pratica si parte mappando le dipendenze AI che hai, processo per processo, per sapere cosa si ferma se un fornitore sparisce. Da lì si introduce un livello di astrazione e di routing tra le applicazioni e i modelli, si tiene pronto un fallback locale per i carichi critici e per i dati sensibili, e si comincia a trattare l’inferenza come si tratta l’energia di un’azienda, con una fornitura principale e una riserva che non dipende da lei. Nessuno di questi passi richiede di rinunciare ai modelli di frontiera quando servono davvero, chiede solo di non restarne prigionieri.

La cosa che mi resta addosso, finita questa settimana, non è la geopolitica del calcolo. È quanta parte della nostra intelligenza operativa giri già su un interruttore tenuto da qualcun altro. Ci siamo affezionati a capacità che non possediamo, che possono cambiare, scadere o essere spente da lontano, e in Pelle Digitale avevo provato a dire che la tecnologia che ci estende è anche la tecnologia che ci espone, ogni volta che rinunciamo a governarla. Possedere il livello che ti tiene acceso sta diventando una scelta quotidiana, da rifare ogni mattina invece di darla per acquisita. Senza dubbio è la domanda che porto in ogni tavolo in queste settimane, quanta della tua intelligenza operativa sei disposto a lasciare su un interruttore che non tieni in mano?

Fonte: Ethan Mollick, post su LinkedIn, 12 giugno 2026. Sui fatti del blocco: comunicato di Anthropic, CNBC, Tom’s Hardware, VentureBeat. Sui dati di mercato: OpenRouter e Andreessen Horowitz, paper della Commissione USA-Cina (USCC).

AI & GENAI, TECH & BUSINESS

Mistral vs Llama vs Qwen vs DeepSeek: quale per l’azienda

Tre anni fa, “modello open-source” significava roba di nicchia per ricercatori. Llama 1 di Meta aveva 65 miliardi di parametri, performance discrete sui benchmark, e una licenza che non ti permetteva di usarlo commercialmente. Il resto era praticamente esercizio accademico. Nel maggio 2026 il panorama è cambiato in modo radicale. Quattro famiglie di modelli open-weight competono testa a testa con i top di gamma proprietari (Claude Opus, GPT-5, Gemini Pro) su task specifici, e per le aziende italiane che vogliono fare AI privata sono diventate la scelta di default invece dell’eccezione.

Ho ricevuto la stessa domanda due volte questa settimana, una da un CTO di un’azienda manifatturiera lombarda e una da un’innovation manager di una banca italiana di medie dimensioni: “Tutti dicono Llama, ma davvero è la scelta giusta per noi?”. La risposta breve è “dipende”, e in questo articolo provo a sciogliere quel dipende.

I quattro modelli che vale la pena considerare seriamente oggi sono: Llama di Meta (americano, ampia diffusione, ecosistema enorme), Mistral di Mistral AI (francese, alleato europeo, focus enterprise), Qwen di Alibaba (cinese, performance al top sui benchmark, costi infrastrutturali bassi), DeepSeek (cinese, reasoning forte, prezzi aggressivi). Provo a confrontarli sui cinque criteri che contano davvero per chi deve prendere una decisione enterprise.

La lingua italiana, prima di tutto

Per le aziende italiane c’è un problema spesso sottovalutato: la qualità della lingua italiana del modello. I benchmark internazionali sono quasi tutti in inglese, e un modello che fa 92 su MMLU in inglese può fare 78 in italiano. Per chi costruisce un agente AI interno che parla con i propri dipendenti, questa differenza si sente nella qualità delle risposte.

I quattro modelli si comportano in modo abbastanza diverso su italiano. Mistral, essendo francese, ha l’italiano nel core training data fin dalle prime versioni, e produce un italiano molto naturale, con sfumature idiomatiche credibili. Llama 3.3 ha migliorato significativamente l’italiano rispetto a Llama 2, ma resta sotto Mistral nelle situazioni complesse (contratti legali, terminologia tecnica specifica). Qwen 4 fa un italiano sorprendentemente buono nelle versioni recenti, soprattutto sui task strutturati, anche se ogni tanto introduce piccoli calchi grammaticali dal cinese che un madrelingua riconosce. DeepSeek è il più debole sull’italiano della categoria, va bene per task tecnici e codice ma spesso suona “tradotto” sul conversazionale.

La mia regola pratica: se l’agente AI deve parlare con i vostri dipendenti italiani in modo fluido, Mistral o Llama. Se l’agente fa task back-end strutturati (estrazione dati, classificazione, codice), Qwen o DeepSeek vanno benissimo. Se siete bilingue inglese-italiano in azienda, qualsiasi dei quattro va bene.

Qualità delle risposte sui task aziendali tipici

I benchmark accademici (MMLU, GSM8K, HumanEval) sono utili come riferimento generale, ma non vi dicono se un modello vi serve in produzione. Per chi vuole capire cosa scegliere per la propria azienda, vale la pena testare quattro categorie di task che tornano spesso.

Sintesi e analisi documentale. Tutti e quattro i modelli, nelle loro versioni 70B+, fanno bene questo task. Mistral Large 3 e Llama 3.3 70B sono praticamente equivalenti sui documenti aziendali italiani. Qwen 4 70B è leggermente più conciso, può andare bene o male a seconda dello stile che cercate. DeepSeek V3 fa molto bene su documenti tecnici e meno bene su prosa argomentativa.

Estrazione strutturata. Quando dovete estrarre dati strutturati da testo libero (campi di un contratto, voci di una fattura, entità da una mail), i modelli si differenziano per affidabilità. Qwen 4 e DeepSeek vincono qui, perché hanno una propensione al rigore strutturale che è perfetta per output JSON, function calling, schema fissi. Llama e Mistral fanno discretamente, ma con tasso di hallucination sui campi vuoti più alto.

Generazione di codice. Categoria dove DeepSeek brilla con il suo modello specializzato Coder, che compete direttamente con Claude Sonnet sui task di programmazione. Qwen 4 Coder è il secondo. Mistral Codestral è solido. Llama 3.3 fa il codice meno bene degli altri tre.

Conversazione lunga e ragionamento. Per agenti AI con conversazioni multi-turno complesse, ricerca multi-step, ragionamento articolato, i modelli reasoning sono la categoria giusta. DeepSeek R2 è il leader open-weight della categoria, eccellente su reasoning matematico e logico. Qwen 4 con thinking mode è il secondo. Mistral e Llama nelle versioni standard sono più orientati al chat istantaneo, meno al reasoning profondo.

Hardware necessario e costi infrastrutturali

I quattro modelli pesano in modo diverso sulla vostra infrastruttura. È un fattore che le aziende spesso valutano in secondo piano e che diventa importante quando si passa dalla demo alla produzione su volumi reali.

Llama 3.3 70B in Q4 quantizzato pesa circa 40 GB di RAM/VRAM. Gira bene su Mac Studio M4 Max 128 GB (30-45 tok/s), su server con 2x RTX 4090 (50-70 tok/s), su singola H100 (90-120 tok/s).

Mistral Large 3 (123 miliardi parametri) è significativamente più pesante. Richiede 70+ GB di memoria, quindi Mac Studio 128 GB o server NVIDIA con almeno 80 GB di VRAM (H100, due 5090 in tandem). Performance: 15-25 tok/s sul Mac, 60-90 tok/s su H100.

Qwen 4 32B-A3B è la sorpresa positiva. È un modello MoE (Mixture of Experts) da 32 miliardi totali con solo 3 miliardi attivi per token. Pesa circa 18 GB ma è veloce come un modello da 7B in inferenza. Sul Mac Mini M4 Pro 48 GB arriva a 50-70 tok/s con qualità di output che compete con modelli 70B densi. È il modello più “efficiente per dollaro” che ho visto nel 2026.

DeepSeek V3 è grande (671B parametri totali, 37B attivi MoE), richiede infrastruttura server seria. Non gira su consumer Mac. Per molte PMI italiane è sovradimensionato.

Calcolando il costo infrastrutturale per servire 100 utenti aziendali simultaneamente in produzione:

  • Qwen 4 32B-A3B: 2.000-4.000 euro hardware
  • Llama 3.3 70B: 5.000-10.000 euro hardware
  • Mistral Large 3: 15.000-30.000 euro hardware
  • DeepSeek V3 full: 40.000+ euro hardware

Licensing e implicazioni geopolitiche

Per le aziende italiane, soprattutto quelle che lavorano con PA o settori regolati, la provenienza geografica del modello inizia a contare.

Llama ha una licenza commerciale aperta che permette praticamente qualsiasi uso (con il limite delle aziende con oltre 700 milioni di utenti attivi, che è un caso che riguarda Meta stessa, non voi). È un modello americano, sviluppato da Meta, distribuito sotto Llama Community License.

Mistral è francese, distribuito sotto Apache 2.0 per le versioni open-weight (Mistral 7B, Mixtral, alcune varianti). Le versioni più recenti come Mistral Large 3 sono proprietarie con API a pagamento ma con opzione enterprise on-premise. Per le aziende italiane che vogliono restare nel perimetro europeo, Mistral è la scelta naturale dal punto di vista geopolitico.

Qwen è di Alibaba, distribuito sotto Apache 2.0 (le versioni più recenti) o Tongyi Qianwen License (alcune varianti). I modelli sono completamente utilizzabili commercialmente. La provenienza cinese può essere un problema per aziende che lavorano con PA, difesa, settori sensibili. Per la maggior parte delle aziende manifatturiere o servizi italiane non c’è alcun problema operativo, ma è un fattore che alcuni board considerano.

DeepSeek è cinese (Hangzhou), distribuito sotto MIT license (più permissiva di Apache 2.0 in alcuni dettagli). Stesse considerazioni geopolitiche di Qwen.

La domanda non è “il modello cinese può rubare i miei dati”: tutti i modelli open-weight girano sul vostro hardware, quindi i dati non escono di un millimetro. La domanda è di posizionamento aziendale: alcune RFP italiane di settore difesa o PA cominciano a escludere esplicitamente componenti software cinesi.

Aggiornamenti e supporto della community

Un fattore spesso sottostimato: come evolve il modello nei prossimi anni? Acquistare hardware oggi per girarci sopra un modello che non viene più aggiornato è un investimento dimezzato.

Llama ha rilasciato versioni nuove ogni 6-9 mesi (Llama 1, 2, 3, 3.1, 3.2, 3.3, e Llama 4 è atteso entro fine 2026). Meta investe tantissimo nell’ecosistema, e la community Hugging Face ha le fine-tunate Llama più estese al mondo. Roadmap solida.

Mistral rilascia con cadenza simile, ma sta progressivamente spostando i modelli più nuovi su licenze proprietarie con accesso commerciale a pagamento. Per chi vuole stare sull’open-weight puro, Mistral si è un po’ rallentato come strategia. L’azienda è solida però (round di finanziamento da 2 miliardi nel 2024), quindi non c’è rischio sostenibilità.

Qwen è quello che evolve più velocemente. Alibaba sta investendo aggressivamente, e Qwen rilascia nuove versioni ogni 2-3 mesi. La velocità di iterazione è impressionante.

DeepSeek ha sorpreso tutti nel 2025 con la versione R1 che competeva con OpenAI o1 su benchmark di reasoning. Sta continuando a rilasciare aggiornamenti, anche se la sostenibilità a lungo termine del progetto è meno chiara di Meta o Alibaba.

La scelta concreta per tre profili aziendali italiani

Provo a tradurre i criteri sopra in tre raccomandazioni operative.

Per la PMI italiana media (50-300 dipendenti, AI per processi interni, no settori sensibili): Qwen 4 32B-A3B è la scelta di default oggi. Costa poco in hardware, gira veloce su un Mac Studio o un workstation modesto, l’italiano è buono per la maggior parte dei task aziendali, ha aggiornamenti frequenti. Se l’agente AI fa molto codice o estrazione strutturata, valutate anche DeepSeek Coder come modello specializzato accanto a Qwen.

Per l’azienda media-grande con focus su lingua italiana e mercati europei (settore retail, media, hospitality, servizi B2C): Mistral Large 3 è la scelta giusta. Italiano impeccabile, posizionamento europeo, supporto enterprise dedicato. Costa di più in hardware (15-30k euro per servire bene 100+ utenti) ma per chi ha quel budget vale.

Per banche, sanità, PA, difesa, manifattura strategica (settori regolati con sensibilità geopolitica): Llama 3.3 70B o Mistral Large 3. Llama per costo infrastrutturale più contenuto e ecosistema ampio, Mistral per posizionamento europeo. Evitate Qwen e DeepSeek se la vostra controparte ha sensibilità sul tema “componenti cinesi”.

Il valore di poter cambiare modello senza riscrivere

Una considerazione che vale per tutti i profili sopra: i quattro modelli open-weight evolvono velocemente, e il modello migliore di oggi probabilmente non sarà quello di fra dodici mesi. Llama 4 è atteso a fine 2026, Mistral sta preparando le sue prossime versioni, Qwen e DeepSeek rilasciano ogni pochi mesi.

Le aziende che costruiscono il proprio stack AI con un layer di astrazione (un orchestratore che espone API compatibili OpenAI come LocalAI.io, di cui sono cofondatore) riescono a cambiare il modello sotto senza ritoccare le applicazioni. Le aziende che si legano a un modello specifico in modo profondo (prompt engineerizzati su quirk specifici di Mistral, function calling con sintassi proprietaria di Qwen, fine-tuning legato a Llama 3.3) si ritrovano a fare la migrazione manuale ogni volta che esce un modello migliore. La differenza, su tre anni, vale settimane di lavoro di sviluppo.

LocalAI è progettato esattamente per questo: gestisce in parallelo Llama, Mistral, Qwen, DeepSeek e tutti i loro fine-tuned, espone un unico endpoint compatibile OpenAI, permette di fare A/B testing fra modelli, di routare task diversi a modelli diversi (Qwen per estrazione strutturata, Mistral per conversazione italiana, DeepSeek per codice), di aggiornare il modello sotto senza che le applicazioni se ne accorgano. È il single point of integration che rende la vostra architettura AI flessibile invece di rigida.

Per chi vuole capire come si imposta lo stack completo dal modello al deployment, ho scritto una guida hardware completa e una guida economica al TCO recente. Per chi sta facendo la decisione operativa su quale modello partire, c’è la pagina Advisory con i formati di lavoro che propongo.

La domanda da farsi oggi non è “qual è il modello migliore”. È: con quale modello vogliamo iniziare adesso, sapendo che fra sei mesi forse cambieremo? E quanto è facile per noi cambiarlo quando arriverà il momento?

AI & GENAI

Mistral in azienda: API, self-hosting, Forge. Cosa scegliere e quanto costa davvero

Diciamo che hai deciso. Mistral è la direzione, per i motivi che ho elencato nella guida sulla scelta enterprise, e i modelli giusti li hai identificati con la mappa operativa. Resta la domanda che sposta davvero il progetto dal documento di intenti al go-live: come lo compri, dove lo metti, quanto costa nei prossimi tre anni. Le quattro opzioni sul tavolo sono Le Chat per i team interni, API La Plateforme per i developer, self-hosting on-premise per chi vuole sovranità totale, Forge per chi vuole un modello proprietario addestrato sui propri dati. Non vanno lette come alternative tra cui scegliere una, sono livelli architetturali che convivono nelle implementazioni enterprise reali.

Provo a metterle in ordine di complessità crescente, con costi realistici per un’azienda italiana media e i criteri per capire dove fermarsi.

Le quattro modalità di consumo, in un colpo d’occhio

Le Chat è il prodotto consumer e team. Interfaccia chat web, mobile app, integrazioni con Drive e altri storage. La versione Pro a 14,99 dollari al mese per utente è equivalente a ChatGPT Plus. La versione Team a 24,99 dollari per utente al mese aggiunge funzioni di collaborazione. La versione Enterprise è negoziata con il vendor e include SLA, supporto dedicato, SSO, audit log avanzati. Caso d’uso: dare ai dipendenti un assistente AI senza far passare dati per cloud americano.

La Plateforme è il prodotto API. Modello pay-per-token, accesso a tutti i modelli (Large, Medium, Small, Magistral, Devstral, Codestral, Ministral, Voxtral). Free tier con quote giornaliere per prototipazione, fatturazione mensile pay-per-use senza minimi contrattuali. I dati transitano dai data center europei di Mistral, l’azienda dichiara residency UE. Caso d’uso: developer che integrano AI nei prodotti, applicazioni esistenti che aggiungono funzionalità AI.

Self-hosting on-premise è il deployment dei modelli open-weight sull’infrastruttura aziendale. Scarichi i pesi, li metti su server GPU che possiedi o noleggi, esponi un endpoint compatibile OpenAI agli applicativi interni. Caso d’uso: settori regolati o con vincoli di sovranità del dato che escludono qualsiasi cloud, anche europeo.

Forge è la piattaforma di training custom annunciata da Mistral a NVIDIA GTC il 17 marzo 2026. Non è una soluzione di fine-tuning né di RAG: supporta pre-training e post-training completi sui dati aziendali, per costruire un modello proprietario dell’azienda. Caso d’uso: organizzazioni con dataset proprietari significativi e necessità di un modello che incorpori conoscenza interna profonda. Tra i primi clienti dichiarati ci sono ASML, Ericsson, European Space Agency, Reply, le agenzie governative di Singapore DSO e HTX.

In una banca media tipica le quattro modalità coesistono: Le Chat Team per i dipendenti, La Plateforme per i progetti di sviluppo interni, self-hosting per i carichi sensibili, e Forge entra in considerazione solo se c’è un dataset proprietario abbastanza grande da giustificarlo (di solito non è il caso, su cui torno sotto).

La Plateforme: prezzi reali e cosa costa davvero

I prezzi La Plateforme cambiano spesso, ma a maggio 2026 gli ordini di grandezza sono questi, in dollari per milione di token, secondo i dati ufficiali Mistral e tracker indipendenti come Artificial Analysis e Pricepertoken.

Per Mistral Large 3 si paga circa 2 dollari per milione di token in input e 6 dollari in output. Il dato che conta per il confronto con i concorrenti è che l’output a 6 dollari è circa il 60% sotto Claude Sonnet (15) e il 50% sotto Gemini Pro (12), e nei task aziendali tipici l’output pesa di più dell’input perché i modelli generano spesso testi più lunghi dei prompt.

Per Mistral Medium 3 il pricing è intorno a 0,40 dollari in input e 2 dollari in output, posizione di mezzo tra Small e Large che per la maggior parte dei carichi aziendali è il miglior rapporto qualità/prezzo.

Per Mistral Small 4 si scende a 0,15 dollari in input e 0,60 in output, prezzi paragonabili a DeepSeek e tra i più bassi del mercato per modelli multimodali di qualità accettabile.

Per Ministral 3B si sta intorno a 0,04-0,10 dollari per milione di token, e per Codestral 0,30 in input e 0,90 in output. Magistral Medium è circa 2 in input e 5 in output, Magistral Small intorno a 0,50 e 1,50.

Un esempio numerico per fissare l’ordine di grandezza. Un’azienda con duecento dipendenti che usa Mistral Medium come assistente interno via API, con un volume medio di trenta prompt al giorno per dipendente, prompt da 500 token e risposta da 1500 token, su 220 giorni lavorativi l’anno, fa circa 2,2 milioni di prompt/anno per circa 4,4 miliardi di token in totale. Costo annuale stimato intorno ai 5.000-7.000 dollari di API, più costi di rete e logging. Per la stessa azienda su Large 3 sarebbe nell’ordine dei 25.000-35.000 dollari. Su Small 4 scenderebbe sotto i 2.000.

C’è da aggiungere l’IVA italiana (Mistral fattura escludendo le imposte) e i costi di gestione (FinOps, monitoring, allocazione per centro di costo). Sono ordini di grandezza, non preventivi, ma servono a rompere l’illusione del “tanto l’AI costa poco”: per progetti significativi i numeri annui salgono velocemente, e proprio qui inizia ad avere senso ragionare di self-hosting.

Self-hosting on-premise: i veri costi totali a tre anni

Questo è il pezzo che mi viene chiesto più spesso, e dove vedo più stime a spanne. Provo a essere preciso, perché la differenza tra un calcolo serio e uno approssimativo è quello che fa fallire o riuscire il business case.

Per servire Mistral Medium 3.5 in self-hosting con throughput sufficiente a 500-1000 utenti aziendali concorrenti, servono mediamente due o tre GPU NVIDIA H200 con 141GB di memoria HBM3e ciascuna. Costo di acquisto a giugno 2026, listino e canale italiano, intorno ai 35-45 mila euro per GPU, quindi 80-120 mila euro di sole GPU. Aggiungi il server che le ospita (chassis Supermicro o Dell con due CPU EPYC, RAM, storage NVMe veloce per il caching), altri 25-35 mila euro. Tot hardware iniziale: 110-160 mila euro.

A questo si aggiunge il software stack: motore di inferenza (vLLM o TensorRT-LLM, gratuiti ma con configurazione che richiede competenze), vector database (Qdrant, Weaviate o Pinecone se non self-hosted), orchestratore di richieste (LangChain, LlamaIndex, o custom), monitoring (Prometheus, Grafana). Tutti open-source o a basso costo, ma servono 30-50 giornate-uomo di setup iniziale di un MLOps engineer, che ai prezzi italiani sono altri 18-30 mila euro tra interno e consulenza.

Operations a regime: il consumo elettrico di due H200 in carico medio è intorno ai 1500W per coppia, su 24/7 fanno circa 13 MWh/anno, intorno ai 3-4 mila euro/anno di sola elettricità in Italia (con prezzi industriali 2026). Manutenzione hardware con contratto vendor, 5-8% del valore l’anno, quindi 6-10 mila euro. Persona dedicata: di solito non serve un FTE intero ma 30-40% del tempo di un MLOps engineer, che diviso significa 25-35 mila euro/anno di costo allocato. Tot ops/anno: 35-50 mila euro.

Sommando: anno 1 = 130-210 mila euro (hardware + setup + ops), anni 2-3 = 35-50 mila euro/anno. Totale a tre anni: circa 200-310 mila euro, con il modello Mistral Medium 3.5 in self-hosting capace di servire un’azienda da 500-1000 dipendenti senza limiti di volume.

Confronto API: la stessa azienda su Mistral Medium via La Plateforme, con i numeri della sezione precedente moltiplicati per scala maggiore, spenderebbe nell’ordine dei 30-60 mila dollari/anno, quindi 90-180 mila dollari su tre anni. Il break-even economico tra le due opzioni si raggiunge tra i 18 e i 30 mesi per volumi di richiesta tipici enterprise. Per volumi più alti il break-even scende; per volumi più bassi sale.

Ma il punto centrale, per cui le aziende scelgono self-hosting anche oltre il break-even economico stretto, va al di là dei costi e tocca la sovranità del dato. Per un’organizzazione che ha vincoli regolatori sul “dove” del dato, il TCO va calcolato includendo il valore del rischio compliance evitato, che spesso è ordini di grandezza superiore al costo infrastrutturale puro.

Sull’analisi di TCO completa cloud vs on-premise ho scritto in dettaglio nella guida dedicata al TCO LLM, che entra anche sui costi nascosti che molti business case dimenticano.

L’aggancio con LocalAI: come si fa nella pratica

Mistral è il modello che vedo più frequentemente girare sotto stack open-source di self-hosting nelle implementazioni italiane, e nello specifico sotto LocalAI. Il motivo è banale: LocalAI espone un endpoint OpenAI-compatible che permette di sostituire le chiamate openai.chat.completions.create() con chiamate al server locale senza riscrivere applicazioni esistenti, e supporta nativamente il caricamento dei modelli Mistral via Hugging Face.

La configurazione tipica di un’implementazione enterprise italiana è questa. Server bare metal in un data center proprietario o presso un provider cloud sovrano (es. ACI, Aruba, WIIT). LocalAI come orchestratore di inferenza, configurato per caricare Mistral Medium 3.5 quantizzato (di solito FP8 o INT8 per ottimizzare memoria GPU senza degrado qualitativo significativo). Vector database Qdrant per il RAG sui documenti aziendali. Endpoint esposto al solo perimetro interno via VPN o rete privata.

I tempi sono concreti. Setup iniziale di un’implementazione standard: 4-6 settimane di sviluppo per portarla in produzione, dato che parta da zero, con un team di un MLOps engineer più un developer più un security engineer part-time. Stabilizzazione: altre 4-8 settimane per tarare ottimamente il modello sui carichi reali e il prompt engineering interno. Da quel momento, gestione a regime con 30-40% di un MLOps engineer.

Forge: il livello più alto della scala, e quando ha davvero senso

Forge è la promessa più ambiziosa di Mistral: non più adattare un modello generico al tuo contesto via fine-tuning o RAG, ma costruire un modello proprietario completo addestrato esclusivamente sui dati aziendali. Pre-training, post-training, reinforcement learning, tutto sull’infrastruttura del cliente. Il modello finale è dell’azienda, non di Mistral, e gira dove vuole il cliente.

Il modello commerciale è particolare. Forge è venduto come piattaforma software con license fee, mentre il compute lo paga l’azienda direttamente (di solito sul proprio cluster GPU o su NVIDIA DGX Cloud). C’è l’opzione di “forward-deployed scientist” Mistral che si installano fisicamente in azienda per gestire il progetto, costo extra. È un modello da consulenza enterprise più che da SaaS.

Quando ha davvero senso. ASML ha aderito perché ha decenni di dati proprietari sulla produzione di macchine litografiche per semiconduttori, dataset altamente specialistici che nessun modello generico cattura correttamente. Ericsson per le specifiche di rete 5G e 5G Advanced, knowledge base che vale anni di R&D interna. ESA per dati di missione e analisi spaziale. Questi sono i profili di cliente Forge: organizzazioni con dataset proprietari di grandezza terabyte o petabyte e necessità di un modello che incorpori conoscenza specialistica profonda.

Quando non ha senso. Per la quasi totalità delle aziende italiane medie (banche regionali, manifatturiere da qualche centinaio di milioni di fatturato, sanità privata), Forge è eccessivo. Il loro problema non è “il modello generico non capisce abbastanza il mio dominio”, è “ho bisogno di un modello con sovranità del dato che lavori sulla mia knowledge base”. Quel problema lo risolve self-hosting più RAG, non Forge. Forge ha senso solo quando il dataset proprietario è la fonte primaria di valore competitivo dell’azienda, ed è abbastanza grande da giustificare un investimento da diversi milioni di euro nel training.

Un’analisi onesta del mercato, fatta da Nick Patience del Futurum Group a marzo 2026, evidenzia che secondo la Data Intelligence Decision Maker Survey 1H 2026, “il 42% degli intervistati spende più della metà del proprio tempo a mantenere e organizzare i dati esistenti invece di usarli produttivamente”. Il messaggio è che Forge presuppone un livello di maturità del dato che la maggior parte delle aziende non ha ancora raggiunto. Per la maggior parte dei progetti italiani, Forge è da considerare in fase due, non al primo go-live.

Vibe CLI: l’agente di coding nel terminale

Una nota breve su Mistral Vibe, perché è la componente che chiude il quadro per i team di sviluppo. Vibe è la CLI agentica di Mistral, lanciata insieme a Devstral 2 a dicembre 2025 e portata a Vibe 2.0 a gennaio 2026 con custom subagents e workflow controls. È paragonabile a Claude Code di Anthropic: un agente di coding che gira nel terminale dello sviluppatore, accede al filesystem del progetto, modifica file multipli mantenendo coerenza architetturale, esegue comandi, fa debugging iterativo.

Per un team di sviluppo italiano che già usa Mistral come provider primario, Vibe è il complemento naturale al modello via API. Per un team che invece sta valutando se Mistral è la scelta giusta anche per il coding agentico, Vibe più Devstral 2 sono concorrenti diretti di Claude Code più Claude Opus, e i confronti sui benchmark mettono Devstral 2 al 72,2% su SWE-bench Verified, in linea con i top di gamma proprietari ma a costi significativamente inferiori secondo i dati Mistral.

Compliance e governance: cosa chiedere al vendor

Chiudo con la parte che salva i progetti dai problemi a regime, e che spesso non viene trattata nelle slide commerciali del vendor.

AI Act: per i sistemi classificati ad alto rischio dal Capo II del regolamento, Mistral fornisce la documentazione tecnica del modello che alimenta gli adempimenti dell’articolo 11. Per il self-hosting questo è particolarmente importante perché la documentazione include training data approfondito, processi di mitigazione bias, valutazioni di robustezza. Chiedi al vendor il Model Card completo e il documento di valutazione del rischio per ciascun modello che usi.

GDPR: La Plateforme dichiara residency UE. Verifica nel DPA Mistral le clausole su sub-processor, trasferimenti, conservazione dei log. Per self-hosting il tema GDPR si sposta sulla tua infrastruttura, semplificando il quadro legale ma spostando l’onere tecnico sull’azienda.

NIS2: per le aziende soggette a NIS2 dall’ottobre 2024, le clausole di security incident notification con Mistral devono essere allineate. Il self-hosting riduce la superficie di rischio terza ma aumenta la responsabilità interna; entrambi gli scenari richiedono presidi di sicurezza adeguati.

Audit log: per qualsiasi implementazione enterprise, esigi log completi delle richieste con retention di almeno 12 mesi. Per self-hosting questo lo configuri tu (ed è un vantaggio: controllo totale). Per La Plateforme verifica nel contratto le condizioni di accesso ai log e il loro export.

Su queste decisioni mi è capitato di affiancare aziende italiane in tutte e quattro le configurazioni, da Le Chat Team in un’azienda di servizi professionali da centocinquanta persone fino a self-hosting completo con LocalAI in un istituto bancario. Quello che cambia il successo del progetto non è mai la tecnologia in sé, è la calibratura tra il caso d’uso reale, i vincoli regolatori specifici e la capacità organizzativa di sostenere l’architettura scelta nel tempo.

Se stai facendo questa valutazione per la tua organizzazione e ti serve un punto di vista esterno, contattami per una prima conversazione. Il primo passo è sempre capire quale combinazione regge il tuo caso reale, non quale è “la migliore” in astratto.

Leggi anche: costruire un'infrastruttura AI privata

AI & GENAI, TECH & BUSINESS

Hardware per LLM locale 2026: Mac, NVIDIA, costi reali

Tre anni fa, “far girare un LLM in locale” significava possedere una workstation con due NVIDIA H100, sapere cosa fosse vLLM, e accettare che il tutto sarebbe stato comunque più lento e meno preciso di una qualsiasi chiamata API a GPT-4. Era un esercizio da ricercatori, da appassionati, da aziende con budget infrastrutturali serissimi.

Nel 2026 il quadro è cambiato. Un Mac Mini M4 Pro da 1.799 euro fa girare Llama 3.3 70B a quantizzazione aggressiva, a 5-10 tokens al secondo, sufficiente per la quasi totalità dei task aziendali batch. Un Mac Studio M4 Max a 4.000 euro arriva a 30-45 tok/s sui modelli da 70B. Una workstation NVIDIA con RTX 5090 supera i 100 tok/s. E sotto, una nuova categoria di mini PC ottimizzati per AI sta emergendo come alternativa serissima, con NVIDIA DGX Spark, AMD Strix Halo, Framework Desktop.

Da quando ho cofondato LocalAI.io mi capita ogni settimana di rispondere alla stessa domanda da CTO italiani: “Quale hardware per LLM locale mi serve per cominciare?”. La risposta dipende da tre variabili che vanno tenute insieme, e che voglio provare a smontare in questo articolo: che modelli volete far girare, quanti utenti simultanei dovete servire, quanto budget e quanto tempo siete disposti a investire nell’ops.

Cosa determina davvero la velocità di un LLM in locale

C’è una metrica che vale più di tutte le altre quando si parla di inferenza LLM: la banda di memoria. Non la potenza di calcolo, non i TFLOPS, non i CUDA cores. È la banda con cui il chip riesce a leggere i pesi del modello dalla memoria, perché generare un token nuovo richiede di leggere TUTTI i pesi del modello, ogni volta. Un modello da 70 miliardi di parametri quantizzato a 4 bit pesa 35-40 GB, e ogni token generato è una passata completa di quei 40 GB.

Su questo dato si gioca la partita fra Apple Silicon e NVIDIA. Una RTX 4090 ha 1.008 GB/s di banda di memoria. Un M4 Max arriva a 546 GB/s, un M4 Pro a 273 GB/s, un M4 base a 120 GB/s. Significa che, modello per modello, NVIDIA è 2-3 volte più veloce di Apple Silicon top di gamma sui token al secondo. Però Apple Silicon ha un asso che NVIDIA non ha: la memoria unificata. Un Mac Studio M4 Max con 128 GB di RAM unificata fa girare modelli che non entrano in nessuna GPU consumer NVIDIA, neanche la 5090 da 32 GB. Per le aziende che vogliono lavorare con modelli da 70B in alto, Apple resta spesso l’unica opzione consumer.

Una nota di realismo importante. Apple sta arrivando con M5 Max e M5 Ultra previsti per fine 2026 con banda di memoria che dovrebbe superare 1 TB/s e tensor core FP8 nativi nel Neural Engine. Se le anticipazioni reggono, il gap di throughput per token con NVIDIA H100 si chiuderà quasi del tutto sull’inferenza, e l’asso della memoria unificata resterà comunque sul tavolo.

Quattro fasce hardware e cosa ci fate dentro

Provo a mappare quattro fasce di setup, dalla più accessibile alla più seria, con i numeri reali di throughput misurati con LLMCheck e altre fonti pubbliche aggiornate a maggio 2026.

Fascia 1: laptop e Mac Mini base, sotto i 1.000 euro. Un MacBook Air M2/M3 con 16 GB, un Mac Mini M4 base 16 GB, un mini PC NUC con CPU recente e 32 GB RAM. Modelli che ci girano bene: Phi-5 Mini, Llama 3.2 3B, Qwen 2.5 7B in quantizzazione Q4. Velocità tipica 40-80 tok/s sui modelli piccoli. Adatto a sperimentare, fare RAG su piccoli corpus documentali, sviluppare prototipi. Non adatto a produzione aziendale seria, non adatto a servire più utenti simultanei.

Fascia 2: workstation singolo utente, 1.500-3.000 euro. Mac Mini M4 Pro 24 GB o 48 GB. PC desktop con RTX 4070/4080. Modelli che girano: Llama 3.3 14B, Mistral Small, Qwen 4 32B-A3B (modello MoE con 3B parametri attivi, eccellente rapporto qualità/velocità sul Mac), Gemma 4 26B. Velocità tipica 25-55 tok/s sui modelli 14-32B. Adatto a uno sviluppatore singolo, a piccolo team che condivide, a applicazioni interne con pochi utenti. Il Mac Mini M4 Pro 48 GB a 1.799 euro è il punto di equilibrio prezzo-prestazioni che consiglio più spesso oggi a chi inizia.

Fascia 3: workstation potente, 4.000-7.000 euro. Mac Studio M4 Max con 64 GB o 128 GB. PC desktop con RTX 4090 o 5090 (32 GB VRAM). Modelli che girano: Llama 3.3 70B Q4 a 30-45 tok/s sul Mac Studio, Qwen 4 70B, DeepSeek R2 in versione compressa. Adatto a produzione interna seria su 10-50 utenti, a serving di applicazioni RAG complesse, a fine-tuning leggero. È la fascia dove Apple Silicon vince per memoria, NVIDIA vince per pura velocità, e la scelta dipende molto dal vostro mix specifico di modelli e workload.

Fascia 4: server-class, 15.000 euro in su. Mac Studio M3 Ultra con 256 GB (per workload memoria-bound). Server NVIDIA con due o quattro RTX 5090 in parallelo, oppure singola H100 da 80 GB. Apple offre DGX Spark, NVIDIA i sistemi DGX. Adatto a piccole-medie aziende che vogliono servire il proprio strato AI internamente a centinaia di utenti, a fine-tuning serio, a training di modelli specializzati piccoli. È la zona dove il ragionamento smette di essere consumer-DIY e diventa decisione infrastrutturale aziendale, con tutto quello che comporta in termini di networking, raffreddamento, alimentazione, backup.

Una scelta concreta per ogni profilo aziendale

Vorrei provare a passare dalle tabelle astratte a tre scenari aziendali che ho visto in concreto negli ultimi mesi, e dire cosa consiglierei in ciascuno.

Studio professionale, 10-30 dipendenti, vuole fare AI privata per RAG su documenti interni. Mac Mini M4 Pro 48 GB, modello Llama 3.3 14B o Qwen 4 32B-A3B. Costo totale 1.800 euro una tantum più il tempo di setup. Stack: Ollama come motore di inferenza, LocalAI come gateway compatibile OpenAI, un vector database come Qdrant in Docker per il RAG. Tempo medio di setup completo: una giornata di lavoro per uno sviluppatore che sa cosa fa. Sufficiente per 5-15 utenti simultanei con interazioni occasionali, non per una chat sempre attiva di 30 persone.

Azienda manifatturiera, 100-300 dipendenti, vuole un agente AI interno con accesso a documenti tecnici e gestionale. Mac Studio M4 Max 128 GB, modello Llama 3.3 70B Q4. Costo totale 4.000-5.000 euro hardware. Setup più articolato: LocalAI per orchestrare modelli multipli (uno per chat conversazionale, uno specializzato sui documenti tecnici), Qdrant o Weaviate per la memoria vettoriale, n8n o Make per le integrazioni con i sistemi aziendali. Tempo di setup completo realistico: una settimana di lavoro di un team da 2 persone. Capacità: 30-50 utenti simultanei.

Azienda servizi finanziari medio-piccola, 50-150 dipendenti, vuole un sistema AI con vincoli GDPR strettissimi. Qui non è solo hardware, è architettura completa. Server con 2x RTX 5090 o singola H100 in colocation italiana, modello Qwen 4 70B o Mistral Large, stack di sicurezza completo con SSO, audit log, segmentazione di rete. Costo hardware 20-30k euro, costo annuale di hosting e operations 30-50k. Setup: 4-6 settimane di lavoro di un team specializzato, magari con il supporto di chi conosce il dominio (qui entra il valore dell’advisory). Capacità: 100-300 utenti simultanei con alto livello di compliance.

Il problema dei costi nascosti

Le aziende che valutano l’AI privata guardando solo al costo dell’hardware sbagliano la metà del calcolo. L’altra metà sono tre voci che spesso non finiscono nei business case ma esistono comunque.

La prima è l’elettricità. Una RTX 5090 sotto carico consuma 575 watt. Un Mac Studio M4 Max si ferma a 130 watt. Su un anno di utilizzo continuativo, parliamo di una differenza di 1.500-2.000 euro l’anno solo di bolletta italiana. Il Mac è in questo molto più efficiente, ed è uno dei motivi per cui molte PMI italiane ci stanno arrivando.

La seconda è il tempo di setup e di manutenzione. Una RTX 5090 richiede driver CUDA, configurazione di vLLM o llama.cpp, tuning della quantizzazione, debugging di edge case su modelli specifici. Un Mac Mini con Ollama va da zero al primo prompt in dieci minuti. Per un’azienda piccola, il tempo del proprio sviluppatore è la voce più costosa di tutte: vale la pena pagarla anche 500 euro in più all’hardware se questo significa risparmiare due giorni di setup.

La terza è il rinnovo. L’hardware AI sta evolvendo velocemente. Un acquisto di oggi è probabilmente sostituibile entro 3 anni con qualcosa di significativamente meglio. Vale la pena pensare il setup in modo modulare, dove l’orchestrator (LocalAI), il vector DB, gli agenti, sono indipendenti dal motore di inferenza sottostante, così quando arriva la prossima generazione di chip si cambia solo quello.

Il software che fa la differenza

L’hardware è metà del lavoro. L’altra metà è lo stack software che ci gira sopra, ed è dove negli ultimi 12 mesi è cambiato tutto. Tre componenti vanno scelti bene fin dall’inizio.

Il motore di inferenza. Ollama è la scelta più semplice per cominciare, perfetto per Mac e PC, ha l’API compatibile OpenAI, supporta MLX su Apple Silicon dalla versione 0.5. Llama.cpp è la base sotto Ollama, più tecnico, dà più controllo. vLLM è per setup server seri con GPU NVIDIA, supporta batching e ha throughput superiore per più utenti. MLX è il framework Apple ottimizzato per Metal, può essere 30-50% più veloce di Ollama su Mac per alcuni modelli. La scelta dipende dal vostro hardware e dal team che dovrà manutenerlo.

L’orchestratore. Qui è dove entra LocalAI. Senza un orchestratore, ogni applicazione del vostro stack chiama direttamente Ollama o vLLM, e quando volete cambiare modello dovete ritoccare ogni client. Con un orchestratore, esponete un unico endpoint compatibile OpenAI, ci puntate tutte le applicazioni, e potete scambiare il motore sotto, gestire più modelli in parallelo, fare A/B testing, aggiungere autenticazione e logging. È il single point of integration che vi salva mesi di refactor quando l’hardware sotto cambia.

Il vector database per il RAG. Qdrant è la scelta più equilibrata oggi, gira bene su hardware modesto, ha buona documentazione, supporta filtri complessi. Weaviate è più potente ma più pesante. Chroma è il più leggero per iniziare ma scala meno. La scelta qui dipende dalla dimensione del corpus documentale che pensate di gestire.

Da dove cominciare se siete una PMI italiana

Se siete il CTO di una PMI italiana e state pensando di portare l’AI in casa, il mio consiglio è ridurre il primo step alla minima espressione possibile. Comprate un Mac Mini M4 Pro 48 GB. Installateci Ollama in dieci minuti. Scaricateci sopra Llama 3.3 14B o Qwen 4 32B. Apriteci sopra LocalAI come gateway. Provate una settimana con un caso d’uso piccolo, magari un agente che risponde a domande sul vostro manuale aziendale via RAG. Misurate latenza, qualità delle risposte, soddisfazione degli utenti.

Se la prova regge, scalate. Se non regge, avete speso 1.800 euro e una settimana di tempo per imparare cosa serve davvero. Confronto con un POC su OpenAI o Anthropic che, fra licenze enterprise e committment iniziale, sarebbe costato spesso di più senza darvi controllo dell’infrastruttura.

L’AI privata oggi non è più un esperimento da ricercatori. È una scelta di architettura accessibile, con costi noti e curva di apprendimento ragionevole, soprattutto per chi parte dai modelli open-weight più solidi (Llama, Mistral, Qwen) e da uno stack software maturo (Ollama, LocalAI, Qdrant).

Per chi vuole capire come si costruisce concretamente l’ecosistema sopra l’hardware, ho scritto una guida completa a LocalAI qualche mese fa, e nelle prossime settimane pubblicherò una guida operativa step-by-step all’installazione completa in azienda. Per chi sta valutando il setup giusto rispetto alle proprie necessità specifiche, c’è la pagina Advisory con i formati di lavoro che propongo.

La domanda da farsi oggi non è più “siamo pronti per l’AI privata”. È: che modello vogliamo far girare per primo nei nostri processi, e su che hardware lo facciamo girare nei prossimi sei mesi?

AI & GENAI

I modelli Mistral nel 2026: come scegliere tra Large 3, Medium 3.5, Small 4, Magistral, Devstral

Tra dicembre 2025 e aprile 2026, Mistral ha rilasciato Large 3, Magistral 1.2 in due taglie, Devstral 2 più la versione Small, Mistral Small 4, la nuova famiglia Ministral 3 in tre dimensioni, Codestral 25.08, Codestral Embed, Voxtral per l’audio, Mistral Medium 3.5. A spanne, undici modelli in cinque mesi, con nomi che a chi non segue il settore quotidianamente sembrano scelti per confondere. Quale ti serve davvero dipende dal carico che vuoi spostare, e la risposta cambia molto tra “assistente interno per duecento dipendenti” e “agente di coding autonomo nel terminale”.

Questa è la mappa che uso quando un’azienda mi chiede di capire l’ecosistema Mistral prima di una decisione di acquisto. Niente classifiche universali, niente “il migliore di tutti”: ogni modello vince in uno scenario specifico, e la scelta diventa banale una volta che hai chiaro il caso d’uso. Per il contesto strategico su perché un’azienda italiana dovrebbe guardare Mistral prima degli altri, c’è la guida pillar sulla scelta enterprise. Qui scendiamo nei singoli modelli.

La mappa dei modelli del 2026

Tre famiglie principali, ognuna con una funzione precisa, più due linee verticali specializzate.

Le famiglie generaliste sono tre: Mistral Large 3 (flagship MoE, ammiraglia di gamma), Mistral Medium 3.5 (dense, ottimizzato per self-hosting e workload agentici), Mistral Small 4 (modello unificato reasoning più visione più coding). Tre opzioni che coprono i casi d’uso generici dal più pesante al più leggero.

La linea reasoning è Magistral 1.2, in due taglie: Magistral Medium per l’enterprise, Magistral Small per il self-hosting permissivo. Si chiama in causa quando il task richiede chain-of-thought esplicito: dimostrazioni matematiche, analisi logiche multi-passo, problemi di programmazione algoritmica.

La linea coding è doppia. Devstral 2 (123B parametri) e Devstral Small 2 (24B) per il coding agentico autonomo, Codestral 25.08 e Codestral Embed per l’autocompletamento in IDE e l’embedding di repository.

La linea edge è Ministral 3 in tre tagli (3B, 8B, 14B parametri), pensata per girare su dispositivi: telefoni, edge gateway, sistemi embedded.

La linea multimodale è Voxtral per audio, text-to-speech e trascrizione, recentemente uscita open-weight con dimensioni che permettono il deploy su smartphone.

Tutti i modelli flagship sono rilasciati sotto Apache 2.0 o licenze permissive equivalenti, con l’unica eccezione di Devstral 2 (Modified MIT, che resta open-source ma con qualche clausola in più). I pesi sono pubblicamente scaricabili, il self-hosting funziona davvero, le API La Plateforme sono un’opzione aggiuntiva ma non l’unica.

Mistral Large 3: l’ammiraglia per i carichi generalisti più pesanti

Large 3 è il modello flagship rilasciato a dicembre 2025 con il codename mistral-large-2512. Architettura Mixture of Experts da 675 miliardi di parametri totali, di cui 41 miliardi attivi a ogni inferenza. Tradotto in operativo: la qualità di output di un modello da 675B con il costo computazionale di un modello da 41B, perché il MoE attiva solo gli esperti rilevanti per ogni token.

Sui benchmark indipendenti, secondo le valutazioni LayerLens/Atlas, Large 3 raggiunge il 73,11% su MMLU-Pro e il 93,60% su MATH-500. È debuttato al secondo posto nella categoria open-source non-reasoning di LMArena. Numeri che lo mettono nella stessa fascia di qualità di GPT-4.1 e Claude Sonnet 4.6 per i task generalisti, con un costo per token sull’output che è circa 60% sotto Claude e 40% sotto GPT-4.1 a parità di volume.

Quando ha senso. Carichi di analisi documentale lunga, ragionamenti complessi su contesti misti, generazione di contenuti tecnici lunghi, supporto a decision-making aziendale che richiede capacità di sintesi su corpus eterogenei. È il modello che metti via API La Plateforme quando il task è abbastanza complesso da non poter essere delegato a Medium o Small, ma non così specialistico da richiedere Magistral.

Quando non ha senso. Self-hosting on-premise, perché l’infrastruttura per servire un MoE da 675B richiede otto GPU H200 in cluster, configurazione che fa salire l’investimento iniziale oltre il milione di euro e che ha senso solo per organizzazioni che processano milioni di richieste al giorno. Per chi vuole self-hosting il modello giusto è Medium 3.5, vedi sotto.

Il contesto è 128K token, in linea con GPT-5 e Claude per la versione standard. Non è il modello con la finestra più ampia (DeepSeek V4 e GPT-5.4 offrono 1M), ma per la quasi totalità dei casi enterprise 128K bastano. Quando non bastano, di solito il problema è di architettura del prompt, non di limite del modello.

Mistral Medium 3.5: il modello pensato apposta per il self-hosting enterprise

Medium 3.5 è uscito il 29 aprile 2026, ed è probabilmente il modello più importante della famiglia per il contesto italiano. Architettura dense (non MoE), dimensione tale da girare su due o tre GPU NVIDIA H200, ottimizzato esplicitamente per workload agentici e coding, comportamento più prevedibile dei MoE.

La parola chiave è “prevedibile”. Quando un MoE come Large 3 viene messo in self-hosting, il routing degli esperti introduce una varianza che complica il dimensionamento dell’infrastruttura, la calibrazione del rate limiting, la gestione della latenza percepita. Su un modello dense come Medium 3.5 questi problemi spariscono: ogni richiesta usa tutti i parametri del modello, la latenza è costante, l’infrastruttura è più semplice da governare.

Per un CIO che sta dimensionando un self-hosting on-premise in una banca o in un gruppo manifatturiero, questa prevedibilità vale più di qualche punto percentuale in più sui benchmark. Significa contratti di SLA che si possono firmare, capacity planning che funziona, ops engineering che non passa metà del tempo a debuggare comportamenti inattesi.

Quando ha senso. Self-hosting on-premise come modello principale aziendale, workload agentici con tool use intensivo, integrazione con LocalAI o stack on-premise simili. È il modello che vedo più spesso scelto come default nei progetti enterprise italiani.

Quando non ha senso. Carichi consumer ad altissimo volume dove conta il prezzo al token assoluto: in quel caso Small 4 o Ministral sono più economici. Task di reasoning estremo: meglio Magistral 1.2.

Mistral Small 4: l’unificazione del marzo 2026

Small 4 è uscito il 16 marzo 2026 con un’idea precisa: prendere tre modelli precedenti (Magistral per il reasoning, Pixtral per il multimodale, Devstral per il coding agentico) e fonderli in un unico sistema che faccia tutte e tre le cose decentemente, invece di richiedere tre modelli separati con tre integrazioni diverse.

Contesto 262K token, prezzo La Plateforme a 0,15 dollari per milione di token in input e 0,60 in output. È il modello più economico della fascia “qualità decente” di Mistral, e l’unificazione delle capability significa che si può usare come workhorse per la maggior parte dei task aziendali medi.

Quando ha senso. Il caso d’uso più ricorrente è l’assistente aziendale interno per medie aziende, dove serve un modello che capisca testo, immagini, codice senza dover orchestrare modelli diversi a seconda del task. Anche carichi di chatbot, customer support assistito, analisi documentale di medio livello.

Quando non ha senso. Carichi che richiedono il massimo della qualità su una singola dimensione: Large 3 batte Small 4 sul reasoning generico, Magistral 1.2 lo batte sul reasoning specialistico, Devstral 2 lo batte sul coding agentico autonomo. Small 4 è la scelta giusta quando il valore è nella semplicità architetturale, non nella performance di picco.

Magistral 1.2: la linea reasoning, Medium e Small

Magistral è la famiglia di reasoning models di Mistral, equivalente concettuale di OpenAI o3 e o4. Versione 1.2 rilasciata a settembre 2025 con i codename magistral-medium-2509 e magistral-small-2509. Due varianti: Medium per l’enterprise via API, Small (24B parametri) sotto Apache 2.0 per il self-hosting.

La caratteristica distintiva è la modalità “Flash Answers”, che permette di alternare tra inferenza standard (veloce) e chain-of-thought esplicito (più lento ma con tracciamento del ragionamento). Per task come dimostrazioni matematiche, problem-solving algoritmico, analisi giuridica multi-passo, l’output diventa interpretabile, e questo è un vantaggio enorme quando devi giustificare una decisione assistita da AI in un contesto regolato.

Sui benchmark di pura matematica OpenAI o3 mantiene un margine, ma il prezzo per token su Magistral è significativamente più basso e la latenza in Flash mode è competitiva. Magistral Small è particolarmente interessante: 24 miliardi di parametri, Apache 2.0, gira su una singola GPU H100, ed è quindi il modello di reasoning self-hostable più capace disponibile a giugno 2026.

Quando ha senso. Compliance finanziaria con tracciamento del ragionamento, supporto a decisioni in settori regolati dove l’audit trail è obbligatorio, problem-solving algoritmico, supporto alla redazione giuridica con catena logica esplicita. In tutti questi casi il chain-of-thought tracciabile vale più della pura performance bruta.

Quando non ha senso. Carichi conversazionali generici dove il reasoning esplicito introduce latenza inutile. Per quello c’è Large 3 o Medium 3.5.

Devstral 2 e Codestral: la linea coding

Devstral 2 è uscito a dicembre 2025 insieme alla CLI Mistral Vibe. È il modello coding agentico flagship: 123 miliardi di parametri dense, contesto 256K, raggiunge il 72,2% su SWE-bench Verified secondo Mistral. Per dare un riferimento, è uno dei migliori modelli open-weight per coding autonomo disponibili oggi, e secondo i dati Mistral è “fino a 7 volte più cost-efficient di Claude Sonnet sui task reali”, secondo l’annuncio ufficiale del rilascio.

C’è anche Devstral Small 2 a 24 miliardi di parametri, sotto licenza Apache 2.0, che gira su una singola GPU di fascia consumer-pro. La combinazione Devstral 2 più Vibe CLI è la risposta Mistral a Claude Code di Anthropic: agente di coding che gira nel terminale dello sviluppatore, capace di esplorare codebase, modificare file multipli mantenendo coerenza architetturale, fare debugging iterativo, gestire dipendenze framework.

Codestral è la linea complementare. Codestral 25.08 (codice codestral-2508) è il modello da 22B parametri specializzato in autocompletamento IDE con supporto nativo Fill-in-the-Middle, contesto 256K, ottimizzato per integrazioni JetBrains, VS Code, LangChain. Codestral Embed è invece il modello specifico per generare embedding di codice, utile per indicizzare repository e costruire knowledge base di codice aziendale.

Quando usare cosa. Devstral 2 con Vibe CLI per il coding agentico autonomo, cioè per l’agente che scrive feature complete partendo da una specifica. Codestral 25.08 per l’autocompletamento intelligente dentro IDE durante lo sviluppo manuale. Codestral Embed per indicizzare codebase aziendali e fare retrieval. Tre strumenti complementari, non alternativi.

Ministral 3: la linea edge per dispositivo

Ministral 3, rilasciato a dicembre 2025 insieme a Large 3, è la famiglia “minuscola” pensata per il deploy su dispositivo. Tre taglie: 3 miliardi di parametri, 8 miliardi, 14 miliardi. La 3B gira su uno smartphone, la 14B su un laptop di fascia alta.

Casi d’uso italiani concreti dove l’ho visto applicato. Industria 4.0 con macchinari offline che devono fare diagnostica locale senza connettività garantita, retail con POS che fanno traduzione real-time in più lingue senza chiamare API esterne, settore field service con tecnici che lavorano in cantieri o impianti remoti. In tutti questi scenari Ministral risolve il problema della “AI senza rete”, che con i modelli cloud non si chiude.

Per dare un’idea dei costi: Ministral 3B via La Plateforme costa circa 0,04-0,10 dollari per milione di token, a seconda della versione, il che lo rende uno dei modelli più economici del mercato. In self-hosting, gira gratis su hardware che già hai.

Voxtral: la linea audio

Voxtral è la famiglia audio uscita open-weight a marzo 2026, dimensioni che vanno dal modello da 24 miliardi per uso server fino a varianti compresse che girano su smartphone. Trascrizione, traduzione audio-to-audio, sintesi vocale, comprensione di audio complesso.

Per il contesto enterprise italiano è ancora una linea di nicchia, ma vale la pena tenerla in radar per casi specifici: contact center con trascrizione automatica delle chiamate, sanità con dettatura medica multilingua, accessibilità per servizi PA.

Italiano e multilingua: il discriminante che non viene dai benchmark

I benchmark MMLU e simili sono quasi tutti in inglese. Un modello che fa 92% su MMLU in inglese può fare 78% sul corrispondente italiano. Per chi costruisce assistenti interni in lingua italiana, questa differenza si sente nella qualità delle risposte, e Mistral parte avvantaggiata.

Il motivo è strutturale. Mistral è francese, addestra su corpus europei multilingua fin dalla prima versione, e l’italiano è una delle lingue di confine principali nei dataset di training continentali. Llama 3.3 ha colmato il gap su italiano generico, ma resta sotto Mistral sulla terminologia legale (clausole contrattuali, riferimenti normativi italiani), su quella finanziaria (regolamentazione Consob, normativa bancaria specifica), su quella tecnico-industriale (manuali di processo italiani, certificazioni di settore). Qwen e DeepSeek sono buoni sull’italiano generico ma introducono calchi grammaticali dal cinese che un madrelingua riconosce nei testi lunghi.

Per un’azienda italiana che costruisce un assistente interno destinato a colleghi italiani, questa è la differenza tra un agente che “sembra italiano” e uno che è italiano. Per il confronto sistematico tra le quattro famiglie open-weight principali, ho già pubblicato un confronto operativo Mistral vs Llama vs Qwen vs DeepSeek che entra nel dettaglio delle valutazioni per il mercato italiano.

La griglia di scelta operativa

Per chiudere, la griglia che uso quando un’azienda mi chiede “quale modello Mistral usiamo”.

Se il caso d’uso è un assistente interno generico per uso quotidiano dei dipendenti, Mistral Medium 3.5 self-hosted è la scelta default. Performance ottime, prevedibilità infrastrutturale, costo controllato a tre anni.

Se sono carichi esplorativi o sperimentali a basso volume in cloud, Mistral Large 3 via API La Plateforme. Massima qualità, paghi solo quello che usi.

Se è un workhorse multimodale a basso costo per volumi alti, Mistral Small 4 via API. È il rapporto qualità/prezzo migliore della famiglia per applicazioni mainstream.

Se serve reasoning tracciabile in settori regolati, Magistral Medium 1.2 via API, oppure Magistral Small in self-hosting se il volume giustifica l’infrastruttura.

Se è un agente di coding per il team dev, Devstral 2 con Vibe CLI. Se è autocompletamento dentro l’IDE, Codestral 25.08.

Se è un’applicazione che deve girare su dispositivo o offline, Ministral 3 nella taglia adatta all’hardware target.

Se è audio, Voxtral, sapendo che la linea è ancora in maturazione.

Questa mappa funziona per la maggior parte dei casi enterprise, ma le scelte vere si fanno sui dettagli: volumi di richiesta giornaliera, latenza accettabile, vincoli infrastrutturali esistenti, competenze MLOps disponibili, profilo di rischio del settore. Quello che funziona per una banca da mille dipendenti non funziona per una manifatturiera da trecento, anche se entrambe partono dal “vogliamo Mistral”.

È il tipo di scelta tecnica che mi capita di affiancare nei progetti di assessment AI aziendale: capire quale combinazione di modelli regge il caso d’uso reale, evitando di pagare la complessità di un Large 3 quando basta Medium 3.5, o di scoprire troppo tardi che il task richiedeva Magistral. Se stai facendo questa valutazione per la tua organizzazione, puoi scrivermi per discuterne.

Per la parte di come acquistare e quanto costa davvero, dall’API a La Plateforme fino al self-hosting on-premise con Forge, c’è la guida dedicata su API, self-hosting, Forge in azienda.

Leggi anche: LocalAI

AI & GENAI

Mistral AI nelle aziende italiane? Perché nel 2026 è diventata la scelta enterprise più seria d’Europa

Tre conversazioni recenti con CIO italiani sullo stesso identico tema. Una banca media del Nord, un gruppo manifatturiero del Veneto, un’azienda sanitaria privata di Roma. Domande diverse, problema sottostante identico: come spostare carichi AI dal cloud americano senza rallentare i progetti e senza far esplodere il budget infrastrutturale.

Ognuno per la sua ragione ovviamente: la banca per la piena applicazione dell’AI Act dal 2 agosto 2026 sui sistemi ad alto rischio, il gruppo manifatturiero perché i dati di produzione non possono finire in dataset di training di nessuno, l’azienda sanitaria perché il GDPR sui dati paziente in cloud extra-UE è diventato un mal di testa che non vale i risparmi.

In tutte e tre le conversazioni Mistral AI è arrivata sul tavolo con sollecitazioni differenti e suggestioni tecniche, e in due casi su tre è già la scelta tecnica in valutazione per il prossimo trimestre.

Mistral nel 2026 non è più interpretabile come “l’alternativa europea sperimentale“. È diventata piuttosto rapidamente la prima risposta seria che si dà a un CIO italiano quando i vincoli sono compliance e sostenibilità dei costi. Provo a spiegare perché, e quando invece non lo è (soprattutto poi sul tema sovranità ci torno in dettaglio).

Chi è Mistral AI

L’azienda è francese, sede a Parigi, fondata nel 2023 da ricercatori usciti da Meta e DeepMind. La distanza tra quel punto di partenza e dove sta oggi vale la pena guardarla con i numeri, perché definisce il tipo di vendor con cui si tratta.

ARR a 400 milioni di dollari a gennaio 2026, salito da circa 20 milioni un anno prima secondo il CEO Arthur Mensch. Valutazione 13,8 miliardi dopo il round chiuso a fine 2025 con Series C guidata da ASML. Quattro sedi globali oltre Parigi: Stati Uniti, Regno Unito, Singapore. E una traiettoria di prodotto che a marzo 2026 ha visto sei rilasci in quindici giorni, dalla famiglia Small 4 che unifica reasoning vision e coding fino a Forge per il training enterprise.

Sul fronte clienti il segnale italiano è arrivato a febbraio e marzo. Il 26 febbraio Accenture ha annunciato una partnership strategica pluriennale per scalare AI enterprise sicure in Europa, con Mauro Macchi, CEO Accenture EMEA, a confermare l’investimento. Il 18 marzo è arrivato l’accordo con Reply, focalizzato proprio su “soluzioni di intelligenza artificiale generativa locali, personalizzabili, sicure e pronte per l’utilizzo in contesti enterprise”, come dichiarato dal CTO Filippo Rizzante. Reply lavora con Mistral nel training e nella valutazione dei modelli per pubblica amministrazione, difesa, financial services e sanità, oltre a telco ed energia. I settori dove la conformità non è un’opzione e la sovranità del dato è un requisito di gara.

Quando un’azienda italiana media decide oggi di mettere Mistral nel proprio stack, non sta scommettendo su una startup. Sta acquistando da un vendor che ASML, Ericsson, ESA, due agenzie governative di Singapore, Accenture e Reply hanno già qualificato in scenari produttivi reali.

Apache 2.0 come scelta strategica non per ideologia

Il vero discriminante di Mistral non è la qualità del modello: su quel terreno la competizione con OpenAI, Anthropic e Google è una corsa serrata che cambia ogni tre mesi o forse meno. Il vero discriminante è la licenza con cui i modelli vengono distribuiti. Apache 2.0, permissiva, commerciale, senza clausole che escludano usi specifici. Mistral Large 3, Magistral Small, Devstral, Ministral: tutti rilasciati con licenza Apache 2.0 o equivalente.

Per un CIO questo significa tre cose pratiche.

La prima è l’assenza di lock-in del vendor. Se domani Mistral aumenta i prezzi API, cambia condizioni contrattuali, viene acquisita da un attore non gradito, viene esclusa da un programma di compliance europea, il modello continua a girare. I pesi del modello sono scaricabili, replicabili, ospitabili dove serve. Non esiste un equivalente in OpenAI, Anthropic o Google: nessuno dei tre rilascia i pesi dei propri modelli flagship. Quando si firma un contratto con loro si firma una dipendenza permanente dall’infrastruttura del fornitore.

La seconda è il self-hosting che funziona davvero. Non quello finto di “Azure OpenAI in region europea”, dove il dato si muove in un perimetro Microsoft ma il modello resta proprietà di OpenAI e la trasparenza sul training data resta zero. Con Mistral si può prendere Mistral Medium 3.5, metterlo su server bare metal in un data center italiano, e avere il controllo completo del flusso: i dati non escono mai dall’infrastruttura, i log restano interni, le richieste non transitano per servizi terzi. Per settori regolati la differenza è strutturale: permette di chiudere il progetto AI in conformità invece di doverlo riprogettare quando arriva l’audit.

La terza è la possibilità di auditare il modello per i requisiti dell’AI Act. Per i sistemi classificati ad alto rischio dall’articolo 6 del regolamento europeo, da agosto 2026 servono evidenze documentali su training data, processo di sviluppo, gestione dei bias, robustezza. Con un modello open-weight si può esaminare quello che effettivamente gira, fare valutazioni indipendenti, produrre la documentazione che chiede AgID. Con un modello chiuso si dipende dalla buona fede e dai certificati del vendor, che vanno bene fino a quando non vanno bene.

Apache 2.0 non è un argomento ideologico. È un’architettura di rischio enterprise.

Mistral contro la concorrenza

I benchmark MMLU-Pro e LMArena occupano metà delle slide nei pitch dei vendor AI, ma non sono il criterio giusto per scegliere quale modello mettere in produzione in un’azienda europea. Lo sono per il singolo task scientifico in laboratorio, non per la decisione di acquisto.

I criteri che muovono davvero la firma di un contratto enterprise in Italia sono cinque, e ho provato a mettere i quattro vendor principali su ognuno.

Sulla residency dei dati nel perimetro UE, Mistral vince netto: La Plateforme gira interamente in data center europei, e il self-hosting permette residency totale. OpenAI offre region europee ma con metadati che possono uscire, Claude di Anthropic non ha ancora residency europea garantita per tutti i tier, Google Gemini ha region UE ma resta soggetto a Cloud Act statunitense.

Sul self-hosting reale, solo Mistral lo offre con i modelli flagship. OpenAI, Anthropic e Google non lo permettono, possono offrirti al massimo deployment in cloud privato gestito da loro.

Sull’italiano nel training data come priorità di prodotto, Mistral parte avvantaggiata perché l’italiano è una lingua di confine della Francia, presente nelle fonti europee usate per il training fin dai primi modelli. OpenAI e Google hanno italiano buono ma derivato, Claude si difende. Il dettaglio si sente quando i casi d’uso sono terminologia legale e finanziaria, o linguaggio medico italiano: Mistral produce testi che un madrelingua riconosce come scritti in italiano, non tradotti.

Sul supporto enterprise europeo, Mistral ha staff in Europa con fusi compatibili, contratti redatti su norma europea, capacità di firmare DPA conformi al GDPR senza emendamenti acrobatici. Gli altri tre vendor possono offrirlo, ma è sempre una negoziazione caso per caso.

Sul presidio fisico in Europa, Mistral ha sede e team principale a Parigi, con presenza commerciale diretta nei principali mercati europei. Per un’azienda italiana questo si traduce in interlocutori reggiungibili, processi di escalation prevedibili, riunioni di servizio fattibili senza notti negli US.

Cinque criteri, Mistral vince su tutti, gli altri tre vendor perdono almeno su due ciascuno. Questo non significa che siano scelte sbagliate in assoluto, significa che se il caso d’uso è italiano e regolato Mistral parte da un vantaggio strutturale che gli altri devono recuperare a forza di concessioni contrattuali.

Quando Mistral non è la scelta giusta

Una guida che racconta solo i vantaggi di un vendor è un brochure di vendita, non un’analisi. Ci sono tre scenari in cui oggi consigliare Mistral è sbagliato, e vale la pena chiamarli con il loro nome.

Il primo è il reasoning scientifico al limite dello stato dell’arte. Se l’applicazione è ricerca farmaceutica avanzata, analisi giuridica multi-giurisdizione su corpus immensi, problemi matematici di livello olimpionico, oggi Claude Opus 4.7 e GPT-5 hanno ancora un margine sul reasoning più sofisticato che Magistral 1.2 sta accorciando ma non ha annullato. Per quei casi la differenza di qualità giustifica i costi e i compromessi sulla sovranità.

Il secondo è la startup early-stage con un team piccolo e zero ops engineering. Mistral via API è semplice, ma quando ha senso passare a self-hosting servono competenze di MLOps che una startup di sei persone non ha. In quei contesti il managed service di OpenAI risparmia mesi di lavoro, e i vincoli di sovranità sono meno stringenti perché il dato del cliente arriva dopo che il prodotto esiste. Mistral diventa la scelta giusta nel passaggio dalla fase early alla fase di scaling enterprise.

Il terzo è il prodotto consumer chat brand-aware. ChatGPT ha vinto la guerra del marchio sul mercato consumer, e per molti casi d’uso l’utente vuole proprio ChatGPT, non un assistente generico. Le Chat di Mistral è un ottimo prodotto, ma se l’obiettivo è uno chatbot brand-coherent per consumer italiani che valga come acquisition channel, l’ecosistema di OpenAI, le sue integrazioni e il suo nome restano un asset che Mistral non eguaglia.

Dire questo apertamente fa parte del lavoro di advisor. Quando un vendor vince sempre su tutto, in un’analisi seria, qualcosa non torna.

I tre scenari italiani dove Mistral è la risposta giusta

Mi è capitato negli ultimi mesi di affiancare aziende che hanno fatto questa scelta, e gli scenari ricorrenti sono tre. Sono quelli che ho davanti più spesso quando mi chiamano per un assessment AI, e probabilmente sono anche i tuoi.

La banca media italiana. Mille o duemila dipendenti, focus retail e PMI, sistemi core legacy ma con un’innovation unit che da due anni sperimenta AI. Il problema concreto è doppio: agosto 2026 porta l’AI Act sui sistemi ad alto rischio, che per le banche include credit scoring, prevenzione frodi, customer journey con decisioni automatiche, e contemporaneamente il rapporto sui costi cloud LLM cresce del 40% trimestre su trimestre.

La configurazione Mistral tipica è ibrida. Mistral Medium 3.5 in self-hosting su due nodi NVIDIA H200 per i carichi sensibili (customer support che tocca dati cliente, sistemi decisionali, generazione documenti contrattuali), Mistral Large 3 via La Plateforme per i carichi esplorativi dove la sovranità è meno critica. Investimento infrastruttura nell’ordine dei 400-500 mila euro una tantum più contratti di supporto, con un break-even sui costi API che si raggiunge tra il diciottesimo e il ventiquattresimo mese per un volume di richieste tipico di un istituto da mille dipendenti.

Il gruppo manifatturiero del Nord. Tre o quattro stabilimenti, ricavi nella fascia 200-500 milioni, prodotti su misura con brevetti propri e know-how di produzione che è il vero asset competitivo. Il problema è che i prompt che farebbero davvero la differenza, quelli che mettono in pari l’AI generativa con un ingegnere senior, contengono dati di produzione, specifiche tecniche riservate, parametri di processo. Caricarli su cloud americano significa metterli in dataset di training futuri, anche con le clausole “data privacy” più tirate, perché il rischio anche solo di esposizione fa già scattare i policy interni.

La configurazione Mistral tipica qui è on-premise pura. Mistral Small 4 o Medium 3.5 su un singolo server NVIDIA H100 in azienda, integrato con la documentazione tecnica via vector database, esposto agli ingegneri di processo come assistente di reparto. Investimento infrastruttura nell’ordine dei 150-200 mila euro, gestione delegata a un partner sistemistico locale, zero traffico esterno per i carichi core. ROI atteso non in risparmio diretto ma in compressione dei tempi di sviluppo prodotto e di problem-solving sulla linea, dove ogni giorno guadagnato vale ordini di grandezza superiori al costo dell’infrastruttura.

La sanità privata romana o milanese. Strutture da 200-500 dipendenti, mix di ambulatorio specialistico, diagnostica, ricovero breve. Il problema è la combinazione GDPR articolo 9 sui dati particolari più AI Act sui sistemi ad alto rischio in sanità, su cui le interpretazioni del Garante diventano più restrittive ogni sei mesi. Inviare dati paziente, anche pseudonimizzati, a un LLM cloud americano significa preparare la difesa legale prima del progetto.

La configurazione Mistral tipica qui è ibrida controllata. Mistral Medium 3.5 self-hosted per tutto quello che tocca dati paziente (refertazione assistita, prima lettura immagini diagnostiche, transcript di visite), Mistral Large 3 via API solo per carichi senza dati personali (knowledge base medica, formazione interna, comunicazione marketing). L’infrastruttura interna costa di più, intorno ai 300 mila euro per il setup iniziale, ma è la sola architettura che permette di sostenere un’ispezione del Garante senza dover dichiarare data breach preventivi.

In tutti e tre i casi, la scelta di Mistral non è ideologica, è strutturale. È quello che permette di fare il progetto AI in conformità con i vincoli esistenti, senza spostare il problema avanti di sei mesi nella speranza che le normative diventino più morbide.

Il percorso pragmatico di impianto

Per un’azienda che oggi sta valutando se Mistral è una scelta sensata, il percorso che funziona è di circa quattro settimane, e non richiede investimenti significativi prima di aver capito se l’opzione regge.

La prima settimana è di assessment dei carichi AI attuali. Mappa di tutte le sperimentazioni in corso, identificazione dei carichi che toccano dati sensibili, classificazione preliminare rispetto all’AI Act, stima del costo annualizzato delle API LLM attuali. Da questa mappa esce la lista dei carichi candidabili a Mistral, che spesso non è il 100% del totale ma una porzione mirata.

La seconda settimana è di prova pilota. Le Chat Pro Team a 24,99 euro al mese per utente per dare ai team interni un assistente che gira su infrastruttura europea, in parallelo qualche giorno-uomo di un developer sui modelli via La Plateforme per validare la qualità sui prompt aziendali reali. Costo totale della prova nell’ordine dei 1.500 euro, output un go/no-go tecnico su Mistral con dati propri, non sui benchmark di marketing.

La terza settimana è di design dell’architettura target. Decisione tra le tre opzioni principali: solo API La Plateforme (low setup, costi ricorrenti), ibrida API più self-hosting parziale (setup medio, ottimizzazione costi a 18 mesi), self-hosting completo (setup alto, sovranità massima). La scelta dipende dal mix dei carichi mappati al primo passo e dal profilo di rischio del settore.

La quarta settimana è di business case e decisione. Confronto a tre anni tra l’architettura proposta e lo status quo, considerando costi infrastrutturali, costi API, costi di gestione, valore della sovranità nel risk management, fattibilità di compliance AI Act. Da qui esce o non esce la decisione di buy.

Questo schema funziona per la maggior parte delle aziende italiane sopra i cento dipendenti. Sotto quella soglia, di solito la complessità organizzativa del self-hosting non si giustifica e Mistral resta interessante via Le Chat e API, senza la parte infrastrutturale.

Queste valutazioni non sono mai solo tecniche. La scelta giusta dipende da come è strutturato il data flow aziendale, dai vincoli regolamentari specifici del settore, dalle competenze interne disponibili, dai progetti AI già in corso. Ogni azienda ha la sua mappa dei rischi e dei vantaggi, e i parametri che ho indicato sono ordini di grandezza che vanno calibrati sul caso reale.

È esattamente il tipo di analisi che mi capita di fare quando un’azienda mi chiede di affiancarla nel ridisegno della propria architettura AI. Se stai facendo questo ragionamento per la tua organizzazione, puoi contattarmi qui per una prima conversazione.

Per chi vuole scendere nel dettaglio dei modelli specifici di Mistral e capire quale conviene per ciascun caso d’uso, ho dedicato un approfondimento su come scegliere tra i modelli Mistral nel 2026 dove confronto Large 3, Medium 3.5, Small 4, Magistral, Devstral e Ministral con i criteri tecnici e di costo. Per chi invece sta valutando le opzioni di acquisto, dall’API a La Plateforme fino al self-hosting on-premise con Forge, c’è la guida dedicata su API, self-hosting, Forge: cosa scegliere e quanto costa davvero.

AI & GENAI, TECH & BUSINESS

10 ragioni per portare l’AI privata al tavolo del board

Quando un’azienda inizia a costruire prodotti su AI, la prima scelta è quasi sempre la stessa: ci si appoggia ai grandi provider americani, e si lascia la AI privata come ipotesi da valutare “più avanti”. OpenAI, Anthropic, Google, qualche volta Mistral. Sono comodi, documentati, hanno API stabili, hanno modelli che funzionano davvero bene, hanno reparti enterprise che rispondono alle email.

Per le prime settimane, va benissimo così. Il problema arriva dopo, quando il prodotto smette di essere un prototipo e diventa qualcosa su cui dipende un pezzo di fatturato, di reputazione, di rapporto col cliente. È a quel punto che la domanda cambia, e diventa una domanda di architettura, non più di tool. Quanto controllo abbiamo davvero sul fondamento di quello che stiamo costruendo?

Negli ultimi mesi ho lavorato su questa domanda con diversi CEO e CTO di aziende italiane, e mi sono convinto che la AI privata vada considerata seriamente per almeno dieci ragioni. Non come fissazione tecnica, non come scelta ideologica anti-Big Tech, ma come opzione architetturale concreta che merita un posto al tavolo del board accanto alle proposte cloud-only.

I dati del cliente finiscono in posti che non controllate

Un contratto enterprise con OpenAI o Anthropic vi dà garanzie legali importanti: zero retention, niente training sui vostri dati, audit trail. Ma il dato tecnico resta: quando il vostro cliente invia una richiesta, quel testo viene processato dentro un data center che non è vostro, da un’infrastruttura che non vedete, sotto giurisdizioni che cambiano in base a dove sta il fornitore. Per applicazioni che trattano contratti, dati sanitari, proprietà intellettuale, strategie commerciali, questa distanza fisica fra dato e azienda è esattamente il punto su cui si stanno irrigidendo i clienti enterprise. Una banca italiana che valuta un vostro prodotto AI non vuole solo sapere che siete GDPR-compliant. Vuole sapere dove gira il modello e chi può guardarci dentro.

Le fondamenta sono in affitto

Costruire un prodotto AI completamente sopra un servizio esterno è comodo per la velocità di sviluppo, ma è l’equivalente di costruire un edificio su un terreno di cui non avete il rogito. Funziona finché funziona. Il giorno in cui il proprietario decide di cambiare le regole del condominio, vi ritrovate a discuterle dalla posizione più debole possibile. Non sto dicendo che OpenAI o Anthropic siano cattivi padroni di casa, anzi. Sto dicendo che la relazione resta strutturalmente asimmetrica, e questa asimmetria diventa rischio quando il vostro prodotto è in produzione presso clienti che si aspettano continuità per anni.

Quanto durano davvero le API che state usando

Modelli che vengono deprecati. Endpoint che spostano comportamento da una versione all’altra. Limiti di token che si modificano. Policy d’uso che si stringono o si allargano. Funzionalità beta che diventano premium. Le aziende che hanno costruito prodotti seri sopra le API dei grandi provider lo sanno: ogni rilascio è anche un piccolo lavoro di regressione testing per capire cosa è cambiato senza preavviso. La vostra roadmap di prodotto non è mai veramente vostra finché dipende dalla roadmap di qualcun altro, soprattutto quando quel qualcun altro rilascia tre versioni maggiori l’anno.

Erediterete la reputazione di chi vi dà il modello

Il nome famoso oggi rassicura il vostro cliente. Domani può finire dentro uno scandalo, una controversia regolatoria, una scelta commerciale impopolare, un caso di sicurezza, un’inchiesta giornalistica. Quando succede, il vostro prodotto eredita istantaneamente la coda di quella reputazione. I clienti più sofisticati lo sanno e mettono nelle loro RFP domande sempre più specifiche su quale modello state usando, dove gira, chi lo controlla. La risposta “usiamo il provider X” è già oggi una risposta che apre conversazioni invece di chiuderle.

I costi non sono sotto il vostro controllo

Potete ottimizzare i prompt, ridurre i token in uscita, fare prompt caching, scegliere il modello più piccolo per ogni task. Sono tutti esercizi utili, e li facciamo tutti. Però il prezzo finale al token lo decide qualcun altro, e lo decide guardando le proprie esigenze di margine, non le vostre. Negli ultimi due anni i costi dei modelli sono scesi rapidamente, ed è una buona notizia per chi è entrato adesso. Ma non c’è nessuna garanzia che continuino a scendere allo stesso ritmo, e ci sono diversi segnali di prezzi che stanno iniziando a risalire su modelli premium con context window molto lunghe o capacità agentic specifiche. Per chi pianifica un business plan a tre anni, è una variabile che vale la pena guardare con attenzione. Su questo tema ho scritto di recente in Quanta intelligenza artificiale stai davvero governando?.

La demo non è la produzione

Quando si dimostra un proof of concept, si usa quasi sempre il modello più potente disponibile. Funziona bene perché costa, e perché si lavora su volumi piccoli. Quando lo stesso prodotto va in produzione con cento clienti, mille clienti, diecimila utenti finali, i conti cambiano: i volumi salgono, la latenza diventa un problema reale, il budget per ogni interazione si stringe, e all’improvviso il modello che faceva la magia nella demo è troppo costoso per girare a regime. Comincia la caccia al modello “abbastanza buono” più economico, e quella caccia si fa molto meglio quando il modello sotto è una commodity che potete sostituire, non un servizio chiuso che dovete riconfigurare ogni volta.

I grandi provider americani non sono imbattibili

C’è un’idea diffusa, e secondo me sbagliata, che i grandi player AI siano destinati a vincere sempre perché hanno inventato la categoria. Non hanno inventato la categoria. Hanno estratto un enorme valore da una combinazione storicamente fortunata di dati pubblici scrapati prima delle restrizioni, infrastruttura GPU comprata in massa al momento giusto, distribuzione ai consumer arrivata prima di tutti gli altri. Tutte cose imitabili da chiunque abbia abbastanza capitale e tempo. Mistral in Europa, DeepSeek e Qwen in Cina, Meta con Llama, Cohere, Stability, decine di laboratori più piccoli stanno già pubblicando modelli open-weight competitivi su task specifici. L’ecosistema sta inevitabilmente convergendo verso una commoditizzazione almeno parziale, ed è ragionevole pensare che fra tre anni il “vincitore” del 2024 non sarà più automaticamente la scelta obbligata del 2027.

La sovranità digitale è diventata clausola contrattuale

Fino al 2023, parlare di sovranità digitale veniva visto come un argomento politico da convegno, lontano dalle decisioni operative di un’azienda. Nel 2026 è diventato un capitolo dei contratti enterprise. Il combinato disposto di GDPR, AI Act europeo, Schrems II, scadenze del PNRR e tensioni geopolitiche fra Stati Uniti, Europa e Cina sta riportando a casa una domanda che sembrava sepolta: dove sta fisicamente il software critico della mia azienda, e chi ha potere giurisdizionale su di esso? Per le aziende che lavorano con la pubblica amministrazione, con la difesa, con il settore bancario o sanitario italiano, questa domanda si è già trasformata in clausole contrattuali specifiche. Per tutte le altre aziende, è solo questione di tempo prima che arrivi nelle gare e nelle due diligence.

Il vendor lock-in tecnico è un debito che si accumula in silenzio

Ogni volta che ottimizzate un prompt per un modello specifico, sviluppate una tool integration su un’API specifica, costruite memoria semantica sopra un embedding-as-a-service specifico, state accumulando un debito tecnico di portabilità. Quel debito non si vede nei primi sei mesi, perché tutto funziona. Si vede al ventiquattresimo mese, quando provate a fare una proof of concept con un altro provider per ragioni di prezzo o di feature e scoprite che la migrazione costa quanto rifare metà del prodotto da zero. Quel debito si riduce drasticamente se il modello sotto è un’astrazione che potete sostituire, e si azzera se quel modello vive dentro un’infrastruttura che possedete. La domanda da farsi oggi non è solo quanto costa cominciare con un provider, è quanto costerebbe cambiarlo fra due anni.

AI Act e compliance non sono un problema futuro

Dall’agosto 2026 entrano in vigore i primi obblighi sostanziali del Regolamento europeo sull’AI per i sistemi ad alto rischio. Le aziende che usano modelli proprietari di terze parti per casi d’uso classificati ad alto rischio si troveranno a dover dimostrare conformità su dati di training, valutazioni di bias, documentazione tecnica, sistemi di monitoraggio, gestione del rischio. Su un modello chiuso, gran parte di queste informazioni vi vengono fornite o non vi vengono fornite dal provider. Su un modello che gira nella vostra infrastruttura, anche se è un modello open-weight scaricato da Hugging Face, la documentazione è almeno auditable, il fine-tuning è tracciabile, il dataset usato è esplicito. La differenza, per chi opera in finanza, sanità, HR, pubblica amministrazione, sta diventando rilevante in modo concreto e a breve termine.

Per chi vuole iniziare, c’è LocalAI.io

La AI pubblica resta utile, e in molti casi resta la scelta giusta per le prime fasi di sperimentazione di un prodotto. Però se la vostra applicazione dipende strutturalmente da privacy, controllo dei costi, sovranità e autonomia strategica, allora la AI privata non è una fissazione tecnica, è semplicemente buona architettura.

Su questo tema ho investito personalmente come cofondatore di LocalAI.io, un progetto open-source che permette di costruire ecosistemi di AI privata a partire dai modelli open-weight già esistenti, con tutto lo stack che serve per portare un prodotto in produzione: gateway compatibile con le API OpenAI, gestione di modelli multipli, RAG, agenti con memoria, deployment on-premise o su cloud privato. LocalAI è usato oggi in produzione da aziende che hanno deciso di avere il proprio strato AI in casa, e da team che vogliono mantenere la flessibilità di cambiare modello senza rifare il prodotto. Per chi vuole capire come funziona nel concreto, ho scritto una guida operativa completa qualche mese fa. Vale la pena darci un’occhiata se queste dieci ragioni hanno toccato qualche corda del vostro contesto.

La domanda finale resta sempre la stessa, e si fa più seria man mano che il vostro prodotto AI cresce. Su cosa state costruendo davvero, comodità immediata di chi vi dà il modello, oppure controllo nel lungo periodo di chi tiene insieme il vostro business? Se è una conversazione che vi sta riguardando, c’è la pagina Advisory con i formati di collaborazione che propongo a CEO e leadership team che stanno affrontando questi temi.

TECH & BUSINESS

LocalAI: la guida per costruire un ecosistema di AI privata, dagli LLM agli agenti con memoria

Per mesi ho visto ripetersi la stessa scena: entusiasmo enorme sull’AI generativa, proof-of-concept ovunque, e poi, quando arriva il momento di portare l’AI dentro processi reali, una domanda che taglia corto: “Dove vivono i dati?”. Subito dopo ne arriva un’altra: “Quanto ci costerà davvero?”. E subito dopo la terza: “Cosa succede se domani cambia un pricing, un accesso, una policy, un modello?”.

È da questa triade (dati, costi, dipendenza) che nasce l’idea della guida su LocalAI. Non come esercizio tecnico, ma come scelta di architettura. E, in fondo, come scelta culturale: riportare l’intelligenza sotto il controllo di chi la usa.

“Guida completa a LocalAI, LocalAGI e LocalRecall” è pensata per costruire un ecosistema di Intelligenza Artificiale privato su hardware consumer: dal server di inferenza agli agenti autonomi, passando per la memoria. Ho provato a scrivere la risorsa che avrei voluto avere io: un percorso unico, pratico, con un filo logico, capace di trasformare pezzi sparsi in una stack coerente.

Il punto di partenza è LocalAI: un server di inferenza che espone API compatibili con OpenAI e permette di eseguire modelli (testo, immagini, audio, embeddings) sul proprio hardware. La compatibilità non è un dettaglio: significa poter “sganciare” un’app dal cloud e reindirizzarla in locale con modifiche minime.

Ma un sistema utile non è solo un modello che risponde. Serve memoria, serve contesto, serve recupero delle informazioni, serve continuità. Per questo la guida si estende a LocalRecall: lo strato di memoria che implementa RAG (retrieval-augmented generation), cioè la capacità di interrogare una base di conoscenza esterna e alimentare il modello con informazioni pertinenti, riducendo errori e allucinazioni e aumentando la qualità delle risposte.

E poi c’è l’ultimo salto: dagli LLM agli agenti. Qui entra LocalAGI, pensato per creare e orchestrare agenti autonomi (anche in modalità no-code/low-code), collegandoli al “cervello” (LocalAI) e alla “memoria” (LocalRecall). Quando questa triade funziona, non stai più giocando con una chat: stai costruendo un sistema capace di fare piani, eseguire task, usare strumenti, ricordare, migliorare.

La struttura del libro riflette questa progressione, perché l’AI locale non è un singolo componente: è un’architettura. Nella prima parte si costruiscono le fondamenta (installazione, modelli, backend, funzionalità principali e ottimizzazioni, con attenzione alla sicurezza). Nella seconda si costruisce la memoria (LocalRecall e le scelte di storage, dalla semplicità alla scalabilità). Nella terza si costruisce l’intelligenza attiva (LocalAGI e la logica agentica). E nella quarta si scende su casi d’uso e appendici operative.

Un aspetto che ho voluto rendere esplicito è che “locale” non significa “romantico”. Significa pragmatico:

  • Privacy: i dati non devono lasciare la macchina, quando non è necessario.
  • Costi: sposti spesa da OPEX variabile (token) a CAPEX + energia, rendendo il budget più prevedibile.
  • Personalizzazione: puoi scegliere modelli, configurazioni, pipeline, senza vendor lock-in.
  • Resilienza: puoi far funzionare parti del sistema anche offline o in rete chiusa.

E poi c’è una parola che spesso manca nel dibattito: responsabilità. Avere controllo significa anche doversi occupare di sicurezza: proteggere endpoint, chiavi, accessi, permessi, logging. La guida insiste su questo perché l’AI locale non è “auto-magicamente” sicura: è solo più governabile, se la governi.

Per chi è questa guida?

Per chi sviluppa e vuole un’alternativa seria al cloud. Per chi fa IT e deve ragionare su TCO e compliance. Per chi costruisce prodotti e vuole embedded AI senza consegnare tutto a terzi. Ma anche per chi, semplicemente, vuole capire la stack: cosa sono i backend di inferenza, perché esistono gli embeddings, come si fa RAG, come si orchestrano agenti, e quali trade-off stai accettando quando dici “usiamo un LLM”.

Nella Nota dell’Autore ho scritto una cosa che per me è centrale: questi strumenti non sono solo strumenti tecnici. Rappresentano una filosofia, accessibilità, trasparenza, controllo, e un invito a contribuire a un ecosistema open-source che sta accelerando a vista d’occhio. La guida è un punto di partenza, non un punto di arrivo. Ma è il punto di partenza che mancava: chiaro, pratico, completo.