Cos’è il RAG per i documenti aziendali: cosa può fare e cosa no

Il RAG può trovare frammenti nei documenti aziendali e preparare risposte collegate alle fonti, ma non addestra il modello, non garantisce la verità e non sostituisce il controllo degli accessi.

Lunedì mattina la responsabile delle risorse umane chiede all’assistente interno per quanto tempo vadano conservati i dati dei candidati e riceve una risposta convincente, corredata da un link alla politica aziendale; c’è un solo problema: la versione trovata ha cessato di essere valida otto mesi prima. Un caso del genere mostra bene cos’è il RAG applicato ai documenti aziendali: sul piano tecnico il sistema può aver fatto tutto ciò che gli era stato chiesto, trovando un frammento semanticamente simile, inserendolo nel contesto del modello e scrivendo una risposta scorrevole; non ha però verificato che il file fosse l’ultima versione approvata, se lo stato della versione non era indicato in modo affidabile nell’indice.

RAG è l’acronimo di retrieval-augmented generation, ossia generazione alla quale, nel momento della risposta, viene aggiunto un contesto esterno recuperato; non è un processo che incorpora i documenti aziendali nei pesi del modello, né uno «strato di intelligenza» separato che sappia automaticamente quale documento sia vero; somiglia piuttosto a una biblioteca con un bibliotecario velocissimo e un redattore di talento: il bibliotecario può portare il volume sbagliato, ma il redattore scriverà comunque un paragrafo convincente. Il lavoro scientifico che ha introdotto il RAG distingue esplicitamente la memoria parametrica del modello dalla fonte esterna recuperata, non parametrica.

Il vantaggio pratico è notevole, purché se ne dichiarino con onestà i limiti: il sistema può trovare i frammenti pertinenti in un insieme di documenti gestito, disporli in un contesto adatto alla domanda e preparare una bozza con un riferimento verificabile alla fonte. Il confine della responsabilità deve essere visibile anche all’utente: l’interfaccia non deve suggerire che l’esistenza di una fonte equivalga a un’approvazione giuridica, e segnalare errori o ambiguità deve essere semplice quanto porre una domanda. Il sistema non può riparare una documentazione scadente, garantire la correttezza fattuale, far rispettare da solo i diritti di accesso o sostituire un flusso di lavoro deterministico e l’approvazione umana nei casi in cui un errore crei un rischio giuridico, finanziario, di sicurezza o per i diritti delle persone; questo confine determina sia l’architettura sia ciò che abbia senso misurare nel progetto pilota.

Perché una politica superata può essere recuperata come vigente

L’incidente della politica superata non nasce nel modello linguistico, ma nella gestione documentale: nell’unità condivisa si trovano «Dati_personali_final.docx», «Dati_personali_final2.docx» e un PDF approvato, ma nessun file reca una data di entrata in vigore uniforme, uno stato o l’identificativo della versione sostituita. L’indice vede tre candidati dal contenuto simile, e la ricerca semantica può assegnare un punteggio elevato al documento vecchio perché la sua formulazione corrisponde più precisamente alla domanda. Il modello non vede la decisione presa in una riunione aziendale se quella decisione non è nei dati, e la parola «final» nel nome del file non è un meccanismo di governance.

Le conseguenze sono insidiose perché la risposta può sembrare migliore di un normale risultato di ricerca: è breve, corretta sul piano grammaticale, rimanda a un documento autentico e dà quindi l’impressione che la verifica sia già avvenuta. Il link alla fonte dimostra soltanto che un determinato file è stato mostrato o associato alla risposta; non dimostra ancora che ogni affermazione derivi dal frammento citato, che il frammento non sia stato estratto da una sezione dedicata alle eccezioni o che il documento abbia titolo per essere considerato autorevole. Il profilo NIST per l’IA generativa non considera un simile aspetto rassicurante un controllo del rischio sufficiente e sottolinea la necessità di una governance lungo l’intero ciclo di vita del sistema.

La soluzione consiste nello stato di pubblicazione, nella catena delle versioni e nelle regole di priorità, non in un prompt più lungo: nell’indice ogni documento deve avere un responsabile, date di inizio e fine validità, uno stato, il documento sostituito, il reparto, la classe di riservatezza e una scadenza per il riesame; il filtro di recupero deve escludere per impostazione predefinita le bozze e le versioni non più valide; quando le fonti sono in conflitto, il sistema deve mostrare il conflitto e astenersi dal simulare un’unica risposta certa, mentre al responsabile deve essere assegnato il compito di riordinare l’insieme documentale. Il RAG può illuminare il caos, ma non può trasformarlo in una politica aziendale.

