Dall’API Gateway all’AI Gateway: governare il traffico verso i modelli AI

Per anni abbiamo raccontato — e costruito — architetture in cui l’API Gateway era il punto centrale di accesso alle API: il componente che gestisce il traffico, applica le policy di sicurezza, garantisce osservabilità e tiene in ordine ecosistemi digitali sempre più complessi. Oggi in quelle stesse architetture sta entrando un nuovo tipo di traffico: le chiamate verso i Large Language Model, siano essi servizi in cloud come OpenAI e Anthropic o modelli open source ospitati nel proprio data center.

A prima vista questo traffico assomiglia molto a quello che conosciamo: è HTTP, trasporta payload JSON, va autenticato, monitorato, protetto. Ma introduce variabili che le API tradizionali non avevano: costi misurati in token, modelli intercambiabili con prezzi e performance molto diversi tra loro, risposte non deterministiche e — soprattutto — dati aziendali e personali che viaggiano dentro i prompt, spesso verso servizi esterni al perimetro aziendale.

Secondo il McKinsey State of AI, l’88% delle organizzazioni utilizza ormai regolarmente l’AI in almeno una funzione di business, e Gartner prevede che entro la fine del 2026 il 40% delle applicazioni Enterprise integrerà agenti AI, contro meno del 5% del 2025. La domanda per chi governa le architetture IT non è più se questo traffico arriverà, ma come gestirlo senza ripetere gli errori già visti con la proliferazione incontrollata delle API. La risposta che il mercato sta dando ha un nome preciso: AI Gateway. E non è un caso che a proporla siano proprio i vendor di API Gateway.

API Management: l’evoluzione naturale di una categoria di prodotto

I principali prodotti di API Management stanno vivendo una trasformazione significativa: dopo aver consolidato le funzionalità classiche — routing, autenticazione, rate limiting, observability — stanno estendendo le stesse capacità al traffico verso i modelli AI.

Kong, che seguiamo e implementiamo da anni presso i nostri clienti, è stato tra i primi a muoversi in questa direzione: il suo AI Gateway non è un prodotto separato, ma un insieme di plugin che si innesta sullo stesso gateway, sulla stessa infrastruttura e sullo stesso modello operativo già in uso per le API.

Questa continuità è il punto architetturale decisivo. Un AI Gateway è, concettualmente, ciò che un API Gateway è sempre stato: un punto di accesso centralizzato che disaccoppia chi consuma un servizio da chi lo eroga, applicando policy trasversali lungo il percorso.

Cambia la natura del servizio a valle — non più un microservizio o un sistema legacy, ma un modello linguistico — e di conseguenza si arricchiscono le policy:

• il rate limiting diventa token limiting: non si contano più solo le richieste al secondo, ma i token consumati, perché è su quelli che si misura il costo;
• il routing diventa model routing: la stessa richiesta può essere indirizzata verso modelli diversi in base a costo, latenza, criticità del caso d’uso o disponibilità del provider, con meccanismi di fallback automatico;
• la gestione delle credenziali si estende alle API key dei provider LLM, che escono dal codice applicativo e vengono custodite centralmente;
• l’observability diventa LLM observability: latenza, token consumati, costi per applicazione, per team, per singolo caso d’uso;
• il caching diventa semantic caching: se due utenti pongono la stessa domanda con parole diverse, il gateway riconosce la somiglianza semantica e restituisce la risposta già generata, riducendo latenza e costi.

Chi ha investito in API Management, in altre parole, possiede già gran parte delle categorie mentali — e degli strumenti — per governare anche l’AI. Ma il modo migliore per capire il valore di questo layer è guardare ai casi d’uso concreti.

Dove l’AI Gateway fa la differenza: i casi d’uso in ambito finanziario e assicurativo

Banche, assicurazioni e istituzioni finanziarie sono tra i settori che stanno adottando l’AI generativa più rapidamente, e al tempo stesso tra i più regolamentati: un contesto in cui la differenza tra adottare l’AI con o senza un layer di governo non è una sfumatura tecnica, ma un fattore abilitante. Vediamo tre scenari.

B2C: l’assistente virtuale che non può permettersi errori

Il caso d’uso più visibile è l’assistente conversazionale rivolto ai clienti: il chatbot che aiuta l’assicurato ad aprire un sinistro, il correntista a comprendere una commissione, il risparmiatore a orientarsi tra i prodotti. Senza un AI Gateway, ogni applicazione dialoga direttamente con il provider LLM: le API key vivono nel codice, i dati personali del cliente — nome, IBAN, targa, condizioni di salute in ambito polizze — finiscono nei prompt senza controllo, e un picco di traffico (o un utente malintenzionato) può generare costi imprevisti.

Con un AI Gateway nel mezzo, lo scenario cambia: i dati personali vengono mascherati automaticamente prima che il prompt lasci il perimetro aziendale, i prompt guard bloccano richieste manipolatorie o fuori ambito (un assistente assicurativo non deve rispondere a domande di consulenza finanziaria non autorizzata), la semantic cache abbatte i costi sulle domande ricorrenti — che in un contact center sono la maggioranza — e il fallback multi-provider garantisce continuità di servizio se il modello primario è degradato. Il risultato è lo stesso assistente, ma con un profilo di rischio e un costo per conversazione radicalmente diversi.

