API, modello aperto o on-premise: come scegliere l’architettura di deployment

Nelle riunioni in cui si decide dove far girare i modelli la discussione parte quasi sempre dal budget e finisce sulla sicurezza, passando per una tabella comparativa di prestazioni che nel giro di sei mesi sarà superata. È il modo più affidabile per prendere una decisione che verrà rifatta.

Le tre opzioni disponibili hanno profili di rischio, di costo e di responsabilità così diversi che confrontarle su un unico asse non porta da nessuna parte. Un’API commerciale trasferisce al fornitore l’onere infrastrutturale e trattiene un vincolo di dipendenza. Un modello a pesi aperti su infrastruttura gestita recupera controllo e sposta il lavoro sul team. Un’installazione on-premise massimizza il governo del dato e introduce un impegno di capitale e di competenze che dura anni.

Il punto di pareggio si sposta con l’utilizzo, non con il volume

L’argomento economico più usato a favore dell’installazione propria è che oltre una certa soglia di volume conviene. È vero e va precisato, perché la variabile che determina il pareggio non è quanto si consuma in totale, è quanto costantemente si consuma.

Un’infrastruttura con acceleratori dedicati si paga a ore, indipendentemente dal fatto che stia elaborando richieste o aspettando. Un carico distribuito in modo uniforme sulle ventiquattro ore riempie quella capacità e rende il costo per operazione molto competitivo. Un carico concentrato in tre ore di punta, con il resto della giornata sotto il 10% di utilizzo, paga capacità ferma per l’85% del tempo e perde qualunque vantaggio, perché il confronto va fatto fra il costo orario dell’infrastruttura e la spesa a consumo che si sarebbe sostenuta soltanto nelle ore attive.

Il calcolo del pareggio va quindi impostato sul fattore di utilizzo e non sul volume mensile. La domanda giusta è quale percentuale della capacità acquistata verrà effettivamente impiegata, e la risposta onesta, nelle organizzazioni con carichi legati agli orari di ufficio, sta quasi sempre sotto il 30%.

Va aggiunta la voce che i confronti trascurano più spesso: il costo delle persone. Un’installazione autogestita richiede competenze di ottimizzazione dell’inferenza, gestione della memoria degli acceleratori, aggiornamento dei modelli, monitoraggio della qualità. Sono profili scarsi e cari, e in molte organizzazioni la scelta on-premise si è rivelata insostenibile non per l’hardware ma per l’impossibilità di trattenere chi lo facesse funzionare.

La residenza del dato è una condizione, non una preferenza

Sul fronte del dato la valutazione cambia natura, perché smette di essere un ottimizzazione e diventa un vincolo. Alcune categorie informative non possono uscire da un perimetro definito, per obblighi settoriali, per clausole verso i clienti o per policy interne che hanno la stessa forza di un obbligo.

Le domande da porre al fornitore, con risposta scritta nel contratto, sono precise.

• Dove risiedono fisicamente i dati durante l’elaborazione e dove eventualmente vengono conservati?
• Per quanto tempo permangono i log delle richieste e chi vi accede?
• I dati inviati vengono usati per addestrare o migliorare i modelli, e con quale meccanismo di esclusione?
• Quali subfornitori intervengono nella catena, per esempio per la moderazione dei contenuti, e in quale giurisdizione operano?

Una precisazione che evita valutazioni sbagliate: molte offerte enterprise delle API commerciali garantiscono residenza europea, esclusione dall’addestramento e conservazione limitata dei log, arrivando a un profilo di conformità che alcune installazioni interne, gestite senza cifratura a riposo e senza segregazione degli accessi, non raggiungono. L’ubicazione fisica dei server non coincide automaticamente con il governo del dato, e un’infrastruttura propria mal gestita espone più di un servizio esterno ben contrattualizzato.

Sul piano regolatorio, chi impiega il sistema conserva gli obblighi previsti dal quadro europeo a prescindere dall’architettura scelta. Il dovere di sorveglianza umana, di informazione e di conservazione dei log non si trasferisce al fornitore perché il modello gira sulla sua infrastruttura.

Chi modifica il modello si porta dietro gli obblighi del fornitore

Un aspetto poco presidiato dell’opzione a pesi aperti riguarda il cambio di ruolo. La norma ISO/IEC 42001 richiede del resto due diligence e contrattualizzazione delle responsabilità anche verso i terzi che forniscono componenti, modelli di base compresi. Scaricare un modello, adattarlo con un addestramento aggiuntivo sui propri dati e metterlo in produzione con il proprio marchio sposta l’organizzazione verso il ruolo di fornitore ai sensi del quadro europeo, con l’insieme di obblighi documentali che ne consegue.

La distinzione non è puramente formale. Un adattamento leggero, che non modifica la destinazione d’uso dichiarata, resta nel perimetro dell’impiego. Un addestramento che cambia il comportamento del sistema o ne estende l’ambito di applicazione produce un sistema nuovo, di cui l’organizzazione risponde. Le aziende che hanno investito nell’adattamento di modelli aperti senza valutare questo passaggio si trovano a dover ricostruire una documentazione tecnica che nessuno aveva pianificato.

Sul versante opposto, i pesi aperti offrono una garanzia che le API non danno: il modello che si è validato resta quello, e nessun aggiornamento del fornitore ne cambia il comportamento da un giorno all’altro. Nei processi soggetti a validazione formale, dove ogni modifica richiede una nuova qualifica, quella stabilità vale più di qualunque differenza di prestazione.

Quattro nodi per arrivare a una scelta difendibile

L’albero che segue si percorre nell’ordine, e ogni nodo esclude opzioni invece di assegnare punteggi.

• Primo nodo, il dato può uscire dal perimetro? Se esistono categorie che per obbligo non possono essere elaborate fuori, l’API pubblica esce dal tavolo per quei flussi specifici, e restano infrastruttura gestita in perimetro controllato oppure installazione propria. Se il vincolo riguarda solo una parte dei casi d’uso, si costruisce un’architettura mista invece di penalizzare tutto il resto.
• Secondo nodo, il comportamento deve restare invariato nel tempo? Se il processo è soggetto a validazione formale o a obblighi di riproducibilità, serve controllo sulla versione del modello, e questo esclude le API che non offrono garanzie di stabilità sulle versioni.
• Terzo nodo, quale fattore di utilizzo è realistico? Sopra il 60% di utilizzo costante l’infrastruttura dedicata diventa competitiva, sotto il 30% quasi mai. In mezzo la decisione si sposta su altri fattori, e conviene non forzarla sull’argomento economico.
• Quarto nodo, esistono le competenze e si possono trattenere? Una risposta negativa a questa domanda annulla i vantaggi teorici delle opzioni autogestite, e conviene affrontarla con il responsabile delle persone prima che con l’architetto.

La configurazione che vedo più spesso funzionare nelle organizzazioni medio-grandi è mista: API commerciale per la maggior parte dei casi d’uso, modello aperto su infrastruttura controllata per i flussi che toccano dati vincolati, con uno strato di astrazione che permette di spostare un caso d’uso da una parte all’altra senza riscrivere l’applicazione. Quello strato costa qualcosa da costruire e restituisce la libertà di cambiare idea, che in un mercato dove i listini si dimezzano ogni dodici mesi vale molto più di un’ottimizzazione al margine.