RAG on-premise sicuro nel 2026: la guida completa agli accessi

Quasi tutti i progetti di AI aziendale nascono in cloud. In un numero crescente di organizzazioni regolamentate è esattamente lì che si fermano. Basta che il legale analizzi i flussi di dati, o che la compliance mappi dove finiscono le query, e il progetto incontra un muro: i documenti riservati non possono uscire dal perimetro. La pressione non è teorica. Il Verizon Data Breach Investigations Report 2026 registra una crescita del 60% in un anno delle violazioni che coinvolgono una terza parte, ormai il 48% del totale: ogni dipendenza da un fornitore esterno di elaborazione è un’esposizione documentata, non un’ipotesi di scuola.

Il RAG aziendale on-premise risponde a questo problema tenendo dentro infrastrutture che l’azienda controlla sia la ricerca dei frammenti di documento pertinenti (retrieval) sia la loro lettura da parte del modello che scrive la risposta (inferenza). Questa guida spiega a CISO, responsabili sicurezza IT e compliance manager come progettare un’installazione sicura con segregazione dei dati per reparto e isolamento della knowledge base: architettura, modelli di permessi, mappatura normativa e i passaggi operativi che tengono i dati dove devono stare. Per il livello infrastrutturale sottostante il riferimento è la guida tecnica al RAG aziendale on-premise per i team IT.

Key takeaways: RAG aziendale on-premise sicuro

• Il RAG on-premise tiene recupero, inferenza e log di audit dentro il perimetro di rete, eliminando dall’architettura l’esposizione verso terze parti.
• Il controllo degli accessi per reparto impedisce la fuga di dati tra divisioni applicando i permessi al momento del recupero, non dopo la generazione della risposta.
• L’isolamento della knowledge base mantiene segregati i documenti di ciascuna business unit dentro il vector store e la pipeline di retrieval, non soltanto a livello di query.
• AIGrant, l’estensione di AI privata di FileGrant, la piattaforma file-centric di CyberGrant, offre document intelligence con RBAC applicato senza inviare alcun file a modelli linguistici pubblici.
• GDPR, NIS2, DORA e AI Act si mappano con precisione sul RAG on-premise quando audit trail e cifratura sono progettati dal primo giorno, non aggiunti dopo.
  
  

Che cos’è il RAG aziendale on-premise?

Il Retrieval-Augmented Generation (RAG) ancora le risposte di un modello linguistico ai documenti dell’azienda invece che alla sua conoscenza generale. Al momento della query il modello recupera i frammenti rilevanti da una knowledge base interna e genera una risposta citata a partire da quel contesto.

In un’installazione on-premise ogni componente della pipeline resta dentro la rete aziendale. Motore di embedding, vector store, livello di retrieval, reranker e modello di inferenza girano su hardware di proprietà o in locazione all’interno del data center. Nessuna query, nessun frammento di documento, nessuna risposta generata attraversa il perimetro.

La differenza conta perché il RAG in cloud invia contenuti interni all’infrastruttura di un fornitore a ogni interrogazione. Per chi tratta atti coperti da segreto professionale, materiale classificato o dossier clinici, quel flusso è un rischio che non si può accettare.

Perché le organizzazioni regolamentate hanno bisogno del RAG on-premise?

Quattro scenari rendono l’on-premise un requisito e non una preferenza. Se ne vale anche uno solo, il RAG in cloud esce dal tavolo prima ancora della valutazione tecnica.

Atti riservati e segreto professionale. Il segreto professionale dipende dalla catena di custodia. Far transitare materiale coperto attraverso un responsabile del trattamento esterno introduce un rischio di decadenza che nessun ufficio legale prudente accetta.

Residenza del dato vincolata. Il GDPR ammette alcuni trasferimenti internazionali, ma le autorità di controllo di Germania, Francia e Svizzera si sono espresse in modo esplicito: i dati devono restare entro i confini nazionali o dell’Unione. Un’installazione on-premise in un data center locale è la strada più lineare.