B2B: la rete distributiva come ecosistema AI

È però negli scenari B2B che l’AI Gateway esprime il valore più consistente, perché è lì che si moltiplicano i soggetti da governare. Pensiamo alla rete distributiva di una compagnia assicurativa: agenzie, broker, canali di bancassurance, comparatori. Molte compagnie hanno già costruito verso questa rete un ecosistema di API — quotazione, emissione, consultazione del portafoglio — governato da un API Gateway con piani di consumo, quote e monitoraggio per partner.

Quando la compagnia decide di mettere a disposizione della rete anche servizi basati su AI — un assistente per la preventivazione di rischi complessi, un motore di risposta sulle condizioni di polizza, un supporto alla raccolta delle informazioni precontrattuali — il problema di governo si ripropone amplificato: ogni partner ha volumi, profili di rischio e contratti diversi, e il costo del servizio non è più trascurabile come quello di una API tradizionale, perché ogni chiamata consuma token.

L’AI Gateway permette di trattare i servizi AI esattamente come prodotti API: quote di token per partner e per canale, throttling differenziato, visibilità puntuale su chi consuma cosa e a quale costo, fino alla possibilità di monetizzare il servizio o ribaltarne i costi sulla rete con la stessa logica dei piani API. Senza questo layer, l’alternativa è replicare controlli e contabilizzazione dentro ogni applicazione — con tempi, costi e incoerenze facilmente immaginabili.

B2B: sinistri, underwriting e il routing intelligente dei documenti

Un secondo scenario B2B riguarda i processi documentali interni ed esterni: la gestione dei sinistri, l’underwriting, l’onboarding di clienti corporate. Qui l’AI viene usata per leggere, classificare ed estrarre informazioni da perizie, referti, bilanci, contratti. Non tutti i documenti sono uguali: una fattura di riparazione può essere elaborata da un modello economico e veloce, una perizia medica contiene dati sanitari che non devono lasciare il perimetro aziendale e richiede un modello ospitato on-premise, un bilancio complesso merita il modello più capace disponibile.

L’AI Gateway rende questa strategia una policy di routing, non una scelta cablata nel codice: la stessa applicazione invia tutte le richieste al gateway, e il gateway smista verso il modello giusto in base a regole di costo, sensibilità del dato e criticità del processo. Quando domani un modello nuovo risulterà più conveniente o più accurato, si aggiornerà una configurazione — non dieci applicazioni. E ogni interazione resta tracciata in un audit trail centralizzato: un requisito che in ambito finanziario non è un’opzione, tra DORA, linee guida delle autorità di vigilanza e AI Act, che chiedono di dimostrare come e dove i sistemi AI vengono utilizzati nei processi decisionali.

Perché centralizzare le funzioni in un Gateway

Tutte le capacità descritte — mascheramento, quote, routing, caching, audit — possono in teoria essere sviluppate dentro ogni singola applicazione. È la stessa obiezione che sentivamo anni fa a proposito degli API Gateway, e la risposta è la stessa: ciò che è trasversale va gestito in modo trasversale. Centralizzare queste funzioni in un gateway significa policy uniformi e verificabili, nessun vendor lock-in verso un singolo provider di modelli, un solo punto di audit per la compliance e la libertà, per i team di sviluppo, di concentrarsi sul valore di business invece che sul plumbing.

Su Kong, in concreto, questo si traduce in una suite di plugin dedicati — AI Proxy e AI Proxy Advanced per l’astrazione multi-LLM e il load balancing semantico tra modelli, AI Prompt Guard e AI Semantic Prompt Guard per la protezione dei prompt, AI Semantic Cache per il caching semantico — che si integrano nello stesso ecosistema di monitoring (Prometheus, Grafana, OpenTelemetry) e nello stesso modello dichiarativo di configurazione che i team che usano Kong già conoscono. L’investimento fatto sull’API management non si duplica: si estende.

Ecosistemi API governati, sicuri e affidabili: la filosofia di Intesys

In Intesys accompagniamo da anni le aziende — in particolare nei settori regolamentati — nella costruzione di ecosistemi API governati, sicuri e osservabili. L’estensione verso l’AI Gateway segue la stessa metodologia che applichiamo all’API Management: un assessment del contesto e dei casi d’uso, un proof of concept mirato su uno scenario ad alto valore, una roadmap che porta progressivamente sotto governo tutto il traffico AI dell’organizzazione.

Perché la lezione dell’API sprawl vale il doppio per l’AI: governare non significa frenare l’innovazione, ma renderla sostenibile, sicura e misurabile. E il momento giusto per farlo è ora, quando i casi d’uso sono ancora pochi — non quando saranno decine, ognuno con le proprie chiavi, i propri costi e i propri rischi.