In una situazione simile l’interfaccia della risposta deve mostrare non soltanto il nome del documento, ma anche la versione, lo stato di validità, il frammento e un avviso sul conflitto; il registro deve conservare quali candidati siano stati trovati e perché ne sia stato scelto uno, affinché l’errore possa essere riprodotto dopo una modifica dell’indice. Se in seguito il sistema comincia a fornire una risposta diversa, il team deve poter stabilire se siano cambiati il documento, la frammentazione, la configurazione della ricerca o il modello; senza questa tracciabilità, un incidente di qualità diventa un’ipotesi sul «comportamento dell’IA» anziché un difetto del sistema che si può correggere.

Cos’è il RAG e come funziona sui documenti aziendali?

La pipeline RAG comincia dall’acquisizione dei dati, non dalla finestra di chat: i file vengono prelevati da archivi definiti, se ne estraggono testo, tabelle e struttura disponibile, mentre per i documenti scansionati serve il riconoscimento ottico dei caratteri, o OCR; il contenuto viene poi suddiviso in frammenti significativi, conservando per ciascuno il collegamento al documento, alla pagina, alla sezione e ai metadati di governance. Le linee guida Microsoft descrivono la frammentazione come una scelta che incide sull’utilità della ricerca: un frammento troppo piccolo perde il filo del ragionamento, uno troppo grande porta con sé molto rumore, mentre una divisione cieca dopo un numero fisso di caratteri può spezzare una tabella o una condizione di eccezione.

Nella fase di indicizzazione si crea per i frammenti una rappresentazione adatta alla ricerca, di solito combinando la ricerca per parole chiave con un confronto semantico basato su vettori numerici; quando l’utente pone una domanda, il sistema può trasformarla in più query di ricerca, applicare filtri per reparto, data e accesso, recuperare i candidati e riordinarli per pertinenza; soltanto allora i frammenti selezionati entrano nella finestra di contesto del modello insieme all’istruzione di rispondere sulla base delle prove disponibili, indicare le fonti e dichiarare quando le prove non bastano. In quel momento nulla viene «imparato per sempre»: il contesto vale per la singola richiesta.

L’ultima fase è la generazione, nella quale un modello linguistico già addestrato trasforma i frammenti in una risposta comprensibile; proprio per questo può anche parafrasare male, unire fonti incompatibili o aggiungere un dettaglio plausibile tratto dalle proprie conoscenze generali. Il risultato deve conservare il legame tra ogni affermazione e il relativo frammento, non limitarsi a un elenco decorativo di fonti in fondo alla risposta; se la domanda richiede un’azione, per esempio modificare un prezzo nel CRM, al modello non va data libertà di esecuzione: una richiesta strutturata di utilizzo di uno strumento deve essere verificata dal codice dell’applicazione, dai permessi e da un passaggio di approvazione. Il recupero aiuta a trovare un fondamento; non conferisce il permesso di agire.

Nella pratica funziona bene il recupero ibrido, in cui il codice esatto di un prodotto o il numero di una politica vengono cercati come parole chiave, mentre il significato della domanda viene confrontato semanticamente; in seguito il riordinamento seleziona i frammenti che rispondono meglio all’intera domanda. Questa sequenza va provata con abbreviazioni reali, codici scritti male, forme flesse e documenti multilingue, perché la domanda usata in una dimostrazione è quasi sempre troppo pulita. Se il frammento necessario non compare tra i candidati, il modello generativo non può recuperarlo con l’eloquenza: l’errore di ricerca va corretto prima di riscrivere il prompt.

Per quali usi documentali è adatto il RAG