Materiale classificato o soggetto a controllo sull’export. Pubblica amministrazione e difesa che lavorano su contenuti classificati o su dati tecnici soggetti a ITAR non possono usare servizi cloud commerciali. L’installazione vive dentro un ambiente controllato.

Policy interne precedenti all’AI. Molte grandi aziende hanno politiche di trattamento che vietano qualsiasi elaborazione di contenuti dei clienti da parte di terzi. Aggiornarle richiede mesi. L’on-premise aggira il problema perché nulla esce dall’edificio.

Il volume della minaccia dietro questi quattro scenari continua a salire. Il Rapporto Clusit 03-2026 ha contato 5.265 incidenti gravi a livello globale nel 2025, con una crescita del 48,7% su base annua, la più alta mai registrata, e del 42% in Italia. Policy scritte per uno scenario più lento vengono messe alla prova da uno scenario più rapido.

Come funziona l’architettura di un RAG on-premise?

Uno stack RAG on-premise ben costruito ha la stessa forma architetturale di un’installazione cloud, con una differenza che governa tutto il resto: ogni componente gira dentro il perimetro. La pipeline attraversa cinque stadi.

Ingestione dei documenti ed embedding

I documenti interni vengono suddivisi in frammenti logici. Ogni frammento viene convertito in una rappresentazione numerica (embedding) da un modello di vettorizzazione eseguito su GPU locali. Gli embedding finiscono in un vector database self-hosted come pgvector, Weaviate o Qdrant.

Durante l’ingestione ogni frammento viene etichettato con i permessi di origine: reparto proprietario, classificazione di sicurezza e lista di controllo accessi ereditata dal sistema sorgente. Sono questi metadati a rendere possibile, più avanti, un retrieval consapevole dei permessi.

Retrieval ibrido e reranking

Quando un utente invia una query, il sistema la converte in vettore e cerca nel database le corrispondenze semantiche più vicine. I sistemi in produzione combinano la ricerca vettoriale densa con la ricerca per parole chiave sparse (BM25), che garantisce precisione su termini esatti come numeri di contratto o codici tecnici.

Un reranker cross-encoder, sullo stesso pool di GPU locali, assegna un punteggio di rilevanza ai risultati combinati. Un dettaglio decide se l’intero impianto regge: i filtri sui permessi vanno applicati prima che il reranker assegni qualsiasi punteggio. Se i filtri intervengono dopo, documenti non autorizzati con punteggio alto occupano i primi posti e lasciano la finestra di contesto senza materiale legittimo.

Inferenza e generazione in locale

I frammenti filtrati e riordinati passano a un modello linguistico ospitato in locale. Modelli a pesi aperti come Llama, Mistral o Qwen girano su infrastruttura GPU aziendale. Nessuna chiamata di inferenza lascia il perimetro. Il modello produce una risposta citata, fondata esclusivamente sul contesto recuperato.

Autovalutazione post-generazione

Un secondo modello locale valuta la risposta generata rispetto alle fonti recuperate. Questo passaggio intercetta allucinazioni e affermazioni non supportate prima che la risposta arrivi all’utente. Eseguire in locale anche il modello giudice significa che nemmeno la valutazione esce dal perimetro.

Log di audit immutabile

Ogni query, ogni risultato di retrieval con il relativo punteggio, ogni verdetto di autovalutazione e ogni risposta generata con le sue citazioni vengono registrati. Per il lavoro regolamentato il log deve essere append-only, con garanzie crittografiche di integrità. Un audit trail completo a livello di protezione del file è ciò che rende il sistema difendibile se un output viene contestato.

Che cos’è il controllo degli accessi per reparto in un RAG?

Il controllo degli accessi per reparto garantisce che una query proveniente da una divisione non faccia mai emergere documenti di un’altra, salvo permessi incrociati espliciti. Non è una funzione da aggiungere in seguito: è una decisione architetturale che condiziona ogni livello della pipeline.

Il problema è lineare: la ricerca per similarità vettoriale ordina i documenti per rilevanza, non per autorizzazione. Una query su “retribuzione dei dipendenti” può restituire documenti semanticamente vicini su bonus dirigenziali, trattative salariali o compensi a collaboratori esterni, attraversando più domini di sicurezza. Senza controllo degli accessi applicato al momento del recupero, il sistema RAG diventa un motore di divulgazione.

