forge_ai: integrare l’AI in un prodotto non è chiamare un’API

Il 10 giugno 2025, poco dopo le nove del mattino ora italiana, ChatGPT ha smesso di rispondere in gran parte del mondo. Nel giro di pochi minuti la piattaforma Downdetector raccoglieva oltre mille segnalazioni, il disservizio si estendeva anche a Sora e l’amministratore delegato di OpenAI, Sam Altman, commentava l’episodio con una battuta sulle schede grafiche «che si sciolgono». Il servizio è tornato pienamente stabile solo la sera, e in alcune aree il giorno dopo.

Per chi usa ChatGPT dal browser, un’interruzione del genere è una seccatura di qualche ora. Per chi ha costruito un prodotto sopra quelle stesse API, è un’altra cosa. Ogni assistente virtuale, ogni funzione di riassunto, ogni estrazione automatica di dati che passava da quel fornitore è andata offline nello stesso istante, senza che il cliente finale capisse perché. La scena si è ripetuta, quasi identica, il 2 dicembre dello stesso anno: migliaia di utenti di nuovo bloccati, un’altra manciata di ore in cui i prodotti che dipendevano da un solo modello hanno semplicemente smesso di funzionare.

Non è un problema di quel fornitore in particolare. È un problema di architettura. E riguarda in modo diretto le software house italiane che stanno mettendo l’AI dentro i propri gestionali e le proprie applicazioni, e le aziende che quelle funzioni le acquistano dando per scontato che restino accese.

Il lavoro vero, quando si porta l’intelligenza artificiale dentro un prodotto, non è la chiamata al modello. È tutto ciò che sta attorno alla chiamata: poter cambiare fornitore senza riscrivere il codice, governare i costi, garantire la continuità del servizio quando un provider cade, proteggere i dati che si sceglie di non mandare fuori. Un software che tratta il proprio fornitore di AI come un dato permanente non ha integrato l’intelligenza artificiale: ha costruito un punto unico di rottura e, insieme, un vincolo di fornitura da cui sarà costoso uscire.

Il fornitore come dipendenza di tipo zero

Nel gergo dell’ingegneria dei sistemi si chiama tier-zero dependency una componente da cui dipende tutto il resto: se cade lei, cade tutto. Un prodotto che chiama un solo modello, di un solo fornitore, ha eletto quel fornitore a dipendenza di tipo zero quasi senza accorgersene. Finché il servizio è acceso, l’illusione regge. Il primo blackout la dissolve.

Il modello mentale del «chiamare un’API» è comodo e fuorviante. Suggerisce che integrare l’AI sia come integrare un servizio di pagamento o una mappa: un endpoint, una chiave, qualche riga di codice. Ma un fornitore di pagamenti si sceglie una volta e raramente si cambia, mentre nel mercato dei modelli linguistici la frontiera si sposta di mese in mese, i prezzi si muovono, un modello viene ritirato e sostituito, un concorrente diventa d’improvviso più conveniente per un certo compito. Legare il proprio codice a un solo provider significa accettare che ogni sua decisione, tecnica o commerciale, diventi una propria decisione subita.

C’è poi la questione della riscrittura. Chi ha integrato un fornitore intrecciando le sue chiamate specifiche in decine di punti del codice scopre, il giorno che vuole cambiare, che «cambiare modello» vuol dire rifare l’integrazione. Il vincolo non è contrattuale, è architetturale, e per questo più insidioso: nessuno lo ha firmato, eppure c’è.

A rendere concreto quel vincolo è il fatto che i fornitori non parlano la stessa lingua. Ognuno ha il proprio formato di richiesta e di risposta, il proprio modo di gestire l’output strutturato, la chiamata di funzione, gli allegati multimodali, lo streaming. Il codice che si appoggia direttamente a uno di essi ne assorbe le idiosincrasie in ogni punto in cui lo tocca. È questo intreccio, più della chiave API, a rendere doloroso il passaggio: non si sostituisce un indirizzo, si smontano decine di piccole assunzioni sparse per il programma.

Lo strato che quasi tutti finiscono per costruire

La risposta a questo problema ha un nome ormai riconosciuto nel settore: gateway. Uno strato intermedio che sta fra l’applicazione e i fornitori di modelli, espone un’unica interfaccia e si occupa, dietro le quinte, di instradare le richieste, gestire il failover da un provider all’altro, tenere la contabilità dei costi, applicare le politiche di accesso. Non è un’idea di nicchia. Nel corso del 2025 e del 2026 è diventata una categoria di prodotto affollata: sul versante open-source e self-hosted c’è LiteLLM, il cui proxy ha superato i quattrocentosettantamila download; sul versante gestito ci sono servizi come OpenRouter, che a giugno 2025 ha raccolto quaranta milioni di dollari a una valutazione di cinquecento milioni; e a segnalare quanto il tema sia entrato nel perimetro della sicurezza, uno degli attori del settore, Portkey, è stato acquisito nel 2026 da Palo Alto Networks.

Attorno all’instradamento si addensano poi le funzioni che, prese una a una, ciascuno finisce per riscrivere da zero: una cache che evita di pagare due volte la stessa domanda, l’osservabilità che dice quanto costa ogni cliente e ogni modello, un modulo di retrieval-augmented generation per interrogare i documenti interni senza rimontarlo a ogni progetto. Sono pezzi noti, e proprio per questo il punto non è inventarli, ma non doverli reimplementare ogni volta, tenendoli in un solo posto governato.

Il punto che accomuna queste esperienze lo ha formulato bene chi quegli strumenti li costruisce: nel momento in cui si aggiunge un secondo fornitore, una logica di failover o un controllo dei costi per team, si sta già costruendo l’infrastruttura di un gateway, che la si chiami così oppure no. La domanda, per una software house, non è quindi «se» avere questo strato, ma chi lo costruisce, dove gira e chi ne governa i dati.

