L'AI che risponde sul tuo archivio

Per dare all’AI accesso al tuo archivio non devi addestrare nulla. E la macchina giusta non è quella che immagini.

C’è un momento preciso in cui nasce questo progetto. Qualcuno — il titolare, la direzione, un socio — ti dice: “di questa cosa dell’AI te ne occupi tu”. E l’idea, in fondo, è semplice e sensata: un’intelligenza artificiale che risponde sui documenti aziendali. Vent’anni di contratti, manuali tecnici, fascicoli, procedure, corrispondenza: poter fare una domanda in italiano e ricevere una risposta puntuale, con il riferimento al documento da cui arriva.

Con un vincolo non negoziabile: quei documenti non possono uscire dall’azienda. Poi inizi a informarti, e la prima parola che incontri ovunque è “addestrare”. Ed è lì che un progetto fattibile si trasforma in una montagna: servono dati preparati, competenze che non hai in casa, una macchina enorme, un budget difficile da difendere. Così il progetto si ferma prima ancora di cominciare.

La buona notizia è che quella montagna, nella maggior parte dei casi, non esiste. In questo approfondimento vediamo perché per interrogare i tuoi documenti non serve addestrare alcun modello, quale carico di lavoro nasce davvero da questo progetto e come si dimensiona la workstation che lo fa girare. Te lo raccontiamo anche nel video qui sotto.

L’equivoco che blocca tutto: “dobbiamo addestrare un’AI sui nostri dati”

Partiamo dal linguaggio, perché è da lì che nasce il blocco. “Addestrare un’AI sui nostri documenti” è la formula che usa tutto il mercato, ed è naturale arrivarci: se voglio che il modello conosca le mie pratiche, dovrò pure insegnargliele. Il punto è che in ambito tecnico “addestrare” ha un significato preciso — modificare i pesi interni del modello con un processo di training — e quel processo serve a uno scopo diverso da quello che hai in mente tu.

Il fine-tuning insegna a un modello come comportarsi: uno stile, un formato di risposta, un registro, una terminologia di settore. Non è lo strumento adatto per fargli memorizzare fatti puntuali e mutevoli — la cifra di un contratto, la revisione corrente di una procedura, la clausola di quel fascicolo. Gli studi più recenti che hanno confrontato i due approcci sul recupero di conoscenza fattuale arrivano a una conclusione netta: quando si tratta di accedere a informazioni specifiche e poco frequenti — ed è esattamente la natura dei dati aziendali — un’architettura di recupero supera con ampio margine il modello riaddestrato.

C’è anche un secondo problema, più concreto: un archivio vive. Ogni settimana entrano documenti nuovi e ne cambiano di vecchi. Con il fine-tuning, ogni aggiornamento significherebbe ripetere il ciclo di training. E intanto, mentre il progetto ufficiale resta fermo, in molte aziende sta già succedendo qualcosa di peggio: le persone usano strumenti di AI da account personali, incollandoci dentro proprio quei documenti che non dovevano uscire. Il tema, quindi, non è se portare l’AI in azienda: è darle un canale ufficiale, controllato, prima che il canale se lo trovino da sé le abitudini.

Dove finisce davvero la memoria della macchina

Chi ha già provato un modello in locale ragiona così: guardo quanta VRAM occupa il modello, verifico che ci stia nella scheda, fatto. Per una chat personale funziona. Per un sistema che lavora sul tuo archivio, no: perché in un’architettura di recupero sulla GPU non vive un modello solo. Accanto al modello che genera le risposte restano residenti, sempre accesi, il modello di embedding che trasforma testi e domande in vettori e, nei sistemi fatti bene, un modello di reranking che raffina la pertinenza dei passaggi recuperati. Sono componenti piccoli, ma occupano il loro spazio in modo permanente.

Poi c’è il consumo che quasi nessuno mette in conto: il contesto. Ogni domanda non viaggia da sola — porta con sé i passaggi recuperati dall’archivio, e la memoria di lavoro della conversazione cresce in proporzione. Per dare un ordine di grandezza: un modello di classe 8B nella quantizzazione tipica occupa circa 5 GB di VRAM, ma con contesti da 32.000 token — il regime normale di lavoro quando le risposte devono poggiare su documenti reali — la sola memoria di conversazione può aggiungerne oltre 4. Su modelli di classe superiore, il contesto arriva a pesare quanto il modello stesso. Esistono tecniche per comprimere questa memoria con perdite minime, ed è una delle leve su cui i nostri esperti lavorano in fase di dimensionamento: ma va prevista in partenza, non scoperta al primo “out of memory”.

La sorpresa dell’archivio: non è lui il problema

