Per quanto tempo un dato resta affidabile per un agente AI?

No. La data di aggiornamento di una pagina dice quando il contenitore è stato modificato, non se ogni informazione al suo interno sia ancora adatta alla decisione che stiamo prendendo. La descrizione di un prodotto può essere stabile, il prezzo può cambiare durante la giornata e la disponibilità anche tra due richieste consecutive. Trattare tutto come un unico documento aggiornato o vecchio nasconde proprio la differenza che conta.

Il problema diventa più evidente quando il lettore non deve soltanto rispondere, ma agire. Se un assistente riporta un prezzo superato, produce una risposta sbagliata. Se un agente usa quel prezzo per selezionare un fornitore, compilare un ordine o promettere un costo a un cliente, il dato vecchio entra in un processo e genera conseguenze. La freschezza smette di essere una qualità editoriale e diventa una condizione operativa.

La ricerca FreshLLMs distingue domande con conoscenza stabile da domande che richiedono informazioni in rapido cambiamento e mostra quanto queste ultime siano difficili per modelli che si affidano alla conoscenza appresa. Il punto utile per un'azienda non è che ogni risposta debba cercare sul web. È che ogni campo deve avere una politica coerente con la velocità con cui può cambiare e con il danno prodotto da un errore.

Non esiste una durata universale da applicare a tutti i settori. Un listino B2B aggiornato ogni trimestre e il prezzo dinamico di un volo sono entrambi prezzi, ma hanno ritmi, fonti e conseguenze diverse. La durata utile va decisa dal proprietario del processo osservando quattro fattori: frequenza reale di cambiamento, costo dell'errore, reversibilità dell'azione e disponibilità di una fonte autorevole da interrogare di nuovo.

La tabella non assegna tempi assoluti. Indica la politica di base da cui partire e che ogni organizzazione deve trasformare in una soglia misurabile. Un dato lento può essere conservato più a lungo, ma va invalidato quando cambia la fonte. Un dato volatile va letto vicino alla decisione. Un dato normativo richiede la versione applicabile e la data di efficacia, non soltanto l'ultima pagina trovata.

Una sola etichetta come "aggiornato oggi" non basta. Per ricostruire una decisione servono almeno quattro momenti distinti: quando il fatto è diventato vero nella fonte, quando il sistema lo ha letto, fino a quando il processo lo considera utilizzabile e quando l'agente lo ha impiegato. Confonderli rende impossibile capire se l'errore nasce dalla fonte, dalla raccolta, dalla cache o da un'azione eseguita troppo tardi.

Il primo è il tempo dell'evento, per esempio l'entrata in vigore di una tariffa. Il secondo è `observed_at`, cioè quando il sistema ha osservato quel valore. Il terzo è `recheck_after` o `valid_until`, la soglia decisa dal processo. Il quarto è `used_at`, il momento in cui il dato ha contribuito a una risposta o a un'azione. Non tutti i sistemi devono usare questi nomi, ma devono conservare la distinzione.

L'RFC 9111 sul caching HTTP offre un vocabolario utile: una risposta può essere riusata mentre è fresca; quando non lo è più, può essere validata con l'origine invece di essere scaricata ciecamente o usata come se nulla fosse. Non è uno standard per agenti AI, ma il principio è trasferibile. Scadenza non significa sempre cancellazione: significa che prima dell'uso serve una nuova prova di validità.

Contiene una regola comprensibile sia al sistema sia alla persona responsabile. Per ogni campo critico dichiara la fonte ammessa, la durata massima dell'osservazione, il controllo da eseguire prima dell'uso, il comportamento in caso di conflitto e chi possiede la decisione. Senza questi elementi, "usa dati aggiornati" resta un'intenzione che nessuno può testare.

Il contratto deve essere proporzionato all'azione. Per suggerire tre prodotti in una pagina informativa può essere accettabile mostrare il prezzo con orario e invitare alla verifica finale. Per inserire automaticamente un ordine, lo stesso prezzo va riletto dalla fonte transazionale immediatamente prima della conferma. Non è il modello a decidere quanto rischio accettare: è il processo, prima che il modello venga eseguito.

