Come dovrebbe un assistente IA spiegare la propria memoria agli utenti?
Quando un assistente IA salva o utilizza informazioni su una persona, la sua spiegazione dovrebbe consentire a quella persona di rispondere a sei domande pratiche: cosa potrebbe essere memorizzato, da dove proviene l'informazione, se il salvataggio è stato confermato, dove potrebbe essere riutilizzata, per quanto tempo viene conservata e come visualizzarla, correggerla o eliminarla. Il momento utile per questa spiegazione è quando un ricordo viene suggerito, salvato o utilizzato. La scheda qui sotto è una proposta di design, non la descrizione di controlli già offerti da ogni app.
Cosa dovrebbe indicare all'utente un'informativa sulla memoria?
Una breve frase come “Lo terrò a mente” può sembrare chiara, lasciando però incerto lo stato effettivo. Significa che il dettaglio è presente nella chat corrente, archiviato per il futuro, dedotto da un'altra fonte o semplicemente riflesso nella risposta successiva? Un'informativa utile nomina lo stato ed offre all'utente un modo per verificarlo.
Progetta la scheda in modo che ogni risposta sia visibile accanto all'azione pertinente. Se un dettaglio è solo suggerito per il salvataggio, etichettalo come suggerimento. Se l'app non può confermare che una memoria persistente sia stata salvata, dillo chiaramente; non insinuare che sia avvenuta una modifica. La formulazione deve corrispondere al comportamento reale del sistema, compresi eventuali ritardi o limiti che il prodotto può comprovare.
Le sei risposte
Domanda dell'utente: Cosa può diventare memoria? — Cosa dovrebbe dire la scheda: Il dettaglio specifico o una descrizione semplice della sua categoria, come “Preferisci brevi riassunti di progetto.” Evita etichette vaghe come “personalizzazione”.
Domanda dell'utente: Da dove proviene? — Cosa dovrebbe dire la scheda: Identifica la fonte: questa chat, una chat precedente, un'app collegata o un'altra fonte effettivamente utilizzata dal prodotto. Se si tratta di un'inferenza, segnalala come inferenza.
Domanda dell'utente: Il salvataggio è stato confermato? — Cosa dovrebbe dire la scheda: Indica se l'elemento è salvato, in attesa, suggerito o non salvato. Mostra i controlli per la conferma quando il prodotto li supporta.
Domanda dell'utente: Dove può essere riutilizzato? — Cosa dovrebbe dire la scheda: Descrivi le destinazioni o i contesti pertinenti, come le chat future o una determinata funzionalità collegata. Non promettere che rimanga in un solo posto a meno che ciò non sia vero.
Domanda dell'utente: Per quanto tempo rimarrà memorizzato? — Cosa dovrebbe dire la scheda: Fornisci un periodo di conservazione supportato o spiega la condizione necessaria per la rimozione. Se le tempistiche variano o non sono note, specificalo e inserisci un link al controllo o alla policy applicabile.
Domanda dell'utente: Come posso visualizzarlo, correggerlo o eliminarlo? — Cosa dovrebbe dire la scheda: Rimanda direttamente ai controlli pertinenti della memoria o dell'attività, spiegando quale azione modifica quale copia o fonte.
Questo è un modello di interazione proposto. Non deve essere presentato come uno standard universale né come l'affermazione che ogni assistente disponga di memoria a livello di singolo elemento, di conferma o di un periodo di conservazione fisso. Se al prodotto manca uno di questi controlli, l'informativa dovrebbe indicare ciò che è disponibile anziché suggerire l'esistenza del controllo.
In cosa differiscono la cronologia delle chat, la memoria salvata e i dati delle app collegate?
Gli utenti devono sapere con quale tipo di informazione hanno a che fare, poiché lo stesso dettaglio può esistere in più di un posto. Un'interfaccia chiara separa almeno tre concetti:
La **cronologia delle chat** è la registrazione di una conversazione. Mantenere o eliminare tale registro è una singola azione, e il suo effetto sulla personalizzazione dipende dal design del prodotto e dalle regole dichiarate.
La **memoria salvata** rappresenta le informazioni che il prodotto conserva o ricava per una personalizzazione successiva. Può essere collegata a chat precedenti, ma è concettualmente diversa dalla trascrizione visibile. L'interfaccia dovrebbe mostrare l'elemento o spiegare perché non può essere esaminato separatamente.
La **fonte da app collegata** è l'informazione disponibile da un altro servizio collegato dall'utente. Disconnettere il servizio può influire sull'accesso futuro, ma non elimina necessariamente le informazioni già copiate, riassunte o incluse nell'attività della chat.
Queste distinzioni sono importanti nei comandi effettivi del prodotto. La Guida delle app Gemini di Google afferma che l'eliminazione delle chat passate potrebbe richiedere un breve lasso di tempo prima di interrompere il loro utilizzo per la personalizzazione, e descrive l'eliminazione o la correzione delle informazioni associate alle chat precedenti. Per le informazioni ricordate da un'app collegata, specifica che gli utenti potrebbero dover eliminare le chat pertinenti e disconnettere l'app; eseguire solo una delle due operazioni potrebbe lasciare disponibile l'altra fonte. Queste sono descrizioni dei controlli e del comportamento di Gemini, non regole universali per gli assistenti IA ([Guida delle app Gemini: memoria delle chat passate](https://support.google.com/gemini/answer/16598469?co=GENIE.Platform%3DDesktop&hl=en)).
La pagina di assistenza separata di Google per le app collegate spiega inoltre che la disconnessione di un'app o l'eliminazione dei dati in quell'app non cancella l'Attività delle app Gemini, e l'eliminazione dell'Attività delle app Gemini non cancella i dati in altri servizi. Ciò illustra il motivo per cui un'informativa dovrebbe identificare la fonte e la copia interessata, anziché usare una generica etichetta come “elimina memoria” ([Guida delle app Gemini: App collegate](https://support.google.com/gemini/answer/16836988?hl=en)).
Che aspetto ha una spiegazione specifica per fonte?
Prendiamo questo esempio fittizio: Riley dice a un assistente in chat: “Sto programmando un fine settimana a Portland”, e ha anche collegato un calendario che contiene un evento a Portland. In seguito, l'assistente utilizza sia la chat sia il contesto del calendario per suggerire un itinerario. Riley elimina la chat. Se il calendario rimane collegato, l'evento può comunque essere una fonte di informazioni indipendente; l'eliminazione della conversazione non implica logicamente che sia stato eliminato anche l'evento dal calendario. Questo esempio illustra la separazione delle fonti. Non implica che alcun prodotto specifico memorizzi o riutilizzi queste informazioni fittizie in quel modo.
Un'informativa utile in questa situazione nominerebbe le fonti separatamente: “Questo suggerimento ha utilizzato la tua chat passata su Portland e un evento disponibile dal tuo calendario collegato”. Se Riley rimuove la chat, l'interfaccia dovrebbe segnalare lo stato di quella fonte correlata alla chat e spiegare se la connessione al calendario rimane attiva. Se il prodotto non può determinare se una fonte è stata utilizzata, non dovrebbe dichiarare che lo è stata.
La stessa regola vale per le correzioni. Se un utente dice: “Quell'evento non è mio”, l'interfaccia dovrebbe specificare se la correzione aggiorna una memoria salvata, modifica il modo in cui viene utilizzata una chat o lascia intatto il calendario collegato. Una correzione su un singolo livello non dovrebbe essere descritta come una correzione di tutte le fonti, a meno che non lo faccia realmente.
Perché dire “Mi ricordo di te” non è sufficiente?
Supponiamo che un'app risponda “Mi ricordo di te”, ma non sia in grado di mostrare un elemento salvato, identificare una fonte, confermare uno stato persistente o spiegare in che modo l'utente possa modificarlo. Questa formulazione può risultare colloquiale, ma non dimostra affatto che un ricordo sia stato salvato. Potrebbe descrivere il contesto della chat corrente, una risposta generata o un record persistente; senza informazioni sullo stato, l'utente non può distinguerli.
Per i designer, questo è un utile caso negativo: non lasciare che un linguaggio amichevole sostituisca una conferma effettiva. Dopo un'azione, mostra uno stato esplicito come “Salvato”, “Non salvato” o “Impossibile confermare”, ma impiega solo stati che il sistema può verificare. Includi un percorso per esaminare l'elemento ove disponibile. Se non esiste un record di memoria separato che l'utente possa ispezionare, spiega cosa significa quella frase in quel prodotto e dove vengono gestite le relative informazioni di supporto.
Come dovrebbero gli utenti controllare e gestire una memoria?
Quando un assistente fa riferimento a un dettaglio in modo inaspettato, l'utente dovrebbe poter seguire una breve sequenza diagnostica:
**Chiedere quali informazioni sono state utilizzate.** Richiedere il dettaglio specifico e la sua fonte. Trattare la risposta come una spiegazione da confrontare con i comandi del prodotto, non come una prova a sé stante.
**Aprire la fonte indicata.** Controllare la conversazione pertinente, le impostazioni della memoria, la cronologia delle attività o le impostazioni delle app collegate. Non dare per scontato che si tratti del medesimo record.
**Correggere il livello corretto.** Se il dettaglio salvato è errato, modificalo o rimuovilo nei controlli della memoria, quando disponibili. Se le informazioni provengono da un servizio collegato, verifica anche tale connessione o l'elemento originale.
**Verificare il risultato.** Cercare un cambio di stato o una conferma. Se il prodotto non può confermare un'eliminazione o una correzione, dovrebbe specificarlo e descrivere qualsiasi ritardo o limitazione documentata per tale azione.
I controlli disponibili variano a seconda del prodotto. Le pagine di assistenza di Gemini, ad esempio, descrivono come attivare o disattivare la memoria delle chat precedenti, trovare ed eliminare le chat passate e correggere le informazioni direttamente in una chat. Spiegano inoltre che i dati delle app collegate e l'attività di Gemini seguono percorsi di gestione separati. Questi esempi sono utili perché rendono concrete le distinzioni tra le fonti; non vanno interpretati come una promessa che un'altra app disponga delle stesse impostazioni.
Posiziona la spiegazione accanto all'azione sulla memoria
Una scheda a sei risposte funziona al meglio quando appare nel momento in cui l'utente ne ha bisogno: prima di confermare una memoria suggerita, dopo un salvataggio o quando una risposta utilizza informazioni provenienti da una chat passata o da un'app collegata. Mantieni lo stato conciso, nomina la fonte con un linguaggio familiare e rimanda l'utente al comando che modifica il record pertinente. Nei casi in cui la conservazione o il riutilizzo non siano noti con precisione, descrivi tale incertezza anziché inventare una durata o una garanzia.
Il test è semplice: dopo aver letto la spiegazione, l'utente è in grado di identificare quali informazioni sono coinvolte, da dove provengono, se sono state effettivamente salvate, dove potrebbero essere utilizzate, cosa le mantiene disponibili e come modificarle? In caso contrario, “Mi ricordo di te” rimane solo una frase. Un'informativa utile rende comprensibile lo stato effettivo del prodotto ed offre all'utente un passaggio pratico successivo.