LEAF Advisory · AI confidenziale
AI su un'infrastruttura che controllate voi.
Alcuni carichi di lavoro non possono inviare dati sensibili a servizi AI condivisi di terze parti. LEAF lavora con i vostri team IT e di sicurezza per definire il perimetro, valutare modelli e infrastruttura e progettare AI privata integrata con identità, rete e ambiente operativo esistenti.
L'obiettivo non è isolare tutto. È mantenere i carichi corretti entro il perimetro appropriato, rendendo espliciti i compromessi tra capacità dei modelli, hardware, operatività e governance.
Che cos'è l'AI confidenziale
L'inferenza privata è una scelta di architettura.
L'AI confidenziale è un'architettura AI privata per le organizzazioni che hanno bisogno di un controllo più stretto su dove girano i modelli e dove vengono elaborati i dati. Dati, prompt, output, embedding, cache e log dovrebbero restare entro perimetri definiti deliberatamente dall'organizzazione.
È una capability di Advisory: LEAF affronta la decisione con i vostri team IT e di sicurezza, con il supporto ingegneristico di LEAF Labs dove l'architettura richiede implementazione, integrazione o validazione delle prestazioni.
Il movimento dei dati è definito esplicitamente per ogni carico di lavoro e per ogni architettura.
La decisione riguarda
- Infrastruttura
- Identità
- Rete
- Storage
- Ciclo di vita dei modelli
- Logging
- Governance
Non è
- Un prodotto software
- Un'appliance
- Una certificazione di sicurezza
- Una soluzione di conformità
- Un LLM installato su un server
Si parte dal carico di lavoro
Non tutti i carichi AI hanno bisogno dello stesso perimetro.
Il modello di deployment segue i vincoli di ogni carico di lavoro, non la preferenza per un tipo di infrastruttura.
Sensibilità
Che cosa succede se prompt, documenti o output vengono esposti.
Classificazione dei dati
Quali classi di dati il carico legge, produce e conserva.
Latenza
Quanto velocemente serve una risposta o un'azione nel flusso di lavoro reale.
Connettività
Se l'ambiente è connesso, limitato o isolato.
Requisiti normativi
Obblighi di residenza, conservazione, accesso o di settore che si applicano ai dati.
Capacità del modello
Quanta qualità richiede davvero il compito, misurata su esempi reali.
Numero di utenti
Chi lo usa, quante persone contemporaneamente e con quale frequenza.
Integrazione
Con quale identity provider, quali fonti dati e quali sistemi deve lavorare.
Responsabilità operativa
Chi lo gestirà, aggiornerà e supporterà dopo il pilota.
L'ordine delle decisioni
- Carico di lavoro
- Classificazione dei dati
- Perimetro di fiducia
- Scelta del modello
- Modello di deployment
- Dimensionamento hardware
L'hardware arriva per ultimo: si dimensiona a partire dalle decisioni precedenti.
Architettura del perimetro di fiducia
Prima definisci il perimetro. Poi progetta l'AI al suo interno.
L'architettura deve mostrare che cosa attraversa il perimetro e che cosa no: identità, gateway, modelli, retrieval, strumenti, log e le poche connessioni autorizzate verso l'esterno.
- Flusso interno al perimetro
- Attraversa solo se la policy lo consente
- Flusso non approvato, fermato al perimetro
Può attraversarlo, se consentito
- Richieste non sensibili verso servizi esterni approvati
- Modelli, dipendenze e aggiornamenti approvati, tramite un'importazione controllata
- Avvisi operativi definiti dalle policy
Progettato per restare dentro
- Prompt, documenti e output riservati
- Embedding, indici e cache
- Log e tracce di audit
- Credenziali e permessi degli strumenti
Modelli di deployment
Quattro modi di tracciare il perimetro.
Ogni modello sposta responsabilità, non solo server. Nessuno è più sicuro per definizione: lo decidono i controlli che lo circondano.
On-premises
Modelli e servizi di supporto girano su infrastruttura gestita all'interno dell'ambiente dell'organizzazione e integrata con la sua rete, la sua identità e i suoi processi operativi.
Non è automaticamente più sicuro: hardware, patch e operatività passano ai vostri team o a un partner.
Cloud privato
Un'infrastruttura cloud dedicata può mantenere i carichi in un ambiente e in una regione controllati dall'organizzazione, conservando i modelli operativi del cloud.
Un cloud provider gestisce comunque l'infrastruttura sottostante; il perimetro lo definiscono tenancy, regione, rete e contratto.
Isolato / air-gapped
Ambienti senza connettività esterna, in cui i modelli e tutto ciò da cui dipendono entrano tramite procedure di trasferimento controllate.
Non è semplicemente più sicuro: l'isolamento aggiunge requisiti su
- Importazione dei modelli
- Gestione delle dipendenze
- Aggiornamenti
- Patch di sicurezza
- Dataset di valutazione
- Monitoraggio
- Procedure di trasferimento
Ibrido con perimetri espliciti
I carichi riservati usano modelli privati, mentre i carichi non sensibili consentiti possono usare servizi esterni, con regole esplicite su quali dati possono uscire.
Spesso è l'architettura più realistica, e quella che richiede le regole più chiare.
Ibrido, reso esplicito
La privacy non richiede di trattare tutti i carichi allo stesso modo.
Un'architettura ibrida instrada ogni richiesta in base a regole. I carichi riservati restano su modelli privati dentro il perimetro; i carichi non sensibili possono usare un servizio esterno, dove le sue condizioni sono accettabili per quell'uso.
Le regole di instradamento fanno parte dell'architettura: scritte, riviste con il vostro team di sicurezza e registrate quando vengono applicate. Spesso è una scelta più realistica di un tutto o niente.
Perimetro
I dati non classificati possono seguire per default il percorso più restrittivo.
Confronto tra i modelli di deployment
Compromessi qualitativi, non un punteggio.
Un orientamento per la prima conversazione. La risposta per un carico specifico arriva dalla valutazione.
| Dimensione | On-premises | Cloud privato | Air-gapped | Ibrido |
|---|---|---|---|---|
| Connettività esterna | Stabilita dalla vostra policy di rete | Rete del provider, limitata dalla vostra configurazione | Nessuna; solo trasferimento controllato | Consentita per carico dalle regole di instradamento |
| Carico operativo | Alto: il vostro team o un partner gestisce hardware e stack | Medio: il provider gestisce l'hardware, voi lo stack | Il più alto: ogni modifica passa per una procedura | Da medio ad alto: due percorsi da gestire e governare |
| Flessibilità dei modelli | Modelli ospitabili, limitati dal vostro hardware | Modelli ospitabili, hardware scalabile con il provider | Modelli importati e approvati in anticipo | La più ampia: modelli privati più servizi esterni consentiti |
| Perimetro dei dati | Il vostro ambiente | Vostra tenancy e regione, su infrastruttura del provider | Ambiente isolato | Diverso per carico, stabilito da regole esplicite |
| Complessità degli aggiornamenti | Moderata | Moderata | Alta | Moderata, su due percorsi |
| Uso tipico | Operatività di data center esistente, dati interni sensibili | Modello operativo cloud con esigenze di residenza o tenancy | Ambienti che devono restare disconnessi | Portafogli che mescolano carichi sensibili e non sensibili |
Solo etichette qualitative. Nessun modello di deployment è superiore agli altri in generale.
Il modello segue il compito
Privato non significa scegliere un modello in base al numero di parametri.
I modelli candidati si valutano su ciò che serve al carico di lavoro, poi si mettono alla prova su di esso.
I modelli disponibili per l'hosting privato possono avere capacità diverse dai più grandi modelli cloud proprietari.
I modelli candidati andrebbero valutati sui compiti rappresentativi dell'organizzazione prima di definire hardware e architettura.
Valutati su
- Qualità sul compito
- Lingua
- Lunghezza del contesto
- Latenza
- Concorrenza
- Memoria
- Licenza
- Quantizzazione
- Stack di serving
- Compatibilità hardware
Non solo modelli linguistici
- Linguaggio
- Embedding
- Reranking
- Visione
- Voce
- Modelli per compiti specifici
AI confidenziale non è sinonimo di chatbot privato: ricerca, classificazione, elaborazione documentale e visione possono girare tutte dentro il perimetro.
Dimensionamento hardware
Misurate il carico prima di acquistare l'infrastruttura.
Il dimensionamento combina variabili che si conoscono solo quando carico e modello sono chiari. Le stime generiche di utenti per GPU le nascondono tutte.
- Modello
- Contesto
- Concorrenza
- Latenza obiettivo
- Memoria
- Dimensionamento
Misurato in un pilota con carico rappresentativo, non stimato da una scheda tecnica.
Hardware con cui LEAF ha lavorato nei progetti
Esempi dell'ampiezza, non hardware raccomandato per l'AI confidenziale. Ogni progetto si dimensiona sul proprio carico.
Compatto ed edge
Raspberry Pi 5 + acceleratore Hailo
Inferenza su immagini e video direttamente sul dispositivo, mantenendo i dati visivi in sede.
Team e reparto
NVIDIA DGX Spark (GB10)
Inferenza privata, retrieval e adattamento dei modelli per un team.
Data center
Server NVIDIA con due GPU H200
Modelli più grandi, più utenti contemporanei e carichi documentali più pesanti.
Sicurezza e governance
Anche l'infrastruttura privata ha bisogno dell'identità.
Eseguire i modelli in privato cambia dove vivono i controlli, non il fatto che servano. Sei aree si affrontano con i vostri team di sicurezza e IT.
Identità e accessi
Chi può usare quale modello, per quale caso d'uso e su quali fonti dati, tramite il vostro identity provider esistente.
Tracciabilità
Richieste, azioni amministrative e modifiche ai modelli registrate e conservate secondo la vostra policy.
Residenza dei dati
Un inventario di dove i dati vengono conservati ed elaborati, non solo di dove gira il modello.
Sicurezza di rete e del serving
Segmentazione, cifratura, gestione dei segreti e hardening degli endpoint di serving.
Filiera dei modelli
Fonti verificate, revisione delle licenze, tracciamento delle versioni e un percorso controllato per nuovi modelli e aggiornamenti.
Governance aziendale
Un inventario di casi d'uso AI, responsabili e approvazioni coerente con i processi di rischio e di change esistenti.
L'identità comprende
- Il vostro identity provider esistente
- Ruoli e gruppi
- Identità di servizio
- Permessi per caso d'uso
- Permessi per fonte dati
- Privilegi amministrativi
I permessi si mappano e si verificano fonte per fonte. Non si presume una propagazione automatica su ogni sistema.
Dove stanno i dati
- Prompt
- Output
- Documenti
- Embedding
- Indici vettoriali
- Cache
- Log
- Backup
- File temporanei
- Pesi dei modelli
Dove gira il modello è solo una parte della residenza dei dati.
Che cosa è osservabile
- Richieste
- Azioni amministrative
- Chiamate agli strumenti, dove rilevanti
- Modello e versione
- Modifiche al deployment
- Errori
- Metadati di utilizzo
I log registrano eventi osservabili, non il ragionamento nascosto di un modello. La conservazione segue la vostra policy.
La conformità resta dell'organizzazione
Eseguire l'AI sulla vostra infrastruttura non rende l'organizzazione conforme.
LEAF non presenta l'AI confidenziale come titolare di certificazioni di sicurezza o di conformità.
Le architetture possono essere progettate per supportare requisiti derivanti da obblighi di protezione dei dati, sicurezza, residenza o di settore. La conformità viene valutata dall'organizzazione e dai suoi auditor su processi, persone e controlli.
Progettare per le minacce che contano
“Privato” non è un modello delle minacce.
Il deployment privato elimina alcuni rischi e ne lascia altri. Quelli rilevanti si valutano per ogni architettura.
Esempi di rischi da valutare, non una checklist completa di security assessment.
Accessi non autorizzati
Utenti o servizi che raggiungono modelli e dati che non dovrebbero raggiungere.
Esfiltrazione dei dati
Contenuti sensibili che escono tramite output, log, strumenti o integrazioni.
Credenziali compromesse
Account o chiavi sottratti e usati contro il gateway o le fonti dati.
Filiera di modelli e dipendenze
Pesi, immagini o librerie manomessi che entrano nell'ambiente.
Endpoint di serving esposti
API di inferenza raggiungibili da reti che non dovrebbero raggiungerle.
Permessi impropri sugli strumenti
Modelli o agenti autorizzati ad agire oltre quanto richiede il caso d'uso.
Flussi di dati non approvati
Connessioni verso servizi esterni che nessuno ha deciso di consentire.
Filiera dei modelli
Anche un modello che gira in locale deve essere affidabile.
I pesi aperti si possono ispezionare e ospitare, ma l'esecuzione in locale non rende affidabili per definizione un modello, le sue dipendenze o la sua immagine di serving.
- Fonte del modello
- Licenza
- Pesi
- Dipendenze
- Immagine di serving
- Versione
- Checksum / firme dove appropriato
- Approvazione
- Procedura di aggiornamento
- Rollback
Ogni nuovo modello o aggiornamento segue lo stesso percorso, anche negli ambienti air-gapped.
Come lavoriamo
Scout. Connect. Unlock.
Il metodo LEAF, applicato con i vostri team IT, di sicurezza e di compliance.
01/ Scout
Mappare il perimetro
Mappare carichi di lavoro, classificazione dei dati, requisiti, modello delle minacce e infrastruttura esistente.
02/ Connect
Co-progettare e validare
Co-progettare l'architettura e validare le scelte di modello e hardware con un pilota delimitato.
03/ Unlock
Gestire e adottare
Integrare procedure operative, monitoraggio e adozione nell'ambiente dell'organizzazione.
L'AI confidenziale è una capability di Advisory. LEAF Labs fornisce supporto ingegneristico dove l'architettura richiede implementazione, integrazione o validazione delle prestazioni.
Dove serve, LEAF Academy supporta operatori, amministratori, utenti e team di governance. Non tutti i progetti di AI confidenziale includono formazione.
Le responsabilità si concordano per progetto
Ogni area ha un responsabile prima della fine del pilota. Non esiste un'assegnazione universale.
Aree
- Architettura
- Ciclo di vita dei modelli
- Infrastruttura
- Identità
- Operazioni di sicurezza
- Aggiornamenti
- Monitoraggio
- Supporto applicativo
Ognuna è in capo a
- Cliente
- LEAF
- Partner del cliente
- Condivisa
Validare prima di standardizzare
Anche un modello privato deve saper svolgere il compito.
Ogni carico si misura su compiti e volumi rappresentativi prima che l'architettura diventi uno standard.
Qualità di risposte e compiti
Risultati corretti e utili sugli esempi dell'organizzazione.
Qualità del retrieval
Dove si usa il retrieval, i passaggi giusti trovati e ordinati.
Latenza
Tempo di risposta nelle condizioni del flusso di lavoro reale.
Throughput
Richieste o documenti elaborati in un certo periodo.
Memoria
Occupazione di modello, contesto e cache sull'hardware di destinazione.
Concorrenza
Comportamento con il numero previsto di utenti contemporanei.
Rifiuti e gestione degli errori
Che cosa succede con richieste fuori ambito, senza risposta o malformate.
Integrazione
Identità, fonti dati e strumenti che funzionano da un capo all'altro.
Stabilità operativa
Riavvii, aggiornamenti e monitoraggio che si comportano come previsto.
Compromessi resi visibili
- Qualità
- Latenza
- Costo dell'hardware
- Complessità operativa
- Scelta del modello
- Frequenza degli aggiornamenti
Un'architettura privata non è in assoluto migliore di un'API pubblica. Scambia alcuni di questi fattori con il controllo, e lo scambio deve valerne la pena.
Il costo dipende da volume dei carichi, utilizzo dell'hardware, scelta del modello, operatività e servizi esterni con cui si confronta.
Dove si applica
Dove un perimetro privato è spesso giustificato.
Conoscenza aziendale sensibile
Documenti interni, contratti, ricerca o progetti che non dovrebbero essere elaborati da servizi condivisi.
Dati regolamentati o con vincoli di residenza
Carichi in cui protezione dei dati, residenza o obblighi di settore determinano dove può avvenire l'elaborazione.
Ambienti operativi isolati
Stabilimenti, laboratori o reti limitati o disconnessi per progetto.
RAG privato e assistenti aziendali
Retrieval e assistenti sulla conoscenza interna, dentro lo stesso perimetro.
Carichi che richiedono più controllo sull'infrastruttura
Casi in cui l'organizzazione deve decidere da sé modelli, versioni, log e tempi degli aggiornamenti.
Schemi illustrativi, non un elenco di progetti realizzati.
Quando può non servire
Il deployment privato non è sempre l'architettura migliore.
Parte della valutazione consiste nel dirlo, quando un perimetro privato non è giustificato.
Sperimentazione a basso volume
L'esplorazione iniziale raramente giustifica un'infrastruttura dedicata.
Già accettabile alle condizioni del provider
Se le condizioni di un provider esterno soddisfano i requisiti per quei dati, uno stack privato può aggiungere costi senza aggiungere un controllo rilevante.
Servono capacità proprietarie di frontiera
Alcuni compiti richiedono capacità che i modelli ospitabili in privato non raggiungono ancora.
Capacità operativa insufficiente
Senza persone che lo gestiscano, lo aggiornino e lo monitorino, uno stack privato diventa un rischio a sé.
Investimento hardware non giustificato
L'utilizzo può essere troppo basso o troppo incerto per giustificare l'acquisto.
Limiti espliciti
Che cosa l'AI privata non risolve da sola.
L'obiettivo è un'architettura controllata, non il massimo isolamento.
- Il deployment privato non garantisce la conformità.
- Il deployment privato non rende automaticamente sicuro un sistema.
- I modelli ospitati in proprio possono avere prestazioni inferiori alle migliori alternative proprietarie.
- L'organizzazione si assume più responsabilità sul ciclo di vita e sull'infrastruttura.
- Gli ambienti air-gapped complicano aggiornamenti e monitoraggio.
- Un dimensionamento hardware basato solo su stime non è affidabile.
- L'hosting locale non corregge permessi applicativi o governance carenti.
Parti dal perimetro
Quali dati e carichi di lavoro devono rimanere sotto il vostro controllo?
Mostrateci il carico di lavoro, i dati che utilizza, i sistemi circostanti e i vincoli che i vostri team devono rispettare. Possiamo valutare se l'AI privata è giustificata e quale architettura conviene validare per prima.