I candidati migliori sono le domande la cui risposta esiste già in molti documenti gestiti, ma per le quali una persona impiega troppo tempo a cercarla: procedure interne, manuali di prodotto, istruzioni tecniche, documentazione sulla qualità, spiegazioni dei modelli di contratto e basi di conoscenza del supporto clienti. Qui il compito del RAG non è inventare una nuova decisione, ma trovare la sezione pertinente, combinare alcuni frammenti compatibili e preparare una bozza. Una buona domanda è «in quale istruzione è descritto questo errore e quali verifiche indica?», non «come deve comportarsi l’azienda in qualsiasi emergenza?». È utile anche come strato di esplorazione dei documenti prima del lavoro umano: il project manager può trovare nei contratti le condizioni di consegna, l’addetto agli acquisti i riferimenti a un requisito e il tecnico dell’assistenza le soluzioni adottate in precedenza per apparecchiature simili. In questi casi la risposta deve aprire il punto esatto della fonte, in modo che l’utente possa verificare il contesto, e il sistema deve registrare la query, i frammenti trovati e la versione utilizzata. Il RAG diventa così uno strumento di navigazione e preparazione di bozze, non un giudice anonimo del quale sia poi impossibile ricostruire il percorso decisionale.

Sono invece cattivi candidati i compiti privi di una base documentale stabile, quelli che richiedono calcoli esatti o l’applicazione di regole e quelli nei quali un solo errore produce automaticamente un’azione irreversibile. Il calcolo delle retribuzioni, l’assegnazione degli accessi, l’esecuzione di un pagamento e il controllo di una scadenza legale devono essere governati dal codice e da regole di business verificabili; il RAG può trovare la spiegazione di una procedura, ma non può sostituire il motore di calcolo o la catena delle autorizzazioni. Se il vero obiettivo è collegare sistemi e spostare dati in modo prevedibile, va valutata l’automazione dei processi aziendali, anziché trasformare una risposta generata nell’interruttore centrale del processo.

L’idoneità dipende anche da chi assume la responsabilità: ogni insieme di documenti richiede una persona che approvi le fonti, risolva i conflitti e decida che cosa rimuovere dall’indice, mentre ogni caso d’uso richiede un team che esamini gli errori e aggiorni il set di test; se nessuno si assume questo lavoro, dopo qualche mese il progetto pilota diventa lo specchio di documenti vecchi, anche se il modello non è cambiato. Per questo una guida di supporto semplice sul piano tecnico ma ben gestita è un primo progetto migliore rispetto al collegamento, in una sola sera, dell’intero disco aziendale.

Che cosa può fare il RAG con i documenti nel lavoro quotidiano

Il RAG può ridurre il tempo che un dipendente passa a indovinare la cartella e le parole chiave giuste, perché la ricerca semantica riesce a trovare un frammento anche quando le parole della domanda non coincidono con la terminologia del documento. Può combinare nella risposta più fonti compatibili, spiegare un’istruzione complessa in un linguaggio più semplice, preparare la bozza di un’e-mail o di un report e mostrare da quali pagine provenga ogni affermazione importante. La ricerca di file di OpenAI e l’architettura di ricerca di Microsoft sono esempi concreti di strumenti, ma la scelta del prodotto non elimina la necessità di definire lo stato dei propri documenti, i filtri e le verifiche di qualità. Il sistema può inoltre mettere in luce problemi della documentazione che la normale consultazione delle cartelle nasconde: per la stessa domanda vengono trovate due istruzioni contraddittorie, le domande frequenti restano senza fonte oppure un reparto domina i risultati perché i suoi file sono strutturati meglio. Questi casi hanno valore soltanto se non vengono nascosti dietro un’unica risposta scorrevole; una fonte non trovata e un conflitto devono diventare eventi misurabili, visibili al responsabile del documento. In questo modo il registro della qualità del RAG diventa anche una lista di lavoro per la gestione della conoscenza, non soltanto un grafico delle prestazioni del modello.

Un’altra possibilità concreta è adattare la presentazione al ruolo e al contesto: il tecnico riceve un’istruzione dettagliata con i codici, mentre l’addetto al supporto clienti riceve una spiegazione più breve, purché entrambi abbiano il diritto di vedere le stesse fonti. Cambia la presentazione, non la verità, e per ogni ruolo devono restare invariati lo stato della fonte e il divieto di inventare ciò che manca. Il nostro lavoro sulle soluzioni di IA per le aziende parte dai confini del caso d’uso e del rischio, non dalla dimostrazione di un modello, perché un buon prototipo prova un vantaggio concreto sui Suoi documenti e mostra allo stesso tempo a quali domande il sistema debba rispondere «non lo so».

