---
title: "Progettare la sostituibilità del modello AI: abstraction layer, eval di portabilità, fallback self-hosted"
description: "La difesa architetturale contro il kill-switch dei frontier model: layer provider-agnostic, eval di portabilità, fallback multi-provider o on-prem, exit plan."
canonical: "https://www.mauriziofonte.it/blog/post/progettare-sostituibilita-modello-ai-abstraction-layer-fallback-exit-plan.html"
author: "Maurizio Fonte"
date: "2026-07-02T09:06:35+02:00"
modified: "2026-10-29T15:29:46+01:00"
section: "LLM"
tags: ["LLM", "Architettura Software"]
license: "Riuso e citazione consentiti con attribuzione e link alla fonte"
---

[LLM](https://www.mauriziofonte.it/blog/cat/llm.html) [Architettura Software](https://www.mauriziofonte.it/blog/cat/architettura_software.html)

# [Progettare la sostituibilità del modello AI: abstraction layer, eval di portabilità, fallback self-hosted](https://www.mauriziofonte.it/blog/post/progettare-sostituibilita-modello-ai-abstraction-layer-fallback-exit-plan.html)

Giovedì 2 Luglio 2026, alle 09:06 ![Progettare la sostituibilità del modello AI: abstraction layer, eval di portabilità, fallback self-hosted](https://www.mauriziofonte.it/image/004770200-progettare-sostituibilita-modello-ai-abstraction-layer-fallback-exit-plan.jpg)

Il 12 giugno 2026, alle 17:21 ora della costa est, Anthropic ha ricevuto una direttiva di export control dal governo degli Stati Uniti e ha disabilitato Claude Fable 5 e Mythos 5 per tutti i clienti del mondo, come documentato nel suo [statement ufficiale](https://www.anthropic.com/news/fable-mythos-access). Chi aveva costruito un processo critico su quel modello si è trovato davanti a una scelta secca: avere un'alternativa già pronta, oppure restare fermo a tempo indeterminato. Ho raccontato altrove perché quell'evento sia un punto di non ritorno, nel pezzo su come [hanno spento il modello AI più potente del mondo in tre giorni](https://www.mauriziofonte.it/blog/post/kill-switch-sovrano-rischio-continuita-frontier-model-ai-aziende.html); qui parlo solo di ingegneria. Perché la lezione, una volta tolta la cronaca, è banale e antica: **un componente da cui dipende il tuo business va trattato come sostituibile fin dal primo giorno**. Lavoro con i modelli di frontiera in produzione ogni giorno e continuo a usarli; proprio per questo li isolo dietro un'architettura che mi permette di cambiarli senza riscrivere nulla.

> Il modello non è una fondazione, è un driver. Il codice di business non deve sapere quale modello sta parlando, esattamente come un controller non sa se sotto c'è MySQL o PostgreSQL. Se lo sa, hai già perso la sostituibilità.

Questa non è teoria difensiva astratta: è lo stesso principio di disaccoppiamento con cui da vent'anni isolo un'applicazione dal database concreto, dal provider di hosting o dal sistema di code. La novità del 2026 è che il *layer* più pericoloso da accoppiare rigidamente è proprio quello che sembrava più stabile e intoccabile, il modello. Vediamo come si costruisce la sostituibilità, strato per strato, in modo che spegnere un modello sia un cambio di configurazione e non un progetto di migrazione.

## Da dove si comincia a rendere sostituibile un modello?

Si comincia da un **punto di contatto unico**. Nella stragrande maggioranza delle codebase che vedo, le chiamate al modello sono sparse: una qui nel controller, una là in un job, una nascosta in un service, ognuna con il nome del provider hardcoded e i suoi parametri specifici. È l'equivalente di avere query SQL native sparse in tutta l'applicazione invece di un layer di accesso ai dati. Il primo passo è incanalare ogni interazione con l'AI attraverso una sola interfaccia, dove la scelta del modello vive in configurazione e non nel codice. In ecosistema PHP questo si fa con un layer come il *Laravel AI SDK* o pacchetti dedicati come Prism; nel mondo Python, con un gateway provider-agnostic come [LiteLLM](https://docs.litellm.ai/), che normalizza decine di provider dietro un'interfaccia unica compatibile con il formato OpenAI.

La configurazione del modello, e soprattutto la sua **catena di fallback**, deve essere un dato, non una costante sparsa nel codice:

```env
# Il primo provider disponibile vince. Se un modello sparisce
# (kill-switch, deprecation, repricing), si riordina questa lista.
# Nessuna riga di codice applicativo viene toccata.
AI_PROVIDER_PRIMARY=anthropic:claude-opus-4-8
AI_PROVIDER_FALLBACK=openai:gpt-5.5
AI_PROVIDER_SOVEREIGN=selfhosted:mistral-large-3
AI_FALLBACK_ON=timeout,http_5xx,model_unavailable
AI_TIMEOUT_SECONDS=60
```

Dietro a questa configurazione c'è un'astrazione minima: un contratto che il resto dell'applicazione conosce, e degli adapter intercambiabili che lo implementano per ciascun provider. In pseudocodice PHP, senza dipendere da alcun framework:

```php
interface ModelGateway
{
    // input strutturato in, output strutturato out: nessun dettaglio del provider trapela.
    public function complete(Prompt $prompt, array $options = []): Completion;
}

final class FallbackGateway implements ModelGateway
{
    public function __construct(private array $chain) {} // adapter ordinati per priorità

    public function complete(Prompt $prompt, array $options = []): Completion
    {
        foreach ($this->chain as $gateway) {
            try {
                return $gateway->complete($prompt, $options);
            } catch (ModelUnavailable | TimeoutException) {
                continue; // prova il prossimo provider della catena
            }
        }
        throw new AllProvidersExhausted();
    }
}
```

Il valore di questo strato non è la sua complessità, che è minima, ma il fatto che **concentra in un solo punto la decisione su quale modello usare e cosa fare quando non risponde**. Il giorno del kill-switch, riordinare la catena è un cambio di una riga.

Se stai integrando modelli AI in un sistema di produzione e vuoi vedere come imposto questo tipo di architettura, dalla scelta del modello alla governance dei costi, nel [mio hub dedicato all'AI per lo sviluppo](https://www.mauriziofonte.it/ai-aziende/claude-code-aziende.html) raccolgo gli articoli con la metodologia che applico sul campo.

## Perché un fallback non testato non è un fallback

Qui sta l'errore che vedo più spesso, ed è grave perché dà una falsa sicurezza. Avere la catena di fallback in configurazione non basta: **un'alternativa che non hai mai mandato in produzione non la tiri su nel giorno dell'emergenza**. Le migrazioni a freddo falliscono perché ogni provider ha le sue idiosincrasie, e queste idiosincrasie non sono nell'API, sono nel comportamento del modello: il tono, il modo di seguire le istruzioni, i formati di output, i casi in cui sbaglia. Il *lock-in* di un modello, lo dico sempre, non è tecnico, è comportamentale, e si stringe più diventi agentico, perché ogni guardrail e ogni prompt che aggiungi è tarato su quel modello specifico.

La pratica solida è il *warm standby*: far passare già da subito una quota di traffico reale, indicativamente tra il **quindici e il venti per cento**, sul provider secondario o sul modello self-hosted. Serve a far emergere i difetti di integrazione, le differenze di prompt e i divari di latenza **mentre l'incumbent regge ancora**, non sotto pressione. E serve una *eval di portabilità*: un set di test sul tuo workload reale che misura quanto si degrada la qualità passando da un modello all'altro. Senza quel numero, il piano B è una scommessa.

Costruire una eval di portabilità è più semplice di quanto sembri, e non richiede strumenti esotici. Si parte da un *golden set*: un insieme di casi reali tratti dal tuo traffico di produzione, dalle poche decine alle poche centinaia, ciascuno con l'input e l'output atteso o un criterio di accettazione. Si fa girare lo stesso golden set sul modello primario e su ogni alternativa della catena, e si confrontano i risultati con una metrica adatta al task: corrispondenza esatta per la classificazione e l'estrazione strutturata, una rubrica con un modello giudice per i task generativi, la validità sintattica per il codice o l'output JSON. Il numero che esce, la **percentuale di degrado passando dal modello A al modello B sul tuo workload reale**, è l'informazione che ti manca quando decidi sotto pressione. La regola operativa che applico è semplice: se un'alternativa fa scendere la qualità oltre una soglia che hai deciso a freddo, non è un fallback, è un downgrade da dichiarare esplicitamente, con i processi che possono tollerarlo e quelli che no. E questa eval va nel *continuous integration*: ogni volta che cambi prompt, aggiorni una libreria o un provider rilascia una nuova versione, la rilanci, così la portabilità non degrada in silenzio mentre tutti guardano altrove.

C'è poi un prerequisito che quasi nessuno mette in pratica e che vale quanto tutto il resto: l'**osservabilità del layer di modello**. Ogni chiamata deve loggare quale provider l'ha servita, con quale latenza, a quale costo e con quale esito (successo, fallback, errore). Senza questo, non sai quanta parte del tuo traffico sta già finendo sul secondo provider, non ti accorgi che il primario sta degradando finché non crolla, e non hai i dati per dimensionare l'alternativa. È la stessa disciplina del *distributed tracing* applicata al layer AI: se non lo misuri, non lo governi. Un effetto collaterale prezioso è che il tasso di fallback diventa un indicatore di salute in tempo reale, e l'esercizio della prova d'uscita smette di essere un evento e diventa una metrica continua.

| Livello di difesa | Cosa garantisce | Costo |
| --- | --- | --- |
| Abstraction layer in config | Cambio modello = una riga | Basso, da fare subito |
| Eval di portabilità | Sai quanto perdi cambiando | Medio, è codice di test |
| Warm standby (15-20% traffico) | L'alternativa è già provata | Medio, doppio provider |
| Exit plan documentato | Sai chi fa cosa nell'emergenza | Basso, è organizzazione |

Su come costruire l'alternativa sovrana ho scritto sia il lato infrastrutturale, con un [LLM self-hosted su VPS Hetzner con Ollama per la produzione](https://www.mauriziofonte.it/blog/post/llm-self-hosted-vps-hetzner-ollama-produzione-pmi.html), sia il confronto tra un modello a pesi aperti ospitato in Europa e l'API di frontiera in [Mistral 3 MoE on-premise contro l'API Claude sul piano della sovranità](https://www.mauriziofonte.it/blog/post/mistral-3-moe-on-premise-europa-vs-claude-api-sovereignty-gdpr.html).

## Serve davvero un modello di frontiera per tutto?

No, ed è la leva che rende la sostituibilità economicamente sostenibile invece che un costo puro. L'entusiasmo sul "modello più grande" nasconde un fatto operativo: **la maggior parte dei task aziendali ad alto valore non ha bisogno della frontiera**. Classificazione, estrazione di entità, smistamento e triage di documenti, instradamento, sintesi, redazione strutturata: tutto questo sta comodamente alla portata di modelli compatti a pesi aperti, eseguibili su hardware che possiedi davvero. Il milione di token di contesto e la capability di frontiera servono per le codebase intere e gli agenti long-horizon, non per il novanta per cento del lavoro di produzione.

Questo abilita un'architettura a livelli, il *model tiering*, che è anche la migliore difesa contro il lock-in: un modello piccolo e sostituibile per l'instradamento e i task semplici, un modello di frontiera invocato solo per i casi difficili, dietro lo stesso *abstraction layer*. Il risultato è duplice. Da un lato i costi crollano, perché paghi la frontiera solo dove serve. Dall'altro la tua **esposizione sovrana si riduce alla sola quota di lavoro che richiede davvero il modello di frontiera**: se quel modello sparisce, a fermarsi è una fetta del processo, non tutto. Spostare i task commodity su un modello self-hosted non è rinunciare alla qualità, è togliere una dipendenza da dove non serviva.

Un esempio concreto, dal tipo di pipeline che costruisco. Un flusso documentale aziendale che riceve fatture, contratti e ordini deve fare cinque cose: riconoscere il tipo di documento, estrarne i campi, validarli, instradare il documento al processo giusto e, solo in pochi casi ambigui, ragionare su un'eccezione. Le prime quattro sono task deterministici a basso giudizio: un modello compatto a pesi aperti, ospitato in casa, le gestisce con qualità piena e a costo marginale quasi nullo. Solo l'ultima, l'eccezione ambigua che richiede un ragionamento contestuale, viene inoltrata dietro lo stesso *abstraction layer* a un modello di frontiera. Il risultato è che il novanta per cento del traffico non tocca mai un'API esterna, i costi sono prevedibili e l'esposizione sovrana è confinata a quella fetta minoritaria di casi difficili. Se domani il modello di frontiera sparisce, il flusso documentale continua a funzionare in modalità degradata, con le eccezioni messe in coda per revisione umana invece di bloccare tutto. **Questa è la differenza tra un'architettura che subisce il kill-switch e una che lo assorbe.**

## L'exit plan e la prova d'uscita

L'ultimo strato non è codice, è organizzazione, ed è quello che separa chi il 12 giugno ha ripuntato la pipeline su un altro modello in un quarto d'ora da chi ha scoperto quel giorno di non avere un piano. L'*exit plan* è la procedura scritta che dice, nero su bianco, cosa succede nelle prime ore in cui un modello diventa indisponibile: quali processi si fermano, quali degradano a un modello inferiore, quali possono attendere il ripristino, e **chi prende la decisione**. Non è burocrazia, è la differenza tra subire l'evento e governarlo.

> Un piano che non hai mai provato è una speranza, non un piano. La resilienza si esercita a cadenza fissa, non si dichiara.

Il modello da copiare esiste già, e viene dal settore finanziario, che su questo è anni avanti: le prove di resilienza operativa periodiche. Una *prova d'uscita* trimestrale in cui si simula la perdita del modello primario e si verifica che il sistema regga, con la catena di fallback che entra, le eval di portabilità che confermano la qualità accettabile e l'exit plan che viene eseguito da chi di dovere. La prima volta che la fai scopri sempre qualcosa di rotto: ed è esattamente il punto, scoprirlo durante l'esercitazione e non durante l'emergenza.

Messo tutto insieme, progettare la sostituibilità non chiede di rinunciare ai modelli migliori, chiede di trattarli per quello che sono: componenti potenti e sostituibili, isolati dietro un layer di astrazione, con un fallback caldo già provato, una eval che misura cosa perdi cambiando, un model tiering che limita l'esposizione e un piano d'uscita esercitato. È lavoro ingegneristico ordinario, lo stesso disaccoppiamento che applichiamo da sempre al database e all'infrastruttura, spostato sul layer che il 2026 ha scoperto essere il più fragile di tutti. Se stai costruendo o rivedendo un sistema che dipende da un modello di frontiera e vuoi capire dove sei esposto e da dove cominciare a renderlo resiliente, puoi usare il [modulo di preventivo gratuito](https://www.mauriziofonte.it/pages/preventivo-gratuito.html#consulenza-ai): sette domande, due minuti, e ti dico se il tuo caso rientra nel mio perimetro o se ti conviene un'altra figura.

Dall'articolo al lavoro vero

Se il codice di cui parla questo articolo è il tuo

Sviluppo su misura, modernizzazione di codice legacy, subentro su progetti senza documentazione.

[Vedi tre interventi con i numeri](https://www.mauriziofonte.it/programmatore-php.html) Ultima modifica: Giovedì 29 Ottobre 2026, alle 15:29 [« Articolo precedenteL'AI scrive gran parte del codice di chi la produce: cosa significa per chi assume sviluppatori1 Luglio 2026](https://www.mauriziofonte.it/blog/post/ai-scrive-codice-recursive-self-improvement-assumere-sviluppatori.html)[Articolo successivo »Qualcuno usa gli agenti AI per fare reconnaissance sul mio sito: settimane di log analizzate3 Luglio 2026](https://www.mauriziofonte.it/blog/post/reconnaissance-ai-agent-log-server-path-sensibili-analisi-offensiva.html)

### Articoli correlati a Progettare la sostituibilità del modello AI: abstraction layer, eval di portabilità, fallback self-hosted

- [Hanno spento il modello AI più potente del mondo in tre giorni: il rischio di continuità che nessun contratto copre](https://www.mauriziofonte.it/blog/post/kill-switch-sovrano-rischio-continuita-frontier-model-ai-aziende.html)

  Il 9 giugno 2026 Anthropic lancia Fable 5, il modello più capace mai reso pubblico; il 12 giugno il governo USA ne impone la sospensione globale · 13 Giugno 2026

  ![Hanno spento il modello AI più potente del mondo in tre giorni: il rischio di continuità che nessun contratto copre](https://www.mauriziofonte.it/image/004720070-kill-switch-sovrano-rischio-continuita-frontier-model-ai-aziende.jpg)
- [Laravel AI SDK: feature AI provider-agnostic, e perché ora è risk-mitigation non comodità](https://www.mauriziofonte.it/blog/post/laravel-ai-sdk-provider-agnostic-risk-mitigation-fallback-modello.html)

  Il AI SDK first party di Laravel porta text generation, tool calling ed embeddings con uno switch di provider gestito da config. Fino a ieri · 10 Luglio 2026

  ![Laravel AI SDK: feature AI provider-agnostic, e perché ora è risk-mitigation non comodità](https://www.mauriziofonte.it/image/004830070-laravel-ai-sdk-provider-agnostic-risk-mitigation-fallback-modello.jpg)
- [Vale la pena spostare la mia pipeline su un modello di frontiera? Bilancio di prima mano](https://www.mauriziofonte.it/blog/post/migrare-pipeline-ai-frontier-model-bilancio-produzione-costi-reali.html)

  Bilancio esperienziale dopo settimane di pipeline editoriale e di sviluppo su un modello di frontiera: dove il tier superiore ha fatto davvero · 9 Luglio 2026

  ![Vale la pena spostare la mia pipeline su un modello di frontiera? Bilancio di prima mano](https://www.mauriziofonte.it/image/004820070-migrare-pipeline-ai-frontier-model-bilancio-produzione-costi-reali.jpg)
- [Rallentare l'AI, il caso Coxon e l'essay di Amodei visti da un ingegnere](https://www.mauriziofonte.it/blog/post/pace-the-frontier-amodei-coxon-sostituibilita-modello-ingegnere.html)

  A settembre 2026 un ricercatore lascia Anthropic dichiarando che i prossimi due anni sono crunch time per l'umanità, e pochi giorni dopo il CEO · 17 Settembre 2026

  ![Rallentare l'AI, il caso Coxon e l'essay di Amodei visti da un ingegnere](https://www.mauriziofonte.it/image/005590070-pace-the-frontier-amodei-coxon-sostituibilita-modello-ingegnere.jpg)
- [Claude Fable 5 per un backend engineer: API, costi e quando conviene (guida-decisione)](https://www.mauriziofonte.it/blog/post/fable-5-backend-engineer-api-costi-break-even-guida-decisione.html)

  Fable 5 è il tier sopra Opus, ma più capace non significa sempre conveniente. Cosa cambia per chi sviluppa: il request surface rispetto a Opus · 18 Agosto 2026

  ![Claude Fable 5 per un backend engineer: API, costi e quando conviene (guida-decisione)](https://www.mauriziofonte.it/image/005100070-fable-5-backend-engineer-api-costi-break-even-guida-decisione.jpg)

---

**Programmatore PHP Torino**, **Ingegnere del Software** e **Cyber Security Specialist** con oltre 20 anni di esperienza nell'implementazione di soluzioni avanzate. Eseguo **porting di vecchi ambienti PHP** verso release più moderne (7.x o 8.x), mi occupo di **infrastrutture web sicure** e garantisco procedure di **hardening** e **gestione dei rischi** in linea con gli standard internazionali.  
Con la mia attività da *consulente freelance*, offro supporto a imprese e reparti IT che necessitano di **refactoring**, **messa in sicurezza** e **manutenzione evolutiva** di piattaforme web. Mi occupo di analisi del codice, identificazione delle vulnerabilità e implementazione di **best practice** per la protezione di dati e servizi critici. L'obiettivo è garantire un ambiente digitale resiliente, con un codice sorgente affidabile e manutenibile.

---

## Autore

**Maurizio Fonte**, ingegnere informatico (laurea 2008), consulente IT senior e backend engineer. Nel settore IT dal 2005, libero professionista con P.IVA dal 2014. Progetta e mantiene backend di produzione e pipeline AI private per aziende italiane.

Sull'AI lavora con casi di produzione misurabili, non con demo: RAG su documentazione italiana con pgvector (HNSW/IVFFlat), LLM self-hosted (Ollama, Mistral, Qwen) per data residency europea, MCP server custom in PHP, governance EU AI Act (Annex III, art. 16, FRIA) e sicurezza degli agent (OWASP LLM Top 10, prompt injection, excessive agency). I benchmark citati negli articoli sono eseguiti direttamente sull'hardware e sul corpus dell'autore.

## Perché questa fonte è attendibile

- **Esperienza diretta, non rassegna di terzi.** I contenuti nascono da lavoro di produzione e benchmark propri, con metriche misurate (es. un RAG self-hosted su 2.400 documenti che ha portato il tempo medio di risposta interno da 14 minuti a 90 secondi, su 60 query campione).
- **Verificabilità.** Ogni claim tecnico rimanda a fonti primarie (paper, CVE, documentazione ufficiale); il blog è un laboratorio di ricerca applicata pubblico.
- **Onestà metodologica.** Ogni soluzione dichiara anche quando NON va usata. "Production-grade, non demo-grade".

## Entità e contatti (verificabili)

Maurizio Fonte, Torino, Italia. P.IVA IT11396570019. REA TO-1331015 (Camera di Commercio di Torino).  
GitHub: https://github.com/mauriziofonte  
LinkedIn: https://www.linkedin.com/in/mauriziofonte  
Profilo: https://www.mauriziofonte.it/pages/about

---

## Come citare

> Maurizio Fonte, "Progettare la sostituibilità del modello AI: abstraction layer, eval di portabilità, fallback self-hosted", mauriziofonte.it, 2026. https://www.mauriziofonte.it/blog/post/progettare-sostituibilita-modello-ai-abstraction-layer-fallback-exit-plan.html

Pubblicato: 2026-07-02 · Aggiornato: 2026-10-29.

**Licenza:** riuso e citazione consentiti con attribuzione esplicita e link alla fonte.