Registrazione e conservazione: guida pratica per i team SaaS

Nell'AI Act, registrazione e conservazione sono controlli di tracciabilità, non un invito a raccogliere per sempre ogni dato possibile. Per i sistemi di IA ad alto rischio, l'articolo 12 richiede la registrazione automatica degli eventi per l'intero ciclo di vita. Fornitori e deployer devono conservare i log generati automaticamente sotto il loro controllo per un periodo adeguato alla finalità e, in genere, almeno sei mesi, salvo diversa norma applicabile.

Gli obblighi non si applicano automaticamente a ogni funzione IA o azienda SaaS. Occorre identificare il sistema, la finalità, il proprio ruolo e la classificazione, distinguendo i log controllati dal fornitore da quelli controllati dal cliente o da un vendor a monte. L'obiettivo è una catena di prove proporzionata che consenta a un revisore autorizzato di collegare un evento rilevante alla versione, al contesto di input/output, all'azione umana, al controllo e alla decisione.

Anche prima dell'applicazione delle norme ad alto rischio, la disciplina aiuta nelle indagini, nel monitoraggio di sicurezza, nelle risposte ai clienti, nel change management e nelle decisioni di prodotto. Non serve sorveglianza indiscriminata, ma logging progettato con finalità, accessi, trigger e limiti.

Partire dall'ambito, non dalla piattaforma

Documentate funzione, modelli e servizi terzi, finalità, utenti, persone interessate, input, output, integrazioni, ambienti e decisioni influenzate. Registrare soltanto la chiamata all'API del foundation model può escludere dati di retrieval, regole di business, override o azioni successive che compongono il flusso SaaS.

Determinate poi il ruolo. Chi sviluppa o commercializza a proprio nome un sistema ad alto rischio può essere fornitore; il cliente che usa il sistema altrui può essere deployer. Rebranding, modifiche sostanziali o nuova finalità possono spostare le responsabilità. Le etichette contrattuali non bastano.

Valutate infine la classificazione. L'articolo 6 copre sistemi collegati ai prodotti dell'allegato I e casi dell'allegato III, con condizioni ed esclusioni. Classificare candidati richiede un'analisi diversa da redigere testi marketing interni. Registrate motivazione, revisore, data, ipotesi e trigger. Per il contesto, leggete come l'AI governance cambia le aspettative di compliance.

Cosa richiede l'AI Act

Secondo l'AI Act, l'articolo 12 impone ai sistemi ad alto rischio la registrazione automatica degli eventi durante il ciclo di vita. Le funzioni devono garantire tracciabilità adeguata, aiutare a individuare rischi o modifiche sostanziali, supportare il monitoraggio post-commercializzazione e consentire ai deployer di controllare il funzionamento.

Gli eventi dipendono dal sistema. Per alcuni sistemi di identificazione biometrica remota dell'allegato III, l'articolo 12 indica dati minimi aggiuntivi. Copiare tale schema in un prodotto diverso non dimostra conformità: gli eventi devono derivare da finalità, rischi, limiti prestazionali, supervisione umana, istruzioni e piano di monitoraggio.

L'articolo 19 impone ai fornitori di conservare i log automatici sotto il loro controllo per un periodo adeguato di almeno sei mesi, salvo diversa disposizione del diritto UE o nazionale, soprattutto sulla protezione dei dati. L'articolo 26 prevede un minimo parallelo per i deployer. Il minimo non autorizza quindi la conservazione illimitata: il piano deve conciliare tracciabilità, minimizzazione, limitazione, sicurezza, diritto del lavoro, regole settoriali, contratti e incidenti.

Dopo il regolamento (UE) 2026/1744, i requisiti si applicano dal 2 dicembre 2027 ai sistemi dell'allegato III e dal 2 agosto 2028 ai sistemi inseriti nei prodotti regolamentati dell'allegato I. Il calendario della Commissione riporta tali date.

Cosa registrare

Un evento utile risponde a una domanda di revisione, non prova solo che un server funzionava:

1. Sistema e versione: identificatore, modello o componente, configurazione, ambiente e release.
2. Tempo e correlazione: timestamp affidabile, ID di richiesta o transazione e collegamenti tra eventi.
3. Contesto operativo: funzione, flusso previsto, ruolo dell'utente o servizio e impostazioni rilevanti.
4. Input e output: riferimenti, hash, sintesi o snapshot protetti sufficienti alla ricostruzione giustificata.
5. Supervisione umana: revisione, approvazione, rifiuto, override, escalation e autorità.
6. Controlli: policy, soglie, filtri, accessi, errori, fallback ed esito.
7. Modifiche e monitoraggio: deployment, variazioni di modello o dati, drift, incidenti, reclami e correzioni.
8. Integrità: origine, storico accessi, conservazione, trasformazione o cancellazione.

