AI Conversation Log Retention and Data Masking: LGPD Guide

AI Conversation Log Retention and Data Masking: LGPD Guide

To retain AI conversation logs in line with Brazil's LGPD, define three things for each type of record: its purpose, the shortest retention period that serves that purpose, and what gets masked before anything is written. Keep enough to audit the agent's decisions and fix mistakes, and delete the rest automatically. There is no number of days that fits every company. The period comes from the purpose and from any legal retention duties, and it should be validated with your legal team or your data protection officer.

Key takeaways

• An AI conversation log almost always contains personal data, so it needs a purpose, a legal basis and a retention period defined before go-live.
• Split logs into layers (decision, content, technical) and give each layer its own retention period instead of one period for everything.
• Mask at the point of logging, not afterward. Data that was never written cannot leak, does not need to be deleted and does not show up in a data subject request.
• Auditing an agent means tracing what it decided and why, which often removes the need to store the full conversation in clear text.
• Retention only exists in practice when deletion is automatic, tested, and covers copies, backups and whatever sits with vendors.

Why keep logs, and why not keep everything

An AI agent that serves customers or runs a process needs a record. Without logs, nobody can answer simple questions: why the agent refused this request, which instruction it followed, when it handed off to a person, which tool it called. Audits, error correction, quality review and defense in a dispute all depend on that trail.

The other side is that the conversation itself is usually the most sensitive data in the system. Customers type their name, CPF (the Brazilian taxpayer ID), address, order details, complaints and sometimes health or financial information nobody asked for. The longer and more complete the stored text, the larger the risk surface: improper access, use for a purpose different from the original one, leaks, and difficulty answering data subject requests.

LGPD handles this tension through principles, including purpose, adequacy, necessity and security. In practice, the design question is: what is the smallest record that still lets me audit? For the broader picture of the law applied to AI, read the guide on LGPD and artificial intelligence: what companies should do.

Log types and why they deserve different retention periods

Treating "the log" as one thing is the most common mistake. An agent produces at least four families of records, each with different risk and different usefulness.

• Decision log: which intent the agent identified, which rule or instruction it used, which tool it called, what the result was, whether it handed off to a human. High audit value and, if well designed, little personal data.
• Content log: the text exchanged with the customer, both user messages and model replies. Useful for investigating cases and reviewing quality, but it concentrates the personal data risk.
• Technical log: latency, errors, token usage, model and prompt version. Usually free of personal data, useful for operations and cost control.
• Access and administration log: who viewed or exported conversations, who changed configuration. This is what proves the log itself is protected.

The pattern we recommend as a working hypothesis, to be validated case by case, is: a longer period for decision and technical logs because they are less sensitive, a short period and restricted access for content logs, and access logs kept for as long as security and internal audit require.

On the technical side, the OpenTelemetry semantic conventions for generative AI help standardize what gets recorded on each call, and they treat message content as potentially sensitive, with capture being optional. That supports the idea that storing the full text should be a decision, not a default.

How to set the retention period for each layer

There is no universal period. What exists is a line of reasoning you can document and defend. Use this decision guide for each log layer, in order.

• What is the concrete purpose? Examples: investigating a complaint, reviewing agent quality, proving what was agreed, debugging a failure. If you cannot write the purpose in one sentence, do not store it.
• What is the legal basis? Each purpose needs an LGPD basis, such as contract performance, compliance with a legal obligation, legitimate interest (with an assessment) or consent. Legal or the data protection officer confirms it.
• Is there a legal or regulatory retention duty for this type of record? If so, it sets the minimum period and must be documented. If not, do not invent one.
• How long does the purpose really require? Think about the case cycle: how long does a typical complaint take to resolve? How long after the interaction can a dispute appear? The period should cover that cycle, not more.
• What happens after the period ends? Define deletion or anonymization, and who confirms it happened.
• Is there an exception for disputed cases? A hold mechanism for a specific reason (legal retention or litigation) keeps you from extending the period for everyone because of a few cases.

LGPD provides that data must be deleted when processing ends, with exceptions such as compliance with a legal obligation. That is why the period has to be a recorded decision with an owner and a review date, not a behavior inherited from a tool. Many platforms keep history indefinitely by default, so check the setting in each one.

If your agent uses model, WhatsApp or observability vendors, their retention counts too. Logs can exist in more than one place. The split of roles and responsibilities is covered in controller vs processor under LGPD, and it is worth having each vendor's retention described in the contract or in their official documentation.

Masking: what to mask, when and with which technique

Masking means reducing how identifiable the data is before it is stored. The practical rule is to mask as early as possible, ideally before the text reaches the log database or the observability service. If the raw data is written first and treated later, you have already created the copy you wanted to avoid.

Obvious masking candidates in Brazilian conversations:

• CPF, CNPJ, RG and other documents.
• Phone number, email and full address.
• Card numbers, bank details and Pix keys.
• Full name, when it is not needed for the purpose of the log.
• Health data, data about minors and other sensitive data mentioned spontaneously.
• Secrets the user pastes into the chat, such as passwords and tokens.

There are three levels, and the difference matters under LGPD:

• Partial masking: keep part of the value (for example, the last digits) so a person can cross-check. The data is still personal.
• Pseudonymization: replace the identifier with a code, keeping the reversal key separate and protected. The data is still personal, because it can be re-identified with the key.
• Anonymization: remove any reasonable possibility of identifying the person. Only then does the data stop being personal, and the bar to prove it is high.

