AI enterprise: come scegliere tra SaaS, RAG e on-premise

La crescente adozione dell’intelligenza artificiale in ambito enterprise pone le organizzazioni di fronte a una scelta architetturale cruciale: quale modello di distribuzione adottare per bilanciare efficacia operativa, controllo sui dati, costi e conformità normativa?

Proponiamo allora un’analisi comparativa strutturata di tre paradigmi dominanti: le soluzioni AI SaaS (Software-as-a-Service), le architetture RAG (Retrieval-Augmented Generation) e la distribuzione in sede, fornendo una tassonomia delle variabili decisionali e un quadro di riferimento di selezione orientato al profilo organizzativo.

Il problema della scelta architetturale

L’adozione dell’AI in contesti enterprise non è più una questione di “se” ma di “come”. La proliferazione di modelli fondazionali — GPT-4, Claude, Gemini, Llama, Mistral — ha abbassato drasticamente la soglia tecnica per l’integrazione di capacità di linguaggio naturale nei processi aziendali. Ma questa democratizzazione tecnologica non ha semplificato la decisione architetturale: l’ha resa più complessa, perché ha moltiplicato le opzioni disponibili senza fornire criteri di selezione consolidati.

La scelta tra SaaS, RAG e on-premise non è puramente tecnica. È una decisione che interseca strategia organizzativa, governance del dato, profilo di rischio e vincoli normativi. Un’azienda farmaceutica con dati di trial clinici, un’istituzione finanziaria soggetta a MiFID II, una startup SaaS b2b e un ente pubblico regionale hanno profili radicalmente diversi che rendono inappropriata qualsiasi raccomandazione universale.

I tre paradigmi: definizioni e architetture

Questo articolo propone un quadro di riferimento analitico per navigare questa complessità, esaminando sistematicamente ciascun paradigma lungo le dimensioni che più impattano la decisione enterprise: privacy e sovranità del dato, struttura dei costi, performance, scalabilità, personalizzazione e conformità normativa.

AI SaaS: il modello di consumo

Il paradigma SaaS rappresenta l’accesso alle capacità AI attraverso API esposte da fornitore cloud — OpenAI, Anthropic, Google, Cohere, Mistral AI — senza che l’organizzazione gestisca alcuna componente dell’infrastruttura di inferenza. L’azienda diventa consumatrice di un servizio cognitivo, pagando per unità lessicali processate o per chiamate API.

In pratica funziona come una telefonata: l’azienda invia la propria richiesta — con i dati necessari a elaborarla — ai server del provider, che elabora tutto e restituisce una risposta. I dati percorrono fisicamente la rete fino ai datacenter del fornitore (spesso all’estero) e lì vengono processati. Il modello non “ricorda” nulla da una sessione all’altra: ogni conversazione riparte da zero, senza alcuna memoria delle interazioni precedenti. La personalizzazione è possibile solo istruendo il modello all’inizio di ogni sessione (tramite un testo di sistema che gli dice come comportarsi) oppure, in alcuni servizi avanzati, attraverso un addestramento aggiuntivo su esempi forniti dall’azienda.

Il vantaggio principale è la velocità di adozione: un team di sviluppo mediamente competente può integrare un LLM in un’applicazione esistente in ore o giorni. Il costo di ingresso è marginale. Lo svantaggio strutturale è che i dati aziendali processati escono dal perimetro organizzativo, con implicazioni dirette per GDPR, segreto industriale e conformità settoriale.

RAG: il paradigma dell’augmentazione

Retrieval-Augmented Generation (RAG) — in italiano: “generazione aumentata dal recupero” — è un’architettura che combina due componenti distinti: un motore di ricerca interno all’azienda e un modello linguistico generativo. Il funzionamento ricorda quello di un esperto che, prima di rispondere, consulta i documenti pertinenti nella propria biblioteca. Quando l’utente formula una domanda, il sistema non si affida alla memoria del modello: cerca prima nei documenti aziendali — manuali, contratti, procedure, normative interne — i passaggi più rilevanti, li raccoglie e li “mostra” al modello come contesto; il modello costruisce poi la risposta sulla base di quel materiale verificato. La ricerca avviene per somiglianza semantica — il sistema trova i testi che trattano lo stesso argomento, non solo quelli che contengono le stesse parole esatte — grazie a una tecnica matematica che trasforma i testi in sequenze numeriche confrontabili tra loro (rappresentazioni vettoriali). Il modello generativo può risiedere sul cloud o sull’infrastruttura interna dell’azienda, a seconda dei requisiti di riservatezza.

