Blog de Metlivi

¿Cómo debería un compañero de IA explicar su memoria a los usuarios?

Cuando un compañero de IA guarda o utiliza información sobre alguien, su explicación debería permitir que esa persona responda a seis preguntas prácticas: qué se podría recordar, de dónde provino la información, si se confirmó el guardado, dónde podría reutilizarse, cuánto tiempo permanece y cómo inspeccionarla, corregirla o eliminarla. El momento idóneo para esta explicación es cuando se sugiere, guarda o utiliza un recuerdo. La tarjeta que figura a continuación es una propuesta de diseño, no una descripción de controles que todas las aplicaciones ya ofrezcan.

27 de septiembre de 20267 min de lecturaHogar, seguridad, mascotas y vida sosteniblePor Metlivi Editorial Team
Sección 1

¿Qué debería comunicar al usuario una divulgación de memoria?

Una frase breve como «lo tendré en cuenta» puede sonar clara, pero deja el estado subyacente en la incertidumbre. ¿Significa que el dato está en el chat actual, almacenado para más tarde, inferido de otra fuente o simplemente reflejado en la siguiente respuesta? Una divulgación útil da un nombre a ese estado y ofrece al usuario una forma de verificarlo.

Diseñe la tarjeta de modo que cada respuesta sea visible junto a la acción pertinente. Si un dato es solo una sugerencia para guardar, identifíquelo como sugerencia. Si la aplicación no puede confirmar que se haya guardado un recuerdo persistente, indíquelo con franqueza; no dé a entender que se produjo un cambio. La redacción debe coincidir con el comportamiento real del sistema, incluidos los retrasos o límites que el producto pueda corroborar.

Sección 2

Las seis respuestas

Pregunta del usuario: ¿Qué puede convertirse en un recuerdo? — Lo que debe indicar la tarjeta: El dato específico o una descripción clara de su categoría, como «Prefieres resúmenes de proyectos breves». Evite etiquetas imprecisas como «personalización».

Pregunta del usuario: ¿De dónde procede? — Lo que debe indicar la tarjeta: Identifique el origen: este chat, un chat anterior, una aplicación conectada u otra fuente que el producto utilice realmente. Si se trata de una inferencia, identifíquela como tal.

Pregunta del usuario: ¿Se confirmó el guardado? — Lo que debe indicar la tarjeta: Especifique si el elemento está guardado, pendiente, sugerido o no guardado. Muestre controles de confirmación cuando el producto los admita.

Pregunta del usuario: ¿Dónde se podría reutilizar? — Lo que debe indicar la tarjeta: Describa los destinos o contextos pertinentes, como futuros chats o una función conectada específica. No prometa que permanecerá en un solo lugar a menos que sea cierto.

Pregunta del usuario: ¿Cuánto tiempo permanecerá? — Lo que debe indicar la tarjeta: Proporcione un período de retención admitido o explique la condición para su eliminación. Si el plazo varía o se desconoce, indíquelo y enlace al control o a la política aplicable.

Pregunta del usuario: ¿Cómo puedo inspeccionarlo, corregirlo o eliminarlo? — Lo que debe indicar la tarjeta: Enlace directamente a los controles de memoria o de actividad aplicables y explique qué acción modifica qué copia u origen.

Se trata de una propuesta de patrón de interacción. No debe presentarse como un estándar universal ni como una afirmación de que todos los compañeros cuentan con memoria a nivel de elemento, confirmación o un período de retención fijo. Si el producto carece de uno de estos controles, la divulgación debe indicar lo que está disponible en lugar de insinuar que el control existe.

Sección 3

¿En qué se diferencian el historial de chat, la memoria guardada y los datos de aplicaciones conectadas?

Los usuarios necesitan saber a qué tipo de información se enfrentan, ya que un mismo dato puede existir en más de un lugar. Una interfaz clara distingue al menos tres conceptos:

El **historial de chat** es el registro de una conversación. Conservar o eliminar ese registro es una sola acción, y su efecto en la personalización depende del diseño del producto y de sus normas declaradas.

La **memoria guardada** es la información que el producto retiene o deriva para una personalización posterior. Puede estar vinculada a chats anteriores, pero conceptualmente es diferente de la transcripción visible. La interfaz debe mostrar el elemento o explicar por qué no se puede inspeccionar por separado.

El **origen de aplicaciones conectadas** es la información disponible a partir de otro servicio que el usuario ha vinculado. Desconectar el servicio puede afectar al acceso futuro, pero no elimina necesariamente la información que ya se haya copiado, resumido o incluido en la actividad del chat.

