Blog de Metlivi

¿Cómo puede un compañero de IA evitar recordatorios para una fecha importante incorrecta?

Para un recordatorio de fecha que requiere confirmación explícita, un compañero de IA debe mantener separada una fecha recordada de una notificación programada. Debe registrar de dónde provino la fecha, pedir al usuario que confirme la persona, la fecha, el año, la zona horaria y la hora del recordatorio, y no enviar nada mientras cualquiera de esos detalles siga sin resolverse. Una corrección, pausa o cancelación debe actualizar el estado del recordatorio y ser visible para el usuario.

27 de septiembre de 20267 min de lecturaGestión del tiempo y crecimiento personalPor Metlivi Editorial Team
Sección 1

Por qué recordar una fecha no es lo mismo que programar un recordatorio

Una conversación puede contener un dato útil sin incluir el permiso para crear una alerta. «El recital de Maya es el 14 de mayo» podría ser una nota que el usuario compartió, un plan tentativo o una fecha deducida a partir de una formulación ambigua. No especifica por sí sola si se desea un recordatorio, a qué año corresponde, a qué hora enviarlo o qué zona horaria utilizar.

Por lo tanto, un diseño confiable trata estos elementos como registros independientes:

**Dato recordado:** lo que se dijo o proporcionó, con su fuente y cualquier incertidumbre.

**Fecha confirmada:** la persona o evento y la fecha del calendario que el usuario ha verificado.

**Notificación programada:** una alerta que el usuario aprobó explícitamente, con una hora de entrega, zona horaria y estado actual.

