Hacer que cada función use el contexto mínimo justificable
Una aplicación de compañía puede ser útil sin consultar un retrato amplio y permanente para cada función. Empieza con una prueba base sin perfil: ¿se puede abrir la herramienta, hacer una elección puntual, obtener un resultado neutral y completar la tarea cuando faltan los intereses guardados, las inferencias, el historial, la ubicación y los contactos? Añade después solo el contexto que cambie una decisión concreta y nombrada. En un registro de dependencias anota la salida afectada, la fuente, si el dato fue aportado o inferido, por qué es necesario, cuál es la alternativa neutral, su alcance y caducidad, cómo se corrige y qué ocurrió durante la prueba. Así la personalización sigue disponible, pero no se convierte en un requisito invisible para utilizar el resto del servicio.
Registrar decisiones visibles, no buscar usos para campos existentes
Comienza por las salidas que la persona encuentra: sugerencias de inicio, temas de conversación, horarios de recordatorios, orden de búsqueda, reaparición de elementos guardados, idioma, notificaciones y opciones de compartir. Escribe para cada salida la decisión exacta y el campo consultado. Que un dato ya esté almacenado no demuestra que sea necesario. Prueba por separado qué pasa si está vacío, es incorrecto, ha quedado antiguo o no está disponible durante un momento. La orientación de la ICO sobre minimización indica que los datos deben ser adecuados, pertinentes y limitados a lo necesario para la finalidad, además de revisarse cuando dejan de hacer falta. En una función, la pregunta práctica es cuál es la entrada más pequeña que permite decidir hoy. Un idioma elegido por la persona y un gusto inferido de unos pocos clics requieren filas distintas, porque su fiabilidad, corrección y vigencia no son iguales.
Diseñar un recorrido completo para un perfil vacío
Ejecuta cada función con una cuenta nueva y con otra que conserve únicamente los datos imprescindibles para crearla. La pantalla inicial debe seguir siendo comprensible, la búsqueda debe aceptar una petición explícita y las sugerencias pueden ofrecer varios puntos de partida neutrales. Una elección como «hoy quiero ideas para estar en casa» puede aplicarse a la sesión y desaparecer al terminar, sin transformarse en un rasgo permanente. Si la función no puede continuar, debe nombrar el dato ausente y explicar su necesidad inmediata, no pedir una descripción amplia de la persona. Para un recordatorio quizá baste una hora elegida; no hacen falta automáticamente todas las conversaciones anteriores. Para mostrar la interfaz puede hacer falta un idioma, pero no la ubicación ni una lista de aficiones. Si un dato opcional bloquea también los ajustes o la exportación, la dependencia está mal delimitada.
Separar el contexto de sesión del perfil persistente
El contexto puede durar una pantalla, una conversación, un proyecto con fecha de término o toda la cuenta. Elige el alcance más corto que aún permita completar la tarea. Las condiciones puntuales deben caducar con su uso. Cuando conservarlas aporte una comodidad real, muestra antes qué se guardará, qué funciones lo leerán, cuándo se revisará y cómo excluirlo o restablecerlo. Las inferencias necesitan una fuente visible y una revisión más frecuente, porque pueden perder exactitud antes que una elección directa. Un dato cómodo nunca debería ser requisito oculto para acceder a la cuenta o revisar la privacidad. La limitación de la finalidad y la minimización del artículo 5 ofrecen una comprobación clara: ¿este campo sigue siendo necesario para el propósito explicado o se reutiliza simplemente porque ya existe?
Dar a cada dependencia una alternativa, una corrección y una caducidad
Asigna una salida neutral a cada entrada opcional: orden cronológico en lugar de orden predicho, categorías amplias en lugar de etiquetas personales, búsqueda manual en lugar de un atajo inferido o borrador privado en lugar de un público supuesto. Registra solo los controles que existen de verdad en el producto: editar, borrar, excluir de esta función o restablecer todo. Después comprueba si la corrección llega a la salida dependiente. ¿Cambian las sugerencias existentes, solo las futuras o permanece un objeto derivado? El Privacy Framework de NIST sitúa el riesgo en el procesamiento y la gobernanza completos, no en un único interruptor. Por eso el registro debe mostrar responsables, destinos derivados y plazos desconocidos como cuestiones abiertas, sin rellenarlos con suposiciones.
Comparar el estado personalizado y el neutral con tareas inocuas
Prepara dos estados que tengas permiso para manejar: uno con el perfil mínimo y otro con una sola preferencia inofensiva. Realiza en ambos la misma búsqueda, selección y guardado. Compara si la tarea se completa, si la explicación es clara, si la preferencia aparece en áreas que no guardan relación y si una corrección produce un cambio previsible. Elimina la preferencia y revisa otra vez sugerencias, notificaciones, opciones de compartir, exportación y perfil visible. Anota versión, idioma, dispositivo, entrada, alternativa esperada, salida observada y dudas pendientes. Repite la prueba cuando una función empiece a leer una fuente nueva, tras una actualización importante o si un dato sigue influyendo después de su fecha declarada. Aprobar no significa producir resultados iguales; significa que el recorrido neutral funciona y que la personalización tiene límites rastreables.
Preguntas frecuentes
¿Reducir la dependencia del perfil obliga a desactivar toda personalización?
No. Exige que cada decisión personalizada tenga una entrada necesaria, alcance limitado, alternativa neutral, vía de corrección y revisión.
¿Qué es una prueba base sin perfil?
Es el recorrido que se ha comprobado como utilizable cuando no existen campos opcionales guardados ni inferidos.
¿Una preferencia inferida debe durar lo mismo que una elección directa?
No de forma automática. Necesita una fuente visible, una corrección sencilla y una caducidad acorde con lo rápido que puede quedar antigua.