telodico.io

AI

RAG aziendale per PMI: prima scegliete i documenti, poi il modello

Il RAG promette AI sui documenti aziendali senza addestrare un modello da zero. Per una PMI funziona solo se prima si mettono ordine, permessi, log e uscita dal fornitore.

8 min

RAG aziendale per PMI: prima scegliete i documenti, poi il modello

Il modo più rapido per sprecare soldi sull’AI aziendale è collegare un chatbot a una cartella condivisa e chiamarlo knowledge management.

Il RAG (Retrieval-Augmented Generation) è una buona architettura. Permette a un assistente AI di rispondere usando documenti aziendali — procedure, offerte, manuali, ticket, contratti, basi di conoscenza — senza addestrare un modello proprietario. È il motivo per cui molte PMI lo stanno guardando con interesse: promette produttività concreta, tempi rapidi e meno dipendenza dai grandi modelli generalisti.

Ma il RAG non ripara il disordine: lo amplifica con un’interfaccia elegante. Se i documenti sono duplicati, vecchi, senza proprietario, pieni di dati personali inutili o accessibili a chiunque, l’AI non diventa intelligente: diventa un motore veloce per trovare errori organizzativi che c’erano già. La differenza tra un progetto utile e un giocattolo rischioso non sta nel nome del modello. Sta in come si scelgono le fonti, dove si indicizzano, chi può interrogarle e quanto è facile cambiare fornitore.

Per una PMI italiana questo è un vantaggio, non un limite. Non serve costruire una piattaforma da grande banca. Serve partire piccoli, con un perimetro sensato, un system integrator che sappia parlare con produzione, commerciale e amministrazione, e qualche regola scritta bene. Il RAG può essere una delle strade più pragmatiche per introdurre AI in azienda senza consegnare tutto il patrimonio informativo a una suite chiusa.

1. Il RAG non è magia: è ricerca documentale con un modello sopra

Il funzionamento è abbastanza semplice. I documenti vengono spezzati in parti più piccole, trasformati in rappresentazioni numeriche, indicizzati in un motore di ricerca o in un vector database, e recuperati quando l’utente fa una domanda. Il modello linguistico usa quei frammenti come contesto per produrre una risposta.

Questa architettura ha un pregio enorme: separa il modello dai dati aziendali. Invece di addestrare un modello su tutto il patrimonio documentale — costoso e spesso inutile per una PMI — si costruisce un sistema che recupera le informazioni pertinenti al momento della richiesta. Il modello può essere commerciale, open weight, ospitato in cloud europeo o su infrastruttura dedicata. I documenti restano una componente separata, governabile e sostituibile.

È qui che molti progetti sbagliano. Si parte dal modello, dal benchmark, dal nome del vendor. Poi si scopre che buona parte dei file sono bozze, versioni superate, scansioni non ricercabili, allegati e-mail salvati tre volte, listini storici mischiati con quelli correnti. A quel punto il problema non è più l’AI: è igiene documentale.

Il RAG è utile quando esiste una base informativa relativamente affidabile. Non perfetta — nessuna PMI ha un archivio perfetto — ma abbastanza chiara da distinguere tra documento valido e documento storico, tra procedura approvata e appunto personale, tra contratto firmato e bozza inviata a un cliente. Se questa distinzione non esiste, il progetto AI diventa una costosa operazione di archeologia aziendale.

La buona notizia è che non occorre sistemare tutto. Occorre scegliere un primo caso d’uso dove il valore è alto e il rischio è controllabile. Manuali tecnici, procedure interne, cataloghi prodotto, FAQ del customer service, documentazione già pubblica o documenti commerciali approvati sono candidati migliori rispetto alla posta elettronica completa dell’azienda o alle cartelle personali dei dipendenti.

2. Il primo perimetro deve essere piccolo, ma vero

Una PMI non dovrebbe iniziare con l’obiettivo di mettere tutta la conoscenza aziendale dentro un assistente AI. È un obiettivo seducente e sbagliato. La conoscenza aziendale non è un monolite: è fatta di reparti, responsabilità, permessi, dati personali, segreti commerciali e abitudini operative.

Il primo perimetro deve essere piccolo, ma utile. Per esempio: assistenza tecnica su una linea di prodotto, supporto al commerciale per recuperare schede e condizioni approvate, ricerca interna sulle procedure qualità, onboarding dei nuovi tecnici. Serve un gruppo di utenti reali, un insieme di documenti identificabile e una metrica semplice: tempo risparmiato, riduzione dei ticket interni, meno errori nelle risposte, più rapidità nella preparazione di offerte.