Nel lavoro quotidiano il vantaggio maggiore nasce quando la persona vede ciò che il sistema ha fatto al suo posto e ciò che resta da verificare. Nella bozza di risposta si possono evidenziare le affermazioni sostenute da prove incomplete, proporre documenti correlati e permettere di segnalare con un’unica azione una versione errata; un simile riscontro vale più di una semplice icona con il pollice. La correzione va associata alla domanda, al frammento e al tipo di errore, affinché il team possa distinguere una fonte non trovata da una formulazione poco chiara o da una regola di business sbagliata e scegliere l’intervento appropriato.

Che cosa non può fare il RAG, per quanto convincente sia la risposta

Il RAG non può garantire la verità, perché l’errore può nascere prima, durante o dopo la generazione: la fonte può contenere un fatto sbagliato, il recupero può selezionare un frammento non pertinente, il contesto può perdere un’eccezione e il modello può collegare in modo errato paragrafi corretti. Una citazione riduce il rischio di fidarsi alla cieca soltanto se l’utente può aprire il punto esatto e controllare che l’affermazione ne derivi davvero; un link a un PDF autentico, però, non è un marchio di qualità, proprio come la bibliografia di un report sbagliato non ne rende corretta la conclusione.

Il RAG non può nemmeno applicare da solo il controllo degli accessi: se, prima del recupero, il livello di ricerca non filtra i documenti in base all’identità verificata dell’utente e ai permessi del documento, il modello può ricevere un frammento che l’utente non è autorizzato a vedere. Un’istruzione aggiunta in seguito al prompt, come «non divulgare informazioni segrete», non corregge questo errore di architettura. Le linee guida Microsoft sul controllo degli accessi a livello di documento prevedono i dati di autorizzazione e i filtri di sicurezza nel percorso stesso della ricerca; un pulsante nascosto nell’interfaccia non offre protezione se la richiesta può essere attivata in un altro modo.

Il RAG non rende sicuro neppure un contenuto non affidabile: un documento, una pagina web o un’e-mail possono contenere un’istruzione che tenta di riscrivere il comportamento del sistema, ossia una prompt injection, e OWASP la indica come un rischio distinto che un semplice divieto nel prompt di sistema non risolve completamente. Il contenuto esterno va quindi trattato come dato, non come comando; le chiamate agli strumenti devono essere autorizzate in modo restrittivo e validate, mentre un’azione ad alto rischio deve continuare a essere governata da una regola deterministica e dall’approvazione umana. Il modello può proporre; è il sistema ad attribuire l’autorità.

Tra i limiti vanno incluse anche la disponibilità e la continuità operativa: se l’indice di ricerca non è raggiungibile, un sistema sicuro non finge di avere ancora accesso alle fonti aziendali, ma passa chiaramente a uno stato di errore o a una modalità limitata; altrimenti l’utente non può distinguere una risposta basata sulle fonti da una libera improvvisazione del modello. Servono inoltre limiti di costo e di richieste, un arresto di emergenza e la possibilità di ripristinare la configurazione precedente. Un prodotto RAG è una catena di più servizi, e ogni guasto silenzioso può cambiare il significato della risposta anche quando la finestra di chat continua a funzionare.

Preparazione dei documenti: OCR, metadati e versioni

La dimensione della cartella documentale non misura il livello di preparazione: un contratto scansionato con una pagina storta, una tabella senza intestazione leggibile, un PDF con il testo nell’ordine sbagliato o una fotografia a basso contrasto possono sembrare comprensibili a una persona, ma perdere nell’estrazione OCR una cifra, il rapporto tra le colonne o il confine di un paragrafo. La descrizione Microsoft dei limiti dell’OCR lega esplicitamente il risultato alla qualità della scansione, alla risoluzione, al contrasto, all’illuminazione, alla rotazione e alle caratteristiche del testo. I documenti rappresentativi vanno quindi controllati dopo l’estrazione, confrontando testo, tabelle, riferimenti di pagina e campi essenziali con l’originale, anziché confidare nel messaggio che il file sia stato «elaborato correttamente».

I metadati danno al frammento il contesto organizzativo: tipo di documento, reparto, prodotto, lingua, responsabile, approvatore, riservatezza, data di entrata in vigore e stato della versione consentono di restringere la ricerca prima di valutarne la somiglianza semantica. Senza questi dati il sistema confronta frasi, ma non sa che l’istruzione di magazzino vale soltanto per la Lituania o che un allegato contrattuale è stato sostituito da uno più recente. I campi più importanti devono provenire da un sistema affidabile o essere controllati da una persona; un’ipotesi generata sullo stato di un documento non deve diventare il filtro che determina la risposta successiva.

