Voltar ao blog
GDPREU AI ActComplianceData ProtectionAI GovernancePrivacyCybersecurity

A tua equipa está provavelmente a colar dados de clientes no ChatGPT gratuito — e na UE isso é ilícito

O ChatGPT gratuito não é o teu subcontratante: colar dados de clientes é ilícito. Como detetar, uma regra de uso, uma checklist e o que fazer se já aconteceu.

P
Davi Nunes
June 2, 2026Atualizado October 30, 202611 min de leitura

Alguém na tua empresa está a fazer isto neste preciso momento: o email de reclamação de um cliente colado na versão gratuita do ChatGPT, numa conta pessoal, a pedir uma resposta educada. Ou um CSV de leads para ordenar, ou uma previsão de renovações com contactos identificados pelo nome.

Na UE, isso é uma comunicação ilícita de dados pessoais. A seguir tens o fundamento jurídico e, depois, o kit para o corrigir: deteção sem vigilância, uma regra de utilização, uma checklist de fornecedores, um procedimento para incidentes, registos, AIPD e formação.

Porque é ilícito: um chatbot gratuito não é o teu subcontratante

Quando outra organização trata dados pessoais por tua conta, o artigo 28(3) do RGPD exige um contrato que vincule esse subcontratante às tuas instruções documentadas, à confidencialidade e à segurança, à tua autorização para subcontratantes ulteriores e ao apagamento ou devolução dos dados no fim.

Um chatbot gratuito de consumo não tem nenhum contrato assim com a tua empresa. O teu colaborador aceitou termos de consumidor em nome próprio e, ao abrigo deles, é o fornecedor que decide durante quanto tempo a conversa é guardada, se o seu pessoal a revê e se serve para melhorar o modelo. Uma organização que decide as finalidades do tratamento é responsável pelo tratamento de pleno direito, não o teu subcontratante. Colar nele o email de um cliente é comunicar dados a terceiros, e isso exige:

  • Um fundamento de licitude do artigo 6 para entregar dados de clientes a um fornecedor de IA para as finalidades dele. Não o tens.
  • Compatibilidade com a finalidade para a qual recolheste os dados (artigo 5(1)(b)). O cliente escreveu-te para resolver uma encomenda, não para alimentar um modelo.
  • Esse destinatário indicado na tua informação de privacidade (artigo 13(1)(e)).
  • Um mecanismo de transferência do capítulo V se o tratamento acontecer fora do EEE.

Se for feito sem autorização, é normalmente também uma violação de dados pessoais: o artigo 4(12) abrange a divulgação não autorizada. O artigo 32(4) obriga-te a tomar medidas para que quem age sob a tua autoridade só trate dados pessoais segundo as tuas instruções. A regra e a formação que vêm a seguir são essas instruções. Uma definição de privacidade numa conta de consumidor não muda nada disto: uma definição não é um contrato, e pertence ao colaborador.

Descobre se está a acontecer, sem espiar ninguém

Vigiar a navegação de cada colaborador é desproporcionado, destrói a confiança de que precisas e, em vários Estados-Membros, as ferramentas de monitorização exigem antes o envolvimento da comissão de trabalhadores. Precisas de saber que ferramentas, que equipas e que volume aproximado, não de nomes. Explica antecipadamente às pessoas o que vais analisar.

Pergunta primeiro. Faz um inquérito curto e anónimo: que ferramentas de IA as pessoas usam no trabalho, para que tarefas, com que conta e que dados lá colocam. Promete, e cumpre, que as respostas servirão para escolher ferramentas aprovadas, não para castigar ninguém.

Conta por domínio, não por pessoa. Põe os domínios de IA em ai-domains.txt, tirados da categoria de IA generativa do teu web gateway ou do teu filtro DNS, se existir, ou das ferramentas que o inquérito identificou. Conta os pedidos por domínio e descarta o endereço do cliente. No formato de log nativo do Squid, o URL é o sétimo campo:

bash
# Requests per AI domain over the log period. No user or client IP is kept.
awk '{print $7}' /var/log/squid/access.log \
  | sed -E 's#^https?://##; s#[:/].*$##' \
  | grep -F -f ai-domains.txt \
  | sort | uniq -c | sort -rn

Os logs de consultas do teu resolver DNS funcionam da mesma forma.

