Cómo definir un contrato de contexto para una herramienta que escucha, recuerda y actúa

Empieza por separar tres capacidades que suelen mezclarse. Escuchar significa capturar una entrada en el momento; recordar significa conservar información para reutilizarla; actuar significa modificar algo fuera de la conversación. Cuando una herramienta presenta las tres como una sola experiencia, el usuario puede aceptar más de lo que entiende. El contrato de contexto debe describirlas por separado y responder para cada una: qué datos utiliza, con qué finalidad, durante cuánto tiempo y quién puede detenerla. Esta división convierte una promesa vaga de “asistencia inteligente” en un conjunto de permisos que pueden revisarse antes de que el sistema entre en producción.

Define el inventario de datos con nombres concretos. Evita categorías amplias como “información del cliente” o “datos de trabajo”. Enumera correo, calendario, archivos, voz, ubicación, historiales, notas internas, métricas y cualquier otra fuente. Para cada elemento registra origen, propietario, sensibilidad y frecuencia de actualización. Incluye también los datos derivados: resúmenes, etiquetas, puntuaciones, inferencias y preferencias calculadas. Muchas exposiciones no nacen del dato original, sino de una conclusión que el sistema conserva y reutiliza como si fuera un hecho. El contrato debe distinguir evidencia, interpretación y decisión.

Asigna una finalidad limitada a cada fuente. Un calendario puede utilizarse para proponer horarios, pero eso no implica permiso para invitar asistentes. Un historial de compras puede servir para recomendar, pero no necesariamente para ajustar precios. Escribe la finalidad en una frase operativa y agrega una lista de usos prohibidos. Después vincula cada finalidad con un resultado visible: sugerencia, borrador, alerta, acción reversible o acción irreversible. Esta relación evita que una conexión creada para ahorrar tiempo se expanda silenciosamente hacia tareas que el usuario nunca evaluó.

Diseña retención y olvido como funciones del producto. El contrato debe indicar qué contexto vive solo durante una sesión, qué se conserva por proyecto y qué permanece hasta que alguien lo elimine. Añade fechas o eventos de caducidad: cierre de campaña, final de contrato, inactividad o cambio de responsable. Incluye el procedimiento para corregir información y propagar esa corrección a resúmenes o decisiones dependientes. Una memoria que no sabe olvidar acumula errores, datos vencidos y explicaciones imposibles de reconstruir. El olvido planificado reduce riesgo y también mejora relevancia.

Clasifica las acciones por impacto y reversibilidad. Organiza las herramientas conectadas en cuatro niveles: lectura, creación de borradores, cambios reversibles y acciones difíciles de deshacer. Para cada nivel define confirmación, evidencia y registro. Leer una agenda puede ser automático; enviar un correo requiere mostrar destinatario y contenido; cancelar una reserva puede necesitar una segunda aprobación. Evita usar una sola ventana de consentimiento para todas las acciones. La autonomía debe crecer cuando el equipo demuestra precisión, capacidad de recuperación y comprensión de las excepciones.

Convierte el contrato en una prueba observable. No basta con publicar una política. Crea casos de prueba donde el sistema recibe datos incompletos, información contradictoria, una solicitud fuera de alcance y una orden irreversible. Comprueba si pregunta, se detiene, explica la fuente y ofrece una salida segura. Registra quién aprobó cada regla y cuándo debe revisarse. El contrato debe tener versión, propietario y fecha de vigencia. Cuando cambia un proveedor, modelo o integración, la revisión debe comprobar si también cambió el tratamiento del contexto.

Cierra con una ficha que cualquier persona pueda entender. Resume en una página: fuentes conectadas, finalidades, memoria, acciones permitidas, confirmaciones, ruta de corrección, eliminación y contacto responsable. Muéstrala antes de activar la herramienta y mantenla accesible desde la experiencia. Para empezar, selecciona un flujo pequeño, completa la ficha y pruébalo durante una semana. Si el equipo no puede explicar con claridad qué sabe la herramienta, por qué lo sabe y qué puede hacer con esa información, todavía no existe un contrato de contexto; solo existe confianza implícita.