Non memorizzate automaticamente prompt, documenti, risposte o identità completi. Talvolta il contenuto è necessario a indagare un danno; altrove bastano un identificatore pseudonimo, hash, categoria, metrica o campione protetto. Decidete campo per campo secondo finalità e rischi documentati.

Flusso operativo

1. Formalizzare la decisione

Per ogni sistema registrate ambito, finalità, ruolo, classificazione, obblighi, obiettivi, categorie e responsabili. Distinguete log aziendali da quelli dipendenti da vendor o clienti. Annotate ipotesi e trigger.

2. Collegare domande ed eventi

Partite dalle domande: quale versione ha prodotto il risultato? La revisione umana era necessaria ed è avvenuta? Si è attivato un controllo? L'uso rispettava la finalità? Cosa è cambiato prima del peggioramento? Associate i campi minimi affidabili e la fonte.

3. Assegnare responsabilità

Engineering gestisce in genere strumentazione e qualità; security accesso, integrità, allarmi e preservazione; product flusso e release; data/ML identificatori di modelli, dataset e valutazioni; privacy liceità e minimizzazione; compliance mappa dei requisiti. Un owner coordina senza inventare fatti altrui.

4. Definire accesso e conservazione

Separate accesso operativo e investigativo. Usate privilegio minimo, autenticazione, log degli accessi, cifratura e controlli di esportazione. Definite inizio, cancellazione, eccezioni, hold e backup, oltre alle responsabilità tra fornitore e deployer.

5. Collegare le revisioni ai trigger

Riesaminate dopo cambi rilevanti a modello, prompt, retrieval, soglia, dati, integrazione, finalità o supervisione, nonché dopo incidenti, reclami, prestazioni anomale, uso illecito o avvisi del vendor. Collegate l'esito alla versione in produzione.

6. Testare ricostruzione e cancellazione

Fate ricostruire a un revisore versione, controlli, azioni umane e follow-up di un evento. Verificate poi la cancellazione da storage principale, analytics, export e backup. Entrambe richiedono evidenze.

Errori comuni

Registrare tutto. Aumenta rischi privacy, sicurezza, contenzioso e costi senza assicurare tracciabilità.

Confondere telemetria e audit trail IA. Uptime ed errori raramente identificano modello, configurazione, supervisione e prova di un risultato.

Applicare sei mesi a ogni record. Il minimo riguarda i log automatici di alto rischio sotto controllo dell'operatore ed è soggetto ad altre leggi.

Ignorare i confini di controllo. Il fornitore non conserva log mai ricevuti; il deployer non deve presumere che il vendor mantenga il suo contesto.

Raccogliere contenuti sensibili senza tutele. Prompt e output possono contenere dati personali o segreti. Minimizzate, separate, cifrate e controllate.

Conservare eventi non interpretabili. Senza schema, tempo, versione o correlazione possono essere inutili.

Esempio: selezione del personale assistita dall'IA

Un fornitore SaaS classifica candidature. Documenta finalità, confini, ruolo e classificazione. Gli eventi collegano modello e configurazione di produzione a ogni ranking, riferimenti di input, output e contesto, soglie, avvisi, revisioni umane, override e azione finale.

L'accesso ai contenuti è limitato alle indagini autorizzate; il monitoraggio ordinario usa dati aggregati ove possibile. La decisione di conservazione spiega articolo 19, vincoli sui dati, responsabilità del cliente e periodi settoriali. Cambiare modello, soglia o revisione attiva una valutazione e mantiene il legame tra vecchie e nuove prove.

Il disegno non garantisce da solo la conformità, ma permette di verificare funzionamento, supervisione umana e risposta responsabile a cambi e incidenti.

FAQ

Qual è lo scopo pratico?

Rendere tracciabile l'attività rilevante collegando evento, versione, contesto, controlli, azioni umane e follow-up senza dati estranei.

Quando si applicano gli obblighi ai team SaaS?

Gli articoli 12, 19 e 26 riguardano sistemi ad alto rischio e ripartiscono i requisiti secondo ruolo e controllo. Confermate sistema, finalità, classificazione e ruolo.

Occorre conservare ogni prompt e risposta?

No. Serve tracciabilità adeguata, non conservazione indiscriminata. Scegliete i campi necessari e proteggeteli.

Per quanto tempo conservare i log?

In genere i log automatici sotto controllo di fornitori o deployer vanno conservati per un periodo adeguato di almeno sei mesi. Altre leggi possono imporre o limitare una durata diversa.

Da dove iniziare?

Inventariate sistema, ruolo, classificazione, fonti e domande, poi definite schema minimo, responsabilità, accesso, conservazione, trigger e test di ricostruzione.

Fonti

• Regolamento (UE) 2024/1689, in particolare articoli 6, 12, 19 e 26.
• Regolamento (UE) 2026/1744 e date modificate.
• Commissione europea, “AI Act”, calendario e obblighi ad alto rischio.