La soluzione richiede tre cose: etichettare ogni frammento con reparto e metadati di sicurezza già in ingestione, risolvere identità e appartenenze a gruppo dell’utente prima che parta il retrieval, filtrare la ricerca vettoriale in base a quell’identità, così che i frammenti non autorizzati non entrino mai nella finestra di contesto.

Come si implementa il controllo degli accessi per reparto?

Esistono tre modelli architetturali per imporre l’isolamento per reparto su un’infrastruttura RAG condivisa. Ciascuno porta con sé compromessi diversi su sicurezza, prestazioni e complessità operativa.

Separazione fisica: un database per reparto

Ogni reparto riceve la propria istanza di vector database, la propria pipeline di embedding e la propria infrastruttura di retrieval. Questo modello elimina ogni possibilità di contaminazione tra divisioni e offre le garanzie di conformità più solide.

Il prezzo è il carico operativo: più cluster di database, più sistemi di backup, più pipeline di monitoraggio da gestire. Se i reparti hanno volumi di utilizzo disomogenei, l’efficienza delle risorse cala. Il modello si adatta alle organizzazioni dove l’isolamento duro non è negoziabile, per esempio una divisione sanitaria che tratta dati clinici accanto a un team finance che gestisce documenti di M&A.

Separazione logica: database condiviso con filtri sui metadati

Tutti i reparti condividono lo stesso vector database, ma ogni frammento porta con sé i metadati che ne identificano reparto, livello di sicurezza e lista di controllo accessi. Al momento della query i filtri sui permessi restringono lo spazio di ricerca ai soli frammenti che l’utente è autorizzato a vedere.

È il modello più diffuso in produzione perché bilancia sicurezza ed efficienza. Il rischio è che un singolo errore nella logica di filtro esponga dati tra reparti. La difesa in profondità diventa obbligatoria: il filtro va applicato sia a livello applicativo sia a livello di database, così che un bug in uno dei due non possa aggirare l’altro.

Architettura ibrida: fisica per i dati sensibili, logica per il resto

Molti sistemi in produzione combinano i due modelli. I reparti ad alta sensibilità (legale, risorse umane, direzione) ricevono istanze isolate fisicamente, gli altri condividono un’infrastruttura separata su base logica. Isolamento duro dove la posta in gioco è più alta, efficienza di costo ovunque altrove.

Come l’isolamento della knowledge base tiene i documenti segregati?

L’isolamento della knowledge base va oltre il controllo degli accessi in fase di query. Tiene i documenti di reparti e business unit diversi separati lungo tutta la pipeline, dall’ingestione all’embedding, dallo storage al retrieval.

Perché i filtri sugli accessi non bastano

I filtri applicati alla query sono necessari ma non sufficienti. Senza isolamento ai livelli di storage e indicizzazione restano aperti diversi rischi. Un modello di embedding addestrato o messo a punto sul corpus di un reparto può codificare schemi provenienti da un altro. Indici vettoriali condivisi possono far trapelare informazioni attraverso attacchi temporali o pattern nei set di risultati. Risultati in cache indicizzati soltanto sull’embedding della query, senza incorporare i permessi dell’utente, possono servire la risposta di un utente a un altro.

Isolamento a livello di storage

Un isolamento efficace richiede collezioni o namespace vettoriali separati per ciascun reparto all’interno del database. Richiede inoltre pipeline di embedding con ambito di reparto, così che il contenuto di una divisione non influenzi mai la vettorizzazione di un’altra. Le chiavi di cache devono combinare il vettore della query con l’hash dei permessi dell’utente: qualsiasi cache semantica che ignora i permessi è un canale di fuga in attesa di essere sfruttato.

Sincronizzazione dei permessi e prevenzione del drift