In implementation, a balanced approach is to store the decision log with a pseudonymized identifier and the conversation text with sensitive entities replaced by labeled placeholders, such as a tag reading CPF or PHONE in brackets. An auditor can still understand what happened, and the risk drops considerably. Pattern-based detection works well for documents and phone numbers and fails more often with names and free-text details, so treat detection as risk reduction, not as a guarantee.

Masking also protects against a risk listed in the OWASP Top 10 for LLM applications: sensitive information disclosure. A log full of clear-text personal data is an easy target, and anyone with access to the observability dashboard effectively gains access to the customer base. In addition, the input and output validation described in guardrails for AI agents can stop sensitive data from entering the flow in the first place.

Illustrative scenario: a support agent on WhatsApp

This is an illustrative scenario, unrelated to any real case. A store uses an AI agent on WhatsApp to report order status, open exchange requests and pass difficult cases to a person. The team wants to audit the agent's decisions and review conversations that ended in a complaint.

The retention design could look like this:

• Decision log: stores the identified intent, the tool called, the result, the reason for any handoff and a pseudonymized customer identifier. Longer period, reviewed periodically, access for operations and audit.
• Content log: stores the text with CPF, phone, address and email replaced by placeholders. Short period, enough for the normal cycle of a complaint. Access limited to a few people, with every lookup recorded.
• Conversations tied to a formal complaint or dispute: flagged with a hold for a specific reason, with an owner and a review date. When the reason ends, they return to the normal period.
• Media sent by the customer, such as a photo of a receipt: kept out of the content log. It stays in the order system, under that system's rules.
• Deletion: a daily automatic routine that erases what has expired and writes a record, without content, showing the routine ran.

With this design, an audit can explain why the agent opened an exchange, and a deletion request from a data subject can be handled by locating the identifier, without scanning free text for names. For the channel side, the guide on how to integrate AI into your company's WhatsApp explains the flow where these records originate.

Step-by-step plan to implement retention

The method we apply in agent projects follows four moves: map, limit, pilot and hand over. Applied to log retention, it looks like this.

Map:

• List every place where the conversation leaves a trace: channel platform, orchestrator, database, observability tool, model vendor, spreadsheets and export emails.
• For each place, note what is stored, for how long today and who has access. Copies nobody remembered almost always turn up.

Limit:

• Write the purpose of each log layer and remove whatever has no purpose.
• Define periods per layer, with a legal basis and an owner.
• Implement masking at the source and restrict access by role, with lookups recorded.
• Check retention and training opt-out options with vendors, in official documentation or in the contract.

Pilot:

• Run one real flow, not all of them at once, with logs in the designed layers.
• Test with synthetic conversations containing fictional data. Did the masking catch it? Did deletion run on schedule? Was a fictional data subject's deletion request fulfilled across every copy?
• Agree on a success metric before starting, for example whether the audit team can explain an agent decision using only the masked log. To structure that measurement, see how to measure an AI automation pilot.

Hand over:

• Deliver the retention policy, the log inventory, the data subject request procedure and the owner of each routine.
• Decide with the team whether the design expands to other flows, gets adjusted or stops.

If the processing involves a relevant volume of personal or sensitive data, consider creating or updating an impact assessment. The article on the data protection impact assessment for AI projects shows when that makes sense and what to include. For official guidance on data protection in Brazil, the reference is the ANPD, the national data protection authority.

Common mistakes that undo a retention policy

• Setting the period on paper while leaving the tool on unlimited retention by default.
• Masking only on the lookup screen while the database stores the raw text.
• Forgetting backups, exports and test environments that received copies of real conversations.
• Granting broad access to the log dashboard because "it's only for debugging".
• Using real conversations, untreated, as evaluation or prompt-tuning material without reassessing the purpose.
• Extending everyone's period because of a few cases, instead of flagging individual exceptions.

None of these mistakes needs sophisticated technology to fix. They need an owner, an inventory and periodic testing.

Frequently asked questions

What is the ideal retention period for AI conversation logs?

There is no universal ideal. The right period is the shortest one that serves the documented purpose and any legal obligations. It is usually shorter for conversation text and longer for decision records that contain no personal data. Validate the definition with legal or your data protection officer.

Does masking the data solve LGPD compliance?

Not by itself. Masking and pseudonymization reduce risk, but pseudonymized data is still personal data, and you still need a purpose, a legal basis, a retention period, access control and a way to handle data subject requests. Only effective anonymization takes data outside the law, and it is hard to prove for free text.

Do I need to store the full conversation to audit the agent?

Generally no. A well-designed decision log, with the intent, the tool called, the result and the reason for any handoff, answers most audit questions. Keep the text, masked and for a short period, for the cases where reviewing the conversation truly adds value.

Does the model or platform vendor also retain the conversations?

They may, and the period and conditions vary by vendor and by plan. Check each vendor's official documentation and contract, record it in your log inventory and see whether there is an option to reduce retention or to opt out of using the data for training.

Sources

• ANPD: Autoridade Nacional de Proteção de Dados
• OpenTelemetry: semantic conventions for generative AI
• OWASP Top 10 for LLM Applications
• NIST AI Risk Management Framework