E l’archivio? Qui arriva il dato che sorprende chiunque affronti il progetto per la prima volta. L’indice semantico di un archivio da 100.000 pagine occupa nell’ordine di 2,5 GB di RAM. Centomila pagine: il lavoro di anni di uno studio professionale o di una PMI strutturata. Il timore “non abbiamo abbastanza spazio, non abbiamo abbastanza dati” si rovescia due volte: lo spazio necessario è una frazione della dotazione standard di una workstation professionale, e i dati che hai già sono esattamente quelli che servono — non occorrono i “big data”, occorre il tuo archivio.

La RAM abbondante serve comunque, ma per ragioni diverse da quelle che immagini: tenere in memoria indice e cache mentre il resto del sistema lavora, assorbire la fase di indicizzazione, garantire margine di crescita. E sotto tutto questo serve uno storage NVMe veloce, perché è lì che vivono i documenti originali e la persistenza dell’indice: quando l’indice lavora da disco, la reattività delle risposte dipende direttamente dalla qualità dello storage. Un archivio su disco di rete lento può trasformare un sistema ben progettato in un sistema che “pensa” per secondi a ogni domanda.

Il costo nascosto: la prima indicizzazione

C’è una fase di questo progetto di cui non parla quasi nessuno, ed è quella che determina la prima impressione che l’azienda avrà del sistema: l’ingestione, cioè la lettura e l’indicizzazione iniziale dell’archivio. La generazione dell’indice in sé, su una GPU adeguata, è rapida. Il vero peso sta prima: nell’estrazione del testo dai documenti.

La variabile decisiva è la composizione dell’archivio. Un PDF nativo digitale si legge in una frazione di secondo. Una scansione — il contratto firmato e scansionato, la pratica archiviata dieci anni fa, il fascicolo cartaceo digitalizzato — deve passare da un motore di riconoscimento ottico, e i benchmark indipendenti sono chiari: è l’OCR la fase pesante dell’intera pipeline, con tempi per pagina che su sola CPU possono salire di ordini di grandezza. Negli studi legali, negli uffici tecnici e nella pubblica amministrazione la quota di scansioni è tipicamente alta: è proprio lì che una GPU dimensionata bene ripaga già nella prima settimana, trasformando un’indicizzazione da giorni in una questione di ore.

La parte rassicurante è che questo costo si paga una volta. A regime, il sistema aggiorna l’indice in modo incrementale: legge solo ciò che è nuovo o cambiato. La prima indicizzazione è un evento; il mantenimento è ordinaria amministrazione.

Da una persona a tutto lo studio: il momento in cui cambia la macchina

Finché il sistema lo usi tu, per validarlo, i conti tornano facilmente. Il salto avviene quando funziona — perché a quel punto lo vogliono tutti. Ed è qui che il dimensionamento cambia natura: la memoria di conversazione di cui parlavamo prima non è condivisa, si moltiplica per ogni utente attivo. Dieci persone che interrogano l’archivio nello stesso momento sono dieci contesti aperti in parallelo sulla stessa GPU, prima ancora di contare il modello.

Sgombriamo però il campo dall’equivoco opposto: per l’AI in azienda non serve un data center. I data center servono per addestrare i modelli di frontiera; per farli lavorare sui documenti di una PMI o di uno studio, una workstation con GPU professionale ad alta VRAM, dimensionata con criterio sui motori di servizio moderni — che gestiscono le richieste concorrenti condividendo intelligentemente la memoria — serve senza affanno un piccolo team. Le nostre workstation professionali su misura nascono esattamente per questo perimetro: la macchina di reparto, sempre accesa, che l’ufficio interroga come fosse un motore di ricerca interno.

Esiste poi una soglia oltre la quale il perimetro cambia, ed è onesto dirlo subito: quando la qualità richiesta impone modelli di classe molto grande, quando gli utenti concorrenti con contesti lunghi superano la memoria di una singola GPU anche dopo le ottimizzazioni, o quando il sistema diventa così centrale da richiedere continuità e ridondanza da infrastruttura. In quei casi la risposta è un server dedicato, non una workstation forzata oltre il suo ruolo. Capire da che parte della soglia stai — oggi, e tra due anni — è la prima cosa che i nostri esperti mettono a fuoco in consulenza, prima ancora di parlare di componenti.

I dati restano dove devono stare

Torniamo al vincolo da cui siamo partiti, perché è la ragione per cui questo progetto si fa in locale. Inviare documenti che contengono dati personali a un servizio esterno è, a tutti gli effetti, un trattamento che coinvolge un fornitore terzo: base giuridica, accordi, valutazioni d’impatto quando il trattamento è ad alto rischio. Con l’elaborazione on-premise la catena si accorcia: i documenti non lasciano mai il perimetro aziendale, e ogni conversazione con il DPO, con il cliente che pretende riservatezza contrattuale o con l’ente che verifica diventa più semplice da documentare.

