Quando si applicano registrazione e conservazione e cosa fare dopo

Logging e conservazione non si applicano allo stesso modo a ogni funzione SaaS. Gli articoli 12, 19 e 26 dell'AI Act riguardano i sistemi di IA ad alto rischio e dipendono dal ruolo di provider o deployer e dai log sotto il controllo dell'organizzazione. Altri sistemi possono richiedere registri per sicurezza, privacy, contratti, qualità o incidenti, ma queste finalità non vanno confuse con gli obblighi ad alto rischio.

Si parte quindi dall'ambito, non dallo strumento: sistema, finalità prevista, workflow, ruolo, classificazione e domande probatorie. Solo dopo si registrano eventi e decisioni necessari a tracciabilità, monitoraggio, supervisione e indagini, con protezioni, tempi giustificati e un test di ricostruzione.

Cosa richiede l'AI Act

L'articolo 12 richiede che i sistemi ad alto rischio consentano tecnicamente la registrazione automatica degli eventi durante il ciclo di vita. Deve sostenere una tracciabilità adeguata alla finalità, rilevare rischi o modifiche sostanziali, facilitare il monitoraggio post-commercializzazione e il controllo operativo del deployer.

È un requisito di progettazione del provider. L'articolo 19 impone al provider di conservare i log automatici sotto il suo controllo; l'articolo 26 fa lo stesso per il deployer. Il minimo generale è sei mesi, salvo diversa norma applicabile, e il periodo deve essere adeguato alla finalità. Separatamente, determinati documenti tecnici, di qualità e conformità devono essere conservati dal provider per dieci anni.

Non esiste uno schema universale: l'articolo 12 specifica dettagli per alcuni sistemi biometrici remoti, mentre negli altri casi il disegno deve essere proporzionato. La guida all'AI Act per provider SaaS tratta ruoli e classificazione.

Quando si applicano gli obblighi specifici

Verificare quattro elementi: se la funzione rientra nella definizione di sistema IA; se è ad alto rischio ai sensi dell'articolo 6 e degli allegati I o III; quale ruolo ricopre l'impresa; quali log controlla davvero. Regole convenzionali e automazioni non diventano IA solo perché elaborano dati. La classificazione dipende dalla finalità effettiva e dalle eccezioni applicabili.

Un'impresa che sviluppa e commercializza con il proprio nome può essere provider; chi usa il sistema di un terzo sotto la propria autorità può essere deployer. Ruoli, finalità, branding e modifiche sostanziali possono cambiare nel tempo. Il provider può controllare eventi del modello e dell'applicazione, mentre il cliente controlla decisioni umane e azioni a valle.

La riforma del 2026 ha fissato l'applicazione al 2 dicembre 2027 per articolo 6(2) e allegato III, e al 2 agosto 2028 per articolo 6(1) e allegato I. Il tempo va usato per progettare: prove storiche mancanti non si possono ricreare.

Quando servono comunque altri registri

Fuori dall'alto rischio possono servire eventi di autenticazione, configurazione e incidenti; prove di consenso, accesso o cancellazione; cronologie di servizio e modifica; versioni, valutazioni, approvazioni e rollback. Indicare sempre la finalità giuridica, contrattuale, di sicurezza o operativa reale.

“Non alto rischio” non significa “non conservare nulla”; allo stesso tempo, l'AI Act non giustifica l'accumulo illimitato di prompt, documenti, output e identità. Per alcune domande bastano identificatore, riferimento protetto, hash, risultato strutturato o campione.

Workflow operativo

1. Documentare finalità, utenti, persone interessate, decisione, input, output, ambienti, integrazioni, modelli, fonti, azioni a valle e revisione umana.
2. Registrare ruolo, classificazione, fatti, revisore, approvazione, incertezze e trigger di rivalutazione. Per fornitori terzi usare le domande prima di adottare strumenti IA interni.
3. Definire le domande: quale versione ha prodotto l'output, quali fonti e controlli sono stati usati, se vi è stata revisione umana e quale azione è seguita.
4. Collegare ogni domanda ai record minimi: identificatore, timestamp affidabile, versioni, contesto, riferimenti, risultato dei controlli, azione umana, esito e integrità.
5. Nominare un owner complessivo e owner per strumentazione, accesso, privacy, richieste, eccezioni, cancellazione e rimedio. Applicare autenticazione, cifratura, limitazioni di export, monitoraggio e accesso d'emergenza.
6. Definire tempi per classe e testare separatamente ricostruzione e cancellazione in produzione, analytics, export, archivi e backup applicabili.

Errori da evitare e prossimi passi

La telemetria ordinaria non è automaticamente un audit trail: disponibilità e latenza raramente spiegano configurazione, controlli e azioni umane. Nessuna parte controlla necessariamente l'intera catena; contratti, documentazione e configurazione reale devono coincidere. Non applicare sei mesi a tutto e non progettare solo per l'audit. Rivalutare con release, cambi di fornitore, rischi e incidenti. Vedere gli errori comuni di registrazione e conservazione.

Scegliere ora un workflow importante, creare una scheda con confine, finalità, ruolo, classificazione, fonti, domande, owner e trigger, quindi collegare da cinque a dieci domande ai record minimi. Un test indipendente prima della prossima release mostrerà se la prova è connessa e affidabile. Questo approccio segue le nuove aspettative di AI governance e i controlli richiesti dai buyer.

FAQ

Si applica a ogni funzione IA?

No. Gli articoli qui discussi riguardano sistemi ad alto rischio; altri obblighi possono comunque giustificare registri.

Provider e deployer conservano gli stessi log?

Non necessariamente. Ognuno conserva i log automatici pertinenti sotto il proprio controllo.

Sei mesi sono sempre corretti?

No. Sono il minimo generale per i log ad alto rischio interessati, salvo altra legge. Altre classi possono avere tempi diversi.

Fonti

• Regolamento (UE) 2024/1689, articoli 12, 18, 19 e 26.
• Regolamento (UE) 2026/1744 sulle nuove date.
• Commissione europea, “AI Act”, calendario corrente.