Questo approccio risolve due debolezze strutturali dei modelli linguistici usati da soli. Il primo problema è quello delle allucinazioni: un modello senza accesso a documenti può “inventare” risposte plausibili ma false, perché genera testo basandosi su pattern statistici appresi durante l’addestramento, non su dati verificati. Con il RAG, ogni risposta è ancorata a fonti reali recuperate in tempo reale: se il documento non lo dice, il sistema non lo inventa. Il secondo problema è la conoscenza cristallizzata: un modello “sa” solo ciò che era presente nei dati con cui è stato addestrato, che possono risalire a mesi o anni fa. Con il RAG, la base documentale è separata dal modello e aggiornabile in qualsiasi momento: aggiungere oggi una nuova policy aziendale significa che il sistema la conoscerà immediatamente, senza dover riavviare nessun processo di addestramento. Il RAG permette inoltre di scegliere con precisione quali documenti esporre al modello e in quale forma, offrendo un controllo granulare sui dati che entrano nel processo di generazione.

Le implementazioni RAG variano considerevolmente in complessità. Un RAG di base recupera i documenti più simili alla domanda e li passa al modello: semplice ed efficace per molti casi aziendali. Un RAG avanzato aggiunge livelli di intelligenza ulteriori: riordina i risultati per rilevanza (ri-classificazione), scompone domande complesse in sotto-domande più semplici, esegue ricerche successive quando la prima non è sufficiente, e include filtri di sicurezza che controllano i documenti recuperati prima di consegnarli al modello. Il grado di sofisticazione da adottare dipende dalla complessità delle domande che il sistema dovrà gestire e dalla quantità di documentazione da coprire.

Il fattore più critico di un sistema RAG non è il modello linguistico scelto, ma la qualità della base documentale su cui si appoggia. Tre aspetti la determinano. Il primo è come i documenti vengono suddivisi prima di essere indicizzati: tagli troppo corti perdono il contesto, tagli troppo lunghi diluiscono il segnale rilevante. Il secondo è la tecnica con cui si converte il testo in rappresentazioni numeriche ricercabili: scelte diverse producono risultati di ricerca con qualità molto differente. Il terzo — spesso il più trascurato — è la governance editoriale: chi è responsabile di aggiornare i documenti, con quale frequenza, attraverso quale processo di validazione. Un sistema RAG alimentato da documenti obsoleti o contraddittori produce risposte obsolete o contraddittorie, indipendentemente dalla potenza del modello che le genera. In questo senso, il RAG trasforma la qualità documentale dell’organizzazione in un requisito operativo del sistema AI.

On-premise: la sovranità computazionale

La distribuzione on-premise — o nella variante cloud privato, su infrastruttura dedicata e fisicamente isolata — significa che l’organizzazione gestisce in autonomia l’intera catena tecnologica: i server con le schede grafiche specializzate (GPU o TPU) necessarie per eseguire i modelli, il sistema operativo, il software che ottimizza come il modello utilizza l’hardware, il modello stesso e l’applicazione che lo espone agli utenti. È l’equivalente di costruire e gestire la propria centrale elettrica invece di allacciarsi alla rete pubblica: massima indipendenza, massima responsabilità. La conseguenza più rilevante è che nessun dato esce mai dall’infrastruttura controllata dall’organizzazione.

I modelli tipicamente distribuiti on-premise appartengono alla categoria open-weight — modelli il cui “codice genetico” (i parametri) è pubblicamente disponibile e può essere installato su propria infrastruttura —: Llama 3.1 e 3.2, Mistral, Falcon, Gemma, Phi-3, DeepSeek. Questi modelli hanno capacità generali inferiori ai modelli di punta accessibili via cloud, ma diventano competitivi — e talvolta superiori — su compiti specializzati nel dominio dell’organizzazione, soprattutto quando combinati con un sistema RAG che li alimenta con documentazione interna ricca e aggiornata (compensando così il divario di capacità del modello base con la qualità del contesto fornito).

