Can I Put Customer Data Into ChatGPT? What Brazil's LGPD Says

Can I Put Customer Data Into ChatGPT? What Brazil's LGPD Says

Yes, as long as the company has a clear purpose, a lawful basis under the LGPD, an account and contract suited to business use, and sends only the minimum necessary. On a personal account with default settings, the safer choice is not to send identifiable customer data. Sensitive data, children's data and large volumes call for a formal review before anything is sent.

Key takeaways

• The LGPD does not ban AI tools, but it requires a purpose, necessity and a lawful basis for every processing of personal data.
• Account type changes the risk: personal accounts, business plans and the API have different terms of use and different training conditions, and you should confirm them in the vendor's official documentation.
• Retention, chat history and training are settings the company must decide and record, not details each employee settles alone.
• Truly anonymizing data is harder than deleting a name. When in doubt, treat the data as personal.
• Sometimes the right decision is not to send: sensitive data, full documents, and any situation without a clear lawful basis or contract.

Does the LGPD prohibit using ChatGPT with customer data?

No. Brazil's General Data Protection Law (Law 13.709) regulates the processing of personal data, and pasting a customer's name, phone number or history into an AI tool is processing. That means the same rules apply to this use as to any other: specific purpose, adequacy, necessity, transparency, security and accountability, all principles in Article 6.

The most common mistake is treating ChatGPT as a private notepad. Legally, it is a third-party service that receives the data. Depending on the contract, that third party may act as a processor, while your company remains the controller, meaning the party that answers to the data subject and to the ANPD (Brazil's data protection authority). It is worth reading the article on controller vs processor in an AI vendor contract to understand who is responsible in each arrangement.

A note on sources: in this text, what we say about the law comes from the official statute. What we say about the product should be checked against the vendor's documentation, which changes over time. Process recommendations come from implementation experience, not from legal requirements. Nothing here replaces the opinion of your data protection officer (DPO) or a lawyer.

Which lawful basis supports sending data to ChatGPT?

The LGPD has no lawful basis specific to AI. You use the same ones in Article 7 and must justify which one applies to the concrete case. The ones most used in everyday company routines are:

• Performance of a contract: the data is necessary to fulfill what was agreed with the customer, for example drafting a reply about an order in progress.
• Legitimate interest: the company has a real, concrete interest, the data subject is not surprised by the use, and the processing respects their rights. It requires a documented assessment, the so-called balancing test.
• Compliance with a legal or regulatory obligation: it rarely applies to sending data to an AI, but it may apply to the original purpose.
• Consent: possible, but fragile for this case, because it must be specific, informed and revocable.

The practical point is that the lawful basis attaches to the purpose, not to the tool. If you collected a customer's phone number to deliver a service, using it to summarize a support conversation may be compatible. Using it to train a third party's model, or for purposes unrelated to the contract, probably is not.

Sensitive personal data (health, racial or ethnic origin, religious belief, biometric data, among others listed in Article 11) has narrower grounds. If your business handles this kind of data, the starting rule is not to send it to an AI tool without prior legal analysis and an environment contracted for that purpose.

Does the account type change the risk?

A great deal. In general terms, and according to OpenAI's public documentation (check the current enterprise privacy page on OpenAI's website, because the terms change), the products divide like this:

• Individual accounts, free or paid: there are data controls the user adjusts personally, including the option to allow or not allow conversations to be used to improve models. The company has no central management, cannot see who configured what, and does not control what each person does.
• Team and business plans: these usually have central administration, their own commercial terms and, according to the documentation, different treatment regarding training. This is the minimum for any recurring use with customer data.
• API: built for integration with systems, with its own terms for developers and companies. It gives more control over what goes in and what is recorded on your side, but it requires engineering.

The decisive difference is not only technical, it is contractual. On a personal account, the person accepts the terms, not the company. If an employee pastes customer data there, the company has lost the ability to prove purpose, limit access and respond to data subject requests. That is a governance problem, which is why a company policy for employee ChatGPT use comes before any training.

Also evaluate international transfer. If the vendor processes data outside Brazil, Article 33 requires a valid mechanism for that transfer. Ask the vendor where processing takes place and which contractual clauses apply, and record the answer.

What should you configure for retention, history and training?

Even on a business plan, there are decisions to make. A checklist for the administrator:

• Training: confirm, in the documentation and the contract, whether submitted data is used to improve models, and turn that option off when it exists and can be adjusted.
• History: decide whether conversations stay saved for users and for how long, bearing in mind that history is one more repository of personal data to protect and eventually delete.
• Temporary chats: features of this kind reduce what stays visible to the user, but they do not necessarily mean the vendor stores nothing. Read what the documentation says about retention for security and legal obligations.
• Access: use corporate login, strong authentication, and remove the accounts of people who leave the company.
• Export and deletion: know how to delete a specific piece of content if a data subject requests erasure (Article 18) or if something was sent improperly.
• Records: keep a record of processing operations (Article 37) that includes the use of the tool, its purpose and the types of data involved.