Anche i dati pubblicati dal brand devono esprimere questa disciplina. Schema.org prevede, per esempio, `priceValidUntil` per dichiarare la data oltre la quale un prezzo non è più disponibile. Il campo da solo non garantisce che un motore lo userà, ma rende esplicita una proprietà che altrimenti rimane implicita. La qualità nasce dalla coerenza tra pagina, feed, dati strutturati e sistema sorgente, non dall'aggiunta isolata di un attributo.

Un agente non dovrebbe trasformare l'assenza di un dato fresco in una falsa certezza. Se la soglia è superata, le opzioni sane sono tre: verificare di nuovo, restituire un risultato esplicitamente limitato oppure fermare l'azione e chiedere intervento. La scelta dipende dal costo del ritardo e dal costo dell'errore. Continuare in silenzio è quasi sempre l'opzione peggiore, perché rende invisibile il compromesso.

Verificare è appropriato quando la fonte è disponibile e il costo della chiamata è inferiore al rischio. Degradare significa offrire qualcosa di meno impegnativo, per esempio un confronto senza prezzo finale o una bozza non eseguibile. Fermarsi è corretto quando l'azione è difficile da annullare, coinvolge denaro, diritti, sicurezza o comunicazioni esterne e manca un dato indispensabile. L'arresto non è un fallimento tecnico: è una funzione di controllo.

Il NIST include data, ora, modifiche e fonti tra le informazioni che possono comporre i metadati di provenienza. Anche qui la provenienza non prova automaticamente che un contenuto sia corretto, ma permette di contestarlo e ricostruirlo. In un workflow agentico questa tracciabilità deve arrivare fino all'azione: quale valore è stato usato, da quale fonte, osservato quando e sotto quale regola.

Non basta provare il percorso ideale con fonti disponibili e dati coerenti. Il test utile introduce deliberatamente condizioni scomode: un prezzo scaduto, due fonti in conflitto, una risposta lenta, un campo assente, un aggiornamento che avviene tra selezione e conferma. Il risultato da osservare non è soltanto se l'agente completa il compito, ma se riconosce quando non ha più le condizioni per completarlo correttamente.

Costruisci un piccolo set di casi con una decisione attesa per ciascuno: usa, verifica, degrada o ferma. Esegui lo stesso set a ogni modifica del workflow e misura almeno il tasso di azioni basate su dati scaduti, i blocchi corretti, i blocchi inutili, la latenza aggiunta dalle verifiche e il costo delle fonti. Ottimizzare soltanto la velocità porta a riusare troppo; ottimizzare soltanto la prudenza porta a fermare tutto.

Poi testa il passaggio tra sistemi. Un valore può essere fresco nell'API di origine e vecchio nell'indice di ricerca, nel database intermedio o nel prompt costruito per il modello. Per ogni campo critico segui il percorso completo fino all'output e verifica dove viene memorizzato, trasformato o duplicato. La freschezza è una proprietà della catena, non soltanto dell'ultima chiamata.

Parti da un solo workflow e dai cinque campi che possono cambiare la decisione. Per ciascuno scrivi fonte, proprietario, frequenza osservata di cambiamento, soglia iniziale e comportamento oltre soglia. Se non sai scegliere una durata, usa una regola conservativa e misura quante verifiche produce. I dati reali del processo permetteranno di allungarla o accorciarla con una ragione, invece che per intuizione.

Separa poi i fatti stabili dai valori volatili. I primi possono vivere in una base di conoscenza versionata e venire aggiornati quando cambia la fonte. I secondi dovrebbero essere recuperati vicino all'inferenza o, quando l'agente agisce, vicino alla conferma. Questa separazione riduce chiamate inutili senza fingere che tutto ciò che è stato indicizzato ieri sia ancora valido oggi.

Infine rendi visibile il limite all'utente e al team. Una risposta con fonte e momento di osservazione è più utile di un numero apparentemente esatto senza contesto. Un agente che dichiara di non poter confermare una disponibilità protegge il processo meglio di uno che completa sempre il compito. La maturità non si misura da quante azioni vengono automatizzate, ma da quante vengono eseguite nelle condizioni dichiarate.