Il costo di ingresso è significativo. Eseguire un modello linguistico di grandi dimensioni (dell’ordine di 70 miliardi di parametri, una misura della sua complessità) richiede tipicamente da 4 a 8 schede grafiche professionali ad alte prestazioni — le stesse usate per applicazioni di calcolo scientifico — con un costo unitario compreso tra 30.000 e 80.000 euro ciascuna. A questo si aggiungono storage ad alta velocità, infrastruttura di rete, sistemi di raffreddamento dedicati e, soprattutto, le competenze del personale tecnico specializzato nella gestione di questi sistemi. Il Total Cost of Ownership diventa favorevole rispetto al SaaS solo a volumi di utilizzo elevati e su orizzonti temporali lunghi (18-36 mesi), rendendo questo paradigma appropriato principalmente per organizzazioni con carichi di lavoro stabili e voluminosi.

La scelta on-premise non è necessariamente motivata dalla performance: spesso è una scelta normativa obbligata. Settori come difesa, intelligence, sanità e servizi finanziari operano sotto regimi normativi che rendono strutturalmente impossibile il transito di certi dati verso infrastrutture terze, indipendentemente dalle garanzie contrattuali del fornitore.

Analisi comparativa: matrice multidimensionale

La tabella seguente sintetizza il confronto tra i tre paradigmi lungo le dimensioni più rilevanti per la decisione enterprise. Il sistema cromatico segnala: verde il vantaggio relativo, arancio la posizione intermedia, rosso lo svantaggio strutturale.

La matrice evidenzia una tensione strutturale tra controllo del dato e velocità operativa che non è risolvibile con l’ottimizzazione tecnica: è un trade-off intrinseco che riflette scelte di valore organizzativo. L’architettura RAG occupa la posizione di compromesso più flessibile, ma richiede competenze progettuali più sofisticate delle altre due opzioni.

Dimensioni Critiche per la Decisione Enterprise

La dimensione della privacy non è un attributo tecnico ma un vincolo regolamentare con conseguenze legali dirette. Il GDPR (Regolamento UE 2016/679) impone che il trattamento di dati personali sia fondato su una base giuridica valida e che i dati non vengano trasferiti a paesi terzi senza garanzie adeguate. L’uso di un LLM SaaS americano per processare dati personali di cittadini europei rientra in questa fattispecie e richiede, come minimo, la stipula di un Data Processing Agreement conforme e la verifica che il fornitore operi sotto meccanismi di trasferimento validi (Standard Contractual Clauses o equivalenti).

Ma il GDPR è solo il livello base. Organizzazioni nei settori bancario (DORA, MiFID II, PCI-DSS), sanitario (HIPAA negli USA, regolamenti nazionali EU), difesa (NIS2, certificazioni NATO), e settore pubblico (Cloud First Policy, qualificazioni ACN) operano sotto strati normativi addizionali che possono imporre requisiti di sovranità del dato non soddisfabili da fornitore cloud tradizionali.

L’architettura RAG offre un vantaggio parziale su questo fronte. Se il modello generativo risiede sul cloud ma la base documentale è locale, è possibile progettare il sistema in modo che al cloud vengano inviati solo i frammenti di testo già depurati da qualsiasi informazione personale o sensibile — mentre i dati originali restano all’interno del perimetro aziendale. È una strategia paragonabile all’inviare a un consulente esterno solo il sunto anonimizzato di un documento, senza mai consegnargli il file originale. Questa soluzione, nota come RAG rispettoso della privacy, richiede però un processo di anonimizzazione robusto e verifiche periodiche per assicurarsi che nessuna informazione sensibile attraversi il confine.

Struttura dei costi e costo totale di proprietà (TCO)

L’analisi economica dei tre paradigmi richiede una distinzione tra costo di ingresso, costo operativo e Total Cost of Ownership su orizzonte pluriennale. Questi tre valori hanno dinamiche molto diverse che rendono fuorviante qualsiasi confronto basato su un singolo metrico.

Per il SaaS: il costo di ingresso è quasi nullo (API key, qualche ora di sviluppo), ma il costo operativo scala linearmente con il volume di utilizzo e può diventare proibitivo ad alto carico. GPT-4o a 5 €/M unità lessicale di dato in ingresso e 15 €/M di risultato è accessibile per prototipi, ma a 50 milioni di unità lessicale/giorno il costo mensile supera rapidamente i 200.000 €.

Per il paradigma RAG ibrido: il costo include l’infrastruttura per l’archivio vettoriale (Pinecone, Weaviate, pgvector), il processo di indicizzazione, il monitoring del sistema e le competenze di ingegneria per il design e la manutenzione. A questi si sommano i costi del modello generativo (cloud o on-premise). Il totale è tipicamente superiore al SaaS puro nella fase iniziale, ma scala meglio per volumi elevati.

