Data Subject Requests in a Chatbot: How to Handle LGPD Rights

Data Subject Requests in a Chatbot: How to Handle LGPD Rights

To handle LGPD data subject requests through a chatbot, the agent must recognize that a message is a formal request, confirm who is asking, open a record with a human owner and return an answer within the legal deadline. The chatbot can receive and organize the request, but the decision on access, correction and deletion should follow rules the company has defined and, in sensitive cases, pass through a person.

Key takeaways

• A data subject request can show up in any conversation, in everyday words like "delete my account" or "what data do you have on me", and the agent must be instructed to recognize it.
• Before handing over or changing any data, the agent should confirm the identity of the person asking, without collecting more information than necessary.
• The ideal workflow has three stages: receive and log, decide and execute, respond and document. The agent leads the first and supports the others.
• Deletion and access requests require looking at every place the data lives: CRM, conversation history, agent memory, search indexes, spreadsheets and vendors.
• Ambiguous requests, requests from third parties, requests involving minors and requests that touch a legal duty to retain data go to a person, with the context already summarized.

Why did the chatbot become a channel for LGPD requests?

When a company serves customers on WhatsApp, its website or Instagram, the conversation is the most natural place for the data subject to speak. They rarely look for the data protection officer's form in the privacy policy. They write in the same place where they made the purchase or asked the question, and they write the way they talk.

This creates a practical obligation: if the AI agent receives the request and ignores it, replies with a generic sentence or hallucinates an answer, the company has failed to honor a right granted by law. The ANPD, Brazil's national data protection authority, is the official reference for guidance on the subject. The law (LGPD, Law 13,709) sets out the rights in Article 18 and the way to respond in Article 19, and the company's legal counsel should confirm the deadline and format currently in force.

The central point is this: the chatbot does not replace the company's privacy process. It is an entry point to that process. If the process does not exist, the first step is to create it, and only then connect the agent.

Which requests can a data subject make?

Article 18 of the LGPD lists the rights. For a chatbot's day-to-day work, these are the ones that come up most:

• Confirmation that the company processes the person's data.
• Access to the data the company holds about them.
• Correction of incomplete, inaccurate or outdated data.
• Deletion of data processed on the basis of consent, or of unnecessary or excessive data.
• Information about which entities the data has been shared with.
• Withdrawal of consent, for example to stop receiving messages.
• Data portability, where applicable and regulated.
• Information about the possibility of refusing consent and the consequences of refusing.

There is also the right to request review of decisions made solely by automated means, a topic we cover in LGPD automated decision-making and the right to review. If your agent approves, denies or classifies customers without human intervention, read it before designing the workflow.

Not every request is resolved the same way. A deletion request may collide with data the company must keep because of a legal or regulatory obligation, such as tax records. For that reason the agent should never promise "we will delete everything now". It should log the request and say that the company will review it and reply.

How does the agent recognize a request in the middle of a conversation?

Data subjects do not use the vocabulary of the law. The agent needs examples of real phrases in its instructions so it can recognize the intent. Some common forms:

• "I want you to delete my data."
• "Can you remove my number from the list? I don't want to receive anything else."
• "What information do you have about me?"
• "My email is wrong in your records, can you fix it?"
• "Who did you share my phone number with?"
• "I never authorized this contact, where did you get my data?"

The instructions to the agent should contain clear rules. When it detects an intent to exercise a right, it stops the sales flow, explains in plain language that it will log the request, asks only for what is needed to confirm identity and opens the record. It does not argue, does not try to retain the customer with an offer and does not downplay the request.

A frequent point of care: requests to stop receiving messages (opt-out) are the most common and must be handled immediately, with no queue. If the company sends outbound messages, the design of consent and unsubscribing is covered in WhatsApp outbound messages: templates, opt-in and best practices.

For writing the instructions themselves, the guide on how to write instructions for an AI support agent helps turn these rules into predictable behavior.

How do you identify who is asking without collecting too much data?

Handing data to someone who is not the data subject is a security incident. Changing or deleting data at an impostor's request is another. That is why identity confirmation comes before any action, and it should be proportional to the risk.

A practical rule is to scale the verification to what is at stake:

• Message opt-out: usually it is enough that the request comes from the same number that receives the messages.
• Simple data correction, such as the spelling of a name: confirm the number and one piece of information only the customer should know, such as the last purchase or the registered email.
• Access to data or a copy: require a second factor, such as a code sent to the email or phone already on file, or a check by a person.
• Deletion: strong confirmation, plus a record that the data subject understood the consequences, such as loss of history or warranties.
• Request on behalf of someone else: always route to a person, who reviews the power of attorney or other proof of representation.

The most common mistake is asking for a photo of an ID by default, which creates a new set of sensitive data just to handle the request. Prefer confirming through channels and data the company already has. If a document is needed, define where it is stored and for how long.

Another technical point: the agent should never decide on its own who the data belongs to. The lookup in the CRM or database should be done by a tool that only returns records of the already verified data subject. OWASP's authorization guidance describes the principle of least privilege, which applies directly: if the tool can only read the verified record, a manipulated conversation cannot extract data about other people. OWASP also maintains a list of risks for applications built on language models, the OWASP Top 10 for LLMs, which includes leakage of sensitive information and prompt injection, both relevant here.