Revê as extensões do browser. Os assistentes de escrita e os resumidores com IA funcionam muitas vezes como extensões que conseguem ler qualquer site que o utilizador abra, CRM e webmail incluídos. Procura no inventário de extensões da tua gestão de dispositivos qualquer uma com acesso a todos os sites. Nos browsers baseados em Chromium, impõe uma lista de extensões permitidas através de política gerida:

json
{
  "ExtensionInstallBlocklist": ["*"],
  "ExtensionInstallAllowlist": ["<approved-extension-id>"]
}

Verifica registos de contas e consentimentos de aplicações. Há dois sítios que mostram os registos em ferramentas de IA sem ler o email de ninguém: o rastreio de mensagens do teu gateway de email (mensagens de boas-vindas e de verificação, contadas por domínio remetente contra a mesma lista) e as aplicações de terceiros a que os utilizadores deram consentimento no teu fornecedor de identidade. Os assistentes que tiram notas em reuniões e os assistentes de caixa de entrada com acesso ao email e ao calendário vêm primeiro.

A regra de uma página: que dados vão para que ferramenta

Uma regra que as pessoas cumprem cabe numa página e funciona nos cinco segundos antes de colar. Três tipos de ferramenta:

  • Ferramentas de consumo: chatbots gratuitos ou de plano pessoal, extensões e apps em contas pessoais, sem contrato com a tua empresa.
  • Ferramentas empresariais aprovadas: um plano empresarial ou uma API que passou a checklist abaixo, usado com contas da empresa e início de sessão único.
  • Implementações internas: um assistente que os teus engenheiros construíram sobre uma API aprovada ou um modelo alojado por vocês, com o vosso próprio controlo de acessos e os vossos próprios logs.

Depois, seis classes de dados:

  • Públicos: o que já está publicado, como os textos do teu site ou a documentação open source. Qualquer ferramenta.
  • Internos: sem dados pessoais nem segredos de clientes, como um documento de processos ou código-fonte não sensível. Ferramentas empresariais aprovadas e implementações internas.
  • Dados pessoais: tudo o que diga respeito a uma pessoa identificável: nomes, emails, telefones, IDs de cliente, endereços IP, texto de tickets, capturas de ecrã do CRM, um cargo junto com o empregador. Ferramentas empresariais aprovadas e implementações internas, para uma finalidade que conste dos teus registos das atividades de tratamento, e minimizados antes: cola a reclamação, não a assinatura.
  • Categorias especiais e dados penais: saúde, origem étnica, convicções, orientação sexual e as restantes categorias do artigo 9, além do registo criminal. Pensa em baixas médicas e investigações de RH. Nenhuma ferramenta de IA, a não ser que uma AIPD tenha aprovado essa utilização concreta.
  • Confidencial de clientes: o que os teus clientes te confiaram por contrato, como o código, a arquitetura ou as listas de clientes deles. Só se o contrato com o cliente o permitir. Nunca numa ferramenta de consumo.
  • Segredos: palavras-passe, chaves de API, chaves privadas. Nunca, em nenhuma ferramenta. Faz a rotação de tudo o que tenha sido colado.

Substituir nomes por códigos que consegues voltar a associar é pseudonimização, e os dados pseudonimizados continuam a ser dados pessoais. Só ficam fora do RGPD os dados que já não podem ser associados a uma pessoa por meios razoavelmente suscetíveis de ser utilizados, incluindo combinações como cargo, empregador e cidade.

Não sabes que ferramentas de IA as tuas equipas já usam, ou se os termos dos fornecedores aguentam? Pede uma avaliação gratuita de governação de IA: inventariamos as ferramentas em uso, comparamos cada uma com a checklist abaixo e adaptamos a regra de uma página aos teus dados.

Antes de usar um plano empresarial ou uma API: a checklist