Per l’on-premise: l’investimento in hardware è la voce dominante nelle prime fasi. Un impianto di quattro schede grafiche ad alte prestazioni (H100 80GB) — la configurazione minima per eseguire un modello da 70 miliardi di parametri — richiede tra 300.000 e 400.000 euro di sola componentistica, ai quali si sommano tra 180.000 e 240.000 euro l’anno di costo del personale tecnico specializzato. Il punto di pareggio economico rispetto al SaaS si raggiunge tipicamente tra i 18 e i 36 mesi, a condizione che il sistema sia usato in modo continuativo e ad alto volume.

La decisione economicamente corretta richiede una proiezione realistica del volume di utilizzo nei 3 anni successivi, con scenari ottimistici e pessimistici. Organizzazioni che sovrastimano l’adozione rischiano di sostenere costi fissi insostenibili con l’on-premise; organizzazioni che sottostimano la crescita rischiano dipendenza dal fornitore e costi esplosivi con SaaS.

Personalizzazione e accuratezza dominio-specifica

Un tema spesso trascurato nella valutazione è che i modelli frontier SaaS eccellono in task generali ma non necessariamente in task altamente specifici di dominio. Un LLM addestrato sulla distribuzione generale del testo web ha una rappresentazione debole di terminologia medica rara, giurisprudenza nazionale, procedure interne aziendali, o linguaggio tecnico di settore non documentato online.

L’architettura RAG mitiga questo problema fornendo al modello contesto documentale specifico al momento dell’inferenza. Se la base di conoscenza è ben curata e il retrieval è accurato, il modello può rispondere correttamente a interrogazione su processi interni, normative specifiche, prodotti proprietari — anche senza averli visti in addestramento. Questa è la ragione principale per cui il RAG supera il SaaS puro per applicazioni enterprise con forte componente di conoscenza istituzionale.

L’addestramento aggiuntivo su modelli open-weight per distribuzione locale rappresenta la forma di personalizzazione più profonda: il modello non riceve solo documenti come contesto, ma modifica strutturalmente i propri parametri interni assorbendo i pattern del dominio aziendale. Il risultato è un modello che “pensa” con il lessico, le convenzioni e le logiche specifiche dell’organizzazione. Il rovescio della medaglia è triplice: servono migliaia di esempi di buona qualità per addestrare il modello, servono competenze tecniche specializzate per condurre il processo correttamente, e si rischia la cosiddetta “dimenticanza catastrofica” (catastrophic forgetting) — il fenomeno per cui un modello, specializzandosi su un dominio, perde progressivamente le capacità generali acquisite in fase di pre-addestramento, come se uno specialista dimenticasse le nozioni di base imparate all’università. Questa tecnica è appropriata per compiti molto specifici e stabili nel tempo, non per esigenze di uso generale.

Scalabilità e resilienza operativa

La scalabilità ha due dimensioni distinte che vengono spesso confuse. La prima è la capacità di reggere i picchi di traffico: cosa succede quando mille utenti usano il sistema contemporaneamente invece di dieci? La seconda è la capacità di espandersi verso nuovi ambiti: il sistema che oggi risponde su normative fiscali può essere esteso domani a gestire anche le procedure HR? Le tre architetture hanno profili molto diversi su entrambe le dimensioni.

Il SaaS scala verticalmente in modo quasi illimitato — l’infrastruttura del fornitore assorbe i picchi — ma scala orizzontalmente con difficoltà: ogni nuovo caso d’uso richiede istruzione engineering separato, e la mancanza di memoria persistente rende complessa la costruzione di esperienze coerenti nel tempo.

Il RAG scala verticalmente attraverso la scalabilità dell’archivio vettoriale e del layer di retrieval, e orizzontalmente attraverso l’aggiunta di nuove collezioni documentali. La complessità cresce con il numero di domini gestiti, ma in modo più controllabile rispetto all’on-premise puro.

L’on-premise è il più vincolato sulla scalabilità verticale (richiede aggiunta di hardware GPU con lead time di settimane o mesi) ma il più flessibile sulla personalizzazione orizzontale, potendo ospitare modelli specializzati per domini diversi senza dipendenze esterne.

Architetture ibride: verso la composizione multi-paradigma

La dicotomia tra i tre paradigmi è concettualmente utile per l’analisi, ma le organizzazioni mature tendono a convergere verso architetture ibride che combinano elementi di tutti e tre in base al profilo di rischio e al tipo di dati dei singoli carichi di lavoro.