What is the step-by-step process for handling a request?

This is a work plan that can be adapted to the size of the company. Each step says who does it: agent, person or system.

• Step one, receive: the agent recognizes the intent, explains in one or two sentences that the request will be logged and says the company will respond. It does not promise an outcome.
• Step two, classify: the agent identifies the type (access, correction, deletion, opt-out, information about sharing, review of an automated decision) and saves the data subject's original text.
• Step three, verify identity: the agent applies the verification level defined for that type of request. If verification fails or there is doubt, it hands off to a person.
• Step four, open the record: the system creates a ticket with date and time, channel, request type, data subject identifier, verification result and internal response deadline.
• Step five, locate the data: a person, or an approved routine, searches the mapped systems: CRM, ERP, support tools, conversation history, agent memory, knowledge base, spreadsheets, email tools and vendors.
• Step six, decide: the owner (normally the data protection officer or whoever they designate) decides whether to fulfill the request fully, partially or deny it with a justification, for example because of a legal retention duty.
• Step seven, execute: correction, deletion or export is carried out by the system or by an authorized person, never improvised by the agent. When data was shared with third parties, the company notifies them, as the law requires.
• Step eight, respond: the agent or a person sends the data subject the final answer in plain language, saying what was done, what was not and why.
• Step nine, document: the record is closed with the decision, the response date and the evidence of execution. This history shows, if needed, that the process works.

Illustrative scenario: a deletion request on WhatsApp

Imagine an online cosmetics store that serves customers on WhatsApp with an AI agent. A customer writes: "I want you to delete everything you have on me and stop messaging me". This scenario is illustrative, not a real case.

The agent recognizes two requests in one sentence: a message opt-out and data deletion. For the first, it logs the unsubscribe immediately and confirms that promotional messages will stop. For the second, it explains that it will open a deletion request and asks for confirmation through a code sent to the email already on file.

Once identity is confirmed, the system opens the ticket and notifies the person responsible for privacy. She locates the data: the online store account, order history, WhatsApp conversations, the contact in the email marketing tool and the agent's memory. She checks that the invoices for past orders must be kept because of a legal obligation, so those records stay, restricted and with no commercial use. Everything else is deleted or anonymized.

The agent then sends a clear reply: what was deleted, what was kept and the reason, and how to contact the data protection officer. The ticket is closed with all of this evidence. At no point did the agent promise to delete everything, and at no point did it decide which data to keep.

How do you apply map, limit, pilot and hand off?

The method we use for any AI agent in a business process fits this topic well.

• Map: list the places where personal data passes through the agent (messages, audio transcripts, CRM, memory, logs, model vendors). Without this map, you cannot handle access or deletion requests with confidence. For the channel integration, see how to integrate AI into your company's WhatsApp.
• Limit: define what the agent can do alone (receive, classify, log, unsubscribe) and what it cannot (deliver data, delete records, deny a request). Restrict its tools to the verified data subject and validate outputs, as described in guardrails for AI agents.
• Pilot: start with one request type, such as opt-out and simple correction, on one channel. Log every case, review the conversations and adjust the instructions before expanding to access and deletion.
• Hand off: define the exact point of handover to a person, with a summary of the request, the verification result and the deadline. The data subject should not have to repeat their story.

At the end of the pilot, the decision is to expand, adjust or stop, based on what the records show: requests correctly recognized, identification errors, response time and data subject satisfaction.

Checklist before putting the workflow live

• A named owner exists to receive and decide on requests, and the data protection officer's contact channel is published in the privacy policy.
• The agent has instructions with real examples of requests and a rule to never promise an outcome.
• Each request type has a defined identity verification level.
• The agent's tools only access data of the verified data subject.
• There is a list of all systems and vendors that store data coming from conversations, including the agent's memory and logs.
• A written rule exists on what may be kept because of a legal obligation and for how long.
• Requests from third parties, minors or ambiguous cases are always handed to a person.
• Each request generates a record with date, channel, decision and the reply sent.
• The workflow has been tested with simulated conversations, including attempts to impersonate someone else.

Frequently asked questions

Can the chatbot delete a customer's data automatically? Technically it can, but it is not advisable without clear rules. Deletion depends on verifying identity, checking whether there is a legal duty to keep the data and reaching every system involved. The safest approach is for the agent to log the request and for a person or an approved routine to carry out the deletion.

Is a request made in a WhatsApp conversation valid? The LGPD provides that the data subject exercises their rights by making a request to the controller, without requiring a specific format. If the person made clear what they want in the chat, the company should treat it as a valid request. Confirm with legal counsel the recording format and response deadline that apply to your case.

What should happen if someone asks for another person's data in the chat? The agent should not deliver anything and should not confirm whether that person is a customer. It explains that, for security, it only serves the data subject or a proven representative, and it hands the case to a person who can review the representation documents.

Does the conversation history with the agent also fall under an access or deletion request? Yes, in general it does, because the conversations contain personal data. This includes audio transcripts, agent memory and records on third-party platforms. That is why mapping where this data lives is the first step, and the retention policy should state how long each item is kept.

Sources

• ANPD: Autoridade Nacional de Proteção de Dados
• OWASP: Authorization Cheat Sheet
• OWASP Top 10 for LLM Applications