Il costo, e chi lo governa

Un gateway serio non si limita a fare da centralino. Fa una cosa che a fine mese si vede in bolletta: instrada ogni richiesta verso il modello più economico in grado di svolgere quel compito. Riassumere una riga non richiede lo stesso modello di frontiera necessario a ragionare su un contratto di venti pagine, eppure moltissime integrazioni mandano ogni richiesta al modello più potente, e più caro, per pigrizia progettuale. La distanza di prezzo fra i modelli «piccoli» e quelli «di frontiera», a parità di token, è di ordini di grandezza: instradare in modo adattivo, tenendo i modelli grandi solo dove servono davvero, abbassa in modo sensibile il costo medio per richiesta. Le stime pubbliche parlano, in scenari tipici, di risparmi nell’ordine del sessanta-ottanta per cento; la cifra dipende dal traffico e va misurata sul caso concreto, ma la direzione non è in discussione.

Per una software house che rivende lo stesso prodotto a molti clienti, questa contabilità non è un dettaglio amministrativo: è il margine. Sapere quanto consuma ogni cliente, poter fissare tetti di spesa per fascia di servizio, assegnare a un piano economico i modelli piccoli e a un piano superiore quelli di frontiera sono le leve con cui un’offerta basata sull’AI resta sostenibile invece di erodersi a ogni chiamata. Senza uno strato che misura per cliente e per modello, quelle leve semplicemente non esistono.

C’è poi la faccia più delicata, quella dei dati. Non tutto ciò che un’azienda vorrebbe dare in pasto a un modello può lasciare la sua rete. Un documento con dati sanitari, un fascicolo con dati personali di clienti, il codice sorgente proprietario: mandarli a un fornitore statunitense è, per molti professionisti e molte imprese italiane, un problema di conformità prima ancora che di prudenza. Qui l’architettura fa la differenza. Uno strato che può instradare i compiti sensibili verso un modello eseguito localmente, senza che un solo byte esca dalla rete aziendale, e mandare al cloud solo ciò che è innocuo, riporta una scelta binaria e paralizzante, «tutto fuori oppure niente AI», a una decisione governabile richiesta per richiesta.

Fra il tutto-locale e il cloud aperto esiste anche una via di mezzo che l’architettura permette di scegliere con cognizione: eseguire lo stesso modello di frontiera in una regione europea, con residenza del dato garantita per contratto, quando il compito richiede più potenza di quanta ne offra un modello locale ma i dati non possono comunque varcare i confini dell’Unione. Anche qui la decisione non è ideologica ma per singolo compito, e la prende chi ha in mano lo strato, non il fornitore.

Una nota di cautela

Sarebbe disonesto presentare il gateway come una scelta a costo zero. Ha un difetto speculare a quello che risolve: lo strato che protegge dal blackout di un fornitore diventa, a sua volta, una dipendenza di tipo zero. Se è costruito o gestito male, un suo malfunzionamento manda giù tutte le funzioni di AI in un colpo solo, esattamente ciò che si voleva evitare. Chi lo ospita in casa, poi, si assume un onere operativo reale: un database da mantenere, aggiornamenti da seguire, prestazioni da tenere sotto controllo. Non a caso una parte del mercato sceglie la strada opposta, un gateway gestito da terzi, per non doverselo amministrare.

E c’è un caso in cui tutto questo è semplicemente sovra-ingegnerizzazione. Un prodotto che chiama un solo modello, che non ha dati sensibili da proteggere e che non prevede di cambiare fornitore fa bene a restare sull’API diretta: aggiungere uno strato in mezzo introdurrebbe complessità senza un beneficio che la giustifichi. La regola pratica è che il gateway inizia a ripagarsi quando compaiono almeno due di tre condizioni, più fornitori, sensibilità ai costi, dati da tenere in casa; sotto quella soglia, la scelta più matura è non costruirlo. Il valore non sta nell’astrazione in sé, ma nell’averla quando serve e nel non pagarla quando non serve.

Cosa cambia, allora

Riconosciuta la cautela, resta il fatto che la maggior parte dei prodotti seri incontra prima o poi almeno due di quelle tre condizioni. Un SaaS multi-cliente deve tracciare i costi per cliente e differenziare i modelli per fascia di servizio. Un’impresa che lavora con dati riservati deve poter tenere una parte del calcolo in casa. Chiunque abbia visto un fornitore cadere vuole un secondo che subentri in automatico. Per questi casi lo strato non è un lusso: è la parte del prodotto che decide se l’AI regge la produzione o soltanto la demo.

È il terreno su cui AYXZA lavora con forge_ai, la libreria che usa per unificare l’accesso ai modelli nei sistemi che costruisce. Una sola interfaccia in Python che parla a OpenAI, Anthropic, Google Gemini e Vertex, agli endpoint compatibili e ai modelli eseguiti localmente con Ollama; instradamento verso il modello adatto al compito, failover automatico fra fornitori, contabilità dei costi per cliente e per modello, una knowledge base documentale integrata. Interamente self-hosted, senza vincolo di fornitura: i dati restano dove l’azienda decide, e cambiare modello è una riga di configurazione, non un cantiere.

Non è una promessa di magia, ed è bene dirlo con la stessa sobrietà con cui si sono elencati i limiti. È un modo di trattare l’intelligenza artificiale per quello che diventa quando entra in un prodotto: non una funzione da chiamare, ma un’infrastruttura da governare. Il resto, come sempre, è ingegneria: si misura, si testa, si mette in esercizio. E si progetta, dal primo giorno, per il giorno in cui l’API non risponderà.