Compliance audit log on-prem: tracciabilità AI per AGID e EU AI Act 2026

Che cosa devi poter dimostrare sul tuo assistente AI, e a chi

La domanda che arriva prima o poi a chi tiene in casa un assistente AI è «possiamo ricostruire che cosa è successo?»: chi ha chiesto, a quale sistema, con quale esito, e se nessuno ha toccato il registro dopo. La risposta tecnica è un registro degli eventi ben progettato. La risposta giuridica è meno uniforme di quanto si legga in giro: un obbligo esplicito di registrazione esiste solo per i sistemi classificati ad alto rischio, e per tutti gli altri la ragione di tenere un registro viene dalla responsabilità del titolare del trattamento e dal buon senso, non da un articolo che lo imponga. Questo articolo distingue i due piani e costruisce quattro pezzi con programmi eseguiti: un record che non copia i dati personali, una pseudonimizzazione che regge, una catena di impronte che rende evidente la manomissione, e un conto onesto sulla durata di conservazione.

Un avvertimento sul perimetro. Qui sotto trovi che cosa dicono i testi ufficiali, letti il 2026-11-13; non è consulenza legale e non dice se la tua azienda abbia obblighi: quello dipende da che cosa fa il tuo sistema e da come è classificato. Il caso che uso è costruito: una PMI con un assistente interno che risponde sulle procedure aziendali. Per la parte dei dati personali, il quadro di partenza è l'articolo su privacy by design; per la sicurezza dei backup del registro, quello sul disaster recovery.

Che cosa dice davvero l'articolo 12 dell'AI Act

Nel testo consolidato del regolamento (UE) 2024/1689, versione del 27 luglio 2026, l'articolo 12 si intitola «Conservazione delle registrazioni» e dice al primo paragrafo che i sistemi di IA ad alto rischio consentono a livello tecnico la registrazione automatica degli eventi («log») per la durata del ciclo di vita del sistema. È una prescrizione di progettazione rivolta al sistema: il sistema deve saper registrare. Il secondo paragrafo dice a che cosa servono le registrazioni, e il terzo fissa un contenuto minimo, ma solo per i sistemi di identificazione biometrica remota dell'allegato III punto 1 lettera a).

• Individuare situazioni in cui il sistema può presentare un rischio ai sensi dell'articolo 79, paragrafo 1, o dare luogo a una modifica sostanziale.
• Agevolare il monitoraggio successivo all'immissione sul mercato dell'articolo 72.
• Monitorare il funzionamento da parte di chi lo usa, come previsto dall'articolo 26, paragrafo 5.

