Ogni azione amministrativa all’interno di AI Suite produce una riga di audit JSONL. La riga registra il timestamp, l’email dell’attore, il verbo dell’azione, la risorsa interessata, il X-App-Id del client di origine e un hash stabile che permette a un revisore di correlare la riga con eventi successivi. La riga registra nessun input o output del modello. Nessun testo di prompt, nessun testo di completamento, nessun contenuto di documento, nessuna entità estratta. Questa scelta — priva di contenuto per progettazione — è ciò che rende la riga di audit utile per i revisori di procurement e compliance, ed è importante spiegare il motivo.

Cosa contiene una riga di audit e cosa no

Una riga rappresentativa, leggermente redatta:

{"ts":"2026-06-05T09:14:22Z","actor":"jane@bank.example","action":"license.assign",
 "subject":"user@bank.example","tier":"commercial","x_app_id":"ai-admin-console",
 "ip":"10.4.1.22","ua_hash":"a17c…","seq":48211}

Cosa contiene: metadati sufficienti per rispondere alle domande degli auditor sugli obblighi del deployer — chi ha fatto cosa, quando, contro quale risorsa, da quale client. Cosa non contiene: alcun payload del flusso AI. Se l’azione avesse invocato un modello (in questo esempio non è successo, ma avrebbe potuto), ci sarebbe una riga che registra l’evento di invocazione, ma nessuna traccia del prompt o della risposta nella nostra infrastruttura.

Questa separazione è voluta. La riga di audit è la prova che un’azione è avvenuta. Il contenuto dell'azione — il prompt inviato al modello, la risposta restituita — risiede sull'hardware del deployer, regolato dalla politica di conservazione del deployer stesso. Noi non lo vediamo mai.

Perché il contenuto resta fuori dalla riga

Due motivi, uno normativo e uno operativo.

Normativo: il Regolamento UE sull'IA richiede ai deployer di IA ad alto rischio di conservare i log "per un periodo appropriato", per monitorare il funzionamento del sistema e dimostrare la conformità su richiesta [1]. L'obbligo è a carico del deployer di dimostrare cosa è accaduto. Le API LLM cloud rispondono a questo conservando prompt e risposta sull'infrastruttura del fornitore, trasferendo così il problema della gestione dei dati al fornitore — e creando un secondo perimetro di conformità che il deployer non controlla. L'audit locale senza contenuto risponde alla stessa domanda normativa senza questo trasferimento: il deployer conserva il contenuto, nel proprio storage, secondo le proprie regole di conservazione.

Operativo: ogni byte di contenuto del modello memorizzato è un byte che deve essere criptato, controllato nell'accesso, conservato, cancellato secondo programma e prodotto in caso di e-discovery. Le righe senza contenuto sono piccole (alcune centinaia di byte), di forma fissa, append-only e facilmente serializzabili nel SIEM esistente del deployer. Sono l'unità probatoria più piccola che soddisfa ancora l'obbligo.

A cosa corrisponde questo nei principali framework

NIST AI RMF 1.0 indica l'auditabilità come dimensione centrale dell'IA affidabile e chiede ai deployer di mantenere "registrazioni delle azioni di sistema sufficienti a ricostruire le decisioni" [2]. "Sufficienti a ricostruire" è la frase chiave: la riga deve permettere a un revisore di ricostruire cosa è accaduto. Una riga senza contenuto lo fa per azioni amministrative (è stata concessa una licenza, è stata modificata una policy, un server è stato registrato) senza conservare il contenuto di un'inferenza. Per la parte di obbligo relativa al contenuto dell'inferenza, è il deposito locale del deployer a rispondere alla domanda.

La guida ENISA sulla cybersecurity dell'IA inquadra questo dal punto di vista della modellazione delle minacce [3]: ogni prompt e risposta memorizzati sull'infrastruttura di un fornitore amplia la superficie di attacco del deployer includendo 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 — la AI Admin Console UI, il aisuite-server daemon JSONL audit e il gancio di inoltro SIEM per organizzazione — implementano questo direttamente. Ogni evento amministrativo arriva in una riga leggibile dal deployer; nel percorso di inferenza locale o ospitato dal cliente, il contenuto di prompt e risposta non va al piano di controllo di Software Tailor.

Come appare questo in una revisione di approvvigionamento

La domanda di approvvigionamento che blocca i fornitori di cloud-AI è: "dove risiede il contenuto dell'inferenza e il nostro team di conformità può produrlo su richiesta?" La domanda a cui risponde l'audit senza contenuto è la stessa, con due risposte chiare: il contenuto risiede sul vostro hardware e il vostro team lo produce perché lo possiede già. La riga di audit dal nostro lato prova che l'azione è avvenuta; il contenuto dal vostro lato prova cosa ha fatto l'azione.

Per un inquadramento più ampio dell'approvvigionamento — incluso come guidare il questionario al fornitore con queste proprietà piuttosto che con certificazioni lato fornitore — vedere Perché le distribuzioni AI on-premise si bloccano nell'approvvigionamento e l'articolo sulla conformità al EU AI Act.

Cosa rimane responsabilità del deployer

L'audit senza contenuto è una proprietà strutturale della distribuzione, non una soluzione di conformità end-to-end. Il deployer rimane responsabile di:

  • Definire cosa significa "sufficiente per ricostruire" per i propri flussi di lavoro — periodo di conservazione, regole di mascheramento, postura di e-discovery.
  • Gestire l'archivio locale del contenuto (qualsiasi cosa scelga il deployer — file system, document DB, archivio blob criptato) e inoltrare le righe di audit dal nostro lato nel SIEM dove le correlano con i propri log.
  • Redazione del promemoria sugli obblighi del deployer che fa riferimento a questa architettura durante l'approvvigionamento.

La nostra parte fornisce l'architettura e il formato della riga di audit. Tutto ciò che segue — inclusa la politica di conservazione dei contenuti — è dove il team di conformità del deployer applica le proprie regole.

Riferimenti

  1. Commissione Europea. "AI Act — Quadro normativo sull'IA." https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai. Consultato il 03-06-2026.
  2. NIST. "AI Risk Management Framework (AI RMF 1.0)." https://www.nist.gov/itl/ai-risk-management-framework. Consultato il 03-06-2026.
  3. ENISA. "Sicurezza informatica dell'intelligenza artificiale." https://www.enisa.europa.eu/topics/iot-and-smart-infrastructures/artificial-intelligence. Consultato il 03-06-2026.