La tentazione del prototipo infinito è forte. Si fa una demo, funziona bene su tre domande, tutti applaudono e nessuno la usa davvero. Il progetto serio prevede invece una fase pilota breve, con documenti veri e utenti veri. Non serve una governance da multinazionale. Serve sapere chi decide che un documento entra nel perimetro, chi lo aggiorna, chi corregge le risposte sbagliate e chi spegne l’accesso se qualcosa non va.

Per restare concreti, le prime decisioni dovrebbero essere poche:

  • quali documenti entrano nel primo indice e quali restano fuori;
  • chi è il proprietario funzionale del contenuto;
  • quali utenti possono interrogare il sistema;
  • dove vengono conservati indice, log e documenti originali;
  • come si esportano dati, embedding e configurazioni se si cambia fornitore.

Non sono formalità. Sono le domande che decidono se l’AI diventa infrastruttura aziendale o l’ennesimo esperimento abbandonato dopo tre mesi. Ed è proprio qui che un integratore vicino, non necessariamente grande, fa la differenza: parlare con le persone che usano i documenti ogni giorno vale più di cento slide sulla trasformazione digitale.

3. GDPR: il problema non è usare l’AI, è indicizzare troppo

Il GDPR non vieta di usare sistemi AI sui documenti aziendali. Chiede però che i trattamenti abbiano una base solida, siano proporzionati e rispettino principi chiari. L’art. 5 del Regolamento (UE) 2016/679 parla di minimizzazione dei dati, esattezza, limitazione della conservazione, integrità e riservatezza. In un progetto RAG questi principi non sono teoria: diventano scelte tecniche.

Indicizzare una cartella piena di contratti, CV, segnalazioni interne, e-mail e documenti sanitari senza selezione è una cattiva idea. Non perché l’AI sia vietata, ma perché si sta trasformando un archivio disordinato in un motore di interrogazione potente. Quello che prima era difficile da trovare diventa accessibile con una domanda in linguaggio naturale. Se i permessi sono larghi, l’AI non crea il problema: lo rende operativo.

L’art. 25 GDPR — protezione dei dati fin dalla progettazione e per impostazione predefinita — è particolarmente adatto a leggere questi progetti. Un RAG fatto bene non indicizza tutto per poi correggere dopo. Parte dal minimo necessario, maschera o esclude i dati personali non pertinenti, tiene separati gli indici per reparti o classi di utenti, applica controlli di accesso coerenti con quelli dei sistemi di origine.

C’è poi l’art. 28 GDPR, che regola il rapporto quando il fornitore tratta dati personali per conto dell’azienda. Molti servizi AI SaaS non sono semplici software: elaborano prompt, documenti, log, output, metriche d’uso. Serve un accordo da responsabile del trattamento quando ricorrono i presupposti, e serve capire dove finiscono i dati. Non basta la frase commerciale secondo cui i dati non vengono usati per addestrare il modello. Bisogna leggere cosa accade a prompt, file caricati, log tecnici, tempi di conservazione e subfornitori.

Infine l’art. 32 GDPR, sulla sicurezza del trattamento. Per un RAG significa cifratura, controllo accessi, logging, segregazione degli ambienti, backup e procedure di ripristino. Anche qui, niente burocrazia inutile: se l’assistente diventa uno strumento quotidiano per vendite, assistenza o operation, deve poter essere ripristinato e verificato come qualunque altro sistema aziendale rilevante.

4. Il lock-in del RAG non è solo nel modello

Si parla molto di lock-in verso i modelli AI. È un tema reale, ma non è l’unico. In un’architettura RAG il lock-in può annidarsi nell’indice vettoriale, nel formato degli embedding, nei connettori verso le fonti documentali, nel sistema di permessi, nei log e nell’interfaccia utente.

Una PMI può accettare una soluzione gestita, anche proprietaria, se il valore è chiaro e il contratto è leggibile. Il punto non è fare tutto in casa. Il punto è non confondere la comodità con l’irreversibilità. Se dopo un anno il progetto funziona, i costi crescono e il fornitore cambia le condizioni, l’azienda deve poter uscire senza ricostruire da zero la propria base di conoscenza.

Gli elementi da chiarire prima sono molto pratici. I documenti originali restano in un repository controllato dall’azienda o vengono duplicati nel servizio del vendor? Gli embedding sono esportabili? L’indice può essere ricostruito usando un altro modello? I connettori verso file server, SharePoint, gestionale, ticketing o CRM sono standard o sviluppati in modo chiuso? I log delle interrogazioni sono disponibili in formato utilizzabile? Le configurazioni dei prompt e dei ruoli sono documentate?