Um plano empresarial ou uma API resolve o problema do artigo 28 apenas se o contrato disser o que precisas. Verifica por escrito antes da implementação e guarda as evidências:

  • Contrato de subcontratação: que cubra o próprio serviço de IA, não só os outros produtos do fornecedor, com os termos do artigo 28(3).
  • Sem treino com os teus dados: um compromisso contratual, e o comportamento por omissão do plano, não uma opção que cada utilizador possa ligar ou desligar.
  • Conservação e revisão humana: durante quanto tempo os prompts e as respostas são guardados, incluindo para monitorização de abusos, se o pessoal do fornecedor os pode ler, e o apagamento quando saíres.
  • Onde acontece o tratamento: a "residência de dados na UE" às vezes cobre os dados armazenados mas não o acesso do suporte nem a monitorização de abusos, por isso lê o âmbito. Tudo o que aconteça fora do EEE precisa de um mecanismo do capítulo V: uma decisão de adequação que abranja o destino, ou cláusulas contratuais-tipo com uma avaliação de impacto da transferência.
  • Subcontratantes ulteriores: uma lista publicada, aviso prévio das alterações e direito de oposição (artigo 28(2)).
  • Controlos de administração: início de sessão único, contas da empresa obrigatórias e a possibilidade de desligar funcionalidades não avaliadas, como a navegação web, os conectores, o carregamento de ficheiros e as ligações públicas de partilha.
  • Logs: logs de auditoria exportáveis de inícios de sessão, alterações de administração e utilização.
  • Notificação de violações: sem demora injustificada (artigo 33(2)), idealmente com um número de horas definido.
  • Garantias de segurança: um certificado ISO 27001 ou um relatório SOC 2 cujo âmbito inclua o serviço de IA.

A mesma checklist aplica-se quando os teus engenheiros chamam um modelo através de uma API a partir do vosso próprio código, que é a via que te dá mais controlo: escolhes que campos saem dos teus sistemas e removes os dados sensíveis antes de enviar. As opções de desenho estão no nosso guia de padrões de integração de LLM para aplicações empresariais; o lado do ataque, da injeção de prompts a um retrieval que deixa escapar documentos, é o que uma revisão de segurança de IA testa.

Dados já colados: um procedimento para avaliar o incidente

Trata cada caso como uma possível violação de dados pessoais, sem procurar culpados: quem espera castigo deixa de reportar. O prazo de 72 horas do artigo 33(1) conta a partir do momento em que a empresa tem conhecimento. A decisão é do teu EPD ou do teu advogado; este procedimento dá-lhes os factos.

  1. 1Reúne os factos: o que foi colado, quando, em que ferramenta e plano, com que conta e se existe uma ligação de partilha.
  2. 2Contém: apaga a conversa e qualquer ligação de partilha, e regista o que apagaste. Apagar do histórico pode não significar apagamento imediato no fornecedor, por isso anota o que os termos dele dizem sobre a conservação.
  3. 3Classifica: de quem são os dados, quantas pessoas, que classes e se havia dados de categorias especiais, financeiros ou de identificação.
  4. 4Se tratas os dados por conta de um cliente, és o subcontratante dele: o artigo 33(2) obriga-te a avisar o cliente sem demora injustificada, o teu contrato pode fixar um prazo mais curto e é o cliente quem decide se notifica a autoridade.
  5. 5Avalia: é obrigatório notificar a autoridade de controlo, a menos que a violação não seja suscetível de resultar num risco para os direitos e liberdades das pessoas. Se for suscetível de resultar num risco elevado, também tens de informar as pessoas afetadas (artigo 34).
  6. 6Regista-o, decidas o que decidires. O artigo 33(5) exige documentar todas as violações, notificadas ou não.
  7. 7Corrige a causa: a ferramenta que faltava, a regra, a formação.

Dois exemplos práticos; só os teus próprios factos decidem. Um agente de suporte cola a reclamação de um cliente sobre uma entrega atrasada, com nome e email, e apaga-a no mesmo dia: uma pessoa, dados de contacto comuns, nada que permita uma fraude. O habitual é concluir que não é suscetível de resultar num risco: regista-se e não se notifica. Uma responsável de RH cola a baixa médica de um colaborador: dados de saúde de uma pessoa numa posição de dependência. Aqui é muito mais provável que seja preciso notificar em 72 horas, e talvez enviar uma mensagem ao colaborador.

Registos das atividades de tratamento e quando precisas de uma AIPD

Toda a utilização aprovada de IA que toque em dados pessoais entra nos teus registos das atividades de tratamento do artigo 30. A exceção para organizações com menos de 250 trabalhadores não abrange o tratamento que não seja ocasional, e um assistente de suporte usado todos os dias não é ocasional. Uma entrada com os campos do artigo 30(1):

yaml
activity: Drafting replies to customer support tickets with an AI assistant
controller: Your Company, privacy@example.com
dpo: dpo@example.com
purpose: Faster, consistent replies to customer support requests
data_subjects: [customers, prospects]
personal_data: [name, email, order number, ticket text]
excluded_data: [special-category data, payment card data, passwords]
recipients:
  - AI provider (processor, DPA signed <date>)
