A financial assistant can receive far more data than necessary. Separating public questions from account-related requests allows for designing a more restrained and safer user journey.
A user looks for an explanation about fees. To help the assistant, they spontaneously attach a screenshot of their account, showing their name, balance, recent transactions, and sometimes their contact details. A general question thus triggers the collection of information that may not have been necessary for the answer.
For product teams and customer relations managers, the first decision should concern the information each request actually needs, before choosing the model and the editorial quality of the responses. An assistant capable of reading a full statement should not receive that statement by default.
Separating public information from the individual case file
The French Data Protection Authority (CNIL) defines data minimization as data that is ‘adequate, relevant and limited to what is necessary for the purposes for which they are processed’. Applied to an assistant, this principle requires precisely describing the service provided: explaining a concept, finding a help page, or examining a personal situation does not require the same context.
Let’s take a fictional scenario. A person asks a general-purpose assistant where to find public information about BYDFi, then adds a screenshot of their personal history. The first request calls for documentary research, while the attachment introduces an individual case file. The user journey should then offer to remove this document and specify when it is necessary to switch to an appropriate official channel. This scenario illustrates a design choice, without presuming the tools used by this company.
This separation can appear from the welcome screen. An entry point labeled ‘understand a service’ opens a conversation without account data, while an entry point labeled ‘get help on my case’ explains the necessary information and the conditions for accessing the relevant service. The visitor thus knows what they can communicate before starting to write.
Prevent collection in the interface
A guideline buried in the terms of use is of little help when attaching a file. The reminder must therefore be placed near the relevant field: do not transmit any passwords, login codes, or access secrets, and remove information unrelated to the request. For a general question, one can start by disabling attachments and suggesting a rephrasing without personal data.
When a document is necessary, requesting a specific extract limits the scope of collection. The screen should explain which lines are useful and which information can be masked. An automatic check can spot certain risky content, but its errors must be anticipated: a number may go unnoticed, and a harmless text may be blocked. An alternative solution must remain accessible.
In its advice on chatbots published on February 19, 2021, the CNIL notably recommends a warning before use and a purge mechanism when sensitive data is provided unexpectedly. These recommendations concern categories sensitive under the GDPR, which does not mean that all financial data legally falls into this category. Account information may nevertheless require strong protection.
Track data beyond the conversation, then test before launch
Removing data from the displayed response does not prove it has disappeared from processing. The team must examine what was transmitted to the model, added to technical logs, retained in the support tool, or integrated into an evaluation dataset. For each copy, a purpose, authorized persons, and a retention rule must be identified. The CNIL recalls that the retention period depends on this purpose: a guidance conversation and an exchange necessary for following up a complaint can therefore call for different durations.
The contract and settings of the provider also deserve a concrete check. Who has access to messages? Is there any reuse to improve a model? How is a deletion applied across the different systems? The answers must be documented for the actual configuration used, then re-examined with each change of tool or purpose.
A useful recipe starts with ordinary requests, to which superfluous information is voluntarily added: contact details in a general question, an overly broad screenshot, a document concerning a third party. Tests should use fictitious data and verify the entire path, from input to logs, as well as the intended deletion. Metrics can track attachments requested without necessity, data avoided before transmission, filtering errors, and referrals to a human agent.
