Il 6 ottobre 2026 Mistral ha lanciato l’anteprima API pubblica di Large 4, un modello nativamente multimodale pensato per coding, agenti e carichi di lavoro enterprise. Nello stesso mese, una rilevazione IDC ha evidenziato che circa la metà delle organizzazioni nei settori regolamentati prevede di spostare training, fine‑tuning e inferenza dei modelli generativi su infrastrutture dedicate on‑premise o in colocation entro 18 mesi. Questi due dati raccontano la stessa storia da due angoli diversi: quando i modelli open raggiungono prestazioni pari a quelli proprietari, il fine‑tuning in locale smette di essere un compromesso tecnico e diventa una scelta difendibile anche dal punto di vista della conformità.

Perché il fine‑tuning in locale torna protagonista nell’autunno 2026

Tra fine settembre e il 20 ottobre 2026 sono stati rilasciati più modelli open o ad accesso aperto rispetto a qualsiasi altra finestra di quattro settimane dell’anno. Alcuni dei più rilevanti sono:

    • Claude Haiku 5.5 (7 ottobre) – 1 milione di token di contesto, 0,10 USD per milione di token in input.
    • GLM 5.3 Fast (7 ottobre) – stesso contesto, output massimo 128 000 token.
    • DeepSeek V4.1 Flash 1017 (17 ottobre) e MiniMax‑M3.1‑Flash (19 ottobre) – ultimi modelli segnalati dal tracker di Opper AI.
    • Gemma 4 26B‑A4B (Google) – disponibile nel servizio Now LLM di ServiceNow per use case sia large che small.

Questa densità di rilasci cambia il calcolo economico del fine‑tuning. Fino a poco tempo fa, personalizzare un modello richiedeva partire da basi con prestazioni nettamente inferiori ai modelli proprietari. Oggi, pesi aperti arrivano già vicini a quelli commerciali su molti task verticali e possono essere specializzati con un dataset interno senza mai inviarlo a un’API terza. Per un ufficio legale, un reparto HR o una sanità territoriale, la differenza tra “i dati restano qui” e “i dati passano per un server americano” non è un dettaglio tecnico: è spesso la condizione che rende un progetto approvabile o no.

Cultura e sicurezza

Più della metà delle organizzazioni intervistate da McKinsey nel 2025 dichiara di usare già tecnologie di AI open source in diverse aree del proprio stack tecnologico, smentendo l’idea che l’open source sia confinato a progetti sperimentali. Tuttavia, oltre il 50 % cita sicurezza e conformità come principale barriera all’adozione più ampia, spiegando perché molti progetti restano nella fase di valutazione anziché arrivare in produzione: non manca la tecnologia, manca spesso un processo chiaro per gestirla in modo conforme.

Confronto costi: modelli proprietari vs open source

Il contesto dei modelli proprietari aiuta a capire perché il fine‑tuning in locale sta tornando centrale anche per chi lavorerebbe volentieri con un’API esterna. Alcuni esempi di pricing recenti:

    • GPT‑6 Astra (OpenAI, 3 settembre 2026) – 10 USD per milione di token in input, 50 USD per milione di token in output.
    • Claude Opus 5.5 (Anthropic, 22 settembre 2026) – 4 USD per milione di token in input, 20 USD in output.
    • Claude Sonnet 5.5 (22 settembre) – 2 USD per milione di token in input, 10 USD in output.

Questi costi sono più alti rispetto a molte alternative open eseguite in locale, dove il prezzo è praticamente nullo al di fuori del consumo energetico e dell’hardware. Inoltre, il ciclo di vita dei modelli cloud si è accorciato: Google ha ritirato Gemini 2.5 Pro, Flash e Flash Lite a favore di Gemini 3.5 Flash, mentre Anthropic ha sostituito Claude Sonnet 4.5 con Sonnet 4.6. Questo accorcia i tempi di aggiornamento e spinge le aziende a considerare soluzioni più stabili e controllabili internamente.

Quando è davvero necessario il fine‑tuning?

Prima di aprire un terminale, chiediti se il problema che vuoi risolvere richiede davvero un fine‑tuning, oppure può bastare RAG o semplice prompt engineering. In sintesi:

    • Fine‑tuning: necessario per cambiare comportamento in modo stabile (tono, formato, stile aziendale) o per task con pattern ripetitivi che il prompt non può imporre con coerenza.
    • RAG (retrieval‑augmented generation): ideale quando serve recuperare informazioni aggiornate o specifiche da documenti, evitando allucinazioni dovute a dataset di training limitati.
    • Prompt engineering: sufficiente per compiti semplici che non richiedono un comportamento persistente.