The goal of this list is to answer three questions without improvising: where did this data go, who had access, and how do I remove it. If the answer depends on someone's memory, the setup is not ready yet.

Is anonymizing enough? How to reduce data before sending

The LGPD defines anonymized data as data that does not allow the data subject to be identified, considering reasonable technical means at the time of processing. Anonymized data, as a rule, falls outside the scope of the law. The problem is that in company practice, almost nothing is truly anonymized: deleting the name but leaving the tax ID (CPF), the address, the order number or a combination of rare details still lets someone identify the person. In that case, the data is only pseudonymized, and it remains personal data.

A reduction order that tends to work:

• Do not send what the task does not need. To improve the tone of a reply, the customer's name is unnecessary.
• Swap identifiers for placeholders, such as Customer A, Order X and City Y, keeping the mapping table only inside your own systems.
• Generalize: instead of an exact date and address, use a month and a region.
• Remove free-text passages that carry identification, such as email signatures, attachments and transcribed audio.
• Review before sending. A second pair of eyes, or an automated check for patterns such as tax IDs, emails and phone numbers, catches what slipped through.

Illustrative scenario: a store needs help answering a complaint about a late delivery. Instead of pasting the full email, the support agent sends the text with placeholders: Customer A complains that order X, placed two weeks ago, has not arrived, and has already received two standard replies. The AI suggests a draft. The agent enters the real details in the store's own system and sends the reply through the official channel. The writing help was used without the name, address or phone number ever leaving the company.

When is it better not to send?

There are situations where the productivity benefit does not justify the risk, and the most professional answer is to keep the data out. Avoid sending when:

• There is sensitive data, such as health information, biometrics or religion, without a contracted environment and legal analysis.
• There is data about children and adolescents, which requires reinforced care (Article 14).
• The content is a full document: contract, medical record, bank statement, ID card, driver's license, proof of address.
• There is no business account, contract or internal policy authorizing that use.
• The purpose is to decide something significant about the person (credit, hiring, cancellation) without human review. In that case, see also the right to review in Article 20, covered in automated decision-making under the LGPD.
• The data is under contractual secrecy with the customer or under a professional duty of confidentiality.
• The volume is large. Pasting an entire customer spreadsheet is the highest-risk case and the one with the least necessity, because there is almost always a way to ask the AI for help without the real data.

If the use is frequent and involves personal data at scale, you may need to prepare a data protection impact assessment, the RIPD (Article 38). The article on the data protection impact assessment for AI projects explains when it applies and what to include.

A five-step plan to decide and document

To move from everyone doing as they please to a rule the company can defend, follow this sequence. It reflects the working method we use in AI projects: map, limit, pilot and hand over.

• Map: list the real uses of ChatGPT today, by department, and which customer data appears in each one. Ask the teams, do not assume. Often the use exists on personal accounts and nobody has declared it.
• Limit: for each use, define the allowed fields, the prohibited fields and the authorized account. Choose the lawful basis and record it. Each task should carry the minimum data necessary.
• Configure: adjust the business account (training, history, access), review the contract with the vendor and check the international transfer.
• Pilot: pick one real workflow, with a few people, a record of what was sent and an agreed success metric, such as response time or rework rate. Review the records to see whether anyone sent what they should not have.
• Hand over: deliver the result with written rules, short training and a named owner. Then decide whether to expand, adjust or stop. Stopping is also a valid outcome.

For the first step, the article on what not to delegate to AI in your business helps separate tasks where AI supports the work from those where the decision and the data should stay with people.

Frequently asked questions

Can I paste a customer's email into ChatGPT to ask for a draft reply? On a business account, with a purpose tied to customer support and data reduced to what is necessary, it is generally defensible. On a personal account, the recommendation is not to do it. The safest route is to swap the name, contact details and identifiers for placeholders and re-enter the real data only in your own system.

Do I need to tell the customer I use AI to process their data? The LGPD requires transparency about the purpose and about who the data is shared with. That is why the privacy policy should describe the use of technology and AI vendors in understandable terms. The exact form of the notice should be validated with your DPO or lawyer, depending on the case.

What should I do if an employee sent customer data by mistake? Record what happened, identify which data and how many people are affected, delete the content when the tool allows it, and notify the DPO. If there is a relevant risk or harm to data subjects, you may need to notify the ANPD and the affected people, following the authority's own guidance. Afterward, use the case to fix the rule, not to look for someone to blame.

Does anonymizing the data settle the LGPD question? Only if the anonymization is effective, meaning no one can identify the data subject with reasonable means. In everyday company routines, what people usually do is pseudonymization, and the data remains personal. So keep the lawful basis, contract and configuration in order even when you reduce the identifiers.

Sources

• Lei Geral de Proteção de Dados Pessoais (Lei 13.709), texto oficial
• ANPD: Autoridade Nacional de Proteção de Dados