Un'impresa che desidera utilizzare un modello generativo deve decidere dove transitano i dati, chi gestisce il modello, quali tracce vengono conservate e come cambiare fornitore. La parola « sovrano » racchiude diverse aspettative: residenza, controllo giuridico, padronanza tecnica, indipendenza economica, software aperto o capacità di funzionare senza un determinato attore.
Nessuna architettura massimizza simultaneamente qualità, semplicità, elasticità, costo e controllo. Una decisione solida inizia classificando gli usi e i dati, quindi confronta gli scenari con gli stessi criteri.
Definire la sovranità ricercata
Un'organizzazione può cercare:
- la riservatezza, per evitare un uso o una conservazione non autorizzati;
- la localizzazione, per operare in una regione o in un paese specifico;
- il controllo operativo, per gestire accessi, log e versioni ;
- la portabilità, per cambiare modello o provider;
- l’autonomia, per continuare a funzionare senza dipendenza esterna ;
- la trasparenza, grazie a pesi o componenti aperti;
- il controllo economico, per evitare un costo variabile incontrollato.
Queste dimensioni devono essere ponderate. Un'API può offrire eccellenti garanzie contrattuali senza dare il controllo del modello. Un server locale può dare il controllo dell'infrastruttura pur dipendendo da una GPU, da un software o da una licenza straniera.
Classificare i dati e le azioni
Lo stesso progetto può gestire contenuti pubblici, note interne, dati personali e segreti. Trattarli in un ambiente unico impone il livello di controllo più elevato a tutti gli usi, spesso a un costo inutile.
Una classificazione pratica distingue:
- pubblico ;
- interne ;
- riservato;
- regolamentato o contrattualmente limitato;
- critica segreta.
Precisa anche i dati derivati: prompt, embeddings, registri, cache, valutazioni e output. Una risposta generata a partire da un dato sensibile può essa stessa essere sensibile.
I cinque scenari di architettura
1. API pubblica
Il fornitore gestisce il modello e l'infrastruttura. L'integrazione è rapida, le capacità sono elastiche e i modelli più recenti sono accessibili. Occorre verificare la conservazione, l'addestramento, i subappaltatori, la regione, la sicurezza e le condizioni di uscita.
Questa opzione è adatta ai dati compatibili con le garanzie ottenute e agli usi in cui la qualità o la velocità di innovazione prevale.
2. API con ambiente o regione dedicata
Alcuni servizi offrono un trattamento regionale, una capacità dedicata o controlli rafforzati. Questo può rispondere a requisiti di prestazioni e di governance, ma rimane un servizio gestito da terzi. I termini precisi del contratto fanno fede.
3. Cloud privato gestito
Il modello è distribuito in un ambiente isolato o in un servizio controllato, con una parte della gestione assicurata da un fornitore. Il compromesso riduce il carico interno migliorando allo stesso tempo il controllo. Devono essere valutati la portabilità e l’accesso dell’operatore.
4. Infrastruttura privata ospitata
L'organizzazione o il suo gestore IT opera i modelli in un'infrastruttura dedicata. Controlla maggiormente la rete, le versioni, i registri e la crittografia. Deve dimensionare le GPU, gli aggiornamenti, la resilienza e la sicurezza.
5. On-premise
Il calcolo viene effettuato nei locali o in un ambiente completamente controllato. Questa soluzione può rispondere a forti vincoli di connettività o di dati. Richiede un investimento, competenze e un piano di rinnovo. La qualità disponibile dipende dalla capacità hardware e dai modelli distribuibili.
Un routing ibrido indirizza le richieste IA verso diversi ambienti a seconda della sensibilità dei dati.
Un'architettura ibrida è spesso la risposta
Gli usi pubblici o poco sensibili possono utilizzare un'API performante. I contenuti riservati possono essere instradati verso un modello privato. I segreti critici possono rimanere esclusi da qualsiasi trattamento generativo o essere gestiti da una capacità locale molto controllata.
Il routing si basa su:
- classificazione dei dati ;
- identità e ruolo ;
- compito;
- modello autorizzato;
- costo e latenza;
- livello di registrazione;
- meccanismo di ripiegamento.
La politica deve essere applicata lato server. L’utente non sceglie liberamente un fornitore per aggirare le regole.
Confrontare la qualità utile, non il prestigio del modello
Un modello più grande non è sempre migliore per un compito. Bisogna testare sulle lingue, formati e istruzioni reali: estrazione, classificazione, sintesi, codice, RAG o conversazione.
Il gioco di valutazione misura accuratezza, rispetto del formato, rifiuto, latenza e costo. Un'architettura privata può utilizzare un modello specializzato più piccolo se il compito è limitato. Un'API esterna può rimanere necessaria per casi complessi.
Dimensionare l'infrastruttura privata
L'inferenza dipende dalle dimensioni del modello, dalla quantizzazione, dal contesto, dal numero di richieste simultanee e dalla latenza. La velocità media non è sufficiente: i picchi, le code, i tempi di caricamento e la manutenzione devono essere inclusi.
La dimensionamento prevede:
- GPU e memoria;
- ridondanza;
- immagazzinamento dei pesi;
- rete;
- schedulatore ;
- cache ;
- supervisione ;
- aggiornamenti ;
- capacità di ripresa.
Una coda e delle priorità possono assorbire alcune attività asincrone. Le interazioni in tempo reale richiedono una capacità riservata.
Costo completo
Un'API di solito fattura l'uso, a cui si aggiungono integrazione, osservabilità e governance. Un'infrastruttura privata trasforma una parte del costo in investimento o capacità riservata, ma aggiunge gestione, energia, supporto, ammortamento e sotto-utilizzo.
Il costo deve essere calcolato per compito completato e per livello di servizio. Un modello locale economico ma spesso corretto manualmente può essere più costoso di un'API di migliore qualità.
Licenze e modelli aperti
Avere pesi disponibili non significa assenza di condizioni. Bisogna verificare la licenza del modello, le restrizioni d’uso, i componenti, i dati di fine-tuning e la possibilità di ridistribuzione.
L'apertura facilita audit, portabilità e personalizzazione, ma l'organizzazione rimane responsabile della sicurezza, degli aggiornamenti e del comportamento del sistema.
Controlli contrattuali per un'API
La due diligence deve coprire:
- uso degli input e output per l'allenamento ;
- durata di conservazione;
- localizzazione del trattamento ;
- subappaltatori;
- crittografia ;
- accesso al supporto;
- notifica di incidente ;
- disponibilità;
- cambiamento di modello;
- esportazione e cancellazione;
- audit e prove.
Le promesse di marketing non sostituiscono le condizioni applicabili al servizio e al conto utilizzato.
Sicurezza di un'infrastruttura privata
L'auto-ospitazione non rende il sistema sicuro. Bisogna gestire identità, segreti, rete, immagini, dipendenze, modelli, dati temporanei e registri. Le interfacce di amministrazione sono isolate e l'accesso alle GPU è controllato.
I modelli e gli artefatti sono verificati prima del dispiegamento. La catena di approvvigionamento, i download e gli aggiornamenti seguono un processo approvato.
Portabilità
Uno strato di astrazione può normalizzare la chiamata, gli errori, l'osservabilità e le politiche tra fornitori. Non deve mascherare le differenze di capacità al punto da ridurre tutti i modelli al minimo comune denominatore.
Prompt, valutazioni e output strutturati sono versionati. I dati sono archiviati in formati esportabili. Uno scenario di cambiamento viene testato prima che diventi urgente.
Sfruttamento e competenze
Una piattaforma privata richiede MLOps, sicurezza, infrastruttura e supporto. I modelli devono essere aggiornati, valutati, distribuiti gradualmente e monitorati. Gli incidenti possono riguardare qualità, deriva, saturazione o perdita di dati.
L'organizzazione deve decidere cosa gestisce da sola e cosa affida a un partner. La sovranità può includere la capacità di cambiare operatore, non necessariamente di internalizzare tutto.
Una decisione per caso d'uso
La buona scelta combina dati, rischio, qualità, volume e capacità. Un portafoglio di usi può utilizzare diversi ambienti con una politica comune. Questo approccio evita di sovradimensionare le attività semplici o di esporre le più sensibili.
Partitech progetta architetture IA aperte e ibride, integra API e distribuisce modelli privati. L'accompagnamento può coprire classificazione, valutazione, dimensionamento, sicurezza, instradamento e reversibilità al fine di costruire una sovranità verificabile piuttosto che un semplice argomento commerciale.
Parliamo del tuo progetto
Confronta con Partitech le architetture di hosting del tuo progetto IA. Contatta Partitech.