I tre scopi sono la chiave di lettura: la norma non chiede di registrare tutto, chiede registrazioni pertinenti a questi tre fini, adeguate alla finalità del sistema. La durata sta altrove. L'articolo 19 impone ai fornitori di conservare i log che sono sotto il loro controllo per un periodo adeguato alla finalità, di almeno sei mesi; l'articolo 26, paragrafo 6, lo impone a chi usa il sistema (il deployer, la tua azienda se ne è l'utilizzatore) con la stessa soglia di sei mesi. Entrambe le disposizioni aggiungono «salvo diversamente disposto dal diritto dell'Unione o nazionale applicabile, in particolare dal diritto dell'Unione in materia di protezione dei dati personali»: il minimo di sei mesi non prevale sul GDPR.

Quando si applica? L'articolo 113 del testo consolidato dice che il capo III, sezioni 1, 2 e 3, cioè anche gli articoli 12, 19 e 26, si applica dal 2 dicembre 2027 per i sistemi classificati ad alto rischio ai sensi dell'articolo 6, paragrafo 2, e dell'allegato III, e dal 2 agosto 2028 per quelli dell'articolo 6, paragrafo 1, e dell'allegato I. Le date sono state spostate dal regolamento (UE) 2026/1744. Per un assistente che risponde su procedure interne, la domanda a monte è se rientri nell'elenco dell'allegato III: se non rientra, non ha l'obbligo dell'articolo 12, e il registro resta una scelta di prudenza.

E in Italia?

La legge 23 settembre 2025, n. 132, all'articolo 1 stabilisce che le sue disposizioni si interpretano e si applicano conformemente al regolamento 2024/1689, e all'articolo 20 designa l'Agenzia per l'Italia digitale (AgID) e l'Agenzia per la cybersicurezza nazionale (ACN) come autorità nazionali per l'intelligenza artificiale, ferma restando l'attribuzione a Banca d'Italia, CONSOB e IVASS del ruolo di autorità di vigilanza del mercato nei rispettivi settori. Il testo assegna all'AgID la promozione dell'innovazione e le funzioni di notifica, valutazione, accreditamento e monitoraggio degli organismi che verificano la conformità, e all'ACN la vigilanza, comprese le attività ispettive e sanzionatorie. L'articolo 24 delega il Governo ad adottare entro dodici mesi dall'entrata in vigore (10 ottobre 2025) i decreti legislativi di adeguamento.

Da qui due conseguenze per ciò che si legge sui «controlli AgID alle PMI con multe da qualche migliaio di euro»: il testo che ho letto non attribuisce all'AgID un potere sanzionatorio verso le imprese, e non ho verificato se i decreti di attuazione siano stati emanati, quindi non riporto importi né procedure di sanzione. Prima di fissare una scadenza, apri il testo vigente su Normattiva e cerca i decreti attuativi.

Che cosa registrare, e che cosa no

Qui sta la tensione di progetto: il registro serve a ricostruire gli eventi, ma il GDPR chiede di trattare solo i dati necessari (minimizzazione, articolo 5, paragrafo 1, lettera c) e di conservarli solo per il tempo necessario (lettera e). Il testo di una domanda a un assistente aziendale può contenere nomi, importi, questioni di salute di un collega. Se lo copi nel registro, hai creato un secondo archivio di dati personali, con le sue regole di accesso e di cancellazione. La scelta prudente è registrare l'evento, non il contenuto: chi (in forma pseudonimizzata), quando, quale sistema e versione del modello, quali fonti sono state consultate, quanto è durata, con quale esito, e un'impronta del prompt e della risposta che permette di verificare in seguito un testo senza averlo copiato.

Il programma costruisce un record così e lo sottopone a un controllo automatico: ogni campo previsto deve esserci con il tipo giusto, nessun campo non previsto deve comparire, e nessun indirizzo email in chiaro può trovarsi nel record. L'impronta è calcolata con HMAC e una chiave, la ragione è nella sezione successiva. Il testo di prompt e risposta non entra nel record: se una pratica richiede di conservarlo, è un'eccezione da motivare con una base e una durata a parte. Nel secondo esperimento il record sbagliato ha l'email al posto dello pseudonimo, un campo con il testo del prompt e manca l'esito: il controllo li trova tutti e tre.

"""Un record di registro che registra l'evento senza copiare i dati personali, con un controllo automatico."""
import hashlib
import hmac
import json
import re

CHIAVE = b"chiave-di-prova-da-tenere-fuori-dal-registro"
EMAIL = re.compile(r"[\w.+-]+@[\w-]+\.[\w.-]+")
CAMPI = {"id_evento": str, "istante_utc": str, "sistema": str, "versione_modello": str,
         "utente": str, "impronta_prompt": str, "impronta_risposta": str,
         "fonti": list, "durata_ms": int, "esito": str}


def impronta(testo):
    return hmac.new(CHIAVE, testo.encode(), hashlib.sha256).hexdigest()[:24]


def costruisci_record(id_evento, istante, utente_email, prompt, risposta, fonti, durata_ms, esito):
    # Nel registro finiscono impronte e identificativi, non il testo di prompt e risposta
    return {
        "id_evento": id_evento,
        "istante_utc": istante,
        "sistema": "assistente-interno",
        "versione_modello": "modello-x 1.0",
        "utente": impronta(utente_email),
        "impronta_prompt": impronta(prompt),
        "impronta_risposta": impronta(risposta),
        "fonti": fonti,
        "durata_ms": durata_ms,
        "esito": esito,
    }


def controlla(record):
    problemi = []
    for campo, tipo in CAMPI.items():
        if campo not in record:
            problemi.append(f"manca {campo}")
        elif not isinstance(record[campo], tipo):
            problemi.append(f"{campo} non è {tipo.__name__}")
    for extra in set(record) - set(CAMPI):
        problemi.append(f"campo non previsto: {extra}")
    testo = json.dumps(record, ensure_ascii=False)
    if EMAIL.search(testo):
        problemi.append("contiene un indirizzo email in chiaro")
    return sorted(problemi)


ok = costruisci_record("evt-0001", "2026-11-13T09:15:02Z", "anna.rossi@esempio.it",
                       "Qual è la procedura di rimborso spese?", "La procedura prevede...",
                       ["kb-101", "kb-205"], 1830, "ok")
print(json.dumps(ok, ensure_ascii=False, indent=2, sort_keys=True))
print("controllo:", controlla(ok) or "nessun problema")

errato = dict(ok)
errato["utente"] = "anna.rossi@esempio.it"
errato["prompt"] = "testo in chiaro che non dovrebbe esserci"
del errato["esito"]
print("controllo del record errato:")
for p in controlla(errato):
    print("  ", p)

# Output:
# {
#   "durata_ms": 1830,
#   "esito": "ok",
#   "fonti": [
#     "kb-101",
#     "kb-205"
#   ],
#   "id_evento": "evt-0001",
#   "impronta_prompt": "1e62af68cea25516a2b3c888",
#   "impronta_risposta": "5cb1023e34a354229e020356",
#   "istante_utc": "2026-11-13T09:15:02Z",
#   "sistema": "assistente-interno",
#   "utente": "f2e8c86b56024fa07786a929",
#   "versione_modello": "modello-x 1.0"
# }
# controllo: nessun problema
# controllo del record errato:
#    campo non previsto: prompt
#    contiene un indirizzo email in chiaro
#    manca esito

L'uscita mostra che cosa finisce davvero nel registro: identificativi, istante in UTC, il modello e la sua versione, gli identificatori delle fonti, l'esito e le tre impronte, e nulla che permetta di leggere la domanda. Per un'indagine puoi chiedere a chi l'ha scritta di mostrare il prompt, calcolare l'impronta e confrontarla con quella registrata. Il controllo non sostituisce la revisione: una regola per email non cattura un codice fiscale o un nome in un campo libero, ed è per questo che i campi liberi sono vietati. Il campo versione_modello è quello che permette di spiegare, dopo un aggiornamento, perché lo stesso prompt abbia dato una risposta diversa.

Pseudonimizzare davvero: l'impronta semplice non basta

La scorciatoia diffusa è registrare un hash SHA-256 dell'email al posto dell'email. Funziona finché nessuno lo prova a invertire, e invertirlo è facile quando lo spazio dei possibili input è piccolo: gli indirizzi aziendali seguono uno schema, e chi legge il registro può provare tutte le combinazioni plausibili e confrontare. Il programma mostra l'attacco su tre indirizzi di una PMI costruita. Con SHA-256 semplice tutti e tre vengono recuperati; con HMAC, cioè la stessa funzione di hash ma legata a una chiave segreta, chi non ha la chiave non recupera nulla. Il pseudonimo resta stabile fra due calcoli, quindi puoi ancora cercare gli eventi di una persona nel registro.

"""Pseudonimizzare l'identità nel registro: SHA-256 semplice contro HMAC con chiave segreta."""
import hashlib
import hmac

# Dipendenti di una PMI costruita: gli indirizzi seguono lo schema nome.cognome@esempio.it
DIPENDENTI = ["anna.rossi@esempio.it", "luca.bianchi@esempio.it", "sara.verdi@esempio.it"]
NOMI = ["anna", "luca", "sara", "marco", "paola"]
COGNOMI = ["rossi", "bianchi", "verdi", "neri", "gallo"]
CHIAVE = b"chiave-di-prova-da-tenere-fuori-dal-registro"   # in produzione sta in un gestore dei segreti


def sha_semplice(email):
    return hashlib.sha256(email.encode()).hexdigest()[:16]


def hmac_chiave(email, chiave):
    return hmac.new(chiave, email.encode(), hashlib.sha256).hexdigest()[:16]


def attacco_a_dizionario(pseudonimi, funzione):
    """Chi legge il registro prova tutti gli indirizzi plausibili e confronta i pseudonimi."""
    trovati = {}
    for nome in NOMI:
        for cognome in COGNOMI:
            ipotesi = f"{nome}.{cognome}@esempio.it"
            if funzione(ipotesi) in pseudonimi:
                trovati[funzione(ipotesi)] = ipotesi
    return trovati


reg_semplice = {sha_semplice(e) for e in DIPENDENTI}
print("SHA-256 semplice, indirizzi recuperati dal registro:", len(attacco_a_dizionario(reg_semplice, sha_semplice)), "su", len(DIPENDENTI))

reg_hmac = {hmac_chiave(e, CHIAVE) for e in DIPENDENTI}
# Chi non ha la chiave prova a replicare lo schema senza chiave, o con una chiave sbagliata
sbagliata = lambda e: hmac_chiave(e, b"chiave-indovinata")
print("HMAC, senza la chiave, indirizzi recuperati:      ", len(attacco_a_dizionario(reg_hmac, sbagliata)), "su", len(DIPENDENTI))

# Stesso input e stessa chiave danno lo stesso pseudonimo: il registro resta interrogabile per utente
print("stabile fra due calcoli:", hmac_chiave(DIPENDENTI[0], CHIAVE) == hmac_chiave(DIPENDENTI[0], CHIAVE))
print("pseudonimo di", DIPENDENTI[0], "->", hmac_chiave(DIPENDENTI[0], CHIAVE))

# Output:
# SHA-256 semplice, indirizzi recuperati dal registro: 3 su 3
# HMAC, senza la chiave, indirizzi recuperati:       0 su 3
# stabile fra due calcoli: True
# pseudonimo di anna.rossi@esempio.it -> f2e8c86b56024fa0

La differenza è tutta nella riga che chiama hmac.new(chiave, ...). La chiave deve stare fuori dal registro e fuori dal sistema che lo legge, in un gestore dei segreti con accessi tracciati; se sta nello stesso posto del registro, l'attacco torna possibile. Cambiare la chiave spezza il legame fra gli eventi vecchi e quelli nuovi: è una scelta di rotazione da decidere prima, perché cambia la possibilità di seguire una persona nel tempo.

Un'ultima precisazione, perché circola l'idea opposta: pseudonimizzare non rende i dati anonimi. Il considerando 26 del GDPR dice che i dati personali sottoposti a pseudonimizzazione, attribuibili a una persona fisica mediante informazioni aggiuntive, dovrebbero essere considerati informazioni su una persona fisica identificabile. Quindi gli eventi del registro restano dati personali, con tutti i diritti degli interessati. Per una richiesta di cancellazione non basta cancellare la tabella di corrispondenza e dichiarare chiuso il caso. L'articolo 17, paragrafo 3, esclude l'obbligo di cancellazione nella misura in cui il trattamento serva ad adempiere un obbligo legale o ad accertare, esercitare o difendere un diritto in sede giudiziaria: valuta caso per caso, e documenta la valutazione.

Un registro che rende evidente la manomissione

Un registro vale come prova solo se si può dire che nessuno lo ha modificato dopo. Un metodo semplice e verificabile è la catena di impronte: ogni voce contiene l'impronta della precedente, calcolata insieme al proprio contenuto in forma canonica (chiavi ordinate, senza spazi superflui, altrimenti due scritture equivalenti danno impronte diverse). Se qualcuno modifica una voce, la sua impronta non corrisponde più al contenuto; se ne cancella una nel mezzo, il collegamento fra le vicine si spezza.

Il programma costruisce una catena di cinque eventi e prova quattro situazioni. L'ultima va letta con attenzione: se qualcuno cancella le voci in coda, la catena che resta è ancora internamente coerente, e senza un riferimento esterno non si accorge di niente. Per questo la testa della catena (l'impronta dell'ultima voce) e la lunghezza vanno conservate altrove, in un posto che chi scrive nel registro non può modificare: un messaggio inviato a una casella di un'altra persona, un registro separato in sola lettura, un file nel backup. Con l'ancora, il troncamento viene rilevato.

"""Catena di impronte per un registro append-only: rileva modifiche e cancellazioni, e il limite sul troncamento in coda."""
import hashlib
import json

GENESI = "0" * 64


def canonico(evento):
    return json.dumps(evento, sort_keys=True, separators=(",", ":"), ensure_ascii=False)


def aggiungi(catena, evento):
    precedente = catena[-1]["impronta"] if catena else GENESI
    impronta = hashlib.sha256((precedente + canonico(evento)).encode()).hexdigest()
    return catena + [{"evento": evento, "precedente": precedente, "impronta": impronta}]


def verifica(catena, testa_attesa=None, lunghezza_attesa=None):
    """Ritorna la lista dei problemi. Se testa e lunghezza sono ancorate all'esterno, controlla anche la coda."""
    problemi, precedente = [], GENESI
    for i, voce in enumerate(catena):
        if voce["precedente"] != precedente:
            problemi.append(f"voce {i}: il collegamento con la precedente è spezzato")
        calcolata = hashlib.sha256((voce["precedente"] + canonico(voce["evento"])).encode()).hexdigest()
        if calcolata != voce["impronta"]:
            problemi.append(f"voce {i}: contenuto modificato")
        precedente = voce["impronta"]
    if lunghezza_attesa is not None and len(catena) != lunghezza_attesa:
        problemi.append(f"lunghezza {len(catena)} invece di {lunghezza_attesa}")
    if testa_attesa is not None and precedente != testa_attesa:
        problemi.append("la testa della catena non coincide con quella ancorata")
    return problemi


catena = []
for n in range(1, 6):
    catena = aggiungi(catena, {"id": n, "utente": f"u{n % 2}", "esito": "ok"})

testa, lunghezza = catena[-1]["impronta"], len(catena)     # da conservare FUORI dal registro
print("integra:", verifica(catena, testa, lunghezza) or "nessun problema")

modificata = [dict(v) for v in catena]
modificata[1] = {**modificata[1], "evento": {"id": 2, "utente": "u0", "esito": "negato"}}
print("evento 2 modificato:", verifica(modificata, testa, lunghezza))

senza_terza = catena[:2] + catena[3:]
print("voce 3 cancellata:", verifica(senza_terza, testa, lunghezza))

troncata = catena[:3]
print("ultime due cancellate, senza ancora:", verifica(troncata) or "nessun problema")
print("ultime due cancellate, con ancora:  ", verifica(troncata, testa, lunghezza))

# Output:
# integra: nessun problema
# evento 2 modificato: ['voce 1: contenuto modificato']
# voce 3 cancellata: ['voce 2: il collegamento con la precedente è spezzato', 'lunghezza 4 invece di 5']
# ultime due cancellate, senza ancora: nessun problema
# ultime due cancellate, con ancora:   ['lunghezza 3 invece di 5', 'la testa della catena non coincide con quella ancorata']

Nell'uscita, la modifica della seconda voce è localizzata («voce 1»), la cancellazione della terza viene rilevata dal collegamento spezzato e dalla lunghezza, e il troncamento in coda passa inosservato senza ancora e viene scoperto con l'ancora. Il limite generale: chi ha accesso in scrittura a tutto il registro può ricalcolare l'intera catena dopo aver modificato un evento, quindi la catena protegge dalle manomissioni parziali e da quelle maldestre, non da chi controlla anche l'ancora. Alberi di Merkle e firme digitali con marca temporale spostano il limite, a costo di più complessità; non li ho implementati qui. Per i servizi che offrono archiviazione in sola scrittura, verifica nella documentazione del fornitore le garanzie reali prima di contarci.

Per quanto tempo conservare: l'aritmetica e lo scopo

La durata non è un numero da copiare: viene dallo scopo del registro e dal vincolo che i dati personali non si conservano più del necessario. Per un sistema ad alto rischio c'è un minimo di sei mesi (articoli 19 e 26), per tutti gli altri nessun minimo e il limite di necessità del GDPR. Il numero «sette anni», che si trova spesso in guide sul tema, non l'ho trovato in nessuno dei due testi come obbligo del registro di un assistente AI; se un obbligo specifico del tuo settore lo impone (per esempio in ambito finanziario, dove l'AI Act rimanda alla documentazione già prevista dalla normativa di settore), lo trovi lì e lo documenti.

Un errore concreto da evitare è l'aritmetica delle ore nei file di configurazione. Il programma mostra che 2555 ore sono 106,5 giorni, non sette anni: sette anni di 365 giorni sono 61.320 ore. Una conversione sbagliata in un parametro di retention produce un registro che si cancella dopo tre mesi e mezzo senza che nessuno se ne accorga. La seconda parte calcola la data in cui un record si può cancellare e mostra un blocco per contenzioso: se è in corso un'indagine, la cancellazione si rinvia, e la regola deve essere scritta nel sistema, non affidata alla memoria.

"""Quanto dura una conservazione: aritmetica delle ore e data di cancellazione con blocco per contenzioso."""
from datetime import date, timedelta


def ore(giorni):
    return giorni * 24


print("2555 ore =", round(2555 / 24, 1), "giorni")
print("sette anni di 365 giorni =", ore(7 * 365), "ore")
print("183 giorni =", ore(183), "ore")


def data_cancellazione(evento, giorni_conservazione, blocco_fino=None):
    """Data dopo la quale il record si può cancellare. Un blocco (indagine, contenzioso) la rinvia."""
    scadenza = evento + timedelta(days=giorni_conservazione)
    if blocco_fino and blocco_fino > scadenza:
        return blocco_fino
    return scadenza


evento = date(2026, 11, 13)
print("evento", evento, "con 183 giorni ->", data_cancellazione(evento, 183))
print("stesso evento con blocco fino al 2027-12-01 ->", data_cancellazione(evento, 183, date(2027, 12, 1)))

# Output:
# 2555 ore = 106.5 giorni
# sette anni di 365 giorni = 61320 ore
# 183 giorni = 4392 ore
# evento 2026-11-13 con 183 giorni -> 2027-05-15
# stesso evento con blocco fino al 2027-12-01 -> 2027-12-01

Se il registro vive in Grafana Loki, la documentazione di Loki dice che la retention si ottiene con il compactor, che per impostazione predefinita il flag retention_enabled non è attivo e quindi i log vivono per sempre, e che il Table Manager con la sua retention è deprecato. La configurazione seguente è uno schema da adattare e non eseguito: nessun Loki è stato avviato per questo articolo, e il valore di 4392 ore (183 giorni) è solo un esempio di calcolo.

# Schema da adattare, NON eseguito: nessun Loki è stato avviato. Parametri dalla documentazione di Loki sulla retention.
compactor:
  working_directory: /loki/compactor
  retention_enabled: true            # senza questo flag, per impostazione predefinita i log restano per sempre
  delete_request_store: filesystem   # obbligatorio quando la retention è attiva

limits_config:
  retention_period: 4392h            # 183 giorni, solo come esempio: la durata la decide lo scopo del registro

Lo schema contiene due insidie. La prima è nel commento di retention_enabled: lasciando il valore predefinito il registro non si cancella mai, e questo è un problema di minimizzazione, non solo di spazio. La seconda è il vincolo che delete_request_store sia impostato quando la retention è attiva, come dice la documentazione. Ricorda anche che se hai una policy di ciclo di vita sul deposito oggetti, deve durare più del periodo di retention, altrimenti il deposito cancella prima.

Chi legge il registro, e come lo provi

Leggere il registro è a sua volta un trattamento: chi ci accede deve essere pochi, identificati, e i loro accessi vanno registrati altrove. La verifica della catena e il controllo dei record si fanno a intervalli regolari, non il giorno in cui qualcuno li chiede: la stessa logica della prova di ripristino dell'articolo precedente. Una routine ragionevole è verificare ogni giorno la catena contro l'ancora, e ogni trimestre provare a ricostruire la storia di un evento a partire dal registro, come lo farebbe un incaricato di una verifica. Se la ricostruzione richiede più di qualche minuto o manca un campo, hai trovato il difetto prima di chi te lo avrebbe contestato.

Domande frequenti

Devo tenere un registro anche se il mio sistema non è ad alto rischio?

L'articolo 12 dell'AI Act non ti obbliga, perché riguarda i sistemi ad alto rischio. Resta il GDPR: se tratti dati personali devi poter dimostrare di rispettare i principi (articolo 5, paragrafo 2) e di garantire la sicurezza, e un registro minimale è il modo ordinario per farlo.

Per quanto tempo devo conservare i log?

Per i sistemi ad alto rischio almeno sei mesi (articoli 19 e 26), salvo diversa disposizione del diritto dell'Unione o nazionale applicabile, in particolare sulla protezione dei dati personali. Per tutti gli altri non c'è un minimo: conta la finalità e la necessità.

Un hash dell'email basta per pseudonimizzare?

No: se gli indirizzi seguono uno schema prevedibile, un attacco a dizionario li recupera, come mostra il programma. Serve un HMAC con chiave segreta custodita fuori dal registro, e anche così i dati restano personali.

Posso registrare il testo dei prompt?

Puoi, ma stai creando un secondo archivio di dati personali, con minimizzazione e durata da giustificare. La scelta prudente è registrare impronte e identificativi delle fonti, e conservare il testo solo in casi motivati.

Che cosa sai fare adesso

Sai dire che cosa richiede l'articolo 12 dell'AI Act, a chi si rivolge, da quando si applica e dove la sua durata minima si ferma davanti al GDPR. Sai costruire un record che descrive l'evento senza copiare i dati personali e verificarlo con un controllo automatico, pseudonimizzare con una chiave invece di un hash semplice, rendere evidente una manomissione con una catena di impronte ancorata all'esterno e calcolare la conservazione senza errori di unità. Il passo successivo della serie rovescia la prospettiva: quando conviene non gestire nulla in casa.

Nella stessa serie trovi anche il riepilogo con la scheda di decisione.