Il buco di sicurezza più frequente nei RAG in produzione è il permission drift: l’accesso di un utente viene revocato nel sistema sorgente alle 9:05, ma la ACL del vector database si aggiorna durante un batch notturno, lasciando una finestra di esposizione di quindici ore. La propagazione dei permessi guidata dagli eventi chiude il varco: il sistema si sottoscrive agli eventi di modifica in tempo reale dei sistemi sorgente e spinge aggiornamenti mirati dei metadati nel vector store in pochi minuti. È lo stesso meccanismo per cui la classificazione manuale dei documenti fallisce: la governance scritta su carta non regge la velocità con cui cambiano i permessi reali.

Pre-filtering o post-filtering: dove applicare i permessi?

Il punto della pipeline in cui si impone il controllo degli accessi ha conseguenze concrete su sicurezza e qualità della ricerca. Due strategie si contendono il campo, e la scelta dipende dalla sensibilità del dato.

Pre-filtering: permessi prima della ricerca

Il pre-filtering restringe il vector database ai soli frammenti che l’utente può vedere, poi esegue la ricerca semantica dentro quel sottoinsieme. È il confine di sicurezza più solido: la query dell’utente non entra mai in contatto con contenuti non autorizzati.

Il compromesso riguarda le prestazioni. Strutture di indice basate su grafo come HNSW possono restare intrappolate in sottografi isolati quando il sottoinsieme autorizzato è piccolo, con il rischio di perdere risultati rilevanti. Serve un lavoro attento di ottimizzazione dell’indice per tenere insieme confine di sicurezza e recall semantico.

Post-filtering: prima la ricerca, poi il filtro

Il post-filtering esegue la ricerca semantica sull’intero database e poi rimuove ciò che l’utente non può vedere. È più semplice da implementare e preserva la massima rilevanza.

Il rischio è che restituisca silenziosamente meno risultati di quelli richiesti. Se otto dei primi dieci risultati sono documenti non autorizzati, all’utente ne arrivano due e il modello genera da una finestra di contesto impoverita. Per le categorie di dati ad alta sensibilità questo compromesso non è accettabile.

Quale approccio scegliere

Pre-filtering per i dati con confini di riservatezza netti: legale, risorse umane, M&A, comunicazioni della direzione. Post-filtering per contenuti a sensibilità più bassa e volume alto, dove la rilevanza conta più del confine rigido. Il post-filtering va comunque accompagnato da logging, così che anche i risultati scartati restino verificabili. Molte installazioni usano entrambi nello stesso sistema, instradando in base alla classificazione del dato.

Come AIGrant realizza un RAG privato on-premise

AIGrant è l’estensione di AI privata di FileGrant, la piattaforma file-centric di CyberGrant, che permette ai dipendenti di interrogare, classificare e cercare i documenti aziendali senza esporre un solo file a modelli linguistici pubblici.

AIGrant rispetta i permessi RBAC a ogni passaggio: ciascun dipendente raggiunge soltanto i file che è autorizzato a vedere. L’AI indicizza automaticamente ogni documento caricato, suggerisce classificazione e permessi in base al contenuto e risponde alle domande in linguaggio naturale, sempre all’interno dell’ambiente cifrato. I dati non lasciano la piattaforma. Nessun documento viene inviato a modelli esterni, né per l’addestramento né per l’inferenza.

Per le organizzazioni che hanno bisogno di protezione del dato file-centric accanto alla document intelligence, AIGrant unisce il retrieval-augmented generation alla cifratura quantum-safe di CyberGrant, al controllo granulare degli accessi e a un audit trail completo. Il livello crittografico usa CRYSTALS-Kyber, standardizzato dal NIST come FIPS 203 (ML-KEM) nell’agosto 2024, che risponde alla logica harvest now, decrypt later sui documenti il cui valore dura un decennio. Il risultato è un assistente che conosce i documenti dell’azienda e trova esattamente quello che serve, con ogni interazione tracciabile e ogni file cifrato. AIGrant estende FileGrant al canale AI: si affianca agli assistenti già in uso e copre ciò che quelli lasciano scoperto.

Come si mappano GDPR, NIS2, DORA e AI Act sul RAG on-premise?