Estas distinciones son importantes en los controles reales del producto. La Ayuda de las aplicaciones de Gemini de Google indica que eliminar chats anteriores puede tardar un breve período de tiempo en dejar de usarse para la personalización, y describe cómo eliminar o corregir la información asociada con chats anteriores. En cuanto a la información recordada desde una aplicación conectada, señala que es posible que los usuarios deban eliminar los chats pertinentes y desconectar la aplicación; realizar solo una de estas acciones puede dejar disponible el otro origen. Se trata de descripciones de los controles y del comportamiento de Gemini, no de reglas universales para los compañeros de IA ([Ayuda de las aplicaciones de Gemini: memoria de chats anteriores](https://support.google.com/gemini/answer/16598469?co=GENIE.Platform%3DDesktop&hl=en)).

La página de ayuda independiente sobre aplicaciones conectadas de Google también indica que desconectar una aplicación o eliminar datos en ella no elimina la actividad de las aplicaciones de Gemini, y que eliminar la actividad de las aplicaciones de Gemini no elimina datos en otros servicios. Esto ilustra por qué una divulgación debe identificar el origen y la copia afectada en lugar de utilizar una etiqueta genérica como «eliminar memoria» ([Ayuda de las aplicaciones de Gemini: aplicaciones conectadas](https://support.google.com/gemini/answer/16836988?hl=en)).

Sección 4

¿Cómo es una explicación específica del origen?

Considere este ejemplo ficticio: Riley le dice a un compañero en un chat: «Estoy planeando un fin de semana en Portland», y también ha conectado un calendario que contiene un evento en Portland. Más adelante, el compañero utiliza tanto el contexto del chat como el del calendario para sugerir un itinerario. Riley elimina el chat. Si el calendario sigue conectado, el evento puede seguir siendo una fuente de información independiente; eliminar la conversación no implica lógicamente que el evento del calendario también se haya eliminado. Este ejemplo ilustra la separación de orígenes. No afirma que ningún producto en particular almacene o reutilice esta información ficticia de ese modo.

Una divulgación útil en esta situación nombraría los orígenes por separado: «Esta sugerencia utilizó tu chat anterior sobre Portland y un evento disponible en tu calendario conectado». Si Riley elimina el chat, la interfaz debe notificar el estado de esa fuente relacionada con el chat y explicar si la conexión del calendario sigue disponible. Si el producto no puede determinar si se utilizó una fuente, no debe afirmar que se haya hecho.

La misma regla se aplica a la corrección. Si un usuario dice: «Ese evento no es mío», la interfaz debe identificar si la corrección actualiza un recuerdo guardado, modifica cómo se utiliza un chat o no altera el calendario conectado. Una corrección en un nivel no debe describirse como una corrección en todos los orígenes a menos que realmente sea así.

Sección 5

¿Por qué «me acuerdo de ti» no es suficiente?

Supongamos que una aplicación responde «me acuerdo de ti», pero no puede mostrar un elemento guardado, identificar un origen, confirmar un estado persistente ni explicar cómo puede modificarlo el usuario. Esa redacción puede resultar conversacional, pero no es una prueba de que se haya guardado un recuerdo. Podría describir el contexto del chat actual, una respuesta generada o un registro persistente; sin información sobre el estado, el usuario no puede distinguir entre ellos.

Para los diseñadores, este es un caso negativo útil: no permita que el lenguaje amistoso sustituya a un comprobante. Tras una acción, muestre un estado explícito como «Guardado», «No guardado» o «No se pudo confirmar», pero utilice solo estados que el sistema pueda verificar. Incluya una vía para inspeccionar el elemento cuando esté disponible. Si no existe un registro de memoria independiente que el usuario pueda inspeccionar, explique qué significa esa frase en ese producto y dónde se gestiona la información que la respalda.

Sección 6

¿Cómo deben los usuarios revisar y gestionar un recuerdo?

Cuando un compañero hace referencia a un dato de forma inesperada, el usuario debería poder seguir una breve secuencia de diagnóstico:

**Preguntar qué información se utilizó.** Solicite el dato concreto y su origen. Considere la respuesta como una explicación que debe contrastarse con los controles del producto, no como una prueba por sí misma.

**Abrir la fuente indicada.** Revise la conversación pertinente, la configuración de memoria, el historial de actividad o la configuración de aplicaciones conectadas. No asuma que se trata del mismo registro.

**Corregir el nivel adecuado.** Si el dato guardado es incorrecto, edítelo o elimínelo en los controles de memoria cuando estén disponibles. Si la información procede de un servicio conectado, revise también esa conexión o el elemento original.

**Verificar el resultado.** Busque un cambio de estado o una confirmación. Si el producto no puede confirmar una eliminación o corrección, debe indicarlo y describir cualquier retraso o limitación documentada para esa acción.

Los controles disponibles variarán según el producto. Las páginas de ayuda de Gemini, por ejemplo, describen cómo activar o desactivar la memoria de chats anteriores, buscar y eliminar chats antiguos y corregir información directamente en un chat. También explican que los datos de aplicaciones conectadas y la actividad de Gemini tienen vías de gestión independientes. Estos ejemplos son útiles porque hacen tangibles las diferencias de origen; no deben interpretarse como una promesa de que otra aplicación disponga de los mismos ajustes.

Sección 7

Sitúe la explicación junto a la acción sobre la memoria

Una tarjeta de seis respuestas funciona mejor cuando aparece en el momento en que el usuario la necesita: antes de confirmar un recuerdo sugerido, después de guardar o cuando una respuesta utiliza información de un chat anterior o de una aplicación conectada. Mantenga el estado conciso, identifique el origen con un lenguaje familiar y enlace al usuario con el control que modifique el registro pertinente. Cuando la retención o la reutilización no se conozcan con precisión, describa la incertidumbre en lugar de inventar una duración o una garantía.

La prueba es sencilla: tras leer la explicación, ¿puede el usuario identificar qué información está involucrada, de dónde provino, si realmente se guardó, dónde se puede utilizar, qué la mantiene disponible y cómo modificarla? Si no es así, «me acuerdo de ti» es solo una frase. Una divulgación útil hace comprensible el estado real del producto y ofrece al usuario un paso práctico a seguir.

Lecturas relacionadas

Sigue explorando este tema