AI Act e obblighi di record-keeping: guida pratica per le imprese<\/h1><\/h1><\/div><\/div><\/div><\/div><\/div>\nIl Regolamento UE 2024\/1689 (AI Act) \u00e8 il primo atto legislativo al mondo dedicato interamente all\u2019intelligenza artificiale. Per le aziende che sviluppano o utilizzano sistemi AI classificati ad alto rischio, la piena applicazione scatta ad agosto 2026 e porta con s\u00e9 obblighi operativi concreti. Tra questi, l\u2019Art. 12 impone la registrazione automatica degli eventi (record-keeping) per l\u2019intero ciclo di vita del sistema. Il problema: il testo normativo \u00e8 preciso negli obiettivi, ma vago sulle modalit\u00e0 operative. Quali eventi registrare? In che formato? Con quali garanzie di integrit\u00e0? Come affrontato nella guida sulla certificazione dei dati per agenti AI e governance<\/a>, la risposta si articola su tre livelli: logging automatico conforme all\u2019Art. 12, conservazione per almeno sei mesi e, per chi vuole andare oltre il minimo normativo, certificazione con valore legale dei log, che trasforma ogni registrazione in una prova opponibile a terzi.<\/p>\nQuesto approfondimento fa parte della guida: Certificazione dei dati per agenti AI: governance e compliance<\/a><\/strong><\/p>\nCosa impone l\u2019Art. 12 dell\u2019AI Act in materia di record-keeping<\/h2>\n
L\u2019Art. 12 del regolamento europeo sull\u2019intelligenza artificiale stabilisce che ogni sistema AI classificato ad alto rischio deve essere progettato con capacit\u00e0 di logging automatico degli eventi, imponendo di fatto un obbligo di record-keeping strutturato per l\u2019intero ciclo di vita del sistema. I log devono consentire di tracciare il funzionamento dalla messa in servizio alla dismissione, garantendo la tracciabilit\u00e0 di ogni decisione algoritmica. Le finalit\u00e0 sono definite dall\u2019Art. 12, paragrafo 2: identificare situazioni di rischio ai sensi dell\u2019Art. 79<\/a>, facilitare il monitoraggio post-commercializzazione previsto dall\u2019Art. 72<\/a>, monitorare le prestazioni operative secondo l\u2019Art. 26, paragrafo 5. La registrazione non \u00e8 facoltativa e non \u00e8 delegabile a processi manuali: \u00e8 il sistema stesso a dover generare i log, senza intervento dell\u2019operatore. Secondo i dati della Commissione Europea<\/a>, i sistemi ad alto rischio rappresentano una quota minoritaria ma ad alta criticit\u00e0 del mercato AI europeo.<\/p>\n\nArt. 12, paragrafo 2, Regolamento UE 2024\/1689:<\/strong> \u201cI sistemi di IA ad alto rischio consentono tecnicamente la registrazione automatica degli eventi (log) per la durata del ciclo di vita del sistema.\u201d I log devono assolvere tre finalita\u2019 regolamentari: identificazione dei rischi ai sensi dell\u2019Art. 79, monitoraggio post-commercializzazione ai sensi dell\u2019Art. 72 e sorveglianza operativa ai sensi dell\u2019Art. 26(5).<\/p>\n<\/blockquote>\nQuali eventi registrare e per quanto tempo<\/h3>\n
I deployer di sistemi AI ad alto rischio devono conservare i log generati automaticamente per almeno sei mesi dalla data di generazione, come previsto dall\u2019Art. 26, paragrafo 6, del Regolamento UE 2024\/1689. Il periodo minimo decorre dal momento in cui ciascun log viene prodotto dal sistema e pu\u00f2 essere esteso da normative settoriali applicabili: il GDPR<\/a>, ad esempio, pu\u00f2 imporre vincoli aggiuntivi se i log contengono dati personali. Sul piano pratico, questo significa che l\u2019infrastruttura di record-keeping deve prevedere uno storage sicuro e accessibile per un semestre dalla creazione di ogni singola registrazione, con la possibilit\u00e0 di estrarre i log su richiesta delle autorit\u00e0 di vigilanza nazionali. La conservazione dei log non \u00e8 un obbligo statico: il deployer deve anche garantire che i log restino leggibili, integri e correlabili per tutto il periodo di conservazione.<\/p>\nGli eventi da registrare variano in base alla tipologia del sistema. L\u2019Art. 12, paragrafo 2, indica che i log devono catturare ogni informazione utile a ricostruire il comportamento del sistema in relazione ai rischi. Per i sistemi di identificazione biometrica remota, elencati nell\u2019Allegato III, punto 1a<\/a>, l\u2019Art. 12, paragrafo 3, \u00e8 pi\u00f9 specifico: timestamp di ogni utilizzo, database di riferimento impiegato, dati di input che hanno prodotto una corrispondenza, identificazione del personale che ha verificato i risultati. Per gli altri sistemi ad alto rischio la norma non prescrive un elenco chiuso. Il principio guida resta la ricostruibilit\u00e0 completa delle decisioni algoritmiche e l\u2019audit trail di ogni interazione rilevante.<\/p>\nQuali sistemi AI rientrano nella categoria ad alto rischio<\/h3>\n
L\u2019Allegato III del regolamento elenca otto aree: identificazione biometrica, gestione di infrastrutture critiche, istruzione e formazione professionale, occupazione e gestione dei lavoratori, accesso a servizi essenziali (credito, assicurazioni, servizi pubblici), attivit\u00e0 di contrasto, gestione della migrazione, amministrazione della giustizia. Si aggiungono poi i sistemi usati come componenti di sicurezza di prodotti gi\u00e0 soggetti a legislazione armonizzata UE: dispositivi medici, macchinari, giocattoli, tra gli altri. La classificazione non dipende dalla tecnologia sottostante, ma dall\u2019uso e dal contesto di impiego.<\/p>\n
Obblighi del fornitore vs obblighi del deployer<\/h3>\n
Il regolamento distingue nettamente due figure. Il fornitore (provider) \u00e8 chi sviluppa il sistema AI o lo immette sul mercato: deve progettare l\u2019architettura di logging, definire quali eventi vengono registrati, produrre log in formati che ne consentano l\u2019analisi. Il deployer \u00e8 chi utilizza il sistema nel proprio contesto operativo: deve conservare i log per almeno sei mesi, renderli disponibili alle autorit\u00e0 di vigilanza su richiesta e monitorare che il sistema funzioni secondo le specifiche del fornitore. Un punto che merita attenzione: se un\u2019azienda acquista un sistema AI ad alto rischio da un vendor esterno, non \u00e8 esonerata dalla responsabilit\u00e0. Il deployer resta garante della conservazione e dell\u2019accessibilit\u00e0 dei log. Per garantire l\u2019integrit\u00e0 di questi log nel tempo, organizzazioni che operano sistemi ad alto rischio si affidano a TrueScreen per acquisire, certificare e conservare ogni evento con timestamp qualificato eIDAS, trasformando un obbligo di compliance in una garanzia probatoria.<\/p>\n
Le imprese che preparano la compliance all\u2019AI Act devono considerare anche l\u2019interazione tra l\u2019Art. 12 e due disposizioni adiacenti. L\u2019Art. 11<\/a> impone ai fornitori di produrre la documentazione tecnica prima dell\u2019immissione sul mercato. L\u2019Art. 18<\/a> obbliga i deployer a mantenere tale documentazione accessibile per dieci anni dal ritiro del sistema dal mercato. L\u2019Art. 12 copre i log operativi automatici con conservazione minima di sei mesi; l\u2019Art. 18 copre la documentazione tecnica e di valutazione della conformit\u00e0 con orizzonte decennale. Entrambi gli obblighi richiedono prova di integrit\u00e0 su richiesta, una sfida che si intensifica nei sistemi AI agentici<\/a> dove agenti autonomi prendono decisioni attraverso confini organizzativi.<\/p>\nSanzioni e timeline: cosa rischia chi non si adegua entro agosto 2026<\/h2>\n
La mancata conformit\u00e0 agli obblighi di record-keeping dell\u2019AI Act comporta sanzioni fino a 15 milioni di euro o il 3% del fatturato annuo globale<\/a>, a seconda di quale importo sia superiore: \u00e8 il secondo dei tre livelli sanzionatori previsti dall\u2019Art. 99 del regolamento. Il primo livello, riservato alle pratiche AI vietate dall\u2019Art. 5, arriva a 35 milioni di euro o il 7% del fatturato. Il terzo livello, per informazioni inesatte fornite alle autorit\u00e0, prevede fino a 7,5 milioni di euro o l\u20191% del fatturato. Per PMI e startup si applica l\u2019importo inferiore tra i due. La scadenza chiave \u00e8 il 2 agosto 2026: da quella data i sistemi ad alto rischio dell\u2019Allegato III devono rispettare integralmente l\u2019Art. 12 e l\u2019intero blocco di obblighi degli Artt. 6-49. Chi non si adegua entro quel termine opera in violazione del regolamento.<\/p>\n\n
Il Regolamento UE 2024\/1689 (AI Act) \u00e8 il primo atto legislativo al mondo dedicato interamente all\u2019intelligenza artificiale. Per le aziende che sviluppano o utilizzano sistemi AI classificati ad alto rischio, la piena applicazione scatta ad agosto 2026 e porta con s\u00e9 obblighi operativi concreti. Tra questi, l\u2019Art. 12 impone la registrazione automatica degli eventi (record-keeping) per l\u2019intero ciclo di vita del sistema. Il problema: il testo normativo \u00e8 preciso negli obiettivi, ma vago sulle modalit\u00e0 operative. Quali eventi registrare? In che formato? Con quali garanzie di integrit\u00e0? Come affrontato nella guida sulla certificazione dei dati per agenti AI e governance<\/a>, la risposta si articola su tre livelli: logging automatico conforme all\u2019Art. 12, conservazione per almeno sei mesi e, per chi vuole andare oltre il minimo normativo, certificazione con valore legale dei log, che trasforma ogni registrazione in una prova opponibile a terzi.<\/p>\n Questo approfondimento fa parte della guida: Certificazione dei dati per agenti AI: governance e compliance<\/a><\/strong><\/p>\n L\u2019Art. 12 del regolamento europeo sull\u2019intelligenza artificiale stabilisce che ogni sistema AI classificato ad alto rischio deve essere progettato con capacit\u00e0 di logging automatico degli eventi, imponendo di fatto un obbligo di record-keeping strutturato per l\u2019intero ciclo di vita del sistema. I log devono consentire di tracciare il funzionamento dalla messa in servizio alla dismissione, garantendo la tracciabilit\u00e0 di ogni decisione algoritmica. Le finalit\u00e0 sono definite dall\u2019Art. 12, paragrafo 2: identificare situazioni di rischio ai sensi dell\u2019Art. 79<\/a>, facilitare il monitoraggio post-commercializzazione previsto dall\u2019Art. 72<\/a>, monitorare le prestazioni operative secondo l\u2019Art. 26, paragrafo 5. La registrazione non \u00e8 facoltativa e non \u00e8 delegabile a processi manuali: \u00e8 il sistema stesso a dover generare i log, senza intervento dell\u2019operatore. Secondo i dati della Commissione Europea<\/a>, i sistemi ad alto rischio rappresentano una quota minoritaria ma ad alta criticit\u00e0 del mercato AI europeo.<\/p>\n Art. 12, paragrafo 2, Regolamento UE 2024\/1689:<\/strong> \u201cI sistemi di IA ad alto rischio consentono tecnicamente la registrazione automatica degli eventi (log) per la durata del ciclo di vita del sistema.\u201d I log devono assolvere tre finalita\u2019 regolamentari: identificazione dei rischi ai sensi dell\u2019Art. 79, monitoraggio post-commercializzazione ai sensi dell\u2019Art. 72 e sorveglianza operativa ai sensi dell\u2019Art. 26(5).<\/p>\n<\/blockquote>\n I deployer di sistemi AI ad alto rischio devono conservare i log generati automaticamente per almeno sei mesi dalla data di generazione, come previsto dall\u2019Art. 26, paragrafo 6, del Regolamento UE 2024\/1689. Il periodo minimo decorre dal momento in cui ciascun log viene prodotto dal sistema e pu\u00f2 essere esteso da normative settoriali applicabili: il GDPR<\/a>, ad esempio, pu\u00f2 imporre vincoli aggiuntivi se i log contengono dati personali. Sul piano pratico, questo significa che l\u2019infrastruttura di record-keeping deve prevedere uno storage sicuro e accessibile per un semestre dalla creazione di ogni singola registrazione, con la possibilit\u00e0 di estrarre i log su richiesta delle autorit\u00e0 di vigilanza nazionali. La conservazione dei log non \u00e8 un obbligo statico: il deployer deve anche garantire che i log restino leggibili, integri e correlabili per tutto il periodo di conservazione.<\/p>\n Gli eventi da registrare variano in base alla tipologia del sistema. L\u2019Art. 12, paragrafo 2, indica che i log devono catturare ogni informazione utile a ricostruire il comportamento del sistema in relazione ai rischi. Per i sistemi di identificazione biometrica remota, elencati nell\u2019Allegato III, punto 1a<\/a>, l\u2019Art. 12, paragrafo 3, \u00e8 pi\u00f9 specifico: timestamp di ogni utilizzo, database di riferimento impiegato, dati di input che hanno prodotto una corrispondenza, identificazione del personale che ha verificato i risultati. Per gli altri sistemi ad alto rischio la norma non prescrive un elenco chiuso. Il principio guida resta la ricostruibilit\u00e0 completa delle decisioni algoritmiche e l\u2019audit trail di ogni interazione rilevante.<\/p>\n L\u2019Allegato III del regolamento elenca otto aree: identificazione biometrica, gestione di infrastrutture critiche, istruzione e formazione professionale, occupazione e gestione dei lavoratori, accesso a servizi essenziali (credito, assicurazioni, servizi pubblici), attivit\u00e0 di contrasto, gestione della migrazione, amministrazione della giustizia. Si aggiungono poi i sistemi usati come componenti di sicurezza di prodotti gi\u00e0 soggetti a legislazione armonizzata UE: dispositivi medici, macchinari, giocattoli, tra gli altri. La classificazione non dipende dalla tecnologia sottostante, ma dall\u2019uso e dal contesto di impiego.<\/p>\n Il regolamento distingue nettamente due figure. Il fornitore (provider) \u00e8 chi sviluppa il sistema AI o lo immette sul mercato: deve progettare l\u2019architettura di logging, definire quali eventi vengono registrati, produrre log in formati che ne consentano l\u2019analisi. Il deployer \u00e8 chi utilizza il sistema nel proprio contesto operativo: deve conservare i log per almeno sei mesi, renderli disponibili alle autorit\u00e0 di vigilanza su richiesta e monitorare che il sistema funzioni secondo le specifiche del fornitore. Un punto che merita attenzione: se un\u2019azienda acquista un sistema AI ad alto rischio da un vendor esterno, non \u00e8 esonerata dalla responsabilit\u00e0. Il deployer resta garante della conservazione e dell\u2019accessibilit\u00e0 dei log. Per garantire l\u2019integrit\u00e0 di questi log nel tempo, organizzazioni che operano sistemi ad alto rischio si affidano a TrueScreen per acquisire, certificare e conservare ogni evento con timestamp qualificato eIDAS, trasformando un obbligo di compliance in una garanzia probatoria.<\/p>\n Le imprese che preparano la compliance all\u2019AI Act devono considerare anche l\u2019interazione tra l\u2019Art. 12 e due disposizioni adiacenti. L\u2019Art. 11<\/a> impone ai fornitori di produrre la documentazione tecnica prima dell\u2019immissione sul mercato. L\u2019Art. 18<\/a> obbliga i deployer a mantenere tale documentazione accessibile per dieci anni dal ritiro del sistema dal mercato. L\u2019Art. 12 copre i log operativi automatici con conservazione minima di sei mesi; l\u2019Art. 18 copre la documentazione tecnica e di valutazione della conformit\u00e0 con orizzonte decennale. Entrambi gli obblighi richiedono prova di integrit\u00e0 su richiesta, una sfida che si intensifica nei sistemi AI agentici<\/a> dove agenti autonomi prendono decisioni attraverso confini organizzativi.<\/p>\n La mancata conformit\u00e0 agli obblighi di record-keeping dell\u2019AI Act comporta sanzioni fino a 15 milioni di euro o il 3% del fatturato annuo globale<\/a>, a seconda di quale importo sia superiore: \u00e8 il secondo dei tre livelli sanzionatori previsti dall\u2019Art. 99 del regolamento. Il primo livello, riservato alle pratiche AI vietate dall\u2019Art. 5, arriva a 35 milioni di euro o il 7% del fatturato. Il terzo livello, per informazioni inesatte fornite alle autorit\u00e0, prevede fino a 7,5 milioni di euro o l\u20191% del fatturato. Per PMI e startup si applica l\u2019importo inferiore tra i due. La scadenza chiave \u00e8 il 2 agosto 2026: da quella data i sistemi ad alto rischio dell\u2019Allegato III devono rispettare integralmente l\u2019Art. 12 e l\u2019intero blocco di obblighi degli Artt. 6-49. Chi non si adegua entro quel termine opera in violazione del regolamento.<\/p>\nCosa impone l\u2019Art. 12 dell\u2019AI Act in materia di record-keeping<\/h2>\n
\n
Quali eventi registrare e per quanto tempo<\/h3>\n
Quali sistemi AI rientrano nella categoria ad alto rischio<\/h3>\n
Obblighi del fornitore vs obblighi del deployer<\/h3>\n
Sanzioni e timeline: cosa rischia chi non si adegua entro agosto 2026<\/h2>\n
![\"Prove](\"https:\/\/truescreen.io\/wp-content\/uploads\/2024\/09\/Mobile-Header.png\")
\n <\/div>\n