Un’architettura ibrida tipica può prevedere: un LLM SaaS infrastruttura cloud per task generali e non sensibili (redazione email, sintesi di contenuti pubblici, assistenza a developer con codice non proprietario); un layer RAG con archivio vettoriale locale e modello infrastruttura cloud per caso d’uso che richiedono base di conoscenza interna ma non elaborano dati personali; una distribuzione locale completo per carico di lavoro ad alto contenuto regolamentare (contratti, dati sanitari, codice sorgente proprietario).

Questa stratificazione richiede una governance centralizzata della classificazione dei dati: ogni dato che entra nei sistemi AI deve essere etichettato con il suo livello di sensibilità, e il sistema deve instradare le richieste verso il layer architetturale appropriato. Senza questo layer di governance, l’architettura ibrida diventa un vettore di rischio piuttosto che uno strumento di mitigazione.

Il concetto di AI Gateway emerge in questo contesto come componente critico: un livello intermedio — un “controllore del traffico” — che si interpone tra gli utenti e tutti i sistemi AI dell’organizzazione. Il suo compito è instradare ogni richiesta verso il sistema appropriato in base alla sensibilità dei dati coinvolti (SaaS per dati non sensibili, on-premise per dati riservati), registrare tutte le interazioni per le verifiche di conformità normativa, applicare filtri di sicurezza sui contenuti, e garantire la continuità del servizio se un fornitore diventa temporaneamente non disponibile. Soluzioni commerciali come LiteLLM, PortKey e Kong AI Gateway rispondono a questa esigenza con diversi livelli di sofisticazione.

Framework di selezione: decision matrix

La scelta del paradigma di distribuzione è un problema multi-criteria che dipende da variabili organizzative, normative e tecniche. La matrice seguente sintetizza le raccomandazioni per profili organizzativi tipici.

La matrice è una semplificazione necessaria: le organizzazioni reali raramente corrispondono a un singolo profilo. Un’azienda farmaceutica di grandi dimensioni ha simultaneamente caratteristiche del profilo “regolamentato” per i dati di trial clinici e del profilo “enterprise con base di conoscenza” per la documentazione scientifica e regolatoria. La risposta corretta in questi casi è sempre l’architettura ibrida stratificata per sensibilità del dato.

Criteri di priorità per la valutazione

Per guidare la valutazione in contesti organizzativi complessi, si propone il seguente ordine di priorità dei criteri:

• Innanzitutto, i vincoli normativi. La conformità è non negoziabile e deve essere il primo filtro. Se un paradigma non soddisfa i requisiti regolamentari applicabili, esce dalla valutazione indipendentemente da tutti gli altri fattori.
• Poi il profilo dei dati. Classificare i dati che l’applicazione AI dovrà processare: personali, sanitari, finanziari, segreti industriali, pubblici. Questa classificazione determina i vincoli sulla residenza del dato.
• Successivamente il volume e la prevedibilità del carico. Il modello economico corretto dipende in modo critico da questa variabile. Carichi imprevedibili favoriscono il SaaS; carichi stabili e voluminosi favoriscono l’on-premise.
• Quindi la specificità del dominio. Più l’applicazione richiede conoscenza istituzionale proprietaria, più il RAG è appropriato rispetto al SaaS puro.
• Infine, le competenze disponibili. Il RAG e l’on-premise richiedono competenze di ML engineering e operazioni ML che molte organizzazioni non hanno internamente. Sottovalutare questo fattore è la causa più frequente di fallimento dei progetti AI enterprise.

Tendenze emergenti e dinamiche evolutive

La ricerca sta rendendo i modelli AI progressivamente più leggeri, attraverso due tecniche complementari.

Compressed models e democratizzazione dell’on-premise

La quantizzazione riduce la precisione numerica con cui il modello memorizza i propri parametri interni — un po’ come convertire un file audio da qualità studio a qualità MP3: si perde qualcosa, ma il file diventa molto più piccolo e gestibile. La distillazione “comprime” un modello grande in uno più piccolo che ne imita il comportamento, come produrre un manuale essenziale da un’enciclopedia. Il risultato pratico è che modelli un tempo richiedenti server da centinaia di migliaia di euro girano oggi su hardware ordinario: Phi-3-mini e Gemma 2 (modelli da 2-4 miliardi di parametri con quantizzazione avanzata) funzionano persino su laptop di fascia alta. Questo apre la strada a scenari di distribuzione periferica — AI che gira direttamente sui dispositivi locali dell’organizzazione senza connessione a server esterni. La frontiera si sta spostando verso modelli da 7 a 13 miliardi di parametri che, con un addestramento aggiuntivo sul dominio specifico, raggiungono prestazioni competitive con modelli molto più grandi su compiti specializzati.