Ogni quadro normativo fa leva su aspetti diversi. L’architettura on-premise semplifica tutti i casi perché rimuove intere categorie di rischio legato a terze parti.

GDPR e residenza del dato

Il RAG on-premise mantiene il trattamento dentro la propria giurisdizione. Le questioni di trasferimento si evitano in larga parte perché i documenti non attraversano confini. I diritti dell’interessato, accesso e cancellazione compresi, diventano più semplici da gestire quando si controlla direttamente l’indice. Il principio di minimizzazione del Regolamento UE 2016/679 risulta soddisfatto per costruzione quando il retrieval basato sui ruoli mostra a ciascun dipendente solo ciò che il suo ruolo consente, e l’articolo 32 considera già cifratura e log misure adeguate.

NIS2 e resilienza operativa

La direttiva NIS2, recepita in Italia con il D.Lgs. 138/2024, impone a soggetti essenziali e importanti misure di gestione del rischio che comprendono sicurezza della supply chain e notifica degli incidenti, con le misure operative attese entro ottobre 2026. Il RAG on-premise toglie il fornitore di AI dalla catena di fornitura. La resilienza migliora perché il sistema gira su infrastruttura che l’organizzazione già governa. Secondo NIST SP 1800-35, pubblicata nel giugno 2025, le architetture zero trust che tengono il dato dentro perimetri controllati si allineano ai principi di sicurezza che NIS2 codifica. Il dettaglio delle scadenze è nell’analisi su cosa deve essere operativo entro il 31 ottobre 2026.

DORA e servizi finanziari

Il Regolamento UE 2022/2554, applicabile dal 17 gennaio 2025, obbliga le entità finanziarie a gestire il rischio ICT derivante da terze parti. L’installazione on-premise elimina un’intera categoria di rischio di terze parti nella protezione dei dati bancari rimuovendo la dipendenza da elaborazione AI esterna. I requisiti di resilienza si applicano allora alla propria infrastruttura, già governata dai framework esistenti.

AI Act e tracciabilità

Il Regolamento UE 2024/1689 richiede tracciabilità e sorveglianza umana per i sistemi di AI ad alto rischio. Un RAG on-premise con logging completo è una delle vie più dirette per soddisfare questi requisiti: ogni query, ogni fonte recuperata e ogni risposta generata restano registrate sotto il controllo dell’azienda, senza dipendenze esterne nella catena decisionale.

Come si realizza un RAG on-premise sicuro, passo per passo

Realizzare un RAG on-premise è un progetto infrastrutturale con la sicurezza costruita dentro ogni livello. Cinque passaggi coprono le decisioni che contano, dalla pianificazione alla produzione.

Passo 1: definire la fonte di verità delle autorizzazioni

Prima che un documento raggiunga la pipeline vettoriale, va stabilito chi può vederlo. Le politiche di autorizzazione vanno mappate in modo esplicito: quali utenti, gruppi, ruoli o attributi danno accesso a quali classi di documenti. La pipeline RAG deve applicare decisioni di autorizzazione già prese altrove, non inventarle implicitamente durante l’indicizzazione.

Passo 2: scegliere e configurare l’infrastruttura

Serve hardware GPU capace di eseguire sia il modello di inferenza sia il reranker, un vector database self-hosted, un isolamento di rete che impedisca a qualsiasi componente l’accesso in uscita verso internet, e storage per il log di audit con scritture append-only firmate crittograficamente.

Passo 3: costruire l’ingestione con etichettatura delle ACL

Collegare i sistemi sorgente e importare i documenti con i loro metadati di controllo accessi intatti. Ogni frammento deve portare reparto, classificazione di sicurezza e ACL del sistema di origine. La sottoscrizione agli eventi di modifica in tempo reale fa sì che le revoche si propaghino al vector store in minuti, non in ore.

Passo 4: implementare un retrieval consapevole dei permessi

