Un sistema RAG rientra nell’AI Act?

Tre punti di aggancio decidono quasi ogni questione pratica. Il primo è se ciò che hai è un sistema di AI secondo la definizione del Regolamento — un sistema automatizzato che deduce, dall’input ricevuto, come generare output quali previsioni, contenuti o raccomandazioni. Una pipeline di retrieval il cui ultimo passo è un modello linguistico che produce testo rientra in quella definizione senza molte discussioni.

Il secondo è la finalità prevista. Gli obblighi più pesanti sono riservati agli usi elencati come ad alto rischio, e questi sono descritti da ciò che il sistema decide sulle persone — accesso al lavoro, merito creditizio, servizi essenziali e simili — oppure dal suo ruolo di componente di sicurezza in un prodotto regolamentato. Un assistente che risponde a “quale versione di questa circolare è in vigore” per un professionista che poi decide è un oggetto molto diverso da uno che assegna un punteggio a un candidato, anche se il codice è quasi identico.

Il terzo è il ruolo. Fornitore e deployer hanno obblighi diversi, e spesso un’organizzazione li ricopre entrambi contemporaneamente: fornitore dell’assistente che ha costruito, deployer dello stesso assistente nella propria operatività e, a monte, cliente di un fornitore di modelli per finalità generali. I ruoli possono anche cambiare — mettere il proprio nome su un sistema, o modificarne la finalità prevista, può renderti il suo fornitore.

Nel caso non ad alto rischio, che riguarda la maggior parte degli assistenti interni sulla conoscenza aziendale, i requisiti pratici sono più leggeri di quanto il dibattito lasci intendere, ma non sono zero. Gli obblighi di trasparenza si applicano quando le persone interagiscono con un sistema di AI o quando vengono generati contenuti — un utente non deve doverlo indovinare. Le aspettative di alfabetizzazione in materia di AI si applicano a chi lo gestisce. E nulla nell’AI Act sostituisce il GDPR: se nell’indice ci sono dati personali, si tratta di un trattamento con una base giuridica, un periodo di conservazione e un interessato che ha diritti su quei dati.

Nel caso ad alto rischio, l’architettura è il lavoro di conformità. Gestione del rischio, governance dei dati di addestramento e di input, documentazione tecnica, registrazione degli eventi, sorveglianza umana e monitoraggio successivo all’immissione sul mercato sono tutte proprietà che un sistema o possiede per costruzione o non possiede affatto. Aggiungere a posteriori un log di audit a un sistema che non è stato costruito per tenerne uno significa, nei fatti, ricostruirlo — ed è per questo che la domanda sulla classificazione va posta all’inizio di un progetto e non alla fine.

Il retrieval sposta il punto in cui sta il rischio. Un modello che allucina è un problema noto; un livello di retrieval che restituisce con sicurezza un documento superato è un problema peggiore, perché l’output è ben formato, ha le sue fonti ed è sbagliato in un modo che sembra giusto. I sistemi in ambienti regolati devono quindi saper dire non solo cosa hanno risposto, ma su quale versione di quale documento si basava la risposta, e se quella versione era in vigore alla data della domanda.

Il secondo aspetto specifico del RAG è l’indice stesso. Qualunque sia la classificazione, un indice costruito su documenti che nessuno ha filtrato è un problema di protezione dei dati prima ancora di essere un problema di AI. Il controllo più economico di tutto questo campo è escludere i dati personali in fase di ingestion, invece di cercare di sopprimerli al momento della risposta — è la scelta di progetto alla base del deployment per Federfarma, dove i dati personali non vengono mai indicizzati.

Il terzo è la sostituzione del modello. Se il passo di generazione è un endpoint esterno, un cambio del modello dietro di esso cambia il comportamento del tuo sistema. Qualunque sia la tua classificazione, devi sapere quale modello ha risposto, quando e con quale configurazione — un requisito architetturale ben prima che normativo.

Non ti dice qual è la tua classificazione. Dipende dalla finalità prevista che dichiari effettivamente, dal settore in cui operi, dal contesto di deployment e, per alcuni settori, dalla normativa di prodotto che si affianca all’AI Act. Si stabilisce con le procedure previste dal Regolamento, non con il parere di un consulente e non con una topologia di deployment.

Una cosa va detta chiaramente: nessuno può certificare la tua conformità in una frase, e un fornitore che si offre di farlo ti sta dicendo qualcosa su di sé. Il deliverable che ha valore è una dichiarazione firmata di cosa hai, cosa ti manca e in quale ordine colmare il divario — con l’architettura descritta con una precisione sufficiente perché i tuoi legali possano lavorarci.