Il quadro normativo va nella stessa direzione: dal 2 agosto 2026 il regolamento europeo sull’intelligenza artificiale entra in applicazione generale, e un sistema interno di interrogazione documentale non rientra di norma tra i casi ad alto rischio — ciò che il quadro premia è il controllo del dato e la capacità di dimostrarlo. Per chi lavora con clienti strutturati o con la pubblica amministrazione, dove la conformità del fornitore è sempre più spesso un prerequisito contrattuale, avere l’AI in casa smette di essere una cautela e diventa un argomento commerciale.

Gli errori più comuni nei progetti di AI documentale

Errore 1: partire dal fine-tuning quando serve il recupero

È l’errore a monte di tutti gli altri, e nasce dal linguaggio più che dalla tecnica. Progetti impostati sull’addestramento per un obiettivo che l’addestramento non serve: più costosi, più fragili sull’aggiornamento dei documenti, e paradossalmente meno precisi sui fatti. Il fine-tuning ha il suo posto — quando vuoi cambiare il comportamento del modello — ma è un secondo passo eventuale, non il punto di partenza.

Errore 2: dimensionare tutto sulla VRAM del modello

La scheda si riempie di modello, e poi il sistema soffoca sul resto: i componenti ausiliari sempre residenti, la memoria di conversazione che cresce con contesto e utenti. Il dimensionamento corretto parte dal carico complessivo del flusso di lavoro, non dalla scheda tecnica del modello.

Errore 3: trattare l’archivio come l’ostacolo

“Abbiamo troppe pagine” e “abbiamo troppo pochi dati” sono due facce dello stesso equivoco. L’indice di centomila pagine sta in pochi gigabyte di RAM; e il valore non sta nella quantità dei dati, ma nel fatto che sono i tuoi. Il vero nodo dell’archivio è un altro: quante scansioni contiene, perché è quello a determinare il peso della prima indicizzazione.

Errore 4: dimensionare per una persona un sistema che userà tutto l’ufficio

Il prototipo funziona sulla macchina di prova, il sistema viene adottato, e dopo tre mesi rallenta ogni giorno alle undici. Non è un difetto del progetto: è il successo che presenta il conto. La concorrenza degli utenti va messa nel dimensionamento dal primo giorno, con una stima onesta di chi lo userà davvero — e di quanto crescerà.

Il punto

Il progetto “un’AI sui nostri documenti” è più piccolo, più solido e più vicino di come lo racconta la parola “addestrare”. Non richiede un data center, non richiede big data, non richiede un gruppo di ricerca interno. Richiede una cosa sola, fatta bene: una macchina dimensionata sul carico reale del tuo flusso — i modelli che convivono in VRAM, i contesti con cui lavorerai, la composizione del tuo archivio, le persone che lo interrogheranno. Sono queste le domande da cui partire. E sono domande sul tuo lavoro, prima che sull’hardware: per questo la risposta giusta non è mai un listino, ma una conversazione con chi quei carichi li dimensiona ogni giorno.

Domande frequenti

Serve addestrare un’intelligenza artificiale per farle leggere i documenti aziendali?

No. Con un’architettura RAG (Retrieval-Augmented Generation) il modello resta invariato: i documenti vengono indicizzati e il sistema recupera i passaggi pertinenti a ogni domanda, rispondendo con le fonti. L’addestramento serve solo quando vuoi modificare il comportamento del modello, non per dargli accesso ai tuoi contenuti.

Quanta memoria serve per indicizzare un archivio da 100.000 pagine?

L’indice semantico di circa 100.000 pagine occupa nell’ordine di 2,5 GB di RAM, una frazione della dotazione di una workstation professionale. Le risorse critiche sono altre: la VRAM per i modelli residenti e per i contesti lunghi, lo storage NVMe per documenti e indice, e la potenza di calcolo per la prima indicizzazione, soprattutto se l’archivio contiene molte scansioni.

I documenti restano davvero in azienda?

Sì: in un sistema RAG on-premise l’intera pipeline — indicizzazione, ricerca e generazione delle risposte — gira sulla workstation in azienda. Nessun documento e nessuna domanda transita su servizi esterni, il che semplifica in modo sostanziale la conformità al GDPR e le risposte da dare a clienti ed enti che richiedono riservatezza.

Quante persone possono usare l’AI sulla stessa workstation?

Una workstation con GPU professionale ad alta VRAM, dimensionata con criterio, serve un piccolo team che interroga l’archivio in parallelo. La soglia dipende dalla classe di modello e dalla lunghezza dei contesti: ogni utente attivo occupa la propria memoria di conversazione sulla GPU. Quando utenti e contesti superano quella soglia, o serve continuità da infrastruttura, il passo successivo è un server dedicato.

Continua a leggere: LLM in locale: le 6 domande prima di scegliere l’hardware