Qui il cloud indipendente non è una bandiera, è un’opzione tecnica e contrattuale. Un RAG può essere ospitato presso un provider italiano o europeo, con componenti open source e un modello commerciale chiamato via API solo quando serve. Oppure può stare dentro una suite globale, se l’azienda accetta consapevolmente quel perimetro. La scelta sbagliata è non scegliere: lasciare che il primo fornitore della demo diventi di fatto il custode della conoscenza aziendale.

La sovranità, per una PMI, si misura nei passaggi di mano. Chi ha le credenziali amministrative? Chi può esportare l’indice? Chi può revocare le chiavi API? Chi sa ricostruire l’ambiente se il vendor non risponde? Chi tiene la documentazione tecnica? Sono domande poco glamour, ma quando il sistema entra nei processi quotidiani contano più del nome del modello.

5. AI Act: meno panico, più alfabetizzazione e controllo d’uso

Il Regolamento (UE) 2024/1689, noto come AI Act, viene spesso usato come spauracchio generico. Per molte PMI che introducono un assistente RAG interno, il punto iniziale non è dimostrare una conformità monumentale. È capire che tipo di sistema si sta usando, per quale scopo e con quali effetti sulle persone.

Non tutti i sistemi AI sono ad alto rischio. Un assistente che aiuta i tecnici a cercare manuali o il commerciale a trovare schede prodotto non ricade automaticamente nella categoria più onerosa del regolamento. Serve invece maggiore attenzione se il sistema incide su selezione del personale, valutazione dei lavoratori, accesso a servizi essenziali, credito, istruzione o altri ambiti sensibili previsti dalle norme.

C’è un obbligo dell’AI Act che le PMI dovrebbero prendere sul serio subito: l’alfabetizzazione AI. Chi utilizza questi sistemi deve adottare misure per garantire un livello sufficiente di competenza del personale e delle persone che li usano o li gestiscono per proprio conto. Tradotto in azienda: non basta comprare lo strumento. Bisogna spiegare agli utenti che l’AI può sbagliare, che le fonti vanno controllate, che non si inseriscono dati fuori perimetro, che gli output non sostituiscono responsabilità e approvazioni.

Questa formazione non deve essere un corso di otto ore pieno di definizioni. Per una PMI funziona meglio una sessione concreta sul caso d’uso: che cosa può fare l’assistente, che cosa non deve fare, quali documenti vede, come segnalare una risposta errata, quando serve una verifica umana. È governance minima, non teatro della compliance.

Anche la trasparenza interna conta. Se un reparto usa un assistente RAG per preparare risposte ai clienti, è bene sapere quali risposte possono uscire senza revisione e quali no. Se l’AI suggerisce contenuti tecnici, commerciali o contrattuali, l’azienda deve decidere dove resta l’approvazione umana. Non per paura della macchina, ma perché la responsabilità verso clienti e fornitori resta aziendale.

6. Il progetto giusto somiglia più a un impianto che a una demo

Un RAG serio per PMI va trattato come un piccolo impianto informativo. Ha sorgenti, trasformazioni, controlli, utenti, manutenzione e costi ricorrenti. Non è una pagina web con una chat sopra.

La parte più sottovalutata è la manutenzione. I documenti cambiano, le procedure vengono aggiornate, i listini scadono, i contratti vengono sostituiti, i dipendenti cambiano ruolo. Se l’indice non viene aggiornato con regole chiare, l’assistente comincia a rispondere con informazioni vecchie. Peggio: lo fa con sicurezza linguistica, così l’errore sembra autorevole.

Serve quindi un ciclo di vita minimo. Quando un documento viene aggiornato nel repository ufficiale, l’indice deve saperlo. Quando un utente perde accesso a una cartella, deve perdere anche accesso alle risposte basate su quei documenti. Quando una risposta è sbagliata, qualcuno deve poter vedere quali fonti sono state recuperate e correggere la base dati. Senza citazioni delle fonti e log consultabili, un RAG diventa una scatola nera aziendale.

Attenzione anche ai costi. Le demo costano poco perché usano pochi documenti, pochi utenti e poche domande. In produzione entrano indicizzazione periodica, storage, chiamate al modello, logging, backup, ambienti di test, monitoraggio e supporto. Non sono costi proibitivi, ma vanno stimati prima. Una soluzione ben dimensionata resta sostenibile; una soluzione scelta solo per moda diventa un abbonamento difficile da ridurre.