Molti progetti aziendali combinano le tre tecniche: un modello fine‑tuned per tono e formato, collegato a un sistema RAG per i fatti, con prompt di sistema che gestiscono i casi limite. Questa guida si concentra sulla parte di fine‑tuning, ma è importante valutare prima l’opzione più economica.

Prerequisiti: hardware, software e versioni

Prima di iniziare, verifica di avere a disposizione quanto segue (versioni testate al 20 ottobre 2026):

    • Python 3.11 o 3.12, pip 24.x
    • GPU NVIDIA con almeno 8 GB di VRAM per QLoRA su modelli da 7B (RTX 3060 12GB o superiore consigliata)
    • Driver NVIDIA recenti e CUDA 12.1 o 12.4
    • PyTorch 2.5 compilato per CUDA
    • Librerie: Unsloth, Hugging Face Transformers 4.46, PEFT 0.13, bitsandbytes 0.44, TRL 0.11
    • Almeno 40 GB di spazio libero su disco per pesi, checkpoint e dataset
    • Dataset proprietario di 500‑1 000 esempi (minimo) – idealmente 2 000‑5 000 per risultati stabili
    • Ollama (ultima versione) per il deployment locale

Se non hai una GPU locale adeguata, puoi affittare un’istanza cloud con una RTX 4090 o una A10 per poche ore. In alternativa, per team che preferiscono delegare l’infrastruttura mantenendo il controllo sul dataset, valuta i servizi di fine‑tuning gestito su Bedrock, Vertex AI e Azure AI Foundry, che presentano differenze di costo molto ampie a seconda del modello e del volume di token.

Valutazione costi‑benefici tra locale e cloud

Considera due scenari:

    • Pilota unico: il cloud on‑demand riduce il rischio di acquistare hardware che resta inutilizzato.
    • Aggiornamenti ricorrenti (mensili o trimestrali): una GPU locale si ripaga più rapidamente, eliminando ogni discussione sul transito dei dati durante il training.

Non sottovalutare il tempo umano: la preparazione del dataset da zero richiede più ore del training stesso, quindi includi questa fase nella pianificazione.

Scelta del modello open‑source più adatto

Per il 2026 i modelli più promettenti per il fine‑tuning locale includono:

    • Mistral‑Large 4: multimodale, ottimizzato per coding e agenti, buona compatibilità con LoRA/QLoRA.
    • Claude Haiku 5.5: token di contesto esteso, costo di input minimo, adatto a casi d’uso conversational.
    • Gemma 4 26B‑A4B: equilibrio tra dimensione e capacità, supportato da ServiceNow per integrazioni enterprise.
    • DeepSeek V4.1 Flash: velocità di inferenza elevata, ideale per ambienti con risorse limitate.

Scegli il modello in base a:

    • Dimensione del contesto necessario.
    • Tipo di task (coding, dialogo, generazione testuale).
    • Compatibilità con le librerie LoRA/QLoRA.
    • Licenza d’uso (verifica che consenta uso commerciale e modifiche).

Preparazione del dataset

Un dataset di qualità è la chiave per un fine‑tuning efficace. Segui questi passi:

    • Raccolta: estrai esempi reali dal tuo sistema (email, ticket, documenti medici) rispettando il principio di minimizzazione del GDPR.
    • Anonimizzazione: rimuovi o pseudonimizza dati personali (nomi, ID, dati sensibili).
    • Formattazione: usa il formato JSONL con campi prompt e completion. Esempio: 
      {

      "prompt": "Qual è la procedura per richiedere un congedo parentale?",
      

      "completion": "Il dipendente deve compilare il modulo X..."
      

      }

    • Bilanciamento: assicurati che le classi di risposta siano equilibrate per evitare bias.
    • Validazione: separa il 10‑15 % dei dati per test e valida la qualità delle risposte prima del training.

Fine‑tuning con LoRA e QLoRA