Agentic Frameworks e Complessità Architetturale

I sistemi AI stanno evolvendo da assistenti che rispondono a domande singole verso agenti autonomi capaci di eseguire sequenze di azioni complesse nel tempo: prenotare una riunione, leggere un documento, aggiornare un database, inviare una notifica — tutto in autonomia, senza intervento umano a ogni passaggio. Questo tipo di sistema — detto “agentico” — richiede che il modello abbia una memoria persistente di ciò che ha fatto, possa usare strumenti software esterni, e sia coordinato con altri agenti specializzati che lavorano in parallelo. Queste caratteristiche sono difficili da garantire con architetture SaaS pure, dove ogni chiamata al modello è indipendente e senza memoria, e spingono verso soluzioni ibride o on-premise dove il controllo sull’intera catena di esecuzione è completo. Piattaforme come LangGraph, AutoGen e CrewAI sono i principali strumenti con cui oggi si costruiscono questi sistemi.

Evoluzione Regolamentare: EU AI Act

L’EU AI Act, in vigore dall’agosto 2024 con applicazione progressiva fino al 2026, introduce una classificazione dei sistemi AI per livello di rischio con obblighi di trasparenza, testing e conformità per i sistemi ad alto rischio. Le applicazioni enterprise nei settori di occupazione (screening candidati), credito (scoring), sanità e servizi essenziali rientrano nella categoria ad alto rischio e richiedono documentazione tecnica, testing su bias, e registrazione in database EU. Questo quadro di riferimento regolamentare aggiunge ulteriore pressione verso soluzioni che garantiscono audit e controllo, tipicamente on-premise o RAG con tracciabilità completa.

Conclusioni

L’analisi comparativa evidenzia che non esiste un paradigma di distribuzione universalmente ottimale per l’AI enterprise. Ogni architettura rappresenta un punto specifico in uno spazio di trade-off multidimensionale, e la decisione corretta dipende dal profilo di rischio, dai vincoli normativi, dal volume di utilizzo e dalle competenze disponibili dell’organizzazione.

Il SaaS rimane il punto di partenza naturale per organizzazioni che vogliono esplorare rapidamente le capacità AI senza investimenti iniziali, ma diventa strutturalmente inadeguato per organizzazioni con requisiti seri di privacy o con carichi di utilizzo elevati. Il RAG è la soluzione più versatile per applicazioni enterprise che richiedono conoscenza istituzionale, offrendo un bilanciamento ragionevole tra personalizzazione e controllo del dato. L’on-premise rimane la scelta obbligata per organizzazioni sotto regimi normativi stringenti, con il costo della sovranità totale che si traduce in investimento significativo e complessità operativa.

La tendenza che emerge con maggiore chiarezza è la convergenza verso architetture ibride stratificate per sensibilità del dato: un unico paradigma per tutta l’organizzazione è raramente ottimale, mentre la composizione di layer architetturali diversi — governati da policy di classificazione dei dati e orchestrati da AI gateway — permette di ottimizzare il trade-off per ciascun carico di lavoro specifico.

La domanda più importante non è “quale architettura AI adottare?” ma “come costruire la governance dei dati che permette di adottare l’architettura giusta per ogni caso d’uso?”. L’AI strategy è inseparabile dalla data strategy.

Riferimenti e Risorse

Lewis, P. et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. NeurIPS 2020.

Gao, Y. et al. (2023). Retrieval-Augmented Generation for Large Language Models: A Survey. arXiv:2312.10997.

Periferico, D. et al. (2024). From Local to Global: A Graph RAG Approach to Interrogazione-Focused Summarization. arXiv:2404.16130. [Microsoft Research]

European Parliament (2024). Regulation (EU) 2024/1689 — Artificial Intelligence Act. Official Journal of the European Union.

NIST (2023). Artificial Intelligence Risk Management Quadro di riferimento (AI RMF 1.0). National Institute of Standards and Technology.

Bommasani, R. et al. (2021). On the Opportunities and Risks of Foundation Models. Stanford CRFM. arXiv:2108.07258.

Hu, E. et al. (2022). LoRA: Low-Rank Adaptation of Large Language Models. ICLR 2022.

Dettmers, T. et al. (2023). QLoRA: Efficient Finetuning of Quantized LLMs. NeurIPS 2023.