transfers: None. Processing in an EU region under the contract
retention: Provider deletes prompts and outputs after <N> days per contract
security: SSO, company accounts only, no-training clause, audit logs in SIEM

Uma AIPD é obrigatória quando um tratamento, "em particular que utilize novas tecnologias", for suscetível de implicar um elevado risco (artigo 35(1)), nos casos enumerados no artigo 35(3) e para tudo o que conste da lista da tua autoridade de controlo ao abrigo do artigo 35(4). As orientações dos reguladores acrescentam sinais de alerta, e dois ou mais costumam significar uma AIPD: avaliar ou pontuar pessoas, dados sensíveis, grande escala, cruzamento de conjuntos de dados, pessoas numa posição mais fraca, como os trabalhadores, e tecnologia inovadora. A IA generativa costuma contar como inovadora, por isso basta mais um sinal para fazer pender a balança.

  • Redigir respostas de suporte: dados pessoais mais tecnologia nova. Com muito volume, isso é grande escala: faz a AIPD.
  • Um assistente de código sobre código interno sem dados pessoais: sem AIPD. Deixa por escrito porquê.
  • Ordenar candidaturas de emprego: pontuar pessoas numa posição mais fraca com tecnologia nova, portanto AIPD. Além disso, entra na área de recrutamento que o Regulamento da IA considera de risco elevado (anexo III), com obrigações a partir de 2 de dezembro de 2027. Isso é um projeto, não um prompt.

Literacia em IA ao abrigo do artigo 4: um plano de formação que consegues demonstrar

O artigo 4 do Regulamento da IA aplica-se desde 2 de fevereiro de 2025 aos prestadores e responsáveis pela implantação de sistemas de IA de qualquer nível de risco: têm de adotar medidas sobre a literacia no domínio da IA do seu pessoal e de outras pessoas que usam sistemas de IA em seu nome. O Digital Omnibus on AI, em vigor desde 27 de julho de 2026, suavizou a redação, mas a obrigação de adotar medidas mantém-se. Uma empresa que aprova ferramentas de IA para o seu pessoal é responsável pela implantação, e um plano documentado é a prova mais direta. Serve também como a tua instrução do artigo 32(4) do RGPD.

  • Todas as pessoas com uma ferramenta de IA, uma hora, à entrada e todos os anos: o que estas ferramentas são (preveem texto plausível e podem errar com toda a confiança), a regra de uma página com os teus próprios exemplos, como reportar uma colagem sem culpas e rever cada resposta antes de chegar a um cliente.
  • Utilizadores intensivos e chefes de equipa, meio dia: anonimizar na prática, perceber quando uma utilização precisa de uma AIPD e o artigo 50, que se aplica desde 2 de agosto de 2026: as pessoas têm de saber quando interagem com um sistema de IA, por isso um chatbot no teu site tem de o deixar claro.
  • Engenheiros que constroem com IA: injeção de prompts, controlo de acessos no retrieval e dados pessoais nos logs de prompts.
  • Evidências: registos de presença, a versão do material que cada pessoa viu, um questionário com casos práticos, a regra assinada e a data da próxima atualização.

Perguntas de questionário para adaptar:

  • Um cliente envia por email uma reclamação com o telefone e o número da encomenda. Com que ferramenta rediges a resposta e o que tiras primeiro?
  • Um cliente envia-te o diagrama de arquitetura dele. Uma ferramenta de IA pode revê-lo?
  • Colaste por engano o atestado médico de um colaborador num chatbot. A quem comunicas, e em quanto tempo?

Em resumo

Se ainda não verificaste, parte do princípio de que alguém na tua empresa o está a fazer. A solução não é um email a pedir às pessoas que parem. É uma ferramenta aprovada que passou a checklist, uma regra de uma página, registos que refletem a realidade, um procedimento calmo para incidentes e formação que consegues provar. O nosso serviço de governação de IA constrói exatamente esse conjunto.

Queres saber onde estás antes que um regulador ou um cliente pergunte? Marca uma avaliação gratuita de governação de IA: mapeamos as ferramentas de IA em uso, revemos os termos delas, redigimos a tua regra e os teus registos das atividades de tratamento, e acompanhamos o teu EPD em relação a quaisquer dados que já tenham sido colados.