Il livello di retrieval va collegato alla directory aziendale (Active Directory, Okta o equivalente) tramite SAML o OAuth per risolvere l’identità di chi interroga. I filtri sui metadati vanno iniettati come obbligatori in ogni query vettoriale prima che raggiunga il database. L’isolamento tra reparti va testato con rigore: una query del reparto A non deve mai restituire frammenti etichettati come reparto B, salvo politiche di condivisione esplicite.

Passo 5: validare, monitorare, correggere

Esercizi di red team che simulano la fuga di dati tra reparti. Monitoraggio del permission drift confrontando periodicamente le ACL dei sistemi sorgente con i metadati del vector store. Tracciamento delle metriche di qualità del retrieval: rilevanza del contesto, fondatezza fattuale, tasso di mancata risposta. Un tasso di mancata risposta in calo insieme a punteggi di rilevanza in crescita conferma che il sistema sta funzionando come previsto.

Quali sono gli errori più frequenti nei progetti di RAG on-premise?

Quasi tutti i fallimenti di sicurezza nei RAG aziendali si riconducono a un gruppo ristretto di errori ricorrenti. Riconoscerli presto fa risparmiare mesi di rimedio.

Trattare la knowledge base come un blocco unico. Indicizzare tutto in un unico vector store indifferenziato, senza metadati di classificazione o proprietà, rende impossibile aggiungere il controllo accessi in un secondo momento. Le ACL si etichettano in ingestione, non dopo.

Scegliere il post-filtering per inerzia. Il post-filtering è la strada di minore sforzo implementativo, non la postura di sicurezza giusta per i contenuti sensibili. Il compromesso va valutato in modo esplicito e per i dati ad alta sensibilità si usa il pre-filtering.

Lasciar accumulare il permission drift. Le modifiche di accesso nei sistemi sorgente che non si propagano all’indice vettoriale creano finestre di esposizione. La sincronizzazione dei permessi va trattata come una pipeline di prima classe, monitorata.

Rimandare il log di audit. Aggiungere il logging dopo il go-live significa perdere mesi di evidenze irrecuperabili. Il log nasce con la versione uno. FileGrant Enterprise costruisce audit trail completi e RBAC granulare direttamente nel livello di protezione del file, la stessa base probatoria che i regolatori si aspettano dentro un sistema di gestione integrato NIS2 e GDPR.

Mettere in cache senza contesto di permessi. Le cache semantiche indicizzate solo sugli embedding delle query sono un canale di fuga. Ogni chiave di cache deve combinare il vettore della query con i gruppi di permessi verificati dell’utente.

In cosa un RAG privato on-premise è diverso dalle alternative cloud

Le piattaforme di collaborazione in cloud offrono funzionalità simili al RAG, legate ai rispettivi ecosistemi. Il limite è architetturale: recupero e inferenza girano sull’infrastruttura del fornitore, quindi i documenti escono dal perimetro a ogni query. Un documento cifrato dentro la rete aziendale si espone nel momento stesso in cui entra in una pipeline di retrieval esterna. È anche la crepa da cui la shadow AI trasforma una policy di governance in un esercizio sulla carta: se lo strumento autorizzato non può leggere i file riservati, qualcuno li incolla dove invece si possono leggere.

Il RAG privato on-premise chiude il varco tenendo ogni passaggio di elaborazione, dall’embedding alla generazione, dentro un ambiente controllato. I documenti non vengono soltanto recuperati in sicurezza: sono cifrati con crittografia quantum-safe (CRYSTALS-Kyber, NIST FIPS 203), protetti da gestione delle chiavi a conoscenza zero e coperti da un audit trail immutabile. I dati non lasciano la piattaforma e le chiavi di cifratura non lasciano l’organizzazione.

La stessa logica vale per i documenti che vivono già in Microsoft 365. Connector di CyberGrant porta la cifratura di FileGrant dentro SharePoint e OneDrive senza migrazione: i file restano dove sono, gli utenti mantengono il login Microsoft e i documenti cifrati restano illeggibili per qualsiasi AI che indicizzi il tenant, Copilot compreso. Connector non sostituisce SharePoint, OneDrive o Purview: copre la cifratura file-centric che quei livelli lasciano fuori.

Cosa chiederà di dimostrare un auditor

