Minimizar lo que se guarda

Aura guarda el historial completo de cada conversación de forma indefinida, «por si hace falta». Esas conversaciones contienen datos de clientes: nombres, reservas, a veces pagos. Cada día que pasan guardadas es un día en que pueden perderse en una brecha, aparecer en una recuperación mal filtrada o terminar en un registro que alguien exporta. El riesgo de un dato guardado no se queda quieto: crece con el tiempo que lo conservas y con la cantidad de sitios por los que pasa.

Para el defensor, un almacén que crece sin límite no es una comodidad, es un pasivo. La pregunta correcta ante cada dato que Aura guarda no es «¿podría servir algún día?» —casi todo podría— sino «¿lo necesito, y hasta cuándo?». Lo que se guarda sin una razón y un plazo es superficie de fuga esperando ocasión.

La defensa se llama minimización y tiene dos ejes. Uno es qué se guarda: solo los datos que el asistente necesita para su función, no todo lo que pasa por delante «por si acaso». El otro es cuánto tiempo: cada dato tiene un plazo tras el cual se borra o se anonimiza, en vez de vivir para siempre. Aplicados a Aura, significan que una conversación se conserva lo que haga falta para dar continuidad al cliente y se purga después, y que los campos que no necesita —un dato de pago completo, por ejemplo— ni siquiera se almacenan.

No es solo higiene: es reducir la superficie por diseño. Un almacén minimizado tiene menos que perder en una brecha y menos que filtrar por un error. Es la misma idea de permiso mínimo, aplicada a los datos en reposo en vez de a las acciones: no le des al sistema —ni a un atacante futuro— acceso a datos que no hacían falta.

La minimización toca de lleno el afinado del modelo, que vimos como tercera fuga. Si el equipo de Brisa decide mejorar a Aura afinándola con conversaciones reales de clientes, esos datos pasan a formar parte del modelo, y lo que entra en el entrenamiento puede reaparecer después sin control de sesión. Afinar con material real sin tratarlo antes es la forma de guardado con peor retorno: el dato queda dentro de los pesos, donde ni se borra con una política de retención ni se filtra por identidad.

Por eso, antes de afinar, el dato se minimiza y se anonimiza: se quitan los identificadores, se reduce a lo que de verdad enseña algo, y se descarta lo que solo añade exposición. Entrenar con menos datos y mejor tratados no solo es más seguro; suele bastar. Meter conversaciones crudas de clientes en el afinado es acumular el riesgo en el peor sitio posible.

Hay una trampa al final: para vigilar un sistema con IA hay que registrar qué entró, qué se recuperó y qué se hizo —lo verás en el módulo de evaluar y vigilar—. Pero ese registro contiene datos de clientes, así que es, él mismo, un dato sensible y un canal de fuga. Un registro guardado sin protección ni plazo puede filtrar tanto como la base de datos que vigila. La vigilancia no exime de la minimización: la traza se protege, se minimiza y se le pone retención como a cualquier otro dato.

El equilibrio es real y hay que resolverlo con criterio, no eliminando una de las dos necesidades. Se registra lo suficiente para poder investigar, pero no más; se protege el registro como el dato sensible que es; y se le fija un plazo. Guardar demasiada traza, para siempre y sin proteger, es resolver el problema de la vigilancia creando un problema de fuga.

Lo que no se guarda no se puede filtrar. Compruébalo sobre Aura: abre su política de datos y retención y mira qué se conserva, por cuánto tiempo y si se anonimiza. El archivo cierra con un código de la sala.