Anche l’aggiornamento è parte del prodotto, non un’attività di importazione una tantum: occorre sapere quanto tempo impieghi una modifica approvata a raggiungere l’indice, come venga eliminato un frammento ritirato, che cosa accada quando cambia l’indirizzo del file e se, in caso di errore, il sistema continui a mostrare la vecchia versione. Le linee guida Microsoft sull’indicizzazione distinguono gli aggiornamenti incrementali dalla reindicizzazione, perciò ogni fonte richiede un metodo documentato di sincronizzazione e controllo degli errori. Prima di un progetto RAG conviene mettere in ordine un unico flusso documentale autorevole; altrimenti un recupero rapido accelera soltanto le conseguenze di una governance poco chiara.

Prima della prima indicizzazione è utile un campione che rappresenti lo stato dei documenti: si scelgono tipi di file, età, lingue, tabelle, scansioni e classi di accesso differenti, quindi per ciascuno si verificano il testo estratto, i confini dei frammenti, i metadati e il link alla fonte. La quota di errori non va trasformata in un’unica media, perché il costo di una virgola mancante in un’istruzione è diverso da quello di un importo mancante in un contratto. Il campione permette di decidere quali formati accettare automaticamente, quali sottoporre a verifica umana e quali non indicizzare per il momento; questo lavoro produce spesso un miglioramento della qualità maggiore rispetto alla scelta di un altro modello linguistico.

Diritti di accesso, privacy e scelta dell’ambiente di esecuzione

Un’architettura sicura comincia dall’identità: chi pone la domanda, a quale organizzazione e reparto appartiene, quali classi di documenti può vedere e se questi diritti vengano verificati a ogni richiesta di recupero. Il filtro delle autorizzazioni deve agire prima che i frammenti entrino nel contesto del modello, mentre nei registri vanno evitate copie non necessarie di domande, risposte e frammenti sensibili completi; occorre provare anche i casi limite: un dipendente cambia ruolo, un documento diventa riservato, un accesso viene revocato oppure un cliente tenta di trovare i contenuti di un altro. «La chat richiede l’accesso» non è un criterio di accettazione sufficiente.

Non esiste una risposta universale e onesta alla domanda «i miei dati verranno usati per addestrare il modello?» senza indicare il fornitore, il prodotto, l’account e le impostazioni. I materiali di OpenAI per le aziende e le API stabiliscono che, per i prodotti aziendali interessati, i dati non vengano usati per addestrare i modelli per impostazione predefinita, mentre la documentazione sui controlli dei dati dell’API descrive separatamente la conservazione, il monitoraggio degli abusi e le eccezioni relative agli endpoint; anche Anthropic distingue il trattamento nei prodotti commerciali, il consenso esplicito al miglioramento e le condizioni di conservazione. Il contratto e il progetto tecnico devono quindi verificare il servizio concreto, non affidarsi all’espressione «API aziendale».

L’esecuzione in una regione dell’UE o nella propria infrastruttura può contribuire a soddisfare requisiti specifici relativi alla localizzazione dei dati, al controllo o all’integrazione, ma non dimostra da sola che la soluzione sia sicura o conforme al GDPR. Devono ancora essere definiti la finalità e la base giuridica del trattamento, la minimizzazione dei dati, i periodi di conservazione, i sub-responsabili del trattamento, la cancellazione, la gestione degli incidenti e l’audit degli accessi; i principi del GDPR valgono per l’intera catena, non soltanto per il Paese in cui si trova il server del modello. A volte la decisione corretta consiste nell’escludere del tutto determinati documenti dal RAG o nel rimuovere, prima dell’indicizzazione, i campi che non servono alla risposta.

Il modello delle minacce non deve considerare soltanto un dipendente curioso: deve coprire anche una sincronizzazione errata dei gruppi, un link condiviso, un ruolo di amministratore, una cache memorizzata e un documento contenente un’istruzione malevola. Gli utenti di test devono rappresentare ogni ruolo e ogni combinazione vietata di ruoli, tentando domande dirette, sinonimi e richieste indirette di riepilogo. Il risultato non deve rivelare né un frammento, né il nome del documento, né un dettaglio riservato deducibile dalla risposta. Il test va ripetuto dopo ogni modifica dei diritti, perché il filtro sicuro di ieri può essere rimasto nella cache. Queste verifiche sono criteri di accettazione, non decorazioni da aggiungere a un successivo audit di sicurezza.