Un RAG on-premise sicuro non è un esperimento tecnologico. È una decisione infrastrutturale dettata dalla realtà normativa e dai requisiti di sovranità del dato. L’architettura in sé è conosciuta: retrieval, reranking, generazione e logging, tutto dentro il perimetro.

La parte difficile è il livello dei permessi. Controllo degli accessi per reparto e isolamento della knowledge base separano un’installazione conforme da una responsabilità legale. La fonte di verità delle autorizzazioni va definita prima di indicizzare il primo documento. I permessi si applicano al momento del recupero, non dopo la generazione. Il drift si monitora. Tutto si registra.

AIGrant dà alle organizzazioni regolamentate un percorso già pronto verso una document intelligence privata e consapevole dei permessi, con cifratura quantum-safe e tracciabilità completa dentro ogni interazione. La domanda aperta non è più se il RAG on-premise sia fattibile. È se l’installazione AI che avete oggi sia in grado di produrre, su richiesta, il log che dimostra chi ha chiesto cosa e quali documenti hanno risposto.

FAQ sul RAG aziendale on-premise sicuro

Che cos’è il RAG aziendale on-premise?

Il RAG aziendale on-premise è un’architettura di retrieval-augmented generation in cui ogni componente, dall’ingestione dei documenti allo storage vettoriale fino all’inferenza e al log di audit, gira dentro la rete dell’organizzazione. Nessun dato esce dal perimetro aziendale.

Perché il RAG on-premise conta per i settori regolamentati?

I settori regolamentati trattano dati coperti da segreto, classificati o vincolati alla residenza, che non possono essere elaborati da fornitori esterni. Il RAG on-premise tiene recupero e generazione dentro infrastrutture controllate, elimina l’esposizione verso terze parti e semplifica la conformità a GDPR, NIS2, DORA e AI Act.

Come applica AIGrant il controllo degli accessi per reparto?

AIGrant, l’estensione di AI privata di FileGrant di CyberGrant, rispetta i permessi RBAC in ogni passaggio della pipeline di retrieval. Ciascun dipendente raggiunge solo i file che è autorizzato a vedere. AIGrant indicizza i documenti in automatico, applica la classificazione in base al contenuto e risponde usando soltanto i frammenti compatibili con i permessi verificati dell’utente.

Qual è la differenza tra pre-filtering e post-filtering in un RAG?

Il pre-filtering restringe la ricerca vettoriale ai documenti autorizzati prima che il retrieval parta, e offre un confine di sicurezza più solido. Il post-filtering cerca prima su tutto il database e rimuove dopo i risultati non autorizzati. Il pre-filtering è consigliato per i dati sensibili, il post-filtering funziona su contenuti a sensibilità più bassa e volume alto.

Un RAG on-premise può usare gli stessi modelli di un RAG in cloud?

Le installazioni on-premise usano di norma modelli a pesi aperti come Llama, Mistral o Qwen al posto delle API commerciali ospitate. L’architettura è identica, cambia solo la scelta del modello. La qualità dei modelli a pesi aperti ha raggiunto il livello di produzione per la maggior parte dei compiti documentali aziendali.

Come impedisce l’isolamento della knowledge base la fuga di dati tra reparti?

L’isolamento della knowledge base separa i documenti ai livelli di storage e indicizzazione, non soltanto al momento della query. Collezioni vettoriali distinte per reparto, pipeline di embedding con ambito di reparto e chiavi di cache che incorporano i permessi garantiscono che il contenuto di una divisione non influenzi né compaia nelle query di un’altra.

Un RAG privato on-premise sostituisce Microsoft Copilot?

No. Un RAG privato on-premise si affianca a Microsoft Copilot e copre i documenti che Copilot non dovrebbe elaborare, come atti coperti da segreto professionale, materiale di M&A o dossier clinici. AIGrant risponde su quei file dentro l’ambiente cifrato, mentre Connector di CyberGrant mantiene gli stessi documenti cifrati dentro SharePoint e OneDrive senza migrazione, così da renderli illeggibili a qualsiasi AI esterna.