LoRA (Low‑Rank Adaptation) riduce drasticamente il consumo di VRAM aggiungendo solo un piccolo set di parametri addestrabili. QLoRA combina LoRA con quantizzazione a 4 bit, consentendo il training di modelli da 13‑30 B su una singola GPU da 12 GB. Procedura tipica:

    • Installa le librerie richieste: 
      pip install transformers==4.46 peft==0.13 bitsandbytes==0.44 unsloth trl==0.11
    • Carica il modello in modalità 4‑bit: 
      from transformers import AutoModelForCausalLM, BitsAndBytesConfig

      bnbconfig = BitsAndBytesConfig(loadin4bit=True, bnb4bitcomputedtype=torch.float16)
      

      model = AutoModelForCausalLM.frompretrained("mistral/large-4b", quantizationconfig=bnb_config)

    • Applica LoRA: 
      from peft import LoraConfig, getpeftmodel

      loracfg = LoraConfig(r=8, loraalpha=32, targetmodules=["qproj","v_proj"])
      

      model = getpeftmodel(model, lora_cfg)

    • Definisci il trainer con TRL: 
      from trl import SFTTrainer

      trainer = SFTTrainer(
      

      model=model,
      

      traindataset=traindataset,
      

      evaldataset=evaldataset,
      

      maxseqlength=2048,
      

      perdevicetrainbatchsize=2,
      

      gradientaccumulationsteps=4,
      

      numtrainepochs=3,
      

      learning_rate=5e-5,
      

      fp16=True,
      

      )

    • Lancia il training: 
      trainer.train()

Durante il training monitora metriche come loss e perplexity. Un valore di loss inferiore a 0.8 è indicatore di buona convergenza per task di risposta breve.

Valutazione del modello fine‑tuned

Dopo il training, valuta il modello su dati di test:

    • Exact Match e F1 per risposte strutturate.
    • BLEU o ROUGE‑L per generazione libera.
    • Test di privacy leakage: verifica che il modello non rigeneri dati sensibili presenti nel training.

Se le metriche non soddisfano gli obiettivi, considera di aumentare il dataset, regolare il learning rate o aumentare il numero di epoch.

Deployment locale con Ollama

Ollama semplifica il serving di modelli in locale, gestendo container, API REST e interfacce CLI. Passaggi chiave:

    • Installa Ollama (versione 0.4.2 o superiore).
    • Importa il modello fine‑tuned: 
      ollama pull ./path/to/finetunedmodel
    • Configura il server: 
      ollama serve --model finetunedmodel --port 11434
    • Verifica con una chiamata curl: 
      curl -X POST http://localhost:11434/v1/completions -d '{"prompt":"Qual è la procedura di onboarding?","max_tokens":200}'

Per garantire la conformità GDPR, aggiungi un layer di logging che:

    • Anonimizza gli IP degli utenti.
    • Registra solo metadati (timestamp, tipo di richiesta) senza contenuto sensibile.
    • Consente l’esportazione dei log per audit periodici.

Documentazione GDPR per il progetto

Il GDPR richiede 12 punti chiave per il trattamento dei dati AI. Ecco una checklist pratica da includere nel tuo dossier:

    • Base giuridica: verifica che il trattamento sia necessario per l’esecuzione di un contratto o per interessi legittimi.
    • Minimizzazione: usa solo i dati strettamente necessari per il fine di addestramento.
    • Limiti di conservazione: definisci una policy di retention (es. 90 giorni) per dataset e modelli.
    • Trasparenza: informa gli utenti su come i loro dati saranno usati per il fine‑tuning.
    • Consenso: raccogli esplicito consenso dove richiesto, con opzione di revoca.
    • Diritti degli interessati: predisponi procedure per accesso, rettifica, cancellazione e portabilità dei dati.
    • Valutazione d’impatto (DPIA): conduci una DPIA specifica per l’AI, valutando rischi di profilazione.
    • Sicurezza dei dati: crittografia at‑rest e in‑transit, controlli di accesso basati su ruoli.
    • Responsabile del trattamento: nomina un Data Protection Officer (DPO) per il progetto AI.
    • Documentazione dei processi: mantieni registro delle attività di training, versioni dei modelli e dataset utilizzati.
    • Valutazione di bias: esegui test periodici per identificare e mitigare bias discriminatori.
    • Audit e monitoraggio: pianifica audit trimestrali per verificare conformità continua.

Con questi passaggi la tua organizzazione avrà una base solida per dimostrare la conformità sia alle autorità di controllo sia ai soggetti interessati.

Conclusioni e prossimi passi

Il panorama del 2026 dimostra che i modelli open‑source hanno raggiunto una maturità tale da rendere il fine‑tuning locale non solo economicamente vantaggioso, ma anche strategico per la conformità normativa. Seguendo questa guida, potrai:

    • Scegliere il modello più adatto alle tue esigenze operative.
    • Preparare un dataset conforme al GDPR.
    • Eseguire un fine‑tuning efficiente con LoRA/QLoRA.
    • Valutare le performance e i rischi di privacy.
    • Distribuire in locale con Ollama, mantenendo il controllo completo sui dati.

Il prossimo passo è mettere in pratica la checklist GDPR, avviare un piccolo proof‑of‑concept con 500 esempi e misurare il valore aggiunto rispetto a una soluzione basata su API cloud. Con