Come misurare recupero, fondatezza nelle fonti e correttezza

Un unico valore di «accuratezza» per un sistema RAG è come un solo voto medio per un ospedale: il numero può sembrare buono mentre una classe critica di errori resta nascosta. Per prima cosa si misura separatamente il recupero, verificando se il frammento necessario compaia entro un numero definito di primi risultati e se frammenti irrilevanti lo abbiano escluso. Si misurano poi la pertinenza del contesto rispetto alla domanda, la fondatezza della risposta nei frammenti forniti, la correttezza fattuale rispetto a un riferimento approvato, la corrispondenza di ogni fonte alla specifica affermazione e la capacità del sistema di non rispondere quando manca una fonte o le fonti sono in conflitto.

La documentazione Microsoft sui valutatori RAG separa queste dimensioni, e il lavoro di ricerca ARES distingue in modo analogo la pertinenza del contesto, la fondatezza della risposta e la pertinenza della risposta. In un set di test pratico, quindi, ogni domanda reale richiede più della «risposta corretta»: servono anche una fonte obbligatoria, formulazioni ammesse, affermazioni vietate, un ruolo, una versione del documento e il comportamento atteso quando le prove non bastano. Alcuni esempi devono venire dalle domande frequenti, altri da eccezioni costose e trappole intenzionali.

La soglia di accettazione va stabilita per ciascuna dimensione e classe di rischio prima di vedere i risultati; altrimenti, dopo la dimostrazione, il team sceglierà l’indicatore che appare migliore. Le misurazioni del progetto pilota devono inoltre conservare la distribuzione degli errori per tipo di documento, reparto, lingua e tipo di domanda, perché la media complessiva può nascondere che i manuali funzionino bene mentre le tabelle dei contratti funzionano male. Un valutatore automatico basato su un modello permette di scalare le prove, ma un campione deve essere esaminato da una persona e le risposte critiche vanno confrontate con una fonte autorevole, non con la sicurezza mostrata da un altro modello.

Dopo il lancio vanno misurate le stesse dimensioni, ma su un campione controllato della produzione e con registri rispettosi della privacy. Una modifica al corpus documentale, all’algoritmo di frammentazione, al modello di embedding, al riordinamento o al modello generativo può migliorare un gruppo di domande e peggiorarne un altro. Per questo ogni versione richiede un test di regressione e una baseline confrontabile, con regole di valutazione invariate per l’intero set di test. Un avviso non deve attivarsi soltanto quando scende il punteggio complessivo, ma anche quando compare un errore critico, per esempio un frammento non autorizzato o una risposta inventata là dove il sistema avrebbe dovuto astenersi.

RAG, ricerca, contesto lungo, fine-tuning e agenti

La normale ricerca full-text è migliore quando l’utente conosce il nome, il codice o l’espressione esatta e gli serve un documento anziché una risposta composta; costa meno, è più prevedibile ed è più facile da sottoporre ad audit. La ricerca semantica aiuta con sinonimi e domande vaghe, ma la generazione va aggiunta soltanto quando un riepilogo offre un valore reale. Il RAG non è obbligatorio in ogni strumento di ricerca aziendale: a volte il prodotto giusto è una buona pagina di ricerca con filtri, anteprima dei frammenti e stato delle versioni, perché è l’utente a poter trarre la conclusione dal documento completo.

Inserire un intero documento in una finestra di contesto lunga può essere semplice per una quantità di materiale piccola e stabile, ma in un corpus ampio aumentano i costi, il rumore e il rischio che un paragrafo importante si perda tra contenuti irrilevanti. Il fine-tuning del modello può invece rafforzare un formato, uno stile o il comportamento in un compito specifico, ma non è un modo pratico per conservare prezzi, politiche e istruzioni che cambiano spesso, perché aggiornare e citare la fonte diventa meno trasparente. Il RAG consente di modificare l’insieme dei documenti senza intervenire sull’addestramento dei pesi del modello, ma questa flessibilità richiede la gestione dell’indice, delle versioni e della qualità del recupero.