Esta separación es una recomendación de diseño para compañeros de IA. Las páginas de ayuda de Google Calendar describen cómo crear eventos y administrar notificaciones en Calendar; no describen la memoria de un compañero de IA ni implementan el flujo de trabajo propuesto aquí. Solo como ejemplo de calendario, las instrucciones de Google tratan la creación de un evento como una acción con detalles del evento y un paso para guardar ([Google Calendar: Crear un evento](https://support.google.com/calendar/answer/72143?hl=en)).

Sección 2

¿Qué detalles se deben confirmar antes de programar?

Confirme los detalles que determinan qué significa la alerta y cuándo puede activarse. Una breve pantalla de revisión o un resumen conversacional debería mostrar:

**Persona o evento:** ¿Sobre quién es la fecha y a qué se refiere?

**Fecha completa:** Día, mes y año. Un mes y un día sin año pueden ser incompletos, especialmente cuando podrían referirse a un acontecimiento pasado o futuro.

**Procedencia de la fecha:** ¿De dónde provino la fecha? Por ejemplo, de una declaración del usuario, una entrada de calendario importada o una deducción. Haga evidente la incertidumbre en lugar de presentar una suposición como algo definitivo.

**Momento del recordatorio:** El tiempo de antelación solicitado y la hora local, como «un día antes a las 9:00 a.m.»

**Zona horaria:** La zona que debe regir la entrega, en particular si el usuario viaja o si la fecha concierne a alguien en otra ubicación.

**Permiso y entrega:** Si el usuario desea recibir una alerta en absoluto y dónde aparecerá si el producto ofrece más de un canal de entrega.

Google Calendar permite a los usuarios configurar notificaciones para eventos y cambiar la configuración de notificaciones; la configuración de su cuenta y de sus eventos determina cómo funcionan esas notificaciones de Calendar ([Google Calendar: Cambiar notificaciones](https://support.google.com/calendar/answer/37242?hl=en)). Ese es un ejemplo útil de cómo tratar una notificación como una acción configurada con sus propios controles, no como una consecuencia automática de conocer una fecha. No debe tomarse como prueba de que Calendar tenga memoria al estilo de un compañero virtual."

Sección 3

Un ejemplo ficticio: de un detalle recordado a una alerta confirmada

Supongamos que un usuario dice: «El recital de Maya es el 14 de mayo». El compañero puede conservar eso como un **dato recordado no confirmado**: la persona, el evento y el mes/día están presentes, pero el año, la zona horaria y el permiso para notificar no lo están. No debería programar una alerta basándose únicamente en esa frase.

El compañero podría preguntar: «Tomé nota de que el recital de Maya podría ser el 14 de mayo. ¿De qué año se trata, qué zona horaria debo usar y le gustaría recibir un recordatorio?». El usuario responde: «14 de mayo de 2027, America/Los_Angeles. Por favor, recuérdame el día anterior a las 9:00 a.m. hora del Pacífico». El compañero resume: «Le recordaré el recital de Maya el 13 de mayo de 2027 a las 9:00 a.m. America/Los_Angeles, un día antes del recital del 14 de mayo. ¿Desea programarlo?».

Solo después de que el usuario confirme, el diseño debe crear un registro de notificación como: **Recital de Maya — 14 de mayo de 2027 — recordatorio el 13 de mayo de 2027 a las 9:00 a.m. America/Los_Angeles — activo**. La fecha y hora anteriores son ejemplos ficticios, no un informe sobre una persona o evento real. Nombrar la zona horaria de forma explícita ayuda a evitar tratar las «9:00 a.m.» como una hora universal. La guía de zonas horarias de Google Calendar explica que las horas de los eventos se muestran en las zonas locales y que los cambios de zona horaria pueden afectar cómo aparecen los elementos del calendario; este es un ejemplo del comportamiento de Calendar, no una afirmación sobre los recordatorios de IA ([Google Calendar: Usar Calendar en diferentes zonas horarias](https://support.google.com/calendar/answer/37064?hl=en)).

El resumen visible para el usuario es importante porque brinda una última oportunidad para detectar un mes y día intercambiados, un año equivocado, una persona incorrecta o una interpretación errónea de «el día anterior». Si el usuario edita el resumen, el compañero debe volver a formular los detalles modificados y obtener confirmación para el cronograma resultante.

Sección 4

¿Qué debería ocurrir cuando una fecha está sin resolver o genera conflicto?

No envíe una alerta basada en una fecha que el sistema no puede identificar con certeza. Por ejemplo, si una nota dice que el recital de Maya es el 14 de mayo de 2027 y otra dice que es el 21 de mayo de 2027, las fechas entran en conflicto. El compañero puede señalar el conflicto y preguntar qué fecha es la correcta, pero el estado de la notificación debe permanecer como **no programada** hasta que el usuario lo resuelva y confirme un horario.

La misma regla se aplica cuando falta un detalle esencial. «Recuérdame antes del recital» no especifica cuándo es el recital, con cuánta antelación debe llegar el recordatorio o posiblemente a qué recital se refiere el usuario. Haga una pregunta de seguimiento específica. Si el usuario no responde, mantenga el elemento como una nota no resuelta sin una notificación activa. Eso evita transformar una deducción en una alerta que el usuario nunca aprobó.

Un modelo de estados útil hace que este comportamiento sea comprensible: **no confirmado**, **necesita aclaración**, **programado**, **en pausa**, **cancelado** o **completado**. Los estados «no confirmado» y «necesita aclaración» no deben comportarse como «programado». Un sistema puede conservar el dato recordado subyacente si corresponde, pero no debe dar a entender que existe una alerta hasta que realmente se haya configurado.

Sección 5

¿Cómo deberían funcionar las correcciones, pausas y cancelaciones?

**Corrección:** Si el usuario dice que el recital es el 21 de mayo, no el 14 de mayo, actualice la fecha y vuelva a mostrar la hora propuesta para el recordatorio. Solicite confirmación antes de activar el cronograma corregido. Si ya se había programado un recordatorio, identifique con claridad qué alerta activa modificará la corrección y confirme la fecha revisada antes de reemplazarla. Conserve suficiente historial visible para explicar el estado actual, sin ocultar la fecha anterior de un modo que pueda confundir al usuario.

**Pausa:** Pausar debe detener la entrega temporalmente conservando la fecha y los detalles del recordatorio. Muestre que la notificación está en pausa y aclare si se reanudará automáticamente o si requiere que el usuario la reactive. No etiquete un recordatorio en pausa como activo. Una pausa es especialmente útil cuando el usuario desea resolver un detalle más tarde pero no quiere que se active una alerta mientras tanto.

**Cancelación:** La cancelación debe desactivar la notificación programada, no limitarse a eliminar una nota de la conversación u ocultar el elemento. Confirme qué recordatorio se está cancelando cuando más de uno pueda coincidir y luego muestre un estado de cancelado. Si la fecha recordada sigue siendo útil, manténgala separada de la alerta cancelada y ofrezca controles claros para editar o eliminar ese dato. Calendar ofrece controles para cambiar la configuración de notificaciones, incluso para un evento individual; este es un ejemplo puntual de gestión de notificaciones, no una prueba de cómo un compañero de IA almacena o cancela recordatorios ([Ayuda sobre notificaciones de Google Calendar](https://support.google.com/calendar/answer/37242?hl=en)).

Tras cualquier cambio, muestre el estado resultante y los detalles importantes: a qué fecha se refiere el recordatorio, cuándo se activaría, su zona horaria y si está activo, en pausa o cancelado. Un cambio silencioso es difícil de verificar para el usuario y puede dejar vigente una suposición desactualizada.

Sección 6

Una breve lista de verificación de auditoría para los usuarios

Antes de confiar en un recordatorio de fecha, revise el elemento en sí:

¿Se nombra a la persona o al evento correctamente?

¿Está confirmada la fecha completa, incluido el año?

¿Puedo saber de dónde provino la fecha y es visible cualquier grado de incertidumbre?

¿Aprobé explícitamente una alerta, en lugar de solo mencionar la fecha?

¿Son correctos el tiempo de antelación, la hora del reloj y la zona horaria del recordatorio?

¿El elemento indica programado y activo, o todavía necesita aclaración?

Si lo corregí, pausé o cancelé, ¿coincide el estado mostrado con lo que solicité?

Si alguna respuesta no es clara, revise o resuelva el elemento antes de tratarlo como una notificación programada. El principio de diseño práctico es simple: conserve la información incierta como incierta, haga que la alerta propuesta sea fácil de inspeccionar y cree o modifique una notificación activa solo después de que la intención del usuario y los detalles relevantes de la fecha sean claros.

Lecturas relacionadas

Sigue explorando este tema