Il ruolo dei system integrator italiani, quelli davvero a misura di PMI, è prezioso proprio qui. Non devono vendere un sogno generico sull’AI. Devono aiutare a disegnare un perimetro, scegliere componenti sostituibili, collegare i sistemi esistenti, documentare le scelte e lasciare all’azienda le chiavi operative. Un buon integratore non rende il cliente dipendente dalla propria magia: gli costruisce una strada percorribile.

7. La domanda da fare non è quale modello usare

La domanda migliore, all’inizio, non è quale modello usare. È quale decisione aziendale vogliamo rendere più veloce, più coerente o meno faticosa.

Se l’obiettivo è ridurre il tempo dei tecnici nel cercare manuali, il progetto avrà certe fonti, certi permessi e certe metriche. Se l’obiettivo è supportare il commerciale nella preparazione delle offerte, ne avrà altri. Se l’obiettivo è aiutare l’amministrazione a trovare procedure interne, cambiano ancora perimetro e rischi. Il modello arriva dopo, come componente sostituibile di un’architettura.

Questo approccio è meno spettacolare, ma più sovrano. Tiene i dati vicino al processo, non al vendor. Permette di usare cloud e AI senza subire automaticamente il pacchetto completo di chi ha la piattaforma più grande. Riduce l’entusiasmo tossico e anche la paura sterile. Soprattutto, dà alle PMI un modo pratico per imparare facendo, senza consegnare al primo chatbot tutto ciò che l’azienda sa.

Il RAG può essere una delle tecnologie più utili per le imprese italiane nei prossimi anni, a patto di non trattarlo come una scorciatoia. Prima i documenti, poi i permessi, poi i log, poi il modello. In quest’ordine. Chi lo capisce costruisce un assistente aziendale. Chi lo ignora costruisce solo una ricerca confusa con una voce convincente.

Riferimenti

Fonti ufficiali

Le versioni autoritative restano quelle pubblicate dagli enti competenti. Verifica sempre alla fonte prima di prendere decisioni operative.

In sintesi

Domande frequenti

Da dove conviene partire con un progetto RAG senza sprecare budget?

Non dal modello o dal benchmark, ma dalla scelta delle fonti. Si parte da un caso d'uso circoscritto ad alto valore e basso rischio, come manuali tecnici, procedure interne, cataloghi prodotto o FAQ del customer service. La posta elettronica completa e le cartelle personali sono i candidati peggiori per un primo indice.

Devo firmare un accordo ex art. 28 GDPR con il fornitore del servizio AI?

Sì, quando il fornitore tratta dati personali per conto dell'azienda ricorrono i presupposti per la nomina a responsabile del trattamento. I servizi AI SaaS elaborano prompt, documenti, log e output, quindi serve capire dove finiscono i dati, i tempi di conservazione e quali subfornitori sono coinvolti. La frase commerciale sul mancato addestramento del modello non basta.

Il mio assistente RAG interno ricade tra i sistemi ad alto rischio dell'AI Act?

Non automaticamente. Un assistente che aiuta i tecnici a cercare manuali o il commerciale a trovare schede prodotto in genere non rientra nella categoria più onerosa. L'attenzione sale se il sistema incide su selezione e valutazione del personale, accesso a credito o servizi essenziali. In ogni caso vale già l'obbligo di alfabetizzazione AI del personale.

Come evito il lock-in in un'architettura RAG, non solo sul modello?

Il lock-in può annidarsi nell'indice vettoriale, negli embedding, nei connettori verso le fonti, nel sistema di permessi e nei log. Prima di firmare va chiarito se i documenti originali restano in un repository aziendale, se gli embedding sono esportabili, se l'indice è ricostruibile con un altro modello e se i connettori sono standard. La sovranità si misura nei passaggi di mano: credenziali, chiavi API, documentazione.

Quali costi ricorrenti devo mettere a budget oltre alla demo iniziale?

In produzione entrano indicizzazione periodica, storage, chiamate al modello, logging, backup, ambienti di test, monitoraggio e supporto. Le demo costano poco perché usano pochi documenti e poche domande. I costi non sono proibitivi, ma vanno stimati prima per evitare un abbonamento difficile da ridurre.

Come impedisco che l'assistente risponda con informazioni vecchie o sbagliate?

Serve un ciclo di vita dell'indice: quando un documento cambia nel repository ufficiale l'indice deve aggiornarsi, e quando un utente perde accesso a una cartella deve perdere accesso anche alle relative risposte. Sono indispensabili citazioni delle fonti e log consultabili, altrimenti il RAG diventa una scatola nera che sbaglia con tono autorevole.

Discussione (0)

Carico…


Per commentare serve un'identità verificata. Inserisci la tua email: riceverai un link per accedere senza password.