Prodotto Pubblicato il 2026-06-05 · 6 min di lettura

Log di audit privi di contenuto: come dimostriamo cosa ha fatto il modello senza conservare i prompt

Ogni azione amministrativa all'interno di AI Suite produce una riga di audit JSONL che registra timestamp, autore e azione — e nessun contenuto di prompt o risposta. Il deployer conserva il contenuto; noi conserviamo la prova che l'azione sia avvenuta.

Ogni azione amministrativa all'interno di AI Suite produce una riga di audit JSONL. La riga registra il timestamp, l'email dell'autore, il verbo dell'azione, la risorsa interessata, l'X-App-Id del client di origine e un hash stabile che consente a un revisore di correlare la riga con eventi successivi. La riga non registra alcun input o output del modello. Nessun testo del prompt, nessun testo del completamento, nessun contenuto di documenti, nessuna entità estratta. Quella scelta — priva di contenuto per design — è ciò che rende la riga di audit utile per i revisori di procurement e compliance, e merita una spiegazione del perché.

Cosa contiene una riga di audit, e cosa non contiene

Una riga rappresentativa, leggermente redatta:

{"ts":"2026-06-05T09:14:22Z","actor":"[email protected]","action":"license.assign",
 "subject":"[email protected]","tier":"commercial","x_app_id":"ai-admin-console",
 "ip":"10.4.1.22","ua_hash":"a17c…","seq":48211}

Cosa ha: metadati sufficienti a rispondere alle domande sugli obblighi del deployer che gli auditor pongono — chi ha fatto cosa, quando, contro quale risorsa, da quale client. Cosa non ha: alcun payload proveniente dal workflow di AI. Se l'azione avesse invocato un modello (non lo ha fatto in questo esempio, ma avrebbe potuto), ci sarebbe una riga a registrare l'evento di invocazione, ma nessuna traccia del prompt o della risposta nella nostra infrastruttura.

Questa separazione è deliberata. La riga di audit è la prova che un'azione sia avvenuta. Il contenuto dell'azione — il prompt inviato al modello, la risposta restituita — vive sull'hardware del deployer, governato dalla policy di retention del deployer. Noi non lo vediamo mai.

Perché il contenuto resta fuori dalla riga

Due ragioni, una normativa e una operativa.

Normativa: l'EU AI Act richiede ai deployer di AI ad alto rischio di conservare i log "per un periodo adeguato", di monitorare il funzionamento del sistema e di dimostrare la conformità su richiesta ^[1]. L'obbligo è in capo al deployer di dimostrare cosa sia accaduto. Le API LLM cloud rispondono a questo memorizzando prompt e risposta sull'infrastruttura del fornitore, il che trasferisce il problema della gestione dei dati al fornitore — e crea un secondo perimetro di conformità che il deployer non controlla. L'audit locale privo di contenuto risponde alla stessa domanda normativa senza quel trasferimento: il deployer conserva il contenuto, nello storage del deployer, secondo le regole di retention del deployer.

Operativa: ogni byte di contenuto del modello che venga memorizzato è un byte che deve essere cifrato, sottoposto a controlli di accesso, conservato, cancellato secondo scadenza e prodotto in sede di e-discovery. Le righe prive di contenuto sono piccole (poche centinaia di byte), a forma fissa, append-only e banalmente serializzabili nel SIEM esistente del deployer. Sono la più piccola unità probatoria che soddisfa comunque l'obbligo.

A cosa corrisponde nei principali quadri normativi

Il NIST AI RMF 1.0 indica l'auditabilità come una dimensione fondamentale dell'AI affidabile e chiede ai deployer di mantenere "registri delle azioni del sistema sufficienti a ricostruire le decisioni" ^[2]. "Sufficienti a ricostruire" è l'espressione operativa: la riga deve consentire a un revisore di ricomporre quanto accaduto. Una riga priva di contenuto fa questo per le azioni amministrative (è stata emessa una licenza, è stata modificata una policy, è stato arruolato un server) senza conservare il contenuto di un'inferenza. Per il lato del contenuto di inferenza dell'obbligo, è lo store locale del deployer a rispondere alla domanda.

La guida ENISA sulla cybersecurity dell'AI inquadra questo dal punto di vista del threat-modelling ^[3]: ogni prompt e risposta memorizzati sull'infrastruttura di un fornitore ampliano la superficie di attacco del deployer per includere quella del fornitore. Rimuovere il contenuto del modello dal lato fornitore restringe quella superficie a ciò che il deployer già controlla.

La forma che distribuiamo — l'interfaccia di AI Admin Console, l'audit JSONL del daemon aisuite-server e l'hook di forwarding SIEM per organizzazione — implementa questo direttamente. Ogni evento amministrativo atterra in una riga leggibile dal deployer; nessun contenuto di prompt o risposta lascia mai il perimetro del deployer.

Come appare in una revisione di procurement

La domanda di procurement che blocca i fornitori di AI cloud è: "dove vive il contenuto dell'inferenza, e il nostro team di compliance può produrlo su richiesta?". La domanda di procurement a cui l'audit privo di contenuto risponde è la stessa, con due risposte pulite: il contenuto vive sul vostro hardware, e il vostro team lo produce perché lo ha già. La riga di audit dal nostro lato dimostra che l'azione è avvenuta; il contenuto dal vostro lato dimostra cosa abbia fatto l'azione.

Per l'inquadramento più ampio di procurement — incluso come impostare il questionario del fornitore su queste proprietà anziché sulle certificazioni lato fornitore — vedi Perché i deployment di AI on-prem si bloccano in fase di procurement e l'articolo sulla conformità all'EU AI Act.

Cosa resta responsabilità del deployer

L'audit privo di contenuto è una proprietà strutturale del deployment, non una soluzione di conformità end-to-end. Il deployer resta titolare di:

Definire cosa significhi "sufficiente a ricostruire" per i propri workflow — periodo di retention, regole di mascheramento, postura di e-discovery.
Operare lo store di contenuto locale (qualunque sia la scelta del deployer — file system, document DB, blob store cifrato) e inoltrare le righe di audit dal nostro lato nel SIEM dove le correla con i propri log.
Scrivere il memo sugli obblighi del deployer che punta a questa architettura durante il procurement.

Dal nostro lato distribuiamo l'architettura e il formato della riga di audit. Tutto ciò che sta a valle — inclusa la policy di retention sul contenuto — è dove il team di compliance del deployer applica le proprie regole.

Riferimenti

European Commission. "AI Act — Regulatory framework on AI." digital-strategy.ec.europa.eu. Consultato il 2026-06-03.
NIST. "AI Risk Management Framework (AI RMF 1.0)." nist.gov/itl/ai-risk-management-framework. Consultato il 2026-06-03.
ENISA. "Artificial Intelligence Cybersecurity." enisa.europa.eu/topics/iot-and-smart-infrastructures/artificial-intelligence. Consultato il 2026-06-03.

Vedi l'audit privo di contenuto in azione su un carico di lavoro reale.

Un pilot gratuito di 1 settimana mette il modello sull'hardware del cliente e inoltra le righe di audit nel SIEM del cliente, in modo che il team di compliance possa scrivere il memo sugli obblighi del deployer a partire dai propri log.

Avvia un pilot gratuito di 1 settimana