L’automazione esegue passaggi definiti in anticipo, mentre un agente di IA può scegliere lo strumento e il passaggio successivo; questa libertà richiede quindi limiti più rigidi su autorizzazioni, validazione e arresto. Il RAG può fornire informazioni a un agente, ma non diritti: anche se il modello trova la politica sulle ferie, non può approvare da solo un’assenza o modificare il sistema retributivo. Una chiamata di funzione strutturata è soltanto una proposta all’applicazione, che verifica lo schema, l’identità, l’azione consentita, l’importo o altri limiti e la necessaria approvazione umana. Il confronto tra tecnologie parte dal rischio del processo, non dal desiderio di usare il termine più recente.

La scelta si può formulare come una semplice prova: se occorre trovare e aprire un file, si comincia dalla ricerca; se occorre riassumere con riferimenti alcune fonti mutevoli, si valuta il RAG; se occorre mantenere un formato stabile o un determinato comportamento di classificazione, può essere adatto il fine-tuning; se occorre eseguire una sequenza prevedibile di azioni, si costruisce un’automazione; un agente si aggiunge soltanto quando il passaggio successivo non può essere programmato in modo sicuro e il vantaggio compensa il rischio aggiuntivo. Gli approcci si possono combinare, ma ogni strato deve avere un compito, una misura e un limite di arresto propri; altrimenti la causa di un errore scompare dietro la parola «IA».

Come costruire un progetto pilota circoscritto con domande reali

Un progetto pilota comincia con un solo insieme di documenti, un solo gruppo di utenti e un solo confine decisionale, per esempio i manuali del supporto tecnico, dove il sistema si limita a trovare le fonti e preparare una bozza di risposta. Prima dello sviluppo il team raccoglie domande reali dai registri di ricerca, dalle e-mail e dalle interviste con i dipendenti, aggiunge le fonti corrette e include deliberatamente casi senza risposta, superati, contraddittori e non autorizzati. Per ogni caso si definisce che cosa sia accettabile: il frammento necessario viene trovato, l’affermazione è fondata nella fonte, la citazione porta al punto corretto, la risposta è fattualmente esatta e il sistema evita in modo sicuro di inventare ciò che manca.

Le soglie vanno fissate prima della dimostrazione e suddivise per rischio: una bozza correggibile può essere accettabile per una comune domanda informativa, mentre una domanda su dati personali, contratti, sicurezza o pagamenti richiede un controllo più rigoroso e l’approvazione umana. Il progetto pilota deve misurare anche il tempo di risposta, il costo per richiesta, il funzionamento dei filtri di accesso, il ritardo nell’aggiornamento dell’indice e la frequenza con cui un dipendente apre la fonte o corregge la risposta. Se il sistema migliora soltanto gli esempi della dimostrazione ma non supera un set di test tenuto nascosto in precedenza, non è stato dimostrato un risultato del prodotto; è stato dimostrato soltanto che il team sa preparare una dimostrazione.

Lo sviluppo delle nostre soluzioni di IA per le aziende parte da 3.500 € e richiede in genere 3–8 settimane, mentre un progetto pilota funzionante sui Suoi dati può essere consegnato in 2–3 settimane; queste cifre indicano il prezzo di partenza del servizio e i tempi generali, non un’offerta fissa per un perimetro ancora ignoto. Alla fine del progetto pilota deve esserci più di una finestra di chat: occorrono un corpus documentale versionato, domande di test, misure separate della qualità, un registro degli errori, verifiche degli accessi e una decisione su ciò che la soluzione non deve fare. I requisiti di integrazione successivi vanno registrati con la stessa chiarezza di qualsiasi altro progetto digitale, secondo il principio descritto in 10 errori da evitare nella realizzazione di un sito web: i criteri di accettazione e i responsabili devono essere definiti prima dell’adozione completa, non dopo la prima schermata impressionante.

Il progetto pilota va proseguito soltanto se raggiunge le soglie definite in anticipo su una parte non vista del set di test, gestisce in modo sicuro le domande non autorizzate o senza risposta e produce un vantaggio misurabile nel lavoro umano. Se il recupero non trova sistematicamente la fonte giusta, vanno corretti prima i documenti, i metadati e l’indice; se la fonte è corretta ma la generazione la distorce, vanno modificati il contesto, il prompt o il modello; se l’errore si presenta soltanto nelle decisioni ad alto rischio, quelle decisioni devono restare a un sistema deterministico e a una persona. Un progetto pilota interrotto non è un fallimento: è una prova ottenuta a basso costo del fatto che, per quel processo, i limiti del RAG contano più dell’effetto prodotto dalla dimostrazione.