I guadagni dell'intelligenza artificiale raramente vanno in positivo e il problema, di solito, è legato all'architettura, non al modello. I team distribuiscono un progetto pilota, quindi guardano come salgono i costi a causa dei problemi di latenza, disastri informatici e incidenti di sicurezza che nessuno aveva preventivato. Pertanto, il modello funziona, ma l'infrastruttura sottostante non è mai stata progettata per portare il carico di lavoro in produzione.
Akamai ha commissionato due studi per mettere alla prova l'area in cui si verifica questo problema. Nel rapporto Lo stato dell'AI inferencing nel 2026 sono stati intervistati 200 professionisti che eseguono l'inferencing in fase di produzione, tre quarti dei quali sono ingegneri e architetti, mentre la maggior parte di essi è costituita dai responsabili delle decisioni relative alle operazioni di implementazione. Nello studio sull'impatto della sicurezza delle API nel 2026 sono stati intervistati 1840 professionisti della sicurezza che operano in sei settori e 10 paesi diversi.
I due rapporti sono giunti alla medesima conclusione: la maggior parte dei team lavora su un'infrastruttura progettata per l'addestramento, ma estesa per includere l'inferencing, pertanto mostra lacune in termini di costi, latenza e vulnerabilità.
Queste lacune vengono colmate se si combinano tre aspetti:
Un'architettura che si adatta alle condizioni attuali
Una sicurezza integrata in questa architettura anziché implementata successivamente
Un inferencing posizionato vicino agli utenti per raggiungere gli obiettivi in tempo reale
Nessuno di questi aspetti è una novità in sé. Il problema è trattare questi aspetti come progetti separati di team distinti tra loro.
Iniziamo dalle caratteristiche di base. L'inferencing è il processo in cui un modello addestrato riceve nuovi input e restituisce un risultato. Ogni chiamata di inferencing si muove come una chiamata API, quindi il modello e l'API non sono separati, ma condividono lo stesso percorso di richiesta, le stesse modalità di errore e la stessa superficie di attacco. Questo thread viene eseguito in entrambi i sondaggi.
Dove la centralizzazione non riesce
L'inferencing centralizzato è destinato all'insuccesso. Per l'addestramento, i lavori in batch e i carichi di lavoro che tollerano la latenza, concentrare il computing in alcune grandi aree geografiche è spesso la scelta ideale e Akamai esegue molti carichi di lavoro in questo modo. La storia raccontata dai dati è più specifica e utile: la centralizzazione non riesce per una classe specifica e crescente di carichi di lavoro e molti team non l'hanno riprogettata per questo scopo.
Il rapporto sullo stato dell'AI inferencing ha rilevato che il 75% delle organizzazioni ha spostato l'AI generativa (GenAI) in fase di produzione, ma la loro infrastruttura non è riuscita a tenere il passo. Una quota crescente di questi carichi di lavoro ora comporta notevoli requisiti di latenza in tempo reale che una latenza round-trip in un'area lontana non può soddisfare, pertanto il 60% dei professionisti ritiene che la vicinanza agli utenti e ai dati sia "importante" o "critica".
Anche in tal caso, il 46% continua ad eseguire l'inferencing da un'unica area geografica centralizzata. Il problema è proprio qui: non il fatto che la centralizzazione sia destinata sempre all'insuccesso, ma che una crescente quota di inferencing in fase di produzione deve essere più vicina all'utente rispetto a quanto consentito da un'infrastruttura centralizzata.
I carichi di lavoro che si interrompono per primi sono prevedibili: punteggio delle frodi all'interno di una transazione in tempo reale, agenti vocali, personalizzazione in tempo reale e qualsiasi pipeline agentica che è concatenata con diverse chiamate di modelli prima di restituire una risposta. Ogni hop eredita la latenza dell'ultimo flusso di traffico. Pertanto, immaginiamo se tutto ciò viene concentrato in un'unica area geografica e i ritardi si sommano con il crescente utilizzo, quindi verranno aggiunti centinaia di millisecondi di latenza esattamente quando il carico di lavoro non può affatto permetterselo.
Dunque, la domanda fondamentale è: architettura centralizzata o distribuita? Quali sono i carichi di lavoro che hanno bisogno della prossimità e quali non hanno questa esigenza? I team più efficaci hanno risposto correttamente alla domanda, in base agli specifici carichi di lavoro, invece di concentrare tutto di default in un'unica area geografica e incorrere nei problemi di latenza.
Un'architettura adattabile e costi invisibili
Un ROI debole indica solitamente che un team sta compensando a livello operativo anziché architettonico. Guardiamo ai costi unitari: il costo di una singola richiesta di inferencing, misurata per token o per query. Se non riesci a vedere questo dato, non riesci ad ottimizzarlo né a capire quando si sta allontanando.
La maggior parte dei team non riesce a vedere il dato: il 77% delle organizzazioni non dispone di un'economia a livello di unità coerente che tiene traccia dell'inferencing, il che significa che la maggioranza di esse non riesce a stabilire se un determinato carico di lavoro sta diventando più economico o più costoso in termini di scalabilità. Questo divario di visibilità è anche una lacuna in termini di sicurezza. Un picco imprevisto nell'utilizzo di token è spesso il primo segno di un attacco DoW (Denial-of-Wallet), in cui un criminale aumenta il volume dell'inferencing proprio per far salire i costi.
Quando l'architettura non è in grado di adattarsi da sola, gli ingegneri non sono più in grado di intervenire manualmente, quindi reindirizzano il traffico se si raggiunge un picco in un'area geografica, ma compromettono la qualità delle risposte per mantenere attivo un server in difficoltà. Quando l'inferencing diminuisce, il 51% dei team prova a utilizzare lo stesso modello, facendo aumentare, di solito, la congestione piuttosto che risolvere il problema. Si tratta di una diagnosi errata, che non riesce a scalare. Scalando un sistema rigido, aumentano anche le sue perdite.
La correzione è programmatica:
Contrassegnare ogni richiesta di inferencing con i metadati di modelli e token che vengono trasmessi al monitoraggio in tempo reale per consentire ad un modello non utilizzato di emergere prima di erodere il budget.
Definire il comportamento fail-open e fail-closed nel codice per consentire al sistema di passare ad un risultato memorizzato nella cache o ad un modello locale più piccolo quando quello principale non risponde, senza dover chiamare un tecnico di notte.
Il 64% dei partecipanti al sondaggio valuta già l'instradamento del traffico automatizzato come un requisito fondamentale, il che fa capire le tendenze del mercato.
La distribuzione è il meccanismo delle performance
Se un ROI basso viene mostrato come legato a caratteristiche di alta latenza e bassa conversione, la causa principale è l'area geografica. L'inferencing in tempo reale è improvviso e sensibile alla latenza, quindi non può essere distribuito in modo affidabile dall'Internet pubblico e da un data center distante.
Le cifre sono inflessibili. Se il budget end-to-end è di 250 millisecondi e l'elaborazione richiede 100 ms, mentre l'handshake dell'API richiede 50 ms, rimangono 100 millisecondi per il trasferimento dei dati. Immaginiamo di dover attraversare un continente e il budget finisce prima che si riesca a far funzionare il modello.
L'applicazione dell'inferencing sui PoP distribuiti consente di mantenere il carico di lavoro nella stessa area geografica dell'utente, bypassare la congestione dell'Internet pubblico e rimuovere il limite di velocità imposto da un'architettura centralizzata. La risposta sembra naturale perché, in termini di rete, è locale.
Quando parliamo di aspetti come gli agenti AI, si dice che siano necessarie circa sei interazioni prima che un'attività venga effettivamente svolta. Se l'utente è abbastanza lontano da richiedere un'interazione di 100 millisecondi, allora sono richiesti 600 millisecondi. Questo valore può andare bene per alcune applicazioni, ma oggi esistono molte applicazioni che vengono create sull'edge e sono sensibili alla latenza. Il sistema di AI integrato con la tua auto è fondamentale perché ti consente di ottenere tutti i dati e le informazioni di cui hai bisogno in tempi molto più brevi.
La distribuzione fa un'altra cosa molto importante per la sicurezza. Quando l'inferencing e l'applicazione vengono eseguite nello stesso percorso, la rete può autenticare l'utente, ispezionare la chiamata API ed eseguire il modello in un'unica posizione. Il loop viene chiuso invece di spedire la richiesta attraverso le zone da controllare altrove.
La sicurezza è una proprietà dell'architettura, non un percorso separato
Se non si protegge l'inferencing, non è possibile scalarlo. Se la sicurezza viene considerata come un flusso di lavoro parallelo, va a discapito delle performance. Entrambi gli studi affermano che il vero errore non è la topologia, ma sono le API non protette, non testate e invisibili.
I dati sono allarmanti: L'87% delle organizzazioni ha subito un incidente relativo alla sicurezza delle API nell'ultimo anno, passando dal 76% registrato nel 2022. Tra i team che hanno subito questi incidenti, gli attacchi alle API collegate all'intelligenza artificiale sono stati quelli più comunemente citati nello studio, con il 42% di questi attacchi collegati alle tecnologie dell'intelligenza artificiale.
Oggi, un incidente medio costa 700.000 dollari all'anno, di cui i primi 4 incidenti sono costati oltre 1,8 milioni di dollari. Le API collegate all'intelligenza artificiale non rappresentano un rischio futuro, ma attuale.
È impossibile proteggere ciò che non si vede
In questo caso, la visibilità si muove nel modo errato. Solo il 23% delle aziende sa quali API restituiscono dati sensibili, una percentuale scesa dal 40% registrato nel 2022. È impossibile difendere le proprietà che non si vedono e l'intelligenza artificiale sta espandendo queste proprietà in modo più rapido di quanto riesca a monitorare un inventario manuale. I copiloti implementano endpoint che non vengono mai sottiposti ad una revisione della sicurezza. Le interfacce in linguaggio naturale rendono l'estrazione dei dati tramite gli attacchi di prompt injection un'attività trascurabile per un criminale che trova sguarnito il percorso giusto.
Il problema non è il punto di ingresso di un sistema. Un criminale che riesce a violare una singola API vulnerabile tenterà di effettuare il movimento laterale per accedere ai componenti più importanti: gli archivi delle funzioni in cui sono memorizzati i dati dell'intelligenza artificiale e i repository che contengono i valori e la logica dei modelli.
La microsegmentazione, la best practice di sicurezza che isola i singoli carichi di lavoro, è ciò che contiene il raggio d'azione degli attacchi. La maggior parte delle organizzazioni non l'ha implementata, ma le aziende che l'hanno fatto riescono a contenere gli attacchi più velocemente. La segmentazione basata sulla rete esistente è ampiamente riconosciuta come complessa, laboriosa e inefficace. La moderna microsegmentazione basata sull'intelligenza artificiale risolve questo problema, ma sfida i pregiudizi radicati. Se la segmentazione viene integrata nella stessa rete che distribuisce l'inferencing, si evita di sacrificare la protezione o le performance.
Il modello di implementazione è basato sulle identità. Le organizzazioni devono:
Definire l'accesso in base alle identità dei carichi di lavoro piuttosto che all'indirizzo IP, in modo da consentire ad uno specifico servizio di inferencing di raggiungere esclusivamente un determinato archivio di funzioni
Eseguire l'individuazione continua delle API per individuare gli endpoint di test abbandonati, che risultano ancora vincolati ai dati di produzione
La sicurezza diventa quindi una proprietà permanente dell'ìinfrastruttura invece di un controllo utilizzato una tantum dagli sviluppatori.
Un problema su due binari
Il problema più profondo che viene evidenziato in entrambi gli studi è di tipo organizzativo, non tecnico. I team creano il traffico e il sistema di sicurezza su percorsi separati e il collegamento tra loro è il punto in cui le cose non riescono.
Il problema si presenta come una lacuna di sicurezza: Il 40% dei dirigenti ha riferito di eseguire avanzati test sulle API, mentre solo il 28% dei team DevSecOps che svolgono questo lavoro è d'accordo. I responsabili ritengono che il problema sia stato risolto, quindi la base non viene adeguatamente finanziata, mentre le spese vengono indirizzate verso strumenti adiacenti. La distanza tra ciò che i dirigenti pensano sia protetto e ciò che è effettivamente protetto continua ad aumentare.
Colmare questa distanza richiede ai team che si occupano della gestione del traffico e ai team che si occupano della protezione del traffico di operare sullo stesso piano di controllo o almeno su un piano convergente. Se le operazioni necessarie per rilevare e contenere le minacce condividono questo piano, un modello di richiesta anomalo, che è tipico degli attacchi di prompt injection o DoW, può attivare l'isolamento automatico dell'endpoint di inferencing interessato, senza richiedere alcun intervento da parte dell'uomo. Questa sincronizzazione è possibile solo quando la distribuzione e la sicurezza non sono sistemi separati.
Cosa scalare a questo punto
Due capacità distinguono i team che riescono a scalare da quelli che rimangono bloccati:
Portabilità. Gli operatori più esperti sono significativamente meno vincolati perché riescono a spostare i carichi di lavoro tra GPU gestite, API ospitate e runtime senza server come variazione di costi e capacità.
Governance del runtime. Il controllo dei messaggi dannosi in entrata e delle risposte che fanno esfiltrare i dati viene applicato al livello della rete anziché implementato nell'applicazione.
Se inseriamo questo controllo su un'unica piattaforma in cui distribuzione, sicurezza e gestione del traffico condividono un unico piano di controllo, si elimina il compromesso tra protezione e performance. Puoi vedere ciò che viene eseguito e dove e se c'è un attacco in corso.
Questo è il problema che Akamai ha risolto per la delivery e la sicurezza dei contenuti e che ora sta risolvendo per l'inferencing in fase di produzione. La stessa rete globale che avvicina l'inferencing agli utenti esegue anche il sistema di sicurezza delle API, la microsegmentazione e la protezione dagli attacchi DDoS (Distributed Denial-of-Service). È questo ciò che consente a una rete di eseguire entrambi i processi contemporaneamente.
Uno scarso ROI dell'intelligenza artificiale è un sintomo
La causa è un'infrastruttura che non ha ancora portato i livelli di architettura, sicurezza e distribuzione adattabili sulla stessa base. Il divario tra performance e protezione si sta ampliando, ma non è né strutturale né permanente. Questo divario viene colmato quando i team che eseguono il traffico coincidono con quelli che si occupano di proteggere l'infrastruttura creata per supportare l'inferencing anziché aggiornata per tollerarlo.
Ulteriori informazioni
Per ulteriori informazioni, puoi leggere il rapporto sullo stato dell'AI inferencing nel 2026 e lo studio sull'impatto della sicurezza delle API.
Tag
