Tracciabilità dei prompt: perché certificare le istruzioni agli agenti AI
Un terzo delle organizzazioni non ha alcun sistema di audit trail per i propri agenti AI (Kiteworks, 2026). Il mercato dell'agentic AI nel 2026 vale 9,14 miliardi di dollari (Fortune Business Insights). Gartner prevede agenti AI nel 40% delle applicazioni enterprise entro fine anno. Eppure un'organizzazione su tre non sa ricostruire quali istruzioni siano state date ai propri agenti, né quando, né da chi. La tracciabilità dei prompt non è più un tema rinviabile.
Gli agenti AI operano sulla base di istruzioni configurabili: system prompt, user prompt, parametri, configurazioni di tool. Quando l'agente commette un errore o prende una decisione contestata, le domande sono immediate. Chi ha dato quelle istruzioni? Quando? Con quale contenuto esatto? I log tecnici, modificabili da qualsiasi amministratore, non offrono risposte con valore probatorio. Come approfondito nella guida sulla certificazione dei dati per agenti AI, solo la certificazione con data certa e immutabilità alla fonte permette di distinguere un errore di configurazione da un difetto del modello e di attribuire responsabilità in modo legalmente valido.
Questo approfondimento fa parte della guida: Certificazione dei dati per agenti AI: governance, compliance e responsabilità legale
Cosa sono i prompt e perché devono essere tracciati
Anatomia di un'istruzione: system prompt, user prompt, configurazioni
Un agente AI riceve istruzioni da tre canali distinti. Il system prompt definisce il comportamento di base: ruolo, limiti operativi, regole di sicurezza. Lo user prompt contiene le richieste specifiche dell'operatore durante ogni sessione. Le configurazioni di tool stabiliscono quali strumenti l'agente può usare, con quali permessi e con quali soglie decisionali.
La differenza non è accademica. Un system prompt che imposta una tolleranza al rischio alta produce risultati radicalmente diversi da uno conservativo, anche con lo stesso modello e gli stessi dati di input. Chi configura questi parametri si assume una responsabilità operativa sulle decisioni dell'agente, che ne sia consapevole o meno.
Il problema dell'attribuzione: chi ha detto cosa all'agente?
Senza un record certificato delle istruzioni impartite, ogni contestazione su una decisione automatizzata si riduce alla parola di un operatore contro un log modificabile. Il gap è misurabile: gli attacchi di prompt injection sono cresciuti del 340% su base annua nel quarto trimestre 2025 (Wiz Research via SQ Magazine), e il 67% di essi non viene rilevato per oltre 72 ore. Il 60% degli incidenti legati alla data privacy nei sistemi AI deriva da manipolazione dei prompt (SQ Magazine). Chi ha modificato il system prompt? Quando? Il log applicativo dice una cosa, l'operatore ne ricorda un'altra. Come sintetizza un rapporto Reworked: senza record di provenienza chiari, la responsabilità ricade su chi "avrebbe dovuto sapere". E in azienda, chi "avrebbe dovuto sapere" ha quasi sempre un nome e un cognome. Il problema non è tecnico: è probatorio. I log modificabili non reggono in sede giudiziaria, e la tracciabilità dei prompt diventa il discrimine tra un'organizzazione che può difendersi e una che non può.
Obblighi normativi e responsabilità del deployer
AI Act Art. 26: gli obblighi di chi configura l'agente
Il regolamento europeo sull'intelligenza artificiale assegna al deployer obblighi precisi di tracciabilità e trasparenza. L'Art. 12 impone la registrazione automatica degli eventi (logging) per i sistemi ad alto rischio, con conservazione minima di sei mesi. L'Art. 26 richiede che il deployer conservi i log generati automaticamente, assicuri la supervisione umana e garantisca trasparenza nell'uso del sistema. In pratica, chi configura un agente AI con un system prompt è tenuto a dimostrare quali istruzioni erano attive in ogni momento, con quali parametri e sotto la responsabilità di quale operatore. Questo obbligo si estende a ogni modifica successiva: un prompt aggiornato senza registrazione è una violazione potenziale. Il punto critico è che il regolamento non impone esplicitamente il valore probatorio di quei log; la compliance formale non basta quando la prova finisce in tribunale.
I tribunali richiedono di più. La Product Liability Directive 2024/2853, applicabile dal 9 dicembre 2026, introduce la presunzione di difettosità quando la documentazione è assente o insufficiente. Il CAD (D.Lgs. 82/2005), agli Art. 20-24, stabilisce che solo i documenti con firma digitale e sigillo qualificato hanno pieno valore legale. Il regolamento eIDAS (Art. 42) conferisce alle marche temporali qualificate la presunzione di accuratezza della data. Chi si limita a conservare log applicativi senza queste garanzie si ritrova con documentazione formalmente presente ma inutilizzabile in tribunale. Gli obblighi di trasparenza dell'AI Act richiedono un livello di prova che il semplice logging tecnico non può offrire.
Prompt injection non tracciati: un rischio legale sottovalutato
Il 55% degli attacchi nel 2026 rientra nella categoria degli indirect prompt injection: manipolazioni multi-hop che transitano attraverso i tool collegati all'agente (SQ Magazine). CrowdStrike ha documentato attacchi contro oltre 90 organizzazioni nel solo 2026. La ricerca accademica (paper arXiv su Stage-Level Tracking of Prompt Injection) conferma che il tracciamento a livello di singolo stadio è necessario per identificare il punto esatto di compromissione.
La conseguenza legale è quella che le organizzazioni sottovalutano di più. Se un prompt injection altera le istruzioni dell'agente e quell'alterazione non è tracciata, il deployer non può dimostrare che l'errore deriva dall'attacco e non dalla propria configurazione. Come riporta Kiteworks, i guardrail a livello di modello non contano come controlli di conformità perché bypassabili. La OWASP Top 10 per LLM colloca il prompt injection al primo posto tra i rischi e sottolinea la necessità di meccanismi di tracciabilità indipendenti dal modello stesso. Senza una strategia strutturata di record-keeping, l'onere della prova resta interamente sul deployer.
Come si certifica un prompt con valore legale?
Certificazione con data certa, hash e immutabilità alla fonte
TrueScreen, the Data Authenticity Platform, certifica ogni prompt attraverso un processo che combina hash SHA-256, marca temporale qualificata eIDAS e sigillo digitale qualificato. Il processo cattura tre elementi in un unico record immutabile: il contenuto esatto del prompt (system prompt, user prompt o configurazione di tool), il momento preciso dell'invio con accuratezza al secondo e l'identità certificata del mittente. Se il prompt venisse modificato anche di un singolo carattere dopo la certificazione, l'hash non corrisponderebbe più. Questo è il Livello 2 del framework a quattro livelli descritto nella guida sulla governance e compliance per la certificazione dei dati AI: dopo la knowledge base certificata (Livello 1), i prompt sono il secondo livello, seguito dalle operazioni e dagli output certificati (Livello 4). L'integrazione avviene tramite REST API e protocollo MCP: la certificazione è automatica, in tempo reale, compatibile con qualsiasi framework operativo.
La differenza tra un log applicativo e una certificazione con valore legale è sostanziale:
| Caratteristica | Log applicativo | Certificazione forense |
|---|---|---|
| Modificabilita' | Si (admin può editare) | No (hash immutabile) |
| Data certa | Timestamp server (manipolabile) | Marca temporale qualificata eIDAS |
| Valore probatorio | Limitato | Pieno (eIDAS, Reg. 910/2014) |
| Attribuzione | IP/username (falsificabile) | Identita' certificata + sigillo digitale |
| Automazione | Varia | API in tempo reale |
Scenario: più operatori, stesso agente, decisione contestata
Esempio concreto. Un istituto finanziario usa un agente AI per il credit scoring. Tre operatori configurano lo stesso agente con system prompt diversi: soglie di tolleranza al rischio differenti, criteri di valutazione personalizzati, parametri di accettazione specifici per segmento di clientela. Un cliente contesta il rifiuto della propria richiesta di credito.
Con i log applicativi tradizionali, ricostruire la catena decisionale è quasi impossibile. Quale operatore ha configurato l'agente al momento della valutazione? Il system prompt attivo era quello con soglie conservative o quello più permissivo? Qualcuno ha modificato il log dopo il fatto? Domande senza risposta certa.
Con la certificazione TrueScreen, ogni modifica al system prompt viene registrata con hash immutabile, marca temporale qualificata e identità dell'operatore. L'istituto può dimostrare quale configurazione era attiva al momento esatto della decisione e distinguere con certezza tra un errore di configurazione umana e un comportamento anomalo del modello. Le organizzazioni usano TrueScreen per creare record immutabili delle istruzioni impartite ai propri agenti AI, e la digital provenance diventa prova concreta anziché concetto astratto.
